Politiques et autorisations dans AWS Identity and Access Management

Gérez l'accès en AWS créant des politiques et en les associant à IAM des identités (utilisateurs, groupes d'utilisateurs ou rôles) ou à AWS des ressources. Une politique est un objet AWS qui, lorsqu'il est associé à une identité ou à une ressource, définit leurs autorisations. AWS évalue ces politiques lorsqu'un IAM principal (utilisateur ou rôle) fait 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 AWS sous forme de JSON documents. AWS prend en charge six types de politiques : les politiques basées sur l'identité, les politiques basées sur les ressources, les limites d'autorisations, les politiques de contrôle des services des Organisations (SCPs), les listes de contrôle d'accès (ACLs) et les politiques de session.

IAMles politiques définissent les autorisations pour une action, quelle que soit la méthode que vous utilisez pour effectuer l'opération. Par exemple, si une politique autorise l'GetUseraction, un utilisateur utilisant cette politique peut obtenir des informations utilisateur auprès du AWS Management Console AWS CLI, du ou du AWS API. Lorsque vous créez un IAM utilisateur, vous pouvez choisir d'autoriser l'accès par console ou par programmation. Si l'accès à la console est autorisé, l'IAMutilisateur peut se connecter à la console à l'aide de ses informations d'identification. Si l'accès par programmation est autorisé, l'utilisateur peut utiliser les touches d'accès pour utiliser le CLI ouAPI.

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.

• Politiques basées sur l'identité : associez des politiques gérées et intégrées aux IAM identités (utilisateurs, groupes auxquels les utilisateurs appartiennent 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 relatives aux compartiments Amazon S3 et les politiques de confiance en matière de IAM rôles. 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.

