휘발성 데이터 노출에 관한 미스터리

당사가 고객 계정의 탐지 결과와 알림을 상시 모니터링하는 것은 아니지만, 최근 한 고객사가 자동화된 조치로 나아가는 여정에서 당사에 보다 선제적인 역할을 요청해 왔습니다. 고객사의 요청에 따라 몇 가지 항목을 주시하고 있던 중... 흥미로운 일이 발생했습니다.

당사 CTO는 AWS에 퍼블릭 RDS 인스턴스가 노출되어 있다는 알림을 받았습니다. 그러나 고객사에 확인했을 때 해당 인스턴스는 더 이상 존재하지 않았습니다. 더 이상한 점은, 퍼블릭 RDS 인스턴스가 매일 밤 생성되었다가 50분 후에 종료되고 있었다는 것입니다. 이런 종류의 활동은 정해진 시점에 수행하는 평가에서는 놓치기 쉽습니다. 당사 CTO는 즉시 고객사에 이를 알리고 인벤토리에서 종료된 인스턴스의 메타데이터를 확보했습니다. 트리거 이벤트와 인스턴스 구성을 철저히(그리고 신속하게, 단 몇 분 만에) 조사한 결과, 다른 데이터베이스의 최신 스냅샷 백업을 기반으로 매일 밤 퍼블릭 인스턴스가 생성되고 있음을 확인했습니다. 이 인스턴스는 알려진 소수의 회사 IP 주소 목록에만 노출된 뒤(다행스러운 소식이었습니다) 얼마 지나지 않아 종료되었습니다.

조사 과정
고객사는 자체 조사를 진행했고, 이것이 데이터 센터에서 실행되는 ETL 자동화 프로세스의 일부임을 확인했습니다. 클라우드 측의 예약 작업이 임시 인스턴스를 퍼블릭으로 생성하고 소수의 IP 주소(5개로, 그래도 많아 보였습니다)로 접근을 제한하면, 데이터 센터가 연결하여 데이터를 추출하는 방식이었습니다. 실제 데이터 변환이 어디에서 이루어지는지는 끝내 확인하지 못했지만, 이는 이번 상황과 크게 관련이 없습니다.

이는 보안 팀에 흥미로운 과제를 제기했습니다. 알림 자체는 유효했지만 실제 보안 문제는 없었기 때문입니다(물론 퍼블릭 RDS 인스턴스보다 이 상황을 처리할 더 안전한 방법은 분명히 존재합니다). 매일 밤 새 인스턴스가 생성되므로 해당 인스턴스를 예외 처리하는 것은 선택지가 아니었습니다. 계정 전체를 검사에서 제외하는 것도 위험했는데, 실제로 노출된 RDS 인스턴스를 간과하게 될 수 있기 때문입니다. 태그 기반 예외 처리 역시 위험했습니다. 누군가 프로세스를 변경해 신뢰할 수 없는 IP 주소에 인스턴스를 노출시킬 수 있기 때문입니다.

얻은 교훈
제 조언은 평가 측면을 복잡하게 만들기보다 근본적인 프로세스를 바로잡는 데 집중하라는 것이었습니다. 실제로 이 프로세스는 절차적 관점에서 이상적이지 않습니다. 퍼블릭 RDS 인스턴스를 허용하는 것은 결코 바람직한 방식이 아닙니다. 필요한 경우가 있긴 하지만, 어디까지나 최후의 수단이어야 합니다. 대신 프라이빗 서브넷에 배치하고, 필요한 위치에서 전용 연결 또는 VPN 기반 연결을 통해 접근해야 합니다.

이번 건은 보안 노출로 이어지지 않았지만, 그래도 배울 만한 흥미로운 교훈이 있습니다. 첫째, 저는 이를 "거짓 오탐"이라고 부릅니다. 알림이 주의가 필요한 실제 상황을 가리켰지만, 이 특정 시나리오에서는 반드시 위험을 초래하지는 않았기 때문입니다. 실제 데이터 유출은 없었지만, 고객사는 조사와 해당 리소스 및 프로세스를 담당하는 팀과의 커뮤니케이션 없이는 이를 알 수 없었습니다.

둘째, 이 문제는 서비스 제어 정책(Service Control Policies)만으로 완전히 예방하기 어렵습니다. 퍼블릭 RDS 인스턴스를 차단하는 조건 키도 없고, 보안 그룹에서 데이터베이스 포트(또는 어떤 포트든)의 개방을 막는 조건 키도 없습니다.

