View a markdown version of this page

En utilisant la politique Amazon Verified Permissions, stockez les alias dans les opérations d'API - Amazon Verified Permissions
Utilisation des alias de Policy Store dans les opérationsUtilisation des alias Across de Policy Store Régions AWSLes alias du magasin de politiques ne constituent pas un mécanisme de contrôle du traficEffectuer des modifications de la politique de stockage sans interruption

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

En utilisant la politique Amazon Verified Permissions, stockez les alias dans les opérations d'API

Toute opération Amazon Verified Permissions qui accepte un policyStoreId paramètre, tel que IsAuthorized IsAuthorizedWithToken GetPolicyStore, et qui peut accepter un nom d'alias de magasin de politiques à la place de l'ID de magasin de politiques.

Important

Lorsque vous utilisez un alias de magasin de politiques comme valeur de policyStoreId paramètre, vous devez inclure le policy-store-alias/ préfixe. Par exemple, utilisezpolicy-store-alias/example-policy-store, nonexample-policy-store.

Utilisation des alias de Policy Store dans les opérations

La IsAuthorized commande suivante utilise un alias de magasin de politiques dont le nom permet example-policy-store d'identifier un magasin de politiques.

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
Note

Vous ne pouvez pas utiliser un alias de magasin de politiques à la place du policyStoreId champ pour l'DeletePolicyStoreopération.

Utilisation des alias Across de Policy Store Régions AWS

L'une des utilisations les plus performantes des alias est au niveau des applications qui s'exécutent dans plusieurs Régions AWS. Par exemple, vous pouvez disposer d'une application globale qui utilise différents magasins de politiques dans chaque région.

  • Dans us-east-1, vous souhaitez utiliser. PSEXAMPLEabcdefg111111

  • Dans eu-west-1, vous souhaitez utiliser. PSEXAMPLEabcdefg222222

Vous pouvez créer une version différente de votre application dans chaque région ou utiliser un dictionnaire ou une instruction switch pour sélectionner le magasin de politiques adapté à chaque région. Mais il est beaucoup plus facile de créer un alias de magasin de politiques avec le même nom d'alias de magasin de politiques dans chaque région. N'oubliez pas que le nom d'alias du policy store distingue les majuscules et minuscules.

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

Utilisez ensuite l'alias Policy Store dans votre code. Lorsque votre code s'exécute dans chaque région, l'alias du magasin de politiques fait référence au magasin de politiques associé dans cette région.

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

Il existe toutefois un risque que l'alias du magasin de politiques soit supprimé. Dans ce cas, les tentatives de l'application pour utiliser le nom de l'alias de la banque de politiques échoueront et vous devrez peut-être recréer ou mettre à jour l'alias de la banque de politiques. Pour atténuer ce risque, veillez à ne pas autoriser les mandants à gérer les alias du magasin de politiques que vous utilisez dans votre application.

Les alias du magasin de politiques ne constituent pas un mécanisme de contrôle du trafic

Un alias de magasin de politiques est un nom stable et convivial pour un magasin de politiques. Il ne s'agit pas d'un mécanisme permettant de déplacer, de diviser ou de pondérer le trafic d'autorisation entre les magasins de politiques. Si vous connaissez les fonctionnalités qui acheminent le trafic entre les versions d'une ressource, telles que les alias Lambda, notez que les alias du policy store ne se comportent pas de la même manière. De par sa conception, un alias de magasin de politiques est plus proche d'un alias AWS KMS clé : il fournit un nom durable à une ressource, et non une couche de routage située devant celle-ci.

C'est la raison pour laquelle nous ne proposons pas d'UpdatePolicyStoreAliasopération. Pour modifier le magasin de règles vers lequel pointe un alias de magasin de politiques, vous supprimez l'alias de magasin de stratégies et créez un nouvel alias de magasin de stratégies portant le même nom et ciblant un magasin de stratégies différent. Il ne s'agit pas d'une opération atomique et elle ne fournit pas les garanties d'un mécanisme de contrôle du trafic.

Lorsque vous modifiez la banque de règles à laquelle renvoie un alias de banque de politiques, la modification ne prend pas effet partout au même instant :

  • Le mappage mis à jour doit se propager du plan de contrôle au plan de données qui évalue les demandes d'autorisation. Le mappage ne se propage pas instantanément.

  • Comme la résolution des alias du magasin de politiques est finalement cohérente et peut être mise en cache, une fenêtre de transition apparaît après une modification. Au cours de cette fenêtre, le magasin de politiques précédemment associé traite certaines demandes et le magasin de stratégies nouvellement associé traite d'autres demandes. La longueur de cette fenêtre est indéterminée.

