La Panne Mondiale de CrowdStrike : Lecons sur la Resilience et la Dependance aux Fournisseurs
Le 19 juillet 2024, CrowdStrike a deploye une mise a jour defectueuse de son Falcon Sensor qui a provoque l'effondrement de 8,5 millions de machines Windows dans le monde entier, selon CNN. Compagnies aeriennes clouees au sol. Hopitaux avec des systemes en panne. Banques hors service. Pertes estimees pour les seules entreprises du Fortune 500 : 5,4 milliards de dollars.
Ce n'etait pas une cyberattaque. Ce n'etait pas un ransomware. C'etait une mise a jour de routine d'un fournisseur de confiance.
Si vous dirigez une startup et pensez que cela ne vous concerne pas, reflechissez-y a deux fois. Ce qui s'est passe ce vendredi est un cas d'ecole sur la dependance aux fournisseurs, la resilience operationnelle et la raison pour laquelle vous avez besoin d'ingenieurs qui comprennent ce qu'ils deploient.
Ce qui s'est passe techniquement
La panne a ete causee par une mise a jour d'un fichier de canal (channel file) du Falcon Sensor de CrowdStrike. Ce fichier contenait une definition defectueuse qui a provoque une lecture de memoire hors limites (out-of-bounds memory read) dans le driver au niveau du kernel Windows. Resultat : ecran bleu de la mort (BSOD) immediat.
La mise a jour a ete diffusee aux alentours de minuit (heure UTC). CrowdStrike l'a annulee 90 minutes plus tard. Mais a ce moment-la, des millions de machines avaient deja automatiquement telecharge le fichier defectueux.
Ce qui etait devastateur, ce n'etait pas seulement la panne. C'etait la vitesse de propagation. Un seul fichier, distribue automatiquement, sans controles intermediaires, a des millions de terminaux simultanement. Le mecanisme de distribution concu pour proteger s'est transforme en vecteur du desastre.
Lecon 1 : La dependance a un fournisseur unique est un risque existentiel
Si une mise a jour d'un seul fournisseur peut faire tomber toute votre operation, votre architecture a un point de defaillance unique.
Cela s'applique a tout : votre fournisseur cloud, votre outil de securite, votre base de donnees managee, votre CDN. Je ne dis pas de ne pas utiliser de services tiers. Je dis que vous devez concevoir en partant du principe que n'importe lequel d'entre eux peut tomber.
Questions que vous devriez vous poser maintenant :
- Si votre fournisseur cloud principal tombe pendant 4 heures, qu'arrive-t-il a vos utilisateurs
- Si votre outil de monitoring cesse de fonctionner, comment savez-vous que quelque chose dysfonctionne
- Si votre fournisseur d'authentification tombe, vos utilisateurs peuvent-ils continuer a utiliser le produit
La reponse a ces questions definit votre niveau de resilience. Et si la reponse a toutes est "on est a l'arret", vous avez un probleme d'architecture.
Lecon 2 : Les mises a jour automatiques sans controles sont dangereuses
CrowdStrike a distribue la mise a jour defectueuse a tous les terminaux en meme temps. Sans canary deployment. Sans rollout progressif. Sans approbation manuelle pour les systemes critiques.
Pour une startup, la lecon est directe : tout changement qui touche la production a besoin de controles.
- Canary deployments : deployer d'abord a 1 % des utilisateurs. S'il n'y a pas d'erreurs, monter a 10 %, puis 50 %, puis 100 %.
- Feature flags : separer le deploiement du lancement. Vous pouvez avoir du code en production sans qu'il soit actif.
- Rollback automatique : si les metriques d'erreurs depassent un seuil, revenir en arriere automatiquement.
- Approbation manuelle pour l'infrastructure critique : tout ne doit pas etre automatique. Les modifications de bases de donnees, de configuration de securite ou d'infrastructure reseau meritent des yeux humains.
Ce n'est pas de la bureaucratie. C'est de l'ingenierie.
Lecon 3 : Vous avez besoin d'ingenieurs qui comprennent ce qu'ils deploient
Beaucoup de startups externalisent completement la securite. Elles contractent un fournisseur, installent l'agent et l'oublient. Personne en interne ne comprend ce que fait cet agent, comment il interagit avec le systeme d'exploitation, ni quelles permissions il a.
L'incident CrowdStrike demontre pourquoi c'est dangereux. Le Falcon Sensor opere au niveau du kernel. Il a un acces total au systeme. Quand il tombe en panne, ce n'est pas une app qui se ferme : c'est le systeme d'exploitation entier qui cesse de fonctionner.
Vous n'avez pas besoin d'une equipe de securite de 10 personnes. Mais vous avez besoin d'au moins un ingenieur senior qui :
- Comprend les integrations de vos fournisseurs de securite au niveau technique
- Peut auditer quels acces chaque outil tiers possede
- Sait reagir quand quelque chose tombe, sans dependre du support du fournisseur
- Evalue le risque de chaque outil operant avec des privileges eleves
La securite deleguee sans supervision n'est pas de la securite. C'est de l'esperance.
Lecon 4 : Les plans de reponse aux incidents ne sont pas optionnels
Quand la panne CrowdStrike s'est produite, les entreprises qui se sont retablies le plus vite avaient un point commun : un plan de reponse aux incidents documente et pratique.
Je ne parle pas d'un document de 80 pages que personne n'a lu. Je parle de reponses claires a des questions simples :
- Qui dirige la reponse en cas d'incident
- Comment l'equipe communique pendant une crise (si Slack tombe, quel est le plan B)
- Ou se trouve le runbook pour les scenarios les plus probables
- Qui a les acces pour faire des rollbacks, redemarrer des services ou escalader aupres des fournisseurs
- Comment on communique aux utilisateurs ce qui se passe
Dans beaucoup de startups, la reponse a toutes ces questions est "on verra sur le moment". Ca fonctionne jusqu'a ce que ca ne fonctionne plus. Et quand ca ne fonctionne plus, chaque minute d'interruption, c'est de l'argent, de la reputation et de la confiance des utilisateurs qui se perdent.
Si votre equipe n'a jamais fait de simulation d'incident, ce week-end est un bon moment pour commencer.
Lecon 5 : La resilience est une discipline d'ingenierie
La resilience n'est pas quelque chose que vous achetez. Ce n'est pas un produit SaaS. Ce n'est pas une case a cocher dans un audit de compliance. C'est une discipline d'ingenierie qui requiert une conception intentionnelle, une implementation soignee et une maintenance continue.
Elle implique :
- Redondance : ne pas avoir de point de defaillance unique a aucun niveau (infrastructure, donnees, fournisseurs, personnes)
- Degradation elegante : quand quelque chose tombe, le systeme continue de fonctionner a capacite reduite au lieu de s'effondrer completement
- Circuit breakers : des mecanismes qui detectent les defaillances en cascade et les isolent avant qu'elles ne se propagent
- Chaos engineering : tester deliberement ce qui se passe quand les choses tombent en panne, avant qu'elles ne tombent en production
- Observabilite : on ne peut pas reparer ce qu'on ne peut pas voir. Logs, metriques, alertes, dashboards
Et le plus important : elle requiert des personnes qui ont concu des systemes pour survivre aux pannes. Des ingenieurs qui ont vecu des incidents, qui savent ce que ca fait quand un systeme tombe a 3 heures du matin, et qui concoivent en gardant cela a l'esprit.
Ce que cela signifie pour votre startup
Si vous etes une startup en phase precoce, vous n'avez probablement pas besoin de redondance multi-cloud ni d'une equipe SRE de 5 personnes. Mais vous avez besoin des bases :
- Un ingenieur senior qui comprend le DevOps et la securite
- Des deploiements avec des controles, pas des pushs directs en production
- Un plan minimum de reponse aux incidents
- Un audit de quels fournisseurs ont acces a quoi, et avec quels privileges
- Des backups testes (pas seulement configures, mais testes en restauration)
Le probleme est que trouver des ingenieurs avec une experience reelle en resilience operationnelle et en gestion d'incidents n'est pas facile. C'est un profil qui se forge avec des annees d'experience, pas avec des formations.
Chez Conectia, nous travaillons avec des ingenieurs senior d'Amerique latine qui ont construit et opere de l'infrastructure en production pour des entreprises en croissance. Des profils DevOps et SRE qui comprennent la gestion du risque fournisseur, qui ont concu des pipelines de deploiement avec des controles, et qui savent construire des systemes qui survivent quand les choses tombent. Parce qu'elles tombent toujours.
L'incident CrowdStrike n'a pas ete le premier et ne sera pas le dernier. La question n'est pas de savoir si votre startup fera face a un incident de ce type. La question est de savoir si votre equipe est preparee a reagir quand il se produira.
Votre equipe a-t-elle la capacite technique de repondre a un incident en production ? Parlez a un CTO -- nous vous aidons a integrer des ingenieurs senior en DevOps et SRE qui construisent des systemes resilients des le premier jour.
