Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Bunny CDN의 보안 사고 대응 과정과 책임 소재에 대한 분석 글입니다. 인프라 제공업체의 무단 접근이 있었으나, 작성자는 회사 측의 사후 조치(특히 TLS 인증서 폐기 요구)와 증거 보존 방식에 대해 비판적인 시각을 제시합니다. 서비스 제공업체는 외주 업체의 실패에 대한 책임을 져야 한다고 주장하며 보안 거버넌스를 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기기대했던 대로 Bunny의 대응이 신속하고 유능함.
공지에 따르면 지난주 인프라 제공업체에서 외부 서버 관리 소프트웨어와 관련한 무단 접근을 알렸으며, 해당 업체 서버에 아르메니아 CDN 노드 하나가 운영되고 있었음. 통보 후 20분 이내에 트래픽 전달을 중단하고, 조사에 필요한 보안 로그를 검토·보존한 뒤 서버를 안전하게 삭제하고 다른 시스템에 대한 접근 권한을 회수함. 해당 서버는 인프라에서 영구 제거함.
유능해 보이지만 회사에 상당히 불리한 대목도 있음. 특히 고객이 Bunny에 맡긴 TLS 인증서를 고객이 직접 폐기해야 한다는 점이 걸림. 받은 이메일 맨 끝에 있던 내용인데, 고객의 비밀 정보가 실제로 침해됐다는 뜻이라 유일하게 마음에 들지 않았음. 모든 고객에게 인증서 폐기를 후속 안내했기를 바람.
지나치게 중립적이라고 할지 모르겠지만, Cloudflare가 같은 글을 썼어도 이런 평가를 받았을지는 의문임.
공급업체를 통해 영향을 받았어도 보안 사고인 건 마찬가지 아닌가? 제목에 맥락이 부족하다는 건 이해하지만, 왜 오해를 부른다는 건지는 모르겠음.
딱히 오해를 부르지는 않음. 여기에는 Bunny 사용자가 많고, 이들에게 관련 있는 보안 사고임. 큰 과실이라기보다 사고가 발생했으니 영향 여부를 확인하고 필요한 조치를 하라는 안내에 가까움.
솔직히 내가 쓰는 서비스의 인프라 제공업체에서 사고가 났다면 바로 이런 표현을 보고 싶음. 그래야 주의를 기울여 내가 신경 써야 할 일인지 판단할 수 있음.
Rickover의 책임에 관한 글을 또 붙여 넣어야 하나? 간단히 말해 서비스 제공업체는 외주업체 선택과 그 결과에 책임을 져야 함. 부실한 호스팅 업체 때문에 침해당하는 것도 그 업체를 이용하는 데 따르는 위험임. Bunny는 여기서 책임을 인정하며 올바르게 대응하고 있음.
지난주 Uber Eats에서 주문에 30분을 쓰고 마지막 확인을 누르자 식당이 그날 주문을 마감했다는 안내가 떴음. 식당에 전화하니 Uber Eats로만 주문을 받고 시스템을 통제할 수 없어 도울 수 없다고 함.
하지만 전화로 주문을 받거나, 고객에게 제대로 서비스하는 외주업체를 선택할 수 있었으므로 책임은 전적으로 식당에 있음. 나도 고객을 위해 외주업체를 쓴다면 “그 업체의 실패는 내 문제가 아니고 통제할 수도 없다”고는 절대 하지 않을 것임. 그러면 무책임하고 무능해서 믿을 수 없는 업체로 보일 뿐임.
공지에 따르면 두 조사 모두 서버에 대한 무단 접근 흔적을 발견하지 못했지만, 가능성을 완전히 배제하지는 못함. 접근이 있었다면 임시 캐시된 CDN 콘텐츠, Pull Zone 설정, TLS 인증서가 노출됐을 수 있음.
예방 차원에서 Bunny 플랫폼 도메인인 b-cdn.net과 bunny.run의 인증서는 모두 폐기·재발급했으며, 사용자 지정 도메인의 관리형 인증서도 24시간 내 재발급 완료를 예상함. 관리형 인증서 사용자는 조치할 필요가 없지만, 직접 관리하는 인증서는 새 개인 키로 폐기·재발급할 것을 권고함. 계정 정보를 비롯한 다른 고객 데이터는 해당 서버에 없었고 내부 시스템도 영향을 받지 않았다고 함.
그렇다면 인프라 제공업체 쪽에서 디스크 읽기 같은 접근이 가능했을 수 있고, 위 목록은 당시 디스크에 있었을 법한 정보라는 뜻인가? 내가 제대로 이해한 건가?
잠재적 침해에 대응할 때는 사고를 격리하고 조사를 위해 모든 것을 보존해야 함. 무엇을 남기고 버릴지 선별해서는 안 됨.
로그만 보존하고 서버를 삭제했다면 증거를 없앴을 가능성이 크며, 공격자가 실제로 서버에 침입했는지, 침입했다면 어떻게 했는지 확인하지 못할 수 있음. 사고 대응 계획이 부실하거나 아예 없다는 걸 보여줌.
거의 매시간 사고가 터지는 느낌임.
외부 서버 관리 소프트웨어와 관련한 무단 접근이라는 게 물리적 보안을 뜻하는 건가? 누군가 서버를 가져갔다는 식인가?
코로케이션 업체는 보통 물리적 보안 외에는 관여하지 않는데, 그게 달라진 건가?
내가 알기로 php.net과 PECL도 Bunny를 사용함. 발견하지 못했다면 변조된 패키지가 유포될 가능성이 상당했겠지만, 피해자가 해당 CDN 노드에 접속해야 하므로 영향 범위는 모르겠음.
첫 화면의 보안 사고 소식이 감당하기 어려울 정도로 늘어난 것 같은데 나만 그런가? 내가 그런 소식에 민감해진 건지, 최근 공격이 빨라진 건지 모르겠음.
실제로 심각한 사고가 늘고 있음. 새로운 사이버 보안 특화 모델의 능력이 대단함.
나만 그런 건 아님. 짧은 여행으로 며칠 동안 제대로 읽지 못하다 돌아왔는데, 지금 첫 화면에 진행 중인 보안 침해가 다섯 건쯤 올라와 있음.
수년간 안일한 CEO들이 “별일 없겠지” 하며 방치한 결과가, LLM이 초보 공격자를 위험한 해커로 바꾸면서 드디어 드러나는 셈임.
안타깝지만 충분히 예상 가능한 일이었음. 예전에 동료와 함께 Bunny를 서비스 제공업체 후보로 검토하면서, 알려진 보안 모범 사례를 따르는지 확인하려고 기본적인 상위 수준의 보안 질문을 했음. 세부 구현을 물은 것도 아니었음.
그런데 답변은 일관되게 “보안상의 이유로 알려줄 수 없다”였고, 여기서 경계심이 들었음. 보안을 큰 틀에서조차 논의할 의향과 능력이 없을 만큼 자신이 없는 업체는 신뢰할 수 없다고 봄.
Bunny가 CDN 거점의 서버를 직접 소유하지 않는다는 건 꽤 알려져 있음. 따라서 언제나 서버 임대업체의 보안 수준에 종속될 수밖에 없음. 좋은 보안을 원하면 그만큼 비용을 내야 함. Bunny는 시장에서도 확실히 저가에 속하고 서버에는 돈이 들기 마련이므로, 결국 가격만큼 얻는 셈임.