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 s'y connecter à l'aide de ses informations d'identification. Si l'accès programmatique est autorisé, l'utilisateur peut utiliser des clés d'accès pour travailler avec la CLI 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 IAM (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 Amazon 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 stratégie basée sur des ressources accorde l'accès à un principal dans le même compte, aucune autre stratégie 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 Accès intercompte aux ressources dans IAM.

Pour connaître les autres services qui prennent en charge les politiques basées sur les ressources, voir AWS services 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 que l'Analyseur d'accès IAM ?.

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. 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 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 politiques 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 les clés d'accès de l'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é 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é.

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.

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.

Politiques 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 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.

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. Nous vous recommandons de choisir la dernière version 2012-10-17. Pour plus d'informations, consultez Éléments de politique JSON IAM : Version.

• 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. Nous vous recommandons de répartir 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 ne peut répertorier que 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.

Accorder les privilèges les plus faibles possible

Lorsque vous créez des politiques IAM, suivez le conseil de sécurité standard du moindre privilège, principe selon lequel il ne faut accorder que les autorisations requises pour une seule tâche. Déterminez les actions que les utilisateurs (et les rôles) doivent effectuer et élaborez des politiques leur permettant de réaliser uniquement ces tâches.

Commencez avec un ensemble d'autorisations minimum et accordez-en d'autres si nécessaire. Cette méthode est plus sûre que de commencer avec des autorisations trop permissives et d'essayer de les restreindre plus tard.

Comme alternative au moindre privilège, vous pouvez utiliser des politiques gérées par AWS ou des politiques accompagnées d'autorisations de * par caractère générique, pour commencer avec les politiques. Veuillez prendre en compte le risque de sécurité constitué par l'octroi, à vos principaux, de davantage d'autorisations que nécessaire pour accomplir leur tâche. Contrôlez ces principaux afin de savoir quelles autorisations ils utilisent. Écrivez ensuite des politiques de moindre privilège.

IAM propose plusieurs options pour vous aider à affiner les autorisations que vous octroyez.

• Understand access level groupings (Comprendre les regroupements de niveau d'accès) : vous pouvez utiliser des regroupements de niveaux d'accès pour comprendre le niveau d'accès accordé par la politique. Les actions de politique sont classées en tant que List, Read, Write, Permissions management ou Tagging. Par exemple, vous pouvez choisir des actions dans les niveaux d'accès List et Read pour accorder un accès en lecture seule à vos utilisateurs. Pour savoir comment utiliser les récapitulatifs de politiques pour comprendre les autorisations de niveau d'accès, consultez Comprendre les niveaux d'accès dans les résumés des politiques.

• Valider vos politiques : vous pouvez effectuer une validation de politique à l'aide d'IAM Access Analyzer lorsque vous créez et modifiez des politiques JSON. Nous vous recommandons d'examiner et de valider toutes vos politiques existantes. IAM Access Analyzer fournit plus de 100 vérifications de politiques pour valider vos politiques. Il génère des avertissements de sécurité lorsqu'une instruction de votre politique autorise un accès que nous considérons comme trop permissif. Vous pouvez utiliser les recommandations exploitables contenues dans les avertissements de sécurité lorsque vous travaillez à l'octroi du moindre privilège. Pour en savoir plus sur les vérifications de politique fournies par IAM Access Analyzer, veuillez consulter IAM Access Analyzer policy validation (Validation de politique IAM Access Analyzer).

• Générer une politique basée sur l'activité d'accès : pour affiner les autorisations que vous octroyez, vous pouvez générer une politique IAM basée sur l'activité d'accès pour une entité IAM (utilisateur ou rôle). IAM Access Analyzer passe en revue vos journaux AWS CloudTrail et génère un modèle de politique contenant les autorisations qui ont été utilisées par l'entité dans la plage de dates spécifiée. Vous pouvez utiliser le modèle pour créer une politique gérée avec des autorisations affinées, puis l'attacher à l'entité IAM. De cette façon, vous accordez uniquement les autorisations dont l'utilisateur ou le rôle a besoin pour interagir avec les ressources AWS pour votre cas d'utilisation spécifique. Pour en savoir plus, veuillez consulter la section Générer des politiques basées sur l'activité d'accès.

• Utiliser les dernières informations consultées : les dernières informations consultées sont une autre fonction pouvant vous aider avec le principe de moindre privilège. Consultez ces informations sous l'onglet Access Advisor sur la page des détails de la console IAM pour un utilisateur, un groupe, un rôle ou une politique IAM. Les dernières informations consultées incluent également des informations sur les dernières actions consultées pour certains services, tels qu'Amazon EC2, IAM, Lambda et Amazon S3. Si vous vous connectez à l'aide des informations d'identification du compte de gestion AWS Organizations, vous pouvez afficher les dernières informations consultées relatives au service dans la section AWS Organizations de la console IAM. Vous pouvez également utiliser la AWS CLI ou l'API AWS pour récupérer un rapport sur les données des services consultés en dernier pour les entités ou politiques dans IAM ou Organizations. Elles vous permettent d'identifier toute autorisation inutile. Vous pouvez ainsi peaufiner vos politiques IAM ou Organizations afin qu'elles respectent au plus près le principe du moindre privilège. Pour plus d’informations, veuillez consulter Ajustement des autorisations dans AWS à l'aide des dernières informations consultées.

• Consulter les événements de compte dans AWS CloudTrail : pour réduire davantage les autorisations, vous pouvez afficher les événements de votre compte dans l'historique des événements AWS CloudTrail. Les journaux d'événements CloudTrail incluent des informations d'événement détaillées utilisables pour réduire les autorisations de la politique. Les journaux incluent uniquement les actions et les ressources dont vos entités IAM ont besoin. Pour de plus amples informations, veuillez consulter Affichage des événements dans la console CloudTrail dans le Guide de l'utilisateur AWS CloudTrail.

Pour en savoir plus, consultez les rubriques de politiques pour des services individuels qui fournissent des exemples de rédaction de politiques pour des ressources spécifiques à des services.

• Authentification et contrôle d'accès pour Amazon DynamoDB dans le Manuel du développeur Amazon DynamoDB

• Utilisation de politiques de compartiment et de politiques d'utilisateur dans le guide de l'utilisateur du service de stockage simple Amazon

• Présentation de la liste de contrôle d'accès (ACL) dans le guide de l'utilisateur service de stockage simple Amazon