Cloudflare Outage Was Caused by a Single Database Permission Change – How 'Minor' Internal Tweaks Can Bring Down the Internet
클라우드플레어 대규모 장애, 단 하나의 데이터베이스 권한 변경이 인터넷 전체를 마비시켰다
blog.cloudflare.com
So let me get this straight: a five-minute database permission tweak somehow generated double-sized bot configs, crashed a globally distributed proxy system, and took half the internet offline? That’s not a bug—it’s poetic failure. At some point, the 'fix' became the exploit.
정리해보자면, 데이터베이스 권한을 다섯 분 만에 조정한 게 어쩌다 보니 봇 설정 파일 크기를 두 배로 만들었고, 전 세계에 퍼진 프록시 시스템을 다운시키고 인터넷 절반을 오프라인으로 만들었다고? 이건 버그라기보다는 시적인 실패다. 어느 순간, '수정 사항' 자체가 공격 코드나 다름 없게 되어버렸다.
What’s wild is that they initially thought it was a DDoS attack. Turns out the true enemy was unchecked internal automation and assumptions baked into code paths deeper than a burrito at Chipotle.
놀라운 건 그들이 처음엔 이것이 DDoS 공격이라고 생각했다는 점이다. 진짜 원인은 치폴레의 부리토보다도 더 깊숙이 박혀 있던 코드 경로 속에 내장된, 통제되지 않은 내부 자동화와 가정들이었다.
메모리 사전 할당은 양날의 검이다. 빠르게 만들긴 하지만, 임의의 한계값을 코드에 고정하고 입력 검증을 생략한다면? 이건 엔지니어링이 아니라 시간이 지나면 터질 시한폭탄을 유지하는 것이다.
내부 설정 업데이트를 사용자 입력처럼 다뤘다면 이런 일은 없었을 것이다. '신뢰할 수 있는 소스'란 정보보안 분야에서 가장 오래된 거짓말이다.
정말 그거다. 이제 우리는 설정 수집 파이프라인에 대해 카오스 실험까지 한다. 믿되 확인하라—자동화된 적팀 테스트를 통해.
이건 보이지 않는 상태 전이로 시작된 연쇄적 장애의 전형적인 사례다. 진짜 비극은 무엇인가? 설정 파일 크기에 대한 무변수 체커가 없었다는 것이다. 이런 종류의 장애 양상은 우리가 90년대부터 알고 있던 것이다.
진짜로 그들이 인프라 작업을 '사소한 것'이라고 부르는 걸 그만둬야 한다. 모든 엔지니어가 알다시피, 변경 사항이 조용할수록 실패는 더 크게 운다.
그래서 11시 30분에 은행 앱이 안 된 거군. 고맙다, 클라우드플레어. 내 401k가 0.3% 하락했다.
심지어 가장 건강한 조직도 속도가 최우선일 땐 기본을 잊는다. 제로 트러스트는 사용자에게만 해당되지 않는다—설정 파일에도 적용되어야 한다.
그런데도 우리는 여전히 학생들에게 '완벽한 시스템'을 가르치고 있다. 언제부터 실패 모델부터 가르칠 것인가?