Politiques et autorisations dans IAM - AWS Identity and Access Management

Politiques et autorisations dans IAM

Vous gérez les accès dans AWS en créant des politiques et en les attachant à des identités IAM (utilisateurs, groupes d'utilisateurs ou rôles) ou des ressources AWS. Une politique 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 politiques lorsqu'un principal IAM (utilisateur ou rôle) envoie une demande. Les autorisations dans les politiques déterminent si la demande est autorisée ou refusée. La plupart des politiques sont stockées dans AWS sous forme de documents JSON. AWS prend en charge six types de politiques : les politiques basées sur une identité, les politiques basées sur les ressources, les limites d'autorisations, les politiques de contrôle de service Organizations, les listes ACL et les politiques de session.

Les politiques 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 politique autorise l'action GetUser, un utilisateur disposant de cette politique peut obtenir des informations utilisateur à partir de l’interface AWS Management Console, de l’interface 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 politique

Les types de politiques suivants sont répertoriés dans l'ordre du plus fréquemment utilisé au moins fréquemment utilisé, et ils peuvent être utilisés dans AWS. Pour de plus amples informations, veuillez consulter les sections ci-dessous pour chaque type de politique.

  • Identity-based policies (Politiques basées sur l'identité) – attachez des politiques gérées et en ligne à des identités (utilisateurs, groupes auxquels appartiennent des utilisateurs ou rôles). Les politiques basées sur l'identité accordent des autorisations à une identité.

  • Resource-based policies (Politiques basées sur les ressources) – attachez des politiques en ligne aux ressources. Les exemples les plus courants de politiques basées sur les ressources sont les politiques de compartiment &S3; et les politiques confiance de rôle IAM. Les politiques basées sur des ressources accordent des autorisations au principal qui est spécifié dans la politique. Les principaux peuvent être dans le même compte que la ressource ou dans d'autres comptes.

  • Permissions boundaries (Limites d'autorisations) – utilisez une politique gérée en tant que limite d'autorisations pour une entité IAM (utilisateur ou rôle). Cette politique définit les autorisations maximales que les politiques 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 politique basée sur les ressources peut accorder à une entité.

  • Organizations SCPs (Politiques de contrôle des services Organizations) – 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 politiques 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.

  • Access control lists (ACLs) (Listes de contrôle d'accès [ACL]) – utilisez les listes de contrôle d'accès (ACL) pour contrôler quels principaux 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 politiques basées sur les ressources, bien qu'elles soient le seul type de politique qui n'utilise pas la structure d'un document de politique JSON. Les listes de contrôle d'accès sont des politiques d'autorisations entre comptes qui accordent des autorisations pour le principal spécifié. Les listes de contrôle d'accès ne peuvent pas accorder des autorisations aux entités au sein du même compte.

  • Session policies (Politiques de session) – transmettez des politiques de session avancées lorsque vous utilisez AWS CLI ou l'API AWS pour endosser un rôle ou un utilisateur fédéré. Les politiques de session limitent les autorisations que les politiques basées sur l'identité du rôle ou de l'utilisateur accordent à la session. Les politiques de session limitent les autorisations d'une session créée, mais n'accordent pas d'autorisations. Pour plus d'informations, consultez Politiques de session.

Politiques basées sur l'identité

Les politiques basées sur l'identité sont des documents de politique d'autorisations JSON qui contrôlent les actions qu'une identité (utilisateurs, groupes d'utilisateurs et rôles) peut effectuer, sur quelles ressources, et dans quelles conditions. Les politiques basées l'identité peuvent être classées comme suit :

  • Politiques gérées – politiques autonomes basées sur une identité que vous pouvez attacher à plusieurs utilisateurs, groupes et rôles dans votre compte AWS. Il existe deux types de politiques gérées.

    • Politiques gérées par AWS – politiques gérées qui sont créées et gérées par AWS.

    • Politiques gérées par le client – politiques gérées que vous créez et gérez dans votre compte AWS. Les politiques gérées par le client offrent davantage de précision sur vos politiques que les politiques gérées par AWS.

  • Politiques en ligne : politiques que vous ajoutez directement à un utilisateur unique, un groupe d'utilisateurs, ou un rôle. Les politiques en ligne maintiennent une relation un-à-un stricte entre une politique et une identité. Elles sont supprimées lorsque vous supprimez l'identité.

Pour savoir comment choisir entre des politiques gérées et en ligne, veuillez consulter Choix entre les politiques gérées et les politiques en ligne.

Politiques basées sur les ressources

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

Pour permettre un accès comptes multiples , vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. L'ajout d'un principal entre comptes à une politique basée sur les ressources ne représente qu'une partie de l'instauration de la relation d'approbation. Lorsque le principal et la ressource se trouvent dans des comptes AWS distincts, vous devez également utiliser une politique basée sur une identité pour autoriser le principal à accéder à la ressource. Toutefois, si une politique basée sur des ressources accorde l'accès à un principal dans le même compte, aucune autre politique basée sur l'identité n'est requise. Pour obtenir des instructions détaillées sur l'octroi d'un accès entre services, veuillez consulter Didacticiel IAM : déléguer l'accès entre des comptes AWS à l'aide des rôles IAM.

Le service IAM prend en charge un seul type de politique basée sur les ressources, nommé politique 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 politiques basées sur les ressources. C'est pour cette raison que vous devez associer une politique d'approbation et une politique basée sur une identité à un rôle IAM. Les politiques d'approbation définissent quelles entités principaux (comptes, utilisateurs, rôles et utilisateurs fédérés) peuvent endosser le rôle. Pour en savoir plus sur la façon dont les rôles IAM sont différents d'autres politiques basées sur les ressources, consultez Différence entre les rôles IAM et les politiques basées sur les ressources.

Pour connaître les autres services qui prennent en charge les politiques basées sur les ressources, voir AWSServices qui fonctionnent avec IAM. Pour en savoir plus sur politiques basées sur les ressources, voir Politiques basées sur l'identité et Politiques basées sur une ressource. Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, consultez Qu'est-ce qu'IAM Access Analyzer ?.

Limites d'autorisations IAM

Une limite d'autorisations est une fonctionnalité avancée dans laquelle vous définissez les autorisations maximales qu'une politique 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 politiques basées sur les ressources qui spécifient l'utilisateur ou le rôle en tant que principal ne sont pas limitées par les limites d'autorisations. Un refus explicite dans l'une de ces politiques remplace l'autorisation. Pour plus d'informations sur les limites d'autorisations, consultez Limites d'autorisations pour les entités IAM.

Politiques de contrôle de service (SCP)

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 politiques 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. Les stratégies de contrôle des services (SCP) limitent les autorisations pour les entités dans les comptes membres, y compris chaque utilisateur racine de compte Compte AWS. Un refus explicite dans l'une de ces politiques remplace l'autorisation.

Pour plus d'informations sur les organisations et les SCP, veuillez consulter Fonctionnement des SCP dans le Guide de l'utilisateur AWS Organizations.

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

Les listes de contrôle d'accès (ACL) sont des politiques de service qui vous permettent de contrôler quels principaux 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 principal au sein du même compte. Les listes de contrôle d'accès sont semblables aux politiques basées sur les ressources, bien qu'elles soient le seul type de politique qui n'utilise pas le format de document de politique JSON. Amazon S3, AWS WAF et Amazon VPC sont des exemples de services prenant en charge les ACL. Pour en savoir plus sur les listes de contrôle d'accès, veuillez consulter Présentation des listes de contrôle d'accès (ACL) dans le Guide du développeur Amazon Simple Storage Service.

Politiques de session

Les politiques de session sont des politiques avancées que vous passez en tant que 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 politiques basées sur l'identité de l'entité IAM (utilisateur ou rôle) utilisée pour créer la session et les politiques de session. Les autorisations peuvent également provenir d'une politique basée sur les ressources. Un refus explicite dans l'une de ces politiques remplace l'autorisation.

Vous pouvez créer une session de rôle et transmettre des politiques de session par programmation à l'aide des opérations d'API AssumeRole, AssumeRoleWithSAML ou AssumeRoleWithWebIdentity. Vous pouvez transmettre un seul document de politique 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 Demande 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 politiques de session. Les autorisations de session obtenues sont une combinaison de la politique basée sur l'identité de l'utilisateur IAM et de la politique 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 politique basée sur les ressources peut spécifier l'ARN de l'utilisateur ou du rôle en tant que principal. Dans ce cas, les autorisations de la politique basée sur les ressources sont ajoutées à la politique basée sur l'identité du rôle ou l'utilisateur avant la création de la session. La politique de session limite les autorisations totales accordées par la politique basée sur les ressources et la politique basée sur l'identité. Les autorisations de session résultantes sont l'intersection des politiques de session et des politiques basées sur les ressources, plus l'intersection des politiques de session et des politiques basées sur l'identité.


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

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


          Évaluation de la politique de session avec une politique 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 politique de session, de la limite d'autorisations et de la politique basée sur l'identité. Toutefois, une limite d'autorisations ne limite pas les autorisations accordées par une politique basée sur les ressources, qui spécifie l'ARN de la session résultante.


          Évaluation de la politique de session avec une limite d'autorisations

Politiques et utilisateur racine

L'utilisateur racine Compte AWS est uniquement affecté par certains types de politique. Vous ne pouvez pas attacher des politiques 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 principal dans une politique basée sur les ressources ou une liste de contrôle d'accès. Un utilisateur racine est toujours le membre d'un compte. Si ce compte est membre d'une organisation dans AWS Organizations, l'utilisateur racine est affecté par les SCP du compte.

Présentation des politiques JSON

La plupart des politiques sont stockées dans AWS en tant que documents JSON. Les politiques basées sur l'identité et les politiques utilisées pour définir des autorisations sont des documents de politique JSON que vous attachez à un utilisateur ou à un rôle. Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les politiques de contrôle de service sont des documents de politique 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 politiques de session sont des politiques JSON que vous fournissez lorsque vous endossez 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 lterface AWS Management Console pour créer et modifier des politiques gérées par le client sans jamais utiliser JSON. Toutefois, si vous utilisez des politiques en ligne pour des groupes ou des politiques complexes, vous devez quand même créer et modifier ces politiques dans l'éditeur JSON à l'aide de la console. Pour plus d'informations sur l'utilisation de l'éditeur visuel, consultez Création de politiques IAM et Modification de politiques IAM.

Lorsque vous créez ou modifiez une politique JSON, IAM peut effectuer une validation de politique pour vous aider à créer une politique efficace. IAM identifie les erreurs de syntaxe JSON, tandis que IAM Access Analyzer fournit des vérifications de politique supplémentaires avec des recommandations pour vous aider à affiner vos politiques. Pour en savoir plus sur la validation de politiques, veuillez consulter Validation de politiques IAM. Pour en savoir plus sur les vérifications des politiques IAM Access Analyzer et les recommandations exploitables, veuillez consulter Validation de politique IAM Access Analyzer.

Structure d'un document de politique JSON

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

  • Informations facultatives sur l'ensemble de la politique (en haut du document)

  • Une ou plusieurs instructions individuelles

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


          Structure d'un document de politique JSON

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

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

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

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

  • Effect – utilisez Allow ou Deny pour indiquer si la politique autorise ou refuse l'accès.

  • Principal (Obligatoire dans certaines circonstances uniquement) – si vous créez une politique 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 politique d'autorisations IAM à attacher à un utilisateur ou un rôle, vous ne pouvez pas inclure cet élément. Le principal est implicitement cet utilisateur ou rôle.

  • Action – incluez la liste des actions autorisées ou refusées par la politique.

  • Resource (Obligatoire dans certaines circonstances uniquement) – si vous créez une politique d'autorisations IAM, vous devez spécifier la liste des ressources auxquelles les actions s'appliquent. Si vous créez une politique 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 politique est attachée.

  • Condition (Facultatif) – spécifiez les circonstances dans lesquelles la politique accorde une autorisation.

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

Plusieurs instructions et plusieurs politiques

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

En raison de la taille limitée des politiques, 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 politique gérée par le client séparée. Par exemple, créez une politique 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 politiques, AWS évalue vos politiques de la même manière.

Par exemple, la politique 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 d’instruction) de FirstStatement, permet à l'utilisateur disposant de la politique 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 instruction 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 politiques 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-facteur (MFA). L'élément Condition de la politique applique l'authentification MFA.

    Lorsqu'une instruction de politique contient un élément Condition, l'instruction 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 politique 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 politique JSON

La politique basée sur l'identité suivante permet au principal 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 politique basée sur les ressources suivante peut être attachée à un compartiment Amazon S3. La politique 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 politique 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", "Statement": [{ "Sid": "1", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::account-id:root"]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] }] }

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