Cloudflare a fait du déploiement de règles de routeur un test de responsabilité en matière de résilience réseau

Résumé

• Le post-mortem public de Cloudflare pour le 17 juillet 2020 a décrit un changement de configuration réseau à Atlanta, une fenêtre de panne majeure de 27 minutes, environ la moitié du trafic perdue au pic, et un impact client mondial qui a fait des contrôles internes de trafic un problème de disponibilité client.
• La question de responsabilité est de savoir qui contrôlait les tests de règles de routeur, le déploiement progressif, la préférence de route, les garde-fous de préfixe maximum, le comportement de basculement du backbone, la communication du statut client, la vitesse de rollback et la preuve que la sécurité du déploiement a changé après l'incident.
• Ce cas n'est pas une panne cloud générique. C'est un cas de résilience réseau car les services Edge de Cloudflare, DNS, sécurité, livraison d'applications et routage de trafic font partie de la chaîne de services publics et de continuité d'activité d'autres organisations.
• Cet article traite le post-mortem de Cloudflare comme un compte rendu d'incident de première partie et utilise BGP, la résilience, SRE, NIST, CISA et les sources de statut comme contexte, pas comme preuve de routeur privé.
• La leçon durable est que le changement réseau progressif doit être prouvé, pas seulement promis: un fournisseur doit montrer comment un déploiement de règle de routeur est testé, limité, observé, annulé et empêché de se transformer en panne client partagée.

Pourquoi ce cas appartient à un dossier de risque et de responsabilité

Cloudflare a fait du déploiement de règles de routeur un test de responsabilité en matière de résilience réseau parce que l'incident du 17 juillet 2020 a exposé une caractéristique fondamentale de la dépendance cloud moderne: la décision interne de trafic d'un fournisseur peut devenir un événement de disponibilité publique pour les clients qui n'ont jamais vu le changement. Le récit d'incident de Cloudflare surhttps://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/a indiqué qu'un changement de configuration à Atlanta a causé un blackholing du trafic du backbone, l'incident principal ayant duré de 21:12 UTC à 21:39 UTC et une part substantielle du trafic ayant été affectée. Ce récit public donne une colonne vertébrale factuelle suffisamment claire pour poser des questions de responsabilité sans inventer de journaux de routeur privés.

Le problème n'est pas de savoir si Cloudflare est inhabituellement fragile. Le problème est que Cloudflare est inhabituellement important pour la disponibilité publique de nombreux clients. Les services Cloudflare peuvent se placer devant des sites Web, des API, des enregistrements DNS, des filtrages de sécurité, la protection DDoS, des applications Workers, des chemins d'accès Zero Trust et le routage de performance. Lorsqu'un fournisseur réseau avec ce rôle subit un événement de backbone ou de routage, l'incident est ressenti par de nombreux clients comme leur propre panne.

Cela fait des contrôles de déploiement du fournisseur une partie du plan de continuité du client, même si le client n'a aucun contrôle sur les routeurs du fournisseur.

La page de statut de Cloudflare surhttps://www.cloudflarestatus.com/et l'historique des statuts surhttps://www.cloudflarestatus.com/history/sont importants car la communication publique devient une partie du contrôle des incidents. Pendant une panne de fournisseur, les clients doivent décider si leur propre origine est cassée, si le DNS est impliqué, si les contrôles de sécurité bloquent le trafic, s'il existe des chemins alternatifs et si les utilisateurs doivent être invités à attendre. Une page de statut n'est pas seulement un artéfact de communication. C'est un signal opérationnel qui façonne le triage en aval.

Ce cas appartient à une série sur le risque et la responsabilité parce que le déclencheur n'était pas une intrusion criminelle ou une catastrophe naturelle. C'était un changement planifié ou autorisé du côté du fournisseur qui a rencontré un mode de défaillance. C'est exactement là où la responsabilité devrait être la plus concrète. Les changements planifiés peuvent être testés, progressifs, limités, observés, annulés et répétés. Si un fournisseur peut publier un post-mortem expliquant ce qui a échoué et ce qui va changer, le public peut demander si la réparation correspond au chemin de défaillance réel.

Le centre d'apprentissage BGP de Cloudflare surhttps://www.cloudflare.com/learning/security/glossary/what-is-bgp/, la RFC 4271 surhttps://www.rfc-editor.org/rfc/rfc4271.htmlet la NIST SP 800-189 surhttps://csrc.nist.gov/pubs/sp/800/189/finalsont utiles car ils encadrent le routage interdomaine et l'échange de trafic résilient. Ils ne constituent pas des conclusions sur les routeurs de juillet 2020. Ils aident les lecteurs à comprendre pourquoi les préférences locales, les annonces de route, le routage de trafic et les backbones de fournisseur sont des surfaces de contrôle plutôt que de la plomberie abstraite.

