Grundlegendes zu Azure-Rollendefinitionen

Wenn Sie die Funktionsweise eine Azure-Rolle nachvollziehen oder eine eigene benutzerdefinierte Azure-Rolle erstellen möchten, ist es hilfreich zu verstehen, wie Rollen definiert werden. Dieser Artikel geht ausführlich auf Rollendefinitionen ein und enthält einige Beispiele.

Rollendefinition

Eine Rollendefinition ist eine Sammlung von Berechtigungen. Gelegentlich wird sie auch einfach als Rolle bezeichnet. Eine Rollendefinition listet die ausführbaren Aktionen wie etwa Lesen, Schreiben und Löschen auf. Unter Umständen werden außerdem die Aktionen aufgeführt, die nicht zugelassen sind oder im Zusammenhang mit den zugrunde liegenden Daten stehen.

Nachstehend finden Sie ein Beispiel für die in einer Rollendefinition enthaltenen Eigenschaften, wenn diese mit Azure PowerShell angezeigt wird:

Name
Id
IsCustom
Description
Actions []
NotActions []
DataActions []
NotDataActions []
AssignableScopes []
Condition
ConditionVersion

Im Folgenden finden Sie ein Beispiel für die in einer Rollendefinition enthaltenen Eigenschaften, wenn diese mit der Azure-Befehlszeilenschnittstelle oder der REST-API angezeigt wird:

roleName
name
id
roleType
type
description
actions []
notActions []
dataActions []
notDataActions []
assignableScopes []
condition
conditionVersion
createdOn
updatedOn
createdBy
updatedBy

In der folgenden Tabelle wird erläutert, was die einzelnen Eigenschaften bedeuten.

Aktionsformat

Aktionen werden mit Zeichenfolgen im folgenden Format angegeben:

• {Company}.{ProviderName}/{resourceType}/{action}

Der Teil {action} einer Aktionszeichenfolge gibt den Typ der Aktionen an, die Sie für einen Ressourcentyp ausführen können. So weist {action} beispielsweise folgende Teilzeichenfolgen auf:

Beispiel für eine Rollendefinition

Im folgenden Codeausschnitt finden Sie die Definition für die Rolle Mitwirkender, so wie sie in Azure PowerShell und in der Azure CLI angezeigt wird. Die Platzhalteraktionen (*) unter Actions geben an, dass der Prinzipal, der dieser Rolle zugewiesen ist, alle Aktionen ausführen und somit alles verwalten kann. Dies schließt auch Aktionen ein, die später definiert werden, wenn Azure neue Ressourcentypen hinzufügt. Die Aktionen unter NotActions werden von den Actions abgezogen. Im Fall der Rolle Mitwirkender sorgt NotActions dafür, dass die Rolle weder den Zugriff auf Ressourcen noch die Zuweisungen für Azure Blueprints verwalten kann.

Rolle „Mitwirkender“, so wie sie in Azure PowerShell angezeigt wird:

{
  "Name": "Contributor",
  "Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "IsCustom": false,
  "Description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "Microsoft.Authorization/*/Delete",
    "Microsoft.Authorization/*/Write",
    "Microsoft.Authorization/elevateAccess/Action",
    "Microsoft.Blueprint/blueprintAssignments/write",
    "Microsoft.Blueprint/blueprintAssignments/delete",
    "Microsoft.Compute/galleries/share/action",
    "Microsoft.Purview/consents/write",
    "Microsoft.Purview/consents/delete"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ],
  "Condition": null,
  "ConditionVersion": null
}

Rolle „Mitwirkender“, so wie sie in der Azure CLI angezeigt wird:

[
  {
    "assignableScopes": [
      "/"
    ],
    "createdBy": null,
    "createdOn": "2015-02-02T21:55:09.880642+00:00",
    "description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
    "name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
    "permissions": [
      {
        "actions": [
          "*"
        ],
        "condition": null,
        "conditionVersion": null,
        "dataActions": [],
        "notActions": [
          "Microsoft.Authorization/*/Delete",
          "Microsoft.Authorization/*/Write",
          "Microsoft.Authorization/elevateAccess/Action",
          "Microsoft.Blueprint/blueprintAssignments/write",
          "Microsoft.Blueprint/blueprintAssignments/delete",
          "Microsoft.Compute/galleries/share/action",
          "Microsoft.Purview/consents/write",
          "Microsoft.Purview/consents/delete"
        ],
        "notDataActions": []
      }
    ],
    "roleName": "Contributor",
    "roleType": "BuiltInRole",
    "type": "Microsoft.Authorization/roleDefinitions",
    "updatedBy": null,
    "updatedOn": "2023-07-10T15:10:53.947865+00:00"
  }
]

