Termes et concepts relatifs aux rôles - AWS Identity and Access Management

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 utilisés par :

  • Un utilisateur IAM qui appartient au même compte AWS que le rôle

  • Un utilisateur IAM dans un compte AWS différent de celui du rôle

  • Un service web proposé par AWS, par exemple Amazon Elastic Compute Cloud (Amazon EC2)

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

Rôle de service AWS

Un rôle qu'un service endosse pour effectuer des actions dans votre compte en votre nom. Lorsque vous configurez certains environnements de services AWS, vous devez définir un rôle que ce service devra endosser. Ce rôle de service doit comprendre toutes les autorisations nécessaires pour que le service puisse accéder aux ressources AWS dont il a besoin. Les rôles de service varient d'un service à un service, mais nombre d'entre eux vous permettent de choisir vos autorisations, tant que vous respectez les exigences documentées pour le service en question. Vous pouvez créer, modifier et supprimer un rôle de service depuis IAM.

Rôle de service AWS pour une instance EC2

Un genre particulier de rôle de service qu'une application s'exécutant sur une instance Amazon EC2 peut endosser pour effectuer des actions dans votre compte. Ce rôle est attribué à l'instance EC2 lorsque vous la lancez. Des applications exécutées sur cette instance peuvent récupérer des informations d'identification de sécurité temporaires et effectuer des actions permises par le rôle. Pour plus d'informations sur l'utilisation d'un rôle de service pour une instance EC2, consultez Utilisation d'un rôle IAM pour accorder des autorisations à des applications s'exécutant sur des instances Amazon EC2.

Rôle lié à un service AWS

Un genre unique de rôle de service directement lié à un service AWS. Les rôles liés à un service sont prédéfinis par le service et comprennent toutes les autorisations nécessaires au service pour appeler d'autres services AWS en votre nom. Le service lié définit aussi la manière dont vous créez, modifiez et supprimez un rôle lié à un service. Un service peut créer ou supprimer automatiquement le rôle. Il peut vous permettre de créer, modifier ou supprimer le rôle dans le cadre des opérations d'un assistant ou d'un processus du service. Ou il peut vous demander d'utiliser IAM pour créer ou supprimer le rôle. Quelle que soit la méthode, les rôles liés à un service simplifient la configuration d'un service étant donné que vous n'avez pas besoin d'ajouter manuellement les autorisations requises.

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 Services AWS 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. Si le service ne comprend pas de documentation pour créer, modifier ou supprimer le rôle lié à un service, vous pouvez alors utiliser la console IAM, la AWS CLI ou l'API. Pour plus d’informations, veuillez consulter Utilisation des rôles liés à 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'assumer RoleB. Vous pouvez permettre à User1 d'assumer RoleA 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 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 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ètre DurationSeconds supérieure à une heure, l'opération échoue.

AWS ne traite pas l'utilisation de rôles pour accorder des autorisations aux applications qui s'exécutent sur des instances EC2 comme chaînage de rôles.

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

Fédération

La création d'une relation d'approbation entre un fournisseur d'identité externe et AWS. Les utilisateurs peuvent se connecter à un fournisseur d'identité Web tel que Login with Amazon, Facebook, Google, ou tout autre fournisseur d'identité compatible avec OpenID Connect (OIDC). Ils peuvent également se connecter à un système d'identité d'entreprise compatible avec SAML (Security Assertion Markup Language) 2.0 tel que les services ADFS (Active Directory Federation Services) de Microsoft. 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.

Utilisateur fédéré

Au lieu de créer un utilisateur IAM, vous pouvez utiliser des identités d'utilisateur préexistantes provenant d'AWS Directory Service, de l'annuaire d'utilisateurs de votre entreprise ou d'un fournisseur d'identité web. 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 plus d'informations sur les utilisateurs fédérés, consultez Utilisateurs fédérés et rôles dans le Guide de l'utilisateur IAM.

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.

Politique d'autorisations

Un document d'autorisations au format JSON dans lequel vous définissez les actions et ressources que le rôle peut utiliser. Le document est écrit conformément aux règles du langage de politique IAM.

Limite d'autorisations

Une fonction avancée dans laquelle vous utilisez des politiques pour limiter les autorisations maximales qu'une politique basée sur les identités peut accorder à un rôle. Vous ne pouvez pas appliquer une limite d'autorisations à un rôle lié à un service. Pour plus d’informations, veuillez consulter Limites d'autorisations pour les entités IAM.

Principal

Une entité de AWS qui peut exécuter des actions et accéder à des ressources. Un principal peut être un utilisateur racine Compte AWS, un utilisateur IAM ou un rôle. Vous pouvez accorder des autorisations d'accès à une ressource de l'une des façons suivantes :

  • Vous pouvez attacher une politique d'autorisation à un utilisateur (directement, ou indirectement via un groupe) ou à un rôle.

  • Pour les services qui prennent en charge les politiques basées sur les ressources, vous pouvez identifier le principal dans l'élément Principal d'une politique attachée à la ressource.

Si vous référencez un compte AWS en tant que principal, il s'agit généralement de n'importe quel principal défini dans ce compte.

Note

Vous ne pouvez pas utiliser de caractère générique (*) dans l'élément Principal d'une politique d'approbation d'un rôle.

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 entre plusieurs comptes. 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 Services AWS qui fonctionnent avec IAM. Pour plus d'informations sur les politiques basées sur les ressources, consultez Différence entre les rôles IAM et les politiques basées sur les ressources.