Le standard de responsabilité publique devrait être pratique. Qui a approuvé la règle de routeur? Comment a-t-elle été testée avant le déploiement? A-t-elle été déployée sur un site ou plusieurs? Quelle télémétrie aurait montré le blackholing avant que les clients ne le remarquent? Quel garde-fou automatique aurait dû arrêter le déplacement excessif de trafic? Quel chemin de rollback existait? Qui a décidé quand rollback? Quels contrôles de préfixe maximum, de préférence locale ou de déploiement progressif ont été modifiés par la suite?

Quels clients ont été affectés, et à quelle vitesse ont-ils pu distinguer l'événement fournisseur de leur propre incident? Le post-mortem public n'a pas besoin de divulguer des détails sensibles de dispositif pour répondre à ces questions à un niveau utile.

La défaillance de règle de routeur devient une panne client lorsque le Edge est une infrastructure partagée

L'incident de juillet 2020 est utile car il rend visible une limite de déploiement interne. Pour un ingénieur de Cloudflare, un changement de règle de routeur ou d'ingénierie du trafic peut être une opération réseau. Pour un client, c'est une disponibilité de site Web, une accessibilité d'API ou une continuité de contrôle de sécurité. Cette traduction est le cœur de la dépendance cloud. Un client peut acheter une protection DDoS, un cache CDN, DNS, un contrôle d'accès ou un Edge compute, mais pendant une panne, le client vit un seul fait de disponibilité: les utilisateurs ne peuvent pas atteindre le service de manière fiable.

La propre documentation de service de Cloudflare surhttps://developers.cloudflare.com/fundamentals/ethttps://developers.cloudflare.com/dns/montre à quel point la surface de contrôle client peut être large. La documentation Workers surhttps://developers.cloudflare.com/workers/et les informations d'interconnexion réseau surhttps://www.cloudflare.com/network-interconnect/montrent que Cloudflare n'est pas simplement un cache de site Web. C'est une plateforme Edge, un runtime développeur et un entité à l'interconnexion. Ces pages ne sont pas des preuves d'incident. Elles expliquent pourquoi les clients dépendent raisonnablement de la gestion interne des changements réseau de Cloudflare.

L'infrastructure partagée modifie le calcul de responsabilité. Si un client change sa propre règle de routeur et casse son réseau, le processus de changement du client est au centre. Si un fournisseur change une règle interne et que des milliers de clients perdent la disponibilité, le processus de changement du fournisseur devient une partie du dossier de risque de nombreux clients. Les clients n'ont peut-être pas besoin de chaque commande de routeur, mais ils ont besoin de suffisamment de preuves pour décider si les contrôles du fournisseur sont compatibles avec la criticité du client.

Cela est particulièrement vrai pour les services publics, de santé, d'urgence, financiers et civiques qui utilisent des fournisseurs Edge cloud dans le cadre de l'accès public.

L'incident démontre également pourquoi la redondance côté client est difficile. Un client peut concevoir un multi-CDN, un DNS secondaire, un basculement d'origine ou un contournement d'urgence, mais ces contrôles sont coûteux et peuvent affaiblir la posture de sécurité s'ils sont mal gérés. De nombreux clients acceptent la concentration de fournisseur parce que la fiabilité et la sécurité du fournisseur sont meilleures que ce que le client peut construire seul. Ce compromis est rationnel, mais il déplace la charge de la preuve vers le fournisseur.

Si les clients comptent sur Cloudflare pour absorber les attaques et router le trafic, Cloudflare doit montrer que son propre chemin de déploiement ne peut pas devenir l'événement de type attaque.

Le matériel SRE de Google sur la gestion de la surcharge surhttps://sre.google/sre-book/handling-overload/et la gestion de l'état critique surhttps://sre.google/sre-book/managing-critical-state/est un contexte utile car il encadre comment les systèmes distribués échouent sous la charge, le feedback et les problèmes de gestion d'état. L'incident Cloudflare était un événement de contrôle réseau, pas un cas Google SRE. Mais le vocabulaire SRE aide à poser les bonnes questions: quel signal était surveillé, quel seuil importait, quelle réponse automatisée existait, quelle décision humaine était nécessaire, et comment la réparation a été vérifiée.

Le récit public de Cloudflare de juillet 2020 a identifié des thèmes d'amélioration post-incident spécifiques, y compris des garde-fous autour de la configuration de routage. La question de responsabilité est de savoir si ces thèmes couvrent le chemin de la création du changement à l'impact client. Une réparation qui vérifie seulement la syntaxe d'une règle peut manquer le comportement du trafic. Une réparation qui surveille un seul routeur peut manquer le déplacement global. Une réparation qui repose uniquement sur une personne remarquant les rapports clients peut être tardive.

Une réparation qui ne peut pas simuler ou limiter le rayon d'explosion avant le déploiement peut encore transformer une commande en panne client.

Le déploiement progressif est un contrôle de responsabilité, pas un simple agrément technique

