Table des matières de l'article :
Le 18 novembre, des milliers de sites web protégés par Cloudflare ont subi des pannes graves et généralisées, donnant l'impression que « La moitié d'Internet » était hors serviceÀ première vue, cela aurait pu ressembler à une cyberattaque ou à un problème d'infrastructure mondial, mais la réalité était bien plus surprenante : une modification des autorisations d'une base de données Cela a déclenché un effet domino qui a entraîné le plantage répété de l'un des services les plus critiques de Cloudflare. La base de données en question est Cliquez MaisonIl s'agit d'une base de données colonnaire haute performance utilisée pour l'analyse en temps réel, choisie pour sa capacité à exécuter des requêtes complexes sur de grands volumes de données en un temps extrêmement court. C'est une technologie très puissante, mais — comme tout composant global et partagé — elle peut devenir un point faible en cas de changement imprévu.
Que s'est-il passé exactement ?
La gestion des bots Cloudflare repose sur un modèle d'apprentissage automatique qui analyse chaque requête HTTP en évaluant un ensemble de caractéristiques collectées à partir des systèmes internes. Ces caractéristiques sont extraites via une requête sur ClickHouse, puis intégrées dans un fichier mis à jour toutes les 5 minutes et distribué sur le réseau mondial Cloudflare. Il s'agit donc d'un mécanisme hautement dynamique et distribué: toute erreur lors de la génération ou du déploiement se propage en quelques minutes.
Modification des autorisations de la base de données
L'équipe Cloudflare procédait à une amélioration interne de ses processus de sécurité : abandon des comptes partagés au profit de comptes d'utilisateurs dédiés et des autorisations explicites. Cette étape consistait à mettre à jour les autorisations de la base de données ClickHouse utilisée par la gestion des bots. L'opération semblait parfaitement anodine. Personne n'aurait imaginé qu'une modification des accès puisse altérer le comportement d'une requête consolidée depuis des années. Et pourtant, c'est exactement ce qui s'est produit.
L'effet secondaire caché : des données dupliquées
Avant la modification, la requête renvoyait environ 60 entités de la base de données par défaut. Après la modification des autorisations, ClickHouse a commencé à lire des données non seulement de la base de données « default », mais aussi de la base de données « r0 ». Le résultat fut un sortie supérieure à 200 fonctionnalitésLe module de gestion des bots comportait un limite fixe à 200 articlesLorsque la liste a dépassé le seuil, le service n'a pas géré la situation, n'a enregistré aucune erreur, n'a activé aucun mécanisme de repli ni aucune dégradation contrôlée : il a simplement tout envoyé à crashUne condition théoriquement improbable, jamais observée auparavant, est soudainement devenue reproductible toutes les cinq minutes, en fonction du nœud générant le fichier de caractéristiques.
Parce que cela ressemblait à une attaque DDoS
Le fichier de configuration était régénéré et redistribué toutes les cinq minutes. De ce fait, certaines instances du réseau Cloudflare recevaient un fichier correct, tandis que d'autres recevaient un fichier corrompu. Il en résultait un comportement inattendu. intermittent et irrégulier: interruptions et reprises de services, nœuds entrant et sortant de manière asynchrone de l'état d'erreur. Ce schéma est également typique d'un attaque DDoS distribuée, surtout lorsqu'il touche plusieurs régions indépendantes. Pour ne rien arranger, l'incident a également provoqué… page d'état de Cloudflare, pour un problème sans aucun rapport. Une coïncidence fatale qui a induit les ingénieurs en erreur pendant plus de deux heures.
Diagnostic et résolution
Ce n'est que vers 14h30 que l'équipe a identifié la source du problème : un fichier de configuration contenant plus de 200 fonctionnalités, généré par des requêtes modifiées suite à la vérification des autorisations de ClickHouse. Une fois la cause identifiée, les ingénieurs ont stoppé la propagation du fichier défectueux et déployé une solution de remplacement. version connue sous le nom de correcteLa récupération complète a été achevée vers 17h06. deux heures et demie après une chirurgie corrective.
Leçons techniques : ce que les ingénieurs doivent retenir
1. Unwrap() tue les systèmes
Le problème le plus grave n'était pas le nombre de fonctionnalités, mais la façon dont le logiciel réagissait à l'anomalie. Le module incriminé utilisait .unwrap() En Rust : un choix pratique pour un développement rapide, mais extrêmement dangereux pour les systèmes critiques. La fonction Unwrap() suppose que l'opération réussit toujours. Si quelque chose tourne mal, cela provoque un panique ce qui interrompt l'ensemble du service, sans journalisation, sans contre-mesures, sans diagnostic. Si le système avait consigné un simple message d'erreur au lieu de planter, le problème aurait été identifié en quelques minutes. .unwrap() dans un pipeline mondial peut provoquer un incident international.
2. Les modifications de la base de données globale sont grenades à fragmentation
Une modification des permissions semblait anodine. Pourtant, dans un système complexe et distribué, même ce qui paraît impossible peut engendrer des effets secondaires dans des sous-systèmes sans lien direct avec cette modification. Les environnements de test ne répliquent jamais parfaitement une infrastructure globale. L'idée qu'une simple modification puisse entraîner la duplication des résultats de requêtes ne figurait pas parmi les risques envisagés. Et pourtant, c'est précisément ce qui s'est produit. La leçon est simple : toute modification globale peut engendrer des effets secondaires. comportements émergents inattendus.
3. Les coïncidences sont plus trompeurs que les insectes
Lorsque deux problèmes sans lien apparent surviennent simultanément, l'esprit a tendance à créer des associations inexistantes. Le plantage de la gestion des bots et la page d'état hors ligne ont rendu crédible l'hypothèse d'une attaque externe. Cloudflare est quotidiennement la cible de nombreuses tentatives d'attaque : partir de cette hypothèse est donc naturel. Cependant, cela a coûté 2,5 heures de recherche pour un problème inexistant. La leçon à retenir : Les données l'emportent toujours sur le récit..
4. Les CDN sont réels point de défaillance unique
Cet incident a mis en lumière une réalité difficile à accepter : Internet est extrêmement dépendant de quelques acteurs mondiaux. Lorsqu'un CDN comme Cloudflare tombe en panne, une grande partie du web est immédiatement impactée. La plupart des entreprises ne disposent ni d'un second CDN opérationnel, ni d'une infrastructure autonome capable d'absorber le trafic. La redondance multi-CDN existe, mais elle est coûteuse, complexe et souvent impraticable. Cette dépendance est bien réelle, et l'incident du 18 novembre l'a une fois de plus démontré.
conclusion
La panne du 18 novembre illustre parfaitement comment des détails apparemment insignifiants peuvent avoir des conséquences désastreuses sur les systèmes mondiaux. Une modification des autorisations de la base de données a altéré le comportement d'une simple requête. Le résultat inattendu a dépassé une limite stricte. Un module critique en dépendait. .unwrap() et a réagi par la panique plutôt que par une gestion de l'erreur. La diffusion mondiale du fichier défectueux toutes les cinq minutes a amplifié l'impact. Un concours de circonstances a entraîné un diagnostic erroné prolongé. Ainsi, à partir d'un simple détail technique, Des dizaines de millions de sites web sont devenus inaccessibles.C’est pourquoi, dans les architectures complexes, ce ne sont pas les attaques qui sont les plus effrayantes : ce sont les petits changements inattendus. Ou pire encore, ce sont les .unwrap() caché dans le code.
