Benutzer, Gruppen und Rollenzuweisungen

Azure Role-Based Access Control (RBAC) ist das Autorisierungssystem, das steuert, wer welche Aktionen für Azure-Ressourcen ausführen darf. Anstatt Berechtigungen direkt einzelnen Personen zuzuweisen, weisen Sie Rollen Sicherheitsprinzipalen (Benutzern, Gruppen, Dienstprinzipalen oder verwalteten Identitäten) in einem bestimmten Bereich zu. Diese Trennung hält Berechtigungen überschaubar, wenn Ihre Organisation wächst.

Jede RBAC-Zuweisung umfasst drei Komponenten. Ein Sicherheitsprinzipal bezeichnet, wer Zugriff erhält (Benutzer, Gruppe oder verwaltete Identität). Eine Rollendefinition legt fest, welche Aktionen zulässig sind (z. B. VMs lesen oder in den Speicher schreiben). Ein Bereich bestimmt, wo der Zugriff gilt — vom größten zum kleinsten Bereich: Verwaltungsgruppe, Abonnement, Ressourcengruppe oder einzelne Ressource. Der Zugriff wird in der Bereichshierarchie nach unten vererbt.

Azure stellt Hunderte von integrierten Rollen bereit. Die vier ressourcenübergreifend am häufigsten verwendeten Rollen sind: Owner — vollständiger Zugriff einschließlich der Möglichkeit, anderen Rollen zuzuweisen; Contributor — vollständiger Zugriff zum Erstellen und Verwalten von Ressourcen, jedoch ohne die Möglichkeit, anderen Zugriff zu gewähren; Reader — schreibgeschützter Zugriff; und User Access Administrator — kann Rollenzuweisungen verwalten, ohne selbst Ressourcen zu verwalten.

Eine Rollenzuweisung gewährt dem angegebenen Sicherheitsprinzipal im angegebenen Bereich die in der Rollendefinition festgelegten Berechtigungen. Rollenzuweisungen werden an alle untergeordneten Bereiche weitergegeben — die Zuweisung von Contributor auf Ressourcengruppenebene gewährt Contributor-Zugriff auf jede Ressource innerhalb dieser Gruppe. Eine Zuweisung auf Abonnementebene gewährt Contributor-Zugriff auf alle Ressourcengruppen in diesem Abonnement.

Das Prinzip der geringsten Berechtigung besagt, dass jede Identität nur die mindestens erforderlichen Berechtigungen für ihre Aufgaben erhalten sollte. In Azure RBAC bedeutet das: Verwenden Sie Reader anstelle von Contributor, wenn kein Schreibzugriff erforderlich ist, bevorzugen Sie den Bereich einer Ressourcengruppe gegenüber dem Abonnementbereich und verwenden Sie nach Möglichkeit spezifische Rollen auf Ressourcenebene (z. B. Storage Blob Data Contributor) anstelle der umfassenden Contributor-Rolle.

Wenn keine integrierte Rolle genau Ihren Anforderungen entspricht, können Sie eine benutzerdefinierte Rolle erstellen. Eine benutzerdefinierte Rollendefinition legt eine Gruppe von Actions (zulässige Vorgänge auf der Steuerungsebene), NotActions (aus der Gruppe der zulässigen Vorgänge ausgeschlossene Aktionen), DataActions (Datenvorgänge für Ressourcen, z. B. das Lesen von Blob-Inhalten) und AssignableScopes (Abonnements oder Verwaltungsgruppen, in denen die Rolle zugewiesen werden kann) fest.

Die Zuweisung von Rollen zu Gruppen statt zu einzelnen Benutzern ist eine bewährte Vorgehensweise. Wenn ein neuer Entwickler dem DevTeam beitritt, fügen Sie ihn der DevTeam-Sicherheitsgruppe in Entra ID hinzu — er erbt automatisch alle Rollenzuweisungen der Gruppe, ohne dass Änderungen an Azure RBAC erforderlich sind. Dieser zentrale Verwaltungspunkt verhindert verstreute Einzelzuweisungen, die beim Ausscheiden von Mitarbeitern schwer zu prüfen oder zu entziehen sind.

Ein Dienstprinzipal ist eine Identität, die von Anwendungen, Skripts und Automatisierungstools verwendet wird, um sich bei Azure zu authentifizieren und auf Ressourcen zuzugreifen. Anders als eine Benutzeridentität können Dienstprinzipale keine interaktive Anmeldung durchführen. Sie erstellen sie aus App Registrations in Entra ID und weisen ihnen anschließend RBAC-Rollen im passenden Bereich zu — beispielsweise können Sie einer CI/CD-Pipeline Contributor-Zugriff auf eine einzelne Ressourcengruppe gewähren, um Infrastruktur bereitzustellen.

Verweigerungszuweisungen blockieren bestimmte Aktionen für Sicherheitsprinzipale, selbst wenn eine Rollenzuweisung diese Aktionen ansonsten erlauben würde. Anders als Rollenzuweisungen können Verweigerungszuweisungen nicht direkt von Administratoren erstellt werden — sie werden von Azure Blueprints oder verwalteten Anwendungen angefügt, um zu verhindern, dass Benutzer geschützte Ressourcen ändern. Eine Verweigerungszuweisung hat Vorrang vor jeder passenden Rollenzuweisung.

Privileged Identity Management (PIM) ist eine Funktion von Entra ID P2, die privilegierten Just-in-Time-Zugriff ermöglicht. Anstatt eine Owner- oder Global-Administrator-Rolle dauerhaft zuzuweisen, machen Sie Benutzer für diese Rolle berechtigt. Wenn sie die Rolle benötigen, aktivieren sie die Zuweisung für einen begrenzten Zeitraum (z. B. 1–8 Stunden), wobei optional ein Genehmigungsworkflow und eine Begründung verlangt werden können. Dadurch wird die dauerhafte Angriffsfläche durch übermäßig privilegierte Konten erheblich reduziert.

Access Reviews (Entra ID P2) sind regelmäßig stattfindende automatisierte Überprüfungen, bei denen Ressourcenbesitzer oder Vorgesetzte bestätigen sollen, ob ihre Teammitglieder ihre aktuellen Rollenzuweisungen weiterhin benötigen. Die Prüfenden genehmigen oder verweigern den weiteren Zugriff direkt in der Überprüfungsoberfläche. So werden veraltete Berechtigungen erkannt, die durch Rollenwechsel, abgeschlossene Projekte oder das Ausscheiden von Mitarbeitern zurückgeblieben sind — eine wichtige Anforderung für Programme zur Einhaltung gesetzlicher Vorgaben.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900) in dieser Lektion.

In dieser Lektion haben Sie gelernt: Azure RBAC weist Sicherheitsprinzipalen in einem bestimmten Bereich Rollen zu, das Prinzip der geringsten Berechtigung bedeutet, nur die mindestens erforderlichen Berechtigungen zu gewähren, und PIM ermöglicht die Just-in-Time-Aktivierung privilegierter Rollen anstelle einer dauerhaften Zuweisung. Als Nächstes behandeln wir die Multi-Faktor-Authentifizierung und den bedingten Zugriff in Entra ID.