Le déploiement progressif est souvent décrit comme une prudence technique, mais pour les fournisseurs d'infrastructure, c'est un contrôle de responsabilité. La raison est simple: le déploiement progressif limite le nombre de clients qui peuvent être affectés avant qu'un mauvais changement ne soit détecté. Un changement global ou à fort rayon d'explosion peut être efficace opérationnellement, mais il transforme une erreur locale en incident public.

La panne de Cloudflare de juillet 2020 montre pourquoi les routeurs, les systèmes d'ingénierie du trafic et les chemins de backbone devraient être traités avec la même discipline de publication attendue du code applicatif, et dans certains cas, une discipline plus stricte.

Un déploiement réseau progressif devrait répondre à plusieurs questions avant que le changement n'atteigne un trafic large. Quel est l'effet prévu? Quelle métrique prouve l'effet? Quelle métrique prouve le dommage? Quelle est la première cellule de déploiement? Combien de temps la cellule doit-elle fonctionner avant l'expansion? Quelle porte automatisée arrête l'expansion? Quel chemin de rollback a déjà été testé? Quel signal visible par le client déclencherait la déclaration d'incident? Quel ingénieur responsable ou commandant d'incident a l'autorité d'arrêter le déploiement? Ces questions ne sont pas bureaucratiques.

Elles permettent au fournisseur de limiter le préjudice client.

Le post-mortem de Cloudflare est important car il a donné aux clients plus qu'une excuse d'une ligne. Il a décrit un chemin de défaillance et des contrôles de suivi. Le public peut encore demander si ces contrôles étaient suffisamment spécifiques. Les limites de préfixe maximum, les contrôles de préférence locale, la validation de configuration et le déploiement progressif semblent tous pertinents car ils correspondent à une défaillance de règle de routeur et de blackholing du trafic. Plus la correspondance est forte, plus la réparation est crédible.

Une déclaration générale selon laquelle le réseau a été rendu plus résilient serait plus faible car elle ne montrerait pas comment le mauvais chemin a été bloqué.

La NIST SP 800-34 Rev. 1 surhttps://csrc.nist.gov/pubs/sp/800/34/r1/finalet la NIST SP 800-160 Vol. 2 Rev. 1 surhttps://csrc.nist.gov/pubs/sp/800/160/v2/r1/finalsont utiles ici car elles définissent la planification de continuité et les concepts de cyber-résilience. Ce ne sont pas des manuels de routeur. Elles aident à traduire l'ingénierie réseau en devoirs de résilience: anticiper, résister, récupérer, adapter et valider. Un post-mortem de fournisseur devrait montrer non seulement la récupération d'un incident, mais aussi l'adaptation du système de déploiement qui a permis l'incident.

Le déploiement progressif a également un pendant communicationnel. Si le fournisseur déploie un changement risqué en cellules, il devrait avoir une détection et une segmentation de statut correspondantes. Les clients dans les régions affectées peuvent avoir besoin d'informations différentes de celles des clients hors du chemin affecté. Une page de statut globale peut masquer les différences régionales, tandis que trop de détails peuvent submerger.

L'équilibre responsable est de fournir des signaux de décision client: services affectés, régions affectées lorsque connues, heure de début, heure d'atténuation, statut actuel et action ou non-action recommandée du client.

L'incitation économique peut aller à l'encontre du progressif. Les fournisseurs mondiaux valorisent la vitesse. Les changements réseau peuvent être urgents car ils répondent à la congestion, au trafic d'attaque, au coût, à la capacité ou à la fiabilité. Mais plus un changement est rapide, meilleures doivent être les barrières. L'incident de juillet 2020 montre que la vitesse n'est pas l'ennemi; c'est la vitesse illimitée. Un fournisseur peut agir rapidement si le système prouve qu'un mauvais changement ne peut pas produire de dommage global avant la détection et le rollback.

La vitesse de rollback n'est visible que lorsque la chronologie est précise

Le récit public d'incident de Cloudflare est utile car il fournit une fenêtre temporelle. Un incident majeur de 27 minutes n'est pas un événement trivial pour les clients dont les services publics dépendent de la plateforme, mais ce n'est pas non plus une panne illimitée. La question de responsabilité est ce que la chronologie prouve. Elle peut montrer la détection, l'escalade, l'atténuation et la récupération. Elle peut aussi révéler où le système a reposé sur l'intervention humaine, où les contrôles automatisés n'ont pas fonctionné, ou où la communication de statut était en retard par rapport à la réalité opérationnelle.

Le rollback est souvent traité comme une question binaire. Soit le fournisseur a rollback, soit il ne l'a pas fait. C'est trop grossier. Un enregistrement de rollback utile explique quand le dommage a commencé, quand la télémétrie interne a montré le dommage, quand le commandement d'incident a été déclaré, quand la décision de rollback a été prise, quand l'action de rollback a commencé, quand le trafic client s'est amélioré, et quand la récupération complète a été confirmée. Ces horodatages permettent aux clients de juger de l'observabilité et de la vitesse de décision du fournisseur.

