O Apagao Global da CrowdStrike: Licoes sobre Resiliencia e Dependencia de Fornecedores
Em 19 de julho de 2024, a CrowdStrike lancou uma atualizacao defeituosa do seu Falcon Sensor que provocou o colapso de 8,5 milhoes de maquinas Windows em todo o mundo, segundo a CNN. Companhias aereas em terra. Hospitais com sistemas fora do ar. Bancos sem operar. Perdas estimadas apenas para as empresas da Fortune 500: 5,4 bilhoes de dolares.
Nao foi um ciberataque. Nao foi um ransomware. Foi uma atualizacao rotineira de um fornecedor de confianca.
Se voce dirige uma startup e acha que isso nao te afeta, pense de novo. O que aconteceu naquela sexta-feira e um caso de estudo perfeito sobre dependencia de fornecedores, resiliencia operacional e por que voce precisa de engenheiros que entendam o que estao implantando.
O que aconteceu tecnicamente
A falha foi causada por uma atualizacao de um arquivo de canal (channel file) do Falcon Sensor da CrowdStrike. Esse arquivo continha uma definicao defeituosa que provocou uma leitura de memoria fora dos limites (out-of-bounds memory read) no driver em nivel de kernel do Windows. O resultado: tela azul da morte (BSOD) imediata.
A atualizacao foi liberada por volta da meia-noite (horario UTC). A CrowdStrike a reverteu 90 minutos depois. Mas a essa altura, milhoes de maquinas ja haviam baixado automaticamente o arquivo defeituoso.
O devastador nao foi apenas a falha. Foi a velocidade de propagacao. Um unico arquivo, distribuido automaticamente, sem gates intermediarios, a milhoes de endpoints simultaneamente. O mecanismo de distribuicao projetado para proteger se tornou o vetor do desastre.
Licao 1: A dependencia de um unico fornecedor e um risco existencial
Se uma atualizacao de um unico fornecedor pode derrubar toda sua operacao, sua arquitetura tem um ponto unico de falha.
Isso se aplica a tudo: seu provedor de cloud, sua ferramenta de seguranca, seu banco de dados gerenciado, seu CDN. Nao estou dizendo para nao usar servicos de terceiros. Estou dizendo que voce deve projetar assumindo que qualquer um deles pode falhar.
Perguntas que voce deveria se fazer agora:
- Se seu provedor de cloud principal cair por 4 horas, o que acontece com seus usuarios
- Se sua ferramenta de monitoracao parar de funcionar, como voce descobre que algo esta falhando
- Se seu provedor de autenticacao cair, seus usuarios conseguem continuar usando o produto
A resposta a essas perguntas define seu nivel de resiliencia. E se a resposta a todas e "ficamos parados", voce tem um problema de arquitetura.
Licao 2: Atualizacoes automaticas sem gates sao perigosas
A CrowdStrike distribuiu a atualizacao defeituosa para todos os endpoints de uma vez. Sem canary deployment. Sem rollout escalonado. Sem aprovacao manual para sistemas criticos.
Para uma startup, a licao e direta: qualquer mudanca que toque producao precisa de gates.
- Canary deployments: implante primeiro para 1% dos usuarios. Se nao houver erros, suba para 10%, depois 50%, depois 100%.
- Feature flags: separe a implantacao do lancamento. Voce pode ter codigo em producao sem que esteja ativo.
- Rollback automatico: se as metricas de erro subirem acima de um limiar, reverta automaticamente.
- Aprovacao manual para infraestrutura critica: nem tudo deve ser automatico. Mudancas em bancos de dados, configuracao de seguranca ou infraestrutura de rede merecem olhos humanos.
Isso nao e burocracia. E engenharia.
Licao 3: Voce precisa de engenheiros que entendam o que estao implantando
Muitas startups terceirizam a seguranca completamente. Contratam um fornecedor, instalam o agente e se esquecem. Nao ha ninguem interno que entenda o que esse agente faz, como interage com o sistema operacional, nem que permissoes tem.
O incidente da CrowdStrike demonstra por que isso e perigoso. O Falcon Sensor opera em nivel de kernel. Tem acesso total ao sistema. Quando falha, nao e um app que fecha: e o sistema operacional inteiro que para de funcionar.
Voce nao precisa de um time de seguranca de 10 pessoas. Mas precisa de pelo menos um engenheiro senior que:
- Entenda as integracoes dos seus fornecedores de seguranca em nivel tecnico
- Consiga auditar quais acessos cada ferramenta de terceiros tem
- Saiba responder quando algo falha, sem depender do suporte do fornecedor
- Avalie o risco de cada ferramenta que opera com privilegios elevados
Seguranca delegada sem supervisao nao e seguranca. E esperanca.
Licao 4: Planos de resposta a incidentes nao sao opcionais
Quando o apagao da CrowdStrike aconteceu, as empresas que se recuperaram mais rapido tinham algo em comum: um plano de resposta a incidentes documentado e praticado.
Nao estou falando de um documento de 80 paginas que ninguem leu. Falo de respostas claras a perguntas simples:
- Quem lidera a resposta quando ha um incidente
- Como o time se comunica durante uma crise (se o Slack cair, qual e o plano B)
- Onde esta o runbook para os cenarios mais provaveis
- Quem tem acesso para fazer rollbacks, reiniciar servicos ou escalar com fornecedores
- Como se comunica aos usuarios o que esta acontecendo
Em muitas startups, a resposta a todas essas perguntas e "vamos vendo". Isso funciona ate que nao funciona. E quando nao funciona, cada minuto fora do ar e dinheiro, reputacao e confianca de usuarios que se perde.
Se seu time nunca fez um simulado de incidente, este fim de semana e um bom momento para comecar.
Licao 5: A resiliencia e uma disciplina de engenharia
A resiliencia nao e algo que voce compra. Nao e um produto SaaS. Nao e um checkbox em uma auditoria de compliance. E uma disciplina de engenharia que requer design intencional, implementacao cuidadosa e manutencao continua.
Implica:
- Redundancia: nao ter um unico ponto de falha em nenhum nivel (infraestrutura, dados, fornecedores, pessoas)
- Degradacao elegante: quando algo falha, o sistema continua funcionando com capacidade reduzida em vez de colapsar completamente
- Circuit breakers: mecanismos que detectam falhas em cascata e as isolam antes que se propaguem
- Chaos engineering: testar deliberadamente o que acontece quando as coisas falham, antes que falhem em producao
- Observabilidade: voce nao pode consertar o que nao pode ver. Logs, metricas, alertas, dashboards
E o mais importante: requer pessoas que tenham projetado sistemas para sobreviver a falhas. Engenheiros que viveram incidentes, que sabem o que se sente quando um sistema cai as 3 da manha, e que projetam tendo isso em mente.
O que isso significa para sua startup
Se voce e uma startup em estagio inicial, provavelmente nao precisa de redundancia multi-cloud nem de um time de SRE de 5 pessoas. Mas precisa do basico:
- Um engenheiro senior que entenda DevOps e seguranca
- Deploys com gates, nao pushes diretos para producao
- Um plano minimo de resposta a incidentes
- Auditoria de quais fornecedores tem acesso a que, e com quais privilegios
- Backups testados (nao apenas configurados, mas testados para restauracao)
O problema e que encontrar engenheiros com experiencia real em resiliencia operacional e gestao de incidentes nao e facil. E um perfil que se forma com anos de experiencia, nao com cursos.
Na Conectia trabalhamos com engenheiros senior da America Latina que construiram e operaram infraestrutura em producao para empresas em crescimento. Perfis de DevOps e SRE que entendem a gestao de risco de fornecedores, que projetaram pipelines de deploy com gates, e que sabem construir sistemas que sobrevivem quando as coisas falham. Porque sempre falham.
O incidente da CrowdStrike nao foi o primeiro e nao sera o ultimo. A pergunta nao e se sua startup vai enfrentar um incidente desse tipo. A pergunta e se seu time esta preparado para responder quando acontecer.
Seu time tem a capacidade tecnica para responder a um incidente em producao? Fale com um CTO -- te ajudamos a incorporar engenheiros senior em DevOps e SRE que constroem sistemas resilientes desde o dia um.
