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.

Limites d'autorisations pour des entités IAM

AWS prend en charge les limites d'autorisations pour les IAM entités (utilisateurs ou rôles). Une limite d'autorisations est une fonctionnalité avancée permettant d'utiliser une stratégie gérée afin de définir le maximum d'autorisations qu'une politique basée sur l'identité peut accorder à une IAM entité. 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.

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

Supposons, par exemple, que l'IAMutilisateur nommé ShirleyRodriguez soit autorisé à gérer uniquement Amazon S3 CloudWatch, Amazon et AmazonEC2. 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 pour toutes les opérations dans Amazon S3 et AmazonEC2. ShirleyRodriguez CloudWatch Shirley ne pourra jamais effectuer d'opérations dans aucun autre serviceIAM, même si elle dispose d'une politique d'autorisation qui l'autorise. 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 dansIAM. 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. Vous pouvez également mettre à jour la limite des autorisations pour lui permettre de créer un utilisateur dansIAM.

Évaluation des autorisations effectives avec limites

La limite d'autorisations pour une IAM entité (utilisateur ou rôle) définit le maximum d'autorisations que l'entité peut avoir. 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. Au sein d'un compte, les autorisations accordées à une entité peuvent être affectées par les politiques basées sur l'identité, les politiques basées sur les ressources, les limites des autorisations, les Organisations SCPs ou les politiques de session. Pour de plus amples informations sur les différents types de politiques, veuillez consulter Politiques et autorisations dans AWS Identity and Access Management.

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 le mode AWS d'évaluation des politiques, consultezLogique d’évaluation de stratégies.

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.

Organisations SCPs : SCPs s'appliquent à un ensemble Compte AWS. Elles limitent les autorisations pour chaque demande faite par un principal dans le compte. Une IAM entité (utilisateur ou rôle) peut faire une demande affectée par uneSCP, une limite d'autorisation 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 annule l’autorisation.

Vous pouvez savoir si votre compte est membre d'une organisation dans AWS Organizations. Les membres de l'organisation peuvent être concernés par unSCP. Pour afficher ces données à l'aide de la AWS CLI commande ou de AWS API l'opération, vous devez disposer des autorisations nécessaires à l'organizations:DescribeOrganizationaction pour votre entité Organizations. Vous devez disposer des autorisations supplémentaires pour effectuer l'opération dans la console Organizations. Pour savoir si un SCP refuse l'accès à une demande spécifique ou pour modifier vos autorisations effectives, contactez votre AWS Organizations administrateur.

Politiques de séance : les politiques de séance sont des politiques avancées que vous utilisez en tant que paramètre lorsque vous créez par programmation une séance temporaire pour un rôle ou un utilisateur fédéré. Les autorisations pour une session proviennent de l'IAMentité (utilisateur ou rôle) utilisée pour créer la session et de la politique de 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 annule 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 les limites d'autorisations pour déléguer les tâches de gestion des autorisations, telles que la création d'utilisateurs, aux IAM utilisateurs de votre compte. Cela permet à d'autres utilisateurs d'exécuter des tâches en votre nom dans une limite d'autorisations spécifique.

Supposons, par exemple, que María soit l'administratrice de la X-Company Compte AWS. 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 :

Pour appliquer ces règles, María exécute les tâches suivantes dont les détails sont inclus ci-dessous :

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 :

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

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 :

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 :

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 :

Lorsque Nikhil se connecte, il a accès à IAM Amazon S3, à l'exception des opérations interdites par la limite des autorisations. Par exemple, il peut modifier son propre mot de passe IAM mais ne peut pas créer un autre utilisateur ni 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.