Les pages de statut peuvent fournir une partie de cet enregistrement. Les ressources de statut de Cloudflare montrent une communication publique, mais le statut public est souvent en retard sur la détection interne car le fournisseur doit vérifier les faits avant de publier. Ce retard peut être acceptable s'il est faible et expliqué. Il devient un problème de responsabilité si les clients passent à déboguer leurs propres systèmes alors que le fournisseur sait déjà qu'un événement global ou régional est en cours. Les clients ont besoin de signaux de statut assez tôt pour éviter de gaspiller un temps critique de réponse aux incidents.

L'enregistrement du rollback devrait également distinguer la récupération technique de la récupération client. Si le trafic Cloudflare récupère au niveau réseau, certains clients peuvent encore subir les conséquences du cache, de la session, du DNS, des tentatives, de la file d'attente ou du support utilisateur. Une courte panne de fournisseur peut créer un travail client plus long. Les post-mortems publics rapportent souvent la récupération du fournisseur, mais l'impact client peut inclure des tickets de support, des transactions perdues, des appels API échoués, une fatigue d'alerte, une communication d'urgence et une perte de confiance.

Cet article ne prétend pas à un chiffre quantifié de perte client pour juillet 2020 car le dossier public n'en supporte pas un. Il dit simplement que la chronologie du fournisseur n'est que le début de la responsabilité client.

La continuité du secteur public augmente les enjeux. Le matériel de résilience des infrastructures critiques de la CISA surhttps://www.cisa.gov/resources-tools/resources/critical-infrastructure-resilienceest utile car de nombreux services publics et critiques dépendent de la disponibilité Web, du DNS et du filtrage de sécurité. Une panne de fournisseur peut affecter les informations civiques, les portails publics, les communications adjacentes aux urgences et les services en ligne de base même lorsque le fournisseur n'est pas lui-même l'agence publique. Cela ne signifie pas que chaque client de Cloudflare était une infrastructure critique. Cela signifie que le processus de contrôle du fournisseur devrait être suffisamment solide pour les clients qui le sont.

La vitesse de rollback est donc une question de preuve. Un fournisseur qui peut montrer un chemin de rollback précis, des outils de rollback testés, des barrières automatisées et une amélioration visible par le client gagne plus de confiance qu'un fournisseur qui dit seulement que le service a été rétabli. Le post-mortem détaillé de Cloudflare crée la base de cette preuve. La prochaine question de responsabilité est de savoir si les clients peuvent voir des preuves continues dans les incidents ultérieurs, la transparence des statuts et les changements dans la pratique de déploiement.

Le peering, le transit et la conception du backbone font partie de la confiance client

L'incident de Cloudflare de juillet 2020 se situe à la frontière entre l'ingénierie interne du backbone et l'écosystème Internet plus large. Les clients inspectent rarement les détails de peering et de transit, mais ces détails façonnent la joignabilité. PeeringDB surhttps://www.peeringdb.com/donne un contexte public pour l'écosystème d'interconnexion. RIPE RIS surhttps://ris.ripe.net/et RouteViews surhttps://www.routeviews.org/routeviews/montrent qu'une observation publique du routage existe, même si elle ne peut révéler chaque décision privée de fournisseur. Les actions des opérateurs MANRS surhttps://manrs.org/netops/actions/et la RFC 7908 surhttps://www.rfc-editor.org/rfc/rfc7908.htmlfournissent un vocabulaire de fuite de route et de sécurité de routage pertinent pour les événements adjacents.

L'incident de juillet 2020 ne doit pas être confondu avec la fuite de route de juin 2019 que Cloudflare a analysée surhttps://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/. En 2019, Cloudflare était un fournisseur affecté expliquant une fuite de route impliquant d'autres réseaux. En 2020, le propre post-mortem de Cloudflare a décrit un problème de configuration réseau interne. La distinction est importante car la carte de responsabilité diffère. Pour une fuite de route, la réparation peut impliquer la validation d'origine, le filtrage, la responsabilité du fournisseur de transit et les normes de l'écosystème. Pour une panne de règle de routeur interne, la réparation se concentre plus directement sur la gestion des changements du fournisseur, les tests, la préférence locale, les garde-fous de préfixe maximum et le rayon d'explosion du contrôle de trafic.

Cloudflare a publié des documents sur RPKI et la sécurité du routage, tels quehttps://blog.cloudflare.com/rpki/ethttps://blog.cloudflare.com/rpki-updates-data/. Ces sources montrent le plaidoyer public de Cloudflare et son vocabulaire technique autour de la sécurité des routes. Elles ne prouvent pas automatiquement la réparation de juillet 2020. Elles aident les lecteurs à comprendre pourquoi un fournisseur qui participe profondément à la sécurité du routage devrait être jugé à la fois par la discipline vérifiable des changements réseau et par l'éducation publique.

La conception du backbone fait partie de la confiance client car les clients achètent des résultats, pas une topologie. Un client peut ne pas se soucier de savoir si le trafic passe par Atlanta, Ashburn, Chicago, Londres ou Singapour jusqu'à ce qu'un changement de routage rende la géographie visible. À ce moment, les clients découvrent que la topologie du fournisseur est une dépendance implicite. Le fournisseur responsable n'a pas à publier la topologie sensible en détail.

