Skalieren der Verwaltung von Azure-Rollenzuweisungen mithilfe von Bedingungen und benutzerdefinierten Sicherheitsattributen

  • Artikel

Für die rollenbasierte Zugriffskontrolle von Azure (Azure RBAC) gilt eine Begrenzung der Rollenzuweisungen pro Abonnement. Wenn Sie Hunderte oder sogar Tausende von Azure-Rollenzuweisungen erstellen müssen, kann dieser Grenzwert auftreten. Die Verwaltung von Hunderten oder Tausenden von Rollenzuweisungen kann schwierig sein. Je nach Szenario können Sie möglicherweise die Anzahl der Rollenzuweisungen reduzieren und die Verwaltung des Zugriffs vereinfachen.

In diesem Artikel wird eine Lösung zum Skalieren der Verwaltung von Rollenzuweisungen mithilfe von Azure-attributbasierten Zugriffssteuerungsbedingungen (Azure ABAC) und benutzerdefinierten Microsoft Entra-Sicherheitsattributen für Prinzipale beschrieben.

Beispielszenario

Stellen Sie sich ein Unternehmen namens Contoso mit Tausenden von Kunden vor, das die folgende Konfiguration einrichten möchte:

  • Verteilen von Kundendaten aus Sicherheits- und Leistungsgründen auf 128 Speicherkonten.
  • Fügen Sie jedem Speicherkonto 2.000 Container hinzu, in denen für jeden Kunden ein Container vorhanden ist.
  • Stellen Sie jeden Kunden durch einen eindeutigen Microsoft Entra-Dienstprinzipal dar.
  • Erlauben Sie jedem Kunden den Zugriff auf Objekte in ihrem Container, aber nicht auf andere Container.

Für diese Konfiguration sind möglicherweise 256.000 Storage Rollenzuweisungen für Blobdatenbesitzer in einem Abonnement erforderlich, was weit über dem Grenzwert für die Rollenzuweisungen liegt. Die Verwaltung dieser vielen Rollenzuweisungen wäre schwierig, wenn nicht unmöglich.

Diagram showing thousands for role assignments.

Beispiellösung

Eine Möglichkeit, dieses Szenario in einer wartbaren Weise zu handhaben, ist die Verwendung von Rollenzuweisungsbedingungen. Das folgende Diagramm zeigt eine Lösung zum Reduzieren der 256.000 Rollenzuweisungen auf nur eine Rollenzuweisung mithilfe einer Bedingung. Die Rollenzuweisung befindet sich in einem höheren Ressourcengruppenbereich. Eine Bedingung steuert den Zugriff auf die Container. Die Bedingung überprüft, ob der Containername mit dem benutzerdefinierten Sicherheitsattribut für den Dienstprinzipal für den Kunden übereinstimmt.

Diagram showing one role assignment and a condition.

Dies ist der Ausdruck in der Bedingung, mit der diese Lösung funktioniert:

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

Die vollständige Bedingung sieht in etwa wie folgt aus. Die Liste der Aktionen kann nur an die benötigten Aktionen angepasst werden.

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

Gründe für die Verwendung dieser Lösung

Es gibt mehrere Zugriffssteuerungsmechanismen, die Sie verwenden können, um Zugriff auf Datenebenenressourcen zu ermöglichen.

Zugriffsschlüssel sind eine gängige Methode zum Bereitstellen des Zugriffs auf Ressourcen auf Datenebene. Zugriffsschlüssel bieten Lese-, Schreib- und Löschberechtigungen für jeden Benutzer, der den Zugriffsschlüssel besitzt. Dies bedeutet, dass Angreifer Zugriff auf Ihre sensiblen Daten erhalten können, wenn sie Ihre Zugriffsschlüssel erhalten. Zugriffsschlüssel verfügen nicht über eine Identitätsbindung, haben keinen Ablauf und stellen ein Sicherheitsrisiko dar.

Wie Zugriffsschlüssel verfügen SAS-Token (Shared Access Signature) nicht über eine Identitätsbindung, sondern laufen regelmäßig ab. Das Fehlen einer Identitätsbindung stellt die gleichen Sicherheitsrisiken wie Zugriffsschlüssel dar. Sie müssen den Ablauf verwalten, um sicherzustellen, dass Clients keine Fehler erhalten. SAS-Token erfordern zusätzlichen Code, um täglich verwalten und arbeiten zu können. Dies kann für ein DevOps-Team einen erheblichen Mehraufwand bedeuten.

Azure RBAC bietet eine zentralisierte, differenzierte Zugriffssteuerung. Azure RBAC verfügt über eine Identitätsbindung, die Ihr Sicherheitsrisiko reduziert. Mithilfe von Bedingungen können Sie die Verwaltung von Rollenzuweisungen möglicherweise skalieren und die Zugriffssteuerung vereinfachen, da der Zugriff auf flexiblen und dynamischen Attributen basiert.

Im Folgenden finden Sie einige der Vorteile dieser Lösung:

  • Zentrale Zugriffssteuerung
  • Einfacher zu verwalten
  • Nicht von Zugriffsschlüsseln oder SAS-Token abhängig
  • Verwaltung des Zugriffs auf jedes Objekt nicht notwendig
  • Kann Ihren Sicherheitsstatus potenziell verbessern

Können Sie diese Lösung verwenden?

Wenn Sie ein ähnliches Szenario haben, führen Sie diese Schritte aus, um zu prüfen, ob Sie diese Lösung möglicherweise verwenden können.

Schritt 1: Ermitteln, ob die Voraussetzungen erfüllt sind

Um diese Lösung verwenden zu können, benötigen Sie:

Schritt 2: Identifizieren der Attribute, die Sie in Ihrer Bedingung verwenden können

Es gibt mehrere Attribute, die Sie in Ihrer Bedingung verwenden können, z. B. die folgenden:

  • Containername
  • Blobpfad
  • Blobindextags [Schlüssel]
  • Blobindextags [Werte in Schlüssel]

Sie können auch eigene benutzerdefinierte Sicherheitsattribute für Benutzer, Unternehmensanwendungen und verwaltete Identitäten definieren.

Weitere Informationen finden Sie unter Azure-Rollenzuweisungsbedingungsformat und -syntax und was sind benutzerdefinierte Sicherheitsattribute in Microsoft Entra ID?.

Schritt 3: Erstellen einer Bedingung in einem höheren Bereich

Erstellen Sie eine oder mehrere Rollenzuweisungen, die eine Bedingung in einem höheren Bereich verwenden, um den Zugriff zu verwalten. Weitere Informationen finden Sie unter Hinzufügen oder Bearbeiten von Bedingungen für Azure-Rollenzuweisungen mithilfe des Azure-Portals.

Nächste Schritte