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.
# Verwenden Sie die Amazon Verified Permissions Policy, um Aliase in API-Vorgängen zu speichern
Jeder Vorgang von Amazon Verified Permissions, der einen `policyStoreId` Parameter wie [ IsAuthorized ](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorized.html) [ IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html), und akzeptiert [ GetPolicyStore](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_GetPolicyStore.html), kann einen Richtlinienspeicher-Aliasnamen anstelle der Richtlinienspeicher-ID akzeptieren.
**Wichtig**
Wenn Sie einen Policy Store-Alias als Wert eines `policyStoreId` Parameters verwenden, müssen Sie das `policy-store-alias/` Präfix angeben. Verwenden Sie beispielsweise`policy-store-alias/example-policy-store`, nicht`example-policy-store`.
## Verwenden von Policy Store-Aliasen in Operations
Der folgende `IsAuthorized` Befehl verwendet einen Richtlinienspeicher-Alias mit dem Namen`example-policy-store`, um einen Richtlinienspeicher zu identifizieren.
------
#### [ AWS CLI ]
```
$ aws verifiedpermissions is-authorized \
--policy-store-id policy-store-alias/example-policy-store \
--principal entityType=User,entityId=alice \
--action actionType=Action,actionId=view \
--resource entityType=Photo,entityId=photo123
```
------
**Anmerkung**
Sie können für den [ DeletePolicyStore ](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_DeletePolicyStore.html) Vorgang keinen Richtlinienspeicher-Alias anstelle des `policyStoreId` Felds verwenden.
## Verwenden von Policy-Speicher-Aliasen (Across) AWS-Regionen
Eine der mächtigsten Verwendungen von Aliasen ist in Anwendungen, die in mehreren AWS-Regionen ausgeführt werden. Beispielsweise könnten Sie über eine globale Anwendung verfügen, die in jeder Region unterschiedliche Policy Stores verwendet.
+ In us-east-1 möchten Sie verwenden. `PSEXAMPLEabcdefg111111`
+ In eu-west-1 möchten Sie verwenden. `PSEXAMPLEabcdefg222222`
Sie könnten in jeder Region eine andere Version Ihrer Anwendung erstellen oder ein Wörterbuch oder eine SWITCH-Anweisung verwenden, um den richtigen Policy Store für jede Region auszuwählen. Es ist jedoch viel einfacher, in jeder Region einen Policy Store-Alias mit demselben Policy-Store-Aliasnamen zu erstellen. Denken Sie daran, dass beim Aliasnamen des Richtlinienspeichers zwischen Groß- und Kleinschreibung unterschieden wird.
------
#### [ AWS CLI ]
```
$ aws --region us-east-1 verifiedpermissions create-policy-store-alias \
--alias-name policy-store-alias/my-app \
--policy-store-id PSEXAMPLEabcdefg111111
$ aws --region eu-west-1 verifiedpermissions create-policy-store-alias \
--alias-name policy-store-alias/my-app \
--policy-store-id PSEXAMPLEabcdefg222222
```
------
Verwenden Sie dann den Policy Store-Alias in Ihrem Code. Wenn Ihr Code in jeder Region ausgeführt wird, verweist der Policy Store-Alias auf den zugehörigen Policy-Store in dieser Region.
------
#### [ AWS CLI ]
```
$ aws verifiedpermissions is-authorized \
--policy-store-id policy-store-alias/my-app \
--principal entityType=User,entityId=alice \
--action actionType=Action,actionId=view \
--resource entityType=Photo,entityId=photo123
```
------
Es besteht jedoch das Risiko, dass der Policy Store-Alias gelöscht wird. In diesem Fall schlagen die Versuche der Anwendung, den Aliasnamen des Richtlinienspeichers zu verwenden, fehl, und Sie müssen den Richtlinienspeicher-Alias möglicherweise neu erstellen oder aktualisieren. Um dieses Risiko zu minimieren, sollten Sie den Hauptbenutzern die Erlaubnis geben, die in Ihrer Anwendung verwendeten Richtlinienspeicher-Aliase zu verwalten.
## Richtlinienspeicher-Aliase sind kein Mechanismus zur Steuerung des Datenverkehrs
Ein Richtlinienspeicher-Alias ist ein stabiler, benutzerfreundlicher Name für einen Richtlinienspeicher. Es handelt sich nicht um einen Mechanismus zur Verlagerung, Aufteilung oder Gewichtung des Autorisierungsdatenverkehrs zwischen Policy-Speichern. Wenn Sie mit Funktionen vertraut sind, die den Datenverkehr zwischen Versionen einer Ressource weiterleiten, z. B. Lambda-Aliasnamen, beachten Sie, dass sich Policy-Speicher-Aliase nicht auf die gleiche Weise verhalten. Ein Policy Store-Alias ist von Natur aus einem AWS KMS Schlüssel-Alias näher: Er bietet einen dauerhaften Namen für eine Ressource, keine davor liegende Routing-Ebene.
Aus diesem Grund bieten wir bewusst keine `UpdatePolicyStoreAlias` Operation an. Um den Richtlinienspeicher zu ändern, auf den ein Richtlinienspeicher-Alias verweist, löschen Sie den Richtlinienspeicher-Alias und erstellen einen neuen Richtlinienspeicher-Alias, der denselben Namen hat und auf einen anderen Richtlinienspeicher abzielt. Dies ist keine atomare Operation und bietet nicht die Garantien, die ein Verkehrskontrollmechanismus bieten würde.
Wenn Sie den Richtlinienspeicher ändern, in den ein Richtlinienspeicher-Alias aufgelöst wird, wird die Änderung nicht überall gleichzeitig wirksam:
+ Die aktualisierte Zuordnung muss von der Steuerungsebene auf die Datenebene übertragen werden, die Autorisierungsanfragen auswertet. Die Zuordnung wird nicht sofort weitergegeben.
+ Da die Auflösung des Policy-Speicher-Alias letztlich konsistent ist und zwischengespeichert werden kann, erscheint nach einer Änderung ein Übergangsfenster. In diesem Fenster verarbeitet der zuvor zugeordnete Richtlinienspeicher einige Anforderungen, und der neu zugeordnete Richtlinienspeicher verarbeitet andere Anforderungen. Die Länge dieses Fensters ist unbestimmt.
In diesem Fenster kann Ihre Anwendung Autorisierungsentscheidungen aus beiden Richtlinienspeichern empfangen. Da verschiedene Richtlinienspeicher unterschiedliche Richtlinien, Entitäten und Schemas enthalten können, kann dieselbe Anforderung zu unterschiedlichen Entscheidungen führen, je nachdem, welcher Richtlinienspeicher sie bereitstellt. Richtlinienspeicher-Aliase können daher keinen atomaren Übergang zwischen den Richtlinienspeichern ermöglichen, und sie sind kein Ersatz für eine Bereitstellungs- oder Verkehrsmanagementstrategie.
**Verwenden Sie Aliase nicht als Umschaltmechanismus**
Erstellen Sie keine übergeordnete Infrastruktur als Code oder Bereitstellungsprimitiv, die auf einen Richtlinienspeicher-Alias verweist, um den Autorisierungsdatenverkehr von einem Richtlinienspeicher auf einen anderen umzuleiten. Da die Änderung nicht atomar ist, können Anfragen für beide Policy-Stores gleichzeitig für einen unbestimmten Zeitraum autorisiert werden. Dies kann zu inkonsistenten Autorisierungsentscheidungen führen. Informationen zum sicheren Wechseln zwischen Policy Stores finden Sie unter[Änderungen am Richtlinienspeicher ohne Ausfallzeiten durchführen](#alias-no-downtime-changes).
## Änderungen am Richtlinienspeicher ohne Ausfallzeiten durchführen
Da Richtlinienspeicher-Aliase keine automatische Umstellung bieten (siehe[Richtlinienspeicher-Aliase sind kein Mechanismus zur Steuerung des Datenverkehrs](#alias-not-traffic-control)), wird empfohlen, die Migration von einem Richtlinienspeicher zu einem anderen zu vermeiden, indem Sie einen Richtlinienspeicher-Alias neu verweisen. Steuern Sie die Migration stattdessen von Ihrer Anwendung aus, sodass Sie den neuen Richtlinienspeicher validieren und bei Bedarf sofort ein Rollback durchführen können. Mit dem folgenden Ansatz können Sie den Policy Store ohne Ausfallzeiten wechseln:
1. Erstellen Sie den neuen Richtlinienspeicher und geben Sie ihm einen eigenen Richtlinienspeicher-Alias, sodass der aktuelle Richtlinienspeicher und der neue Richtlinienspeicher jeweils einen eigenen, stabilen Namen haben. `policy-store-alias/example-policy-store`Verweisen Sie beispielsweise weiterhin auf Ihren aktuellen Richtlinienspeicher und erstellen Sie einen Richtlinienspeicher `policy-store-alias/example-policy-store-2` für den neuen Richtlinienspeicher. Verwenden Sie keinen einzelnen Richtlinienspeicher-Alias erneut oder verweisen Sie ihn nicht neu, um den Wechsel durchzuführen.
1. Replizieren Sie Ihre Richtlinien, Ihr Schema und jede andere Konfiguration in den neuen Richtlinienspeicher und führen Sie sie parallel zum aktuellen Richtlinienspeicher aus.
1. Fügen Sie Ihrer Anwendung einen Konfigurationswert oder ein Feature-Flag hinzu (z. B. mithilfe AppConfig), das bestimmt, welcher Richtlinienspeicher-Alias für Autorisierungsentscheidungen maßgeblich ist. Verlassen Sie sich nicht darauf, den Alias selbst zu ändern, um den Traffic umzuleiten.
1. Führen Sie den neuen Policy Store im Shadow-Modus aus. Senden Sie dieselbe `IsAuthorized` oder eine `IsAuthorizedWithToken` Anfrage an beide Policy Stores und vergleichen Sie die Entscheidungen. Erfassen Sie alle Unstimmigkeiten und untersuchen Sie sie, bis der neue Richtlinienspeicher die von Ihnen erwarteten Entscheidungen wiedergibt.
1. Verwenden Sie das Feature-Flag, um Autorisierungsentscheidungen schrittweise auf den neuen Policy-Store-Alias zu übertragen, z. B. in einem schrittweisen Rollout auf Ihren Anwendungshosts oder Benutzersegmenten. Überwachen Sie die Autorisierungsentscheidungen und die Fehlerraten, während Sie fortfahren.
1. Verwenden Sie das Feature-Flag, um sofort zum ursprünglichen Policy Store-Alias zurückzukehren, wenn Sie ein Problem feststellen. Da Ihre Anwendung den Switch steuert, erfolgt das Rollback sofort und hängt nicht von der Aliasweitergabe ab.
1. Nehmen Sie den alten Richtlinienspeicher und seinen Richtlinienspeicher-Alias außer Betrieb, nachdem der neue Richtlinienspeicher vollständig validiert wurde und der gesamte Datenverkehr abgewickelt wird.
Dieses Muster gibt Ihrer Anwendung statt der Aliasverbreitung die Kontrolle darüber, welcher Richtlinienspeicher jede Anforderung verarbeitet. Diese Kontrolle macht die Migration sicher und reversibel und vermeidet das Übergangsfenster, das durch das erneute Verweisen eines Policy-Speicher-Alias entstehen würde.