Il devrait expliquer le mode de défaillance à un niveau qui permet aux clients de comprendre si l'incident était local, régional, systémique ou global en termes de conception.

Le dossier public devrait également éviter de surestimer ce que les clients peuvent vérifier indépendamment. Les collecteurs de routes publics peuvent montrer un certain comportement visible BGP, mais ils peuvent ne pas montrer le blackholing interne du trafic, les politiques de routeur locales, les détails privés du backbone ou l'impact au niveau applicatif. Les journaux clients peuvent montrer des requêtes échouées mais pas la cause racine. Les pages de statut peuvent montrer l'état du service mais pas toutes les preuves privées. Un article crédible garde ces limites de preuve visibles.

Le modèle de responsabilité utile est en couches. Les contrôles de l'écosystème Internet traitent des fuites de route et de la confiance interdomaine. Les contrôles du backbone du fournisseur traitent de la sécurité du chemin interne. Les contrôles de produit traitent de la façon dont les services Edge échouent ou continuent sous stress réseau. Les contrôles client traitent de la redondance, du contournement d'urgence et du triage des incidents. La communication publique relie les couches. Si une couche est décrite comme la réponse complète, le dossier devient trompeur.

La continuité client dépend de la preuve du fournisseur, pas de la confiance du fournisseur

Pour les clients, la question principale après la panne de juillet 2020 n'était pas de savoir si les employés de Cloudflare étaient confiants. C'était de savoir si le fournisseur pouvait montrer que le chemin de changement avait été corrigé. La continuité client dépend de la preuve car les clients doivent décider s'ils continuent à compter sur le fournisseur pour des chemins critiques, s'ils doivent construire une redondance coûteuse, s'ils doivent changer l'architecture, s'ils doivent ajuster les runbooks d'incident et s'ils doivent signaler les pannes à leurs propres parties prenantes.

Le formulaire 10-K 2020 de Cloudflare surhttps://www.sec.gov/Archives/edgar/data/1477333/000147733321000023/net-20201231.htmfournit un contexte de risque commercial pour l'entreprise, tandis que les documents de confiance et de conformité de Cloudflare surhttps://www.cloudflare.com/trust-hub/fournissent un contexte d'assurance actuel. Les dépôts d'investisseurs et les pages de confiance ne sont pas des preuves de réparation d'incident. Ils montrent que la disponibilité, la sécurité et la confiance client sont matérielles pour le modèle d'affaires. Cela rend la responsabilité détaillée des incidents commercialement rationnelle, pas seulement éthiquement souhaitable.

Les acheteurs de continuité devraient poser des questions post-incident concrètes. Le fournisseur a-t-il limité le rayon d'explosion des changements de règles de routeur? Le déploiement inclut-il un déploiement canari ou par cellule pour les politiques réseau? Quelles métriques arrêtent le déploiement? Les contrôles de préfixe maximum et de préférence locale sont-ils automatisés? Le rollback est-il testé? Les messages de statut sont-ils liés aux états d'incident internes? Les services face au client sont-ils classés par criticité? Les actions post-mortem internes sont-elles suivies jusqu'à leur achèvement?

Les clients entreprises peuvent-ils recevoir des preuves d'incident plus détaillées sous contrat?

Les clients doivent également examiner leur propre côté. Peuvent-ils contourner Cloudflare en toute sécurité si nécessaire? Le contournement exposerait-il les origines à une attaque? Le DNS secondaire est-il configuré et testé? Les applications sont-elles résilientes au comportement de tentative Edge? Les équipes de support internes savent-elles quand se fier au statut de Cloudflare plutôt que d'ouvrir des incidents d'origine? Les communications des services publics sont-elles préparées pour les pannes Edge tierces?

Une panne de fournisseur n'efface pas la responsabilité de continuité du client, mais la responsabilité du client n'est juste que lorsque le fournisseur fournit des preuves utiles.

L'incident de juillet 2020 met en évidence la différence entre les pourcentages de disponibilité et la gravité d'une panne. Un fournisseur peut offrir une haute disponibilité annuelle et encore causer un incident grave de 27 minutes pour un client dont les utilisateurs étaient actifs à ce moment. Les métriques agrégées peuvent masquer un préjudice concentré. La responsabilité devrait mesurer à la fois la fiabilité au niveau de la flotte et la gravité en temps client. Pour un portail public, une courte panne pendant une échéance peut être plus importante qu'une panne plus longue pendant une période calme.

Cet article traite donc le post-mortem de Cloudflare comme un enregistrement public constructif, pas simplement un aveu de faute. L'entreprise a donné une explication spécifique et nommé des thèmes de réparation. C'est mieux qu'une vague réassurance. La charge de responsabilité continue après la publication: la pratique ultérieure de déploiement, la transparence ultérieure des statuts, les incidents ultérieurs et les preuves client déterminent si le post-mortem est devenu un contrôle durable. Un post-mortem est une promesse pour l'avenir autant qu'un rapport sur le passé.

