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.

# Politiques relatives aux autorisations vérifiées par Amazon
<a name="policies"></a>

Une *politique* est une déclaration qui permet ou interdit à un *mandant* d'effectuer une ou plusieurs *actions* sur une *ressource*. Chaque politique est évaluée indépendamment des autres politiques. Pour plus d'informations sur la manière dont les politiques Cedar sont structurées et évaluées, consultez la section [Validation des politiques Cedar par rapport au schéma](https://docs.cedarpolicy.com/policies/validation.html) dans le Guide de référence du langage de politique Cedar.

Vous pouvez éventuellement attribuer un nom de stratégie à une stratégie. Les noms des politiques doivent être uniques pour toutes les politiques du magasin de politiques et être préfixés par`name/`. Vous pouvez utiliser un nom de stratégie à la place de l'ID de stratégie dans les opérations du plan de contrôle qui acceptent un `policyId` paramètre. L'exemple suivant utilise un nom de stratégie pour récupérer une politique avec`GetPolicy`.

```
$ aws verifiedpermissions get-policy \
    --policy-id name/example-policy \
    --policy-store-id PSEXAMPLEabcdefg111111
```

**Important**  
Lorsque vous rédigez des politiques Cedar qui font référence à des principes, à des ressources et à des actions, vous pouvez définir les identifiants uniques utilisés pour chacun de ces éléments. Nous vous recommandons vivement de suivre les meilleures pratiques suivantes :  
**Utilisez des identificateurs uniques universels (UUIDs) pour tous les identifiants principaux et de ressources.**  
Par exemple, si un utilisateur `jane` quitte l'entreprise et que vous autorisez ensuite quelqu'un d'autre à utiliser le nom`jane`, ce nouvel utilisateur a automatiquement accès à tout ce qui est accordé par les politiques qui font toujours référence`User::"jane"`. Cedar ne fait pas la distinction entre le nouvel utilisateur et l'ancien. Cela s'applique à la fois aux identificateurs principaux et aux identificateurs de ressources. Utilisez toujours des identifiants dont l'unicité est garantie et qui ne sont jamais réutilisés afin de ne pas autoriser l'accès par inadvertance en raison de la présence d'un ancien identifiant dans une politique.  
Lorsque vous utilisez un UUID pour une entité, nous vous recommandons de le suivre avec le spécificateur//comment et le nom « convivial » de votre entité. Cela permet de faciliter la compréhension de vos politiques. Par exemple : principal == Rôle : « a1b2c3d4-e5f6-a1b2-c3d4- »,//administrateurs EXAMPLE11111
**N'incluez pas d'informations d'identification personnelle, confidentielles ou sensibles dans l'identifiant unique de vos mandants ou de vos ressources.** Ces identifiants sont inclus dans les entrées de journal partagées dans les AWS CloudTrail sentiers.

**Topics**
+ [Création de politiques statiques relatives aux autorisations vérifiées par Amazon](policies-create.md)
+ [Modification des politiques statiques d'Amazon Verified Permissions](policies-edit.md)
+ [Ajouter du contexte](context.md)
+ [Utilisation du banc de test Amazon Verified Permissions](test-bench.md)
+ [Exemples de politiques relatives aux autorisations vérifiées par Amazon](policies-examples.md)