Les utilisateurs et les rôles IAM vous permettent tous deux de gérer l'accès à vos ressources AWS avec des ensembles d'autorisations spécifiques, mais les deux types d'accès IAM sont utilisés différemment dans la pratique. Dans cet article, nous expliquons les différences et comment les utiliser.

Les utilisateurs sont externes (utilisés pour les personnes)

La différence fondamentale entre les utilisateurs et les rôles IAM réside dans la provenance de l'accès autorisé.

• Les utilisateurs IAM autorisent l'accès externe à vos ressources AWS. Vous utilisez ces ressources pour donner aux employés l'accès à AWS Management Console et pour authentifier l'interface de ligne de commande exécutée sur leurs machines. Les utilisateurs IAM donnent un accès direct aux services à l'aide des jetons de sécurité donnés.
• Les rôles IAM sont uniquement destinés à un usage interne et vous pouvez attribuer des éléments tels que les instances EC2 et les fonctions Lambda pour leur permettre de faire leur travail efficacement. Les rôles ne donnent aucun accès par eux-mêmes, mais ils permettent aux services d'agir comme s'ils disposaient de certaines autorisations.

Avec cela à l'écart, parlons des utilisateurs IAM, le plus simple des deux. Ils présentent un moyen fantastique de gérer l'accès pour tout, des comptes de service aux vrais employés. Avec Users, vous recevez un ID de clé d'accès et une clé d'accès secrète, qui sont utilisés pour authentifier l'AWS CLI. Vous pouvez faire assumer un rôle à la CLI une fois que vous êtes authentifié, mais vous avez toujours besoin d'un compte utilisateur IAM avec l'autorisation de le faire (à l'exception des instances EC2, nous en parlerons plus tard).

Vous pouvez également donner accès à AWS Management Console (l'interface graphique Web), ce qui rend les utilisateurs IAM parfaits pour les employés. Vous devez toujours donner les bonnes autorisations, sinon la console générera de nombreuses erreurs, mais la possibilité d'utiliser la console est cruciale.

Vous pouvez ajouter des utilisateurs IAM à des groupes plutôt que de spécifier directement des autorisations, ce qui vous permet de gérer plus facilement les différents rôles de votre organisation.

Cependant, les utilisateurs présentent quelques problèmes dans la pratique. La première est que pour authentifier une application exécutée sur EC2, vous devez laisser les clés d'accès sur cette instance. Ce n’est pas aussi grave que de laisser vos clés d’accès root, mais c’est toujours un problème de sécurité qui n’a pas besoin d’exister. Le problème est particulièrement grave si l'on considère que cela peut permettre aux employés d'élever leurs privilèges; si une application s'exécute avec des privilèges plus élevés et stocke ses clés sur le disque, l'employé peut voler et utiliser ces clés, ce qui n'est pas idéal.

Le deuxième problème est que les utilisateurs IAM permettent d'accéder à vos ressources AWS à partir de nulle part, même en dehors d'AWS. Cela est nécessaire pour les comptes d'employés, mais pas pour les applications qui s'exécutent déjà dans AWS.

Les rôles sont censés être assumés par des entités autorisées

La solution aux problèmes avec les utilisateurs est résolue par les rôles. Les rôles sont essentiellement les mêmes que ceux des utilisateurs, mais sans les clés d'accès ni l'accès à la console de gestion. Il s’agit essentiellement d’un ensemble d’autorisations pouvant être accordées à différents services.

Par exemple, un problème courant est que les services d'authentification doivent pouvoir télécharger des objets vers S3. Au lieu de créer un compte utilisateur, qui laisserait des clés secrètes sur votre serveur EC2 (et toutes les AMI personnalisées que vous avez configurées) et activerait l'accès externe, vous créez à la place un rôle qui autorise l'accès S3, tel que «S3Uploader».

Vous pouvez attribuer ce rôle à une fonction Lambda lui permettant de placer des objets dans votre compartiment, ou vous pouvez l'attribuer directement à une instance EC2. Le service auquel un rôle est attribué est ensuite autorisé à accéder aux ressources qui lui ont été attribuées, mais cela ne pose pas de risque pour la sécurité. De nombreux services AWS créent des rôles par défaut pour fonctionner, de sorte que votre console IAM peut déjà en avoir un certain nombre.

Les rôles peuvent également être utilisés par les utilisateurs pour activer l'élévation des privilèges gérés. Un employé peut assumer un rôle (qui est connecté dans CloudTrail), en leur accordant les autorisations de ce rôle pendant une courte période. Cela permet à l'utilisateur de demander des informations d'identification à court terme à AWS STS, ce qui est plus sûr que d'attacher les autorisations directement aux clés d'accès de l'utilisateur.

L'ajout de rôles aux instances EC2 est très utile. Vous pouvez ajouter un rôle à une instance à partir du Console de gestion EC2 en faisant un clic droit sur une instance et en sélectionnant «Paramètres d'instance»> «Joindre / Remplacer le rôle IAM»:

Vous pouvez également spécifier le rôle dans un modèle de lancement ou une configuration de lancement. Chaque instance (et la plupart des services) ne peut avoir qu'un seul rôle, mais vous pouvez attacher n'importe quel nombre de stratégies au rôle lui-même.

L'AWS CLI utilise automatiquement le rôle pour l'instance donnée, donc aucune configuration n'est requise. Si vous souhaitez passer manuellement à un rôle, vous pouvez le faire avec le assumer un rôle commander:

aws sts assume-role --role-arn "arn: aws: iam :: 123456789012: role / example-role" --role-session-name AWSCLI-Session

Notez que cela nécessite un compte utilisateur IAM pour exécuter cette commande, ce qui ne le rend utile que pour activer l'élévation de privilèges pour les employés.