Les preuves négatives font partie d'un post-mortem réseau utile

Un post-mortem réseau solide ne devrait pas seulement dire ce qui s'est passé. Il devrait aussi dire ce qui ne s'est pas passé, dans la mesure où le fournisseur peut le prouver. Les preuves négatives sont précieuses car les clients doivent limiter leur propre réponse. Si un incident était un événement de blackholing du trafic plutôt qu'un événement de corruption de données DNS, les clients peuvent prioriser la disponibilité et les preuves de tentative au lieu de l'intégrité du fichier de zone.

Si le fournisseur peut montrer que la configuration client n'a pas été modifiée, les clients peuvent éviter un rollback inutile de leurs propres paramètres. Si le fournisseur peut montrer que l'événement n'a pas exposé le contenu du trafic, les clients peuvent séparer l'examen de confidentialité de l'examen de disponibilité. Le but n'est pas de minimiser l'incident. Le but est d'empêcher les clients d'effectuer un travail coûteux dans la mauvaise voie de risque.

Pour la panne Cloudflare de juillet 2020, des preuves négatives utiles incluraient des limites autour de l'intégrité des données, de la configuration client, de l'état de la politique de sécurité, de l'état des enregistrements DNS, de l'état des certificats, de l'état du code Workers et de l'accès à l'origine. Les post-mortems publics se concentrent souvent sur la chaîne positive de défaillance car c'est là que se trouve le drame. Les clients ont également besoin d'exclusions.

Ils doivent savoir si un événement de règle de routeur a modifié le contenu, divulgué des données privées, contourné la politique de sécurité, modifié le DNS ou simplement empêché la joignabilité. Si le fournisseur ne peut pas prouver une exclusion, il devrait le dire. S'il peut en prouver une, il devrait en énoncer la base.

Les preuves négatives aident également les équipes d'achat et d'audit. Un acheteur lisant un post-mortem peut devoir décider s'il doit déposer un incident de confidentialité, une exception de disponibilité, une note de risque fournisseur, un examen de continuité ou aucune action supplémentaire. Ces décisions diffèrent. Un incident de confidentialité nécessite des questions sur le périmètre des données. Une exception de disponibilité nécessite des questions sur la disponibilité et l'avis client. Une note de risque fournisseur demande si le fournisseur a changé les contrôles.

Un examen de continuité demande si le client a besoin de chemins de service secondaires. Une même panne peut déclencher plusieurs de ces processus, mais un post-mortem précis peut empêcher une escalade inutile.

Il y a une discipline dans la rédaction de preuves négatives. Le fournisseur devrait éviter les affirmations trop larges comme "aucun impact client au-delà de la disponibilité" sauf s'il a des preuves couvrant tous les cas d'usage client.

Un meilleur modèle est un langage limité: "nous n'avons pas observé de modifications de la configuration client dans les systèmes affectés", ou "l'événement a été causé par un trafic abandonné à l'intérieur du backbone et n'a pas impliqué l'accès au tableau de bord client", ou "les clients ont peut-être vu des requêtes échouées mais n'ont pas besoin de faire tourner les identifiants car l'incident n'a pas impliqué de matériel d'authentification." Les faits exacts dépendent de l'incident. La pratique responsable est d'énoncer la limite.

Les preuves publiques ne peuvent aller que jusqu'à un certain point. Cloudflare peut avoir des données spécifiques au client, des enregistrements de support privés, des briefings d'incident pour entreprises ou une télémétrie interne qui n'est pas publique. L'article public ne devrait pas inventer ces faits. Mais le standard de responsabilité devrait toujours nommer les preuves dont les clients bénéficieraient. L'absence de preuves négatives publiques n'est pas une preuve de préjudice caché. C'est une raison pour les clients sophistiqués de demander à leurs équipes de compte une déclaration d'incident plus précise si le service est critique.

Les runbooks clients devraient inclure les décisions de panne Edge du fournisseur

La panne de Cloudflare de juillet 2020 montre également que les clients ont besoin de runbooks pour la défaillance Edge du fournisseur, pas seulement pour la défaillance d'origine. De nombreuses équipes d'incident sont formées à inspecter leur propre application, base de données, région cloud, pare-feu, couche d'authentification et historique de déploiement lorsque les utilisateurs signalent un accès échoué.

Si un fournisseur Edge est devant le service, le runbook devrait également demander si le fournisseur Edge a un incident de statut en cours, si le routage alternatif ou le contournement est sûr, si l'origine est saine derrière le fournisseur et si le client peut communiquer l'impact utilisateur sans affaiblir la sécurité.

