Limites d'autorisations pour des entités IAM
AWS prend en charge les limites d'autorisations pour les entités IAM (utilisateurs ou rôles). Une limite d'autorisations est une fonctionnalité avancée permettant d'utiliser une stratégie gérée pour définir les autorisations maximales qu'une stratégie basée sur l'identité peut accorder à une entité IAM. La limite d'autorisations d'une entité lui permet d'effectuer uniquement les actions autorisées à la fois par ses stratégies basées sur l'identité et ses limites d'autorisations.
Pour de plus amples informations sur les types de stratégies, veuillez consulter Types de stratégie.
Vous pouvez utiliser une stratégie gérée par AWS ou par le client pour définir la limite d'une entité IAM (utilisateur ou rôle). Cette stratégie limite le nombre maximum d'autorisations pour l'utilisateur ou le rôle.
Par exemple, supposons que l'utilisateur IAM nommé ShirleyRodriguez
doive être autorisé à gérer uniquement Amazon S3, Amazon CloudWatch et Amazon EC2.
Pour appliquer cette règle, vous pouvez utiliser la stratégie suivante afin de définir
les autorisations pour l'utilisateur ShirleyRodriguez
:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*" ], "Resource": "*" } ] }
Lorsque vous utilisez une stratégie pour définir la limite d'autorisations d'un utilisateur,
elle limite les autorisations de l'utilisateur mais ne fournit pas seule les autorisations.
Dans cet exemple, la stratégie définit les autorisations maximales de ShirleyRodriguez
en tant que toutes les opérations dans Amazon S3, CloudWatch et Amazon EC2. Shirley
ne peut pas exécuter d'opérations dans les autres services, y compris IAM, même si
elle dispose d'une stratégie d'autorisations qui le permet. Par exemple, vous pouvez
ajouter la stratégie suivante à l'utilisateur ShirleyRodriguez
:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:CreateUser", "Resource": "*" } }
Cette stratégie permet de créer un utilisateur dans IAM. Si vous attachez cette stratégie
à l'utilisateur ShirleyRodriguez
et que Shirley tente de créer un utilisateur, l'opération échoue. Elle échoue car
la logique d'évaluation de stratégie recherche la stratégie utilisée en tant que limite
d'autorisations limite qui n'autorise pas l'opération iam:CreateUser
. Pour autoriser Shirley à exécuter toutes les opérations dans AWS, vous devez ajouter
une stratégie d'autorisations avec des actions dans Amazon S3, Amazon CloudWatch ou
Amazon EC2. Sinon, vous pouvez mettre à jour la limite d'autorisations pour lui permettre
de créer un utilisateur dans IAM.
Évaluation des autorisations effectives avec limites
La limite d'autorisations pour une entité IAM (utilisateur ou rôle) définit le nombre maximum d'autorisations maximum dont peut disposer une entité. Cela peut modifier les autorisations effectives pour cet utilisateur ou rôle. Les autorisations effectives d'une entité correspondent aux autorisations accordées par toutes les stratégies affectant l'utilisateur ou le rôle. Dans un compte, les autorisations d'une entité peuvent être affectées par des stratégies basées sur l'identité, des stratégies basées sur les ressources, des limites d'autorisations, des stratégies de contrôle de service Organisations ou des stratégies de session. Pour de plus amples informations sur les différents types de stratégies, veuillez consulter Stratégies et autorisations.
Si l'un de ces types de stratégie refuse explicitement l'accès pour une opération, la demande est refusée. Les autorisations accordées à une entité par plusieurs types d'autorisations sont plus complexes. Pour plus de détails sur la manière dont AWS évalue les stratégies, consultez Logique d'évaluation des stratégies.
Stratégies basées sur l'identité avec des limites – Les stratégies basées sur l'identité sont des stratégies en ligne ou gérées qui sont attachées à un utilisateur, un groupe d'utilisateurs ou un rôle. Les stratégies basées sur l'identité accordent une autorisation à l'entité, et les limites d'autorisations limitent ces autorisations. Les autorisations effectives sont une combinaison de ces deux types de stratégie. Un refus explicite dans l'une ou l'autre de ces stratégies remplace l'autorisation.

Stratégies basées sur les ressources – Les stratégies basées sur les ressources contrôlent la façon dont le mandataire spécifié peut accéder à la ressource à laquelle la stratégie est attachée. Dans un compte, les limites d'autorisations ne réduisent pas les autorisations accordées par les stratégies basées sur les ressources. Les limites d'autorisations réduisent les autorisations accordées à une entité par des stratégies basées sur l'identité. Les stratégies basées sur des ressources fournissent ensuite des autorisations supplémentaires à l'entité. Dans ce cas, les autorisations effectives représentent tout ce qui est autorisé par la stratégie basée sur les ressources et la combinaison de la limite d'autorisations et de la stratégie basée sur l'identité. Un refus explicite dans l'une de ces stratégies remplace l'autorisation.

