---
title: "10 contrôles AWS pour DORA : la checklist | Silamir Group"
description: "Les 10 contrôles AWS qui répondent aux articles 8 à 12 de DORA : root, MFA, chiffrement, CloudTrail, GuardDuty, sauvegardes. Références CIS v5.0 et FSBP."
url: https://audit.aws.silamir.com/fr/ressources/10-controles-aws-dora
lang: fr
updated: 2026-10-23
---

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.

Publié le 23 octobre 2026 · 7 min de lecture

## 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/0` ou `::/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.

[Faire l'auto-diagnostic gratuit](https://audit.aws.silamir.com/fr/ressources/auto-diagnostic-aws)

## À lire aussi

- **[ISO 27001 et NIS 2 sur AWS](https://audit.aws.silamir.com/fr/ressources/iso-27001-nis2-aws)**: ISO 27001 et NIS 2 sur AWS : contrôles de l'annexe A et mesures de l'article 21 vérifiables dans vos comptes, part d'AWS, limites d'un audit et preuves à produire.
- **[Guide CIS v5.0](https://audit.aws.silamir.com/fr/ressources/guide-cis-aws-v5)**: CIS AWS Foundations Benchmark v5.0 : contrôles IAM, stockage, journalisation, surveillance et réseau, nouveautés et passage depuis v3.0 dans Security Hub.
- **[Checklist sécurité AWS](https://audit.aws.silamir.com/fr/ressources/checklist-securite-aws)**: 40 points à vérifier pour sécuriser un compte AWS : compte root, IAM, CloudTrail, GuardDuty, chiffrement, réseau, applications exposées et sauvegardes.

## 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](https://aws.amazon.com/marketplace/pp/prodview-llvpm5sa4mljs) · [Voir le fonctionnement](https://audit.aws.silamir.com/fr/fonctionnement)
