Étude de cas
CybersécuritéSuivi et encadrement de pentest
Contexte
Le pentest se déroulait dans une grande entité publique, avec de fortes exigences de sécurité. Un prestataire externe devait éprouver l’exposition réelle du système, et il était hors de question de le laisser travailler sur la production. J’ai monté un environnement dédié, où il pouvait frapper sans conséquence, et j’ai écrit noir sur blanc ce qu’il avait le droit de toucher. Il fallait aussi pouvoir relire chaque tentative après coup, une fois la campagne terminée. La plateforme auditée, je l’avais co-conçue : je connaissais l’architecture, ce qui aide à cadrer l’audit. Ça ne remplace pas un regard extérieur, et c’était tout l’intérêt de faire appel à quelqu’un d’autre.
Le défi
Piloter le pentest de bout en bout sans jamais exposer le SI : monter un environnement d’audit cloisonné et reproductible sur du cloud public, en suivre l’activité, encadrer la campagne du premier jour jusqu’au retest, et faire qualifier, corriger puis revérifier les vulnérabilités trouvées.
Ouverture contrôlée
Un auditeur a besoin d’accès pour travailler ; une entité à hautes exigences de sécurité ne peut pas ouvrir les siens. D’où un environnement d’audit dédié, isolé du reste du SI, vivant le temps de la campagne et détruit ensuite.
Boîte noire puis boîte grise
Tout donner d’entrée fausse le test : le rapport décrit alors ce qu’on a montré, pas ce qu’un attaquant aurait trouvé seul. Ne rien donner du tout brûle du temps d’audit sur de la reconnaissance déjà faite en interne.
Traçabilité
Un tiers autorisé à attaquer doit pouvoir être suivi. Sans télémétrie sur l’environnement d’audit, aucune réponse possible à la question « qu’est-ce qui a été tenté, sur quoi, et quand ? ».
L’approche
01 · L’environnement d’audit
Une réplique cloisonnée, montée automatiquement
Le périmètre exposé est reproduit chez Scaleway, dans un environnement séparé du SI : le prestataire attaque une copie, jamais la production. Tout est monté en infrastructure as code : le même environnement se remonte à l’identique en rejouant le code. Il ne survit pas à la campagne, il est détruit à la fin, et c’est prévu dès le départ.
02 · Le cloisonnement
Segmentation réseau et flux minimaux
Le réseau d’audit est découpé en VPC séparés, un par zone exposée, et chaque flux ouvert vers l’extérieur ou entre VPC est justifié par un besoin de test précis. Le prestataire ne voit que ce que l’audit exige, ni le reste du SI ni les réseaux d’administration.
03 · La visibilité
Télémétrie pendant toute la campagne
Logs, métriques et alerting sur l’environnement d’audit : on voit la campagne avancer en direct, on détecte une sortie de cadre, et on peut reconstituer après coup le déroulé d’une tentative. Sans ces traces, impossible de répondre à un auditeur qui demanderait ce qui a été tenté.
04 · Le déroulé
Boîte noire d’abord, boîte grise au fil de l’eau
La campagne démarre sans aucun contexte : le prestataire explore ce que verrait un attaquant. Puis les informations s’ouvrent progressivement, selon l’avancement : on ne partage une cartographie ou une piste que quand elle évite de rejouer une reconnaissance déjà faite, pour dépenser le temps d’audit là où il reste du terrain.
05 · La sortie
Corriger les findings, puis revérifier
Les vulnérabilités remontées sont qualifiées avec le prestataire, pas recopiées du rapport : priorisation par exposition réelle, correction, puis revérification de chaque point. La campagne ne se clôture qu’une fois les findings refermés.
Les résultats
Aucune vulnérabilité critique
La campagne n’a remonté que quelques vulnérabilités, aucune critique, toutes corrigées puis revérifiées avant la clôture.
Architecture validée par un tiers
Pas de faille critique, et ce n’est pas de la chance : peu de surface exposée, durcissement posé dès la conception.
Choix de design confirmés
Les partis pris de conception sortent validés par un regard extérieur : de quoi continuer à construire dessus sans redouter l’arbitrage initial.
La stack
- Infrastructure Scaleway
- Kubernetes
- Helm
- Terraform