Les mauvaises configurations cloud que nous voyons

Presque chaque évaluation de posture que nous menons commence par la même heure : l'export des réglages de Microsoft 365, d'Entra ID et des comptes AWS, comparés à un benchmark. Les écarts trouvés varient peu d'une organisation à l'autre. Ce n'est pas un défaut de compétence ; c'est ce qui arrive quand un environnement grandit sans base de référence.

Ce que disent les sources

Le Center for Internet Security (CIS) publie les CIS Benchmarks, des guides de configuration prescriptifs élaborés par consensus d'experts bénévoles, de fournisseurs et de membres de la communauté, distribués gratuitement en format PDF. Selon la page du CIS, plus d'une centaine de guides couvrent plus de vingt-cinq familles de produits, dont les fondations AWS, Azure, Google Cloud et Microsoft 365. Chaque recommandation est classée en deux profils : le niveau 1, une recommandation de base applicable rapidement avec un impact minimal sur les opérations, et le niveau 2, une défense en profondeur pour les environnements sensibles, dont certaines mesures peuvent gêner les opérations si elles sont appliquées sans précaution.

Microsoft Learn décrit les paramètres de sécurité par défaut d'Entra ID : inscription de tous les utilisateurs à l'authentification multifacteur, MFA obligatoire pour les administrateurs, blocage des protocoles d'authentification hérités (clients sans authentification moderne, IMAP, SMTP, POP3), blocage du flux de code d'appareil, et MFA pour l'accès au portail Azure et aux outils d'administration. Microsoft y indique que, selon ses observations, plus de 99,9 % des attaques courantes contre les identités sont arrêtées par la MFA et le blocage de l'authentification héritée, et que la plupart des tentatives de connexion compromises viennent encore de l'authentification héritée. La même page recommande deux comptes d'accès d'urgence, exclusivement infonuagiques, réservés aux scénarios de bris de glace.

La documentation AWS sur les bonnes pratiques IAM demande que les humains accèdent par fédération avec des identifiants temporaires, que les charges de travail utilisent des rôles plutôt que des clés d'accès à long terme, que la MFA soit exigée là où un utilisateur IAM ou le compte racine subsiste, que le moindre privilège soit appliqué, que les utilisateurs, rôles et identifiants inutilisés soient revus et supprimés régulièrement, et que l'accès public ou intercompte aux ressources soit vérifié avec IAM Access Analyzer.

Pourquoi ça compte

Voici, sans chiffre parce que nous n'en publions pas, les écarts que nous retrouvons le plus souvent.

Microsoft 365 et Entra ID. L'authentification héritée est encore permise pour « une imprimante multifonction » ou « un vieux script », ce qui contourne la MFA pour tout le domaine. Les comptes d'accès d'urgence n'existent pas, ou existent avec une MFA liée au téléphone d'un ancien administrateur. Les rôles d'administrateur global sont attribués en permanence à des comptes utilisés au quotidien. Les consentements d'applications par les utilisateurs sont ouverts. Le partage externe SharePoint est permis à tous, sans expiration. Les journaux d'audit ne sont pas conservés au-delà de la valeur par défaut.

AWS. Le compte racine a des clés d'accès actives. Des utilisateurs IAM avec des clés d'accès vieilles de plusieurs années servent à des intégrations que personne ne sait nommer. Des politiques accordent l'accès complet à un service entier faute d'avoir été réduites après la phase de découverte. Le journal CloudTrail n'est pas activé dans toutes les régions, ou ses fichiers sont dans un compartiment que le même rôle peut effacer. Des compartiments S3 restent accessibles publiquement parce que le blocage n'a pas été appliqué au niveau du compte.

Aucun de ces écarts n'est exotique. Chacun figure dans le benchmark CIS correspondant, au niveau 1 pour la plupart. Ils persistent parce que personne n'a la responsabilité de comparer la configuration au benchmark, et parce que les corrections cassent parfois quelque chose que personne ne veut réparer.

Ce que nous en pensons chez Sentrix

La bonne réponse n'est pas un outil de plus ; c'est une base de référence choisie, mesurée, et tenue.

1. Adopter le benchmark CIS de chaque plateforme au niveau 1 comme base de référence interne, et documenter chaque exception avec un propriétaire et une date de revue.
2. Mesurer avant de corriger : un premier export complet, comparé au benchmark, donne la liste des écarts et le point de départ que l'auditeur voudra voir.
3. Corriger d'abord les écarts qui contournent la MFA : blocage de l'authentification héritée et du flux de code d'appareil dans Entra ID, MFA sur le compte racine et les utilisateurs IAM restants dans AWS.
4. Retirer les identifiants à long terme : fédération et rôles temporaires dans AWS, identités gérées pour les charges de travail Azure, et rotation de ce qui ne peut pas être remplacé.
5. Fermer l'accès public par défaut, au niveau du compte ou de l'organisation, puis rouvrir explicitement ce qui doit l'être, avec la justification écrite.
6. Automatiser la comparaison : un export mensuel comparé au benchmark, dont les nouveaux écarts créent un ticket avec un propriétaire. C'est le rôle d'un module de gestion continue de l'exposition aux menaces, comme celui de la plateforme Sentrix.

Pour ISO 27001:2022, ces mesures répondent aux contrôles 8.9 (gestion de la configuration), 8.5 (authentification sécurisée) et 5.23 (sécurité des services infonuagiques) ; pour SOC 2, aux critères CC6.1 à CC6.3. Voir la fiche ISO 27001 et notre service de sécurité infonuagique.

La prochaine étape

Exportez l'état de l'authentification héritée dans les journaux de connexion d'Entra ID et la liste des clés d'accès IAM avec leur date de dernière utilisation. Ces deux listes prennent une heure à produire et contiennent, presque toujours, les deux premiers écarts à corriger.