CDN을 운영하는 조직이 공급업체를 평가할 때 흔히 묻는 질문은 “이 업체가 안전한가”다. 그러나 운영 중인 서비스에는 더 불편하지만 실용적인 질문이 있다. 우리 CDN 또는 그 인프라 공급업체 중 한 곳이 침해됐을 때, 몇 분 안에 트래픽과 권한을 끊고 어떤 데이터가 영향을 받았는지 설명할 수 있는가다.
이 질문은 공급업체의 평판을 평가하는 일이 아니다. 한 CDN 노드가 의심 상태가 되었을 때, 그 노드가 전체 서비스 경로·인증서·관리 권한·고객 데이터로 번지는 것을 막는 설계를 점검하는 일이다.
Bunny CDN이 공개한 보안 사고 공지는 이 차이를 보여준다. 해당 회사는 인프라 공급업체의 제3자 서버 관리 소프트웨어 관련 무단 접근 통지를 받은 뒤, 아르메니아에 있던 CDN 노드 한 대의 트래픽 경로를 20분 안에 중단했다고 밝혔다. 이어 관련 로그를 보존·검토하고 서버를 삭제했으며 다른 시스템에 대한 접근도 철회했다. 조사 시점에 해당 서버 접근 증거는 발견하지 못했지만, 가능성을 완전히 배제할 수는 없다고 설명했다.
여기서 운영 책임자가 봐야 할 것은 “접근 증거가 있었는가”만이 아니다. 의심을 확인하는 동안에도 노드를 서비스 경로와 관리 권한에서 분리할 수 있었는지, 그리고 고객에게 어떤 범위가 잠재적으로 노출될 수 있는지 구분해 알릴 수 있었는지다.
실패는 침해 자체보다 연결된 권한에서 커진다
CDN 노드 한 대가 손상되었다고 해서 곧바로 전체 계정 데이터나 내부 시스템이 유출되는 것은 아니다. 반대로 노드 하나라도 캐시 콘텐츠, 배포 설정, TLS 인증서, 원본 서버 접근 정보, 관리 API 권한과 넓게 연결돼 있다면 영향은 빠르게 커질 수 있다.
Bunny CDN이 언급한 잠재적 노출 범위는 임시 캐시 콘텐츠, Pull Zone 설정, 해당 서버에 저장된 TLS 인증서였다. 계정 데이터와 다른 내부 시스템은 그 서버에 저장되지 않았다고 밝혔다. 이 구분은 “침해 여부”와 별개로, 노드에 어떤 자산을 두었는지에 따라 조사와 복구의 범위가 달라진다는 점을 보여준다.
CDN 보안 검토에서 확인할 대상은 다음처럼 나뉜다.
- 트래픽 경로: 의심 노드나 특정 지역·공급업체를 라우팅 대상에서 즉시 제외할 수 있는가
- 관리 권한: 해당 노드 또는 운영 환경이 다른 시스템에 접근하는 자격증명을 얼마나 갖고 있는가
- 전송 보안 자산: TLS 인증서와 개인 키가 어느 시스템에 존재하며, 의심 시 재발급·교체 범위는 어디까지인가
- 캐시 데이터: 노드에 남을 수 있는 콘텐츠가 공개 정적 파일인지, 인증이 필요한 응답이나 민감한 결과물인지
- 조사 증거: 격리 전에 필요한 로그를 보존하고, 이후 해당 노드의 요청·설정 변경·권한 사용 흔적을 확인할 수 있는가
이 다섯 항목이 분리돼 있지 않으면 사고 대응은 “서버를 내렸다”에서 멈춘다. 서버를 내린 뒤에도 어떤 인증서가 남았는지, 어떤 설정이 노출됐을 수 있는지, 다른 시스템으로 이어지는 권한이 있었는지를 설명하지 못하면 고객·감사·경영진에게 영향 범위를 입증하기 어렵다.
조기 신호는 침해 경보보다 ‘철회가 어려운 구조’에서 먼저 보인다
사고는 탐지 시스템이 경보를 낼 때 시작되지 않는다. 의심 노드를 끊는 데 사람의 수동 확인, 공급업체 지원 요청, 변경 승인 대기, 여러 콘솔 이동이 필요할 때 이미 대응 시간은 길어진다.
다음 신호가 보이면 침해 여부와 무관하게 운영 설계를 다시 확인할 시점이다.
첫째, 특정 CDN 노드·리전·업스트림 공급업체를 제외하는 절차가 문서에는 있으나 실제 실행 책임자와 권한이 정해져 있지 않은 경우다. 장애 대응 권한과 보안 격리 권한이 다른 팀에 흩어져 있으면, 침해 의심 상황에서 트래픽 차단 결정이 늦어진다.
둘째, 노드 제거와 자격증명 철회가 별개로 관리되는 경우다. 서비스 경로에서 제외한 서버가 다른 관리 시스템이나 원본 자산에 계속 접근할 수 있다면, 라우팅 차단은 격리의 절반에 그친다.
셋째, 고객 도메인의 인증서 교체가 공급업체의 진행 상태에 전적으로 묶여 있고, 자체 인증서 고객의 조치 범위가 불명확한 경우다. Bunny CDN은 플랫폼 도메인 인증서를 철회·재발급하고, 관리형 사용자 정의 도메인 인증서도 재발급한다고 밝혔다. 자체 인증서를 관리하는 고객에게는 새 개인 키로 철회·재발급을 권고했다. 이처럼 인증서 운영 방식에 따라 복구 주체와 할 일이 달라진다.
넷째, 캐시되는 응답의 종류를 운영팀이 설명하지 못하는 경우다. “캐시가 있다”는 말만으로는 영향도를 판단할 수 없다. 어떤 URL과 응답 유형이 CDN에 남을 수 있는지, 인증 후 응답이 포함될 수 있는지, 설정상 이를 어떻게 제한하는지를 서비스별로 확인해야 한다.
공급업체 평가표에는 ‘사고 시 실행권’이 들어가야 한다
CDN이나 클라우드 공급업체를 선정할 때 보안 인증, 기능 목록, 지역 수, 장애 공지는 중요하다. 다만 운영 단계에서는 공급업체의 예방 통제만큼 고객과 공급업체가 사고 중 무엇을 직접 실행할 수 있는지도 평가해야 한다.
CTO나 개발 리드는 계약 갱신, 다중 CDN 검토, 보안 아키텍처 변경 전에 다음 질문을 담당 팀과 공급업체에 던져볼 수 있다.
-
의심 노드 또는 특정 인프라 공급업체를 트래픽 경로에서 제외하는 권한은 누구에게 있는가?
콘솔, API, 지원 요청 중 어느 방식으로 실행하는지와 승인 절차를 함께 확인한다. 목표 시간은 조직의 서비스 중요도에 맞게 정하되, “가능하다”는 답보다 실제 명령·화면·책임자를 확인하는 편이 낫다. -
노드를 제외한 뒤 어떤 접근 권한이 자동 또는 수동으로 철회되는가?
서버 접근, 배포 권한, 설정 동기화 권한, 원본 관련 자격증명, 관리 API 토큰을 하나의 목록으로 확인한다. 노드 폐기와 권한 철회가 같은 절차에 묶여 있지 않다면 별도 대응 단계로 명시해야 한다. -
인증서가 저장되거나 사용되는 위치는 어디이며, 재발급 시 고객이 해야 할 일은 무엇인가?
관리형 인증서와 고객 관리 인증서는 복구 방식이 다를 수 있다. TLS/DTLS 배포 보안 권고는 현재 사용하는 프로토콜과 설정을 점검하는 기준이 될 수 있지만, 사고 대응의 핵심은 인증서 교체 책임과 실행 순서를 미리 정해 두는 데 있다. -
잠재 노출 범위를 판단할 로그를 누가 보존하고 제공하는가?
공급업체의 조사 결과를 기다리는 동안 고객 조직도 자신의 DNS 변경 기록, 원본 접근 기록, 배포 이력, 인증서 관리 이력을 확인할 수 있어야 한다. 로그가 존재한다는 사실과 조사에 필요한 기간·형태로 확보할 수 있다는 사실은 다르다.
이 질문은 공급업체에 완벽한 무침해를 요구하기 위한 것이 아니다. 침해 가능성을 0으로 만들 수 없다는 전제에서, 의심 노드 하나를 서비스 전체와 분리할 수 있는지 확인하기 위한 질문이다.
복구 계획은 ‘서비스 재개’와 ‘신뢰 회복’을 분리해야 한다
트래픽을 다른 노드로 돌리면 사용자 관점의 서비스 장애는 짧아질 수 있다. 그러나 보안 사고의 복구는 그 시점에 끝나지 않는다. 의심 서버에 남았을 수 있는 자산을 분류하고, 필요한 접근을 철회하며, 인증서를 교체하고, 조사 가능한 기록을 보존해야 한다.
이 과정에서 “접근 증거가 없다”는 조사 결과는 중요하지만, 그 결과만으로 교체·철회 여부를 결정하기는 어렵다. Bunny CDN도 접근 증거를 발견하지 못했다고 밝히면서 인증서 재발급 조치를 진행했다. 이는 침해가 확인됐다고 단정하는 행동이 아니라, 조사 불확실성이 남아 있을 때 어떤 자산을 예방적으로 교체할지 판단한 사례로 볼 수 있다.
조직마다 같은 범위의 조치가 필요한 것은 아니다. 고객이 직접 인증서를 관리하는지, CDN이 인증서를 관리하는지, 어떤 콘텐츠가 캐시되는지, 특정 리전 중단이 서비스에 미치는 영향이 어떤지에 따라 대응은 달라진다. 그래서 사고 대응 문서는 공급업체의 일반 공지에 의존하기보다 자사 서비스의 자산 목록과 권한 연결 관계를 기준으로 작성해야 한다.
다음 보안 점검 회의에서는 “우리 CDN이 침해되면 무엇이 유출되는가”보다 먼저 이 질문을 확인해 보자. 특정 노드 하나를 지금 바로 서비스 경로와 관리 권한에서 분리하라고 지시하면, 누가 어떤 순서로 실행하고 몇 분 뒤 어떤 증거를 제시할 수 있는가. 답이 문서가 아니라 실행 가능한 절차로 나오기 전까지, CDN 보안 평가는 완료되지 않았다.
