[관점]
자산 관리 강화로 이 문제를 풀려는 시도는 대체로 실패한다. 등록 절차를 조이면 실습 인스턴스는 등록을 피해 개인 계정이나 사업부 계정으로 옮겨갈 뿐이다. 통제가 강해질수록 그림자 자산이 늘어나는 전형적인 구조다.
이 사안의 본질은 자산 관리가 아니라 계정 설계다. 실습용 인스턴스가 위험한 이유는 그것이 취약해서가 아니라 운영 계정 안에 들어 있기 때문이다. 같은 인스턴스가 신뢰 관계가 끊긴 별도 계정에 있으면 뚫려도 거기서 끝난다.
그래서 먼저 물어야 할 것은 「우리 실습 서버 목록이 있는가」가 아니다. 「실습·데모 목적의 리소스가 운영 계정과 같은 신뢰 경계 안에 있는가」다.
보안 교육이나 신입 개발자 실습을 위해 의도적으로 취약한 웹 애플리케이션을 띄우는 일은 흔하다. 목적이 분명하고 기간도 짧다. 문제는 그 기간이 끝난 뒤다. 교육이 끝나도 인스턴스는 남고, 담당자는 부서를 옮기고, 자산 목록에는 처음부터 등록되지 않았다.
Pentera Labs 는 이 방치된 실습 앱이 실제로 대기업 클라우드 침해의 진입점이 되고 있음을 대규모로 확인하였다.
규모 — 추정이 아니라 실측
연구팀은 초기 검색에서 1만 건 이상의 후보를 수집한 뒤 실제로 살아 있는 취약 애플리케이션 1,926개를 검증하였다. 이 가운데 974개, 약 60%가 AWS·Azure·GCP 위에서 동작하고 있었다. 노출된 고유 자격증명 세트는 109건이 확인되었다.
DVWA 하나만 떼어 보면 성격이 더 분명해진다. 발견된 616개 인스턴스 중 54%인 334개가 기본 자격증명을 그대로 사용하고 있었고, 약 20%에서는 이미 공격자가 남긴 흔적이 발견되었다. 크립토마이너, 웹셸, 지속성 확보 스크립트가 그것이다.
마지막 수치가 이 리서치의 핵심이다. 이 자산들은 「언젠가 위험해질 수 있는 것」이 아니라 이미 남의 손에 들어가 있는 것이다.
경로 — 취약한 앱 하나가 계정 전체로
연구가 보여 주는 경로는 짧다. 공개 IP 로 노출된 실습 앱에 기본 자격증명으로 들어간다. 실습 앱은 취약점을 학습시키려는 목적으로 만들어졌으므로 진입 자체는 설계된 결과다.
문제는 그다음이다. 이 인스턴스는 대개 사내 클라우드 계정 안에 있고, 인스턴스 메타데이터 서비스를 통해 임시 IAM 자격증명을 꺼낼 수 있다. 실습 편의를 위해 역할 권한을 넓게 준 경우가 많아, 확보한 자격증명이 관리자급으로 이어진다. 그 지점부터는 스토리지 버킷, 시크릿 매니저, 컨테이너 레지스트리가 열린다.
리서치는 Cloudflare, F5, Palo Alto Networks 사례를 실명으로 공개한다. 보안을 업으로 하는 회사들이다. 자산 관리 역량이 부족해서 생긴 문제가 아니라는 뜻이고, 국내 조직이 「우리는 다르다」고 말하기 어려운 근거이기도 하다.
연구팀은 이 탐색을 자동화하기 위해 LLM 기반 인식 프레임워크를 만들어 오픈소스로 공개하였다. 방어 측이 같은 도구로 자사 노출을 먼저 찾을 수 있다는 뜻이지만, 공격 측의 탐색 비용도 함께 하락한다는 뜻이기도 하다.
권고
리서치는 일곱 가지를 제시한다. 클라우드 리소스 인벤토리 유지, 최소 권한 원칙 적용, 네트워크 격리와 아웃바운드 제한, Shodan·Censys 를 통한 정기 스캔, 임시 리소스 자동 만료 정책, 배포 전 기본값 변경 강제, 그리고 테스트 환경에도 운영과 동일한 모니터링 적용이다.
국내 적용 관점
국내에서 이 유형은 「오픈 전 검증용 서버」로 반복되어 왔다. 대외 서비스 오픈을 앞두고 검증용으로 띄운 서버가 오픈 이후에도 남아, 실 데이터를 담은 채 노출되는 형태다. 개인정보 처리 시스템으로 등록되지 않았으니 접근통제·암호화 점검 대상에서도 빠져 있다. 국내 대기업과 공공기관의 유출 사고 원인 분석에서 방치된 테스트·개발 서버가 반복해서 지목되어 온 이유가 여기에 있다. 리서치가 제시한 DVWA 수치는 이 관행이 국내만의 문제가 아님을 보여 준다. 국내에서 이 자산이 특히 오래 남는 이유는 삭제 책임이 정해져 있지 않기 때문이다. 생성은 요청자가 하지만 삭제는 아무도 소유하지 않는다. 생성 시점에 만료일과 소유자를 함께 기록하지 않으면 이후 어떤 점검으로도 정리되지 않고, 담당자 이동과 함께 소유자 정보만 사라진다.
실효성 있는 조치는 목록이 아니라 계정 분리다. 실습·데모 목적 전용 계정 또는 구독을 따로 두고 운영 계정과 신뢰 관계를 끊는다. 해당 계정의 리소스에는 만료 태그를 강제하고 기한이 지나면 자동 정지시킨다. 이 두 가지가 서면 인벤토리 정확도와 무관하게 피해 범위를 고정한다. 인벤토리는 그다음 문제다. 순서를 뒤집으면 인벤토리를 만드는 몇 달 동안 노출이 그대로 유지된다. 신뢰 관계 차단과 만료 정책은 목록 없이도 계정 단위로 즉시 적용할 수 있다는 점이 이 순서의 근거다.
메타데이터 서비스 접근 설정이 국내에서 특히 방치되어 있다. 경로의 핵심 고리는 인스턴스 메타데이터에서 임시 자격증명을 꺼내는 단계다. AWS 라면 IMDSv2 강제, GCP·Azure 라면 메타데이터 접근 제한 설정이 이 고리를 끊는다. 국내 조직 다수가 클라우드 도입 초기 설정을 그대로 유지하고 있어, 이 항목 하나만 점검해도 경로의 성립 조건이 사라진다. 함께 볼 것은 실습 인스턴스에 붙은 IAM 역할의 권한 범위와 해당 서브넷에서 운영망으로의 통신 허용 여부다. 한 가지 함정이 있다. 이 설정은 신규 인스턴스에만 적용되는 경우가 많아, 기존 인스턴스는 별도 일괄 변경이 필요하다. 변경 전에는 메타데이터에 의존하는 애플리케이션이 있는지 확인해야 한다. 오래된 배포 스크립트가 여기에 걸리는 사례가 있다.
ASM 도입 논거로 이 사례가 유효한 이유는 비용 구조가 명확하기 때문이다. 내부 자산 관리 개선은 여러 부서의 협조가 필요하지만, 외부 관점 스캔은 보안팀 단독으로 착수할 수 있고 첫 스캔에서 대개 몇 건이 도출된다. 그 몇 건이 다음 예산 논의의 근거가 된다. 리서치가 쓴 방법도 Shodan·Censys 수준의 공개 검색이므로, 자사 도메인과 IP 대역을 대상으로 같은 검색을 돌려 보는 것부터 착수할 수 있다. 첫 스캔에는 도구 도입이 필요 없다. 공개 검색으로 결과가 나오면 그때 도구와 예산을 논의하는 편이 순서가 맞고, 실제로 확인된 몇 건이 논의 자체를 단축한다.
점검 항목
질문 1 실습·교육·데모 리소스가 운영 계정과 신뢰 관계를 공유하는가?
질문 2 인스턴스 메타데이터 서비스 접근이 제한되어 있는가?
기존 인스턴스에도 적용되었는가, 신규에만 적용되었는가?
질문 3 실습 인스턴스의 IAM 역할 권한 범위와 운영망 통신 허용 여부는?
질문 4 임시 리소스에 만료일과 소유자가 생성 시점에 기록되는가?
질문 5 자사 도메인·IP 대역을 외부 관점에서 정기적으로 조회하는가?출처 · Pentera Labs, When the Lab Door Stays Open: Exposed Training Apps Exploited for Fortune 500 Cloud Breaches (2026-01-21, Noam Yaffe)