Beispiel 4: Zugriffskontrolle für mehrere Mandanten mit RBAC und ABAC - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beispiel 4: Zugriffskontrolle für mehrere Mandanten mit RBAC und ABAC

Um das RBAC-Beispiel aus dem vorherigen Abschnitt zu erweitern, können Sie Benutzern Attribute hinzufügen, um einen hybriden RBAC-ABAC-Ansatz für die mehrinstanzenfähige Zugriffskontrolle zu erstellen. Dieses Beispiel enthält dieselben Rollen wie das vorherige Beispiel, fügt jedoch das Benutzerattribut und den Kontextparameter hinzu. account_lockout_flag uses_mfa Das Beispiel verfolgt auch einen anderen Ansatz zur Implementierung der mehrinstanzenfähigen Zugriffskontrolle mithilfe von RBAC und ABAC und verwendet einen gemeinsamen Richtlinienspeicher anstelle eines anderen Richtlinienspeichers für jeden Mandanten.

Beispiel für mehrinstanzenfähige Zugriffskontrolle mit RBAC, ABAC, Amazon Verified Permissions und Cedar

Dieses Beispiel stellt eine mehrinstanzenfähige SaaS-Lösung dar, bei der Sie Autorisierungsentscheidungen für Mandant A und Mandant B treffen müssen, ähnlich wie im vorherigen Beispiel.

Um die Benutzersperrfunktion zu implementieren, fügt das Beispiel das Attribut account_lockout_flag dem User Entitätsprinzipal in der Autorisierungsanfrage hinzu. Dieses Flag sperrt den Benutzerzugriff auf das System und gewährt dem gesperrten Benutzer DENY alle Rechte. Das account_lockout_flag Attribut ist der User Entität zugeordnet und gilt so lange, User bis das Kennzeichen in mehreren Sitzungen aktiv aufgehoben wird. In dem Beispiel wird die when Bedingung zur Auswertung account_lockout_flag verwendet.

Das Beispiel fügt auch Details zur Anfrage und Sitzung hinzu. Die Kontextinformationen geben an, dass die Sitzung mithilfe der Multi-Faktor-Authentifizierung authentifiziert wurde. Um diese Überprüfung zu implementieren, verwendet das Beispiel die when Bedingung, um das uses_mfa Flag als Teil des Kontextfeldes auszuwerten. Weitere Informationen zu bewährten Methoden für das Hinzufügen von Kontext finden Sie in der Cedar-Dokumentation.

permit ( principal in MultitenantApp::Role::"allAccessRole", action in [ MultitenantApp::Action::"viewData", MultitenantApp::Action::"updateData" ], resource ) when { principal.account_lockout_flag == false && context.uses_mfa == true && resource in principal.Tenant };

Diese Richtlinie verhindert den Zugriff auf Ressourcen, es sei denn, die Ressource befindet sich in derselben Gruppe wie das Tenant Attribut des anfordernden Prinzipals. Dieser Ansatz zur Aufrechterhaltung der Mandantenisolierung wird als One Shared Multi-Tenant Policy Store-Ansatz bezeichnet. Weitere Informationen zu Designüberlegungen für verifizierte Berechtigungen für mehrinstanzenfähige SaaS-Anwendungen finden Sie im Abschnitt Überlegungen zum Entwurf verifizierter Berechtigungen für mehrere Mandanten.

Die Richtlinie stellt außerdem sicher, dass der Principal Mitglied von allAccessRole und ist und seine Aktionen auf und beschränkt. viewData updateData Darüber hinaus überprüft diese Richtlinie, ob dies der Fall account_lockout_flag ist false und ob der Kontextwert für als uses_mfa bewertet wird. true

In ähnlicher Weise stellt die folgende Richtlinie sicher, dass sowohl der Prinzipal als auch die Ressource demselben Mandanten zugeordnet sind, wodurch ein mandantenübergreifender Zugriff verhindert wird. Diese Richtlinie stellt außerdem sicher, dass der Principal Mitglied von ist, viewDataRole und beschränkt seine Aktionen auf. viewData Darüber hinaus wird überprüft, ob der Wert account_lockout_flag ist false und ob der Kontextwert für als uses_mfa bewertet wird. true

permit ( principal in MultitenantApp::Role::"viewDataRole", action == MultitenantApp::Action::"viewData", resource ) when { principal.account_lockout_flag == false && context.uses_mfa == true && resource in principal.Tenant };

Die dritte Richtlinie ähnelt der vorherigen. Die Richtlinie erfordert, dass die Ressource Mitglied der Gruppe ist, die der Entität entspricht, die vertreten wird durchprincipal.Tenant. Dadurch wird sichergestellt, dass sowohl der Prinzipal als auch die Ressource Mandant B zugeordnet sind, wodurch ein mandantenübergreifender Zugriff verhindert wird. Diese Richtlinie stellt sicher, dass der Principal Mitglied von ist, updateDataRole und beschränkt Aktionen auf. updateData Darüber hinaus überprüft diese Richtlinie, ob der Wert account_lockout_flag ist false und ob der Kontextwert für als uses_mfa bewertet wird. true

permit ( principal in MultitenantApp::Role::"updateDataRole", action == MultitenantApp::Action::"updateData", resource ) when { principal.account_lockout_flag == false && context.uses_mfa == true && resource in principal.Tenant };

Die folgende Autorisierungsanfrage wird anhand der drei zuvor in diesem Abschnitt erörterten Richtlinien bewertet. In dieser Autorisierungsanfrage Alice stellt der Principal vom Typ User und mit dem Wert von eine updateData Anfrage mit der RolleallAccessRole. Alicehat das AttributTenant, dessen Wert istTenant::"TenantA". Die AktionAlice, die ausgeführt werden soll, ist updateData, und die Ressource, auf die sie angewendet werden soll, ist SampleData vom TypData. SampleDatahat TenantA als übergeordnete Entität.

AliceKann gemäß der ersten Richtlinie im <DATAMICROSERVICE_POLICYSTOREID> Richtlinienspeicher die updateData Aktion für die Ressource ausführen, vorausgesetzt, dass die Bedingungen in der when Klausel der Richtlinie erfüllt sind. Die erste Bedingung erfordert, dass das principal.Tenant Attribut ausgewertet wirdTenantA. Die zweite Bedingung erfordert, dass das Attribut account_lockout_flag des Prinzipals false Die letzte Bedingung erfordertuses_mfa, dass true der Kontext Da alle drei Bedingungen erfüllt sind, gibt die Anfrage eine ALLOW Entscheidung zurück.

{ "policyStoreId": "DATAMICROSERVICE_POLICYSTORE", "principal": { "entityType": "MultitenantApp::User", "entityId": "Alice" }, "action": { "actionType": "MultitenantApp::Action", "actionId": "updateData" }, "resource": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "context": { "contextMap": { "uses_mfa": { "boolean": true } } }, "entities": { "entityList": [ { "identifier": { "entityType": "MultitenantApp::User", "entityId": "Alice" }, "attributes": { { "account_lockout_flag": { "boolean": false }, "Tenant": { "entityIdentifier": { "entityType":"MultitenantApp::Tenant", "entityId":"TenantA" } } } }, "parents": [ { "entityType": "MultitenantApp::Role", "entityId": "allAccessRole" } ] }, { "identifier": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "attributes": {}, "parents": [ { "entityType": "MultitenantApp::Tenant", "entityId": "TenantA" } ] } ] } }