Audit de posture cloud : ce qu’il faut vérifier au-delà du simple score

Un audit de posture cloud peut produire des centaines de recommandations et un score global rassurant — ou inquiétant. Le problème est qu’un score décrit une méthode de calcul, pas à lui seul le risque réel d’un environnement.

Microsoft présente le CSPM comme un mécanisme de visibilité continue sur l’état de sécurité des actifs cloud et de génération de recommandations pour réduire les mauvaises configurations et les risques.2 AWS calcule de son côté ses scores Security Hub CSPM à partir de la proportion de contrôles réussis parmi les contrôles activés disposant de données.4 Ces deux exemples suffisent à montrer pourquoi un « 82 % » n’a de sens qu’avec son périmètre et sa méthode.

EXPOSITIONService publicAccessible depuis Internet

IDENTITÉRôle permissifPrivilèges excessifs

ACTIFDonnée critiqueImpact métier élevé

PRIORITÉContexte combinéÀ traiter avant un finding isolé

1. Vérifier le périmètre avant de lire le résultat

Un rapport ne devrait jamais commencer par le score. Il devrait commencer par ce qui a été observé : comptes AWS, subscriptions Azure, projets GCP, régions, organisations, services couverts, fenêtre de collecte et permissions utilisées.

Un environnement oublié crée un angle mort ; une permission insuffisante peut donner un résultat incomplet ; une ressource qui n’est pas enregistrée par le service utilisé peut ne jamais participer au calcul. AWS précise par exemple que certains scores nécessitent l’enregistrement des ressources via AWS Config.45

La première question d’un audit devient donc : « de quoi ce résultat est-il représentatif ? »

2. Séparer score, finding et risque

Un contrôle vérifie une condition. Un finding matérialise un résultat ou un écart. Un score agrège des résultats selon une méthode. Le risque, lui, dépend du contexte : exposition, exploitabilité, privilèges, sensibilité des données, dépendances et impact métier.

Microsoft indique explicitement que sa priorisation de risque peut prendre en compte l’exposition Internet, la sensibilité des données, le mouvement latéral et l’appartenance à un chemin d’attaque.3 Le même défaut de configuration peut donc avoir une priorité différente selon la ressource affectée.

Cette distinction est essentielle pour éviter deux erreurs : traiter mécaniquement tous les findings « High » avant de comprendre le contexte, ou poursuivre l’amélioration d’un score alors que quelques chaînes de risque critiques restent ouvertes.

3. Examiner les identités avant les détails cosmétiques

Dans le cloud, les identités relient les utilisateurs, les workloads, les services et les comptes. Un audit utile doit regarder les rôles très permissifs, les relations de confiance, les clés longues durées, les comptes inutilisés, l’authentification forte et les identités de workloads.

L’objectif n’est pas de transformer chaque permission large en incident. Il est d’identifier les combinaisons qui ouvrent une trajectoire : une identité accessible depuis une ressource exposée, capable d’assumer un rôle privilégié et d’atteindre une donnée sensible mérite davantage d’attention qu’une permission équivalente sur un bac à sable isolé.

4. Relier l’exposition réseau à ce qui se trouve derrière

« Public » n’est pas synonyme de « vulnérable », et « privé » n’est pas synonyme de « sûr ». Un endpoint Internet peut être nécessaire. Il doit être analysé avec les mécanismes d’authentification, les protections applicatives, les flux autorisés et surtout la criticité du service.

Une cartographie de dépendances aide ici à sortir du finding isolé : si un service exposé donne accès à une API interne, qui elle-même utilise une identité capable de lire un stockage sensible, la priorité vient de la chaîne et non d’une seule règle.

Contexte
Cartographie SI : les 5 étapes de l’ANSSI transformées en plan opérationnel →

5. Identifier les données et les actifs qui changent réellement l’impact

Deux bases mal configurées ne présentent pas nécessairement le même risque. Il faut distinguer données publiques, données internes, secrets, données personnelles, données de santé, sauvegardes et données indispensables à un service critique.

