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.
Rôles IAM
Un rôle IAM est une identité IAM que vous pouvez créer dans votre compte et qui dispose d'autorisations spécifiques. Un rôle IAM est similaire à un utilisateur IAM, car il s'agit d'une identité AWS avec des politiques d'autorisation qui déterminent ce que l'identité peut et ne peut pas faire dans AWS. En revanche, au lieu d'être associé de manière unique à une personne, un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. En outre, un rôle ne dispose pas d’informations d’identification standard à long terme comme un mot de passe ou des clés d’accès associées. Au lieu de cela, lorsque vous adoptez un rôle, il vous fournit des informations d’identification de sécurité temporaires pour votre session de rôle.
Vous pouvez utiliser des rôles pour déléguer l'accès à des utilisateurs, des applications ou des services qui n'ont normalement pas accès à vos ressources AWS. Par exemple, vous pouvez accorder aux utilisateurs de votre AWS l'accès à des ressources dont ils ne disposent généralement pas, ou accorder aux utilisateurs d'un Compte AWS l'accès aux ressources d'un autre compte. Il est également possible d'autoriser une application mobile à utiliser des ressources AWS, mais sans pour autant intégrer de clés AWS dans l'application (où elles peuvent être difficiles à mettre à jour et d'où les utilisateurs peuvent potentiellement les extraire). Dans certains cas, vous pouvez vouloir accorder l'accès à AWS à des utilisateurs qui ont déjà des identités définies en dehors d'AWS, par exemple dans votre annuaire d'entreprise. Ou, vous pouvez accorder l'accès à votre compte à des tiers afin de leur permettre de réaliser un audit de vos ressources.
Pour de tels scénarios, vous pouvez déléguer l'accès aux ressources AWS à l'aide d'un rôle IAM. Cette section présente les rôles et les différentes façons de les utiliser. Elle explique également quand et comment choisir les diverses approches et comment créer, gérer, prendre (endosser) et supprimer des rôles.
Note
Lorsque vous créez votre Compte AWS pour la première fois, aucun rôle n'est créé par défaut. Au fur et à mesure que vous ajoutez des services à votre compte, ils peuvent ajouter des rôles liés à un service pour répondre à leurs cas d'utilisation.
Un rôle lié à un service est un type de rôle de service lié à un Service AWS. Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service s’affichent dans votre Compte AWS et sont détenus par le service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Avant de pouvoir supprimer les rôles liés à un service, vous devez d'abord supprimer les ressources qui leur sont associées. Vos ressources sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l'autorisation d'accéder aux ressources.
Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez AWS services qui fonctionnent avec IAM et recherchez les services affichant Oui dans la colonne Rôle lié à un service. Choisissez un Yes (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service.
Rubriques
Quand créer un utilisateur IAM (au lieu d'un rôle)
Nous vous recommandons de n'utiliser les utilisateurs IAM que pour les cas d'utilisation non pris en charge par les utilisateurs fédérés. Voici certaines des fonctionnalités les plus utilisées :
-
Charges de travail qui ne peuvent pas utiliser de rôles IAM — Vous pouvez exécuter une charge de travail à partir d'un emplacement qui a besoin d'accéder à AWS. Dans certaines situations, vous ne pouvez pas utiliser les rôles IAM pour fournir des informations d'identification temporaires, comme pour les extensions WordPress. Dans ces situations, utilisez les clés d'accès à long terme de l'utilisateur IAM pour cette charge de travail afin de vous authentifier auprès de AWS.
-
Clients AWS tiers : si vous utilisez des outils qui ne prennent pas en charge l’accès avec IAM Identity Center, tels que des clients AWS tiers ou des fournisseurs qui ne sont pas hébergés sur AWS, utilisez les clés d’accès à long terme pour un utilisateur IAM.
-
AWS CodeCommit accès— Si vous utilisez CodeCommit pour stocker votre code, vous pouvez utiliser un utilisateur IAM avec des clés SSH ou des informations d'identification spécifiques au service pour que CodeCommit puisse s'authentifier auprès de vos référentiels. Nous vous recommandons de procéder ainsi en plus de vous servir d'un utilisateur dans IAM Identity Center pour une authentification ordinaire. Les utilisateurs d'IAM Identity Center sont les personnes de votre personnel qui ont besoin d'accéder à vos Comptes AWS ou à vos applications cloud. Pour permettre aux utilisateurs d'accéder à vos référentiels CodeCommit sans configurer les utilisateurs IAM, vous pouvez configurer l'Utilitaire git-remote-codecommit. Pour plus d'informations sur IAM et CodeCommit, veuillez consulter Informations d’identification IAM pour CodeCommit : informations d’identification Git, clés SSH et clés d’accès AWS. Pour de plus d'informations sur la configuration de l'utilitaire git-remote-codecommit, voir Connexion à AWS CodeCommit référentiels avec rotation des informations d'identification dans le Guide de l'utilisateurAWS CodeCommit.
-
Amazon Keyspaces (for Apache Cassandra) access (Accès Amazon Keyspaces (pour Apache Cassandra)) : dans une situation où vous n'êtes pas en mesure de vous servir des utilisateurs dans IAM Identity Center, par exemple à des fins de test de compatibilité avec Cassandra, vous pouvez utiliser un utilisateur IAM avec des informations d'identification spécifiques au service pour vous authentifier auprès d'Amazon Keyspaces. Les utilisateurs d'IAM Identity Center sont les personnes de votre personnel qui ont besoin d'accéder à vos Comptes AWS ou à vos applications cloud. Vous pouvez également vous connecter à Amazon Keyspaces à l'aide d'informations d'identification temporaires. Pour de plus d'informations, veuillez consulter Utilisation d'informations d'identification temporaires pour se connecter à Amazon Keyspaces à l'aide d'un rôle IAM et du plugin Sigv4 dans le Guide du développeur Amazon Keyspaces (pour Apache Cassandra).
-
Accès d’urgence : dans une situation où vous n’avez pas accès à votre fournisseur d’identité et où vous devez prendre des mesures sur votre Compte AWS. La création d'utilisateurs IAM bénéficiant d'un accès d'urgence peut faire partie de votre plan de résilience. Nous vous recommandons de veiller à ce que les informations d'identification des utilisateurs d'urgence soient étroitement contrôlées et sécurisées à l'aide de l'authentification multifactorielle (MFA).
Termes et concepts relatifs aux rôles
Voici quelques termes de base pour vous aider à vous familiariser avec les rôles.
- Rôle
-
Une identité IAM que vous pouvez créer dans votre compte et qui dispose d'autorisations spécifiques. Un rôle IAM présente des similitudes avec un utilisateur IAM. Les rôles et les utilisateurs sont tous deux des identités AWS avec des politiques d'autorisations qui déterminent ce que l'identité peut ou ne peut pas faire dans AWS. En revanche, au lieu d'être associé de manière unique à une personne, un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. En outre, un rôle ne dispose pas d’informations d’identification standard à long terme comme un mot de passe ou des clés d’accès associées. Au lieu de cela, lorsque vous adoptez un rôle, il vous fournit des informations d’identification de sécurité temporaires pour votre session de rôle.
Les rôles peuvent être endossés par :
-
Un utilisateur IAM du même Compte AWS ou dans un autre Compte AWS
-
Rôles IAM dans le même compte
-
Principaux de service, à utiliser avec les services AWS et les fonctionnalités tels que :
-
Services qui vous permettent d’exécuter du code sur des services de calcul, tels qu’Amazon EC2 ou AWS Lambda
-
Fonctionnalités qui exécutent des actions sur vos ressources en votre nom, comme la réplication d’objets Amazon S3
-
Services fournissant des informations d’identification de sécurité temporaires à vos applications exécutées en dehors d’AWS, telles que Rôles Anywhere IAM ou Amazon ECS Anywhere
-
-
Un utilisateur externe authentifié par un service de fournisseur d’identité (IdP) externe, compatible avec SAML 2.0 ou OpenID Connect.
-
- Rôle de service AWS
-
Un rôle de service est un rôle IAM qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez Création d’un rôle pour la délégation d’autorisations à un Service AWS dans le Guide de l’utilisateur IAM.
- Rôle lié à un service AWS
-
Un rôle lié à un service est un type de rôle de service lié à un Service AWS. Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service s’affichent dans votre Compte AWS et sont détenus par le service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Note
Si vous utilisez déjà un service lorsqu'il commence à prendre en charge des rôles liés à un service, vous pouvez recevoir un e-mail vous informant de l'existence d'un nouveau rôle sur votre compte. Dans ce cas, le service crée automatiquement le rôle lié à un service sur votre compte. Aucune action de votre part n'est requise pour prendre ce rôle en charge et il est préférable de ne pas le supprimer manuellement. Pour plus d’informations, veuillez consulter Un nouveau rôle est apparu dans mon compte AWS.
Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez AWS services qui fonctionnent avec IAM et recherchez les services affichant Oui dans la colonne Rôle lié à un service. Choisissez un Yes (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service. Pour en savoir plus, consultez Créer un rôle lié à un service.
- Création de chaînes de rôles
-
La création de chaînes de rôles se produit lorsque vous utilisez un rôle pour assumer un second rôle via l'interface AWS CLI ou l'API. Par exemple,
RoleA
dispose de l'autorisation d'assumerRoleB
. Vous pouvez permettre à User1 d'assumerRoleA
en utilisant ses informations d'identification d'utilisateur à long terme dans l'opération API AssumeRole. Cette opération renvoie les informations d'identification à court terme deRoleA
. Avec le chaînage de rôles, vous pouvez utiliser les informations d'identification à court terme deRoleA
pour permettre à User1 d'assumerRoleB
.Lorsque vous endossez un rôle, vous pouvez passer une balise de session et la définir comme transitive. Les balises de session transitives sont transmises à toutes les sessions suivantes d'une chaîne de rôles. Pour en savoir plus sur les balises de session, veuillez consulter Transmission des balises de session dans AWS STS.
La création de chaînes de rôles limite votre session de rôle d'AWS CLI ou d'API AWS à une heure maximum. Lorsque vous utilisez l'opération d'API AssumeRole pour endosser un rôle, vous pouvez spécifier la durée de votre session de rôle à l'aide du paramètre
DurationSeconds
. Vous pouvez spécifier une valeur de paramètre jusqu'à 43200 secondes (12 heures), en fonction du paramètre de durée de session maximale de votre rôle. Toutefois, si vous endossez un rôle à l'aide de la création de chaînes de rôles et que vous définissez une valeur de paramètreDurationSeconds
supérieure à une heure, l'opération échoue. - Délégation
-
L'octroi à une personne d'autorisations lui permettant d'accéder aux ressources que vous contrôlez. La délégation implique la mise en place d'une confiance entre deux comptes. Le premier est le compte propriétaire de la ressource (le compte de confiance). Le second est le compte qui contient les utilisateurs qui doivent accéder à la ressource (le compte approuvé). Les comptes d'approbation et approuvés peuvent être :
-
Un même compte.
-
Comptes distincts se trouvant tous deux sous le contrôle de votre organisation.
-
Deux comptes appartenant à des organisations différentes.
Pour déléguer l’autorisation d’accès à une ressource, vous créez un rôle IAM dans le compte d’approbation auquel sont attachées deux politiques. La politique d'autorisation accorde à l'utilisateur du rôle les autorisations nécessaires pour exécuter les tâches prévues sur la ressource. La politique d'approbation détermine les membres du compte autorisés à endosser le rôle.
Lorsque vous créez une politique d'approbation, vous ne pouvez pas spécifier de caractère générique (*) comme ARN dans l'élément de principal. La politique d'approbation est attachée au rôle dans le compte d'approbation, et représente la moitié des autorisations. L'autre moitié est une politique d'autorisation attachée à l'utilisateur dans le compte approuvé qui autorise cet utilisateur à prendre ou endosser le rôle. Un utilisateur qui endosse un rôle temporairement abandonne ses propres autorisations, de manière à adopter celles du rôle. Lorsque l'utilisateur quitte le rôle ou cesse de l'utiliser, ses autorisations d'origine sont restaurées. Un paramètre supplémentaire appelé ID externe permet de sécuriser l'utilisation de rôles entre des comptes qui ne sont pas contrôlés par la même organisation.
-
- Politique d'approbation
-
Document de politique JSON dans lequel vous définissez les principaux en lesquels vous avez confiance pour endosser le rôle. Une politique d'approbation de rôle est une politique basée sur les ressources requise qui est attachée à un rôle dans IAM. Les principaux que vous pouvez spécifier dans la politique d'approbation comprennent les utilisateurs, les rôles, les comptes et les services.
- Rôle pour l'accès entre comptes
-
Un rôle qui octroie l'accès aux ressources d'un compte à un principal approuvé d'un autre compte. Les rôles constituent le principal moyen d’accorder l’accès intercompte. Toutefois, certains services AWS vous permettent d'attacher une politique directement à une ressource (au lieu d'utiliser un rôle en tant que proxy). Il s'agit là de politiques basées sur les ressources que vous pouvez utiliser pour accorder l'autorisation d'accès aux ressources aux principaux d'un autre Compte AWS. Ces ressources incluent notamment les compartiments Amazon Simple Storage Service (S3), les coffres S3 Glacier, les rubriques Amazon Simple Notification Service (SNS) et les files d'attente Amazon Simple Queue Service (SQS). Pour connaître les services qui prennent en charge les politiques basées sur les ressources, veuillez consulter AWS services qui fonctionnent avec IAM. Pour plus d'informations sur les politiques basées sur les ressources, consultez Accès intercompte aux ressources dans IAM.
Ressources supplémentaires
Les ressources suivantes peuvent vous aider à en savoir plus sur la terminologie IAM relative aux rôles IAM.
-
Les principaux sont des entités dans AWS qui peuvent exécuter des actions et accéder à des ressources. Un principal peut être un Utilisateur racine d'un compte AWS, un utilisateur IAM ou un rôle. Un principal qui représente l’identité d’un service AWS est un principal de service. Utilisez l’élément Principal dans les politiques d’approbation des rôles pour définir les principaux auxquels vous faites confiance pour assumer le rôle.
Pour plus d’informations et des exemples de principaux que vous pouvez autoriser à assumer un rôle, consultez AWS JSONéléments de politique : Principal.
-
La fédération d’identité crée une relation d’approbation entre un fournisseur d’identité externe et AWS. Vous pouvez utiliser votre fournisseur OpenID Connect (OIDC) ou Security Assertion Markup Language (SAML) 2.0 pour gérer les utilisateurs autorisés à accéder aux ressources AWS. Lorsque vous utilisez OIDC et SAML 2.0 pour configurer une relation d’approbation entre ces fournisseurs d’identité externes et AWS, l’utilisateur est affecté à un rôle IAM. L'utilisateur reçoit également des informations d'identification temporaires qui lui permettent d'accéder à vos ressources AWS.
Pour de plus amples informations sur les utilisateurs fédérés, veuillez consulter Fournisseurs d'identité et fédération.
-
Les utilisateurs fédérés sont des identités d’utilisateur préexistantes provenant d’AWS Directory Service, de l’annuaire des utilisateurs de votre entreprise ou d’un fournisseur OIDC. On parle alors d'utilisateurs fédérés. AWS attribue un rôle à un utilisateur fédéré lorsque l'accès est demandé via un fournisseur d'identité.
Pour de plus amples informations sur les utilisateurs fédérés, veuillez consulter Utilisateurs fédérés et rôles.
-
Les politiques d’autorisation sont des politiques basées sur l’identité qui définissent les actions et les ressources que le rôle peut utiliser. Le document est écrit conformément aux règles du langage de politique IAM.
Pour en savoir plus, consultez Référence de politique JSON IAM.
-
Les limites des autorisations sont une fonctionnalité avancée dans laquelle vous utilisez des politiques pour limiter les autorisations maximales qu’une politique basée sur l’identité peut accorder à un rôle. Vous ne pouvez pas appliquer une limite d'autorisations à un rôle lié à un service.
Pour en savoir plus, consultez Limites d'autorisations pour les entités IAM.