Autorisations requises pour accéder aux autres ressources IAM

Les ressources sont des objets au sein d'un service. IAMles ressources incluent les groupes, les utilisateurs, les rôles et les politiques. Si vous êtes connecté avec Utilisateur racine d'un compte AWS informations d'identification, vous n'avez aucune restriction quant à l'administration des IAM informations d'identification ou IAM des ressources. Toutefois, IAM les utilisateurs doivent être explicitement autorisés à administrer les informations d'identification ou IAM les ressources. Pour ce faire, vous pouvez attacher une politique basée sur les identités à l'utilisateur.

Note

Tout au long du AWS documentation, lorsque nous faisons référence à une IAM politique sans mentionner aucune des catégories spécifiques, nous entendons une politique basée sur l'identité et gérée par le client. Pour de plus amples informations sur les catégories de politique, veuillez consulter Politiques et autorisations dans AWS Identity and Access Management.

Autorisations pour la gestion des identités IAM

Les autorisations requises pour administrer les IAM groupes, les utilisateurs, les rôles et les informations d'identification correspondent généralement aux API actions de la tâche. Par exemple, pour créer des IAM utilisateurs, vous devez disposer de l'iam:CreateUserautorisation associée à la API commande correspondante : CreateUser. Pour permettre à un IAM utilisateur de créer d'autres IAM utilisateurs, vous pouvez associer une IAM politique telle que la suivante à cet utilisateur :

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

Dans une politique, la valeur de l'élément Resource dépend de l'action et des ressources que cette action peut affecter. Dans l'exemple précédent, la politique autorise un utilisateur à créer un autre utilisateur (* est un caractère générique qui correspond à toutes les chaînes). En revanche, une politique qui permet aux utilisateurs de modifier uniquement leurs propres clés d'accès (APIactions CreateAccessKeyet UpdateAccessKey) comporte généralement un Resource élément. Dans ce cas, il ARN inclut une variable (${aws:username}) qui correspond au nom de l'utilisateur actuel, comme dans l'exemple suivant :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListUsersForConsole",
            "Effect": "Allow",
            "Action": "iam:ListUsers",
            "Resource": "arn:aws:iam::*:*"
        },
        {
            "Sid": "ViewAndUpdateAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:UpdateAccessKey",
                "iam:CreateAccessKey",
                "iam:ListAccessKeys"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}

Dans l'exemple précédent, ${aws:username} est une variable qui renvoie au nom utilisateur de l'utilisateur actuel. Pour de plus amples informations sur les variables de politique, veuillez consulter Éléments des stratégies IAM : variables et balises.

L'utilisation d'un caractère générique (*) dans le nom d'action facilite souvent l'octroi d'autorisations pour toutes les actions associées à une tâche spécifique. Par exemple, pour permettre aux utilisateurs d'effectuer n'importe quelle IAM action, vous pouvez utiliser iam:* pour l'action. Pour autoriser les utilisateurs à effectuer n'importe quelle action associée uniquement aux clés d'accès, vous pouvez utiliser iam:*AccessKey* dans l'élément Action d'une instruction de politique. Cela permet d'accorder à l'utilisateur l'autorisation d'effectuer les actions CreateAccessKey, DeleteAccessKey, GetAccessKeyLastUsed, ListAccessKeys et UpdateAccessKey. (Si une action dont le nom contient « AccessKey » est ajoutée dans le futur, l'utilisation iam:*AccessKey* de l'Actionélément donnera également à l'utilisateur l'autorisation d'effectuer cette nouvelle action.) IAM L'exemple suivant montre une politique qui permet aux utilisateurs d'effectuer toutes les actions relatives à leurs propres clés d'accès (remplacez-les account-id par votre Compte AWS IDENTIFIANT) :

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:*AccessKey*",
    "Resource": "arn:aws:iam::account-id:user/${aws:username}"
  }
}

Certaines tâches, comme la suppression d'un groupe, impliquent plusieurs actions : vous devez d'abord supprimer les utilisateurs du groupe, puis détacher ou supprimer les stratégie du groupe et enfin supprimer réellement le groupe. Si vous souhaitez qu'un utilisateur supprime un groupe, vous devez vous assurer d'accorder à celui-ci les autorisations nécessaires pour exécuter toutes les actions associées.

Autorisations pour travailler dans AWS Management Console

Les exemples précédents montrent les politiques qui permettent à un utilisateur d'effectuer les actions avec AWS CLIou le AWS SDKs.

Lorsque les utilisateurs utilisent la console, celle-ci émet des demandes pour IAM répertorier les groupes, les utilisateurs, les rôles et les politiques, et pour obtenir les politiques associées à un groupe, à un utilisateur ou à un rôle. La console émet également des demandes pour obtenir Compte AWS des informations et des informations sur le mandant. Le principal est l'utilisateur qui effectue les demandes sur la console.

En général, pour effectuer une action, vous devez posséder uniquement l'action correspondante dans une politique. Pour pouvoir créer un utilisateur, vous devez disposer d'une autorisation pour appeler l'action CreateUser. Souvent, lorsque vous utilisez la console pour effectuer une action, vous devez avoir les autorisations pour afficher, répertorier, obtenir, ou encore afficher les ressources sur la console. Ceci est nécessaire pour vous permettre de naviguer au sein de la console pour effectuer l'action spécifiée. Par exemple, si l'utilisateur Jorge souhaite utiliser la console pour modifier ses propres clés d'accès, il accède à la IAM console et choisit Utilisateurs. Cette action indique à la console d'effectuer une demande ListUsers. Si Jorge n'a pas l'autorisation d'exécuter l'action iam:ListUsers, la console se voit refuser l'accès lorsqu'elle essaie de répertorier les utilisateurs. Par conséquent, Jorge ne peut accéder à son propre nom et à ses propres clés d'accès, même s'il a l'autorisation d'exécuter les actions CreateAccessKey et UpdateAccessKey.