Les recommandations ANSSI sur l’hébergement cloud des SI sensibles insistent sur la prise en compte du type de SI, de la sensibilité des données et du niveau de menace pour orienter les choix d’hébergement.1 Cette logique rappelle qu’une posture cloud ne se réduit pas à une checklist universelle : le contexte de sensibilité compte.

6. Vérifier journalisation, détection et capacité d’enquête

Un audit de configuration devrait aussi poser des questions sur la capacité à comprendre ce qui s’est passé. Les logs d’administration sont-ils activés et centralisés ? Les accès aux données sensibles sont-ils observables ? Les événements ont-ils une durée de conservation adaptée ? Les alertes arrivent-elles réellement dans un processus de traitement ?

Une configuration conforme au moment T n’empêche pas un changement ultérieur. La journalisation et l’historique donnent les moyens d’expliquer un écart, de détecter un drift et d’enquêter après un incident.

7. Lire les standards et les scores avec leur méthode

AWS explique que son score représente la proportion de contrôles réussis parmi les contrôles activés pris en compte, et qu’un contrôle peut être compté une seule fois dans le score résumé même s’il appartient à plusieurs standards.4 Le score est utile pour suivre une tendance dans le même système de mesure, mais il ne doit pas être comparé naïvement à celui d’un autre produit ou d’un autre périmètre.

Autre conséquence : améliorer un score peut être utile sans être la meilleure priorité immédiate. Microsoft précise d’ailleurs que la priorisation de risque est distincte du secure score dans Defender for Cloud.3

8. Construire une vraie file de remédiation

La sortie d’un audit ne devrait pas être une liste brute. Chaque finding important mérite au minimum :

• un actif et un propriétaire ;
• une explication du contexte de risque ;
• une action proposée ;
• une échéance ou une justification d’exception ;
• une méthode de vérification après correction ;
• un statut qui distingue « corrigé », « accepté », « non applicable » et « à revoir ».

AWS expose par exemple des statuts de workflow pour suivre l’investigation et la résolution des findings dans Security Hub CSPM.5 Peu importe l’outil : le principe utile est que la remédiation possède une vie propre et traçable.

9. Contrôler le drift après la correction

Une correction ponctuelle n’est pas une garantie. Une policy peut être modifiée, une ressource recréée, une nouvelle région ouverte ou un pipeline IaC réintroduire une configuration non souhaitée.

La valeur d’un CSPM est donc aussi temporelle : observer en continu ou à intervalles réguliers, détecter les régressions et comparer les changements. Pour les environnements gérés par Infrastructure as Code, la meilleure correction est souvent double : corriger la ressource et corriger la source de configuration.

10. Le rapport final doit expliquer, pas seulement classer

Un bon rapport de posture peut être lu à plusieurs niveaux :

1. direction / risque : quels scénarios sont prioritaires et pourquoi ;
2. RSSI / cloud security : quelles familles de contrôle et quelles chaînes d’attaque dominent ;
3. équipes techniques : quelles ressources modifier et comment vérifier le résultat ;
4. gouvernance : quels écarts sont acceptés, pour combien de temps et par qui.

Cette structure évite d’utiliser le même score pour répondre à toutes les questions.

Checklist : les dix questions à poser devant un score cloud

Avant d’utiliser un score de posture comme indicateur de pilotage, vérifier :

1. Quels comptes, projets et régions sont inclus ?
2. Quelles ressources ne peuvent pas être évaluées ?
3. Quels standards et contrôles sont activés ?
4. Comment le score est-il calculé ?
5. Quels findings concernent des actifs exposés ?
6. Les identités et relations de confiance sont-elles analysées ?
7. La sensibilité des données intervient-elle dans la priorité ?
8. Les exceptions sont-elles documentées ?
9. Une correction est-elle vérifiée et surveillée dans le temps ?
10. Le score peut-il baisser ou monter sans que le risque réel évolue dans le même sens ?

Le score reste utile : il fournit un repère reproductible. Mais la maturité de l’audit se voit dans la capacité à expliquer ce qui se trouve derrière le nombre et à relier les findings au système, aux données et aux décisions de remédiation.