Aktionen auf Steuerungs- und Datenebene

Die rollenbasierte Zugriffssteuerung für Aktionen auf Steuerungsebene wird in den Eigenschaften Actions und NotActions einer Rollendefinition angegeben. Im Folgenden finden Sie einige Beispiele für Aktionen auf Steuerungsebene in Azure:

• Verwalten des Zugriffs auf ein Speicherkonto
• Erstellen, Aktualisieren oder Löschen eines Blobcontainers
• Löschen einer Ressourcengruppe und aller dazugehörigen Ressourcen

Der Zugriff auf Steuerungsebene wird nicht von Ihrer Datenebene geerbt, wenn die Methode für die Containerauthentifizierung auf Microsoft Entra-Benutzerkonto und nicht auf Zugriffsschlüssel festgelegt ist. Diese Trennung verhindert, dass Rollen mit Platzhaltern (*) uneingeschränkten Zugriff auf Ihre Daten erhalten. Wenn einem Benutzer also beispielsweise die Rolle Leser für ein Abonnement zugewiesen ist, kann er das Speicherkonto anzeigen, aber standardmäßig nicht die zugrunde liegenden Daten.

Vorher wurde die rollenbasierte Zugriffssteuerung nicht bei Datenaktionen verwendet. Die Autorisierung bei Datenaktionen variiert je nach Ressourcenanbieter. Das gleiche Autorisierungsmodell mit rollenbasierter Zugriffssteuerung, das für Aktionen auf Steuerungsebene gilt, wurde auf die Aktionen auf Datenebene erweitert.

Zur Unterstützung von Aktionen auf Datenebene wurden der Rollendefinition neue Dateneigenschaften hinzugefügt. Aktionen auf Datenebene werden in den Eigenschaften DataActions und NotDataActions angegeben. Durch Hinzufügen dieser Dateneigenschaften wird die Trennung zwischen Steuerungs- und Datenebene beibehalten. Hierdurch wird verhindert, dass aktuelle Rollenzuweisungen mit Platzhaltern (*) plötzlich Zugriff auf Daten erhalten. Im Folgenden werden einige Aktionen auf Datenebene aufgeführt, 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

Dies ist die Rollendefinition Storage-Blobdatenleser, die Aktionen in der Actions-Eigenschaft und der DataActions-Eigenschaft umfasst. In dieser Rolle können Sie den Blobcontainer sowie die zugrunde liegenden Blobdaten lesen.

Rolle „Storage-Blobdatenleser“, so wie sie in Azure PowerShell angezeigt wird:

{
  "Name": "Storage Blob Data Reader",
  "Id": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
  "IsCustom": false,
  "Description": "Allows for read access to Azure Storage blob containers and data",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
  ],
  "NotActions": [],
  "DataActions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ],
  "Condition": null,
  "ConditionVersion": null
}

Rolle „Storage-Blobdatenleser“, so wie sie in der Azure CLI angezeigt wird:

[
  {
    "assignableScopes": [
      "/"
    ],
    "createdBy": null,
    "createdOn": "2017-12-21T00:01:24.797231+00:00",
    "description": "Allows for read access to Azure Storage blob containers and data",
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
    "name": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
    "permissions": [
      {
        "actions": [
          "Microsoft.Storage/storageAccounts/blobServices/containers/read",
          "Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
        ],
        "condition": null,
        "conditionVersion": null,
        "dataActions": [
          "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
        ],
        "notActions": [],
        "notDataActions": []
      }
    ],
    "roleName": "Storage Blob Data Reader",
    "roleType": "BuiltInRole",
    "type": "Microsoft.Authorization/roleDefinitions",
    "updatedBy": null,
    "updatedOn": "2021-11-11T20:13:55.297507+00:00"
  }
]

Den Eigenschaften DataActions und NotDataActions können nur Aktionen auf Datenebene hinzugefügt werden. Durch Festlegen der isDataAction-Eigenschaft auf true identifizieren Ressourcenanbieter, bei welchen Aktionen es sich um Datenaktionen handelt. Wie Sie eine Liste der Aktionen anzeigen, in denen isDataAction auf true festgelegt ist, erfahren Sie unter Vorgänge für Ressourcenanbieter. Bei Rollen ohne Datenaktionen sind die Eigenschaften DataActions und NotDataActions in der Rollendefinition nicht erforderlich.

Die Autorisierung für alle API-Aufrufe auf Steuerungsebene wird von Azure Resource Manager verarbeitet. Die Autorisierung für API-Aufrufe auf Datenebene wird von einem Ressourcenanbieter oder von Azure Resource Manager verarbeitet.

