Audit de sécurité d'un environnement AWS et sauvegardes immuables
J'ai appliqué au cloud la démarche de mon audit Active Directory : un environnement AWS mal configuré exprès, mesuré avec Prowler, corrigé par ordre de gravité, puis mesuré à nouveau.
En bref
Des sauvegardes hors site doivent survivre à un rançongiciel, et à la prise de contrôle du compte Microsoft 365 qui porte déjà la messagerie de l'entreprise.
J'ai audité un compte AWS volontairement mal configuré avec Prowler en lecture seule, appliqué huit remédiations par gravité, puis verrouillé les sauvegardes avec Object Lock.
Échecs critiques de 5 à 3 et hauts de 20 à 14, conformité de 47,8 % à 57 %, sauvegardes non supprimables pendant 30 jours, même par le compte racine.
Contexte
Une sauvegarde hors site doit survivre à la compromission du reste du système d'information. La PME où j'ai mené mes projets en production utilise Microsoft 365 pour sa messagerie : si ses sauvegardes de secours dépendaient aussi de Microsoft, un attaquant maître de ce compte atteindrait les deux d'un coup. J'ai donc retenu AWS plutôt qu'Azure, pour séparer le fournisseur d'identité des sauvegardes de celui de la messagerie.
C'est un laboratoire : un environnement volontairement mal configuré, pour mesurer l'effet de chaque correction, comme dans mon audit Active Directory.
Ce que j'ai fait
- Sécuriser le compte racineMFA, région de Paris pour garder les données dans l'Union européenne, et une alerte de budget, qui sert aussi de détecteur d'intrusion bon marché : une consommation anormale trahit un compte détourné.
- Introduire trois défauts courantsUn bucket S3 de sauvegarde public et sans versioning, une instance EC2 avec SSH ouvert à tout Internet, et un compte de service IAM doté de
AdministratorAccess, alors qu'il ne sert qu'à écrire les sauvegardes Veeam. - Auditer en lecture seuleUn compte dédié à Prowler, limité à
SecurityAuditetViewOnlyAccess: une fuite de ses clés ne permet de rien modifier. Premier scan sur les référentiels CIS, RGPD et PCI-DSS : 186 contrôles évalués, échecs concentrés sur IAM, EC2 et S3. - Corriger par ordre de gravitéHuit remédiations : SSH limité à l'adresse de l'administrateur, accès publics S3 bloqués au niveau du compte, CloudTrail, chiffrement EBS par défaut, versioning, et pour IAM le moindre privilège, la MFA et la suppression d'une clé superflue.
- Rendre les sauvegardes immuablesSecond bucket avec Object Lock en mode Conformité : même le compte racine ne peut pas supprimer un objet avant la fin de sa rétention. Chiffrement SSE-KMS avec une clé que je gère, chaque utilisation tracée dans CloudTrail.
Voir les détails techniques
| Ressource | Défaut introduit | Risque |
|---|---|---|
| Bucket S3 de sauvegarde | Accès public autorisé, pas de versioning | Sauvegardes lisibles depuis Internet ; un fichier écrasé ou supprimé est perdu |
| Instance EC2 | SSH ouvert à toute adresse Internet | Administration exposée au monde entier |
| Compte de service IAM | Politique AdministratorAccess complète | Sa clé, si elle est volée, ouvre tout le compte AWS |
Premier scan : échecs IAM (30), EC2 (15) et S3 (11).
Les cinq échecs critiques du premier scan
| Contrôle Prowler | Ce qui le déclenchait | Correction |
|---|---|---|
| EC2 : SSH (port 22) ouvert depuis Internet | L'instance au SSH ouvert à toute adresse, défaut introduit | SSH limité à l'adresse de l'administrateur |
| IAM : utilisateur doté de AdministratorAccess | Le compte de service des sauvegardes, défaut introduit | Politique sur mesure : écrire dans le bucket, rien d'autre |
| IAM : utilisateur doté de AdministratorAccess | Un second utilisateur IAM | — |
| IAM : politique gérée par AWS accordant « *:* » | AdministratorAccess attachée à un utilisateur | — |
| IAM : MFA matérielle sur le compte racine | Une MFA est active sur le compte racine, mais pas sur une clé matérielle | — |
Sur ces 25 échecs critiques et hauts, 16 touchent deux familles : les identités (11 : MFA, droits d'administration, clés à longue durée de vie) et l'exposition réseau (5 : SSH, groupes de sécurité et ACL ouverts à tout Internet). Les neuf autres portent surtout sur la journalisation, les disques (chiffrement, instantanés) et les accès publics S3.
| Correction | Gravité | Pourquoi |
|---|---|---|
| SSH limité à l'adresse IP de l'administrateur | Critique | L'administration n'est plus exposée à tout Internet |
| Accès publics S3 bloqués, au niveau du compte et du bucket | Haute | Le blocage au niveau du compte empêche qu'un futur bucket soit rendu public par erreur |
| CloudTrail activé sur toutes les actions | Haute | Savoir qui a fait quoi, et quand |
| Chiffrement EBS par défaut | Haute | Tout nouveau disque est chiffré, sans dépendre d'un oubli |
| Versioning du bucket | Moyenne | Une sauvegarde écrasée ou supprimée reste récupérable |
Côté identités : AdministratorAccess retiré du compte de service et remplacé par une politique sur mesure qui l'autorise seulement à écrire dans le bucket de sauvegarde (une clé volée n'ouvre plus que ce dont le service a besoin), MFA sur le compte d'administration, et suppression d'une clé d'accès programmatique superflue, car une clé qui ne sert à rien ne peut que fuiter.
Pourquoi le mode Conformité. En mode Gouvernance, un compte doté d'une permission particulière peut lever le verrou : exactement ce qu'utiliserait un attaquant devenu administrateur. Le second bucket, corp-backup-immutable, a reçu Object Lock dès sa création, avec une rétention de 30 jours.
| Scan | Contrôles évalués | Conformité |
|---|---|---|
| 1 · état initial | 186 | 47,8 % |
| 2 · après 8 remédiations | 213 | 57,3 % |
| 3 · après KMS et Object Lock | 232 | 57,0 % |
Résultats
Entre le deuxième et le troisième scan, le taux recule légèrement (57,3 % puis 57,0 %) alors que la configuration s'est améliorée. La raison : Prowler n'audite que ce qui existe. Activer CloudTrail ou créer le second bucket ajoute de nouveaux contrôles, dont une partie échoue au départ ; le nombre de contrôles passe de 186 à 232.
Un taux de conformité ne mesure donc pas seul une progression : il se lit avec le nombre de contrôles évalués et les échecs par gravité, qui baissent nettement (critiques de 5 à 3, hauts de 20 à 14).
Ce que j'améliorerais
- Traiter les familles de contrôles encore en échec (3 critiques, 14 hauts) : alertes sur les événements sensibles de CloudTrail, journaux de flux réseau, détection des menaces native d'AWS, gestion des identifiants IAM.
- Automatiser le scan Prowler à intervalle régulier et raccorder CloudTrail au SIEM Wazuh, pour qu'un changement de politique ou la suppression d'une clé déclenche une alerte.
- Comparer les deux options pour l'immuabilité : AWS permet aujourd'hui d'activer Object Lock sur un bucket existant dont le versioning est actif ; un bucket neuf garde l'avantage de tout verrouiller dès la première écriture.
Compétences
Pour aller plus loin
- Un score de conformité qui baisse quand on progresse : Un laboratoire AWS audité avec Prowler, un taux de conformité qui recule alors que la configuration s'améliore, et les deux chiffres qui permettent de le lire.