Comparer les utilisateurs et groupes IAM

AWS Identity and Access Management (IAM) est le service qui contrôle qui peut faire quoi dans votre compte. Deux de ses composants fondamentaux sont les utilisateurs et les groupes. Un utilisateur est une identité permanente associée à une personne ou à une application, tandis qu’un groupe est simplement un conteneur qui regroupe des utilisateurs afin qu’ils partagent les mêmes autorisations. Comprendre cette différence constitue la base de tout le reste de l’examen.

Un utilisateur IAM est une identité à long terme dont le nom est unique dans votre compte. Il peut disposer de deux types d’informations d’identification :

• Un mot de passe de console pour se connecter via le Web.
• Des clés d’accès (un ID de clé d’accès et une clé secrète) pour les appels d’API et de CLI par programmation.

Comme ces informations d’identification sont durables, AWS les considère comme présentant un risque plus élevé. La bonne pratique consiste à privilégier les rôles et les informations d’identification temporaires plutôt que de créer de nombreux utilisateurs dotés de clés permanentes.

Un groupe IAM est un ensemble d’utilisateurs qui partagent des autorisations par l’intermédiaire de politiques associées. Les groupes rendent la gestion des accès évolutive : au lieu d’associer la même politique à dix développeurs, vous l’associez une seule fois à un groupe « Developers », puis vous y ajoutez les utilisateurs. Voici les points essentiels attendus à l’examen :

• Un groupe ne possède aucune information d’identification et ne peut pas être un principal dans une politique.
• Un utilisateur peut appartenir à plusieurs groupes.
• Les groupes ne peuvent pas être imbriqués dans d’autres groupes.

Lorsqu’un utilisateur effectue une demande, IAM combine toutes les politiques applicables : celles qui sont directement associées à l’utilisateur et celles qui sont associées à chacun des groupes auxquels il appartient. Le résultat est l’union de toutes les actions autorisées, sauf si un refus explicite apparaît quelque part. L’appartenance à un groupe ne fait donc qu’ajouter des autorisations, jamais en retirer, sauf lorsqu’une instruction de refus explicite est présente.

Gérer les autorisations utilisateur par utilisateur favorise la dérive de configuration : avec le temps, chaque utilisateur accumule un ensemble légèrement différent de politiques, difficile à vérifier. Les groupes centralisent les autorisations, de sorte qu’une seule modification de politique s’applique uniformément à tous les utilisateurs d’un rôle. Pour un auditeur, il est bien plus simple de consulter la liste des membres du groupe « Admins » que d’examiner des dizaines d’utilisateurs individuellement.

Vous pouvez inspecter les membres depuis la CLI afin de vérifier qui dispose d’un accès élevé. La commande ci-dessous liste tous les utilisateurs d’un groupe ; il s’agit souvent de la première étape lorsqu’il faut traiter un constat d’accès excessivement privilégié.

Ne confondez pas les utilisateurs IAM avec l’utilisateur racine. L’utilisateur racine est l’identité du propriétaire du compte, créée lors de l’ouverture de celui-ci, et dispose d’un accès illimité qui ne peut pas être restreint par les politiques IAM. AWS recommande vivement de mettre les informations d’identification racine hors d’accès, d’y activer l’authentification multifacteur (MFA) et de ne jamais l’utiliser pour les tâches quotidiennes. Créez plutôt des utilisateurs IAM individuels ou, mieux encore, utilisez la fédération.

Chaque utilisateur IAM doit avoir MFA activé, ce qui exige un second facteur, comme une clé matérielle ou une application d’authentification, en plus du mot de passe. Vous pouvez imposer MFA au moyen de conditions de politique telles que aws:MultiFactorAuthPresent. L’examen vérifie souvent l’utilisation de MFA pour protéger les opérations sensibles, comme la suppression de ressources ou la modification des paramètres de sécurité.

Une erreur courante consiste à créer des utilisateurs IAM avec des clés d’accès statiques pour les applications exécutées sur EC2 (Elastic Compute Cloud). Cela intègre des secrets à long terme susceptibles de fuir. Le modèle sécurisé consiste à associer un rôle IAM à l’instance, ce que nous allons voir ensuite. Pour les équipes humaines, privilégiez la fédération avec IAM Identity Center plutôt que la gestion individuelle des utilisateurs.

Le rapport d’identification IAM est un fichier CSV téléchargeable qui répertorie chaque utilisateur, indique quand son mot de passe et ses clés d’accès ont été utilisés pour la dernière fois, et précise si MFA est activé. Associé à IAM Access Analyzer et aux données de dernière utilisation, il vous aide à trouver les utilisateurs obsolètes, les clés inutilisées et les groupes aux permissions trop larges. Une revue régulière constitue un élément essentiel de l’hygiène du moindre privilège, et l’examen l’attend de vous.

Utilisez des utilisateurs lorsque vous avez besoin d’une identité distincte et authentifiée pour une personne ou une ancienne application. Utilisez des groupes pour attribuer proprement des permissions communes et éviter les divergences entre utilisateurs. Dans les conceptions modernes, vous réduisez au minimum les utilisateurs permanents et vous vous appuyez entièrement sur les rôles pour les charges de travail et sur la fédération pour les personnes. Les utilisateurs et les groupes restent des notions essentielles, mais ils constituent le point de départ, pas l’objectif final.

Vérifiez votre compréhension des utilisateurs et des groupes.

Vous avez appris qu’un utilisateur IAM est une identité authentifiée destinée à être utilisée à long terme, tandis qu’un groupe IAM est un conteneur sans identifiants qui regroupe des utilisateurs afin de partager des politiques. Les permissions correspondent à l’union des politiques de l’utilisateur et du groupe, les groupes ne peuvent pas être imbriqués, et l’utilisateur racine doit être mis à l’abri avec MFA. Privilégiez les rôles pour les charges de travail et la fédération pour les personnes afin d’éviter les secrets à longue durée de vie et la dérive de configuration.