Verwalten des Ressourcenzugriffs mithilfe von Rollen
Integrierte Rollen für Azure-Ressourcen (mit PowerShell)
Azure bietet mehrere integrierte Rollen für die gängigsten Sicherheitsszenarios. Für ein besseres Verständnis der Funktionsweise von Rollen werden im Folgenden drei Rollen aufgelistet, die für alle Ressourcentypen gelten:
- Besitzer: Verfügen über vollständigen Zugriff auf alle Ressourcen, einschließlich des Rechts, den Zugriff an andere Personen zu delegieren.
- Mitwirkende: Können alle Arten von Azure-Ressourcen erstellen und verwalten, aber keinen anderen Personen Zugriff gewähren.
- Leseberechtigter: Kann vorhandene Azure-Ressourcen anzeigen.
Rollendefinitionen
Jede Rolle besteht aus mehreren Eigenschaften, die in einer JSON-Datei (JavaScript Object Notation) definiert sind. Die Rollendefinition enthält Name, ID und Beschreibung. Sie enthält zudem die zulässigen Berechtigungen (Actions), verweigerte Berechtigungen (NotActions) sowie den Bereich (z. B. Lesezugriff) der Rolle.
Für die Rolle „Besitzer“ bedeutet dies Folgendes: Alle Aktionen sind zulässig (durch ein Sternchen (*) angezeigt), keine Aktionen werden verweigert, und es gelten alle Bereiche (durch einen Schrägstrich (/) angezeigt).
Diese Informationen können mit dem PowerShell-Cmdlet Get-AzRoleDefinition Owner
abgerufen werden.
Get-AzRoleDefinition Owner
Dieser Code sollte die folgende Ausgabe liefern:
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
Geben Sie denselben Befehl für die Rollen Mitwirkender und Leser ein, und sehen Sie sich die jeweils zulässigen und verweigerten Aktionen an.
Integrierte Rollen
Eine ausführliche Untersuchung der RBAC- und Benutzerrollen in Microsoft Entra ID finden Sie unter Untersuchen von RBAC und Benutzerrollen in Microsoft Entra ID.
Was ist eine Rollendefinition?
Eine Rollendefinition ist eine Sammlung von Berechtigungen. In einer Rollendefinition sind die Vorgänge der Rolle aufgelistet, wie etwa Lesen, Schreiben und Löschen. Sie kann auch die Vorgänge auflisten, die nicht ausgeführt werden können, oder Vorgänge, die im Zusammenhang mit den zugrunde liegenden Daten stehen.
Wie zuvor beschrieben, weist eine Rollendefinition die folgende Struktur auf:
Name | BESCHREIBUNG |
---|---|
Id |
Eindeutiger Bezeichner für die Rolle, der von Azure zugewiesen wird |
IsCustom |
TRUE bei einer benutzerdefinierten Rolle, FALSE bei einer integrierten Rolle |
Description |
Lesbare Beschreibung der Rolle |
Actions [] |
Zulässige Berechtigungen; * gibt an, dass alle Aktionen zulässig sind |
NotActions [] |
Verweigerte Berechtigungen |
DataActions [] |
Bestimmte zulässige Berechtigungen, die auf Daten angewendet werden, z. B. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read . |
NotDataActions [] |
Bestimmte verweigerte Berechtigungen, die auf Daten angewendet werden. |
AssignableScopes [] |
Bereiche, in denen diese Rolle gilt; / gibt global an, kann aber in eine hierarchische Struktur hineinreichen |
Diese Struktur wird im JSON-Format dargestellt, wenn sie in der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) oder der zugrunde liegenden API verwendet wird. Das folgende Beispiel zeigt die Rollendefinition Mitwirkender im JSON-Format:
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Eigenschaften „Actions“ und „NotActions“
Sie können die Eigenschaften Actions
und NotActions
so anpassen, dass die erteilten und verweigerten Berechtigungen genau Ihren Bedürfnissen entsprechen. Diese Eigenschaften haben stets das Format {Company}.{ProviderName}/{resourceType}/{action}
.
Das folgende Beispiel zeigt die Aktionen für die drei Rollen, die weiter oben vorgestellt wurden:
Integrierte Rolle | Actions | NotActions |
---|---|---|
Besitzer (alle Aktionen zulässig) | * |
- |
Mitwirkender (alle Aktionen zulässig, mit Ausnahme von Schreiben oder Löschen von Rollenzuweisungen) | * |
Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action |
Leser (alle Leseaktionen zulässig) | */read |
- |
Der Platzhaltervorgang (*
) unter Actions
gibt an, dass der Prinzipal, der dieser Rolle zugewiesen ist, alle Aktionen ausführen kann. Anders ausgedrückt: Diese Rolle kann alles verwalten, einschließlich Aktionen, die zukünftig definiert werden, wenn neue Ressourcentypen zu Azure hinzugefügt werden. Für die Rolle Leser ist nur die Aktion read
zulässig.
Die Vorgänge unter NotActions
werden von Actions
subtrahiert. Bei der Rolle Mitwirkender entzieht NotActions
der Rolle die Verwaltung des Ressourcenzugriffs sowie den Zuweisungszugriff für Ressourcen.
Eigenschaften „DataActions“ und „NotDataActions“
Datenvorgänge werden in den Eigenschaften DataActions
und NotDataActions
angegeben. Datenvorgänge können getrennt von Verwaltungsvorgängen angegeben werden. Hierdurch wird verhindert, dass aktuelle Rollenzuweisungen mit Platzhaltern (*
) plötzlich Zugriff auf Daten erhalten. Nachstehend finden Sie einige Datenvorgänge, die in DataActions
und NotDataActions
angegeben werden können:
- Lesen einer Liste von Blobs in einem Container
- Schreiben eines Speicherblobs in einem Container
- Löschen einer Nachricht in einer Warteschlange
Sie können Datenvorgänge zur zu den Eigenschaften DataActions
und NotDataActions
hinzufügen. Durch Festlegen der Eigenschaft isDataAction
auf true
identifizieren Ressourcenanbieter, bei welchen Vorgängen es sich um Datenvorgänge handelt. Bei Rollen ohne Datenvorgänge können diese Eigenschaften in der Rollendefinition weggelassen werden.
Diese Aktionen funktionieren auf die gleiche Weise wie ihre Entsprechungen im vorherigen Abschnitt. Sie können Aktionen angeben, die Sie zulassen möchten (oder *
für alle), sowie in der Sammlung NotDataActions
eine Liste von bestimmten Aktionen, die entfernt werden sollen. Die folgende Auflistung enthält einige Beispiele für Datenvorgänge. Eine vollständige Liste der Aktionen und Datenvorgänge finden Sie in der Ressourcenanbieter-Dokumentation:
Datenvorgang | Beschreibung |
---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete |
Löscht Blobdaten. |
Microsoft.Compute/virtualMachines/login/action |
Meldet sich bei einem virtuellen Computer als regulärer Benutzer an. |
Microsoft.EventHub/namespaces/messages/send/action |
Sendet Nachrichten an einen Event Hub. |
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read |
Gibt eine Datei/einen Ordner oder eine Liste mit Dateien/Ordnern zurück. |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
Liest Nachrichten in einer Warteschlange. |
Zuweisbare Bereiche
Für die vollständige Implementierung einer Rolle reicht es nicht aus, die Eigenschaften Actions und NotActions zu definieren. Sie müssen auch den Bereich der Rolle ordnungsgemäß festlegen.
Mit der Rolleneigenschaft AssignableScopes werden die Bereiche (Abonnements, Ressourcengruppen oder Ressourcen) angegeben, in denen die Rolle für die Zuweisung verfügbar ist. Sie können die Verfügbarkeit der benutzerdefinierten Rolle für die Zuweisung auf die Abonnements oder Ressourcengruppen beschränken, für die dies erforderlich ist. Dadurch werden die restlichen Abonnements oder Ressourcengruppen für Benutzer übersichtlicher.
Im Folgenden finden Sie einige Beispiele:
Beschreibung | Bereich |
---|---|
Beschränkt auf ein Abonnement | "/subscriptions/{sub-id}" |
Beschränkt auf eine bestimmte Ressourcengruppe in einem bestimmten Abonnement | "/subscriptions/{sub-id}/resourceGroups/{rg-name}" |
Beschränkt auf eine bestimmte Ressource | "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}" |
Macht eine Rolle für die Zuweisung in zwei Abonnements verfügbar | "/subscriptions/{sub-id}", "/subscriptions/{sub-id}" |
Erstellen von Rollen
Microsoft Entra ID bietet bereits integrierte Rollen, die 99 % Ihrer Vorhaben abdecken dürften. Nach Möglichkeit sollte eine integrierte Rolle verwendet werden. Bei Bedarf können Sie jedoch benutzerdefinierte Rollen erstellen.
Hinweis
Zum Erstellen von benutzerdefinierten Rollen wird die Microsoft Entra ID P1 oder P2 benötigt. Sie können sie nicht mit der kostenlosen Version erstellen.
Eine neue Rolle kann auf verschiedene Weise erstellt werden:
Microsoft Entra Admin Center: Sie können das Microsoft Entra Admin Center verwenden, um eine benutzerdefinierte Rolle zu erstellen, indem Sie Rollen und Administratoren unter Rollen und Administratoren im linken Menü auswählen und dann Neue benutzerdefinierte Rolle auswählen.
Azure-Portal: Sie können das Azure-Portal verwenden, um eine benutzerdefinierte Rolle zu erstellen, indem Sie Microsoft Entra ID>-Rollen und Administratoren>Neue benutzerdefinierte Rolle auswählen.
Azure PowerShell: Verwenden Sie das Cmdlet
New-AzRoleDefinition
, um eine neue Rolle zu definieren.Azure Graph-API: Verwenden Sie einen REST-Aufruf an die Graph-API, um eine neue Rolle programmgesteuert zu erstellen.
In der Zusammenfassung dieses Moduls finden Sie einen Link zur Dokumentation für diese Methoden.