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.
# Implementierung eines PDP mithilfe von Amazon Verified Permissions
Amazon Verified Permissions ist ein skalierbarer, detaillierter Service zur Verwaltung und Autorisierung von Berechtigungen, mit dem Sie einen Policy Decision Point (PDP) implementieren können. Als Policy-Engine kann er Ihrer Anwendung dabei helfen, Benutzeraktionen in Echtzeit zu überprüfen und übermäßig privilegierte oder ungültige Berechtigungen hervorzuheben. Es hilft Ihren Entwicklern, sicherere Anwendungen schneller zu entwickeln, indem es die Autorisierung externalisiert und die Richtlinienverwaltung und -verwaltung zentralisiert. Durch die Trennung der Autorisierungslogik von der Anwendungslogik unterstützt Verified Permissions die Entkopplung von Richtlinien.
[Durch die Verwendung verifizierter Berechtigungen zur Implementierung eines PDP und die Implementierung der geringsten Rechte und der kontinuierlichen Überprüfung innerhalb von Anwendungen können Entwickler ihren Anwendungszugriff an den Zero-Trust-Prinzipien ausrichten.](https://aws.amazon.com/security/zero-trust/) Darüber hinaus können Sicherheits- und Auditteams besser analysieren und prüfen, wer Zugriff auf welche Ressourcen innerhalb einer Anwendung hat. Verified Permissions verwendet [Cedar](https://www.cedarpolicy.com/en), eine speziell entwickelte und sicherheitsorientierte Open-Source-Richtliniensprache, um richtlinienbasierte Zugriffskontrollen auf der Grundlage von rollenbasierter Zugriffskontrolle (RBAC) und attributebasierter Zugriffskontrolle (ABAC) für eine detailliertere, kontextsensitive Zugriffskontrolle zu definieren.
Verified Permissions bietet einige nützliche Funktionen für SaaS-Anwendungen, z. B. die Möglichkeit, die Mehrmandantenautorisierung mithilfe mehrerer Identitätsanbieter wie Amazon Cognito, Google und Facebook zu aktivieren. Eine weitere Funktion für verifizierte Berechtigungen, die besonders für SaaS-Anwendungen hilfreich ist, ist die Unterstützung benutzerdefinierter Rollen pro Mandant. Wenn Sie ein CRM-System (Customer Relationship Management) entwerfen, kann ein Mandant die Granularität des Zugriffs nach Verkaufschancen auf der Grundlage eines bestimmten Kriterienkatalogs definieren. Ein anderer Mandant könnte eine andere Definition haben. Die zugrunde liegenden Berechtigungssysteme in Verified Permissions können diese Variationen unterstützen, was es zu einem ausgezeichneten Kandidaten für SaaS-Anwendungsfälle macht. Verified Permissions unterstützt auch die Möglichkeit, Richtlinien zu schreiben, die für alle Mandanten gelten, sodass es als SaaS-Anbieter einfach ist, Guardrail-Richtlinien anzuwenden, um unbefugten Zugriff zu verhindern.
![\[Verwenden von Amazon Verified Permissions zur Implementierung eines PDP\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp.png)
**Warum verifizierte Berechtigungen verwenden?**
Verwenden Sie Verified Permissions mit einem Identitätsanbieter wie [Amazon Cognito](https://aws.amazon.com/cognito/) für eine dynamischere, richtlinienbasierte Zugriffsverwaltungslösung für Ihre Anwendungen. Sie können Anwendungen entwickeln, mit denen Benutzer Informationen austauschen und zusammenarbeiten können, während gleichzeitig die Sicherheit, Vertraulichkeit und Vertraulichkeit ihrer Daten gewahrt bleiben. Verified Permissions trägt zur Senkung der Betriebskosten bei, indem es Ihnen ein detailliertes Autorisierungssystem zur Verfügung stellt, mit dem Sie den Zugriff auf der Grundlage der Rollen und Attribute Ihrer Identitäten und Ressourcen durchsetzen können. Sie können Ihr Richtlinienmodell definieren, Richtlinien an einem zentralen Ort erstellen und speichern und Zugriffsanfragen innerhalb von Millisekunden auswerten.
In Verified Permissions können Sie Berechtigungen mithilfe einer einfachen, für Menschen lesbaren Deklarationssprache namens Cedar ausdrücken. In Cedar geschriebene Richtlinien können von allen Teams gemeinsam genutzt werden, unabhängig von der Programmiersprache, die von den jeweiligen Teamanwendungen verwendet wird.
**Was ist zu beachten, wenn Sie verifizierte Berechtigungen verwenden**
In Verified Permissions können Sie Richtlinien erstellen und diese im Rahmen der Bereitstellung automatisieren. Sie können Richtlinien auch zur Laufzeit als Teil der Anwendungslogik erstellen. Als bewährte Methode sollten Sie eine CI/CD-Pipeline (Continuous Integration and Continuous Deployment) verwenden, um Richtlinienversionen zu verwalten, zu ändern und nachzuverfolgen, wenn Sie Richtlinien im Rahmen des Onboardings und der Bereitstellung von Mandanten erstellen. Alternativ kann eine Anwendung Richtlinienversionen verwalten, ändern und nachverfolgen. Die Anwendungslogik bietet diese Funktionalität jedoch nicht von Natur aus. Um diese Funktionen in Ihrer Anwendung zu unterstützen, müssen Sie Ihre Anwendung explizit so entwerfen, dass sie diese Funktionalität implementiert.
Wenn für eine Autorisierungsentscheidung externe Daten aus anderen Quellen bereitgestellt werden müssen, müssen diese Daten abgerufen und im Rahmen der Autorisierungsanfrage an Verified Permissions weitergeleitet werden. Zusätzlicher Kontext, Entitäten und Attribute werden mit diesem Service standardmäßig nicht abgerufen.
# Überblick über Cedar
Cedar ist eine flexible, erweiterbare und skalierbare richtlinienbasierte Sprache für die Zugriffskontrolle, mit der Entwickler Anwendungsberechtigungen in Form von Richtlinien ausdrücken können. Administratoren und Entwickler können Richtlinien definieren, die es Benutzern ermöglichen oder verbieten, auf Anwendungsressourcen zuzugreifen. Einer einzelnen Ressource können mehrere Richtlinien zugeordnet werden. Wenn ein Benutzer Ihrer Anwendung versucht, eine Aktion für eine Ressource auszuführen, fordert Ihre Anwendung eine Autorisierung von der Cedar Policy Engine an. Cedar bewertet die geltenden Richtlinien und gibt eine `ALLOW` `DENY` Oder-Entscheidung zurück. Cedar unterstützt Autorisierungsregeln für alle Arten von Prinzipalen und Ressourcen, ermöglicht eine rollenbasierte Zugriffskontrolle (RBAC) und eine attributebasierte Zugriffskontrolle (ABAC) und unterstützt Analysen mithilfe automatisierter Argumentationstools.
Mit Cedar können Sie Ihre Geschäftslogik von der Autorisierungslogik trennen. Wenn Sie Anfragen anhand des Codes Ihrer Anwendung stellen, rufen Sie die Autorisierungs-Engine von Cedar auf, um festzustellen, ob die Anfrage autorisiert ist. Wenn sie autorisiert ist (die Entscheidung lautet`ALLOW`), kann Ihre Anwendung den angeforderten Vorgang ausführen. Wenn sie nicht autorisiert ist (die Entscheidung ist es`DENY`), kann Ihre Anwendung eine Fehlermeldung zurückgeben. Zu den Hauptmerkmalen von Cedar gehören:
+ **Ausdruckskraft** — Cedar wurde speziell für die Unterstützung von Anwendungsfällen im Bereich Autorisierung entwickelt und unter Berücksichtigung der Lesbarkeit durch den Menschen entwickelt.
+ **Leistung** — Cedar unterstützt Indexierungsrichtlinien für einen schnellen Abruf und bietet eine schnelle und skalierbare Echtzeitauswertung mit begrenzter Latenz.
+ **Analyse** — Cedar unterstützt Analysetools, mit denen Sie Ihre Richtlinien optimieren und Ihr Sicherheitsmodell verifizieren können.
Weitere Informationen finden Sie auf der [Cedar-Website](https://www.cedarpolicy.com/).
# Beispiel 1: Einfaches ABAC mit verifizierten Berechtigungen und Cedar
In diesem Beispielszenario wird Amazon Verified Permissions verwendet, um zu bestimmen, welche Benutzer auf Informationen in einem fiktiven Payroll-Microservice zugreifen dürfen. Dieser Abschnitt enthält Codefragmente von Cedar, um zu demonstrieren, wie Sie Cedar verwenden können, um Entscheidungen zur Zugriffskontrolle zu treffen. Diese Beispiele sind nicht dazu gedacht, einen vollständigen Überblick über die Funktionen von Cedar und Verified Permissions zu geben. Einen ausführlicheren Überblick über Cedar finden Sie in der [Cedar-Dokumentation](https://docs.cedarpolicy.com/).
In der folgenden Abbildung möchten wir zwei allgemeine Geschäftsregeln durchsetzen, die mit der `viewSalary` `GET` Methode verknüpft sind: *Mitarbeiter können ihr eigenes Gehalt einsehen* und *Mitarbeiter können das Gehalt aller Personen einsehen, die ihnen unterstellt sind.* Sie können diese Geschäftsregeln mithilfe von Richtlinien für verifizierte Berechtigungen durchsetzen.
![\[Beispiel für eine grundlegende ABAC-Implementierung mit Amazon Verified Permissions und Cedar zur Implementierung eines PDP\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)
*Mitarbeiter können ihr eigenes Gehalt einsehen.*
In Cedar ist das grundlegende Konstrukt eine *Entität*, die einen Prinzipal, eine Aktion oder eine Ressource darstellt. Um eine Autorisierungsanfrage zu stellen und eine Evaluierung mit einer Richtlinie für verifizierte Berechtigungen zu starten, müssen Sie einen *Prinzipal,* eine *Aktion*, eine *Ressource* und eine *Liste von Entitäten angeben.*
+ Der Principal (`principal`) ist der angemeldete Benutzer oder die angemeldete Rolle.
+ Die Aktion (`action`) ist die Operation, die durch die Anfrage ausgewertet wird.
+ Die Ressource (`resource`) ist die Komponente, auf die die Aktion zugreift.
+ Die Liste der Entitäten (`entityList`) enthält alle erforderlichen Entitäten, die zur Auswertung der Anfrage benötigt werden.
Um die Geschäftsregel „*Mitarbeiter können ihr eigenes Gehalt einsehen*“ zu erfüllen, können Sie eine Richtlinie für verifizierte Berechtigungen wie die folgende angeben.
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner
};
```
Mit dieser Richtlinie `Action` wird geprüft, `ALLOW` ob das Objekt `viewSalary` und die Ressource in der Anfrage über ein Attribut verfügen, das dem Prinzipal entspricht. Wenn Bob beispielsweise der angemeldete Benutzer ist, der den Gehaltsbericht angefordert hat, und auch der Besitzer des Gehaltsberichts ist, wird die Richtlinie wie folgt ausgewertet. `ALLOW`
Die folgende Autorisierungsanfrage wird an Verified Permissions gesendet, um anhand der Beispielrichtlinie bewertet zu werden. In diesem Beispiel ist Bob der angemeldete Benutzer, der die `viewSalary` Anfrage stellt. Daher ist Bob der Principal des Entitätstyps`Employee`. Die Aktion, die Bob auszuführen versucht, ist `viewSalary,` und die Ressource, die angezeigt `viewSalary` wird, `Salary-Bob` entspricht dem Typ`Salary`. Um zu beurteilen, ob Bob die `Salary-Bob` Ressource anzeigen kann, müssen Sie eine Entitätsstruktur angeben, die den Typ `Employee` mit dem Wert `Bob` (Principal) mit dem Eigentümerattribut der Ressource verknüpft, die diesen Typ hat`Salary`. Sie geben diese Struktur in einer an`entityList`, wobei die zugehörigen Attribute einen Eigentümer `Salary` enthalten, der einen Eigentümer angibt, der den Typ `Employee` und den Wert enthält`Bob`. `entityIdentifier` Verified Permissions vergleicht die in der Autorisierungsanfrage `principal` angegebenen Werte mit dem `owner` Attribut, das der `Salary` Ressource zugeordnet ist, um eine Entscheidung zu treffen.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
}
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {}
}
]
}
}
```
Die Autorisierungsanfrage an Verified Permissions gibt Folgendes als Ausgabe zurück, wobei das Attribut entweder `ALLOW` oder `decision` ist`DENY`.
```
{
"determiningPolicies":
[
{
"determiningPolicyId": "PAYROLLAPP_POLICYSTOREID"
}
],
"decision": "ALLOW",
"errors": []
}
```
Da Bob in diesem Fall versucht hat, sein eigenes Gehalt einzusehen, wird die an Verified Permissions gesendete Autorisierungsanfrage als ausgewertet. `ALLOW` Unser Ziel war es jedoch, Verified Permissions zu verwenden, um zwei Geschäftsregeln durchzusetzen. Die Geschäftsregel, die Folgendes besagt, sollte ebenfalls zutreffen:
*Mitarbeiter können das Gehalt aller Mitarbeiter einsehen, die ihnen unterstellt sind.*
Um diese Geschäftsregel zu erfüllen, können Sie eine weitere Richtlinie angeben. Mit der folgenden Richtlinie wird geprüft, `ALLOW` ob die Aktion `viewSalary` und die Ressource in der Anforderung ein Attribut hat`owner.manager`, das dem Prinzipal entspricht. Wenn Alice beispielsweise die angemeldete Benutzerin ist, die den Gehaltsbericht angefordert hat, und Alice die Managerin des Berichtsbesitzers ist, wird die Richtlinie wie folgt ausgewertet. `ALLOW`
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager
};
```
Die folgende Autorisierungsanfrage wird an Verified Permissions gesendet, um anhand der Beispielrichtlinie bewertet zu werden. In diesem Beispiel ist Alice die angemeldete Benutzerin, die die `viewSalary` Anfrage stellt. Daher ist Alice die Principal und die Entität ist vom Typ`Employee`. Die Aktion, die Alice auszuführen versucht`viewSalary`, ist, und die Ressource, die angezeigt `viewSalary` wird, ist vom Typ `Salary` mit dem Wert von`Salary-Bob`. Um zu beurteilen, ob Alice die `Salary-Bob` Ressource anzeigen kann, müssen Sie eine Entitätsstruktur angeben, die den Typ `Employee` mit einem Wert von `Alice` mit dem `manager` Attribut verknüpft, das dann dem `owner` Attribut des Typs `Salary` mit dem Wert von zugeordnet werden muss`Salary-Bob`. Sie geben diese Struktur in einer an`entityList`, wobei die mit verknüpften Attributen einen Besitzer `Salary` enthalten, der einen Eigentümer angibt`entityIdentifier`, der den Typ `Employee` und den Wert enthält`Bob`. Verified Permissions überprüft zunächst das `owner` Attribut, woraufhin der Typ `Employee` und der Wert `Bob` ausgewertet werden. Anschließend bewertet Verified Permissions das zugeordnete `manager` Attribut `Employee` und vergleicht es mit dem angegebenen Prinzipal, um eine Autorisierungsentscheidung zu treffen. In diesem Fall liegt die Entscheidung `ALLOW` daran, dass die `resource.owner.manager` Attribute `principal ` und identisch sind.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "None"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
}
}
},
"parents": []
}
]
}
}
```
Bisher haben wir in diesem Beispiel die beiden mit der `viewSalary` Methode verknüpften Geschäftsregeln — *Mitarbeiter können ihr eigenes Gehalt einsehen und Mitarbeiter können das Gehalt* *aller Mitarbeiter einsehen, die ihnen unterstellt sind — als Richtlinien für verifizierte Berechtigungen bereitgestellt, mit denen die Bedingungen jeder Geschäftsregel unabhängig voneinander erfüllt werden können*. Sie können auch eine einzige Richtlinie für verifizierte Berechtigungen verwenden, um die Bedingungen beider Geschäftsregeln zu erfüllen:
*Mitarbeiter können ihr eigenes Gehalt und das Gehalt aller Mitarbeiter einsehen, die ihnen unterstellt sind.*
Wenn Sie die vorherige Autorisierungsanfrage verwenden, prüft die folgende Richtlinie, `ALLOW` ob die Aktion `viewSalary` und die Ressource in der Anforderung ein Attribut hat, `owner.manager` das gleich dem ist`principal`, oder ein Attribut, `owner` das dem `principal` entspricht.
```
permit (
principal,
action == PayrollApp::Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager ||
principal == resource.owner
};
```
Wenn Alice beispielsweise die angemeldete Benutzerin ist, die den Gehaltsbericht anfordert, und wenn Alice entweder die Managerin des Eigentümers oder die Eigentümerin des Berichts ist, dann wird die Richtlinie wie folgt ausgewertet. `ALLOW`
Weitere Informationen zur Verwendung logischer Operatoren mit Cedar-Richtlinien finden Sie in der [Cedar-Dokumentation](https://docs.cedarpolicy.com/policies/syntax-operators.html).
# Beispiel 2: Basic RBAC mit verifizierten Berechtigungen und Cedar
In diesem Beispiel werden Verified Permissions und Cedar verwendet, um grundlegende RBAC-Funktionen zu demonstrieren. Wie bereits erwähnt, ist das grundlegende Konstrukt von Cedar eine Entität. Entwickler definieren ihre eigenen Entitäten und können optional Beziehungen zwischen Entitäten erstellen. Das folgende Beispiel umfasst drei Arten von Entitäten: `Users``Roles`, und`Problems`. `Students`und `Teachers` können als Entitäten des Typs betrachtet werden, `Role,` und jede `User` kann mit Null oder einer der folgenden Entitäten verknüpft werden`Roles`.
![\[Beispiel für eine grundlegende RBAC-Implementierung mit Amazon Verified Permissions und Cedar zur Implementierung eines PDP\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)
In Cedar werden diese Beziehungen dadurch ausgedrückt, dass das Objekt mit dem `User` `Bob` als `Role` `Student` übergeordnetem Element verknüpft wird. Diese Zuordnung gruppiert logisch alle studentischen Benutzer in einer Gruppe. Weitere Informationen zur Gruppierung in Cedar finden Sie in der [Cedar-Dokumentation](https://docs.cedarpolicy.com/overview/terminology.html#term-group).
Die folgende Richtlinie gilt als Grundlage für die Entscheidung `ALLOW` für die Aktion `submitProblem,` für alle Prinzipale, die mit der logischen Gruppe `Students` des Typs verknüpft sind. `Role`
```
permit (
principal in ElearningApp::Role::"Students",
action == ElearningApp::Action::"submitProblem",
resource
);
```
Die folgende Richtlinie bewertet die Entscheidung `ALLOW` für die Aktion `submitProblem` oder für alle Prinzipale`answerProblem`, die mit der logischen Gruppe `Teachers` des Typs verknüpft sind. `Role`
```
permit (
principal in ElearningApp::Role::"Teachers",
action in [
ElearningApp::Action::"submitProblem",
ElearningApp::Action::"answerProblem"
],
resource
);
```
Um Anfragen mit diesen Richtlinien auswerten zu können, muss das Evaluierungsmodul wissen, ob der in der Autorisierungsanfrage angegebene Hauptbenutzer Mitglied der entsprechenden Gruppe ist. Daher muss die Anwendung im Rahmen der Autorisierungsanfrage die entsprechenden Informationen zur Gruppenmitgliedschaft an die Evaluierungs-Engine weitergeben. Dies erfolgt über die `entities` Eigenschaft, die es Ihnen ermöglicht, der Cedar Evaluation Engine Attribut- und Gruppenmitgliedschaftsdaten für den Prinzipal und die Ressource zur Verfügung zu stellen, die am Autorisierungsaufruf beteiligt waren. Im folgenden Code wird die Gruppenzugehörigkeit dadurch gekennzeichnet, dass ein Elternteil angerufen hat`Role::"Students"`. `User::"Bob"`
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Students"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
In diesem Beispiel ist Bob der angemeldete Benutzer, der die `answerProblem` Anfrage stellt. Daher ist Bob der Principal und die Entität ist vom Typ`User`. Die Aktion, die Bob auszuführen versucht, ist`answerProblem`. Um zu beurteilen, ob Bob die `answerProblem` Aktion ausführen kann, müssen Sie eine Entitätsstruktur angeben, die die Entität `User` mit einem Wert von verknüpft `Bob` und ihr Gruppenmitgliedschaft zuweist, indem sie eine übergeordnete Entität als `Role::"Students"` auflistet. Da Entitäten in der Benutzergruppe nur die Aktion ausführen `Role::"Students"` dürfen`submitProblem`, wird diese Autorisierungsanfrage wie folgt ausgewertet. `DENY`
Wenn andererseits der Typ`User`, der den Wert hat `Alice` und Teil der Gruppe ist, `Role::"Teachers"` versucht, die `answerProblem` Aktion auszuführen, wird die Autorisierungsanfrage als ausgewertet`ALLOW`, da die Richtlinie vorschreibt, dass Prinzipale in der Gruppe die Aktion `answerProblem` für alle Ressourcen ausführen `Role::"Teachers"` dürfen. Der folgende Code zeigt diese Art von Autorisierungsanfrage, die zu ausgewertet wird. `ALLOW`
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Teachers"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
# Beispiel 3: Zugriffskontrolle für mehrere Mandanten mit RBAC
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": []
}
]
}
}
```
# 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\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-4.png)
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](https://docs.cedarpolicy.com/auth/entities-syntax.html).
```
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](avp-design-considerations.md).
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 durch`principal.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 Rolle`allAccessRole`. `Alice`hat das Attribut`Tenant`, dessen Wert ist`Tenant::"TenantA"`. Die Aktion`Alice`, die ausgeführt werden soll, ist `updateData,` und die Ressource, auf die sie angewendet werden soll, ist `SampleData` vom Typ`Data`. `SampleData`hat `TenantA` als übergeordnete Entität.
`Alice`Kann gemäß der ersten Richtlinie im `` 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 wird`TenantA`. Die zweite Bedingung erfordert, dass das Attribut `account_lockout_flag` des Prinzipals `false` Die letzte Bedingung erfordert`uses_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"
}
]
}
]
}
}
```
# Beispiel 5: UI-Filterung mit verifizierten Berechtigungen und Cedar
Sie können Verified Permissions auch verwenden, um die RBAC-Filterung von UI-Elementen auf der Grundlage autorisierter Aktionen zu implementieren. Dies ist äußerst nützlich für Anwendungen mit kontextsensitiven Benutzeroberflächenelementen, die im Fall einer mehrinstanzenfähigen SaaS-Anwendung bestimmten Benutzern oder Mandanten zugeordnet sein könnten.
Im folgenden Beispiel dürfen `Users` von ihnen `Role` `viewer` keine Updates durchführen. Für diese Benutzer sollte die Benutzeroberfläche keine Aktualisierungsschaltflächen rendern.
![\[Beispiel für UI-Filterung mit Amazon Verified Permissions und Cedar\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-5.png)
In diesem Beispiel hat eine einseitige Webanwendung vier Schaltflächen. Welche Schaltflächen sichtbar sind, hängt `Role` von dem Benutzer ab, der gerade bei der Anwendung angemeldet ist. Beim Rendern der Benutzeroberfläche durch die einseitige Webanwendung werden verifizierte Berechtigungen abgefragt, um zu ermitteln, zu welchen Aktionen der Benutzer berechtigt ist, und generiert dann die Schaltflächen auf der Grundlage der Autorisierungsentscheidung.
Die folgende Richtlinie legt fest, dass der Typ `Role` mit dem Wert sowohl Benutzer als auch Daten anzeigen `viewer` kann. Eine `ALLOW` Autorisierungsentscheidung für diese Richtlinie erfordert eine `viewData` `viewUsers` OR-Aktion und erfordert außerdem, dass dem Typ `Data` oder eine Ressource zugeordnet wird`Users`. Eine `ALLOW` Entscheidung ermöglicht es der Benutzeroberfläche, zwei Schaltflächen zu rendern: `viewDataButton` und`viewUsersButton`.
```
permit (
principal in GuiAPP::Role::"viewer",
action in [GuiAPP::Action::"viewData", GuiAPP::Action::"viewUsers"],
resource
)
when {
resource in [GuiAPP::Type::"Data", GuiAPP::Type::"Users"]
};
```
Die folgende Richtlinie legt fest, dass der Typ `Role` mit dem Wert von nur Daten anzeigen `viewerDataOnly` kann. Eine `ALLOW` Autorisierungsentscheidung für diese Richtlinie erfordert eine `viewData` Aktion und erfordert außerdem, dass dem Typ eine Ressource zugeordnet wird`Data`. Eine `ALLOW` Entscheidung ermöglicht es der Benutzeroberfläche, die Schaltfläche zu rendern`viewDataButton`.
```
permit (
principal in GuiApp::Role::"viewerDataOnly",
action in [GuiApp::Action::"viewData"],
resource in [GuiApp::Type::"Data"]
);
```
Die folgende Richtlinie legt fest, dass der Typ `Role` mit dem Wert Daten und Benutzer bearbeiten und anzeigen `admin` kann. Eine `ALLOW` Autorisierungsentscheidung für diese Richtlinie erfordert die Aktion `updateData` `updateUsers``viewUsers`, `viewData,` oder und außerdem muss dem Typ `Data` oder eine Ressource zugeordnet werden`Users`. Eine `ALLOW` Entscheidung ermöglicht es der Benutzeroberfläche, alle vier Schaltflächen zu rendern: `updateDataButton``updateUsersButton`,`viewDataButton`, und`viewUsersButton`.
```
permit (
principal in GuiApp::Role::"admin",
action in [
GuiApp::Action::"updateData",
GuiApp::Action::"updateUsers",
GuiApp::Action::"viewData",
GuiApp::Action::"viewUsers"
],
resource
)
when {
resource in [GuiApp::Type::"Data", GuiApp::Type::"Users"]
};
```