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 3: Zugriffskontrolle für mehrere Mandanten mit RBAC
<a name="avp-mt-abac-examples"></a>

Um das vorherige RBAC-Beispiel näher zu erläutern, können Sie Ihre Anforderungen um SaaS-Mehrmandantenfähigkeit erweitern, was eine häufige Anforderung für SaaS-Anbieter ist. Bei Lösungen mit mehreren Mandanten wird der Ressourcenzugriff immer im Namen eines bestimmten Mandanten bereitgestellt. Das heißt, Benutzer von Mandant A können die Daten von Mandant B nicht einsehen, selbst wenn diese Daten logisch oder physisch in einem System zusammengefasst sind. Das folgende Beispiel zeigt, wie Sie die Mandantenisolierung mithilfe mehrerer [Richtlinienspeicher für verifizierte Berechtigungen](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) implementieren können und wie Sie Benutzerrollen verwenden können, um Berechtigungen innerhalb des Mandanten zu definieren. 

Die Verwendung des Entwurfsmusters „Pro Tenant Policy Store“ ist eine bewährte Methode, um die Mandantenisolierung aufrechtzuerhalten und gleichzeitig die Zugriffskontrolle mit verifizierten Berechtigungen zu implementieren. In diesem Szenario werden Benutzeranfragen von Mandant A und Mandant B anhand separater Richtlinienspeicher bzw. `DATAMICROSERVICE_POLICYSTORE_A` `DATAMICROSERVICE_POLICYSTORE_B` 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](avp-design-considerations.md).

![Beispiel für mehrinstanzenfähige Zugriffskontrolle mit RBAC, Amazon Verified Permissions und Cedar](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)


Die folgende Richtlinie befindet sich im Richtlinienspeicher. `DATAMICROSERVICE_POLICYSTORE_A` Es wird überprüft, ob der Prinzipal Teil der Typgruppe `allAccessRole` ist. `Role` In diesem Fall darf der Principal die `updateData` Aktionen `viewData` und für alle Ressourcen ausführen, die Mandant A zugeordnet sind.

```
permit (
    principal in MultitenantApp::Role::"allAccessRole",
    action in [
        MultitenantApp::Action::"viewData",
        MultitenantApp::Action::"updateData"
    ],
    resource
);
```

Die folgenden Richtlinien befinden sich im `DATAMICROSERVICE_POLICYSTORE_B` Richtlinienspeicher. Die erste Richtlinie überprüft, ob der Prinzipal Teil der `updateDataRole` Typgruppe ist. `Role` Unter der Annahme, dass dies der Fall ist, erteilt sie den Prinzipalen die Erlaubnis, die `updateData` Aktion für Ressourcen auszuführen, die Mandant B zugeordnet sind.

```
permit (
    principal in MultitenantApp::Role::"updateDataRole",
    action == MultitenantApp::Action::"updateData",
    resource
);
```

Diese zweite Richtlinie schreibt vor, dass Prinzipale, die Teil der `viewDataRole` Typgruppe sind, die `viewData` Aktion für Ressourcen ausführen `Role` dürfen, die Mandant B zugeordnet sind.

```
permit (
    principal in MultitenantApp::Role::"viewDataRole",
    action == MultitenantApp::Action::"viewData",
    resource
);
```

Die Autorisierungsanfrage von Mandant A muss an den `DATAMICROSERVICE_POLICYSTORE_A` Richtlinienspeicher gesendet und anhand der Richtlinien überprüft werden, die zu diesem Speicher gehören. In diesem Fall wird sie anhand der ersten Richtlinie verifiziert, die zuvor im Rahmen dieses Beispiels erörtert wurde. In dieser Autorisierungsanfrage fordert der Prinzipal des Typs `User` mit dem `Alice` Wert von die Ausführung der `viewData` Aktion an. Der Principal gehört zur Typgruppe `allAccessRole``Role`. Alice versucht, die `viewData` Aktion auf der `SampleData` Ressource auszuführen. Da Alice die `allAccessRole` Rolle innehat, führt diese Bewertung zu einer `ALLOW` Entscheidung.

```
{
  "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
  "principal": {
      "entityType": "MultitenantApp::User",
      "entityId": "Alice"
  },
  "action": {
      "actionType": "MultitenantApp::Action",
      "actionId": "viewData"
  },
  "resource": {
      "entityType": "MultitenantApp::Data",
      "entityId": "SampleData"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
            "entityType": "MultitenantApp::User",
            "entityId": "Alice"
        },
        "attributes": {},
        "parents": [
            {
                "entityType": "MultitenantApp::Role",
                "entityId": "allAccessRole"
            }
        ]
      },
      {
        "identifier": {
            "entityType": "MultitenantApp::Data",
            "entityId": "SampleData"
        },
        "attributes": {},
        "parents": []
      }
    ]
  }
}
```

Wenn Sie sich stattdessen eine Anfrage von Mandant B von ansehen`User Bob`, werden Sie etwa die folgende Autorisierungsanfrage sehen. Die Anfrage wird an den `DATAMICROSERVICE_POLICYSTORE_B` Richtlinienspeicher gesendet, da sie von Mandant B stammt. In dieser Anfrage `Bob` möchte der Principal die Aktion `updateData` für die Ressource `SampleData` ausführen. `Bob`Ist jedoch nicht Teil einer Gruppe, die Zugriff auf die Aktion `updateData` für diese Ressource hat. Daher führt die Anfrage zu einer `DENY` Entscheidung.

```
{
  "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_B",
  "principal": {
      "entityType": "MultitenantApp::User",
      "entityId": "Bob"
  },
  "action": {
      "actionType": "MultitenantApp::Action",
      "actionId": "updateData"
  },
  "resource": {
      "entityType": "MultitenantApp::Data",
      "entityId": "SampleData"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
            "entityType": "MultitenantApp::User",
            "entityId": "Bob"
        },
        "attributes": {},
        "parents": [
            {
                "entityType": "MultitenantApp::Role",
                "entityId": "viewDataRole"
            }
        ]
      },
      {
        "identifier": {
            "entityType": "MultitenantApp::Data",
            "entityId": "SampleData"
        },
        "attributes": {},
        "parents": []
      }
    ]
  }
}
```

In diesem dritten Beispiel wird `User Alice ` versucht, die `viewData` Aktion für die Ressource auszuführen`SampleData`. Diese Anforderung wird an den `DATAMICROSERVICE_POLICYSTORE_A` Richtlinienspeicher weitergeleitet, da der Principal zu Mandant A `Alice` gehört. Er `Alice` ist Teil der Gruppe `allAccessRole` des Typs`Role`, der es ihr ermöglicht, die `viewData` Aktion für Ressourcen auszuführen. Daher führt die Anfrage zu einer `ALLOW` Entscheidung.

```
{
  "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
  "principal": {
      "entityType": "MultitenantApp::User",
      "entityId": "Alice"
  },
  "action": {
      "actionType": "MultitenantApp::Action",
      "actionId": "viewData"
  },
  "resource": {
      "entityType": "MultitenantApp::Data",
      "entityId": "SampleData"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
            "entityType": "MultitenantApp::User",
            "entityId": "Alice"
        },
        "attributes": {},
        "parents": [
            {
                "entityType": "MultitenantApp::Role",
                "entityId": "allAccessRole"
            }
        ]
      },
      {
        "identifier": {
            "entityType": "MultitenantApp::Data",
            "entityId": "SampleData"
        },
        "attributes": {},
        "parents": []
      }
    ]
  }
}
```