La partie difficile est que le contournement peut être dangereux. Un client utilisant Cloudflare pour la protection DDoS, le pare-feu d'application Web, la terminaison TLS, l'atténuation des bots, le contrôle d'accès ou le masquage d'origine peut ne pas être en mesure de contourner le fournisseur sans exposer l'origine à une attaque ou à une mauvaise configuration. Un contournement d'urgence qui fonctionne pour un site statique à faible risque peut être inacceptable pour une API à haut risque ou un service public. Cela signifie que la planification des pannes Edge du fournisseur doit être conçue avant la panne.

Les clients devraient décider quels services peuvent contourner, lesquels ne le peuvent pas, lesquels nécessitent des fournisseurs Edge secondaires et lesquels nécessitent une communication plutôt qu'un basculement technique.

La même logique s'applique aux conceptions de DNS secondaire et multi-CDN. La redondance peut réduire la dépendance, mais elle ajoute une complexité de configuration et peut créer de nouveaux chemins de défaillance. Si un fournisseur secondaire ne reflète pas les règles de sécurité, le comportement du cache, la configuration TLS, l'authentification d'origine et la journalisation, le chemin de basculement peut être moins sûr que la panne. La responsabilité du fournisseur et la continuité client interagissent donc.

Cloudflare doit rendre ses propres contrôles solides; les clients doivent décider quels services justifient le coût et la complexité d'un repli indépendant.

Les clients du secteur public et des services critiques devraient être particulièrement explicites. Un portail municipal, un site d'information scolaire, une application de service de santé, une page de dépôt judiciaire ou un canal de communication adjacent aux urgences peut avoir une tolérance différente à la panne, au risque de contournement et à la messagerie publique.

Le runbook client devrait identifier qui peut déclarer une panne de fournisseur tiers, qui peut changer la messagerie de statut, qui peut contacter le fournisseur, qui peut décider de ne pas contourner parce que le risque de sécurité est plus grand que le bénéfice de disponibilité et qui peut informer le public de ce qui est connu. La page de statut du fournisseur devient une entrée dans ce processus de gouvernance.

Le fournisseur peut faciliter ces runbooks en publiant des conseils d'action client clairs pendant les incidents. Parfois, la bonne action client est aucune: attendre l'atténuation du fournisseur et ne pas modifier la configuration d'origine. Parfois, la bonne action est de suspendre les déploiements ou de supprimer les alertes en double. Parfois, il s'agit de router les utilisateurs critiques via un chemin alternatif pré-approuvé. Le message de statut devrait être suffisamment précis pour que les clients ne créent pas de préjudice supplémentaire en essayant de s'aider eux-mêmes.

Après l'incident, les clients devraient enregistrer ce que leur propre surveillance a vu. Les vérifications synthétiques ont-elles échoué en même temps que le statut du fournisseur? Les utilisateurs de certaines régions ont-ils subi un impact pire? Les équipes de support ont-elles mal diagnostiqué une défaillance d'origine? Les alertes ont-elles submergé les répondants? Le comportement de tentative a-t-il amplifié la charge sur les origines? Les communications d'urgence ont-elles fonctionné? Cet enregistrement client ne remplace pas le post-mortem de Cloudflare. C'est la moitié aval du dossier de responsabilité.

Ensemble, les preuves du fournisseur et les preuves du client montrent si la dépendance est suffisamment comprise pour être maintenue ou si l'architecture doit changer.

Les clients entreprises et du secteur public peuvent également demander un pack de preuves du fournisseur qui va au-delà du post-mortem public sans divulguer de détails réseau sensibles. Le pack utile ne nommerait pas chaque routeur ni n'exposerait la topologie propriétaire. Il résumerait les classes de service affectées, les fenêtres temporelles affectées, les symptômes observés par le client, le contrôle qui a échoué, le mécanisme de rollback, le responsable de la remédiation et la preuve que les actions de suivi ont été complétées.

Il dirait également si l'incident a impliqué la confidentialité, l'intégrité ou seulement la disponibilité, en utilisant un langage limité. Ce type de pack de preuves permet à un client de clore son propre ticket de risque fournisseur avec des faits au lieu d'une large confiance.

Le fournisseur bénéficie également de cette discipline. Sans pack de preuves structuré, chaque client important pose une version différente de la même question, et les équipes de support deviennent des traducteurs du post-mortem. Avec un pack structuré, les équipes de compte, de sécurité, juridiques et techniques peuvent se référer au même enregistrement. L'enregistrement peut préserver les détails sensibles tout en répondant aux questions opérationnelles que les clients doivent répondre en interne. Cela réduit la spéculation et rend le post-mortem public plus utile plutôt que moins.

L'incident de Cloudflare de juillet 2020 doit donc être lu comme une incitation à la conception de l'échange de preuves entre fournisseur et client. Le blog public d'un fournisseur peut expliquer le chemin de défaillance principal. Une page de statut peut suivre les conditions en direct. Un pack de preuves client peut soutenir la clôture de gouvernance. La télémétrie client peut montrer l'impact local. Les quatre enregistrements sont nécessaires car aucun enregistrement unique ne répond à chaque question de responsabilité.

