Les dix erreurs de configuration cloud que l’on retrouve dans presque tous les comptes

Les rapports d’incident cloud se ressemblent. Pas de faille zéro jour, pas d’attaquant d’État : une ressource exposée que personne ne pensait exposée, une identité plus large que nécessaire, et un journal qui n’était pas activé pour le prouver. Voici les dix réglages qui reviennent, dans l’ordre où nous les rencontrons.

1. Le bucket accessible publiquement

Le classique. Une politique de bucket qui autorise la lecture à tous, un blocage d’accès public désactivé « le temps d’un test », une liste de contrôle d’accès héritée. Les données partent sans qu’aucune alerte ne se déclenche, puisqu’il n’y a pas d’intrusion.

À vérifier : le blocage d’accès public au niveau du compte et de chaque bucket, les politiques qui contiennent un principal « tout le monde », les sites statiques qui ne devraient pas en être.

2. Le port d’administration ouvert au monde

SSH, RDP, un port de base de données, une interface d’administration : un groupe de sécurité qui accepte toute adresse source sur ces ports expose la machine à l’ensemble d’internet, et aux robots qui le parcourent en continu.

À vérifier : chaque règle entrante sans restriction d’adresse source, sur les ports d’administration d’abord, puis sur tous les autres.

3. La base de données joignable depuis internet

Une base gérée avec une adresse publique et un groupe de sécurité large. Ce n’est jamais voulu ; c’est le réglage par défaut d’un assistant de création ou le reste d’une migration.

À vérifier : l’option « accessible publiquement » de chaque base, puis son groupe de sécurité.

4. Les clés d’accès éternelles

Une clé d’accès créée il y a trois ans pour un script, jamais tournée, toujours valide, dont personne ne sait plus où elle vit. Le jour où elle fuit (dépôt de code, poste de travail, ticket de support), rien ne la distingue d’un usage légitime.

À vérifier : l’âge de chaque clé, sa dernière utilisation, et si un rôle ne pourrait pas la remplacer.

5. L’identité administratrice sans second facteur

Un compte avec les pleins droits, protégé par un mot de passe seul. Les campagnes d’hameçonnage visent exactement ces comptes.

À vérifier : la liste des identités à droits larges, et pour chacune l’état du second facteur.

6. Le rôle qui peut tout faire

Une politique en étoile attachée à un rôle d’instance ou de fonction « pour que ça marche ». La machine qui le porte devient le point d’entrée vers tout le compte.

À vérifier : les permissions effectives de chaque rôle, pas les politiques déclarées ; ce que le rôle a réellement utilisé ces quatre-vingt-dix jours.

7. Le service de métadonnées en version 1

Sur une instance exposée, une faille web ordinaire suffit alors à voler les identifiants du rôle. Un paramètre à changer, souvent laissé par défaut.

À vérifier : les instances dont les jetons de métadonnées sont facultatifs, en commençant par celles qui ont une adresse publique.

8. Les journaux désactivés ou non conservés

Journal d’activité du compte non activé dans une région, journaux de bucket absents, journaux de flux réseau jamais créés. Au moment de l’incident, impossible de dire ce qui s’est passé, ni depuis quand.

À vérifier : le journal d’activité dans toutes les régions, sa durée de conservation, sa protection contre la suppression.

9. Le chiffrement au repos laissé de côté

Un volume, un instantané, une base ou un bucket non chiffrés. Rarement l’origine d’un incident, toujours un aggravant, et une non-conformité directe sur la plupart des référentiels.

À vérifier : les ressources de stockage sans chiffrement, et les instantanés partagés avec d’autres comptes.

10. Le secret dans un endroit lisible

Un mot de passe dans une variable d’environnement de fonction, une clé privée dans un bucket, un jeton dans un dépôt de code. Le secret finit toujours par se retrouver là où quelqu’un peut le lire.

À vérifier : les variables d’environnement des fonctions et conteneurs, le contenu des buckets et des disques, l’historique des dépôts.

Ce que la liste ne dit pas

Aucun de ces dix points n’est grave seul. Un bucket public qui ne contient que des images publiques n’est pas un incident. Un rôle large sur une machine isolée non plus. L’incident, c’est la combinaison : la machine publique (2) avec IMDSv1 (7) et un rôle large (6) qui lit un bucket (1) contenant des données clients. Vérifiez la liste, puis vérifiez les combinaisons.

C’est le travail d’un scanner de configuration couplé à un graphe des relations entre ressources. Ctadel vérifie ces dix points sur six clouds, et relie les constats pour montrer les chemins qu’ils forment ensemble. La page Configuration cloud détaille ce qui est vérifié ; la démonstration en ligne montre le résultat sur un compte fictif.