Beispiel für Datenaktionen

Sehen Sie sich ein spezielles Beispiel an, um die Funktionsweise von Aktionen auf Steuerungs- und Datenebene besser zu verstehen. Alice wurde die Rolle Besitzer im Abonnementbereich zugewiesen. Bob wurde die Rolle Mitwirkender an Storage-Blobdaten in einem Speicherkontobereich zugewiesen. Die folgende Abbildung veranschaulicht dieses Beispiel.

Die Rolle Besitzer für Alice und die Rolle Mitwirkender an Storage-Blobdaten für Bob verfügen über die folgenden Aktionen:

Besitzer

    Aktionen
    *

Mitwirkender an Speicherblobdaten

    Aktionen
    Microsoft.Storage/storageAccounts/blobServices/containers/delete
    Microsoft.Storage/storageAccounts/blobServices/containers/read
    Microsoft.Storage/storageAccounts/blobServices/containers/write
    Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
    DataActions
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

Da Alice über eine Platzhalteraktion (*) im Geltungsbereich eines Abonnements verfügt, werden die Berechtigungen nach unten vererbt, um ihr die Durchführung aller Aktionen auf Steuerungsebene zu ermöglichen. Alice kann Container lesen, schreiben und löschen. Alice kann jedoch keine Aktionen auf Datenebene durchführen, ohne zusätzliche Schritte zu unternehmen. Beispielsweise kann Alice standardmäßig die Blobs innerhalb eines Containers nicht lesen. Um die Blobs lesen zu können, müsste Alice die Speicherzugriffsschlüssel abrufen und damit auf die Blobs zugreifen.

Die Berechtigungen von Bob sind ausschließlich auf Actions und DataActions beschränkt, die in der Rolle Mitwirkenden an Storage-Blobdaten angegeben sind. Basierend auf der Rolle kann Bob Aktionen auf Steuerungs- und Datenebene durchführen. Beispielsweise kann Bob Container im angegebenen Speicherkonto lesen, schreiben und löschen und zudem die Blobs lesen, schreiben und löschen.

Weitere Informationen zur Sicherheit auf Steuerungs- und Datenebene für den Speicher finden Sie im Azure Storage-Sicherheitsleitfaden.

Welche Tools unterstützen die Verwendung von Azure-Rollen für Datenaktionen?

Um Datenaktionen anzuzeigen und zu verwenden, müssen Sie über die richtigen Tool- oder SDK-Versionen verfügen:

Um die Datenaktionen in der REST-API anzuzeigen und zu verwenden, müssen Sie den Parameter api-version auf die folgende oder eine höhere Version festlegen:

• 2018-07-01

Aktionen

Die Berechtigung Actions gibt die Aktionen auf Steuerungsebene an, deren Ausführung die Rolle zulässt. Es handelt sich um eine Sammlung von Zeichenfolgen, mit denen sicherungsfähige Aktionen von Azure-Ressourcenanbietern identifiziert werden. Im Folgenden finden Sie einige Beispiele für Aktionen auf Steuerungsebene, die in Actions verwendet werden können.

NotActions

Die Berechtigung NotActions gibt die Aktionen auf Steuerungsebene an, die von den zulässigen Aktionen (Actions) abgezogen oder ausgeschlossen werden, die einen Platzhalter (*) enthalten. Verwenden Sie die Berechtigung NotActions, wenn sich die Aktionen, die Sie zulassen möchten, einfacher durch das Abziehen von Actions, die einen Platzhalter (*) enthalten, definieren lässt. Zur Ermittlung des Zugriffs, der durch eine Rolle gewährt wird (effektive Berechtigungen), werden die Aktionen in NotActions von denen in Actions abgezogen.

Actions - NotActions = Effective control plane permissions

In der folgenden Tabelle werden zwei Beispiele für die effektiven Berechtigungen auf Steuerungsebene für eine Microsoft.CostManagement-Platzhalteraktion angezeigt:

Unterschiede zwischen NoActions und Ablehnungszuweisungen

NotActions und Ablehnungszuweisungen sind nicht identisch und dienen unterschiedlichen Zwecken. NotActions stellen eine bequeme Möglichkeit dar, um bestimmte Aktionen von einer Platzhalteraktion (*) auszuschließen.

Ablehnungszuweisungen blockieren Aktionen für bestimmte Benutzer, selbst wenn diesen durch eine Rollenzuweisung Zugriff erteilt wurde. Weitere Informationen finden Sie unter Verstehen von Ablehnungszuweisungen für Azure-Ressourcen.

DataActions

