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 limite 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 AWS gérée ou une politique gérée par le client pour définir les limites d'une entité IAM (utilisateur ou rôle). Cette politique limite le nombre maximum d'autorisations pour l'utilisateur ou le rôle.

Supposons, par exemple, que l'utilisateur IAM nommé Shirley soit autorisé à gérer uniquement Amazon S3 CloudWatch, Amazon et Amazon EC2. Pour appliquer cette règle, vous pouvez utiliser la politique suivante afin de définir les autorisations pour l'utilisateur Shirley :

JSON

{
    "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 Amazon EC2. Shirley CloudWatch 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 Shirley :

JSON

{
  "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 Shirley 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. 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 ou les politiques de session AWS Organizations SCPs. 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 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 utilisateur IAM (qui n'est pas une session principale d'utilisateur AWS STS fédérée) ne sont pas limitées par un refus implicite dans une politique basée sur l'identité ou une limite d'autorisation.

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 principales des AWS STS utilisateurs fédérés

AWS STS sessions d'utilisateur principal fédérées — Une session d'utilisateur principal AWS STS fédérée est une session créée en appelant. 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.

Toutefois, si une politique basée sur les ressources accorde l'autorisation à l'ARN de l'utilisateur IAM qui a fédéré, les demandes effectuées par le principal de l'utilisateur AWS STS fédéré pendant la session sont limitées par un refus implicite dans une limite d'autorisation ou une politique de session.

AWS Organizations SCPs— SCPs sont appliqués à un tout 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 annule 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 AWS CLI commande ou de l'opération AWS API, vous devez disposer des autorisations nécessaires à l'organizations:DescribeOrganizationaction pour votre AWS Organizations entité. Vous devez disposer d'autorisations supplémentaires pour effectuer l'opération dans la AWS Organizations console. 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 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 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 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.

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 :

• 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 Amazon logs S3 et ne peuvent pas accéder à l' EC2 instance i-1234567890abcdef0 Amazon.

• 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 de logs Amazon S3 ou à l' EC2 instance i-1234567890abcdef0 Amazon

JSON

{
    "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'ServiceBoundariesénoncé de cette politique permet un accès complet aux AWS services 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.

JSON

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

JSON

{
    "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. La CloudWatchLimited déclaration permet à Zhang d'effectuer cinq actions dans CloudWatch. Sa limite d'autorisations autorise toutes les actions CloudWatch, de sorte que ses CloudWatch autorisations effectives ne sont limitées que 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 le 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 les autorisations, Zhang choisit les politiques IAMFulld'accès et d'ReadOnlyAccessautorisations Amazon S3 qui permettent à Nikhil de faire son travail.

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.