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. # Sprachbegriffe und Konzepte der Amazon Verified Permissions- und Cedar-Richtlinien Sie sollten die folgenden Konzepte verstehen, um Amazon Verified Permissions zu verwenden. **Topics** + [Autorisierungsmodell](#term-authorization-model) + [Autorisierungsanfrage](#term-authorization-request) + [Antwort auf die Autorisierung](#term-authorization-response) + [Überlegte Richtlinien](#term-considered-policies) + [Kontextdaten](#term-context-data) + [Festlegung von Richtlinien](#term-determining-policies) + [Daten der Entität](#term-entity-data) + [Berechtigungen, Autorisierung und Prinzipale](#term-permissions-authorization-principals) + [Durchsetzung von Richtlinien](#term-policy-enforcement) + [Richtlinienspeicher](#term-policy-store) + [Alias für den Richtlinienspeicher](#term-policy-store-alias) + [Richtlinienname](#term-policy-name) + [Name der Richtlinienvorlage](#term-policy-template-name) + [Zufriedene Richtlinien](#term-satisfied-policies) + [Unterschiede zwischen Amazon Verified Permissions und der Sprache der Cedar-Richtlinie](terminology-differences-avp-cedar.md) **Sprachkonzepte von Cedar Policy** + [Autorisierung](https://docs.cedarpolicy.com/overview/terminology.html#authorization) + [Entität](https://docs.cedarpolicy.com/overview/terminology.html#entity) + [Gruppen und Hierarchien](https://docs.cedarpolicy.com/overview/terminology.html#term-group) + [Namespaces](https://docs.cedarpolicy.com/policies/validation.html#namespaces) + [Richtlinie](https://docs.cedarpolicy.com/overview/terminology.html#policy) + [Vorlage für eine Richtlinie](https://docs.cedarpolicy.com/overview/terminology.html#policy-template) + [Schema](https://docs.cedarpolicy.com/overview/terminology.html#schema) ## Autorisierungsmodell Das *Autorisierungsmodell* beschreibt den Umfang der von der Anwendung [gestellten Autorisierungsanfragen](#term-authorization-request) und die Grundlage für die Bewertung dieser Anfragen. Es wird anhand der verschiedenen Ressourcentypen, der mit diesen Ressourcen ergriffenen Maßnahmen und der Art der Hauptpersonen, die diese Aktionen ausführen, definiert. Dabei wird auch der Kontext berücksichtigt, in dem diese Maßnahmen ergriffen werden. Die *rollenbasierte Zugriffskontrolle (RBAC)* ist eine Bewertungsgrundlage, auf der Rollen definiert und mit einer Reihe von Berechtigungen verknüpft werden. Diese Rollen können dann einer oder mehreren Identitäten zugewiesen werden. Die zugewiesene Identität erwirbt die mit der Rolle verknüpften Berechtigungen. Wenn die mit der Rolle verknüpften Berechtigungen geändert werden, wirkt sich die Änderung automatisch auf alle Identitäten aus, denen die Rolle zugewiesen wurde. Cedar kann RBAC-Entscheidungen mithilfe von Hauptgruppen unterstützen. Bei der *attributebasierten Zugriffskontrolle (ABAC)* handelt es sich um eine Bewertungsgrundlage, bei der die mit einer Identität verknüpften Berechtigungen anhand der Attribute dieser Identität bestimmt werden. Cedar kann ABAC-Entscheidungen durch die Verwendung von Richtlinienbedingungen unterstützen, die auf die Attribute des Auftraggebers verweisen. Die Cedar-Richtliniensprache ermöglicht die Kombination von RBAC und ABAC in einer einzigen Richtlinie, indem Berechtigungen für eine Gruppe von Benutzern definiert werden können, für die attributbasierte Bedingungen gelten. ## Autorisierungsanfrage Eine *Autorisierungsanfrage* ist eine Anforderung verifizierter Berechtigungen durch eine Anwendung, um eine Reihe von Richtlinien auszuwerten, um festzustellen, ob ein Principal in einem bestimmten Kontext eine Aktion an einer Ressource ausführen darf. ## Antwort auf die Autorisierung Die *Autorisierungsantwort* ist die Antwort auf die [Autorisierungsanfrage](#term-authorization-request). Sie enthält eine Entscheidung über das Zulassen oder Verweigern sowie zusätzliche Informationen, z. B. die IDs zu den maßgeblichen Richtlinien. ## Überlegte Richtlinien In *Betracht gezogene Richtlinien* sind alle Richtlinien, die von Verified Permissions ausgewählt und bei der Bewertung einer [Autorisierungsanfrage berücksichtigt werden sollen](#term-authorization-request). ## Kontextdaten *Kontextdaten* sind Attributwerte, die zusätzliche Informationen zur Auswertung bereitstellen. ## Festlegung von Richtlinien *Entscheidende Richtlinien* sind die Richtlinien, die die [Reaktion auf die Autorisierung](#term-authorization-response) bestimmen. Wenn es beispielsweise zwei [erfüllte Richtlinien](#term-satisfied-policies) gibt, von denen die eine die Option „Verweigern“ und die andere eine „Zulassen“ ist, dann ist die Ablehnungsrichtlinie die ausschlaggebende Richtlinie. Wenn es mehrere erfüllte Genehmigungsrichtlinien und keine erfüllten Verbotsrichtlinien gibt, dann gibt es mehrere ausschlaggebende Richtlinien. Falls keine Richtlinien übereinstimmen und die Antwort „Verweigert“ lautet, gibt es keine ausschlaggebenden Richtlinien. ## Daten der Entität *Entitätsdaten* sind Daten über den Prinzipal, die Aktion und die Ressource. Entitätsdaten, die für die Bewertung von Richtlinien relevant sind, umfassen die Gruppenzugehörigkeit bis nach oben in der Entitätshierarchie und die Attributwerte des Prinzipals und der Ressource. ## Berechtigungen, Autorisierung und Prinzipale Verified Permissions verwaltet detaillierte *Berechtigungen* und *Autorisierungen* innerhalb von benutzerdefinierten Anwendungen, die Sie erstellen. Ein *Principal* ist ein Benutzer einer Anwendung, entweder eines Menschen oder einer Maschine, deren Identität an eine Kennung wie einen Benutzernamen oder eine Computer-ID gebunden ist. Der Authentifizierungsprozess bestimmt, ob der Principal wirklich die Identität ist, für die er sich ausgibt. Dieser Identität sind eine Reihe von *Anwendungsberechtigungen* zugeordnet, die festlegen, welche Aktionen dieser Prinzipal in dieser Anwendung ausführen darf. Bei der *Autorisierung* werden diese Berechtigungen bewertet, um festzustellen, ob ein Hauptbenutzer eine bestimmte Aktion in der Anwendung ausführen darf. Diese Berechtigungen können als [Richtlinien](https://docs.cedarpolicy.com/overview/terminology.html#policy) ausgedrückt werden. ## Durchsetzung von Richtlinien Die *Durchsetzung von Richtlinien* ist der Prozess, bei dem die Bewertungsentscheidung innerhalb der Anwendung außerhalb verifizierter Genehmigungen durchgesetzt wird. Wenn bei der Bewertung „Verified Permissions“ der Wert „Verweigert“ zurückgegeben wird, würde die Durchsetzung sicherstellen, dass der Hauptbenutzer am Zugriff auf die Ressource gehindert wird. ## Richtlinienspeicher Ein *Richtlinienspeicher* ist ein Container für Richtlinien und Vorlagen. Jeder Store enthält ein Schema, das zur Validierung der dem Store hinzugefügten Richtlinien verwendet wird. Standardmäßig hat jede Anwendung ihren eigenen Richtlinienspeicher, aber mehrere Anwendungen können sich einen einzigen Richtlinienspeicher teilen. Wenn eine Anwendung eine Autorisierungsanfrage stellt, identifiziert sie den Richtlinienspeicher, der zur Auswertung dieser Anfrage verwendet wurde. Richtlinienspeicher bieten die Möglichkeit, eine Reihe von Richtlinien zu isolieren. Sie können daher in einer Mehrmandantenanwendung verwendet werden, um die Schemas und Richtlinien für jeden Mandanten zu speichern. Eine einzelne Anwendung kann separate Richtlinienspeicher für jeden Mandanten haben. Bei der Bewertung einer [Autorisierungsanfrage](#term-authorization-request) berücksichtigt Verified Permissions nur die Teilmenge der Richtlinien im Richtlinienspeicher, die für die Anfrage relevant sind. Die Relevanz wird anhand des *Geltungsbereichs* der Richtlinie bestimmt. Der Geltungsbereich identifiziert den spezifischen Prinzipal und die Ressource, für die die Richtlinie gilt, sowie die Aktionen, die der Prinzipal mit der Ressource ausführen kann. Die Definition des Geltungsbereichs trägt zur Leistungssteigerung bei, indem die Anzahl der in Betracht gezogenen Richtlinien eingegrenzt wird. ## Alias für den Richtlinienspeicher Ein *Policy Store-Alias* ist ein benutzerfreundlicher Name für einen Policy Store. Sie können einen Richtlinienspeicher-Alias verwenden, um einen Richtlinienspeicher in jedem Vorgang mit verifizierten Berechtigungen zu identifizieren, der einen `policyStoreId` Parameter akzeptiert. Richtlinienspeicher-Aliase sind unabhängige AWS Ressourcen mit eigenen ARNs Ressourcen. Jeder Alias ist jeweils einem Richtlinienspeicher zugeordnet, und mehrere Aliase können demselben Richtlinienspeicher zugeordnet werden. Weitere Informationen finden Sie unter [Aliasnamen der Amazon-Richtlinie „Verified Permissions“ speichern](policy-store-aliases.md). ## Richtlinienname Ein *Richtlinienname* ist ein optionaler benutzerfreundlicher Name für eine Richtlinie. Richtliniennamen müssen für alle Richtlinien im Richtlinienspeicher eindeutig sein und mit `name/` dem Präfix versehen sein. Bei Operationen auf Steuerungsebene, die einen `policyId` Parameter akzeptieren, können Sie anstelle der Richtlinien-ID einen Richtliniennamen verwenden. Namen können beim Erstellen oder Aktualisieren einer Richtlinie festgelegt werden. Nur `GetPolicy` und `ListPolicies` gib den Namen in der Ausgabe zurück. ## Name der Richtlinienvorlage Ein *Richtlinienvorlagenname* ist ein optionaler benutzerfreundlicher Name für eine Richtlinienvorlage. Die Namen der Richtlinienvorlagen müssen für alle Richtlinienvorlagen im Richtlinienspeicher eindeutig sein und mit `name/` dem Präfix versehen sein. Bei Operationen auf Steuerungsebene, die einen `policyTemplateId` Parameter akzeptieren, können Sie anstelle der Richtlinienvorlagen-ID einen Namen für die Richtlinienvorlage verwenden. Namen können beim Erstellen oder Aktualisieren einer Richtlinienvorlage festgelegt werden. Nur `GetPolicyTemplate` und `ListPolicyTemplates` geben Sie den Namen in der Ausgabe zurück. ## Zufriedene Richtlinien *Erfüllte Richtlinien* sind die Richtlinien, die den Parametern der [Autorisierungsanfrage](#term-authorization-request) entsprechen. # Unterschiede zwischen Amazon Verified Permissions und der Sprache der Cedar-Richtlinie Amazon Verified Permissions verwendet die Cedar Policy Language Engine, um seine Autorisierungsaufgaben auszuführen. Es gibt jedoch einige Unterschiede zwischen der systemeigenen Cedar-Implementierung und der Implementierung von Cedar in Verified Permissions. In diesem Thema werden diese Unterschiede beschrieben. ## Namespace-Definition Die Implementierung von Verified Permissions von Cedar unterscheidet sich von der nativen Cedar-Implementierung wie folgt: + Verified Permissions unterstützt nur einen [Namespace in einem Schema](https://docs.cedarpolicy.com/schema/schema.html#namespace), das in einem Richtlinienspeicher definiert ist. + Mit Verified Permissions können Sie keinen [Namespace](https://docs.cedarpolicy.com/schema/schema.html#namespace) erstellen, der aus einer leeren Zeichenfolge besteht oder die folgenden Werte enthält: `aws``amazon`, oder. `cedar` ## Unterstützung von Richtlinienvorlagen Sowohl Verified Permissions als auch Cedar erlauben Platzhalter im Gültigkeitsbereich nur für `principal` und`resource`. Verified Permissions setzt jedoch auch voraus, dass weder die noch die `principal` Rechte `resource` uneingeschränkt sind. Die folgende Richtlinie ist in Cedar gültig, wird jedoch von Verified Permissions abgelehnt, da sie nicht eingeschränkt `principal` ist. ``` permit(principal, action == Action::"view", resource == ?resource); ``` Die beiden folgenden Beispiele sind sowohl für Cedar als auch für Verified Permissions gültig, da sowohl für als auch für Verified Permissions `principal` Einschränkungen `resource` gelten. ``` permit(principal == User::"alice", action == Action::"view", resource == ?resource); ``` ``` permit(principal == ?principal, action == Action::"a", resource in ?resource); ``` ## Schema-Unterstützung Verified Permissions erfordert, dass alle JSON-Schlüsselnamen des Schemas keine leeren Zeichenfolgen sind. Cedar erlaubt in einigen Fällen leere Zeichenfolgen, z. B. für Eigenschaften oder Namespaces. ## Definition von Aktionsgruppen Die Autorisierungsmethoden von Cedar erfordern eine Liste der Entitäten, die bei der Bewertung einer Autorisierungsanfrage anhand der Richtlinien berücksichtigt werden müssen. Sie können die Aktionen und Aktionsgruppen, die von Ihrer Anwendung verwendet werden, im Schema definieren. Cedar nimmt das Schema jedoch nicht als Teil einer Evaluierungsanfrage auf. Stattdessen verwendet Cedar das Schema nur, um die von Ihnen eingereichten Richtlinien und Richtlinienvorlagen zu validieren. Da Cedar bei Bewertungsanfragen nicht auf das Schema verweist, selbst wenn Sie Aktionsgruppen im Schema definiert haben, müssen Sie auch die Liste aller Aktionsgruppen als Teil der Entitätenliste angeben, die Sie an die Autorisierungs-API-Operationen übergeben müssen. Verified Permissions erledigt das für Sie. Alle Aktionsgruppen, die Sie in Ihrem Schema definieren, werden automatisch an die Entitätsliste angehängt, an die Sie als Parameter für die `IsAuthorized` `IsAuthorizedWithToken` OR-Operationen übergeben. ## Formatierung von Entitäten Die JSON-Formatierung von Entitäten in Verified Permissions, die den `entityList` Parameter verwenden, unterscheidet sich in folgenden Punkten von Cedar: + In Verified Permissions müssen bei einem JSON-Objekt alle Schlüssel-Wert-Paare in ein JSON-Objekt mit dem Namen eingeschlossen sein. `Record` + Eine JSON-Liste in Verified Permissions muss in ein JSON-Schlüssel-Wert-Paar eingeschlossen werden, wobei der Schlüsselname `Set` und der Wert die ursprüngliche JSON-Liste von Cedar sind. + Für `String``Long`, und `Boolean` Typnamen wird jedes Schlüssel-Wert-Paar aus Cedar in Verified Permissions durch ein JSON-Objekt ersetzt. Der Name des Objekts ist der ursprüngliche Schlüsselname. Innerhalb des JSON-Objekts gibt es ein Schlüssel-Wert-Paar, wobei der Schlüsselname der Typname des Skalarwerts (`String``Long`, oder`Boolean`) und der Wert der Wert aus der Cedar-Entität ist. + Die Syntaxformatierung von Cedar-Entitäten und Verified Permissions-Entitäten unterscheidet sich in folgenden Punkten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/verifiedpermissions/latest/userguide/terminology-differences-avp-cedar.html) **Example - Listen** Die folgenden Beispiele zeigen, wie eine Liste von Entitäten in Cedar bzw. Verified Permissions ausgedrückt wird. ``` [ { "number": 1 }, { "sentence": "Here is an example sentence" }, { "Question": false } ] ``` ``` { "Set": [ { "Record": { "number": { "Long": 1 } } }, { "Record": { "sentence": { "String": "Here is an example sentence" } } }, { "Record": { "question": { "Boolean": false } } } ] } ``` **Example - Bewertung der Politik** Die folgenden Beispiele zeigen, wie Entitäten für die Auswertung einer Richtlinie in einer Autorisierungsanfrage in Cedar bzw. Verified Permissions formatiert werden. ``` [ { "uid": { "type": "PhotoApp::User", "id": "alice" }, "attrs": { "age": 25, "name": "alice", "userId": "123456789012" }, "parents": [ { "type": "PhotoApp::UserGroup", "id": "alice_friends" }, { "type": "PhotoApp::UserGroup", "id": "AVTeam" } ] }, { "uid": { "type": "PhotoApp::Photo", "id": "vacationPhoto.jpg" }, "attrs": { "private": false, "account": { "__entity": { "type": "PhotoApp::Account", "id": "ahmad" } } }, "parents": [] }, { "uid": { "type": "PhotoApp::UserGroup", "id": "alice_friends" }, "attrs": {}, "parents": [] }, { "uid": { "type": "PhotoApp::UserGroup", "id": "AVTeam" }, "attrs": {}, "parents": [] } ] ``` ``` [ { "Identifier": { "EntityType": "PhotoApp::User", "EntityId": "alice" }, "Attributes": { "age": { "Long": 25 }, "name": { "String": "alice" }, "userId": { "String": "123456789012" } }, "Parents": [ { "EntityType": "PhotoApp::UserGroup", "EntityId": "alice_friends" }, { "EntityType": "PhotoApp::UserGroup", "EntityId": "AVTeam" } ] }, { "Identifier": { "EntityType": "PhotoApp::Photo", "EntityId": "vacationPhoto.jpg" }, "Attributes": { "private": { "Boolean": false }, "account": { "EntityIdentifier": { "EntityType": "PhotoApp::Account", "EntityId": "ahmad" } } }, "Parents": [] }, { "Identifier": { "EntityType": "PhotoApp::UserGroup", "EntityId": "alice_friends" }, "Parents": [] }, { "Identifier": { "EntityType": "PhotoApp::UserGroup", "EntityId": "AVTeam" }, "Parents": [] } ] ``` ## Längen- und Größenbeschränkungen Verified Permissions unterstützt die Speicherung in Form von Richtlinienspeichern für Ihr Schema, Ihre Richtlinien und Richtlinienvorlagen. Aufgrund dieser Speicherung legt Verified Permissions einige Längen- und Größenbeschränkungen fest, die für Cedar nicht relevant sind. | Objekt | Limit für verifizierte Berechtigungen (in Byte) | Zedernholzlimit | | --- | --- | --- | | Größe der Police¹ | 10.000 | Keine | | Beschreibung der Online-Richtlinie | 150 | Gilt nicht für Cedar | | Größe der Richtlinienvorlage | 10.000 | Keine | | Größe des Schemas | 100 000 | Keine | | Entitätstyp | 200 | Keine | | Policy ID (Richtlinien-ID) | 64 | Keine | | ID der Richtlinienvorlage | 64 | Keine | | Entity-ID | 200 | Keine | | ID des Richtlinienspeichers | 64 | Gilt nicht für Cedar | ¹ Unter Verifizierte Berechtigungen gibt es eine Obergrenze für Richtlinien pro Richtlinienspeicher, die auf der Gesamtgröße der im Richtlinienspeicher erstellten Richtlinien, Aktionen und Ressourcen basiert. Die Gesamtgröße aller Richtlinien, die sich auf eine einzelne Ressource beziehen, darf 200.000 Byte nicht überschreiten. Bei Richtlinien, die mit Vorlagen verknüpft sind, wird die Größe der Richtlinienvorlage nur einmal gezählt, zuzüglich der Größe jedes Parametersatzes, der zur Instanziierung jeder mit der Vorlage verknüpften Richtlinie verwendet wird.