IAMrôles - AWS Gestion de l’identité et des accès

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.

IAMrôles

Un IAM rôle est une IAM identité que vous pouvez créer dans votre compte et qui dispose d'autorisations spécifiques. Un IAM rôle est similaire à un IAM utilisateur, dans la mesure où il s'agit d'une AWS identité dotée de politiques d'autorisation qui déterminent ce que l'identité peut et ne peut pas faire 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 AWS ressources. Par exemple, vous pouvez autoriser les utilisateurs de votre AWS compte à accéder à des ressources dont ils ne disposent pas habituellement, ou autoriser les utilisateurs d'un compte à Compte AWS accéder aux ressources d'un autre compte. Vous pouvez également autoriser une application mobile à utiliser AWS des ressources, mais ne pas intégrer de AWS clés dans l'application (où elles peuvent être difficiles à mettre à jour et où les utilisateurs peuvent éventuellement les extraire). Parfois, vous souhaitez donner AWS accès à des utilisateurs dont l'identité est déjà définie à l'extérieur AWS, par exemple dans le répertoire de votre 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 ces scénarios, vous pouvez déléguer l'accès aux AWS ressources à l'aide d'un IAMrôle. 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, 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 apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un IAM administrateur peut consulter, mais pas modifier les autorisations pour 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 des 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.

Quand créer un IAM utilisateur (au lieu d'un rôle)

Nous vous recommandons de n'utiliser des IAM utilisateurs 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 ne pouvant pas utiliser de IAM rôles : vous pouvez exécuter une charge de travail à partir d'un emplacement nécessitant un accès AWS. Dans certains cas, vous ne pouvez pas utiliser de IAM rôles pour fournir des informations d'identification temporaires, par exemple pour les WordPress plug-ins. Dans ces situations, utilisez les clés d'accès à long terme de l'IAMutilisateur auprès desquelles cette charge de travail doit s'authentifier AWS.

  • AWS Clients tiers : si vous utilisez des outils qui ne prennent pas en charge l'accès avec IAM Identity Center, tels que des AWS clients tiers ou des fournisseurs qui ne sont pas hébergés sur Identity Center AWS, utilisez les clés d'accès à long terme des IAM utilisateurs.

  • AWS CodeCommit accès — Si vous avez l'habitude de CodeCommit stocker votre code, vous pouvez utiliser un IAM utilisateur possédant des SSH clés ou des informations d'identification spécifiques au service pour vous authentifier CodeCommit auprès de vos référentiels. Nous vous recommandons de le faire en plus d'utiliser un utilisateur dans IAM Identity Center pour une authentification normale. Les utilisateurs d'IAMIdentity Center sont les membres de votre personnel qui ont besoin d'accéder à vos applications cloud Comptes AWS ou à celles de celles-ci. Pour permettre aux utilisateurs d'accéder à vos CodeCommit référentiels sans configurer IAM les utilisateurs, vous pouvez configurer l'git-remote-codecommitutilitaire. Pour plus d'informations sur IAM et CodeCommit, voirIAMinformations d'identification pour CodeCommit : informations d'identification, SSH clés et clés AWS d'accès Git. Pour plus d'informations sur la configuration de l'git-remote-codecommitutilitaire, consultez la section Connexion aux AWS CodeCommit référentiels avec des informations d'identification rotatives dans le Guide de AWS CodeCommit l'utilisateur.

  • Accès à Amazon Keyspaces (pour Apache Cassandra) : si vous ne parvenez pas à utiliser des utilisateurs dans IAM Identity Center, par exemple à des fins de test de compatibilité avec Cassandra, vous pouvez utiliser un IAM utilisateur possédant des informations d'identification spécifiques au service pour vous authentifier auprès d'Amazon Keyspaces. Les utilisateurs d'IAMIdentity Center sont les membres de votre personnel qui ont besoin d'accéder à vos applications cloud Comptes AWS ou à celles de celles-ci. Vous pouvez également vous connecter à Amazon Keyspaces à l'aide d'informations d'identification temporaires. Pour plus d'informations, consultez les sections Utilisation d'informations d'identification temporaires pour vous connecter à Amazon Keyspaces à l'aide d'un IAM rôle et du plug-in 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 définition d'IAMutilisateurs d'accès d'urgence peut faire partie de votre plan de résilience. Nous recommandons de contrôler et de sécuriser étroitement les informations d'identification des utilisateurs en cas d'urgence à 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

IAMIdentité que vous pouvez créer dans votre compte et qui possède des autorisations spécifiques. Un IAM rôle présente certaines similitudes avec un IAM utilisateur. 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 assumés de la manière suivante :

  • Un IAM utilisateur du même nom Compte AWS ou d'un autre Compte AWS

  • IAMrôles dans le même compte

  • Principes de service, à utiliser avec des AWS services et des fonctionnalités tels que :

    • Services qui vous permettent d'exécuter du code sur des services informatiques, 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 de AWS, telles que IAM Roles Anywhere ou Amazon ECS Anywhere

  • Un utilisateur externe authentifié par un service de fournisseur d'identité externe (IdP) compatible SAML avec la version 2.0 ou OpenID Connect

AWS rôle de service

Un rôle de service est un IAMrôle qu'un service assume pour effectuer des actions en votre nom. Un IAM administrateur peut créer, modifier et supprimer un rôle de service de l'intérieurIAM. Pour plus d'informations, consultez la section Création d'un rôle auquel déléguer des autorisations Service AWS dans le Guide de IAM l'utilisateur.

AWS rôle lié au service

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 apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un IAM administrateur peut consulter, mais pas modifier les autorisations pour 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 des 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 de plus amples informations, veuillez consulter Créer un rôle lié à un service.

Création de chaînes de rôles

Le chaînage des rôles se produit lorsque vous utilisez un rôle pour assumer un second rôle par le biais du AWS CLI ouAPI. Par exemple, RoleA dispose de l'autorisation d'assumer RoleB. Vous pouvez autoriser User1 à assumer RoleA en utilisant ses informations d'identification utilisateur à long terme lors de l' AssumeRole APIopération. Cette opération renvoie les informations d'identification à court terme de RoleA. Avec le chaînage de rôles, vous pouvez utiliser les informations d'identification à court terme de RoleA pour permettre à User1 d'assumer RoleB.

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 Transmettez les tags de session AWS STS.

Le chaînage des rôles limite votre session AWS CLI ou celle des AWS API rôles à un maximum d'une heure. Lorsque vous utilisez l'AssumeRoleAPIopération pour assumer un rôle, vous pouvez spécifier la durée de votre session de rôle à l'aide du DurationSeconds paramètre. 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ètre DurationSeconds 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éder à une ressource, vous créez un IAM rôle dans le compte de confiance auquel deux politiques sont associées. 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 de confiance, vous ne pouvez pas spécifier de caractère générique (*) ARN dans et dans l'élément 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 JSON politique dans lequel vous définissez les principes auxquels vous faites confiance pour assumer le rôle. Une politique de confiance dans les rôles est une stratégie basée sur les ressources requise 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. Cependant, certains AWS services vous permettent d'associer une politique directement à une ressource (au lieu d'utiliser un rôle comme proxy). C'est ce que l'on appelle des politiques basées sur les ressources, et vous pouvez les utiliser pour accorder aux principaux un autre Compte AWS accès à la ressource. Certaines de ces ressources incluent les compartiments Amazon Simple Storage Service (S3), les coffres-forts 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 des services qui fonctionnent avec IAM. Pour plus d'informations sur les politiques basées sur les ressources, consultez Accès aux ressources entre comptes dans IAM.