• Limites d'autorisations : utilisez une politique gérée comme limite d'autorisations pour une IAM entité (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é.

• Organisations SCPs : utilisez une politique de contrôle des AWS Organizations services (SCP) pour définir les autorisations maximales pour les membres du compte d'une organisation ou d'une unité organisationnelle (UO). SCPslimitez les autorisations que les politiques basées sur l'identité ou les politiques basées sur les ressources accordent aux entités (utilisateurs ou rôles) du compte, mais n'accordez pas d'autorisations.

• Listes de contrôle d'accès (ACLs) : ACLs à utiliser pour contrôler les principaux des autres comptes qui peuvent accéder à la ressource à laquelle ils ACL sont attachés. ACLssont similaires aux politiques basées sur les ressources, bien qu'elles soient le seul type de stratégie qui n'utilise pas la structure du document de JSON stratégie. ACLssont des politiques d'autorisations entre comptes qui accordent des autorisations au principal spécifié. ACLsne peut pas accorder d'autorisations aux entités d'un même compte.

• Politiques de session — Adoptez des politiques de session avancées lorsque vous utilisez le AWS CLI ou AWS API pour assumer 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 JSON des documents de politique d'autorisation 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 l'identité que vous pouvez associer à plusieurs utilisateurs, groupes et rôles au sein de votre. Compte AWS Il existe deux types de politiques gérées.

  • AWS politiques gérées : politiques gérées 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 fournissent un contrôle plus précis de vos politiques que les politiques AWS gérées.

• Politiques en ligne : politiques que vous ajoutez directement à un utilisateur unique, un groupe d'utilisateurs, ou un rôle. Les politiques intégrées maintiennent une one-to-one relation 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 Choisissez entre des politiques gérées et des politiques intégrées.

Politiques basées sur les ressources

Les politiques basées sur les ressources sont des documents de JSON politique 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 activer l'accès entre comptes, vous pouvez spécifier un compte entier ou IAM des entités d'un autre compte comme 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 sont séparés Comptes AWS, vous devez également utiliser une politique basée sur l'identité pour accorder au principal l'accès à 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 IAMtutoriel : Déléguer l'accès à travers AWS comptes utilisant des IAM rôles.

Le IAM service ne prend en charge qu'un seul type de politique basée sur les ressources, appelée politique de confiance des rôles, qui est attachée à un IAM rôle. Un IAM rôle est à la fois une identité et une ressource qui prend en charge les politiques basées sur les ressources. Pour cette raison, vous devez associer à la fois une politique de confiance et une politique basée sur l'identité à un IAM rôle. Les politiques d’approbation définissent quelles entités de principal (comptes, utilisateurs, rôles et utilisateurs fédérés) peuvent endosser le rôle. Pour savoir en quoi IAM les rôles sont différents des autres politiques basées sur les ressources, voir. Accès aux ressources entre comptes dans IAM

Pour connaître les autres services qui prennent en charge les politiques basées sur les ressources, voir AWS des 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 responsables de comptes situés en dehors de votre zone de confiance (organisation de confiance ou compte) ont accès à vos rôles, voir Qu'est-ce qu'IAMAccess Analyzer ? .

IAMlimites des autorisations

Une limite d'autorisations est une fonctionnalité avancée dans laquelle vous définissez le maximum d'autorisations qu'une politique basée sur l'identité peut accorder à une IAM entité. 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 annule l’autorisation. Pour plus d'informations sur les limites d'autorisations, consultez Limites d'autorisations pour des entités IAM.

Politiques de contrôle des services (SCPs)

AWS Organizations est un service permettant de regrouper et de gérer de manière centralisée Comptes AWS les actifs détenus par votre entreprise. Si vous activez toutes les fonctionnalités d'une organisation, vous pouvez appliquer des politiques de contrôle des services (SCPs) à l'un ou à l'ensemble de vos comptes. SCPssont des JSON politiques qui spécifient les autorisations maximales pour une organisation ou une unité organisationnelle (UO). Les SCP limites d'autorisations pour les entités présentes dans les comptes des membres, y compris chacune d'entre elles Utilisateur racine d'un compte AWS. Un refus explicite dans l’une de ces politiques annule l’autorisation.

Pour plus d'informations sur les Organizations et consultez SCPs les politiques de contrôle des services dans le Guide de AWS Organizations l'utilisateur.

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

Les listes de contrôle d'accès (ACLs) sont des politiques de service qui vous permettent de contrôler quels principaux d'un autre compte peuvent accéder à une ressource. ACLsne peut pas être utilisé pour contrôler l'accès d'un mandant au sein du même compte. ACLssont similaires aux politiques basées sur les ressources, bien qu'elles soient le seul type de stratégie qui n'utilise pas le format du document de JSON stratégie. Amazon S3 et Amazon VPC sont des exemples de services compatiblesACLs. AWS WAF Pour en savoir plusACLs, consultez la présentation de la liste 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 pour une session sont l'intersection des politiques basées sur l'identité de l'IAMentité (utilisateur ou rôle) utilisée pour créer la session et des 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 annule l’autorisation.

Vous pouvez créer une session de rôle et transmettre des politiques de session par programmation à l'aide des AssumeRole opérationsAssumeRoleWithSAML, ou AssumeRoleWithWebIdentityAPI. Vous pouvez transmettre un seul document de politique JSON de session en ligne à l'aide du Policy paramètre. 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 Autorisations pour les informations d'identification de sécurité temporaires.

Lorsque vous créez une session utilisateur fédérée, vous utilisez les clés d'accès de l'IAMutilisateur pour appeler l'opération par programmation. GetFederationToken API 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 Demande d'informations d'identification par le biais d'un courtier d'identité personnalisé.

Une politique basée sur les ressources peut spécifier ARN l'utilisateur ou le 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 ARN 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é. Cependant, une limite d'autorisations ne limite pas les autorisations accordées par une politique basée sur les ressources qui spécifie ARN la session résultante.

Politiques et utilisateur racine

Elle Utilisateur racine d'un compte AWS est affectée par certains types de politiques, mais pas par d'autres. 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. Toutefois, vous pouvez spécifier l'utilisateur root en tant que principal dans une politique basée sur les ressources ou dans un. ACL Un utilisateur racine est toujours le membre d'un compte. Si ce compte est membre d'une organisation en AWS Organizations, l'utilisateur root est concerné par tout ce qui SCPs concerne le compte.

Présentation des stratégies JSON

La plupart des politiques sont stockées AWS sous forme de JSON documents. Les politiques basées sur l'identité et les politiques utilisées pour définir les limites des autorisations sont des documents JSON de politique que vous attachez à un utilisateur ou à un rôle. Les politiques basées sur les ressources sont des documents JSON de stratégie que vous attachez à une ressource. SCPssont des documents de JSON politique à syntaxe restreinte que vous attachez à une unité AWS Organizations organisationnelle (UO). ACLssont également attachés à une ressource, mais vous devez utiliser une syntaxe différente. Les politiques de session sont des JSON politiques que vous fournissez lorsque vous assumez un rôle ou une session utilisateur fédérée.

Il n'est pas nécessaire que vous compreniez la JSON syntaxe. Vous pouvez utiliser l'éditeur visuel du AWS Management Console pour créer et modifier des politiques gérées par les clients sans jamais les utiliserJSON. Toutefois, si vous utilisez des politiques intégrées pour des groupes ou des politiques complexes, vous devez toujours créer et modifier ces politiques dans l'JSONéditeur à l'aide de la console. Pour plus d'informations sur l'utilisation de l'éditeur visuel, consultez Définissez des IAM autorisations personnalisées avec des politiques gérées par le client et Modifier les IAM politiques.

Lorsque vous créez ou modifiez une JSON politique, vous IAM pouvez effectuer une validation de stratégie pour vous aider à créer une politique efficace. IAMidentifie les erreurs de JSON syntaxe, tandis qu'IAMAccess Analyzer fournit des vérifications de politique supplémentaires avec des recommandations pour vous aider à affiner davantage vos politiques. Pour en savoir plus sur la validation de politiques, veuillez consulter IAMvalidation des politiques. Pour en savoir plus sur les vérifications des politiques IAM d'Access Analyzer et les recommandations pratiques, consultez la section Validation des politiques IAMAccess Analyzer.

JSONstructure du document de politique

Comme l'illustre la figure suivante, un document JSON de politique 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 aux instructions lors de leur évaluation. Si plusieurs politiques s'appliquent à une demande, AWS applique une logique OR à 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 IAMJSONéléments de politique : 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'IAMautorisation à associer à 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 uniquement dans certaines circonstances) — Si vous créez une politique d'IAMautorisation, vous devez spécifier une liste de 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 IAMJSONréférence à un élément de politique.

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 IAM utilisateurs, une autre pour l'autogestion et une autre pour la gestion des compartiments S3. Quelle que soit la combinaison de plusieurs déclarations et de plusieurs 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 »). Mais dans la pratique, l'ChangePasswordAPIopération (ou change-password CLI commande équivalente) n'affecte que 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 et de récupérer tout objet qui se trouve dans un compartiment nomméamzn-s3-demo-bucket-confidential-data, mais uniquement lorsque l'utilisateur est authentifié à l'aide de l'authentification multifactorielle ()MFA. L'Conditionélément de la politique impose l'MFAauthentification.

  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 valeur est vraie lorsque l'utilisateur est authentifiéMFA. Si l'utilisateur n'est pas MFA authentifié, cela donne la Condition valeur 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 amzn-s3-demo-bucket-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:::amzn-s3-demo-bucket-confidential-data",
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

Exemples de syntaxe JSON de politique

La politique basée sur l'identité suivante permet au principal implicite de répertorier un seul compartiment Amazon S3 nommé amzn-s3-demo-bucket :

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

La politique basée sur les ressources suivante peut être attachée à un compartiment Amazon S3. La politique permet aux membres d'un groupe spécifique Compte AWS d'effectuer toutes les actions Amazon S3 dans le compartiment nomméamzn-s3-demo-bucket. 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:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }]
}

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

