Évaluation des autorisations effectives avec limites Délégation de responsabilité à d'autres utilisateurs à l'aide des limites d'autorisations

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 d'autorisation à l'utilisateur ShirleyRodriguez et que Shirley tente de créer un utilisateur, l'opération échoue. Elle échoue car la limite des autorisations n'autorise pas l'opération iam:CreateUser. Compte tenu de ces deux stratégies, Shirley n'est pas autorisée à effectuer des opérations dans AWS. Vous devez ajouter une stratégie d'autorisations différente pour autoriser des actions dans d'autres services, tels que Amazon S3. 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 dans IAM.

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

Évaluation des stratégies basées sur l'identité et des limites d'autorisations

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.

Stratégies basées sur des ressources pour les utilisateurs IAM: Dans un compte, un refus implicite dans une limite d'autorisations ne limite pas les autorisations accordées à un utilisateur IAM par une stratégie basée sur les ressources. Les limites d'autorisations réduisent les autorisations accordées à un utilisateur par des stratégies basées sur l'identité. Les stratégies basées sur les ressources peuvent fournir à l'utilisateur des autorisations supplémentaires.
Stratégies basées sur les ressources pour les rôles IAM et les utilisateurs fédérés: Dans un compte, un refus implicite dans une limite d'autorisations limite les autorisations accordées à l'ARN du rôle IAM ou de l'utilisateur IAM sous-jacent par la stratégie basée sur les ressources. Cependant, si la stratégie basée sur les ressources accorde des autorisations directement au principal de session (l'ARN de rôle endossé ou d'utilisateur fédéré), un refus implicite dans la limite d'autorisations ne limite pas ces autorisations. Pour plus d'informations sur les autorisations effectives pour les sessions de rôle endossé ou d'utilisateur fédéré, consultez la section Stratégies de session.

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.

Évaluation d'une stratégie de contrôle de service, d'une limite d'autorisations et d'une stratégie basée sur l'identité

Vous pouvez savoir si votre compte est membre d'une organisation dans AWS Organizations. Les membres de l'organisation pourraient être affectés par une SCP. Pour afficher ces données à l'aide de la commande d'AWS CLI ou 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 des 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.

Évaluation d'une stratégie de session, d'une limite d'autorisations et d'une stratégie basée sur l'identité

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 EC2 i-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. Maria prend note de l'ARN de son administrateur IAM et l'utilise dans la stratégie pour empêcher Zhang d'y accéder.
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 la console IAM Cela signifie qu'ils peuvent changer leur mot de passe après s'être connecté à la console. Ils ne peuvent pas définir leur mot de passe initial. Pour autoriser ces actions, ajoutez l'action "*LoginProfile" à la déclaration AllowManageOwnPasswordAndAccessKeys.
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 compartiment logs.
L'instruction DenyEC2Production refuse explicitement l'accès à l'instance i-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",
                "iam:PutUserPolicy"
            ],
            "Resource": "*",
            "Condition": {"StringEquals": 
                {"iam:PermissionsBoundary": "arn:aws:iam::123456789012: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:ListGroups",
                "iam:ListGroupsForUser",
                "iam:CreateGroup",
                "iam:GetGroup",
                "iam:DeleteGroup",
                "iam:UpdateGroup",
                "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:SetDefaultPolicyVersion",
                "iam:SimulatePrincipalPolicy",
                "iam:SimulateCustomPolicy" 
            ],
            "NotResource": "arn:aws:iam::123456789012:user/Maria"
        },
        {
            "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égie XCompanyBoundaries 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. Il possède les autorisations de réinitialiser les mots de passe et de créer des clés d'accès pour tout utilisateur IAM non répertorié dans la clé de condition. Cela lui permet d'aider les utilisateurs qui rencontrent des problèmes de connexion.
L'instruction NoBoundaryPolicyEdit refuse l'accès à Zhang pour mettre à jour la stratégie XCompanyBoundaries. 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 S3 ZhangBucket. 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.

Note

Les stratégies de Zhang lui permettent de créer un utilisateur qui peut alors accéder à des ressources Amazon S3 auxquelles il ne peut pas accéder. En déléguant ces actions administratives, Maria approuve l’accès de Zhang à Amazon S3.

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. Il désactive la case à cocher en regard de Réinitialisation du mot de passe, car les stratégies ci-dessus permettent à Zhang de modifier son mot de passe uniquement après s'être connecté à la console IAM.
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égie XCompanyBoundaries 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 à Amazon S3.

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.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Stratégies gérées par AWS obsolètes

Identité et ressource