Guide

CIS AWS Foundations Benchmark v5.0 : le guide des contrôles

Ce que contient le benchmark CIS pour AWS dans sa version 5.0, section par section, ce qui change depuis la v3.0, par où commencer et comment suivre votre conformité dans la durée.

Publié le 27 septembre 2026 · mis à jour le 23 octobre 2026 · 5 min de lecture

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 5.0.0 compte 63 recommandations. C'est la plus récente prise en charge par AWS Security Hub CSPM, dont le standard CIS v5.0.0 est certifié par le CIS aux niveaux 1 et 2 et évalue automatiquement une partie des 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, usage du compte root, revue des routes de peering).
Le benchmark n'est pas une certification : c'est une grille d'évaluation, souvent reprise par les auditeurs externes.

Les cinq sections du benchmark

Sections du CIS AWS Foundations Benchmark v5.0.0
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, identités centralisées.
2. Storage	S3 (HTTPS, MFA Delete, classification des données, accès public), RDS (chiffrement, mises à jour, accès public, Multi-AZ) 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, journalisation des objets S3.
4. Monitoring	15 filtres de métriques et alarmes CloudWatch sur les événements sensibles, Security Hub activé.
5. Networking	EC2 (chiffrement EBS par défaut, accès CIFS), NACL et groupes de sécurité sur les ports d'administration, groupe de sécurité par défaut, peering VPC, IMDSv2.

Ce qui change par rapport à la v3.0

Les sections 3 et 4 gardent leur numérotation. Les sections 1, 2 et 5 sont renumérotées : un écart cité « CIS 1.10 » dans un rapport v3.0 s'appelle « CIS 1.9 » en v5.0.

Principales différences entre CIS AWS Foundations v3.0.0 et v5.0.0
Sujet	v3.0.0	v5.0.0
Questions de sécurité du compte	1.3	Retirée ; les recommandations suivantes de la section 1 remontent d'un rang
MFA du root / MFA des utilisateurs console	1.5 / 1.10	1.4 / 1.9
IAM Access Analyzer / AWSCloudShellFullAccess	1.20 / 1.22	1.19 / 1.21
Chiffrement EBS par défaut	2.2.1 (section Storage)	5.1.1 (nouvelle sous-section EC2 de Networking)
RDS / EFS	2.3.x / 2.4.1	2.2.x / 2.3.1, avec une nouvelle recommandation 2.2.4 (Multi-AZ)
Accès CIFS (port 445)	Absent	5.1.2 : réservé aux réseaux de confiance
NACL, groupes de sécurité, peering, IMDSv2	5.1 à 5.6	5.2 à 5.7

Dans Security Hub, le standard v5.0.0 ajoute notamment les contrôles RDS.5 et RDS.15 (Multi-AZ) et EFS.8. Les deux versions peuvent être actives en même temps : activez la v5.0.0 avant de désactiver la v3.0.0, pour ne pas créer de trou dans l'évaluation.

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 (1.3), MFA activé (1.4, matériel en 1.5), usage réservé aux rares tâches qui l'exigent (1.6).
Mots de passe : 14 caractères minimum (1.7), pas de réutilisation (1.8).
MFA pour chaque utilisateur IAM disposant d'un accès console (1.9), sans clé d'accès créée à l'initialisation (1.10).
Identifiants inutilisés : désactivés au-delà de 45 jours (1.11) ; une seule clé active par utilisateur (1.12), tournée tous les 90 jours (1.13).
Moindre privilège : permissions attribuées par groupe (1.14), aucune politique donnant *:* (1.15), un rôle dédié au support AWS (1.16), des rôles d'instance plutôt que des clés sur les serveurs (1.17).
IAM Access Analyzer activé dans toutes les régions (1.19), pour repérer les accès externes non voulus.
Hygiène : certificats SSL/TLS expirés supprimés d'IAM (1.18), identités gérées centralement par fédération ou AWS Organizations (1.20), accès AWSCloudShellFullAccess restreint (1.21).

Section 2 : stockage

S3 : refus des requêtes HTTP non chiffrées dans la politique de bucket (2.1.1), MFA Delete sur les buckets critiques (2.1.2), Block Public Access au niveau du compte et des buckets (2.1.4).
Données S3 : découvertes, classées et protégées si nécessaire (2.1.3), par exemple avec Amazon Macie.
RDS : chiffrement au repos (2.2.1), mises à jour mineures automatiques (2.2.2), pas d'accès public (2.2.3), déploiement Multi-AZ (2.2.4).
EFS : systèmes de fichiers chiffrés (2.3.1).

Section 3 : journalisation

CloudTrail activé dans toutes les régions (3.1), avec validation d'intégrité des fichiers (3.2) et chiffrement par une clé KMS gérée par vous (3.5).
Journalisation des accès sur le bucket S3 qui reçoit CloudTrail (3.4), et journalisation des écritures et lectures d'objets S3 (3.8, 3.9).
AWS Config activé dans toutes les régions (3.3).
Rotation activée sur les clés KMS symétriques (3.6).
Journaux de flux VPC activés, au minimum sur le trafic rejeté (3.7).

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é. Security Hub ne vérifie pas lui-même ces filtres de métriques : contrôlez-les à part. Sans ces alarmes, un incident peut passer inaperçu pendant des semaines.

Section 5 : réseau

EC2 : chiffrement EBS par défaut activé dans chaque région (5.1.1), accès CIFS (port 445) réservé aux réseaux de confiance (5.1.2).
Aucune NACL (5.2) ni aucun groupe de sécurité n'autorise 0.0.0.0/0 (5.3) ni ::/0 (5.4) 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 (5.5).
Les routes de peering VPC sont limitées au strict nécessaire (5.6).
Les instances EC2 exigent IMDSv2 pour le service de métadonnées (5.7).

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 et du port 445 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 v5.0.0 de Security Hub dans chaque région utilisée : il réévalue en continu les contrôles automatisables. Si la v3.0.0 est active, gardez-la jusqu'à ce que la v5.0.0 ait produit ses premiers résultats.
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 v5.0 distinct du score FSBP, liste les contrôles en échec avec les ressources concernées et les priorise avec le reste des constats.

Où en est votre compte AWS ?

Dix questions, trois minutes, sans accès à votre compte : un score sécurité, un score FinOps et l'article à lire pour chacun de vos trois points les plus faibles. Vos réponses restent dans votre navigateur.

Faire l'auto-diagnostic gratuit

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.

Souscrire sur AWS Marketplace Voir le fonctionnement