셋째, 인스턴스가 휘발성이라는 점은 실시간으로 또는 매우 짧은 주기로 운영하지 않는 한 노출을 놓칠 수 있음을 의미합니다. 저는 사고 대응 교육에서 실제로 이 주제를 다루는데, 짧은 시간 안에 무언가가 노출되고 데이터가 유출된 뒤 증거를 없애기 위해 삭제되는 상황이 많기 때문입니다. 그래서 사고 대응 담당자는 언제나 배포 환경에 직접 접근할 수 있어야 하며, 과거 이력을 확인할 수 있는 인벤토리(AWS Config 또는 당사와 같은 서드파티 도구 등)에 접근할 수 있어야 합니다. API 호출만으로는 맥락이 부족해 무슨 일이 벌어지고 있는지 충분히 파악하지 못할 수 있습니다. 이번 사례에서도 노출은 탐지할 수 있지만, 어떤 포트가 어디에 노출되어 있는지 확인하려면 DB 인스턴스를 직접(또는 인벤토리에서) 살펴봐야 합니다.

넷째, 예방적 선택지가 제한적이기 때문에 탐지 및 시정 통제를 활용해야 합니다. 이번 사례에서는 CreateDBInstance API 호출을 직접 탐지하고 PubliclyAccessible=True 파라미터를 확인할 수 있습니다. 또한 퍼블릭 RDS 인스턴스에 대해 CSPM(역시 CSP 제공 도구나 당사 같은 벤더의 도구)으로 지속적인 모니터링을 수행할 것을 적극 권장합니다. 조치 측면에서는 인스턴스 생성이 탐지되면 이를 종료하는 방법이 하나의 선택지입니다. 다만 ModifyDBInstance를 사용해 PubliclyAccessible 파라미터를 제거하는 편이 더 나은 접근일 수 있습니다. 이 방법을 사용한다면, 퍼블릭 RDS 인스턴스가 허용되지 않음이 확실한 배포 환경에서만 이러한 자동화를 구현하는 것이 중요합니다. 팀과 소통하지 않아 3년간 정상 운영되어 온 승인된 데이터베이스 연결을 끊는 날은, 아마도 이력서를 꺼내야 할 날일 것입니다.

결과적으로 이번 사건은 고객사에 보안 위험을 초래하지 않았습니다. 그러나 보다 안전한 프로세스의 필요성을 부각시켰고, 고객사는 더 안전한 방식으로 처리할 수 있는 방안을 적극적으로 검토하고 있습니다. 이 사례가 특히 흥미로운 이유는 휘발성 데이터 노출, 유출, 반출이 실제로 우려되는 문제이며, 당사가 처음 발견한 정황이 실제 공격과 구분되지 않아 보였기 때문입니다. 깊이 파고든 후에야 당사와 고객사 보안 팀은 그것이 예정된 프로세스의 일부임을 알게 되었습니다. 좋은 관행을 정착시키기 위해 팀들과 긴밀히 협업하고, 클라우드의 매우 유동적인 특성을 감당할 수 있도록 모니터링 역량을 갖추며, 이처럼 이례적인 일이 발생했을 때 해당 배포를 담당하는 인원과 소통하는 것이 매우 중요합니다.

클라우드에서는 오탐과 정말 심각한 문제를 구분할 유일한 방법이 직접 관련된 담당자에게 확인하는 것뿐인 경우가 있습니다. 제가 슈뢰딩거의 구성 오류에서 썼듯이, 공격자는 어떤 제로데이 취약점에 의존하기보다 동일한 API 호출과, 안타깝게도 동일한 자격 증명을 활용합니다.

초청 연사

Rich Mogull

FireMon 클라우드 보안 부문 SVP
Rich는 FireMon의 클라우드 보안 부문 SVP로서 최첨단 클라우드 보안 연구와 구현을 이끌고 있습니다. 그는 Securosis의 CEO로 재직하던 당시의 연구를 기반으로 만든 클라우드 보안 자동화 플랫폼 DisruptOps가 인수되면서 FireMon에 합류했습니다. 25년 이상의 보안 경력을 보유하고 있으며, 약 10년 전부터 클라우드 분야에서 실무를 시작해 현재는 클라우드 보안과 DevSecOps를 전문으로 하고 있습니다. Securosis와 DisruptOps를 설립하기 전에는 Gartner 보안 팀의 리서치 부사장을 역임했습니다.