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 2: Mehrmandantenfähige Zugriffskontrolle und benutzerdefiniertes RBAC mit OPA und Rego In diesem Beispiel wird anhand von OPA und Rego demonstriert, wie die Zugriffskontrolle auf einer API für eine Mehrmandantenanwendung mit benutzerdefinierten Rollen implementiert werden kann, die von Mandantenbenutzern definiert werden. Es zeigt auch, wie der Zugriff je nach Mandant eingeschränkt werden kann. Dieses Modell zeigt, wie OPA detaillierte Genehmigungsentscheidungen auf der Grundlage von Informationen treffen kann, die in einer hochrangigen Rolle bereitgestellt werden. ![Benutzerdefiniertes RBAC mit OPA und Rego](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/opa-example-2.png) Die Rollen für die Mandanten werden in externen Daten (RBAC-Daten) gespeichert, die verwendet werden, um Zugriffsentscheidungen für OPA zu treffen: ``` { "roles": { "tenant_a": { "all_access_role": ["viewData", "updateData"] }, "tenant_b": { "update_data_role": ["updateData"], "view_data_role": ["viewData"] } } } ``` Wenn diese Rollen von einem Mandantenbenutzer definiert werden, sollten sie in einer externen Datenquelle oder einem Identitätsanbieter (IdP) gespeichert werden, der als Informationsquelle bei der Zuordnung von mandantendefinierten Rollen zu Berechtigungen und zum Mandanten selbst dienen kann.  In diesem Beispiel werden zwei Richtlinien in OPA verwendet, um Autorisierungsentscheidungen zu treffen und zu untersuchen, wie diese Richtlinien die Mandantenisolierung erzwingen. Diese Richtlinien verwenden die zuvor definierten RBAC-Daten. ``` default allowViewData = false allowViewData = true { input.method == "GET" input.path = ["viewData", tenant_id] input.tenant_id == tenant_id role_permissions := data.roles[input.tenant_id][input.role][_] contains(role_permissions, "viewData") } ``` Um zu verdeutlichen, wie diese Regel funktioniert, stellen Sie sich eine OPA-Abfrage mit der folgenden Eingabe vor: ``` { "tenant_id": "tenant_a", "role": "all_access_role", "path": ["viewData", "tenant_a"], "method": "GET" } ``` *Eine Autorisierungsentscheidung für diesen API-Aufruf wird wie folgt getroffen, indem die *RBAC-Daten*, die *OPA-Richtlinien und die OPA-Abfrageeingabe* kombiniert werden:* 1. Ein Benutzer von tätigt einen `Tenant A` API-Aufruf an. `/viewData/tenant_a` 1. Der Data-Microservice empfängt den Aufruf und fragt die `allowViewData` Regel ab. Dabei wird die im Beispiel für die OPA-Abfrageeingabe gezeigte Eingabe übergeben. 1. OPA verwendet die abgefragte Regel in OPA-Richtlinien, um die bereitgestellten Eingaben auszuwerten. OPA verwendet auch die Daten aus RBAC-Daten, um die Eingabe auszuwerten. OPA macht Folgendes: 1. Überprüft, ob die für den API-Aufruf verwendete Methode `GET` 1. Überprüft, ob der angeforderte Pfad `viewData` 1. Überprüft, ob `tenant_id` der Pfad mit dem Pfad übereinstimmt, der dem Benutzer `input.tenant_id` zugeordnet ist. Dadurch wird sichergestellt, dass die Mandantenisolierung aufrechterhalten wird. Ein anderer Mandant kann, selbst mit einer identischen Rolle, nicht autorisiert werden, diesen API-Aufruf durchzuführen. 1. Ruft eine Liste mit Rollenberechtigungen aus den externen Daten der Rollen ab und weist sie der Variablen zu. `role_permissions` Diese Liste wird mithilfe der vom Mandanten definierten Rolle abgerufen, die dem Benutzer in zugeordnet ist `input.role.` 1. Überprüft`role_permissions`, ob es die Berechtigung enthält `viewData.` 1. OPA gibt die folgende Entscheidung an den Data-Microservice zurück: ``` { "allowViewData": true } ``` Dieser Prozess zeigt, wie RBAC und Tenant Awareness dazu beitragen können, eine Autorisierungsentscheidung mit OPA zu treffen. Um diesen Punkt weiter zu veranschaulichen, sollten Sie einen API-Aufruf von `/viewData/tenant_b` mit der folgenden Abfrageeingabe in Betracht ziehen: ``` { "tenant_id": "tenant_b", "role": "view_data_role", "path": ["viewData", "tenant_b"], "method": "GET" } ``` Diese Regel würde dieselbe Ausgabe wie die OPA-Abfrageeingabe zurückgeben, obwohl sie für einen anderen Mandanten gilt, der eine andere Rolle innehat. Das liegt daran, dass dieser Aufruf für die RBAC-Daten bestimmt ist `/tenant_b` und den `view_data_role` darin enthaltenen RBAC-Daten immer noch die `viewData` entsprechende Berechtigung zugewiesen ist. Um dieselbe Art von Zugriffskontrolle durchzusetzen`/updateData`, können Sie eine ähnliche OPA-Regel verwenden: ``` default allowUpdateData = false allowUpdateData = true { input.method == "POST" input.path = ["updateData", tenant_id] input.tenant_id == tenant_id role_permissions := data.roles[input.tenant_id][input.role][_] contains(role_permissions, "updateData") } ``` Diese Regel entspricht funktionell der `allowViewData` Regel, überprüft jedoch einen anderen Pfad und eine andere Eingabemethode. Die Regel gewährleistet weiterhin die Mandantenisolierung und überprüft, ob die vom Mandanten definierte Rolle dem API-Aufrufer die Berechtigung erteilt. Um zu sehen, wie dies durchgesetzt werden könnte, überprüfen Sie die folgende Abfrageeingabe für einen API-Aufruf an: `/updateData/tenant_b` ``` { "tenant_id": "tenant_b", "role": "view_data_role", "path": ["updateData", "tenant_b"], "method": "POST" } ``` Diese Abfrageeingabe gibt, wenn sie mit der `allowUpdateData` Regel ausgewertet wird, die folgende Autorisierungsentscheidung zurück: ``` { "allowUpdateData": false } ``` Dieser Anruf wird nicht autorisiert. Der API-Aufrufer ist zwar mit der richtigen verknüpft `tenant_id` und ruft die API mithilfe einer zugelassenen Methode auf, aber die `input.role` ist die vom Mandanten `view_data_role` definierte. Der `view_data_role` hat nicht die `updateData` Erlaubnis, daher ist der Aufruf von nicht autorisiert. `/updateData` Dieser Aufruf wäre für einen `tenant_b` Benutzer erfolgreich gewesen, der über das verfügt`update_data_role`.