IAM cloud : rôles, politiques et moindre privilège

La gestion des identités et des accès (IAM) dans les environnements cloud contrôle qui peut faire quoi sur quelles ressources. Ses trois piliers sont les entités principales (utilisateurs, groupes, comptes de service), les autorisations (actions individuelles) et les politiques (documents associant les entités principales aux autorisations).

Les politiques IAM d’AWS sont des documents JSON qui autorisent ou refusent des actions d’API sur des ressources. Les rôles sont des identités assumées par des services (EC2, Lambda) ou des utilisateurs fédérés. Préférez les rôles aux clés d’accès à longue durée de vie pour les instances EC2.

Accordez uniquement les autorisations nécessaires à l’accomplissement d’une tâche précise. Commencez avec zéro autorisation et n’ajoutez que ce qui est requis. Réexaminez et réduisez les autorisations au fil du temps. Les autorisations inutilisées constituent une surface d’attaque inutile.

Les limites d’autorisation définissent le niveau maximal d’autorisations qu’une entité principale peut avoir, quelles que soient les politiques qui lui sont associées. Utilisez-les pour déléguer l’administration de l’IAM en toute sécurité : les développeurs peuvent créer des rôles, mais ne peuvent pas dépasser la limite que vous définissez.

GCP utilise des comptes de service avec des fichiers de clés ou la fédération d’identités de charge de travail. Azure utilise des identités gérées (attribuées par le système et attribuées par l’utilisateur), ce qui élimine la nécessité de gérer les identifiants : la plateforme prend automatiquement en charge la rotation des jetons.

AWS IAM Access Analyzer surveille en continu les politiques de ressources et signale les ressources partagées avec l’extérieur (compartiments S3, clés KMS, fonctions Lambda). Il identifie automatiquement les accès publics ou inter-comptes involontaires.

ABAC étend RBAC en accordant des autorisations selon les balises et attributs des ressources et des entités principales. Une politique autorisant l’accès aux ressources portant la même valeur de projet que l’entité principale évolue mieux que des milliers d’affectations individuelles de rôles.

Faites tourner les clés d’accès IAM tous les 90 jours. Activez MFA pour tous les utilisateurs humains. Détectez les identifiants inutilisés avec Access Advisor et supprimez-les. Surveillez l’utilisation du compte racine : elle ne devrait presque jamais apparaître dans les journaux CloudTrail.

Les mauvaises configurations de l’IAM permettent l’escalade de privilèges : iam:PassRole + ec2:RunInstances permet à un attaquant de lancer une instance EC2 avec un rôle d’administrateur. iam:CreateAccessKey permet à un attaquant d’ajouter des clés à n’importe quel utilisateur. Une analyse régulière des chemins d’escalade est essentielle.

Les rôles entre comptes permettent à un compte AWS d’accéder aux ressources d’un autre compte. Définissez une stratégie de confiance sur le rôle du compte cible en indiquant le compte source et, éventuellement, un identifiant externe pour atténuer le risque de mandataire confus.

Générez des rapports d’identifiants IAM chaque mois. Utilisez les règles AWS Config pour détecter les configurations IAM non conformes. Intégrez les constats IAM à un SIEM afin de centraliser les alertes de violation de stratégies. Appliquez les garde-fous SCP au niveau de l’organisation.

Quel est l’objectif d’une limite d’autorisations dans AWS IAM ?

La gestion des identités et des accès dans le cloud contrôle l’accès au moyen de principaux, de stratégies et de rôles. L’application du principe du moindre privilège, l’utilisation d’identités gérées, l’activation d’outils d’analyse des accès et l’audit régulier de l’utilisation des identifiants sont des pratiques essentielles pour sécuriser les environnements cloud.