Points clés
- La gestion des accès cloud (IAM — Identity and Access Management) est le contrôle de sécurité le plus critique dans les environnements cloud
- Microsoft Security : 98 % des attaques cloud pourraient être bloquées par une gestion correcte des identités et une authentification multifacteur
- Les erreurs IAM les plus fréquentes : droits excessifs, comptes de service non surveillés, absence de MFA sur les comptes à privilèges, accès non révoqués
- Le principe de moindre privilège est le fondement de l'IAM cloud — il est rarement respecté en pratique sans processus formalisés
Dans l'architecture de sécurité cloud, l'identité est le nouveau périmètre. Là où les architectures on-premise s'appuyaient sur le réseau physique comme première ligne de défense (si vous êtes dans notre réseau, vous avez une certaine confiance), les architectures cloud supposent que le réseau est non fiable et font de l'identité — qui êtes-vous, avez-vous le droit de faire ceci — le contrôle primaire. Cette transition redéfinit la priorité des investissements de sécurité cloud : l'IAM (Identity and Access Management) devient le contrôle le plus critique, devant la sécurité réseau.
La gestion des accès cloud englobe plusieurs dimensions : les comptes humains (employés, prestataires, sous-traitants avec accès aux services cloud), les comptes de service (identités techniques utilisées par les applications et les automatismes), les rôles et permissions (droits accordés à chaque compte), et le cycle de vie (création, modification, révocation des accès). Chacune de ces dimensions est une source potentielle de vulnérabilités si elle n'est pas gérée rigoureusement.
Le principe de moindre privilège dans le cloud
Le principe de moindre privilège — chaque identité n'accède qu'aux ressources strictement nécessaires à sa fonction — est universellement reconnu comme fondamental mais rarement respecté en pratique. Les raisons sont documentées : la pression opérationnelle conduit à l'attribution de droits larges pour "ne pas bloquer" les équipes, les environnements de test héritent souvent des droits de production, et les révisions régulières des droits requièrent des ressources que les organisations n'ont pas toujours.
AWS, Azure et Google Cloud proposent tous des outils d'analyse des droits IAM qui identifient les permissions accordées mais jamais utilisées (Unused Permissions). Ces outils permettent de réduire les droits excessifs de manière progressive et documentée, sans bloquer les utilisateurs légitimes.
Les comptes de service : l'angle mort IAM
Les comptes de service — identités techniques utilisées par les applications, les scripts d'automatisation et les pipelines CI/CD — sont l'angle mort le plus fréquent dans la gestion des accès cloud. Ces comptes disposent souvent de droits d'administration élevés (nécessaires pour déployer et gérer des ressources cloud), ne sont pas soumis à l'authentification multifacteur (techniquement incompatible avec leur usage automatisé), et ne font pas l'objet de révisions régulières.
L'incident Capital One (2019) a exploité précisément ce type de compte : une identité de service avec des droits excessifs permettait l'accès aux métadonnées d'instances EC2. Des droits respectant le principe de moindre privilège auraient contenu l'impact de la compromission.
L'authentification multifacteur sur les accès cloud
L'activation du MFA sur les comptes humains avec accès aux consoles cloud est le contrôle le plus simple et le plus efficace pour réduire le risque de compromission par credential. Microsoft rapporte que le MFA bloque 99,9 % des attaques sur les comptes. Malgré cette efficacité documentée, l'activation du MFA sur les comptes cloud à privilèges reste incomplète dans de nombreuses organisations — souvent parce qu'elle n'est pas imposée par défaut et que les équipes résistent à la friction supplémentaire.
Les politiques d'accès conditionnel (Conditional Access dans Azure, Service Control Policies dans AWS Organizations) permettent d'imposer le MFA de manière centralisée sur tous les accès aux ressources sensibles, sans laisser à l'appréciation individuelle la décision de l'activer.
La compromission d'Uber en 2022 a exploité des credentials d'un sous-traitant obtenus via ingénierie sociale, combinés à une fatigue MFA (bombardement de l'utilisateur de demandes MFA jusqu'à acceptation par erreur). Une fois ces credentials validés, l'attaquant a découvert dans un partage réseau des scripts PowerShell contenant en clair les credentials d'un compte d'administration Privileged Access Management (PAM). Avec ces credentials, l'attaquant a eu accès à l'ensemble de l'infrastructure cloud d'Uber. Plusieurs niveaux d'IAM défaillant (credentials dans le code, MFA contournable par fatigue, pas de rotation des secrets) ont créé la chaîne de compromission.
Lors de la campagne SolarWinds, les attaquants ont utilisé leur accès initial via le backdoor Sunburst pour se déplacer vers les tenants Microsoft 365 et Azure AD des organisations victimes. Ils ont exploité des configurations IAM permissives — comptes de service avec droits élevés, absence de surveillance des créations de règles dans Exchange — pour maintenir leur accès après la détection initiale. L'investigation a montré que des droits IAM respectant le principe de moindre privilège auraient significativement limité leur capacité à se déplacer latéralement dans les environnements cloud des victimes.
Alibaba Cloud a publié en 2023 une analyse anonymisée des configurations IAM de ses clients, révélant que 67 % des comptes analysés présentaient au moins une configuration à risque élevé : comptes avec droits d'administration complets, clés d'accès actives sans rotation depuis plus d'un an, ou absence de MFA sur les comptes console. Cette publication a conduit Alibaba Cloud à lancer un programme de notification proactive des clients présentant des risques IAM critiques — reconnaissant que les erreurs IAM constituent la principale vulnérabilité de ses clients.