Sécurité cloud AWS, GCP, Azure : les 10 erreurs IAM les plus courantes

IAM : la porte d'entrée de votre cloud

Identity and Access Management est le système de contrôle d'accès de votre infrastructure cloud. Une erreur de configuration IAM ne crée pas une simple faille : elle donne à un attaquant les clés de l'ensemble de votre environnement. Les brèches cloud les plus médiatisées (Capital One, Twitch, Microsoft) impliquent toutes des erreurs IAM.

Erreur 1 : clés d'accès statiques dans le code

Des access keys AWS ou des service account keys GCP committées dans le code source. Les bots scannent GitHub en temps réel. Une clé publiée est exploitée en moins de 30 minutes en moyenne.

Correction : utilisez des rôles IAM pour les services, des identités managées pour les machines virtuelles, et un gestionnaire de secrets pour les cas où une clé est nécessaire.

Erreur 2 : permissions administrateur sur les utilisateurs applicatifs

Un service de backend avec AdministratorAccess sur AWS ou le rôle Owner sur GCP. L'application n'a besoin que de lire/écrire dans une table DynamoDB, mais elle a les droits pour supprimer l'ensemble du compte.

Correction : principe du moindre privilège. Créez des policies qui n'accordent que les permissions exactes nécessaires.

Erreur 3 : pas de MFA sur les comptes root et admin

Le compte root AWS sans MFA est accessible avec juste un email et un mot de passe. Un phishing réussi donne un accès total à l'infrastructure.

Correction : MFA hardware (YubiKey) sur tous les comptes avec des privilèges élevés. Sans exception.

Erreur 4 : rôles assumables sans conditions

Un rôle IAM assumable par n'importe quel service du compte, ou pire, par n'importe quel compte AWS via une politique de confiance trop large. "Principal": "*" dans une trust policy est une porte ouverte.

Correction : spécifiez exactement quels principals peuvent assumer chaque rôle, avec des conditions sur l'IP source ou le tag de session.

Erreur 5 : service accounts GCP avec clés téléchargées

Créer une clé JSON pour un service account GCP et la distribuer aux développeurs ou la stocker sur un serveur. Ces clés n'expirent jamais et sont impossibles à tracer.

Correction : utilisez Workload Identity Federation pour les accès depuis l'extérieur de GCP. Pour les services internes, utilisez le service account attaché à l'instance.

Erreur 6 : buckets S3 / Cloud Storage publics

La configuration par défaut a évolué, mais des buckets restent accessibles publiquement par erreur de configuration. Les données exposées vont des backups de base de données aux fichiers clients.

Correction : bloquez l'accès public au niveau de l'organisation avec S3 Block Public Access ou les Organization Policies GCP.

Erreur 7 : pas de rotation des credentials

Des access keys créées il y a trois ans, des mots de passe de service account jamais changés. Plus un credential vit longtemps, plus il a de chances d'être compromis.

Correction : rotation automatique tous les 90 jours maximum. Préférez les credentials temporaires (STS, Workload Identity).

Erreur 8 : CloudTrail / Audit Logs désactivés ou incomplets

Sans logs d'audit, impossible de détecter une compromission ou de faire du forensics après incident. Certaines PME désactivent les logs pour économiser sur le stockage.

Correction : activez CloudTrail (AWS), Cloud Audit Logs (GCP), Activity Log (Azure) sur toutes les régions et tous les services.

Erreur 9 : policies wildcard

"Resource": "*" et "Action": "s3:*" dans la même politique. L'application a accès à tous les buckets S3 du compte au lieu du seul bucket nécessaire.

Correction : spécifiez les ARN exacts des ressources. Utilisez IAM Access Analyzer pour identifier les permissions excessives.

Erreur 10 : pas de séparation entre environnements

Production, staging et développement dans le même compte cloud avec les mêmes credentials. Un développeur avec accès au staging a aussi accès à la production.

Correction : un compte/projet par environnement. Utilisez AWS Organizations ou GCP Folders pour la gouvernance.

Notre approche

Chez CleanIssue, nous vérifions systématiquement la configuration IAM lors de nos audits d'infrastructure cloud. Parlez-nous de votre revue externe pour identifier vos erreurs de configuration.