5 typische Azure-RBAC-Fehler in Projekten und wie du sie vermeidest

Azure Role-Based Access Control (RBAC) scheitert im Projektalltag selten an fehlenden Features. Die Probleme entstehen meist dort, wo unter Zeitdruck zu breite Rollen, falsche Scopes und fehlende Governance als pragmatische Ausnahme durchrutschen. Aus genau diesen Ausnahmen wird nach und nach ein dauerhaftes Berechtigungsmodell mit zu vielen Owner-Zuweisungen, unklaren Verantwortlichkeiten und langen Diskussionen vor dem nächsten Audit.

Dieser Artikel schaut deshalb auf typische Fehler aus realen Projekten. Wer diese Muster früh erkennt, bekommt meist auch einen ruhigeren Betrieb. Die Angriffsfläche schrumpft, Offboarding wird einfacher und Berechtigungen bleiben für Plattformteams, Auditoren und Fachbereiche nachvollziehbar.

Warum Azure RBAC in Projekten so oft entgleist

Die Azure-RBAC-Grundmechanik ist eigentlich klar. Ein Principal, also etwa ein Benutzer, eine Gruppe oder eine Dienstidentität, bekommt eine Rolle auf einem Scope, und über die Vererbung entstehen daraus effektive Berechtigungen. In Projekten wird daraus trotzdem schnell ein unübersichtliches Konstrukt, weil RBAC oft nebenbei entsteht, während das Team eigentlich liefern will.

Ein Go-Live rückt näher, ein Deployment hängt an fehlenden Rechten, und jemand vergibt eben schnell Owner auf Subscription-Ebene. Technisch funktioniert das sofort. Organisatorisch folgen daraus meist weitere Ausnahmen, zusätzliche Einzelzuweisungen und immer mehr Nacharbeit beim Offboarding.

Microsoft beschreibt in den Azure-RBAC-Best-Practices Least Privilege, kleine Scopes und wenige privilegierte Rollen als klare Leitplanken. Im Alltag kippt genau das zuerst. Die folgenden fünf Fehler sind in vielen Azure-Umgebungen ganz gewöhnlicher Alltag.

Fehler 1: Rechte auf zu breitem Scope vergeben

Am häufigsten liegt das Problem beim Scope. Wenn ein Team Contributor oder Owner auf Subscription- oder Management-Group-Ebene vergibt, obwohl eigentlich nur eine einzelne Resource Group betroffen ist, vervielfacht sich der Schaden eines Fehlers oder eines kompromittierten Kontos sofort. Laut der Scope-Übersicht von Microsoft ist genau diese Vererbung der zentrale Hebel im Modell.

Warum passiert das so oft? Weil ein breiter Scope zunächst bequem wirkt. Wenn Resource Groups unsauber geschnitten sind oder Verantwortlichkeiten nicht klar festgelegt wurden, scheint eine Zuweisung auf Subscription-Ebene wie der einfachste Weg. Die Komplexität landet damit nur später im Betrieb, in der Incident Response und im Audit.

Ein typisches Beispiel ist ein Deployment-Service, der nur in einer Ziel-Resource-Group Ressourcen aktualisieren soll. Bekommt er stattdessen Contributor auf der ganzen Subscription, kann derselbe Principal plötzlich auch in anderen Umgebungen arbeiten, Tags ändern oder bestehende Ressourcen versehentlich beeinflussen. Damit wächst für denselben Use Case der potenzielle Schadensbereich deutlich, also der Blast Radius.

Ein paar typische Fehlmuster zeigen das ziemlich klar.

• Contributor auf Subscription statt Contributor nur auf der betroffenen Resource Group.
• Owner für ein Projektteam statt Owner nur für sehr wenige Plattformverantwortliche.
• Ein gemeinsamer Scope für Dev, Test und Prod statt eigener Scopes entlang von Lifecycle und Verantwortung.

In Infrastructure as Code lässt sich der gewünschte Scope explizit festhalten. Ein kleines Bicep-Beispiel zeigt das besser als jede Portal-Maske.

param principalId string
param resourceGroupName string

// Integrierte Rolle Contributor
var contributorRoleId = 'b24988ac-6180-42a0-ab88-20f7382dd24c'

resource targetRg 'Microsoft.Resources/resourceGroups@2024-03-01' existing = {
  name: resourceGroupName
}

resource rgAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(targetRg.id, principalId, contributorRoleId)
  scope: targetRg
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', contributorRoleId)
    principalId: principalId
    principalType: 'ServicePrincipal'
    description: 'Deployment für genau diese Resource Group'
  }
}

Starte immer mit dem kleinsten sinnvollen Scope und erweitere nur dann, wenn der reale Bedarf nachgewiesen ist. Die Empfehlung von Microsoft, die Zahl der Subscription Owner strikt klein zu halten, reduziert in Projekten vor allem unklare Verantwortlichkeiten und senkt den Aufwand bei Audit und Incident Response.