Pendant cette fenêtre, votre application peut recevoir des décisions d'autorisation de l'un ou l'autre des magasins de politiques. Étant donné que différents magasins de stratégies peuvent contenir des politiques, des entités et des schémas différents, la même demande peut entraîner des décisions différentes selon le magasin de stratégies qui la dessert. Les alias des magasins de politiques ne peuvent donc pas fournir de distinction atomique entre les magasins de politiques et ils ne peuvent pas remplacer une stratégie de déploiement ou de gestion du trafic.

N'utilisez pas d'alias comme mécanisme de découpage

Ne créez pas d'infrastructure en tant que code ou de primitive de déploiement de niveau supérieur qui repointe un alias de magasin de politiques afin de transférer le trafic d'autorisation d'un magasin de politiques à un autre. Comme la modification n'est pas atomique, les demandes peuvent être autorisées pour les deux magasins de politiques en même temps pendant une période indéterminée. Cela peut entraîner des décisions d'autorisation incohérentes. Pour changer de magasin de polices en toute sécurité, consultezEffectuer des modifications de la politique de stockage sans interruption.

Effectuer des modifications de la politique de stockage sans interruption

Étant donné que les alias de magasin de politiques ne fournissent pas de coupure atomique (voirLes alias du magasin de politiques ne constituent pas un mécanisme de contrôle du trafic), nous vous recommandons d'éviter de migrer d'un magasin de stratégies à un autre en redirigeant un alias de magasin de politiques. Contrôlez plutôt la migration depuis votre application afin de pouvoir valider la nouvelle banque de politiques et revenir instantanément en arrière si nécessaire. L'approche suivante vous permet de changer de magasin de politiques sans interruption de service :

  1. Créez le nouveau magasin de politiques et attribuez-lui son propre alias de magasin de politiques, de sorte que le magasin de politiques actuel et le nouveau magasin de politiques aient chacun un nom distinct et stable. Par exemple, continuez à policy-store-alias/example-policy-store pointer vers votre magasin de politiques actuel et policy-store-alias/example-policy-store-2 créez-en un pour le nouveau. Ne réutilisez pas et ne redirigez pas un seul alias de magasin de politiques pour effectuer le changement.

  2. Répliquez vos politiques, votre schéma et toute autre configuration dans le nouveau magasin de politiques et exécutez-le en parallèle avec le magasin de politiques actuel.

  3. Ajoutez une valeur de configuration ou un indicateur de fonctionnalité à votre application (par exemple, en utilisant AppConfig) qui détermine quel alias de magasin de politiques fait autorité pour les décisions d'autorisation. Ne vous fiez pas à la modification de l'alias lui-même pour changer de trafic.

  4. Exécutez le nouveau magasin de politiques en mode fantôme. Envoyez la même IsAuthorizedWithToken demande IsAuthorized ou la même demande aux deux magasins de polices et comparez les décisions. Enregistrez et examinez toute divergence jusqu'à ce que le nouveau magasin de polices rende les décisions que vous attendez.

  5. Utilisez l'indicateur de fonctionnalité pour transférer progressivement les décisions d'autorisation vers le nouvel alias de la banque de politiques, par exemple lors d'un déploiement progressif sur les hôtes de votre application ou les segments d'utilisateurs. Surveillez les décisions d'autorisation et les taux d'erreur au fur et à mesure.

  6. Utilisez l'indicateur de fonctionnalité pour revenir immédiatement à l'alias d'origine de la banque de politiques si vous détectez un problème. Comme votre application contrôle le commutateur, la restauration est instantanée et ne dépend pas de la propagation des alias.

  7. Désactivez l'ancien magasin de politiques et son alias de magasin de politiques une fois que le nouveau magasin de politiques est entièrement validé et dessert l'ensemble du trafic.

Ce modèle permet à votre application, plutôt que la propagation d'alias, de contrôler le magasin de politiques qui répond à chaque demande. Ce contrôle est ce qui rend la migration sûre et réversible, et il permet d'éviter la fenêtre de transition qu'introduirait le repointage d'un alias de magasin de politiques.