Grundlagen der Autorisierung

Die Autorisierung (manchmal als AuthZ abgekürzt) wird verwendet, um Berechtigungen festzulegen, die die Bewertung des Zugriffs auf Ressourcen oder Funktionen ermöglichen. Im Gegensatz dazu wird die Authentifizierung (manchmal als AuthN abgekürzt) verwendet, um zu bestätigen, dass eine Entität, z. B. ein Benutzer oder ein Dienst, tatsächlich die vorgegebene Entität ist.

Die Autorisierung kann die Angabe der Funktionen, Ressourcen oder Daten umfassen, auf die eine Entität zugreifen darf. Die Autorisierung legt auch fest, was mit den Daten durchgeführt werden kann. Diese Autorisierungsmaßnahme wird oft als Zugriffssteuerung bezeichnet.

Authentifizierung und Autorisierung sind Konzepte, die nicht nur auf Benutzer beschränkt sind. Dienste oder Daemonanwendungen sind häufig so aufgebaut, dass Anforderungen für Ressourcen nicht im Namen eines bestimmten Benutzers, sondern im eigenen Namen gestellt werden. In diesem Artikel wird der Begriff „Entität“ verwendet, um entweder einen Benutzer oder eine Anwendung zu bezeichnen.

Autorisierungsansätze

Es gibt mehrere gängige Ansätze für die Autorisierung. Die rollenbasierte Zugriffssteuerung ist derzeit der gängigste Ansatz bei Microsoft Identity Platform.

Authentifizierung als Autorisierung

Die einfachste Form der Autorisierung besteht wahrscheinlich darin, den Zugriff abhängig davon zu gewähren oder zu verweigern, ob die Entität, die eine Anforderung stellt, authentifiziert wurde. Wenn der Anforderer nachweisen kann, dass er die vorgegebene Entität ist, kann er auf die geschützten Ressourcen oder Funktionen zugreifen.

Zugriffssteuerungslisten

Die Autorisierung über Zugriffssteuerungslisten (ACLs) umfasst die Verwaltung expliziter Listen bestimmter Entitäten, die Zugriff auf eine Ressource oder Funktion haben oder nicht. ACLs ermöglichen eine feinere Kontrolle über die Authentifizierung als Autorisierung. Deren Verwaltung wird aber mit zunehmender Anzahl der Entitäten schwierig.

Rollenbasierte Zugriffssteuerung

Die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) ist wahrscheinlich der gängigste Ansatz zum Erzwingen der Autorisierung in Anwendungen. Bei der Verwendung von RBAC werden Rollen definiert, um die Arten von Aktivitäten zu beschreiben, die eine Entität ausführen kann. Ein Anwendungsentwickler gewährt Zugriff für Rollen und nicht für einzelne Entitäten. Ein Administrator kann dann verschiedenen Entitäten Rollen zuweisen, um zu steuern, welche Entitäten auf welche Ressourcen und Funktionen zugreifen können.

In erweiterten RBAC-Implementierungen können Rollen Berechtigungssätzen zugeordnet werden, wobei eine Berechtigung eine präzise Aktion oder Aktivität beschreibt, die ausgeführt werden kann. Rollen werden dann als Kombinationen von Berechtigungen konfiguriert. Berechnen Sie die Gesamtberechtigung, die für eine Entität festgelegt wird, indem Sie die Berechtigungen für die verschiedenen Rollen, die der Entität zugewiesen sind, kombinieren. Ein gutes Beispiel für diesen Ansatz ist die RBAC-Implementierung, die den Zugriff auf Ressourcen in Azure-Abonnements steuert.

Hinweis

Die rollenbasierte Zugriffssteuerung für Anwendungen unterscheidet sich von Azure RBAC und Microsoft Entra RBAC. Benutzerdefinierte Azure-Rollen und integrierte Rollen sind beide Teil von Azure RBAC, das bei der Verwaltung von Azure-Ressourcen hilft. Microsoft Entra RBAC ermöglicht die Verwaltung von Microsoft Entra-Ressourcen.

