Limites d'autorisations pour les 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 politique gérée pour définir les autorisations maximales qu'une politique 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 politiques basées sur l'identité et ses limites d'autorisations.

Pour de plus amples informations sur les types de politiques, veuillez consulter Types de politique.

Important

N'utilisez pas de déclarations de politique basée sur les ressources qui incluent un élément de politique NotPrincipal ayant un effet Deny sur les utilisateurs IAM ou les rôles auxquels est attachée une politique de limites des autorisations. L'élément NotPrincipal ayant un effet Deny refusera toujours tout principal IAM auquel est attachée une politique de limite des autorisations, quelles que soient les valeurs spécifiées dans l'élément NotPrincipal. Certains utilisateurs ou rôles IAM qui auraient autrement eu accès à la ressource n'y ont donc plus accès. Nous vous recommandons de modifier vos déclarations de politique basée sur les ressources afin d'utiliser l'opérateur de condition ArnNotEquals avec la clé de contexte aws:PrincipalArn dans le but de limiter l'accès plutôt que l'élément NotPrincipal. Pour en savoir plus sur l'élément NotPrincipal, veuillez consulter AWS Éléments de politique JSON : NotPrincipal.

Vous pouvez utiliser une politique gérée par AWS ou par le client pour définir la limite d'une entité IAM (utilisateur ou rôle). Cette politique limite le nombre maximum d'autorisations pour l'utilisateur ou le rôle.

Par exemple, supposons que l'utilisateur IAM dénommé ShirleyRodriguez doit être autorisé à gérer uniquement Amazon S3, Amazon CloudWatch et Amazon EC2. Pour appliquer cette règle, vous pouvez utiliser la politique 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 politique 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 politique 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 politique d'autorisations qui le permet. Par exemple, vous pouvez ajouter la politique suivante à l'utilisateur ShirleyRodriguez :

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:CreateUser",
    "Resource": "*"
  }
}

Cette politique permet de créer un utilisateur dans IAM. Si vous attachez cette politique 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 politiques, Shirley n'est pas autorisée à effectuer des opérations dans AWS. Vous devez ajouter une politique d'autorisations différente pour autoriser des actions dans d'autres services, tels qu'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 politiques affectant l'utilisateur ou le rôle. Dans un compte, les autorisations d'une entité peuvent être affectées par des politiques basées sur l'identité, des politiques basées sur les ressources, des limites d'autorisations, des politiques de contrôle de service Organizations ou des politiques de session. Pour de plus amples informations sur les différents types de politiques, veuillez consulter Politiques et autorisations dans IAM.

Si l'un de ces types de politique 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 politiques, consultez Logique d'évaluation de politiques.

