Guide
CIS AWS Foundations Benchmark v3.0 : le guide des contrôles
Ce que contient le benchmark CIS pour AWS, section par section, par où commencer et comment suivre votre conformité dans la durée.
Qu'est-ce que le CIS AWS Foundations Benchmark ?
Le Center for Internet Security (CIS) publie des référentiels de durcissement élaborés par consensus entre praticiens. Le CIS AWS Foundations Benchmark décrit la configuration de base attendue d'un compte AWS : identités, stockage, journalisation, surveillance et réseau.
- La version 3.0.0 est la référence actuelle ; AWS Security Hub propose un standard CIS v3.0.0 qui évalue automatiquement une partie de ses recommandations.
- Chaque recommandation est classée en niveau 1 (socle raisonnable pour tous) ou niveau 2 (défense en profondeur, pour les environnements sensibles).
- Certaines recommandations sont automatisables (vérifiables par API), d'autres manuelles (coordonnées de contact, questions de sécurité, revue de processus).
- Le benchmark n'est pas une certification : c'est une grille d'évaluation, souvent reprise par les auditeurs externes.
Les cinq sections du benchmark
| Section | Ce qu'elle couvre |
|---|---|
| 1. Identity and Access Management | Compte root, MFA, politique de mots de passe, clés d'accès, moindre privilège, IAM Access Analyzer. |
| 2. Storage | S3 (accès public, HTTPS, MFA Delete), chiffrement EBS par défaut, RDS et EFS. |
| 3. Logging | CloudTrail multi-région, intégrité et chiffrement des journaux, AWS Config, rotation des clés KMS, journaux de flux VPC. |
| 4. Monitoring | 15 filtres de métriques et alarmes CloudWatch sur les événements sensibles, Security Hub activé. |
| 5. Networking | NACL et groupes de sécurité sur les ports d'administration, groupe de sécurité par défaut, peering VPC, IMDSv2. |
Section 1 : protéger le compte root et les identités
C'est la section la plus fournie, et celle où se trouvent les écarts les plus graves.
- Compte root : aucune clé d'accès, MFA activé (matériel au niveau 2), usage réservé aux rares tâches qui l'exigent.
- Mots de passe : 14 caractères minimum, pas de réutilisation des 24 derniers.
- MFA pour chaque utilisateur IAM disposant d'un accès console.
- Identifiants inutilisés : désactivés au-delà de 45 jours ; une seule clé active par utilisateur, tournée tous les 90 jours.
- Moindre privilège : permissions attribuées par groupe ou par rôle, aucune politique donnant
*:*, un rôle dédié au support AWS, des rôles d'instance plutôt que des clés sur les serveurs. - IAM Access Analyzer activé, pour repérer les accès externes non voulus.
Section 2 : stockage
- S3 : refus des requêtes HTTP non chiffrées dans la politique de bucket, Block Public Access au niveau du compte et des buckets, MFA Delete sur les buckets critiques.
- EBS : chiffrement par défaut activé dans chaque région.
- RDS : chiffrement au repos, mises à jour mineures automatiques, pas d'accès public.
- EFS : systèmes de fichiers chiffrés.
Section 3 : journalisation
- CloudTrail activé dans toutes les régions, avec validation d'intégrité des fichiers et chiffrement par une clé KMS gérée par vous.
- Journalisation des accès sur le bucket S3 qui reçoit CloudTrail, et journalisation des lectures et écritures d'objets S3.
- AWS Config activé dans toutes les régions.
- Rotation activée sur les clés KMS symétriques.
- Journaux de flux VPC activés, au minimum sur le trafic rejeté.
Section 4 : surveillance
Les recommandations 4.1 à 4.15 demandent un filtre de métriques et une alarme CloudWatch sur les journaux CloudTrail, pour être alerté quand :
- des appels d'API sont refusés, une connexion console a lieu sans MFA ou échoue, le compte root est utilisé ;
- une politique IAM, la configuration de CloudTrail ou d'AWS Config, ou la politique d'un bucket S3 change ;
- une clé KMS est désactivée ou programmée pour suppression ;
- un groupe de sécurité, une NACL, une passerelle réseau, une table de routage ou un VPC est modifié ;
- la structure d'AWS Organizations change.
La recommandation 4.16 demande que Security Hub soit activé. Sans ces alarmes, un incident peut passer inaperçu pendant des semaines.
Section 5 : réseau
- Aucune NACL ni aucun groupe de sécurité n'autorise
0.0.0.0/0(ni::/0) vers les ports d'administration, comme 22 (SSH) et 3389 (RDP). - Le groupe de sécurité par défaut de chaque VPC bloque tout le trafic.
- Les routes de peering VPC sont limitées au strict nécessaire.
- Les instances EC2 exigent IMDSv2 pour le service de métadonnées.
Par où commencer
Si vous partez de loin, traitez d'abord ce qui ferme les risques majeurs :
- MFA sur le compte root, et suppression de ses clés d'accès.
- CloudTrail multi-région avec validation d'intégrité.
- S3 Block Public Access au niveau du compte.
- Fermeture des ports d'administration ouverts à Internet.
- MFA sur tous les accès console.
- Puis les alarmes de la section 4, qui vous préviennent si l'un de ces réglages est défait.
Suivre la conformité dans la durée
- Activez le standard CIS v3.0.0 de Security Hub dans chaque région utilisée : il réévalue en continu les contrôles automatisables.
- Complétez par des règles AWS Config pour les contrôles propres à votre contexte.
- Faites auditer régulièrement le compte : l'audit Silamir calcule un score CIS v3.0 distinct du score FSBP, liste les contrôles en échec avec les ressources concernées et les priorise avec le reste des constats.
Prêt à auditer votre compte AWS ?
Souscrivez sur AWS Marketplace, déployez le rôle en lecture seule et recevez vos rapports dans l'heure.