Documentation AWS » AWS Identity and Access Management » Guide de l'utilisateur » Gestion des accès » Stratégies et autorisations » Limites d'autorisations pour des entités IAM

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 dans laquelle vous utilisez une stratégie gérée pour définir les autorisations maximales qu'une stratégie 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.

Pour plus d'informations sur les types de stratégies, consultez 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 plus d'informations sur les différents types de stratégies, consultez 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 tout ce qui est autorisé par les deux types de stratégies. 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 des autorisations supplémentaires à l'entité. Les autorisations effectives pour cet ensemble de types de stratégies sont tout ce qui est autorisé par la stratégie basée sur les ressources et tout ce qui est autorisé par les limites d'autorisations et la stratégie basée sur les identités. 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. Si une entité IAM (utilisateur ou rôle) fait une demande affectée par une stratégie de contrôle de service, une limite d'autorisations et une stratégie basée sur l'identité, la demande est autorisée uniquement si les trois types de stratégie l'autorisent. Un refus explicite dans l'une de ces stratégies remplace l'autorisation.

Stratégies de session – Les stratégies de session sont des stratégies avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Les autorisations pour une session 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égies sont tout ce qui est autorisé par les trois types. Un refus explicite dans l'une de ces stratégies remplace l'autorisation. Pour plus d'informations sur les stratégies de session, consultez 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 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 :

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

2. María crée la stratégie gérée DelegatedUserBoundary et l'assigne en tant que limite d'autorisations pour Zhang.

3. María crée la stratégie gérée DelegatedUserPermissions et l'attache en tant que limite d'autorisations pour Zhang.

4. 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 accorde aux utilisateurs un accès complet à plusieurs services et un accès limité à gestion automatique dans IAM, et leur refuse l’accès aux compartiments de 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 :

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

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

3. 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. Cela est essentiel car si Zhang ou un autre administrateur accorde à un nouvel utilisateur une stratégie d'autorisations avec accès IAM complet, ce dernier peut alors modifier ses propres autorisations ou celles d'autres utilisateurs. Cette instruction évite ce genre de problème.

4. L'instruction DenyS3Logs refuse explicitement l'accès au compartiment logs.

5. 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"
            ],
            "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 :

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

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

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

4. 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 :

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

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

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

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 :

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

2. Sur la page Définir des autorisations, Zhang choisit les stratégies d'autorisations IAMFullAccess et AmazonS3ReadOnlyAccess qui permettent à Nikhil de travailler.

3. Zhang ignore la section Set permissions boundary (Définir une limite d'autorisations), oubliant ainsi les instructions de María.

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

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

6. 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 plus d'informations sur la propriété des compartiments, consultez 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 une stratégie basée sur les ressources à l'instance i-1234567890abcdef0 qui autorise Nikhil à démarrer et arrêter l'instance, elle ne peut pas gérer l'instance. La raison est que toutes les actions sur l'instance i-1234567890abcdef0 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:GetSecretsValue, Nikhil peut récupérer et déchiffrer le secret. La raison en est que les opérations Secrets Manager ne sont pas explicitement refusées par sa limite d'autorisations, et les limites d'autorisations ne limitent pas les stratégies basées sur les ressources.