Identity-based policies with boundaries (Politiques basées sur l'identité avec des limites) : les politiques basées sur l'identité sont des politiques en ligne ou gérées qui sont attachées à un utilisateur, un groupe d'utilisateurs ou un rôle. Les politiques 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 politique. Un refus explicite dans l'une ou l'autre de ces stratégies remplace l'autorisation.

Resource-based policies (Politiques basées sur les ressources) : les politiques basées sur les ressources contrôlent la façon dont le principal spécifié peut accéder à la ressource à laquelle la politique est attachée.

Politiques basées sur des ressources pour les utilisateurs IAM

Au sein d'un même compte, les politiques basées sur les ressources qui accordent des autorisations à un ARN d'utilisateur IAM (qui n'est pas une séance d'utilisateur fédéré) ne sont pas limitées par un rejet implicite dans une politique basée sur l'identité ou une limite d'autorisations.

Politiques basées sur les ressources pour les rôles IAM

Rôle IAM – Les politiques basées sur les ressources qui accordent des autorisations à un ARN de rôle IAM sont limitées par un rejet implicite dans une limite d'autorisations ou une politique de séance.

Séance de rôle IAM – Au sein d'un même compte, les politiques basées sur les ressources qui accordent des autorisations à un ARN de séance de rôle IAM accordent des autorisations directement à la séance de rôle endossée. Les autorisations accordées directement à une séance ne sont pas limitées par un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance. Lorsque vous endossez un rôle et faites une demande, le principal qui fait la demande est l'ARN de séance du rôle IAM et non l'ARN du rôle lui-même.

Politiques basées sur les ressources pour les sessions d'utilisateur fédéré IAM

Séances d'utilisateur fédéré IAM – Une séance d'utilisateur fédéré IAM est une séance créée en appelant les outils GetFederationToken. Lorsqu'un utilisateur fédéré fait une demande, le principal qui effectue la demande est l'ARN d'utilisateur fédéré et non l'ARN de l'utilisateur IAM qui a fédéré. Dans le même compte, les politiques basées sur les ressources accordant des autorisations à un ARN d'utilisateur fédéré accordent des autorisations directement à la séance. Les autorisations accordées directement à une séance ne sont pas limitées par un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance.

Cependant, si une politique basée sur les ressources accorde une autorisation à l'ARN de l'utilisateur IAM qui s'est fédéré, les demandes faites par l'utilisateur fédéré pendant la séance sont limitées par un rejet implicite dans une limite d'autorisation ou une politique de séance.

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

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é Organizations. Vous devez disposer des autorisations supplémentaires pour effectuer l'opération dans la console Organizations. 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.

Politiques de session : les politiques de session sont des politiques avancées que vous passez en tant que paramètre lorsque vous programmez afin de créer 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 politique de la session. Les autorisations de politique basée sur l'identité de l'entité sont limitées par la politique de la session et la limite d'autorisations. Les autorisations effectives pour cet ensemble de types de politique sont la combinaison des trois types de politique. Un refus explicite dans l'une de ces politiques remplace l'autorisation. Pour de plus amples informations sur les politiques de session, veuillez consulter Politiques 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 de l'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 politiques.

• Les utilisateurs se voient refuser l'accès au compartiment logs Amazon S3 et ne peuvent pas accéder à l'instance Amazon EC2 i-1234567890abcdef0.

• Les utilisateurs ne peuvent pas supprimer leurs propres politiques 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 politique 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 politique gérée DelegatedUserBoundary et l'assigne en tant que limite d'autorisations pour Zhang. Maria prend note de l'ARN de son administrateur et l'utilise dans la stratégie pour empêcher Zhang d'y accéder.

3. María crée la politique 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 politique gérée pour définir la limite pour les nouveaux utilisateurs. María autorise Zhang à donner aux utilisateurs les politiques d'autorisations dont ils ont besoin, mais elle souhaite que ces derniers soient limités. Pour ce faire, elle crée la politique gérée par le client suivante avec le nom XCompanyBoundaries. Cette politique 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 que cela soit possible, ajoutez l'action "*LoginProfile" à l'instruction 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 :

1. L'instruction ServiceBoundaries de cette politique 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 politiques 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. La déclaration 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 attribue à un nouvel utilisateur une politique d'autorisations avec un accès complet à IAM. Dans ce cas, cet utilisateur peut ensuite modifier ses propres autorisations ou celles des 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 politique gérée par le client suivante et la nomme DelegatedUserBoundary. Cette politique définit le nombre maximum de permissions dont dispose Zhang.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CreateOrChangeOnlyWithBoundary",
            "Effect": "Allow",
            "Action": [
                "iam:AttachUserPolicy",
                "iam:CreateUser",
                "iam:DeleteUserPolicy",
                "iam:DetachUserPolicy",
                "iam:PutUserPermissionsBoundary",
                "iam:PutUserPolicy"
            ],
            "Resource": "*",
            "Condition": {
               "StringEquals": {
                 "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries"
                }
            }
        },
        {
            "Sid": "CloudWatchAndOtherIAMTasks",
            "Effect": "Allow",
            "Action": [
              "cloudwatch:*",
              "iam:CreateAccessKey",
              "iam:CreateGroup",
              "iam:CreateLoginProfile",
              "iam:CreatePolicy",
              "iam:DeleteGroup",
              "iam:DeletePolicy",
              "iam:DeletePolicyVersion",
              "iam:DeleteUser",
              "iam:GetAccountPasswordPolicy",
              "iam:GetGroup",
              "iam:GetLoginProfile",
              "iam:GetPolicy",
              "iam:GetPolicyVersion",
              "iam:GetRolePolicy",
              "iam:GetUser",
              "iam:GetUserPolicy",
              "iam:ListAccessKeys",
              "iam:ListAttachedRolePolicies",
              "iam:ListAttachedUserPolicies",
              "iam:ListEntitiesForPolicy",
              "iam:ListGroups",
              "iam:ListGroupsForUser",
              "iam:ListMFADevices",
              "iam:ListPolicies",
              "iam:ListPolicyVersions",
              "iam:ListRolePolicies",
              "iam:ListSSHPublicKeys",
              "iam:ListServiceSpecificCredentials",
              "iam:ListSigningCertificates",
              "iam:ListUserPolicies",
              "iam:ListUsers",
              "iam:SetDefaultPolicyVersion",
              "iam:SimulateCustomPolicy",
              "iam:SimulatePrincipalPolicy",
              "iam:UpdateGroup",
              "iam:UpdateLoginProfile",
              "iam:UpdateUser"
            ],
            "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 :

1. L'instruction CreateOrChangeOnlyWithBoundary autorise Zhang à créer des utilisateurs IAM, mais uniquement s'il utilise la politique 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 politique. Enfin, cette instruction autorise Zhang à gérer des politiques 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 politiques. 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 l’élément de politique NotResource. Cela lui permet d'aider les utilisateurs qui rencontrent des problèmes de connexion.

3. L'instruction NoBoundaryPolicyEdit refuse l'accès à Zhang pour mettre à jour la politique XCompanyBoundaries. Il n'est pas autorisé à modifier une politique 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 politique DelegatedUserBoundary comme limite d'autorisations pour l'utilisateur Zhang.

Tâche 3 : María doit créer une politique 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 politique suivante et la nomme DelegatedUserPermissions. Cette politique 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 politique accorde à Zhang un accès complet à IAM. Toutefois, ses autorisations IAM effectives sont uniquement restreintes par sa limite d'autorisations, car cette dernière autorise uniquement certaines opérations IAM.

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 politique 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 politique d'autorisations.

   Note

   Les politiques 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 politique DelegatedUserPermissions en tant que politique 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 politique 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. Il décoche la case en regard de Requires password reset (Réinitialisation du mot de passe requise), car les politiques ci-dessus permettent à Zhang de modifier son mot de passe uniquement après s'être connecté à la console IAM.

2. Sur la page Définir des autorisations, Zhang choisit les politiques 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 politique 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 politique 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 politiques. Nikhil a un accès en lecture seule à Amazon S3.

Si une personne ajoute au compartiment logs une politique 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 politique se traduit par le refus d'une demande. Toutefois, si une politique 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 politiques basées sur les ressources.