Stratégies de contrôle de service Organisations – Les stratégies de contrôle de service sont appliquées à l'ensemble d'un compte AWS. Elles limitent les autorisations pour chaque demande faite par un mandataire dans le compte. Une entité IAM (utilisateur ou rôle) peut effectuer une demande qui est soumise à une stratégie de contrôle de service, une limite d'autorisations et une stratégie basée sur l'identité. Dans ce cas, la demande est autorisée uniquement si les trois types de stratégie l'autorisent. Les autorisations effectives sont la combinaison des trois types de stratégie. Un refus explicite dans l'une de ces stratégies remplace l'autorisation.

Vous pouvez savoir si votre compte est membre d'une organisation dans AWS Organizations. Les membres de l'organisation peuvent être soumis à une stratégie
de contrôle de service. Pour afficher ces données à l'aide de la commande de l'AWS
CLI ou de l'opération d'API AWS, vous devez avoir les autorisations permettant d'effectuer
l'action organizations:DescribeOrganization
pour votre entité Organisations. Vous devez disposer d'autorisations supplémentaires
pour effectuer l'opération dans la console Organisations. Pour savoir si une stratégie
de contrôle de service refuse l'accès à une demande spécifique ou pour modifier vos
autorisations effectives, contactez votre administrateur AWS Organizations.
Stratégies de session – Les stratégies de session sont des stratégies avancées que vous transmettez 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 proviennent de l'entité IAM (utilisateur ou rôle) utilisée pour créer la session et de la stratégie de la session. Les autorisations de stratégie basée sur l'identité de l'entité sont limitées par la stratégie de la session et la limite d'autorisations. Les autorisations effectives pour cet ensemble de types de stratégie sont la combinaison des trois types de stratégie. Un refus explicite dans l'une de ces stratégies remplace l'autorisation. Pour de plus amples informations sur les stratégies de session, veuillez consulter Stratégies de session.

