Politiques et autorisations dans AWS Identity and Access Management

Gérez l'accès en AWS créant des politiques et en les associant aux identités IAM (utilisateurs, groupes d'utilisateurs ou rôles) ou aux AWS 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 principal IAM (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 documents JSON. AWS prend en charge sept 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 AWS Organizations services (SCPs), les politiques de contrôle AWS Organizations des ressources (RCPs), les listes de contrôle d'accès (ACLs) 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'GetUseraction, un utilisateur utilisant cette politique peut obtenir des informations utilisateur auprès de AWS Management Console, de AWS CLI, ou de l' AWS API. 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é.

• AWS Organizations SCPs— Utilisez une politique de contrôle des AWS Organizations services (SCP) pour définir les autorisations maximales pour les utilisateurs IAM et les rôles IAM au sein des comptes de votre organisation ou unité organisationnelle (UO). SCPs limiter les autorisations que les politiques basées sur l'identité ou les politiques basées sur les ressources accordent aux utilisateurs IAM ou aux rôles IAM au sein du compte. SCPs n'accordez pas d'autorisations.

• AWS Organizations RCPs— Utilisez une politique de contrôle AWS Organizations des ressources (RCP) pour définir les autorisations maximales pour les ressources au sein des comptes de votre organisation ou unité organisationnelle (UO). RCPs limitez les autorisations que les politiques basées sur l'identité et les ressources peuvent accorder aux ressources des comptes au sein de votre organisation. RCPs 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 l'ACL est attachée. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles soient le seul type de politique qui n'utilise pas la structure du document de stratégie JSON. ACLs sont des politiques d'autorisations entre comptes qui accordent des autorisations au principal spécifié. ACLs ne 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 l' AWS API AWS CLI or 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 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 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 Choix entre politiques gérées et 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 intercompte à 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 entre les AWS comptes à l'aide de IAM rôles.

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. Si vous spécifiez un rôle, une session ou un utilisateur dans l’élément principal d’une politique basée sur les ressources, une autorisation explicite dans la limite des autorisations n’est pas requise. Toutefois, si vous spécifiez un ARN de rôle dans l’élément principal d’une politique basée sur les ressources, une autorisation explicite dans la limite des autorisations est requise. Dans les deux cas, un refus explicite dans la limite des autorisations est effectif. 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 les entités IAM.

AWS Organizations politiques de contrôle des services (SCPs)

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. SCPs sont des politiques JSON qui spécifient les autorisations maximales pour les utilisateurs IAM et les rôles IAM au sein des comptes d'une organisation ou d'une unité organisationnelle (UO). Le SCP limite les autorisations accordées aux principaux sur les comptes des membres, y compris pour chacun d'entre eux. Utilisateur racine d'un compte AWS Un rejet explicite dans l’une de ces politiques annule toute autorisation définie dans d’autres politiques.

Pour plus d'informations sur AWS Organizations et SCPs, voir Politiques de contrôle des services (SCPs) dans le Guide de AWS Organizations l'utilisateur.

AWS Organizations politiques de contrôle des ressources (RCPs)

Si vous activez toutes les fonctionnalités d'une organisation, vous pouvez utiliser les politiques de contrôle des ressources (RCPs) pour appliquer de manière centralisée les contrôles d'accès aux ressources de plusieurs organisations Comptes AWS. RCPs sont des politiques JSON que vous pouvez utiliser pour définir le maximum d'autorisations disponibles pour les ressources de vos comptes sans mettre à jour les politiques IAM associées à chaque ressource que vous possédez. Le RCP limite les autorisations pour les ressources des comptes membres et peut avoir un impact sur les autorisations effectives pour les identités, y compris Utilisateur racine d'un compte AWS, qu'elles appartiennent ou non à votre organisation. Un refus explicite dans toute RCP applicable annule toute autorisation définie dans d’autres politiques susceptibles d’être associées à des identités ou à des ressources individuelles.

Pour plus d'informations AWS Organizations et pour RCPs inclure une liste de ces Services AWS supports RCPs, voir Politiques de contrôle des ressources (RCPs) 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. ACLs ne peut pas être utilisé pour contrôler l'accès d'un mandant au sein du même compte. ACLs sont similaires 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 stratégie JSON. Amazon S3 et AWS WAF Amazon VPC sont des exemples de services compatibles. ACLs Pour en savoir plus ACLs, 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 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 annule 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 Autorisations affectées aux informations d’identification de sécurité temporaires.

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 Demande d’informations d’identification via un fournisseur 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

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. 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 en AWS Organizations, l'utilisateur root est affecté par SCPs et RCPs pour le compte.

Présentation des politiques JSON

La plupart des politiques sont stockées AWS sous forme de 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. SCPset RCPs sont des documents de politique JSON à syntaxe restreinte que vous attachez à la AWS Organizations« racine de l'organisation », à l'unité organisationnelle (UO) ou à un compte. ACLs sont également attachés à 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 du 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 Définition d’autorisations IAM personnalisées avec des politiques gérées par le client 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 politique 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 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 É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) : si vous créez une politique basée sur les ressources, vous devez spécifier 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) : 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 requis ou non en fonction de la ressource que vous utilisez.

• 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érence de l’élément 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 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 »). 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é amzn-s3-demo-bucket-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 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 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é 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 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 Niveaux d'accès dans les récapitulatifs de politique.

• 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 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 affinées, puis l'attacher à l'entité IAM. 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 Génération d’une politique de l’analyseur d’accès IAM.

• 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 actions auxquelles vous avez accédé pour la dernière fois pour certains services, tels qu'Amazon EC2, IAM, 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 console IAM. Vous pouvez également utiliser l' AWS API AWS CLI or pour récupérer un rapport sur les dernières informations consultées pour les entités ou les politiques dans IAM ou AWS Organizations. Vous pouvez utiliser ces informations pour identifier les autorisations inutiles afin d'affiner votre IAM ou vos AWS Organizations politiques 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 entités IAM 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 Guide du développeur Amazon DynamoDB

• Politiques de compartiment pour Amazon S3 dans le Guide de l’utilisateur Amazon Simple Storage Service.

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