Attributbasierte Zugriffssteuerung

Die attributbasierte Zugriffssteuerung (Attribute-Based Access Control, ABAC) ist ein präziserer Zugriffssteuerungsmechanismus. Bei diesem Ansatz werden Regeln auf die Entität, die Ressourcen, auf die zugegriffen wird, und die aktuelle Umgebung angewendet. Die Regeln bestimmen die Zugriffsebene für den Zugriff auf Ressourcen und Funktionen. Ein Beispiel dafür wäre, dass Benutzer, die Manager sind, an Werktagen von 9:00 bis 17:00 Uhr nur auf Dateien zugreifen dürfen, die mit dem Metadatentag „Manager nur während der Arbeitszeit“ gekennzeichnet sind. In diesem Fall wird der Zugriff bestimmt, indem das Attribut (Status als Manager) des Benutzers, das Attribut (Metadatentag einer Datei) der Ressource und auch ein Umgebungsattribut (aktuelle Uhrzeit) untersucht werden.

Ein Vorteil von ABAC besteht darin, dass durch Auswertung von Regeln und Bedingungen eine präzisere und dynamische Zugriffssteuerung erreicht werden kann, ohne dass eine große Anzahl spezifischer Rollen und RBAC-Zuweisungen erstellt werden muss.

Eine Methode zum Erreichen von ABAC mit Microsoft Entra ID ist die Verwendung dynamischer Gruppen. Dynamische Gruppen ermöglichen Administratoren das dynamische Zuweisen von Benutzern zu Gruppen basierend auf bestimmten Benutzerattributen mit gewünschten Werten. So kann beispielsweise eine Gruppe für Autoren erstellt werden, in der alle Benutzer mit der Aufgabenbezeichnung „Autor“ dynamisch der Gruppe „Autoren“ zugewiesen werden. Dynamische Gruppen können in Kombination mit RBAC für die Autorisierung verwendet werden. Dabei werden Rollen Gruppen zugeordnet und Benutzer dynamisch Gruppen zugewiesen.

Azure ABAC ist ein Beispiel für eine ABAC-Lösung, die derzeit verfügbar ist. Azure ABAC baut auf Azure RBAC auf und fügt Rollenzuweisungsbedingungen auf der Grundlage von Attributen im Kontext bestimmter Aktionen hinzu.

Implementieren der Autorisierung

Die Autorisierungslogik wird häufig intern in Anwendungen oder Lösungen implementiert, für die eine Zugriffssteuerung erforderlich ist. In vielen Fällen stellen Anwendungsentwicklungsplattformen Middleware oder andere API-Lösungen zur Verfügung, die die Implementierung der Autorisierung vereinfachen. Beispiele hierfür sind die Verwendung von AuthorizeAttribute in ASP.NET oder Route Guards in Angular.

Bei Autorisierungsansätzen, die auf Informationen zur authentifizierten Entität aufbauen, wertet eine Anwendung Informationen aus, die während der Authentifizierung ausgetauscht werden, Zum Beispiel durch die Verwendung der Informationen, die in einem Sicherheitstoken bereitgestellt wurden. Wenn Sie planen, Informationen aus Token für die Autorisierung zu verwenden, empfiehlt es sich, sich an diesen Leitfaden zum ordnungsgemäßen Schutz von Apps durch die Überprüfung von Ansprüchen zu halten. Für Informationen, die nicht in einem Sicherheitstoken enthalten sind, kann eine Anwendung zusätzliche Aufrufe an externe Ressourcen tätigen.

Es ist nicht unbedingt erforderlich, dass Entwickler die Autorisierungslogik vollständig in ihre Anwendungen einbetten. Stattdessen können dedizierte Autorisierungsdienste verwendet werden, um die Implementierung und Verwaltung der Autorisierung zu zentralisieren.

Nächste Schritte