Accorder le moindre privilège

Lorsque vous créez des IAM politiques, suivez les conseils de sécurité standard qui consistent à accorder le moindre privilège ou à n'accorder que les autorisations nécessaires à l'exécution d'une 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.

IAMpropose plusieurs options pour vous aider à affiner les autorisations que vous accordez.

• 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 Niveaux d'accès dans les récapitulatifs de politique.

• Validez vos politiques : vous pouvez effectuer la validation des politiques IAM à l'aide d'Access Analyzer lorsque vous créez et modifiez des JSON politiques. Nous vous recommandons d'examiner et de valider toutes vos politiques existantes. IAMAccess Analyzer fournit plus de 100 contrôles de politique 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 contrôles de politique fournis par IAM Access Analyzer, consultez la section Validation des politiques IAM Access Analyzer.

• Générer une politique basée sur l'activité d'accès — Pour vous aider à affiner les autorisations que vous accordez, vous pouvez générer une IAM politique basée sur l'activité d'accès d'une IAM entité (utilisateur ou rôle). IAMAccess Analyzer examine vos AWS CloudTrail journaux et génère un modèle de politique contenant les autorisations qui ont été utilisées par l'entité au cours de la période spécifiée. Vous pouvez utiliser le modèle pour créer une politique gérée avec des autorisations détaillées, puis l'associer à l'IAMentité. Ainsi, vous accordez uniquement les autorisations dont l'utilisateur ou le rôle a besoin pour interagir avec les AWS ressources correspondant à votre cas d'utilisation spécifique. Pour en savoir plus, consultez la section Génération de politiques IAM Access Analyzer.

• 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 dans l'onglet Access Advisor de la page de détails de la IAM console pour un IAM utilisateur, un groupe, un rôle ou une politique. Les dernières informations consultées incluent également des informations sur les actions auxquelles vous avez accédé pour la dernière fois pour certains services, tels qu'Amazon EC2IAM, Lambda et Amazon S3. Si vous vous connectez à l'aide AWS Organizations des informations d'identification du compte de gestion, vous pouvez consulter les informations du dernier accès au service dans la AWS Organizationssection de la IAM console. Vous pouvez également utiliser le AWS CLI ou AWS API pour récupérer un rapport sur les dernières informations consultées concernant les entités ou les politiques de nos IAM Organisations. Vous pouvez utiliser ces informations pour identifier les autorisations inutiles afin d'affiner vos politiques IAM ou celles des Organisations afin de mieux respecter le principe du moindre privilège. Pour de plus amples informations, veuillez consulter Affiner les autorisations en AWS utilisant les dernières informations consultées.

• Passez en revue les événements du compte dans AWS CloudTrail — Pour réduire davantage les autorisations, vous pouvez consulter les événements de votre compte dans l'historique des AWS CloudTrail événements. CloudTrail les journaux d'événements contiennent des informations détaillées sur les événements que vous pouvez utiliser pour réduire les autorisations prévues par la politique. Les journaux incluent uniquement les actions et les ressources dont vos IAM entités ont besoin. Pour plus d'informations, consultez la section Affichage CloudTrail des événements dans la CloudTrail console dans le guide de AWS CloudTrail l'utilisateur.

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.

• Utilisation de politiques basées sur les ressources pour DynamoDB dans le manuel du développeur Amazon DynamoDB

• Politiques relatives aux compartiments pour Amazon S3 dans le guide de l'utilisateur d'Amazon Simple Storage Service

• Présentation de la liste de contrôle d'accès (ACL) dans le guide de l'utilisateur d'Amazon Simple Storage Service