La gestion de la posture de sécurité cloud (CSPM) évalue la configuration du plan de contrôle cloud au regard des exigences de sécurité définies. Dans les environnements AWS, Azure et Google Cloud, la CSPM permet de déterminer si les ressources, les identités et les paramètres au niveau du compte correspondent à la posture établie. Elle n’inspecte pas les charges utiles des paquets applicatifs et ne remplace pas la détection en temps réel d’une attaque en cours.
Les outils CSPM fonctionnent généralement sans agent. Ils utilisent des identifiants en lecture seule pour appeler les API de chaque fournisseur, dresser un inventaire des ressources et évaluer des règles sur la base de cet inventaire. Parmi les exemples, on peut citer AWS Config et Security Hub, Microsoft Defender for Cloud, Google Security Command Center, ainsi que des outils d’analyse open source tels que Prowler et Steampipe. Lorsqu’une ressource ne respecte pas l’une de ces règles, l’outil signale le résultat sous la forme d’une constatation (ou finding).
Une constatation est un constat relatif à un état de configuration observable, comme le paramètre d’accès d’une ressource de stockage ou l’autorisation attribuée à une identité. Sa valeur dépend des preuves que le processus CSPM peut lire et de la règle utilisée pour interpréter ces preuves.
Nous pouvons désormais identifier les limites liées aux fournisseurs ainsi que les sources de preuves utilisées lors d’une évaluation CSPM.
Les preuves de configuration décrivent les informations rapportées par le plan de contrôle du fournisseur au moment de la collecte. Les journaux d’activité fournissent un historique des actions de gestion, comme la modification d’une politique ou la création d’une ressource par une entité (principal). Dans AWS, il s’agit d’AWS Config et de CloudTrail ; dans Azure, d’Azure Resource Graph et de l’Activity Log ; et dans Google Cloud, de Cloud Asset Inventory et de Cloud Audit Logs. Ensemble, ces sources permettent de confirmer l’existence d’un paramètre et d’identifier potentiellement son auteur, mais elles ne prouvent ni la réussite d’une requête applicative, ni l’accès à des données, ni l’innocuité d’un paquet réseau.
La dérive de configuration correspond à l’écart entre la configuration approuvée (ou attendue) et la configuration réelle observée. Cette dérive peut résulter d’une modification manuelle, d’une erreur d’automatisation, d’un retour arrière de déploiement ayant rétabli une ancienne valeur, ou de la création d’une ressource en dehors du processus de livraison prévu. La solution CSPM ne détecte cet écart que si la ressource figure dans son inventaire et que les preuves correspondantes sont disponibles.
Limites des preuves Une constatation CSPM établit un état de configuration dans le périmètre du fournisseur. Elle ne permet pas, à elle seule, de déterminer l’exploitabilité, l’impact métier ou la réussite d’un accès.
Une constatation peut constituer un faux positif lorsque la règle évaluée signale un problème alors que l’exigence applicable autorise l’état observé. Par exemple, une règle formulée de manière trop large pourrait signaler un point de terminaison exposé à Internet qui est volontairement public et protégé par des contrôles non évalués par ladite règle. La démarche prudente consiste à valider l’exigence, l’objectif de la ressource, le vecteur d’exposition et les contrôles compensatoires avant de modifier la configuration de production.
L’absence d’autorisations de lecture entraîne le problème inverse. Si l’identité utilisée par la solution CSPM ne peut pas lister une ressource, récupérer une politique ou inspecter un paramètre pertinent, l’évaluation risque d’être incomplète plutôt que de donner un résultat « propre » (sans anomalies). Une ressource non gérée produit le même effet pratique lorsqu’elle se situe en dehors du périmètre d’évaluation (comptes, abonnements, projets ou inventaire).
Le modèle de responsabilité partagée impose également des limites. Le fournisseur cloud gère le service sous-jacent, tandis que le client reste responsable de choix tels que l’attribution des identités, l’exposition réseau, les politiques de ressources et la configuration de l’accès aux données. Un résultat positif lors d’une vérification de posture ne transfère pas cette responsabilité et ne démontre pas l’efficacité de tous les contrôles gérés par le client.
Règle de décision Ne considérez l’absence de constatations comme une information utile qu’après avoir confirmé le périmètre, les autorisations de collecte, l’applicabilité de la règle et la fenêtre temporelle des preuves.
Nous utiliserons une charge de travail volontairement restreinte, nommée orders-api. Elle correspond à un service applicatif à l’écoute sur le port 8080 et stockant des données de commande dans une ressource de stockage d’objets native au fournisseur cloud. Chaque version demeure confinée aux limites de son propre fournisseur ; ainsi, aucune identité, autorisation de stockage ou alerte de sécurité n’est censée transiter d’un cloud à l’autre.
Sur AWS, orders-api utilise le rôle orders-api-role et le compartiment (bucket) orders-data-s3. Sur Azure, elle utilise l’identité gérée orders-api-mi et le compte de stockage ordersdatast. Sur Google Cloud, elle utilise le compte de service orders-api-sa et le compartiment orders-data-gcs. Ces identifiants sont fictifs, mais la délimitation qu’ils illustrent est réutilisable.
Nous pouvons examiner comment l’identité de chaque charge de travail reste cantonnée aux ressources de son propre fournisseur.