La Commission européenne perd 350 Go de données après le piratage de son compte AWS — le modèle de responsabilité partagée a échoué au premier échelon

Le 8 août 2026, BleepingComputer révélait que la Commission européenne — l’organe exécutif de l’Union européenne — enquêtait sur une intrusion dans son environnement Amazon Web Services. Un acteur malveillant a revendiqué l’exfiltration de plus de 350 Go de données, incluant plusieurs bases de données et un serveur de messagerie interne. AWS a confirmé que ses services avaient « fonctionné comme prévu » et qu’aucun événement de sécurité n’avait affecté son infrastructure.

Ce détail — « fonctionné comme prévu » — est précisément le problème. Il pointe vers une défaillance du modèle de responsabilité partagée, et plus spécifiquement vers l’échelon le plus basique de la sécurité cloud : la gestion des identités et des accès.

Ce que l’on sait de l’intrusion

Les faits établis par BleepingComputer et ses sources proches du dossier sont les suivants :

• Au moins un compte AWS de la Commission européenne a été compromis par un acteur malveillant non identifié.
• L’attaquant affirme avoir exfiltré plus de 350 Go de données et fourni des captures d’écran montrant l’accès à des informations d’employés de la Commission ainsi qu’à un serveur de messagerie interne.
• L’intrusion a été rapidement détectée et l’équipe de réponse aux incidents de cybersécurité de la Commission est mobilisée.
• L’attaquant déclare ne pas chercher à extorquer la Commission mais prévoit de publier les données en ligne ultérieurement.
• La Commission n’a pas encore communiqué publiquement sur l’incident.

La méthode de compromission initiale n’a pas été divulguée. Aucune CVE spécifique n’est associée à cet incident à ce stade, ce qui renforce l’hypothèse d’une compromission par identité plutôt que par exploitation de vulnérabilité logicielle.

Le modèle de responsabilité partagée n’a pas protégé la Commission

Le modèle de responsabilité partagée d’AWS est clair depuis deux décennies : AWS sécurise l’infrastructure du cloud (hardware, hyperviseur, réseau physique) ; le client sécurise ce qu’il met dans le cloud (données, identités, configurations, chiffrement). La phrase « AWS n’a pas subi d’événement de sécurité » confirme que la brèche s’est produite côté client — probablement au niveau IAM, le service de gestion des identités.

Les vecteurs les plus probables, dans l’ordre :

1. Clés d’accès IAM exposées dans un dépôt de code, un fichier de configuration ou un outil CI/CD. En 2025, GitHub a détecté 39 millions de secrets exposés dans des dépôts publics. Une clé IAM avec des privilèges AdministratorAccess ou S3FullAccess suffit pour vider des buckets entiers.
2. Identifiants utilisateur IAM compromis sans authentification multi-facteurs (MFA) — une erreur qui reste étonnamment fréquente y compris dans les organisations gouvernementales.
3. Rôle IAM assumable depuis l’extérieur — un rôle mal configuré avec une trust policy trop permissive, associé à une fédération d’identité compromise.
4. Accès programmatique non surveillé — un compte de service utilisé par une application tierce ou un partenaire, jamais audité, jamais désactivé.

Dans tous ces cas, la surface d’attaque n’est pas l’infrastructure AWS mais la gestion des identités humaines et machines côté client. L’incident de la Commission européenne est le rappel que le cloud security posture management (CSPM) ne remplace pas l’hygiène IAM de base : rotation des clés, principe du moindre privilège, MFA obligatoire, suppression des identités dormantes.

350 Go de quoi ?

La taille de l’exfiltration — 350 Go — donne une indication sur la nature des données compromises. À titre de comparaison :

• 350 Go de documents bureautiques représentent environ 7 à 10 millions de pages Word ou PDF.
• 350 Go de bases de données peuvent contenir des dizaines de millions d’enregistrements structurés — correspondances internes, données de partenaires, informations contractuelles.
• 350 Go de courriels avec pièces jointes représentent plusieurs années d’archives de messagerie pour une organisation de la taille de la Commission (32 000 employés).

La mention d’un serveur de messagerie interne est particulièrement préoccupante. L’accès à la messagerie d’une institution comme la Commission européenne expose non seulement des données personnelles mais aussi des négociations diplomatiques, des échanges pré-décisionnels et des informations commerciales sensibles couvertes par des accords de confidentialité.

Pourquoi la réponse de la Commission compte

La Commission européenne est soumise au règlement (UE) 2018/1725 — l’équivalent du RGPD pour les institutions européennes. Ce règlement impose une notification sous 72 heures au Contrôleur européen de la protection des données (CEPD) en cas de violation de données personnelles. L’absence de communication publique huit jours après la détection suggère soit que l’enquête est encore en cours, soit que l’évaluation d’impact n’est pas terminée.

Mais le silence a un coût. Un acteur institutionnel qui ne communique pas sur une brèche documentée par la presse perd la confiance des États membres, des partenaires commerciaux et des citoyens européens dont les données sont potentiellement exposées. La transparence n’est pas une option — c’est une obligation réglementaire et politique.

Comment un RSSI peut éviter le même scénario

Cet incident fournit une liste de contrôle immédiatement actionnable pour toute organisation utilisant AWS :

1. Auditez toutes les clés IAM de plus de 90 jours. Désactivez celles qui n’ont pas été utilisées. Supprimez celles qui n’ont pas de propriétaire identifié.
2. Imposez le MFA sur tous les comptes IAM humains, sans exception. Activez les IAM roles pour les charges de travail machine plutôt que des clés statiques.
3. Activez AWS CloudTrail sur tous les comptes et toutes les régions, avec validation d’intégrité des logs. Une intrusion sans logs est une intrusion qu’on ne peut pas investiguer.
4. Mettez en place des SCP (Service Control Policies) pour bloquer les actions dangereuses au niveau de l’organisation AWS : désactivation de CloudTrail, création de clés IAM non restreintes, ouverture publique de buckets S3.
5. Surveillez les API calls suspects via GuardDuty et les IAM Access Analyzer findings — une clé utilisée depuis une géographie inhabituelle ou un rôle assumé par un principal externe inattendu doit déclencher une alerte immédiate.

Verdict

L’intrusion dans le compte AWS de la Commission européenne n’est pas un exploit zero-day sophistiqué. C’est l’échec prévisible de la gestion des identités dans une grande organisation qui traite le cloud comme un datacenter externalisé plutôt que comme un système distribué où chaque identité est un périmètre de sécurité.

Si votre organisation utilise AWS et que vous ne pouvez pas affirmer avec certitude que chaque clé IAM est attribuée, auditable et protégée par MFA, vous êtes dans la même situation que la Commission européenne avant le 8 août. La différence, c’est que vous avez encore le temps de corriger.

Références

• BleepingComputer — European Commission investigating breach after Amazon cloud account hack (8 août 2026)
• BleepingComputer — European Commission confirms data breach after Europa.eu hack
• AWS Shared Responsibility Model
• GitHub — Octoverse 2025: State of secrets scanning
• Règlement (UE) 2018/1725 — Protection des données pour les institutions européennes