DORA
10 contrôles AWS pour DORA
DORA ne liste aucun réglage AWS : il fixe des principes de protection, de détection et de reprise. Voici les dix contrôles de configuration AWS qui y répondent le plus directement, l'article de DORA qu'ils servent, et les références CIS v5.0 et FSBP pour les vérifier.
En résumé
- DORA s'applique depuis le 17 janvier 2025 aux entités financières de l'Union. Ses articles 8 à 12 portent sur l'identification, la protection, la détection, la réponse et la sauvegarde.
- AWS est prestataire tiers critique depuis novembre 2025, mais la configuration de vos comptes reste sous votre responsabilité.
- Les dix contrôles couvrent l'inventaire, les identités, le chiffrement, l'exposition, la journalisation, la détection, les sauvegardes et la reprise.
- Chacun se vérifie dans la configuration, avec les contrôles CIS AWS Foundations v5.0 et AWS Foundational Security Best Practices (FSBP) cités.
Pourquoi ces dix contrôles
Le règlement (UE) 2022/2554 et son règlement délégué (UE) 2024/1774 décrivent ce que doit couvrir le cadre de gestion du risque TIC, sans prescrire de technologie. Sur AWS, une partie de ces exigences se traduit en paramètres vérifiables.
Les dix contrôles ci-dessous ont été retenus parce qu'ils répondent chacun à un article précis de DORA, qu'ils se constatent dans la configuration d'un compte, et qu'une autorité de contrôle peut raisonnablement demander à les voir. Ils ne couvrent ni la gouvernance, ni la gestion des incidents, ni les contrats avec vos prestataires.
1. Un inventaire des ressources à jour et balisé
DORA, article 8 : identifier et classer les actifs TIC, et les dépendances qui soutiennent les fonctions critiques ou importantes.
- Activer AWS Config dans chaque région utilisée, pour garder l'historique de chaque ressource.
- Baliser les ressources par application, environnement et niveau de criticité, et imposer ces tags par une Tag Policy d'AWS Organizations.
- Références : CIS 3.3, FSBP Config.1.
2. Un compte root verrouillé
DORA, article 9 : limiter l'accès physique et logique aux seuls besoins légitimes. Le compte root d'AWS peut tout faire, y compris fermer le compte.
- Aucune clé d'accès sur le compte root, et un MFA matériel.
- Un usage réservé aux rares tâches qui l'exigent, surveillé par une alarme.
- Références : CIS 1.3 à 1.6 et 4.3, FSBP IAM.4, IAM.6 et IAM.9.
3. Une authentification forte et des identités fédérées
DORA, article 9 : mettre en place des mécanismes d'authentification forte. Le règlement délégué 2024/1774 détaille le contrôle des accès et la gestion des identités.
- MFA pour chaque utilisateur disposant d'un accès console, et de préférence plus aucun utilisateur IAM : des identités fédérées par IAM Identity Center.
- Clés d'accès inutilisées désactivées après 45 jours, clés actives tournées tous les 90 jours.
- Références : CIS 1.9, 1.11, 1.13 et 1.20, FSBP IAM.5.
4. Le moindre privilège, et aucun accès externe non voulu
DORA, article 9 : n'accorder que les droits nécessaires à la fonction. Un rôle trop large ou partagé avec un compte tiers est souvent le premier maillon d'une attaque.
- Aucune politique donnant
*:*, des permissions attribuées par rôle ou par groupe. - IAM Access Analyzer activé dans toutes les régions, et ses constats d'accès externes traités.
- Références : CIS 1.14, 1.15 et 1.19, FSBP IAM.1.
5. Un chiffrement au repos maîtrisé
DORA, article 9 : protéger la confidentialité et l'intégrité des données. Le règlement délégué 2024/1774 demande une politique de chiffrement et de gestion des clés.
- Chiffrement EBS activé par défaut dans chaque région, bases RDS et systèmes EFS chiffrés.
- Clés KMS gérées par vous pour les données sensibles, avec rotation activée.
- Références : CIS 2.2.1, 2.3.1, 3.6 et 5.1.1, FSBP EC2.7, KMS.4 et RDS.3.
6. Aucune exposition publique non voulue
DORA, article 9 : protéger les réseaux et prévenir les accès non autorisés. Un bucket public ou un port SSH ouvert sur Internet annule les autres protections.
- Block Public Access activé au niveau du compte et de chaque bucket S3.
- Aucun groupe de sécurité ni aucune NACL n'ouvre les ports d'administration (22, 3389) à
0.0.0.0/0ou::/0; le groupe par défaut bloque tout. - Références : CIS 2.1.4 et 5.2 à 5.5, FSBP S3.1 et S3.8.
7. Une journalisation complète et infalsifiable
DORA, articles 10 et 12 : détecter les activités anormales et conserver les traces nécessaires à l'analyse d'un incident.
- CloudTrail actif dans toutes les régions, avec validation d'intégrité des fichiers et chiffrement par une clé KMS.
- Journaux de flux VPC activés, au minimum sur le trafic rejeté, et une durée de conservation définie.
- Références : CIS 3.1, 3.2, 3.5 et 3.7, FSBP CloudTrail.1, CloudTrail.2, CloudTrail.4 et EC2.6.
8. Une détection active des menaces
DORA, article 10 : disposer de mécanismes de détection rapide, avec des seuils d'alerte définis.
- GuardDuty activé dans toutes les régions, et ses constats remontés à une équipe qui les traite.
- Security Hub activé avec les standards FSBP et CIS v5.0, et des alarmes CloudWatch sur les événements sensibles : connexion root, changement de politique IAM, arrêt de CloudTrail, modification de groupe de sécurité.
- Références : CIS 4.1 à 4.16, FSBP GuardDuty.1.
9. Des sauvegardes isolées et restaurables
DORA, article 12 : définir des politiques de sauvegarde, restaurer à partir de systèmes séparés de la source, et tester régulièrement la restauration.
- Des plans AWS Backup couvrant les ressources critiques, avec copie vers un autre compte ou une autre région.
- Un coffre de sauvegarde verrouillé (AWS Backup Vault Lock) contre la suppression, et des tests de restauration planifiés.
- Références : FSBP RDS.11 et DynamoDB.2 ; AWS Backup restore testing pour les essais.
10. Une architecture qui tient les objectifs de reprise
DORA, articles 11 et 12 : une politique de continuité, des plans de réponse et de rétablissement, et des objectifs de temps et de point de reprise.
- Bases de données en Multi-AZ, charges de travail réparties sur plusieurs zones de disponibilité, contrôles de santé Route 53.
- Des RTO et RPO documentés pour chaque fonction critique, et une reprise multi-région ou AWS Elastic Disaster Recovery quand l'objectif l'exige.
- Références : CIS 2.2.4, FSBP RDS.5.
Les dix contrôles en un tableau
| Contrôle | DORA | Références |
|---|---|---|
| Inventaire et balisage | Art. 8 | CIS 3.3 · Config.1 |
| Compte root verrouillé | Art. 9 | CIS 1.3-1.6 · IAM.4, IAM.6, IAM.9 |
| Authentification forte, identités fédérées | Art. 9 | CIS 1.9, 1.11, 1.13, 1.20 · IAM.5 |
| Moindre privilège, accès externes | Art. 9 | CIS 1.14, 1.15, 1.19 · IAM.1 |
| Chiffrement au repos | Art. 9 | CIS 2.2.1, 2.3.1, 3.6, 5.1.1 · EC2.7, KMS.4, RDS.3 |
| Aucune exposition publique | Art. 9 | CIS 2.1.4, 5.2-5.5 · S3.1, S3.8 |
| Journalisation infalsifiable | Art. 10, 12 | CIS 3.1, 3.2, 3.5, 3.7 · CloudTrail.1, .2, .4, EC2.6 |
| Détection des menaces | Art. 10 | CIS 4.1-4.16 · GuardDuty.1 |
| Sauvegardes isolées et testées | Art. 12 | RDS.11, DynamoDB.2 |
| Objectifs de reprise | Art. 11, 12 | CIS 2.2.4 · RDS.5 |
Transformer ces contrôles en preuves
- Dater chaque vérification : un état de configuration n'a de valeur qu'à une date donnée.
- Nommer les ressources en écart, pas seulement le nombre d'écarts, et suivre leur correction dans un registre.
- Recommencer : l'article 24 demande de tester au moins une fois par an les systèmes qui soutiennent des fonctions critiques ou importantes. Entre deux revues, AWS Config et Security Hub surveillent en continu.
- Remonter à la direction : l'article 5 fait porter à l'organe de direction la responsabilité finale du risque TIC.
L'audit Silamir couvre ces dix thèmes sur un compte AWS, cite chaque ressource en écart et produit un plan d'action priorisé et une synthèse pour la direction, pour 299 USD par audit. Il ne réalise pas les tests de restauration eux-mêmes et ne délivre pas de certification DORA.
Contrôles AWS et DORA : questions fréquentes
DORA impose-t-il des réglages AWS précis ?
Non. DORA et son règlement délégué 2024/1774 fixent des exigences de principe : contrôle des accès, chiffrement, journalisation, sauvegarde, continuité. Les référentiels CIS AWS Foundations v5.0 et FSBP permettent de les traduire en contrôles vérifiables sur AWS.
AWS étant prestataire critique, ces contrôles sont-ils encore nécessaires ?
Oui. La désignation place AWS sous la supervision directe des autorités européennes, mais l'article 28 de DORA rappelle que l'entité financière reste pleinement responsable de ses obligations. La configuration de vos comptes relève de vous.
Ces dix contrôles suffisent-ils pour être conforme à DORA ?
Non. Ils fournissent des éléments de preuve pour les articles 8 à 12, sur vos comptes AWS. DORA couvre aussi la gouvernance, la gestion et la notification des incidents, les tests, le registre d'informations et les contrats avec les prestataires.
À quelle fréquence vérifier ces contrôles ?
En continu avec AWS Config et Security Hub, et au moins une fois par an dans le cadre d'une revue datée, comme le prévoit l'article 24 pour les systèmes qui soutiennent des fonctions critiques ou importantes.
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.
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.