Le contexte
Une startup francaise du secteur sante m'a mandate pour auditer son infrastructure AWS. Leur application stocke des donnees de sante utilisateurs — des donnees de categorie speciale au sens du GDPR Article 9, le niveau de protection le plus eleve qui existe.
Le resultat de l'audit : 36 failles identifiees, dont 9 critiques. Un score de securite AWS Well-Architected de 2 sur 10.
Voici les problemes majeurs que j'ai trouves, et comment les corriger.
L'etat des lieux
| Framework | Score | Verdict |
|---|---|---|
| AWS Well-Architected (Security) | 2/10 | Defaillant |
| ISO 27001:2022 | 18/100 | Non certifiable — 30 non-conformites |
| SOC2 Type II | 15/100 | Non auditable |
| GDPR Article 32 | 20/100 | Violations materielles |
1. Base de donnees exposee sur internet
La base de donnees de production — contenant toutes les donnees de sante — etait accessible publiquement depuis internet. Elle n'etait protegee que par un security group autorisant des adresses IP specifiques.
Si ce security group est modifie par erreur (un clic dans la console AWS), toute la base devient ouverte au monde.
En plus :
- Pas de protection contre la suppression accidentelle
- Le mot de passe n'avait pas ete change depuis 3.5 ans
- Une adresse IP personnelle etait whitelistee pour l'acces direct
Solution : Migrer la base en sous-reseau prive (isole), activer la deletion protection, et mettre en place la rotation automatique des credentials via AWS Secrets Manager.
2. Zero monitoring de securite
Chaque service de monitoring AWS etait desactive :
- Pas de CloudTrail (aucune trace de qui fait quoi)
- Pas de GuardDuty (aucune detection de menaces)
- Pas de AWS Config (aucun suivi des changements de configuration)
- Pas de VPC Flow Logs (aucune visibilite reseau)
En cas de breach, l'entreprise ne pouvait ni detecter l'intrusion, ni l'investiguer, ni la signaler aux autorites dans les 72 heures requises par le GDPR.
Solution : Activer CloudTrail dans toutes les regions, deployer GuardDuty, configurer AWS Config avec les regles de conformite, et mettre en place des alertes CloudWatch.
3. Secrets en clair dans CloudFormation
Les cles de production Stripe (sk_live_...), les secrets webhook, et les cles API de services tiers etaient visibles en clair dans les templates CloudFormation — accessibles a quiconque avec un acces basique en lecture.
Pire : staging et production utilisaient les memes cles API pour certains services.
Solution : Migrer tous les secrets vers AWS Secrets Manager, les referencer par ARN dans CloudFormation, et separer les cles staging/production.
4. Staging et production dans le meme compte
Les deux environnements cohabitaient dans un seul compte AWS. Un credential compromis en staging donnait acces a la production. Le pipeline CI/CD avait des droits administrateur sur les deux environnements avec un mot de passe non renouvele depuis 18 mois.
Solution : Architecture multi-comptes AWS Organizations :
- Compte production (isole)
- Compte staging (isole)
- Compte shared (CI/CD, artefacts)
- Compte securite (logs centralises)
5. Zero MFA, SSH ouvert au monde
Aucun compte n'avait l'authentification a deux facteurs activee. Meme pas le compte root. SSH etait ouvert sur 0.0.0.0/0 en staging ET en production.
Solution : MFA obligatoire sur tous les comptes, migration vers AWS SSO/Identity Center, fermeture immediate de SSH publique, utilisation de Session Manager pour l'acces aux instances.
Le livrable
J'ai livre :
- Rapport d'audit complet : 36 findings categorises (critique, haut, moyen, bas) avec references aux frameworks (ISO 27001, SOC2, GDPR, AWS Well-Architected)
- Plan de remediation technique : architecture multi-comptes, stacks CloudFormation, graphe de dependances et ordre d'execution
- Estimation chiffree : deux options (15-22K EUR securite seule, 22-31K EUR avec modernisation conteneurs)
- Briefing CEO non-technique : resume des risques en langage business, consequences juridiques et financieres, recommandation
Ce que j'en retiens
La majorite des startups que j'audite ont des problemes similaires. L'infrastructure a ete montee rapidement pour livrer le produit, et la securite a ete repoussee "a plus tard". Le probleme, c'est que "plus tard" arrive generalement sous la forme d'un incident.
Un audit regulier — meme leger — permet d'identifier les risques avant qu'ils ne se materialisent. C'est un investissement, pas un cout.
Vous avez des doutes sur la securite de votre infrastructure AWS ? Parlons-en.