Gestion de la posture de sécurité dans le cloud (CSPM)
Presque toutes les violations majeures de sécurité dans le cloud dont j’ai lu l’analyse rétrospective remontent à une erreur de configuration, et non à une faille « zero-day » sophistiquée. Un compartiment de stockage laissé accessible au public, un rôle d’identité doté de bien plus d’autorisations que ce dont la charge de travail a réellement besoin, un groupe de sécurité ouvert à l’ensemble d’Internet parce que c’était plus simple pendant les tests et que personne ne l’a fermé par la suite. Les plateformes cloud vous offrent une flexibilité considérable, et cette flexibilité signifie qu’il est tout à fait possible de créer un système qui fonctionne parfaitement tout en étant grand ouvert, sans qu’aucun message d’erreur ne vous le signale.
La sécurité dans le cloud consiste à vérifier en permanence que votre environnement cloud respecte les meilleures pratiques en matière de sécurité et votre propre politique, afin de repérer le compartiment de stockage rendu public, le rôle IAM trop large ou la base de données non chiffrée avant qu’un attaquant ne les découvre. Les environnements qui rencontrent des problèmes ne sont généralement pas ceux qui n’ont jamais fait l’objet d’un audit de sécurité, mais ceux qui ont été validés une fois, puis ont continué à se développer sans que personne ne procède à une nouvelle vérification.
Comment je procède pour cela
Je commence par analyser votre empreinte cloud réelle, qui s’étend souvent sur plusieurs comptes, services et parfois plusieurs fournisseurs, puis je mets en place une surveillance continue de la configuration plutôt qu’un audit ponctuel. Une évaluation ponctuelle ne vous renseigne que sur la situation actuelle ; une erreur de configuration introduite le mois prochain par un nouveau déploiement n’apparaîtra pas avant qu’un problème ne survienne.
À partir de là, je classe les résultats par ordre de priorité en fonction de leur exploitabilité réelle : une base de données exposée publiquement et contenant des données sensibles revêt bien plus d’importance qu’un environnement de test interne dont les autorisations sont légèrement trop laxistes, et j’intègre les mesures correctives dans votre workflow de déploiement réel plutôt que de les traiter dans le cadre d’un audit de sécurité distinct effectué a posteriori. L’objectif est de détecter les erreurs de configuration dans le cadre du processus de déploiement habituel de votre équipe, grâce à des revues « infrastructure-as-code » et à des vérifications « policy-as-code », plutôt que de compter sur quelqu’un qui se souviendrait d’auditer manuellement les paramètres à intervalles réguliers.
À qui s'adresse ce document ?
Si votre environnement cloud s’est développé plus rapidement que votre processus d’évaluation de la sécurité, si vous n’avez jamais réalisé d’audit dédié à la configuration du cloud, ou si vous n’êtes pas certain de pouvoir détecter une faille publique avant qu’un pirate ne la découvre, cela vaut la peine de mettre ce dispositif en place.
Contactez-nous et examinons ensemble à quoi ressemble réellement votre environnement cloud aujourd’hui.