Le fournisseur possède la preuve de contrôle interne; le client possède les décisions de continuité locales; le public possède l'attente que les défaillances d'infrastructure partagée sont décrites d'une manière qui aide les services affectés à récupérer sans deviner.

Cet échange donne également aux réviseurs futurs une base de référence pour comparer la prochaine panne par rapport au changement de contrôle promis, au lieu de traiter chaque incident comme une histoire isolée.

La même base de référence peut être utilisée dans la revue d'architecture. Si un incident ultérieur de Cloudflare affecte un service différent, un client peut demander si les contrôles de juillet 2020 étaient pertinents, si une nouvelle classe de défaillance est apparue et si le style de post-mortem du fournisseur s'est amélioré ou affaibli. Si un incident ultérieur répète le même modèle de croissance rapide du rayon d'explosion, le client a la preuve que la réparation précédente n'a pas entièrement résolu la dépendance.

Si les incidents ultérieurs sont plus étroits, plus rapides à détecter et plus clairs dans la messagerie de statut, le client a la preuve que le système de contrôle a mûri. Cette utilisation comparative est pourquoi les post-mortems devraient préserver des affirmations de contrôle spécifiques au lieu d'un langage général de résilience.

La leçon durable est de rendre la sécurité des changements réseau observable

La leçon durable de la panne de règle de routeur de Cloudflare de juillet 2020 est que la sécurité des changements réseau doit être observable avant, pendant et après le déploiement. Avant le déploiement, le fournisseur devrait connaître l'effet de trafic prévu, simuler ou valider le comportement de la politique, identifier le rayon d'explosion et choisir un chemin progressif. Pendant le déploiement, il devrait surveiller le trafic, les erreurs, les indicateurs de blackholing, les changements de route, la santé face au client et les portes d'expansion.

Après le déploiement, il devrait préserver les preuves, publier un compte limité, compléter la remédiation et tester la réparation.

Ce n'est pas une demande de réseaux parfaits. Les grands réseaux échouent. La question de responsabilité est de savoir s'ils échouent de manière limitée, observable et réversible. Un fournisseur peut gagner la confiance en montrant qu'une mauvaise règle ne peut pas capturer ou abandonner silencieusement trop de trafic, qu'une cellule canari attrape un comportement inattendu, que des portes automatisées arrêtent le déploiement, que le rollback est répété et que la communication de statut atteint les clients avant qu'ils ne perdent du temps à déboguer leurs propres origines.

Les documents plus larges de Cloudflare sur le routage et la fiabilité, y comprishttps://www.cloudflare.com/learning/security/glossary/what-is-bgp/,https://blog.cloudflare.com/rpki/ethttps://blog.cloudflare.com/rpki-updates-data/, montrent que l'entreprise comprend le routage public comme un domaine de responsabilité. Le cas de juillet 2020 applique le même standard en interne. Le plaidoyer pour le routage public est le plus fort lorsque les contrôles de changement réseau internes sont également vérifiables. Les clients ne ressentent pas la distinction entre les causes interdomaines et intradomaines aussi clairement que les ingénieurs. Ils ressentent la joignabilité.

L'incident suggère également une question générale pour tous les fournisseurs Edge et cloud: quelle classe de changement interne peut produire une panne client, et comment cette classe est-elle limitée? Un fournisseur devrait être en mesure de répondre pour les changements DNS, les changements de routage, les changements de règle de pare-feu, les changements de certificat, les changements de politique d'identité, les changements de politique de cache, les outils de déploiement et les migrations de base de données. La réponse devrait inclure à la fois la prévention et la récupération. "Nous avons des experts" n'est pas un contrôle.

"Nous déployons par étapes avec des conditions d'arrêt automatiques et un rollback testé" est plus proche d'un contrôle. "Nous publions des post-mortems avec suivi des actions" est encore plus proche.

La continuité du secteur public rend cette discipline moins optionnelle. Les gouvernements, les écoles, les services de santé, les sites adjacents aux urgences et les organisations civiques dépendent souvent de fournisseurs Edge cloud commerciaux car cela peut améliorer la sécurité et la performance. Cette dépendance n'est raisonnable que si les fournisseurs traitent les changements réseau internes comme un risque public. Un changement de règle de routeur à l'intérieur d'un fournisseur peut devenir un incident de service public à l'extérieur du fournisseur. La chaîne de responsabilité doit reconnaître cette réalité.

La panne de Cloudflare de juillet 2020 appartient donc à cette série car c'est un exemple propre de contrôle pratique. L'opérateur qui pouvait déployer la règle de routeur avait le devoir le plus fort de tester, progresser, observer et annuler le changement. Les clients avaient le devoir de comprendre la dépendance et de planifier la continuité, mais ils ne pouvaient pas réparer le backbone du fournisseur.

Le dossier public est le plus fort lorsqu'il dit exactement cela: les contrôles internes du fournisseur sont devenus des contrôles de disponibilité client, l'incident a été réparé et la réparation doit rester suffisamment visible pour que les clients puissent faire confiance au prochain changement réseau.