방치된 IAM 역할 타고 번진 데이터 레이크 침해: Qubole AWS 크로스 어카운트 자격증명 유출 사건 분석
공격자가 데이터 플랫폼 Qubole의 AWS 테넌트 자격증명을 탈취해 고객사 클라우드 환경에 침투했다. 미사용 IAM 역할과 신뢰 정책의 맹점을 악용한 공격 경로와 엔터프라이즈 방어 대책을 분석한다.
발행일: 2026.11.10
2026년 10월 14일–26일 AssumeRole 악용
Qubole 플랫폼의 중앙 AWS 계정 ID
관리 이벤트만 활성화되어 유출 객체 추적 불가
엔터프라이즈 클라우드 환경에서 서드파티 SaaS를 연동할 때 널리 쓰이는 AWS 크로스 어카운트(Cross-Account) 신뢰 관계가 침해 통로로 악용되었다. 클라우드 보안 기업 위즈(Wiz)와 센트라(Sentra)에 따르면, 공격자는 이데라(Idera) 산하 데이터 레이크 플랫폼 큐볼(Qubole)의 AWS 계정 자격증명을 확보한 뒤 큐볼 고객사들의 AWS 계정으로 불법 횡적 이동을 감행했다.
이번 침해의 핵심은 공격자가 개별 기업의 인프라를 직접 해킹한 것이 아니라는 점이다. 공급사의 중앙 관리 계정을 장악한 뒤, 고객사 계정에 등록된 IAM 역할의 신뢰 정책(Trust Policy)을 타고 넘어가는 공급망 공격 형태를 띠었다.
AWS 외부 IP에서 시작되어 고객사 내부 시크릿 및 S3 데이터 유출로 이어진 공격 파이프라인
공격자가 공급사 AWS 계정(805246085872) 자격증명 획득
AWS 외부 IP에서 고객사 IAM 역할로 External ID 동반 세션 요청
Lambda 환경변수, Secrets Manager, SSM Parameter Store 탈취
Okta·Entra ID 키 검증 후 S3 버킷 전체 다운로드
서드파티 크로스 어카운트 IAM 신뢰 메커니즘과 권한 악용 원리
큐볼과 같은 데이터 레이크 플랫폼은 고객사 AWS 계정 내 리소스에 접근하기 위해 교차 계정 IAM 역할을 요구한다. 고객사는 큐볼의 AWS 계정 ID(805246085872)를 신뢰 주체(Principal)로 지정하고, 혼동된 대리인(Confused Deputy) 공격을 방지하기 위해 공급사가 발급한 고유 식별값인 익스터널 ID(External ID)를 조건문(sts:ExternalId)에 결합한다.
공격자는 이 신뢰 구조의 맹점을 정확히 찔렀다. 큐볼 플랫폼 계정의 실제 자격증명을 탈취한 상태였기 때문에, 고객사 계정에 설정된 익스터널 ID만 확보하면 합법적인 AssumeRole 요청을 생성할 수 있었다. AWS 공식 보안 가이드에 명시되어 있듯 익스터널 ID는 비밀번호나 시크릿 키가 아니며, 해당 역할을 조회할 수 있는 내부 사용자에게 노출되는 식별 코드에 불과하다.
공급사 테넌트 훼손 시 고객사 환경으로 권한이 전이되는 메커니즘
큐볼 사용을 중단했으나 AWS 계정 내 신뢰 관계를 방치한 고객사 다수 피격
공급사 테넌트가 탈취되면 External ID 검증 조건문이 무력화되는 구조
신뢰 정책 내 aws:SourceIp 제한 추가 및 서비스 해지 시 역할 즉시 삭제
피해를 입은 다수의 IAM 역할은 이미 실무에서 사용되지 않던 유휴 상태였다. 프로젝트가 종료되었거나 큐볼 플랫폼 사용을 중단했음에도 인프라 관리자가 IAM 역할과 신뢰 정책을 삭제하지 않고 방치했다.
공격자는 비활성 상태인 유휴 역할이라도 신뢰 관계만 유지되어 있다면 얼마든지 세션을 생성할 수 있다는 점을 악용했다. 또한 큐볼 연결 시 IAM 역할 대신 영구 AWS 액세스 키(Access Key)를 발급했던 조직들 역시 10월 8일부터 11일 사이에 별도의 자격증명 악용 공격을 받았다.
침해 기간 자산 노출 범위와 자격증명 탈취 비교
공격자는 고객사 AWS 환경에 진입한 직후 체계적인 자격증명 수집 및 내부 정찰을 수행했다. 계정 내에 보관된 다른 시스템의 민감 자격증명을 긁어모아 2차 피해를 유발하는 형태였다.
AWS 람다(Lambda) 함수의 환경 변수를 읽어 들였고, AWS 시크릿 매니저(Secrets Manager)와 시스템 매니저 파라미터 스토어(SSM Parameter Store)의 등록값을 일괄 조회했다. 공격자는 탈취한 자격증명을 오픈소스 시크릿 스캐너인 트러플호그(TruffleHog)에 입력하여 실제 동작 여부를 즉시 검증했다.
| 탈취 대상 자산 | 침해 확인 리소스 유형 | 공격자 실행 행위 | 엔터프라이즈 영향도 |
|---|---|---|---|
| AWS 자체 권한 | IAM User Access Key, STS Session | 추가 권한 획득 및 리소스 접근 | 고객사 클라우드 내부 제어권 장악 |
| 엔터프라이즈 IdP | Okta Client Credentials, Microsoft Entra ID Secrets | API 및 인증 플랫폼 유효성 테스트 | 전사 싱글사인온(SSO) 및 SaaS 침투 위험 |
| 스토리지 자산 | Amazon S3 버킷 내 오브젝트 | 버킷 내 데이터 일괄 다운로드 | 핵심 데이터 레이크 원본 유출 |
| 서버리스 런타임 | AWS Lambda 환경 변수 | 평문 보관된 DB 접속 정보 및 토큰 수집 | 백엔드 데이터베이스 무단 접속 가능 |
| 설정 관리소 | SSM Parameter Store, Secrets Manager | 저장된 모든 시크릿 값 원격 덤프 | 서드파티 API 연동 키 전면 유출 |
공격자는 특정 데이터를 선별적으로 검색하지 않고 해당 역할이 접근할 수 있는 모든 S3 버킷을 무차별적으로 긁어모았다. 단일 세션 안에서 버킷 전체를 통째로 다운로드하는 공격 패턴이 확인되었다.
이 공격을 통해 피해 기업의 자체 AWS 액세스 키뿐 아니라 오크타(Okta)와 마이크로소프트 엔트라 ID(Entra ID) 클라이언트 시크릿까지 외부로 넘어갔다. 클라우드 인프라 하나가 뚫리면서 기업 전체의 인증 백본이 위협받는 연쇄 침해로 이어진 셈이다.
영구 자격증명 방식과 임시 STS 역할 위임 방식의 리스크 구조
- + 영구 액세스 키 발급 및 교체 오버헤드 제거
- + External ID를 통한 혼동된 대리인 공격 차단
- + 세션 만료 시간(최대 12시간) 강제 적용
- – 신뢰 정책 내 IP 제한 없으면 외부 인터넷에서 직접 호출 가능
- – 미사용 유휴 역할이 남아있을 경우 영구적인 백도어로 변질
- – SaaS 플랫폼 침해 시 모든 연동 고객사가 동시 피격
CloudTrail S3 로깅 사각지대와 포렌식 장애 요인
사고 조사 과정에서 기업들의 보안 가시성 결손이 심각한 문제로 드러났다. 공격 징후를 확인하기 위해서는 2026년 10월 1일 이후의 AWS 클라우드트레일(CloudTrail) 로그를 전수 조사해야 한다.
큐볼의 플랫폼 계정인 805246085872에서 발생한 AssumeRole 요청 중 AWS 내부 대역이 아닌 외부 공인 IP 주소에서 유입된 이벤트를 식별하는 것이 핵심이다. 그러나 실제 침해 피해를 입은 다수 기업은 어떤 데이터가 유출되었는지 파악하지 못했다.
기본 로깅 설정만으로는 실제 객체 유출 여부를 증명할 수 없다
- • AssumeRole 세션 생성 기록 추적 가능
- • S3 버킷 목록 조회(ListBuckets) 확인 가능
- • 실제 파일 다운로드(GetObject) 기록 누락
- • 개별 파일 다운로드 건별 정밀 기록
- • 다운로드된 객체의 정확한 용량 및 경로 추적
- • 법적 증거 능력 및 유출 피해 규모 산출 가능
클라우드트레일의 기본 관리 이벤트(Management Events)는 AssumeRole 호출이나 S3 버킷 목록 조회(ListBuckets)까지만 기록한다. 버킷 내부의 특정 객체를 읽어간 행위(GetObject)는 S3 데이터 이벤트(Data Events)나 S3 서버 액세스 로그를 별도로 켜두지 않으면 기록에 남지 않는다.
비용 절감을 이유로 데이터 이벤트를 비활성화해 둔 피해 기업들은 공격자가 S3 버킷에 접근한 사실은 확인했으나, 실제 어떤 기밀 데이터가 다운로드되었는지 증명하지 못했다. 이는 규제 기관 보고 및 고객 통지 단계에서 심각한 법적·재무적 리스크로 이어진다.
S3 데이터 이벤트 비용은 10만 건당 약 0.10달러 수준이다. 테라바이트급 데이터 레이크 환경에서는 월 수백에서 수천 달러의 로깅 비용이 발생할 수 있으나, 이를 전면 배제한 결과 수억 원대 이상의 침해 조사 비용과 불확실성을 떠안게 되었다.
유휴 IAM 신뢰 제거와 서드파티 크로스 어카운트 방어 프레임워크
이번 사건은 서드파티 SaaS 시스템 연동 시 ‘역할을 만들어두고 잊어버리는’ 인프라 관리 관행에 경종을 울린다. 기업 보안팀과 클라우드 엔지니어링 리더는 다음 4단계 프레임워크에 따라 즉각적인 방어 및 격리 조치를 단행해야 한다.
침해 흔적 확인부터 영구적인 신뢰 통제 수립까지
계정 ID 805246085872가 포함된 모든 IAM 역할 및 정책 파기
10월 1일 이후 외부 IP에서 발생한 AssumeRole 이벤트 추출
Okta, Entra ID, AWS Access Key 전면 재발급 및 세션 종료
서드파티 신뢰 정책에 aws:SourceIp 및 aws:PrincipalArn 제한 삽입
1. 큐볼 관련 잔존 권한 파기 및 임시 자격증명 폐기
신뢰 주체에 805246085872 계정이 포함된 모든 IAM 역할을 즉시 비활성화하거나 삭제해야 한다. 과거 큐볼 서비스에 연결했던 영구 IAM 사용자 액세스 키가 남아있다면 즉시 비활성화 후 폐기한다. 기존에 발급된 STS 임시 세션을 무효화하기 위해 해당 IAM 역할에 인라인 거부 정책(aws:CurrentTime 기준 폐기)을 연결해야 한다.
2. 2차 노출 자격증명 무효화 및 로테이션
해당 IAM 역할이 접근 권한을 가졌던 AWS Secrets Manager, SSM Parameter Store, Lambda 환경 변수를 전수 검사해야 한다. 여기에 등록되어 있던 마이크로소프트 엔트라 ID 클라이언트 시크릿, 오크타 API 토큰, 데이터베이스 접속 비밀번호, 사내 서비스 API 키를 전면 로테이션해야 한다. 공격자가 이미 트러플호그로 검증을 마쳤으므로 기존 자격증명은 이미 외부에 유출된 것으로 간주하고 처리해야 한다.
3. 신뢰 정책 조건문 강화 및 발신 IP 제한
향후 서드파티 SaaS에 크로스 어카운트 역할을 부여할 때는 단순 계정 ID와 익스터널 ID 조합에만 의존해서는 안 된다. 공급사가 공개하는 공식 정적 IP 대역이 존재한다면 신뢰 정책 조건문에 aws:SourceIp 조건을 반드시 명시해야 한다. 공급사 인프라가 탈취되더라도 공격자가 임의의 외부 인터넷망에서 직접 AssumeRole을 호출하는 것을 원천 차단할 수 있다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::VENDOR_ACCOUNT_ID:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "UNIQUE_ENTERPRISE_ID"
},
"IpAddress": {
"aws:SourceIp": [
"VENDOR_STATIC_IP_RANGE/32"
]
}
}
}
]
}4. 미사용 IAM 역할 자동 탐지 및 파기 파이프라인 수립
클라우드 운영 관리 도구를 활용해 30일 이상 AssumeRole 호출이 발생하지 않은 서드파티 IAM 역할을 자동 식별해야 한다. 프로젝트 종료나 벤더 계약 해지 시 SaaS 대시보드에서 연동만 끊을 것이 아니라, 클라우드 테라폼(Terraform) 코드 및 계정 내 신뢰 정책을 삭제하는 오프보딩 프로세스를 의무화해야 한다. 잔존하는 유휴 역할은 언젠가 뚫릴 수밖에 없는 열린 문과 같다.