RBAC Denkmodell

Das Modell in drei Fragen

Azure RBAC wird deutlich einfacher, wenn du jede Berechtigung als Antwort auf drei Fragen behandelst:

1. Wer? (Security Principal) – Benutzer, Gruppe, Service Principal oder Managed Identity.
2. Was? (Role Definition) – welche Aktionen sind erlaubt/verboten.
3. Wo? (Scope) – auf welcher Ebene gilt es: Management Group, Subscription, Resource Group oder Ressource.

Eine RBAC-Zuweisung ist dann schlicht: Principal bekommt Rolle auf Scope.

Scope zuerst, Rolle danach

In der Praxis entstehen die meisten Over-Permissions nicht, weil jemand die “falsche” Rolle auswählt – sondern weil der Scope zu breit ist.

Bewährte Reihenfolge:

1. Scope minimieren: Kann es eine Resource Group statt Subscription sein? Kann es ein dedizierter Shared-Service-Scope sein?
2. Rolle wählen: Reader/Contributor/Owner sind grob – oft gibt es spezifischere Rollen (z. B. “Key Vault Secrets User”).
3. Vererbung bedenken: Eine Zuweisung auf Management Group wirkt in allen darunterliegenden Subscriptions.

Rollen sind Aktionspakete

Eine Role Definition ist ein Bündel aus actions, notActions, dataActions und notDataActions.

• Management plane (actions): Erstellen/Ändern von Ressourcen (ARM).
• Data plane (dataActions): Zugriff auf Daten (z. B. Storage Blob lesen/schreiben).

Das ist der Grund, warum „Contributor“ nicht automatisch Zugriff auf Daten bedeutet – und warum Storage-/KeyVault-Zugriffe oft zusätzlich konfiguriert werden müssen.

Beispiel: “Ich darf den Storage Account, aber nicht die Blobs”

Typische Situation:

• Du kannst den Storage Account im Portal öffnen, Settings ändern, Diagnostics konfigurieren.
• Der Zugriff auf Container/Blobs schlägt mit 403 fehl.

Ursache:

• Dir fehlen Data-Plane-Rollen (z. B. “Storage Blob Data Reader/Contributor”) auf dem passenden Scope.

Das ist kein Bug, sondern ein bewusstes Trennmodell. Für Troubleshooting hilft, zuerst zu klären: Geht es um ARM (Ressource verwalten) oder um Datenzugriff?

Gruppen statt Einzelzuweisungen

Für Menschen ist “User → Rolle” fast immer die falsche Ebene. Gute Praxis:

• Rollen werden an Entra-Gruppen vergeben.
• Benutzer werden in Gruppen aufgenommen (Join/Leave ist dann der Change, nicht die RBAC-Struktur).
• Namenskonventionen machen Scopes sichtbar (z. B. az-sub-prod-app1-contributor).

Typische Scopes und was dort hingehört

• Management Group: Plattform-Governance (Policy, RBAC-Baselines, zentrale Reader-Rollen). Sehr vorsichtig mit Contributor/Owner.
• Subscription: Workload-Teams, die die Subscription “besitzen” (aber idealerweise ohne Rechte zu delegieren).
• Resource Group: Standard für Workload-Delegation; hier ist Least Privilege am einfachsten.
• Ressource: für punktuelle Delegation (z. B. ein Key Vault, ein Storage Account).

Debugging: Warum habe ich (k)einen Zugriff?

Ein schneller Diagnosepfad:

• Identität: Bist du im richtigen Tenant und Subscription-Kontext?
• Token: Wurde nach Rollenänderungen ein neues Token gezogen (Portal/CLI)?
• Scope: Liegt die Zuweisung wirklich über der betroffenen Ressource?
• Deny Assignments: Manche Dienste/Blueprints/Managed Apps erzeugen Deny Assignments, die RBAC “überstimmen”.
• Conditional Access: Für Portal/CLI kann CA unterschiedlich wirken (MFA, compliant device, named locations).

Wenn du reproduzierbar debuggen willst, hilft oft ein sehr konkreter Ablauf:

1. Kontext festziehen (Tenant/Subscription).
2. RBAC-Zuweisung und Scope prüfen (nicht nur “Rolle ist da”).
3. Token erneuern (nach Aktivierung/Änderung) und Propagation-Zeit einplanen.
4. Erst dann Policies/Deny Assignments als Ursache prüfen.

Checkliste für saubere RBAC-Designs

• Scopes klein halten, Delegation auf RG-Ebene bevorzugen.
• Human Access über Gruppen modellieren.
• Privilegierte Rollen zeitlich begrenzen (siehe RBAC vs. PIM).
• Data-Plane-Berechtigungen explizit prüfen (Storage/Key Vault/SQL).