Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Politiques et autorisations dans Gestion des identités et des accès AWS

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 neuf types de politiques : politiques basées sur l'identité, politiques basées sur les ressources, politiques de point de terminaison VPC, limites d'autorisations, politiques de contrôle des AWS Organizations services (SCP), politiques de contrôle des AWS Organizations ressources (RCP), listes de contrôle d'accès (ACL), partages Resource Access Manager (RAM) et 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 politiques

Identity-based les politiques sont des documents de politique d'autorisation 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. Identity-based les politiques peuvent être classées plus en détail :

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.

Resource-based politiques

Resource-based les politiques 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éfinissent dans quelles conditions cela s'applique. Resource-basedles politiques sont des politiques intégrées. 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 Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de 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 Identity-based politiques et politiques basées sur les ressources. 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 ?.

Politiques de point de terminaison d’un VPC

Une politique de point de terminaison VPC est une politique basée sur les ressources que vous attachez à un point de terminaison VPC pour contrôler quels principaux peuvent utiliser le point de terminaison et quelles ressources sont accessibles via celui-ci. Les politiques de point de terminaison VPC ne remplacent ni ne remplacent les politiques basées sur l'identité ou les politiques basées sur les ressources associées au service de destination. Elles agissent comme une limite d'accès supplémentaire limitée au trafic qui traverse le point de terminaison. Les politiques relatives aux points de terminaison VPC sont utilisées pour garantir que seules les identités fiables de votre AWS Organizations organisation peuvent accéder aux ressources fiables via vos points de terminaison VPC. Si vous ne joignez pas de politique de point de terminaison personnalisée, AWS associez une politique par défaut qui autorise un accès complet. Pour plus d'informations sur les politiques relatives aux points de terminaison, consultez la section Contrôler l'accès aux points de terminaison VPC à l'aide des politiques relatives aux points de terminaison dans le Guide.AWS PrivateLink

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 politiques 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 (SCP)

Si vous activez toutes les fonctionnalités d’une organisation, vous pouvez appliquer les politiques de contrôle des services (SCP) à l’un ou à l’ensemble de vos comptes. Les SCP 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é d’organisation (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 les SCP, consultez la section Politiques de contrôle des services (SCP) dans le guide de l'AWS Organizations utilisateur.

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

Si vous activez toutes les fonctions d’une organisation, vous pouvez utiliser les politiques de contrôle des ressources (RCP) pour appliquer de manière centralisée les contrôles d’accès aux ressources de plusieurs Comptes AWS. Les RCP sont des politiques JSON que vous pouvez utiliser pour définir le nombre 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 sur AWS Organizations les RCP, y compris une liste de ceux Services AWS qui prennent en charge les RCP, voir les politiques de contrôle des ressources (RCP) dans le guide de l'AWS Organizations utilisateur.

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 et Amazon VPC sont des exemples de services qui prennent en charge les ACL. AWS WAF Pour en savoir plus sur les listes de contrôle d’accès, consultez Présentation des listes de contrôle d’accès (ACL) dans le Guide du développeur Amazon Simple Storage Service.

AWS Resource Access Manager (AWS (RAM) partages de ressources

AWS Resource Access Manager (AWS RAM) vous permet de partager les ressources que vous créez dans l'une des Comptes AWS unités organisationnelles ou Compte AWS avec l'ensemble d'une organisation AWS Organizations, sans avoir à écrire de politiques individuelles basées sur les ressources pour chaque ressource partagée. Bien que vous puissiez accorder un accès entre comptes en attachant une politique basée sur les ressources directement à une ressource, la AWS RAM fournit une alternative gérée et centralisée qui élimine le besoin d'énumérer les identifiants de compte dans les politiques ou de conserver des documents de politique identiques pour tous les comptes. Grâce à la RAM, les comptes consommateurs voient les ressources partagées de manière native dans leurs consoles de service, les propriétaires des ressources conservent la pleine propriété et la visibilité sur les personnes qui y ont accès, et les autorisations gérées définissent le maximum d'actions que les consommateurs peuvent effectuer, le tout régi par un partage des ressources unique plutôt que par des politiques par ressource. Les cas d'utilisation courants incluent le partage de sous-réseaux VPC, de pièces jointes AWS Transit Gateway, de règles Route 53 Resolver et de configurations de License Manager entre comptes. Pour plus d'informations, voir Qu'est-ce que AWS Resource Access Manager ? dans le Guide de l'utilisateur de la AWS RAM.

Politiques de session

Les politiques de session sont des politiques avancées que vous transmettez en paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur principal AWS STS 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 utilisateur principale AWS STS fédérée, 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 les SCP et RCP associés au compte.

Présentation des politiques JSON

La plupart des politiques sont stockées AWS sous forme de documents JSON. Identity-based les politiques et politiques utilisées pour définir les limites des autorisations sont des documents de politique JSON que vous attachez à un utilisateur ou à un rôle. Resource-based les politiques sont des documents de politique JSON que vous attachez à une ressource. Les SCP et RCP 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. 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 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 :

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.

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 :

JSON

{
  "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 :

JSON

{
  "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.)

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333: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. Cela est plus sûr que de commencer par des autorisations trop clémentes puis d'essayer de les renforcer ultérieurement.

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.

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.