Fehler 2: Rollen direkt an Personen statt an steuerbare Principals vergeben

Der schnellste Weg im Portal ist oft die direkte Zuweisung an einen Benutzer. Genau deshalb ist sie so beliebt. Für ein belastbares Betriebsmodell ist sie aber fast immer die schlechtere Wahl.

Die Best Practices für Azure RBAC empfehlen Rollen an Gruppen statt an Benutzer zu vergeben. Das prägt den späteren Betrieb ganz direkt. Gruppen machen Verantwortlichkeiten sichtbar, reduzieren die Zahl der Assignments und vereinfachen Onboarding sowie Offboarding erheblich.

Noch wichtiger ist die saubere Trennung der Principal-Typen. Menschen solltest du über Gruppen steuern. Anwendungen und Automatisierung gehören, wo möglich, an Managed Identities oder Service Principals. Direkte User-Zuweisungen bleiben damit die begründete Ausnahme, nicht der Standard.

Sobald Teams diesen Grundsatz ignorieren, entstehen schnell dutzende Einzelzuweisungen für Incident-Fälle, Sonderdeployments oder Projektspitzen. Wenn dann jemand die Rolle wechselt oder das Unternehmen verlässt, bleiben Berechtigungen leicht liegen. Microsoft weist in der Dokumentation zu Role Assignments und Principals ausdrücklich darauf hin, dass gelöschte Identitäten als Identity not found sichtbar bleiben können und aktiv bereinigt werden müssen.

Pragmatisch bedeutet das für Projekte vor allem eines. Definiere RBAC-Gruppen pro Funktion oder System, zum Beispiel für Plattformbetrieb, Deployment oder lesenden Support. Nutze Managed Identities für Workloads konsequent dort, wo Azure sie anbietet. Und behandle jede direkte User-Zuweisung wie einen Ausnahmefall mit Ablaufdatum.

Fehler 3: Die falsche Rolle als Quick Fix verwenden

Viele RBAC-Fehler wirken im ersten Moment wie Zeitgewinn. Meist verschieben sie das Problem nur nach hinten. Wenn jemand für einen Datenzugriff Contributor bekommt oder eine App gleich mit Key Vault Administrator ausgestattet wird, steckt dahinter meist ein Quick Fix unter Druck und selten ein sauberer Architekturentscheid.

Ein häufiger Stolperstein ist die Verwechslung von Control Plane und Data Plane. Ein Contributor darf Ressourcen verwalten, aber nicht automatisch auf alle Daten innerhalb dieser Ressourcen zugreifen. Wer für Blob-Daten nur lesen muss, braucht eher eine passende Data-Plane-Rolle wie Storage Blob Data Reader als eine breit angelegte Verwaltungsrolle. Dasselbe gilt für Key Vault, wo für viele Anwendungen die Rolle Key Vault Secrets User ausreicht.

Noch problematischer wird es bei Custom Roles mit Wildcards. Microsoft warnt in den RBAC-Best-Practices und in der Dokumentation zu Wildcard-Berechtigungen nicht ohne Grund davor. Ein * in Actions oder DataActions kann künftig neue Berechtigungen automatisch mitgeben, obwohl du sie heute noch gar nicht auf dem Schirm hast.

Wenn eine Built-in Role nicht passt, solltest du eine Custom Role möglichst eng aus konkreten Aktionen ableiten. So bleibt nachvollziehbar, was die Rolle wirklich kann. Der Nachteil ist zusätzlicher Pflegeaufwand, aber der ist im Betrieb fast immer billiger als eine dauerhaft überprivilegierte Standardrolle.

{
  "Name": "Storage Container Metadata Reader",
  "IsCustom": true,
  "Description": "Darf Container lesen, aber keine Daten ändern oder löschen.",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>/resourceGroups/<rg-name>"
  ]
}

Ein pragmatischer Weg ist hier fast nie der breiteste. Prüfe zuerst Built-in Roles, modelliere Datenzugriff bewusst separat und behandle jede privilegierte Administratorrolle als Ausnahme mit klarer Begründung.

Fehler 4: Privilegierte Rechte permanent vergeben

Permanente Owner- oder User Access Administrator-Zuweisungen sind bequem, aber sie vergrößern die Angriffsfläche jeden einzelnen Tag. In gewachsenen Umgebungen bleiben solche Rechte oft lange bestehen, obwohl sie nur für einen Change, eine Migration oder einen Incident gebraucht wurden.

Die Microsoft-Empfehlung für Privileged Identity Management ist sinnvoll, wenn du hochriskante Azure-Ressourcenrollen zeitlich begrenzen willst. Mit eligible statt dauerhaft active reduzierst du Dauerechte, ohne jede Ausnahme erst durch ein manuelles Ticket schicken zu müssen. Der Hebel ist aber nicht kostenlos, weil PIM zusätzlichen Prozess- und Lizenzaufwand mitbringt. Mehr zum praktischen Nutzen und zur Einführung findest du in unserem Artikel: Entra ID PIM: Weniger Dauerechte, mehr Kontrolle.

