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 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).