Si vous souhaitez autoriser les utilisateurs à administrer des groupes, des utilisateurs, des rôles, des politiques et des informations d'identification avec AWS Management Console, vous devez inclure des autorisations pour les actions effectuées par la console. Pour obtenir des exemples de politiques que vous pouvez utiliser pour accorder ces autorisations à un utilisateur, consultez Exemples de politiques de gestion de ressources IAM.

Accordez des autorisations à travers AWS comptes

Vous pouvez directement autoriser IAM les utilisateurs de votre propre compte à accéder à vos ressources. Si les utilisateurs d'un autre compte ont besoin d'accéder à vos ressources, vous pouvez créer un IAM rôle, c'est-à-dire une entité qui inclut des autorisations mais qui n'est pas associée à un utilisateur spécifique. Les utilisateurs d'autres comptes peuvent alors utiliser le rôle et accéder aux ressources selon les autorisations que vous avez attribuées à ce rôle. Pour de plus amples informations, veuillez consulter Accès pour un IAM utilisateur à un autre utilisateur Compte AWS que vous possédez.

Note

Certains services prennent en charge les politiques basées sur les ressources, comme décrit dans Politiques basées sur l'identité et Politiques basées sur une ressource (Amazon S3, Amazon et Amazon SNSSQS, par exemple). Pour ces services, une alternative à l'utilisation de rôles consiste à attacher une politique à la ressource (compartiment, rubrique ou file d'attente) que vous voulez partager. La politique basée sur les ressources peut spécifier AWS compte autorisé à accéder à la ressource.

Autorisations pour qu'un service accède à un autre service

Nombreux AWS services, accès, autres AWS services. Par exemple, plusieurs AWS les services, notamment AmazonEMR, Elastic Load Balancing et Amazon EC2 Auto Scaling, gèrent les instances Amazon. EC2 Autre AWS les services utilisent les compartiments Amazon S3, les SNS rubriques Amazon, les SQS files d'attente Amazon, etc.

Le scénario pour gérer des autorisations dans ces cas varie selon le service. Voici des exemples de la façon dont les autorisations sont gérées pour différents services :

• Dans Amazon EC2 Auto Scaling, les utilisateurs doivent être autorisés à utiliser Auto Scaling, mais ils n'ont pas besoin d'une autorisation explicite pour gérer les EC2 instances Amazon.

• Entrée AWS Data Pipeline, un IAM rôle détermine ce que peut faire un pipeline ; les utilisateurs ont besoin d'une autorisation pour assumer ce rôle. (Pour plus de détails, consultez la section Octroi d'autorisations aux pipelines IAM dans le AWS Data Pipeline Guide du développeur.)

Pour plus de détails sur la manière de configurer correctement les autorisations afin qu'un AWS le service est capable d'accomplir les tâches que vous souhaitez, reportez-vous à la documentation du service que vous appelez. Pour savoir comment créer un rôle pour un service, consultez Création d'un rôle pour déléguer des autorisations à un AWS service.

Configuration d'un service doté d'un IAM rôle pour travailler en votre nom

Lorsque vous souhaitez configurer un AWS service pour travailler en votre nom, vous fournissez généralement un IAM rôle qui définit ce que le service est autorisé à faire. ARN AWS vérifie que vous êtes autorisé à transmettre un rôle à un service. Pour de plus amples informations, veuillez consulter Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service.

Actions requises

Les actions sont les choses que vous pouvez faire sur une ressource, comme l'affichage, la création, l'édition et la suppression de cette ressource. Les actions sont définies par chacun AWS service.

Pour autoriser une personne à effectuer une action, vous devez inclure les actions nécessaires dans une politique qui s'applique à l'identité appelante ou à la ressource affectée. En général, pour fournir l'autorisation requise pour effectuer une action, vous devez inclure cette action dans votre politique. Par exemple, pour créer un utilisateur, vous devez ajouter l' CreateUser action à votre politique.

Dans certains cas, une action peut exiger l'inclusion d'actions connexes supplémentaires dans votre politique. Par exemple, pour autoriser quelqu'un à créer un répertoire dans AWS Directory Service à l'aide de l'ds:CreateDirectoryopération, vous devez inclure les actions suivantes dans leur politique :

• ds:CreateDirectory

• ec2:DescribeSubnets

• ec2:DescribeVpcs

• ec2:CreateSecurityGroup

• ec2:CreateNetworkInterface

• ec2:DescribeNetworkInterfaces

• ec2:AuthorizeSecurityGroupIngress

• ec2:AuthorizeSecurityGroupEgress

Lorsque vous créez ou éditez une politique à l'aide de l'éditeur visuel, vous recevez des avertissements et des instructions pour vous aider à choisir toutes les actions requises pour votre politique.

Pour plus d'informations sur les autorisations requises pour créer un répertoire dans AWS Directory Service, voir Exemple 2 : Autoriser un utilisateur à créer un annuaire.