Délégation de responsabilité à d'autres utilisateurs à l'aide des limites d'autorisations
Vous pouvez utiliser des limites d'autorisations pour déléguer à des utilisateurs IAM de votre compte des tâches de gestion d'autorisations, comme la création d'utilisateurs,. Cela permet à d’autres utilisateurs d’exécuter des tâches en votre nom dans une limite d’autorisations spécifique.
Par exemple, supposons que María soit l'administratrice du compte AWS de l'entreprise X. Elle souhaite déléguer des tâches de création d'utilisateurs à Zhang. Toutefois, elle doit s'assurer que Zhang crée des utilisateurs qui respectent les règles de l'entreprise suivantes :
-
Les utilisateurs ne peuvent pas utiliser IAM pour créer ou gérer des utilisateurs, groupes, rôles ou stratégies.
-
Les utilisateurs se voient refuser l'accès au compartiment Amazon S3
logs
et ne peuvent pas accéder à l'instance Amazon EC2i-1234567890abcdef0
. -
Les utilisateurs ne peuvent pas supprimer leurs propres stratégies de limite.
Pour appliquer ces règles, María exécute les tâches suivantes dont les détails sont inclus ci-dessous :
-
María crée la stratégie gérée
XCompanyBoundaries
pour utiliser en tant que limite d'autorisations pour tous les nouveaux utilisateurs du compte. -
María crée la stratégie gérée
DelegatedUserBoundary
et l'assigne en tant que limite d'autorisations pour Zhang. -
María crée la stratégie gérée
DelegatedUserPermissions
et l'attache en tant que limite d'autorisations pour Zhang. -
María explique à Zhang ses nouvelles responsabilités et limites.
Tâche 1 : María doit d'abord créer une stratégie gérée pour définir la limite pour les nouveaux
utilisateurs. María autorise Zhang à donner aux utilisateurs les stratégies d'autorisations
dont ils ont besoin, mais elle souhaite que ces derniers soient limités. Pour ce faire,
elle crée la stratégie gérée par le client suivante avec le nom XCompanyBoundaries
. Cette stratégie effectue les opérations suivantes :
-
Permet aux utilisateurs d'avoir un accès complet à plusieurs services
-
Autorise un accès autonome limité dans IAM
-
Refuse aux utilisateurs l'accès au compartiment des journaux Amazon S3 ou à l'instance Amazon EC2
i-1234567890abcdef0
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ServiceBoundaries", "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*", "dynamodb:*" ], "Resource": "*" }, { "Sid": "AllowIAMConsoleForCredentials", "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswordAndAccessKeys", "Effect": "Allow", "Action": [ "iam:*AccessKey*", "iam:ChangePassword", "iam:GetUser", "iam:*ServiceSpecificCredential*", "iam:*SigningCertificate*" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::logs", "arn:aws:s3:::logs/*" ] }, { "Sid": "DenyEC2Production", "Effect": "Deny", "Action": "ec2:*", "Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0" } ] }
Chaque instruction répond à un objectif distinct :
-
L'instruction
ServiceBoundaries
de cette stratégie accorde un accès complet aux services AWS spécifiés. Cela signifie que de nouvelles actions de l'utilisateur dans ces services sont uniquement limitées par les stratégies d'autorisations qui lui sont attachées. -
L'instruction
AllowIAMConsoleForCredentials
autorise l'accès pour répertorier tous les utilisateurs IAM. Cet accès est nécessaire pour accéder à la page Utilisateurs dans la AWS Management Console. Il permet également d'afficher les exigences de mot de passe pour le compte, qui sont nécessaires lorsque vous modifiez votre mot de passe. -
L'instruction
AllowManageOwnPasswordAndAccessKeys
autorise les utilisateurs à gérer uniquement leur propre mot de passe de console et les clés d'accès par programmation. Ceci est important si Zhang ou un autre administrateur accorde à un nouvel utilisateur une stratégie d'autorisations avec un accès IAM complet. Dans ce cas, cet utilisateur peut ensuite modifier ses propres autorisations ou celles des autres utilisateurs. Cette instruction évite ce genre de problème. -
L'instruction
DenyS3Logs
refuse explicitement l'accès au compartimentlogs
. -
L'instruction
DenyEC2Production
refuse explicitement l'accès à l'instancei-1234567890abcdef0
.
Tâche 2 : María souhaite autoriser Zhang à créer tous les utilisateurs X-Company, mais uniquement
avec la limite d'autorisations XCompanyBoundaries
. Elle crée la stratégie gérée par le client suivante et la nomme DelegatedUserBoundary
. Cette stratégie définit le nombre maximum de permissions dont dispose Zhang.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CreateOrChangeOnlyWithBoundary", "Effect": "Allow", "Action": [ "iam:CreateUser", "iam:DeleteUserPolicy", "iam:AttachUserPolicy", "iam:DetachUserPolicy", "iam:PutUserPermissionsBoundary" ], "Resource": "*", "Condition": {"StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/XCompanyBoundaries"}} }, { "Sid": "CloudWatchAndOtherIAMTasks", "Effect": "Allow", "Action": [ "cloudwatch:*", "iam:GetUser", "iam:ListUsers", "iam:DeleteUser", "iam:UpdateUser", "iam:CreateAccessKey", "iam:CreateLoginProfile", "iam:GetAccountPasswordPolicy", "iam:GetLoginProfile", "iam:*Group*", "iam:CreatePolicy", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetUserPolicy", "iam:GetRolePolicy", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:ListEntitiesForPolicy", "iam:ListUserPolicies", "iam:ListAttachedUserPolicies", "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:PutUserPolicy", "iam:SetDefaultPolicyVersion", "iam:SimulatePrincipalPolicy", "iam:SimulateCustomPolicy" ], "Resource": "*" }, { "Sid": "NoBoundaryPolicyEdit", "Effect": "Deny", "Action": [ "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": [ "arn:aws:iam::123456789012:policy/XCompanyBoundaries", "arn:aws:iam::123456789012:policy/DelegatedUserBoundary" ] }, { "Sid": "NoBoundaryUserDelete", "Effect": "Deny", "Action": "iam:DeleteUserPermissionsBoundary", "Resource": "*" } ] }
Chaque instruction répond à un objectif distinct :
-
L'instruction
CreateOrChangeOnlyWithBoundary
autorise Zhang à créer des utilisateurs IAM, mais uniquement s'il utilise la stratégieXCompanyBoundaries
permettant de définir la limite d'autorisations. Cette instruction lui permet également de définir la limite d'autorisations pour les utilisateurs existants, mais uniquement à l'aide de cette même stratégie. Enfin, cette instruction autorise Zhang à gérer des stratégies d'autorisations pour les utilisateurs avec cette limite d'autorisations définie. -
L'instruction
CloudWatchAndOtherIAMTasks
autorise Zhang à exécuter les tâches de gestion d'autres utilisateurs, groupes et stratégies. Remarque : Zhang n'a pas l'autorisation de supprimer la limite d'autorisations pour lui-même ou d'autres utilisateurs. -
L'instruction
NoBoundaryPolicyEdit
refuse l'accès à Zhang pour mettre à jour la stratégieXCompanyBoundaries
. Il n'est pas autorisé à modifier une stratégie utilisée pour définir la limite d'autorisations pour lui-même ou d'autres utilisateurs. -
L’instruction
NoBoundaryUserDelete
interdit à Zhang de supprimer la limite d’autorisations pour lui-même ou d’autres utilisateurs.
María attribue ensuite la stratégie DelegatedUserBoundary
comme limite d'autorisations pour l'utilisateur Zhang
.
Tâche 3 : María doit créer une stratégie d'autorisations pour Zhang, car la limite d'autorisations
restreint le nombre maximum d'autorisations, mais n'accorde pas à elle seule l'accès.
Elle crée la stratégie suivante et la nomme DelegatedUserPermissions
. Cette stratégie définit les opérations que Zhang peut exécuter au sein de la limite
définie.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAM", "Effect": "Allow", "Action": "iam:*", "Resource": "*" }, { "Sid": "CloudWatchLimited", "Effect": "Allow", "Action": [ "cloudwatch:GetDashboard", "cloudwatch:GetMetricData", "cloudwatch:ListDashboards", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics" ], "Resource": "*" }, { "Sid": "S3BucketContents", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::ZhangBucket" } ] }
Chaque instruction répond à un objectif distinct :
-
L'instruction
IAM
de la stratégie accorde à Zhang un accès complet à IAM. Toutefois, ses limites d'autorisations n'autorisant que certaines opérations IAM, ses autorisations IAM effectives sont uniquement restreintes par sa limite d'autorisations. -
L'instruction
CloudWatchLimited
autorise Zhang à exécuter cinq actions dans CloudWatch. Sa limite d'autorisations permet toutes les actions dans CloudWatch. Par conséquent, ses autorisations CloudWatch effectives sont limitées uniquement par sa stratégie d'autorisations. -
L'instruction
S3BucketContents
autorise Zhang à répertorier le compartiment Amazon S3ZhangBucket
. Toutefois, sa limite d'autorisations n'autorise aucune action Amazon S3. Par conséquent, il ne peut pas exécuter d'opérations S3, quelle que soit sa stratégie d'autorisations.
María assigne ensuite la stratégie DelegatedUserPermissions
en tant que stratégie d'autorisations pour l'utilisateur Zhang
.
Tâche 4 : Elle explique à Zhang comment créer un nouvel utilisateur. Elle lui indique qu'il
peut créer de nouveaux utilisateurs avec les autorisations dont il a besoin, mais
il doit leur assigner la stratégie XCompanyBoundaries
en tant que limite d'autorisations.
Zhang exécute les tâches suivantes :
-
Zhang crée un utilisateur avec l'AWS Management Console. Il saisit le nom d'utilisateur
Nikhil
et accorde à l'utilisateur l'accès à la console. -
Sur la page Définir des autorisations, Zhang choisit les stratégies d'autorisations IAMFullAccess et AmazonS3ReadOnlyAccess qui permettent à Nikhil de travailler.
-
Zhang ignore la section Set permissions boundary (Définir une limite d'autorisations), oubliant ainsi les instructions de María.
-
Zhang examine les détails de l'utilisateur et choisit Créer un utilisateur.
L'opération échoue et l'accès est refusé. La limite d'autorisations
DelegatedUserBoundary
de Zhang exige que tous les utilisateurs qu'il crée utilisent la stratégieXCompanyBoundaries
en tant que limite d'autorisations. -
Zhang revient à la page précédente. Dans la section Set permissions boundary (Définir une limite d'autorisations), il choisit la stratégie
XCompanyBoundaries
. -
Zhang examine les détails de l'utilisateur et choisit Créer un utilisateur.
L'utilisateur est créé.
Lorsque Nikhil se connecte, il accède à IAM et Amazon S3, à l'exception des opérations
refusées par la limite d'autorisations. Par exemple, il peut modifier son propre mot
de passe dans IAM, mais ne peut pas créer d'autre utilisateur ou modifier ses stratégies.
Nikhil a un accès en lecture seule à tous les compartiments dont il est le propriétaire
dans Amazon S3. Toutefois, même si quelqu'un lui accorde la propriété sur le compartiment
logs
, il ne peut pas l'afficher. Pour de plus amples informations sur la propriété des
compartiments, veuillez consulter Gestion des autorisations d'accès de vos ressources Amazon S3 dans le Amazon Simple Storage Service Manuel du développeur.
Si une personne ajoute au compartiment logs
une stratégie basée sur les ressources qui autorise Nikhil à placer un objet dans
le compartiment, il ne peut toujours pas accéder au compartiment. En effet, toutes
les actions sur le compartiment logs
sont explicitement refusées par sa limite d'autorisations. Un refus explicite dans
n'importe quel type de stratégie se traduit par le refus d'une demande. Toutefois,
si une stratégie basée sur les ressources attachée à un secret Secrets Manager permet
à Nikhil d'effectuer l'action secretsmanager:GetSecretValue
, Nikhil peut récupérer et déchiffrer le secret. En effet, les opérations Secrets
Manager ne sont pas explicitement refusées par sa limite d'autorisations et les conditions
de refus implicite dans les limites d'autorisations ne limitent pas les stratégies
basées sur les ressources.