Posture de sécurité cloud : détecter et corriger les mauvaises configurations sur AWS, Azure et GCP

Le travail de posture de sécurité cloud de SEYA Group détecte les mauvaises configurations dans les comptes AWS, Microsoft Azure et Google Cloud que vous nommez, les classe par priorité et aide votre équipe à corriger celles qui comptent. La revue couvre l'identité, les chemins réseau, l'exposition des données et la journalisation. Elle peut prendre la forme d'une évaluation ponctuelle ou d'une vérification récurrente. Ce n'est pas une certification, et ce n'est pas un service de surveillance sur 24 heures.

À qui s'adresse ce service

Aux responsables infrastructure et architectes sécurité qui ont plus d'un compte ou d'un abonnement et aucune liste unique de ce qui est exposé. Aux équipes qui préparent une revue de sécurité client ou un audit et ont besoin que les écarts soient consignés avant l'arrivée d'un évaluateur. Aux équipes plateforme qui utilisent déjà Terraform et veulent la même revue exprimée sous forme de politique exécutable à chaque changement.

Ce que vous obtenez

• Une revue par rapport à un référentiel. Des constats rattachés aux CIS Benchmarks pertinents pour le cloud du périmètre, plus les vérifications que votre propre standard exige déjà. CIS est une base publiée à l'aune de laquelle nous mesurons. SEYA n'émet pas de certification CIS.
• Identité. Qui peut endosser des rôles privilégiés, quelles clés et quels principaux de service sont encore actifs, et où une personne ou un pipeline dispose de plus d'accès que la tâche ne l'exige.
• Réseau et données. Points de terminaison publics, groupes de sécurité ou règles de pare-feu ouverts, stockage accessible plus largement que ne le prévoit la conception, et paramètres de chiffrement qui ne correspondent pas au standard du compte.
• Journalisation. Si les journaux d'audit existent, où ils vont et qui peut les supprimer. Un contrôle qui n'est pas journalisé ne peut pas être démontré plus tard.
• Une liste de corrections. Classée par exposition, avec un responsable de votre côté. Si vous souhaitez que les corrections soient codifiées, nous les écrivons sous forme de Terraform ou de vérifications de politique que votre pipeline peut exécuter. Cette construction relève du DevSecOps.

Déroulement d'une mission

• Ponctuelle. Un accès en lecture seule aux comptes du périmètre, une liste écrite de constats et une restitution. C'est le bon point de départ quand vous ne faites pas encore confiance au tableau d'ensemble.
• Continue. Les mêmes vérifications exprimées sous forme de politique exécutée à chaque changement du code d'infrastructure, plus une cadence de revue des exceptions. Continue ne signifie pas que SEYA surveille la console la nuit. Ce sont votre pipeline et votre équipe qui exécutent les vérifications.
• Outils. Nous utilisons les services de sécurité propres au fournisseur cloud et, si vous en avez déjà un, votre produit CSPM. SEYA ne vous impose pas d'acheter un outil chez nous. Le livrable, ce sont les constats et les corrections, pas une licence.

Ce dont vous avez besoin au départ

Un accès aux comptes permettant de lire la configuration, un responsable nommé pour les exceptions, et un accord sur les comptes dans le périmètre. Les constats centrés sur l'identité se prolongent souvent en feuille de route zero trust. Les preuves que vous remettrez à un auditeur se prolongent en préparation SOC 2. La revue de posture elle-même s'arrête aux constats et aux corrections convenues.

Un exemple publié de ce type de travail de fondation est le premier environnement Google Cloud de LiveRamp : réseau VPC partagé, plans de contrôle GKE séparés, environnements cloisonnés et IAM granulaire. Cette mission a conçu la fondation. Ce n'était pas une attestation CIS.

Questions fréquentes

Une revue de posture est-elle la même chose qu'un test d'intrusion ?

Non. Une revue de posture lit la configuration : identité, réseau, données et journalisation. Un test d'intrusion tente d'exploiter un système en fonctionnement. Nous préciserons dans la note de cadrage lequel des deux vous achetez. Cette page décrit la revue de configuration.

Couvrez-vous AWS, Azure et Google Cloud dans une même revue ?

Oui, lorsque ces comptes sont dans le périmètre. Chaque cloud est examiné au regard de son propre CIS Benchmark et de votre standard. Les constats ne sont pas moyennés en un score unique qui masquerait un mauvais compte.

Direz-vous que nous avons réussi ?

Nous dirons quelles vérifications correspondaient au référentiel et lesquelles ne correspondaient pas, à la date de la revue. Nous ne dirons pas que le parc est certifié, et un changement ultérieur peut rouvrir un constat. Les vérifications continues existent pour que le prochain changement n'attende pas la prochaine revue annuelle.

Réservez une évaluation de sécurité cloud et listez les comptes. Le premier appel fixe le périmètre et détermine si vous avez besoin d'une revue ponctuelle ou de vérifications dans le pipeline.