Ressources supplémentaires

Les ressources suivantes peuvent vous aider à en savoir plus sur IAM la terminologie relative aux IAM rôles.

  • Les principaux sont des entités AWS qui peuvent effectuer des actions et accéder aux ressources. Un principal peut être un Utilisateur racine d'un compte AWS, un IAM utilisateur ou un rôle. Un principal qui représente l'identité d'un AWS service est un principal de service. Utilisez l'élément Principal dans les politiques de confiance 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 directeurs que vous pouvez autoriser à assumer un rôle, consultezAWS JSONéléments de politique : Principal.

  • La fédération d'identité crée une relation de confiance entre un fournisseur d'identité externe et AWS. Vous pouvez utiliser votre fournisseur OpenID Connect (OIDC) ou Security Assertion Markup Language (SAML) 2.0 existant pour gérer les personnes autorisées à accéder aux ressources. AWS Lorsque vous utilisez OIDC et SAML 2.0 pour configurer une relation de confiance entre ces fournisseurs d'identité externes et AWS , un IAM rôle est attribué à l'utilisateur. 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 existantes provenant de AWS Directory Service l'annuaire des utilisateurs de votre entreprise ou d'un OIDC fournisseur. Ils sont appelés utilisateurs fédérés. AWS attribue un rôle à un utilisateur fédéré lorsque l'accès est demandé par le biais d'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 rédigé conformément aux règles du langage IAM politique.

    Pour de plus amples informations, veuillez consulter IAMJSONréférence politique.

  • Les limites d'autorisations sont une fonctionnalité avancée dans laquelle vous utilisez des politiques pour limiter le maximum d'autorisations 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 de plus amples informations, veuillez consulter Limites d'autorisations pour des entités IAM.