Ce qu'est réellement un rôle IAM

Un rôle IAM est une identité que vous pouvez endosser pour recevoir un ensemble de permissions, mais, contrairement à un utilisateur, il ne possède aucun identifiant permanent. Lorsqu’une entité endosse un rôle, AWS lui attribue à la place des identifiants de sécurité temporaires qui expirent après une durée définie. Les rôles constituent la méthode sécurisée et moderne pour accorder des accès sur AWS et apparaissent partout dans l’examen SCS-C02.

Chaque rôle comporte deux parties de politique :

• Une politique de confiance (également appelée politique d’endossement du rôle), qui indique qui est autorisé à endosser le rôle.
• Une ou plusieurs politiques de permissions, qui indiquent ce que le rôle peut faire une fois endossé.

Cette séparation est au cœur de la délégation sécurisée permise par les rôles : vous décidez qui peut emprunter l’identité et, séparément, ce que cette identité peut faire.

Lorsqu’un rôle est endossé, le Security Token Service (STS) émet un ensemble d’identifiants contenant un ID de clé d’accès, une clé secrète et un jeton de session, tous valables pendant une durée limitée (de 15 minutes à 12 heures). Comme ils expirent automatiquement, des identifiants temporaires divulgués deviennent rapidement inutiles, ce qui réduit considérablement le risque par rapport aux clés d’accès à longue durée de vie.

La politique de confiance répertorie les principals qui peuvent endosser le rôle. Il peut s’agir :

• D’un service AWS (tel qu’EC2 ou Lambda), afin de donner une identité à une charge de travail.
• D’un utilisateur ou rôle IAM du même compte ou d’un autre compte, pour un accès intercomptes.
• D’une identité fédérée provenant d’un fournisseur SAML ou OIDC.

Si un principal n’est pas nommé dans la politique de confiance, il ne pourra jamais endosser le rôle, quelles que soient les permissions accordées par les politiques de permissions.

L’utilisation la plus courante consiste à permettre à un service AWS d’agir en votre nom. Par exemple, une instance EC2 à laquelle est associé un rôle peut appeler S3 sans aucune clé intégrée ; AWS renouvelle automatiquement les identifiants en arrière-plan. L’examen attend de vous que vous reconnaissiez que les rôles de service éliminent les secrets statiques de vos applications.

Voici un extrait de politique de confiance qui permet au service EC2 d’endosser un rôle. L’élément Principal identifie qui peut l’endosser, et l’action est toujours sts:AssumeRole.

Les rôles sont particulièrement adaptés à l’accès intercomptes. Le compte A crée un rôle qui fait confiance au compte B ; un principal du compte B l’endosse et reçoit des identifiants temporaires pour agir dans le compte A. Aucune clé n’est partagée, l’accès est limité par la politique de permissions et chaque partie peut révoquer la confiance à tout moment. C’est l’alternative recommandée à la distribution de clés à longue durée de vie entre les comptes.

Les identités externes, telles que les utilisateurs d’une entreprise authentifiés par SAML ou les utilisateurs d’une application via la fédération d’identités Web, endossent elles aussi des rôles. Le fournisseur d’identité vérifie l’utilisateur, puis AWS émet des identifiants temporaires associés à un rôle. Ainsi, les personnes n’ont jamais besoin d’utilisateurs IAM : seule une identité vérifiée correspondant à un rôle est nécessaire.

Le principal avantage des rôles en matière de sécurité est l’absence d’identifiants permanents à voler, à renouveler ou à valider accidentellement dans un dépôt de code. Les permissions n’existent que pendant une session temporaire. Cela respecte le principe du moindre privilège dans le temps : l’accès est accordé uniquement lorsque cela est nécessaire et expire de lui-même.

Un point subtil : être autorisé à endosser un rôle vous accorde uniquement les permissions de ce rôle, et non vos permissions combinées à celles du rôle. Lorsque vous endossez un rôle, vous adoptez une nouvelle identité. Vos permissions initiales sont mises de côté pour cette session : la conception du rôle doit donc inclure tout ce dont la tâche a besoin.

Utilisez un rôle dès qu’une charge de travail a besoin d’accéder à AWS, lorsqu’un compte doit agir dans un autre ou lorsque des personnes s’authentifient auprès d’un fournisseur externe. Les rôles sont la réponse à presque toutes les questions de l’examen du type « comment accorder un accès sans clés à longue durée de vie ? ». Ils associent une politique de confiance (qui) à des politiques de permissions (quoi) pour fournir un accès sécurisé, temporaire et auditable.

Vérifiez votre compréhension des rôles.

Un rôle IAM est une identité sans identifiants, endossée pour obtenir des permissions temporaires auprès de STS. Il associe une politique de confiance (qui peut l’endosser) à des politiques de permissions (ce qu’il peut faire). Les rôles permettent l’accès aux services, la délégation intercomptes et la fédération, tout en éliminant les secrets à longue durée de vie. Endosser un rôle remplace votre identité par celle du rôle pendant la session.