sajjit.soti
← Retour aux projets

Étude de cas — Projet personnel de sécurité cloud

SOC Cloud auto-réparateur : de la surveillance passive à la remédiation automatisée

La plupart des outils de sécurité cloud s’arrêtent à l’alerte — un humain doit encore voir la notification, comprendre le risque, puis aller le corriger. Ce projet pose une question plus ciblée : pour une classe bien connue de mauvaises configurations, pourquoi attendre un humain ? Le résultat est un auditeur Python 24/7 qui scanne l’infrastructure AWS toutes les 60 secondes et, pour les constats les plus risqués, se corrige lui-même avant même d’alerter qui que ce soit.

60 s

Intervalle d'audit AWS continu

4

Catégories de risques automatisées

0 clic

Remédiation des règles de pare-feu exposées

24/7

Audit permanent piloté par Cron

01

Pourquoi l’auto-réparation, pas seulement l’alerte

Une règle de pare-feu qui ouvre SSH (port 22) à l’ensemble d’internet (0.0.0.0/0) est l’une des mauvaises configurations cloud les plus courantes — et les plus dangereuses. Dans un dispositif purement réactif, cette fenêtre reste ouverte le temps qu’une personne voie l’alerte et agisse. L’objectif de ce projet était de fermer cette fenêtre automatiquement : détecter l’exposition, la supprimer, puis notifier l’équipe que cela s’est produit — dans cet ordre précis.

02

Quatre catégories de défense automatisée

Auto-remédiation

Si un port de pare-feu comme SSH 22 est exposé à internet, le script supprime immédiatement la règle non sécurisée — sans étape d’approbation, sans délai.

Garde-identité

Signale les utilisateurs IAM sans MFA activé, ainsi que les clés d’accès de plus de 90 jours — les deux chemins les plus courants vers un compte AWS compromis.

Protection des données

Identifie les volumes EBS non chiffrés et les buckets S3 accessibles publiquement avant qu’ils ne deviennent un incident d’exposition de données.

Contrôle des coûts

Surveille les instances actives pour détecter le « Shadow IT » — des ressources créées en dehors du processus normal — avant qu’elles ne deviennent un dépassement de budget.

03

Comment c’est construit

L’auditeur lui-même est un script Python utilisant Boto3(le SDK d’AWS) pour interroger l’état du compte — règles de pare-feu, utilisateurs IAM, buckets de stockage, instances actives — sur une boucle fixe, planifiée avec Linux Crontoutes les 60 secondes. Les ressources AWS qu’il audite sont elles-mêmes provisionnées avec Terraform, si bien que l’environnement entier — ce qui est surveillé et l’infrastructure sur laquelle cela tourne — est défini comme du code. Quand l’auditeur trouve et corrige un problème, il envoie une notification instantanée via AWS SNS, pour qu’une remédiation ne reste jamais silencieuse.

04

Construit en deux passes

La première version fonctionnelle couvrait uniquement l’hygiène de l’infrastructure : volumes EBS non chiffrés, tags de propriété manquants, et règles de pare-feu non sécurisées. L’identité fut l’étape suivante, délibérée : après la livraison de la première phase, l’exposition IAM (utilisateurs sans MFA, clés d’accès obsolètes) était la lacune la plus évidente restante ; elle est donc devenue le cœur de la seconde passe, aux côtés des vérifications de contrôle des coûts pour les instances non gérées.

05

Ce que ce projet a appris

La sécurité n’est pas une configuration ponctuelle — c’est une boucle continue de détection, alerte et remédiation. Automatiser les parties routinières et bien comprises de cette boucle est précisément ce qui libère une équipe de sécurité pour se concentrer sur les menaces qui nécessitent réellement un jugement humain.