Sécurité cloud
Sécurité cloud
Découvrez ce qui est réellement exposé dans votre cloud, corrigez les erreurs de configuration à l'origine des compromissions, et maintenez ce niveau au fil de vos livraisons.
Aperçu
La sécurité cloud consiste à garder votre environnement AWS, Azure ou GCP défendable alors qu'il change, ce qu'il fait chaque jour. La cause dominante des compromissions cloud n'est pas un exploit exotique mais une erreur de configuration : un bucket de stockage laissé public, un rôle IAM trop permissif, un port d'administration ouvert sur Internet, la journalisation désactivée sur le compte dont plus personne ne se souvient. Nous combinons la gestion de la posture (détecter et corriger ces erreurs en continu) et les tests d'intrusion cloud (prouver ce qu'un attaquant pourrait réellement atteindre et enchaîner), car un score de posture vous dit seulement ce qui est mal configuré, pas ce qui est véritablement exploitable.
Méthodologie et standards
Les évaluations sont mesurées à l'aune des CIS Foundations Benchmarks pour AWS, Azure et GCP, des piliers sécurité des cadres Well-Architected des fournisseurs, et de l'OWASP Cloud-Native Top 10. Les tests respectent les règles d'engagement des fournisseurs, et les constats liés aux identités sont formulés au regard du principe du moindre privilège plutôt que d'une checklist générique.
Ce qui est inclus
Ce que vous recevez
Questions fréquentes
Seulement d'une partie. Dans le modèle de responsabilité partagée, AWS, Azure et GCP sécurisent l'infrastructure sur laquelle le cloud fonctionne. Tout ce que vous y déposez, vos données, vos identités, votre configuration réseau, vos politiques d'accès et vos charges de travail, relève de votre responsabilité. La plupart des compromissions cloud surviennent nettement du côté client de cette frontière, précisément là où nous testons.
Le CSPM analyse en continu votre configuration et signale ce qui s'écarte d'un référentiel. Un test d'intrusion cloud pose une autre question : compte tenu de ces erreurs de configuration, que pourrait réellement atteindre un attaquant ? Le test enchaîne les constats en véritables chemins d'attaque, et c'est ainsi que vous découvrez qu'un rôle exposé de faible gravité se trouve à un saut de vos données de production. Il vous faut la gestion de posture pour l'hygiène continue, et les tests pour la preuve.
Non. Nous convenons des règles d'engagement à l'avance, respectons les politiques de test des fournisseurs cloud et limitons toute activité susceptible d'affecter la disponibilité. Les vérifications destructrices sont menées sur un compte hors production lorsqu'il en existe un, et vous disposez d'un canal de contact en temps réel avec les testeurs tout au long de l'engagement.
Oui. C'est en multi-cloud que la dérive de posture est la plus marquée, car les équipes appliquent un socle chez un fournisseur sans jamais le répliquer chez les autres. Nous évaluons AWS, Azure et GCP selon le même standard, et couvrons Kubernetes et les charges de travail conteneurisées, y compris le RBAC, la sécurité des pods, la provenance des images et le plan de contrôle.
En les corrigeant là où elles naissent. Les correctifs ponctuels appliqués dans la console sont annulés au déploiement suivant : nous livrons donc la remédiation sous forme de modifications d'infrastructure-as-code et de garde-fous (service control policies, Azure Policy, contrôleurs d'admission) qui empêchent purement et simplement le déploiement de la mauvaise configuration, puis nous ajoutons une surveillance continue de la posture pour détecter la dérive.
Principalement les CIS Foundations Benchmarks pour AWS, Azure et GCP, ainsi que les piliers sécurité des cadres Well-Architected des fournisseurs. Lorsque vous avez un enjeu de conformité, nous mappons les constats aux contrôles ISO 27001, SOC 2 ou PCI DSS pertinents, afin qu'une seule évaluation serve à la fois le besoin de sécurité et le besoin d'audit.