L'apagada global de CrowdStrike: lliçons de resiliència i dependència de proveïdors
El 19 de juliol de 2024, CrowdStrike va publicar una actualització defectuosa del seu Falcon Sensor que va fer caure 8,5 milions de màquines Windows arreu del món, segons la CNN. Avions a terra. Hospitals amb els sistemes caiguts. Bancs que no podien operar. Pèrdues estimades només per a les empreses del Fortune 500: 5.400 milions de dòlars.
No va ser cap ciberatac. No va ser ransomware. Va ser una actualització rutinària d'un proveïdor de confiança.
Si dirigeixes una startup i creus que això no va amb tu, repensa-t'ho. He passat anys al costat enterprise de la resposta a incidents, en fallades com aquesta, i el que va passar aquell divendres és un cas d'estudi perfecte sobre dependència de proveïdors, resiliència operativa i per què necessites enginyers que entenguin què despleguen.
Un fitxer defectuós, cap gate entremig, milions de màquines caigudes
La fallada la va causar l'actualització d'un channel file del Falcon Sensor de CrowdStrike. El fitxer contenia una definició defectuosa que provocava una lectura de memòria fora de límits (out-of-bounds memory read) al driver de Windows a nivell de kernel. El resultat: pantalla blava de la mort (BSOD) immediata.
L'actualització es va publicar cap a mitjanit UTC. CrowdStrike la va retirar 90 minuts més tard. Però aleshores milions de màquines ja havien descarregat automàticament el fitxer defectuós.
El que la va fer devastadora no va ser només la fallada en si. Va ser la velocitat de propagació. Un sol fitxer, distribuït automàticament, sense gates intermedis, a milions d'endpoints alhora. El mecanisme de distribució dissenyat per protegir es va convertir en el vector del desastre.
Lliçó 1: dependre d'un sol proveïdor és un risc existencial
Si l'actualització d'un sol proveïdor pot tombar tota la teva operació, la teva arquitectura té un punt únic de fallada.
Això val per a tot: el proveïdor de cloud, l'eina de seguretat, la base de dades gestionada, el CDN. No dic que no facis servir serveis de tercers. Dic que has de dissenyar assumint que qualsevol pot fallar.
Preguntes que t'hauries d'estar fent ara mateix:
- Si el teu proveïdor principal de cloud cau quatre hores, què passa amb els teus usuaris
- Si l'eina de monitoratge deixa de funcionar, com t'assabentes que alguna cosa s'ha trencat
- Si el proveïdor d'autenticació cau, els usuaris poden continuar fent servir el producte
Les teves respostes a aquestes preguntes defineixen el teu nivell de resiliència. I si la resposta a totes és «estem venuts», tens un problema d'arquitectura.
Lliçó 2: les actualitzacions automàtiques sense gates són perilloses
CrowdStrike va distribuir l'actualització defectuosa a tots els endpoints alhora. Sense canary deployment. Sense rollout esglaonat. Sense aprovació manual per als sistemes crítics.
Per a una startup, la lliçó és senzilla: qualsevol canvi que toqui producció necessita gates.
- Canary deployments: desplega primer a l'1% dels usuaris. Si no hi ha errors, passa al 10%, després al 50% i després al 100%.
- Feature flags: separa el desplegament del llançament. Pots tenir codi a producció sense que estigui actiu.
- Rollback automàtic: si les mètriques d'error superen un llindar, reverteix automàticament.
- Aprovació manual per a la infraestructura crítica: no tot s'ha d'automatitzar. Els canvis a bases de dades, configuració de seguretat o infraestructura de xarxa mereixen ulls humans.
Això no és burocràcia. És enginyeria.
Lliçó 3: necessites enginyers que entenguin què despleguen
Moltes startups externalitzen la seguretat del tot. Contracten un proveïdor, instal·len l'agent i se n'obliden. Ningú de dins no entén què fa aquell agent, com interactua amb el sistema operatiu ni quins permisos té.
L'incident de CrowdStrike mostra per què això és perillós. El Falcon Sensor opera a nivell de kernel. Té accés complet al sistema. Quan falla, no és una app que es tanca: és tot el sistema operatiu que deixa de funcionar.
No necessites un equip de seguretat de deu persones. Però sí, com a mínim, un enginyer sènior que:
- Entengui les integracions dels teus proveïdors de seguretat a nivell tècnic
- Pugui auditar quins accessos té cada eina de tercers
- Sàpiga respondre quan alguna cosa es trenca, sense dependre del suport del proveïdor
- Pugui avaluar el risc de cada eina que opera amb privilegis elevats
La seguretat delegada sense supervisió no és seguretat. És fer-se il·lusions.
Lliçó 4: els plans de resposta a incidents no són opcionals
Quan va esclatar l'apagada de CrowdStrike, les empreses que es van recuperar més de pressa tenien una cosa en comú: un pla de resposta a incidents documentat i assajat.
No parlo d'un document de 80 pàgines que ningú no ha llegit. Parlo de respostes clares a preguntes senzilles:
- Qui lidera la resposta quan hi ha un incident
- Com es comunica l'equip durant una crisi (si Slack cau, quin és el pla B)
- On és el runbook dels escenaris més probables
- Qui té accés per fer rollbacks, reiniciar serveis o escalar amb els proveïdors
- Com expliques als usuaris què està passant
A moltes startups, la resposta a tot això és «ja ho anirem veient». Funciona fins que deixa de funcionar. I quan deixa de funcionar, cada minut de caiguda són diners, reputació i confiança dels usuaris que s'esfumen.
Si el teu equip no ha fet mai un simulacre d'incident, aquest cap de setmana és un bon moment per començar.
Lliçó 5: la resiliència és una disciplina d'enginyeria
La resiliència no es compra. No és un producte SaaS. No és una casella en una auditoria de compliance. És una disciplina d'enginyeria que demana disseny intencional, implementació acurada i manteniment continu.
Implica:
- Redundància: cap punt únic de fallada a cap nivell (infraestructura, dades, proveïdors, persones)
- Degradació elegant: quan alguna cosa falla, el sistema continua funcionant amb capacitat reduïda en lloc d'ensorrar-se del tot
- Circuit breakers: mecanismes que detecten fallades en cascada i les aïllen abans que s'escampin
- Chaos engineering: provar deliberadament què passa quan les coses fallen, abans que fallin a producció
- Observabilitat: no pots arreglar el que no veus. Logs, mètriques, alertes, dashboards
I el més important: demana gent que hagi dissenyat sistemes per sobreviure a fallades. Enginyers que han viscut incidents, que saben què vol dir que un sistema caigui a les tres de la matinada, i que dissenyen amb això al cap.
El que jo posaria en marxa aquest trimestre
Si ets una startup en fase inicial, segurament no necessites redundància multi-cloud ni un equip de SRE de cinc persones. Però sí els fonaments:
- Un enginyer sènior que entengui DevOps i seguretat
- Desplegaments amb gates, no pushes directes a producció
- Un pla mínim de resposta a incidents
- Una auditoria de quins proveïdors tenen accés a què, i amb quins privilegis
- Backups provats (no només configurats: provats per restaurar)
El problema és que trobar enginyers amb experiència real en resiliència operativa i gestió d'incidents no és fàcil. És un perfil que es forja amb anys d'experiència, no amb cursos.
A Conectia treballem amb enginyers sènior de LATAM que han construït i operat infraestructura de producció per a empreses en creixement. Perfils de DevOps i SRE que entenen la gestió del risc de proveïdors, que han dissenyat pipelines de desplegament amb gates i que saben construir sistemes que sobreviuen quan les coses van malament. Perquè sempre acaben anant malament.
L'incident de CrowdStrike no va ser el primer ni serà l'últim. La pregunta no és si la teva startup s'enfrontarà a un incident així. La pregunta és si el teu equip estarà preparat per respondre quan arribi.
El teu equip té la capacitat tècnica per respondre a un incident a producció? Parla amb un CTO — t'ajudem a incorporar enginyers sènior de DevOps i SRE que construeixen sistemes resilients des del primer dia.
