AWS Identity and Access Management
Guide de l'utilisateur

Stratégies et autorisations

Vous gérez les accès dans AWS en créant des stratégies et en les attachant à des identités IAM (utilisateurs, groupes d'utilisateurs ou rôles) ou des ressources AWS. Une stratégie est un objet dans AWS qui, lorsqu'il est associé à une identité ou à une ressource, définit les autorisations de ces dernières. AWS évalue ces stratégies lorsqu'une entité mandataire (utilisateur ou rôle) envoie une demande. Les autorisations dans les stratégies déterminent si la demande est autorisée ou refusée. La plupart des stratégies sont stockées dans AWS sous forme de documents JSON. AWS prend en charge six types de stratégies : les stratégies basées sur une identité, les stratégies basées sur les ressources, les limites d'autorisations, les stratégies de contrôle de service Organisations, les ACL et les stratégies de session.

Les stratégies IAM définissent les autorisations d'une action quelle que soit la méthode que vous utilisez pour exécuter l'opération. Par exemple, si une stratégie autorise l'action GetUser, un utilisateur disposant de cette stratégie peut obtenir des informations utilisateur à partir d'AWS Management Console, de l'AWS CLI ou de l'API AWS. Lorsque vous créez un utilisateur IAM, vous pouvez choisir d'autoriser la console ou un accès par programme. Si l'accès à la console est autorisé, l'utilisateur IAM peut se connecter à la console à l'aide d'un nom d'utilisateur et d'un mot de passe. Ou si un accès par programme est autorisé, l'utilisateur peut utiliser des clés d'accès pour utiliser l'interface de ligne de commande ou l'API.

Types de stratégie

Les types de stratégie suivants sont répertoriés par ordre de fréquence et utilisables dans AWS. Pour de plus amples informations, veuillez consulter les sections ci-dessous pour chaque type de stratégie.

  • Stratégies basées sur l'identité – Attachez des stratégies gérées et en ligne à des identités IAM (utilisateurs, groupes auxquels appartiennent des utilisateurs ou rôles). Les stratégies basées sur l'identité accordent des autorisations à une identité.

  • Stratégies basées sur les ressources – Attachez des stratégies en ligne aux ressources. Les exemples les plus courants de stratégies basées sur les ressources sont les stratégies de compartiment Amazon S3 et les stratégies d'approbation de rôle IAM. Les stratégies basées sur des ressources accordent des autorisations à une entité mandataire qui est spécifiée dans la stratégie. Les mandataires peuvent être dans le même compte que la ressource ou dans d'autres comptes.

  • Limites d'autorisations – Utilisez une stratégie gérée en tant que limite d'autorisations pour une entité IAM (utilisateur ou rôle). Cette stratégie définit les autorisations maximales que les stratégies basées sur une identité peuvent accorder à une entité, mais n'accorde pas d'autorisations. Les limites d'autorisations ne définissent pas les autorisations maximales qu'une stratégie basée sur les ressources peut accorder à une entité.

  • Politiques de contrôle des services d'organisations – Utilisez une politique de contrôle des services (SCP) AWS Organizations pour définir les autorisations maximales pour les membres du compte d'une organisation ou d'une unité d'organisation (OU). Les politiques de contrôle des services limitent les autorisations que les stratégies basées sur l'identité ou sur une ressource accordent à des entités (utilisateurs ou rôles) au sein du compte, mais n'accordent pas d'autorisations.

  • Listes de contrôle d'accès (ACL) – Utilisez les listes de contrôle d'accès (ACL) pour contrôler quels mandataires dans d'autres comptes peuvent accéder à la ressource à laquelle la liste de contrôle d'accès (ACL) est attachée. Les listes de contrôle d'accès sont semblables aux stratégies basées sur les ressources, bien qu'elles soient le seul type de stratégie qui n'utilise pas la structure d'un document de stratégie JSON. Les listes de contrôle d'accès sont des stratégies d'autorisations entre comptes qui accordent des autorisations pour l'entité mandataire spécifiée. Les listes de contrôle d'accès ne peuvent pas accorder des autorisations aux entités au sein du même compte.

  • Stratégies de session – Transmettez des stratégies de session avancées lorsque vous utilisez l'API d'AWS CLI ou AWS pour assumer un rôle ou un utilisateur fédéré. Les stratégies de session limitent les autorisations que les stratégies basées sur l'identité du rôle ou de l'utilisateur accordent à la session. Les stratégies de session limitent les autorisations d'une session créée, mais n'accordent pas d'autorisations. Pour plus d'informations, consultez Stratégies de session.

Stratégies basées sur l'identité

Les stratégies basées sur l'identité sont des documents de stratégie d'autorisations JSON que vous pouvez attacher à une identité (utilisateur, groupe d'utilisateurs ou rôles). Ces stratégies contrôlent les actions qu'une entité (utilisateur ou rôle) peut effectuer, sur quelles ressources et dans quelles conditions. Les stratégies basées l'identité peuvent être classées comme suit :

  • Stratégies gérées – Stratégies autonomes basées sur une identité que vous pouvez attacher à plusieurs utilisateurs, groupes et rôles dans votre compte AWS. Vous pouvez utiliser deux types de stratégies gérées :

    • Stratégies gérées par AWS – Stratégies gérées qui sont créées et gérées par AWS. Si vous n'êtes pas encore familiarisé avec les stratégies, nous vous recommandons de commencer par utiliser des stratégies gérées par AWS.

    • Stratégies gérées par le client – Stratégies gérées que vous créez et gérez dans votre compte AWS. Les stratégies gérées par le client offrent davantage de précision sur vos stratégies que les stratégies gérées par AWS. Vous pouvez créer et éditer une stratégie IAM dans l'éditeur visuel ou en créant le document de stratégie JSON directement. Pour plus d'informations, consultez Création de stratégies IAM et Modification de stratégies IAM.

  • Stratégies en ligne – Stratégies que vous créez et gérez, et qui sont intégrées directement à un utilisateur, groupe ou rôle. Dans la plupart des cas, nous vous déconseillons d'utiliser des stratégies en ligne.

Pour savoir comment choisir entre une stratégie gérée ou en ligne, consultez Stratégies gérées et stratégies en ligne.

Stratégies basées sur une ressource

Les stratégies basées sur les ressources sont des documents de stratégie JSON que vous attachez à une ressource, telle qu'un compartiment Amazon S3. Ces stratégies accordent au mandataire spécifié l'autorisation d'effectuer des actions spécifiques sur cette ressource et définit sous quelles conditions cela s'applique. Les stratégies basées sur les ressources sont des stratégies en ligne. Il ne s'agit pas de stratégies basées sur les ressources.

Pour permettre un accès entre comptes, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que mandataire dans une stratégie basée sur les ressources. L'ajout d'un mandataire entre comptes à une stratégie basée sur les ressources ne représente qu'une partie de l'instauration de la relation d'approbation. Lorsque le mandataire et la ressource se trouvent dans des comptes AWS distincts, vous devez également utiliser une stratégie basée sur une identité pour autoriser l'entité mandataire à accéder à la ressource. Toutefois, si une stratégie basée sur des ressources accorde l'accès à un mandataire dans le même compte, aucune autre stratégie basée sur l'identité n'est requise.

Le service IAM prend en charge un seul type de stratégie basée sur les ressources, nommé stratégie d'approbation de rôle, qui est attaché à un rôle IAM. Un rôle IAM est à la fois une identité et une ressource qui prend en charge les stratégies basées sur les ressources. C'est pour cette raison que vous devez associer une stratégie d'approbation et une stratégie basée sur une identité à un rôle IAM. Les stratégies d'approbation définissent quelles entités mandataires (comptes, utilisateurs, rôles et utilisateurs fédérés) peuvent assumer le rôle. Pour en savoir plus sur la façon dont les rôles IAM sont différents d'autres stratégies basées sur les ressources, consultez Différence entre les rôles IAM et les stratégies basées sur les ressources.

Pour connaître les autres services qui prennent en charge les stratégies basées sur les ressources, voir Services AWS qui fonctionnent avec IAM. Pour en savoir plus sur stratégies basées sur les ressources, voir Stratégies basées sur l'identité et Stratégies basées sur une ressource.

Limites d'autorisations IAM

Une limite d'autorisations est une fonctionnalité avancée dans laquelle vous définissez les autorisations maximales qu'une stratégie basée sur les identités peut accorder à une entité IAM. Lorsque vous définissez une limite d'autorisations pour une entité, l'entité peut effectuer uniquement les actions autorisées par ses deux ses stratégies basées sur l'identité et ses limites d'autorisations. Les stratégies basées sur les ressources qui spécifient l'utilisateur ou le rôle en tant que mandataire ne sont pas limitées par les limites d'autorisations. Un refus explicite dans l'une de ces stratégies remplace l'autorisation. Pour de plus amples informations sur les limites d'autorisations, veuillez consulter Limites d'autorisations pour des entités IAM.

Stratégies de contrôle de service

AWS Organizations est un service permettant de regrouper et de gérer de façon centralisée les comptes AWS détenus par votre entreprise. Si vous activez toutes les fonctions d'une organisation, vous pouvez appliquer les stratégies de contrôle de service (SCP) à l'un ou à l'ensemble de vos comptes. Les stratégies de contrôle de service qui spécifient les autorisations maximales pour une organisation ou une unité d'organisation. La politique de contrôle des services limite les autorisations pour les entités dans les comptes membres, y compris dans chaque Utilisateur racine d'un compte AWS. Un refus explicite dans l'une de ces stratégies remplace l'autorisation.

Pour plus d'informations sur Organisations et sur les politiques de contrôle des services, consultez À propos des politiques de contrôle des services dans le Manuel de l'utilisateur AWS Organizations.

Listes de contrôle d'accès (ACL)

Les listes de contrôle d'accès (ACL) sont des stratégies de service qui vous permettent de contrôler quels mandataires d'un autre compte peuvent accéder à une ressource. Les ACL ne peuvent pas être utilisées pour contrôler l'accès pour un mandataire au sein du même compte. Les listes de contrôle d'accès sont semblables aux stratégies basées sur les ressources, bien qu'elles soient le seul type de stratégie qui n'utilise pas le format de document de stratégie JSON. Amazon S3, AWS WAF et Amazon VPC sont des exemples de services prenant en charge les listes de contrôle d'accès. Pour en savoir plus sur les listes de contrôle d'accès, consultez Présentation de la liste de contrôle d'accès (ACL) dans le Manuel du développeur Amazon Simple Storage Service.

Stratégies de session

Les stratégies de session sont des stratégies avancées que vous transmettez dans un paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Les autorisations d'une session sont une combinaison des stratégies basées sur l'identité de l'entité IAM (utilisateur ou rôle) utilisée pour créer la session et les stratégies de session. Les autorisations peuvent également provenir d'une stratégie basée sur les ressources. Un refus explicite dans l'une de ces stratégies remplace l'autorisation.

Vous pouvez créer une session de rôle et transmettre des stratégies de session par programmation à l'aide des opérations d'API AssumeRole, AssumeRoleWithSAML ou AssumeRoleWithWebIdentity. Vous pouvez transmettre un seul document de stratégie de session en ligne JSON à l'aide du paramètre Policy. Vous pouvez utiliser le paramètre PolicyArns pour spécifier jusqu'à 10 stratégies de session gérées. Pour plus d'informations sur la création d'une session de rôle, consultez Obtention d'informations d'identification temporaires de sécurité.

Lorsque vous créez une session d'utilisateur fédéré, vous utilisez des clés d'accès d'utilisateur IAM pour appeler par programmation l'opération d'API GetFederationToken. Vous devez également transmettre des stratégies de session. Les autorisations de session obtenues sont une combinaison de la stratégie basée sur l'identité de l'utilisateur IAM et de la stratégie de session. Pour plus d'informations sur la création d'une session d'utilisateur fédéré, consultez GetFederationToken : Fédération via un broker d'identité personnalisé.

Une stratégie basée sur les ressources peut spécifier l'ARN de l'utilisateur ou du rôle en tant que mandataire. Dans ce cas, les autorisations de la stratégie basée sur les ressources sont ajoutées à la stratégie basée sur l'identité du rôle ou l'utilisateur avant la création de la session. La stratégie de session limite les autorisations totales accordées par la stratégie basée sur les ressources et la stratégie basée sur l'identité. Les autorisations de session obtenues sont une combinaison des stratégies de session et de la stratégie basée sur les ressources ou de la stratégie basée sur l'identité.


          Évaluation de la stratégie de session avec une stratégie basée sur les ressources en spécifiant l'ARN de l'entité

Une stratégie basée sur les ressources peut spécifier l'ARN de la session en tant que mandataire. Dans ce cas, les autorisations de la stratégie basée sur les ressources sont ajoutées après la création de la session. Les autorisations de stratégie basée sur les ressources ne sont pas limitées par la stratégie de session. La session résultante dispose de toutes les autorisations de la stratégie basée sur les ressources en plus de la combinaison de la stratégie basée sur l'identité et de la stratégie de session.


          Évaluation de la stratégie de session avec une stratégie basée sur les ressources en spécifiant l'ARN de la session

Une limite d'autorisations peut définir la limite maximale des autorisations pour un utilisateur ou un rôle qui est utilisé pour créer une session. Dans ce cas, les autorisations de session obtenues sont une combinaison de la stratégie de session, de la limite d'autorisations et de la stratégie basée sur l'identité. Toutefois, une limite d'autorisations ne limite pas les autorisations accordées par une stratégie basée sur les ressources, qui spécifie l'ARN de la session résultante.


          Évaluation de la stratégie de session avec une limite d'autorisations

Stratégies et utilisateur racine

L'Utilisateur racine d'un compte AWS est uniquement affecté par certains types de stratégie. Vous ne pouvez pas attacher des stratégies basées sur l'identité à l'utilisateur racine, et vous ne pouvez pas définir la limite d'autorisations pour l'utilisateur racine. Pourtant, vous pouvez spécifier l'utilisateur racine en tant que mandataire dans une stratégie basée sur les ressources ou une liste de contrôle d'accès (ACL). En tant que membre d'un compte, l'utilisateur racine est affecté par toutes les stratégies de contrôle de service du compte.

Présentation des stratégies JSON

La plupart des stratégies sont stockées dans AWS en tant que documents JSON. Les stratégies basées sur l'identité et les stratégies utilisées pour définir des autorisations sont des documents de stratégie JSON que vous attachez à un utilisateur ou à un rôle. Les stratégies basées sur les ressources sont des documents de stratégie JSON que vous attachez à une ressource. Les stratégies de contrôle de service sont des documents de stratégie JSON avec une syntaxe limitée que vous attachez à une unité d'organisation AWS Organizations. Les listes de contrôle d'accès sont également attachées à une ressource, mais vous devez utiliser une syntaxe différente. Les stratégies de session sont des stratégies JSON que vous fournissez lorsque vous assumez une session de rôle ou d'utilisateur fédéré.

Il n'est pas nécessaire pour vous de comprendre la syntaxe JSON. Vous pouvez utiliser l'éditeur visuel dans l'AWS Management Console pour créer et modifier des stratégies gérées par le client sans jamais utiliser JSON. Toutefois, si vous utilisez des stratégies en ligne pour des groupes ou des stratégies complexes, vous devez quand même créer et modifier ces stratégies dans l'éditeur JSON à l'aide de la console. Pour plus d'informations sur l'utilisation de l'éditeur visuel, consultez Création de stratégies IAM et Modification de stratégies IAM.

Structure d'un document de stratégie JSON

Comme illustré dans la figure suivante, un document de stratégie JSON inclut les éléments suivants :

  • Informations facultatives sur l'ensemble de la stratégie (en haut du document)

  • Une ou plusieurs déclarations individuelles

Chaque instruction inclut des informations sur une seule autorisation. Si une stratégie inclut plusieurs instructions, AWS applique une logique OR dans les instructions lors de leur évaluation. Si plusieurs stratégies s'appliquent à une demande, AWS applique une logique OR dans toutes ces stratégies lors de leur évaluation.


          Structure d'un document de stratégie JSON

Les informations contenues dans une déclaration sont situées dans une série d'éléments.

  • Version – Spécifiez la version du langage de stratégie que vous souhaitez utiliser. Conformément aux bonnes pratiques, utilisez la dernière version 2012-10-17.

  • Statement – Utilisez cet élément de stratégie principal comme conteneur pour les éléments suivants. Vous pouvez inclure plus d'une instruction dans une stratégie.

  • Sid (Facultatif) – Incluez un ID d'instruction facultatif pour différencier vos instructions.

  • Effect – Utilisez Allow ou Deny pour indiquer si la stratégie autorise ou refuse l'accès..

  • Principal (Obligatoire dans certaines circonstances uniquement) – Si vous créez une stratégie basée sur les ressources, vous devez indiquer le compte, l'utilisateur, le rôle ou l'utilisateur fédéré auquel vous souhaitez autoriser ou refuser l'accès. Si vous créez une stratégie d'autorisations IAM à attacher à un utilisateur ou un rôle, vous ne pouvez pas inclure cet élément. Le mandataire est implicitement cet utilisateur ou rôle.

  • Action – Incluez la liste des actions autorisées ou refusées par la stratégie.

  • Resource (Obligatoire dans certaines circonstances uniquement) – Si vous créez une stratégie d'autorisations IAM, vous devez spécifier la liste des ressources auxquelles les actions s'appliquent. Si vous créez une stratégie basée sur les ressources, cet élément est facultatif. Si vous n'incluez pas cet élément, la ressource à laquelle l'action s'applique est la ressource à laquelle la stratégie est attachée.

  • Condition (Facultatif) – Spécifiez les circonstances dans lesquelles la stratégie accorde une autorisation.

Pour en savoir plus sur ces éléments et d'autres éléments de stratégie plus avancés, consultez Références des éléments de stratégie JSON IAM.

Plusieurs déclarations et plusieurs stratégies

Si vous souhaitez définir plusieurs autorisations pour une entité (utilisateur, groupe ou rôle), vous pouvez utiliser plusieurs instructions dans une seule stratégie. Vous pouvez également attacher plusieurs stratégies. Si vous essayez de définir plusieurs autorisations dans une seule instruction, votre stratégie peut ne pas accorder l'accès que vous attendez. Conformément aux bonnes pratiques, divisez les stratégies par type de ressource.

En raison de la taille limitée des stratégies, il peut être nécessaire d'en utiliser plusieurs pour les autorisations les plus complexes. Il est également conseillé de créer des regroupements fonctionnels d'autorisations dans une stratégie gérée par le client séparée. Par exemple, créez une stratégie pour la gestion des utilisateurs IAM, une pour la gestion automatique et une autre pour la gestion de compartiment S3. Quelle que soit la combinaison de plusieurs instructions et stratégies, AWS évalue vos stratégies de la même manière.

Par exemple, la stratégie suivante comporte trois instructions, chacune définissant un ensemble séparé d'autorisations dans un seul compte. Les instructions définissent les opérations suivantes :

  • La première instruction, avec un Sid (ID de déclaration) de FirstStatement, permet à l'utilisateur disposant de la stratégie attachée de modifier son propre mot de passe. L'élément Resource de cette instruction a pour valeur « * » (ce qui signifie « toutes les ressources »). Toutefois, dans la pratique, l'opération d'API ChangePassword (ou la commande CLI change-password équivalente) affecte uniquement le mot de passe de l'utilisateur qui fait la demande.

  • La deuxième déclaration permet à l'utilisateur de répertorier tous les compartiments Amazon S3 de son compte AWS. L'élément Resource de cette instruction a pour valeur "*" (ce qui signifie « toutes les ressources »). Cependant, du fait que les stratégies n'accordent pas l'accès aux ressources des autres comptes, l'utilisateur peut uniquement répertorier les compartiments de son propre compte AWS.

  • La troisième instruction permet à l'utilisateur de répertorier les objets situés dans un compartiment appelé confidential-data, mais uniquement lorsque l'utilisateur est authentifié avec une authentification multi-facteurs (MFA). L'élément Condition de la stratégie applique l'authentification MFA.

    Lorsqu'une déclaration de stratégie contient un élément Condition, la déclaration est effective uniquement lorsque l'élément Condition est true. Dans ce cas, la Condition est true lorsque l'utilisateur est authentifié MFA. Si l'utilisateur n'est pas authentifié MFA, cette Condition est false. Dans ce cas, la troisième instruction de cette stratégie ne s'applique pas et l'utilisateur n'a pas accès au compartiment confidential-data.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FirstStatement", "Effect": "Allow", "Action": ["iam:ChangePassword"], "Resource": "*" }, { "Sid": "SecondStatement", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "ThirdStatement", "Effect": "Allow", "Action": [ "s3:List*", "s3:Get*" ], "Resource": [ "arn:aws:s3:::confidential-data", "arn:aws:s3:::confidential-data/*" ], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } ] }

Exemples de syntaxe d'une stratégie JSON

La stratégie basée sur l'identité suivante permet au mandataire implicite de répertorier un seul compartiment Amazon S3 nommé example_bucket :

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } }

La stratégie basée sur les ressources suivante peut être attachée à un compartiment Amazon S3. La stratégie permet aux membres d'un compte AWS spécifique d'exécuter n'importe quelle action Amazon S3 dans le compartiment nommé mybucket. Elle permet à n'importe quelle action d'être exécutée sur un compartiment ou les objets qu'il contient. (Du fait que la stratégie accorde une approbation uniquement au compte, les utilisateurs individuels du compte doivent se voir accorder des autorisations concernant les actions Amazon S3 spécifiées.)

{ "Version": "2012-10-17", "Id": "S3-Account-Permissions", "Statement": [{ "Sid": "1", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] }] }

Pour afficher des exemples de stratégies sur des scénarios courants, consultez Exemples de stratégies basées sur l'identité IAM.