Die Berechtigung DataActions gibt die Aktionen auf Datenebene an, deren Ausführung für Ihre Daten innerhalb des Objekts die Rolle zulässt. Wenn ein Benutzer z.B. über Lesezugriff auf Blobdaten auf ein Speicherkonto verfügt, kann er die Blobs in diesem Speicherkonto dann lesen. Im Anschluss finden Sie einige Beispiele für Datenaktionen, die in DataActions verwendet werden können.

NotDataActions

Die Berechtigung NotDataActions gibt die Aktionen auf Datenebene an, die von den zulässigen Aktionen (DataActions) abgezogen oder ausgeschlossen werden, die einen Platzhalter (*) enthalten. Verwenden Sie die Berechtigung NotDataActions, wenn sich die Aktionen, die Sie zulassen möchten, einfacher durch das Abziehen von DataActions, die einen Platzhalter (*) enthalten, definieren lässt. Zur Ermittlung des Zugriffs, der durch eine Rolle gewährt wird (effektive Berechtigungen), werden die Aktionen in NotDataActions von denen in DataActions abgezogen. Jedem Ressourcenanbieter stehen entsprechende APIs zur Verfügung, um Datenaktionen durchzuführen.

DataActions - NotDataActions = Effective data plane permissions

In der folgenden Tabelle werden zwei Beispiele für die effektiven Berechtigungen auf der Datenebene für eine Microsoft.Storage-Platzhalteraktion gezeigt:

AssignableScopes

Die AssignableScopes-Eigenschaft gibt die Bereiche (Stamm, Verwaltungsgruppen, Abonnements oder Ressourcengruppen) an, in denen eine Rollendefinition zugewiesen werden kann. Sie können eine benutzerdefinierte Rolle nur in den für Sie erforderlichen Verwaltungsgruppen, Abonnements oder Ressourcengruppen für die Zuweisung zur Verfügung stellen. Sie müssen mindestens eine Verwaltungsgruppe, ein Abonnement oder eine Ressourcengruppe verwenden.

Wenn AssignableScopes beispielsweise auf ein Abonnement festgelegt ist, bedeutet dies, dass die benutzerdefinierte Rolle für die Zuordnung im Abonnementbereich für das angegebene Abonnement, den Ressourcengruppenbereich für jede Ressourcengruppe im Abonnement oder den Ressourcenbereich für jede Ressource im Abonnement verfügbar ist.

Bei integrierten Rollen ist AssignableScopes auf den Stammbereich ("/") festgelegt. Der Stammbereich gibt an, dass die Rolle für die Zuweisung in allen Bereichen verfügbar ist.

Beispiele für gültige zuweisbare Bereiche:

Sie können in AssignableScopes einer benutzerdefinierten Rolle nur eine einzige Verwaltungsgruppe definieren.

Obwohl es möglich ist, eine benutzerdefinierte Rolle mit einer Ressourceninstanz mithilfe AssignableScopes der Befehlszeile zu erstellen, empfiehlt es sich nicht. Jeder Mandant unterstützt maximal 5.000 benutzerdefinierte Rollen. Die Verwendung dieser Strategie könnte möglicherweise Ihre verfügbaren benutzerdefinierten Rollen ausschöpfen. Letztlich wird die Zugriffsstufe durch die benutzerdefinierte Rollenzuweisung (Bereich + Rollenberechtigungen + Sicherheitsprinzipal) und nicht durch die in der benutzerdefinierten Rolle aufgeführten AssignableScopes bestimmt. Erstellen Sie also Ihre benutzerdefinierten Rollen mit AssignableScopes der Verwaltungsgruppe, Abonnement oder Ressourcengruppe, weisen sie jedoch die benutzerdefinierten Rollen mit schmalem Bereich wie Ressourcen oder Ressourcengruppe zu.

Weitere Informationen zu AssignableScopes für benutzerdefinierte Rollen finden Sie unter Benutzerdefinierte Azure-Rollen.

Definition der Rolle „Administrator für privilegierte Rollen“

Privilegierte Administratorrollen sind Rollen, die privilegierten Administratorzugriff gewähren, z. B. die Möglichkeit, Azure-Ressourcen zu verwalten oder anderen Benutzer*innen Rollen zuzuweisen. Wenn eine integrierte oder benutzerdefinierte Rolle eine der folgenden Aktionen enthält, gilt sie als privilegiert. Weitere Informationen finden Sie unter Auflisten oder Verwalten der Zuweisungen privilegierter Administratorrollen.

Nächste Schritte

• Grundlegendes zu Rollenzuweisungen
• Integrierte Azure-Rollen
• Benutzerdefinierte Azure-Rollen
• Vorgänge für Azure-Ressourcenanbieter