Wichtig ist die richtige Dosierung. Legst du jede mittlere Betriebsrolle mit starren Freigaben lahm, wird das Modell im Alltag umgangen. Konzentrierst du PIM auf Owner, User Access Administrator und wenige weitere Hochrisiko-Rollen, steigt die Sicherheit spürbar, ohne den Betrieb auszubremsen. Die Dokumentation zu Azure-Ressourcenrollen in PIM liefert dafür den technischen Rahmen.

PIM ist in diesem Zusammenhang nicht der eigentliche Fix für schlechtes RBAC-Design. Es verhindert aber, dass historisch gewachsene Sonderrechte dauerhaft offen bleiben. Wenn PIM in einer kleineren Umgebung organisatorisch nicht realistisch ist, ist eine manuell befristete Zuweisung mit sauberem Review immer noch besser als ein permanenter Owner. Für Plattformteams mit mehreren Subscriptions ist das oft ein schneller Hebel.

Fehler 5: RBAC ohne Lifecycle und ohne saubere Delegation betreiben

Viele Teams behandeln RBAC wie eine einmalige Einrichtung. Rechte werden vergeben, ein Ticket wird geschlossen, und danach schaut lange niemand mehr hin. Ab dann häufen sich meist veraltete Berechtigungen, unklare Zuständigkeiten und zusätzliche manuelle Nacharbeit.

Role Assignments ohne erkennbare Begründung, Einträge mit Identity not found, externe Dienstleister mit Zugriff lange nach Projektende oder Delegationsrechte, die praktisch jede weitere Rechtevergabe erlauben. Dann fehlt sichtbar ein sauberer Lifecycle.

Azure unterstützt inzwischen sogar Beschreibungen in Role Assignments. Das wirkt unscheinbar, hilft im Audit aber enorm. Wenn zu einer Zuweisung nachvollziehbar dokumentiert ist, wofür sie gedacht war, wer sie braucht und welches Ticket dahintersteht, sinkt der manuelle Aufklärungsaufwand später deutlich.

Delegation ist dabei besonders sensibel. Statt pauschal Owner oder User Access Administrator zu verteilen, solltest du prüfen, ob eine eingeschränkte Delegation über Role Based Access Control Administrator mit Conditions ausreicht. So kann ein Team nur die Rollen vergeben, für die es wirklich verantwortlich ist, und nicht den halben Tenant weiterreichen.

Ein sauberes RBAC-Modell endet also nicht bei der Zuweisung. Es braucht Reviews, Offboarding für Benutzer, Service Principals und Managed Identities sowie klare Eigentümer für privilegierte Rollen und Delegationspfade.

Eine kurze Projekt-Checkliste für sauberes RBAC

Bevor du eine neue Rollenzuweisung freigibst, reichen oft fünf sehr einfache Fragen. Wer diese Fragen konsequent stellt, erkennt einen großen Teil späterer Berechtigungsprobleme schon im Design.

• Ist der Scope wirklich so klein wie möglich?
• Ist die Rolle die minimal passende Built-in Role?
• Ist der Principal die richtige Wahl, also Gruppe, Managed Identity oder nur ausnahmsweise ein Benutzer?
• Muss die Zuweisung permanent sein oder reicht eine zeitlich begrenzte Aktivierung?
• Ist klar, wer diese Zuweisung später prüft und wieder entfernt?

Als Bonusfrage lohnt sich fast immer noch eine sechste. Gibt es eine Beschreibung oder ein Ticket, mit dem sich die Entscheidung später nachvollziehen lässt? In Pull Requests für Infrastruktur oder in Architektur-Reviews deckt diese kleine Checkliste Probleme oft früher auf als jede spätere Berechtigungsbereinigung.

Weniger Sonderrechte, weniger Auditschmerz

Die meisten Azure-RBAC-Probleme sind keine Portalprobleme. Es sind Design- und Betriebsprobleme. Zu breite Scopes, direkte User-Zuweisungen, schnelle Fehlrollen, permanente Privilegien und fehlende Reviews führen mit der Zeit zu fehleranfälligem Offboarding, längeren Audits und Rückfragen dazu, wer warum welche Rechte behalten hat.

Für ein kleines Start-Audit reicht oft schon ein pragmatischer erster Schnitt. Zähle deine Subscription Owner, suche nach direkten User-Zuweisungen, prüfe privilegierte Dauerrechte und baue die drei offensichtlichsten Überprivilegierungen zuerst ab. Damit gewinnst du oft schon in weniger als 30 Minuten einen deutlich besseren Überblick.

Gutes RBAC bremst Projekte in der Regel nicht aus. Es reduziert Ausnahmen, vereinfacht Entscheidungen und verhindert, dass Betrieb und Security später denselben Wildwuchs aufräumen müssen.

Wie gehst du in deinen Projekten mit Azure-RBAC-Ausnahmen und Sonderrechten um? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.