Skip to content
ViganoLabs Dokumentation

Entra-Identität für Azure Workloads

Problemstellung

Section titled “Problemstellung”

Workloads in Azure brauchen Identität für zwei sehr unterschiedliche Dinge:

  • Laufzeit-Zugriff (z. B. App liest Secret aus Key Vault, schreibt in Storage)
  • Deployment/Provisioning (z. B. Pipeline erstellt Ressourcen via ARM)

Wenn diese beiden Pfade vermischt werden, entstehen überprivilegierte Identitäten und schwer auditierbare Berechtigungen.

Grundprinzipien

Section titled “Grundprinzipien”

1) Laufzeit und Deployment trennen

Section titled “1) Laufzeit und Deployment trennen”
  • Laufzeit: Managed Identity (oder Workload Identity je nach Plattform) mit minimalem Scope.
  • Deployment: dedizierte CI/CD-Identität mit eingeschränktem Scope pro Stack/Subscription.

2) Secrets vermeiden

Section titled “2) Secrets vermeiden”

Wo möglich:

  • Managed Identities (Azure-native)
  • Federation (OIDC) für CI-Systeme statt Client Secrets

Wenn du CI/CD modern betreibst, ist OIDC/Federation ein großer Hebel: du eliminierst langlebige Secrets und bekommst besser auditierbare Zugriffspfade.

3) Least Privilege über Scopes

Section titled “3) Least Privilege über Scopes”

Eine “richtige” Rolle am falschen Scope ist immer noch zu viel.

Default:

  • Workload-Identitäten auf Resource Group oder Ressource.
  • Nur in Ausnahmefällen Subscription-breit.

Muster: Service-zu-Service Zugriff

Section titled “Muster: Service-zu-Service Zugriff”

Beispiele:

  • App Service → Key Vault (Secrets User)
  • Function → Storage (Blob Data Contributor)
  • Automation → Policy Remediation (Policy Contributor + spezifische Rollen)

Der Zugriff sollte explizit je Dienst modelliert sein, statt generisch “Contributor” zu vergeben.

Muster: Identity-”Schichten” pro Umgebung

Section titled “Muster: Identity-”Schichten” pro Umgebung”

Eine robuste Struktur trennt Identitäten nach Umgebung und Zweck:

  • ci-nonprod-* für Deployments in Non-Prod
  • ci-prod-* für Deployments in Prod
  • Workload-Identitäten je Anwendung/Service (nicht “eine MI für alles”)

Das macht Reviews und Containment im Incident-Fall deutlich einfacher.

RBAC-Design: so klein wie möglich, so klar wie nötig

Section titled “RBAC-Design: so klein wie möglich, so klar wie nötig”

Praktische Heuristik:

  • Deployments brauchen häufig ARM-Rechte auf RG/Subscription.
  • Laufzeit braucht häufig Data-Plane-Rechte auf konkreten Ressourcen.

Wenn du diese beiden vermischst, entsteht schnell eine Identität, die “alles” kann – und niemand traut sich später, Rechte zu entziehen.

Betriebliche Hinweise

Section titled “Betriebliche Hinweise”
  • Monitoring: Logge und überwache AuthZ-Fehler (403) als Frühindikator für Drift.
  • Review: Regelmäßige Überprüfung der Role Assignments (insbesondere bei User-assigned MIs).

Verwandte Themen

Section titled “Verwandte Themen”