CSP 관리영역 침해 이후 권한 상승과 수평이동

클라우드 침해사고에서 가장 위험한 상황은 가상머신 한 대가 해킹된 경우가 아니다. 공격자가 CSP의 관리영역(Control Plane)에 접근할 수 있는 사용자 계정이나 서비스 계정의 권한을 확보한 경우다.

관리영역은 가상머신, 스토리지, 네트워크, IAM, 데이터베이스 같은 클라우드 자원을 생성하고 변경하는 영역이다. 공격자는 이곳에서 확보한 권한을 이용해 다른 계정과 워크로드로 이동하고, 경우에 따라 내부망이나 온프레미스 환경까지 침해 범위를 확장할 수 있다.

이러한 움직임을 모두 ‘피벗’이라고 표현하기도 하지만, 보안 관점에서는 다음과 같이 구분하는 것이 정확하다.

권한 상승: 현재보다 높은 권한을 획득하는 행위
수평이동: 확보한 권한을 이용해 다른 ID·계정·워크로드로 이동하는 행위
피벗: 장악한 시스템을 네트워크 경유지로 사용하는 행위

이 글에서는 CSP 관리영역 침해 이후 발생하는 권한 상승과 수평이동 과정을 중심으로 살펴본다. 침해한 워크로드를 통해 내부망으로 들어가는 단계에 한해서는 피벗이라는 용어를 사용한다.

관리영역 침해가 위험한 이유

전통적인 온프레미스 침해사고에서는 공격자가 서버에 접속한 뒤 내부 네트워크를 스캔하고, 취약한 시스템을 찾아 이동하는 방식이 일반적이었다.

클라우드에서는 양상이 다르다. 공격자가 관리영역의 자격증명을 확보하면 방화벽을 우회해 서버를 한 대씩 공격하지 않아도 된다. 정상적인 CSP API와 관리 기능을 이용해 다음 작업을 수행할 수 있기 때문이다.

조직·계정·구독·프로젝트 구조 확인
IAM 사용자, 역할 및 서비스 계정 열람
다른 역할이나 서비스 계정의 권한 획득
가상머신, 컨테이너 및 서버리스 자원 제어
보안그룹, 네트워크 ACL 및 라우팅 설정 변경
관리형 원격 명령 기능을 통한 워크로드 접근
스토리지와 데이터베이스 스냅샷 생성
새로운 자격증명과 신뢰 관계 생성
감사로그와 보안서비스 설정 변경

따라서 관리영역 침해는 단순한 관리자 콘솔 계정 탈취가 아니다. 클라우드 환경 전체의 제어 권한이 공격자에게 넘어갈 수 있는 사고로 봐야 한다.

전체 공격 흐름

단계	공격자의 목적	주요 행위
초기 접근	유효한 관리 자격증명 확보	피싱, 세션 탈취, API 키 및 CI/CD 비밀정보 유출
환경 정찰	현재 권한과 접근 가능한 자원 확인	조직 구조, IAM, 워크로드, 네트워크, 로그 설정 조회
권한 상승	현재보다 높은 권한 획득	역할 위임, 정책 변경, 서비스 계정 가장
지속성 확보	기존 자격증명 차단 이후에도 재접속	신규 키, 앱 자격증명, 신뢰 관계 및 연합 인증 추가
수평이동	다른 ID·워크로드·계정으로 이동	역할 전환, 원격 명령, 배포 설정 변경
네트워크 피벗	장악한 워크로드를 경유지로 사용	다른 VPC·VNet 또는 온프레미스 내부망 접근
목적 수행	정보 탈취 또는 서비스 파괴	데이터 복사, 스냅샷 공유, 암호화, 자원 삭제

실제 사고에서는 각 단계가 명확하게 분리되지 않는다. 공격자는 환경을 정찰하면서 동시에 권한을 상승시키거나, 워크로드를 장악한 뒤 그 안에서 더 높은 권한의 자격증명을 발견해 다시 관리영역으로 돌아올 수 있다.

관리계정 침해 → 권한 상승 → 워크로드로 수평이동 → 워크로드 자격증명 획득 → 관리영역 재진입 → 다른 계정과 환경으로 확산

1. 공격자는 먼저 현재 권한을 확인한다

공격자는 탈취한 계정으로 바로 파괴적인 작업을 수행하기보다 현재 자격증명으로 무엇을 할 수 있는지부터 확인한다.

현재 사용자 또는 역할의 식별 정보
직접 부여되거나 상속된 IAM 권한
다른 역할이나 서비스 계정으로 전환할 수 있는지
접근 가능한 계정·구독·프로젝트
생성하거나 수정할 수 있는 컴퓨팅 자원
접근 가능한 비밀정보 저장소
감사로그 및 보안서비스 설정
다른 클라우드나 온프레미스와의 연결 구조

이때 읽기 권한을 가볍게 보면 안 된다. 클라우드 자원 목록, IAM 정책, 네트워크 구조, 태그와 인스턴스 이름만 확인해도 운영계와 개발계, 중요 데이터베이스, 배포 서버 및 보안시스템을 상당 부분 구분할 수 있다. 상세 조회 권한은 공격자가 다음 수평이동 경로를 설계하는 데 필요한 지도를 제공한다.

보안담당자가 확인할 항목

평소 사용하지 않던 국가나 ASN에서 발생한 관리 API 호출
짧은 시간에 대량으로 발생한 자원 및 IAM 목록 조회
사람 계정에서 발생한 자동화 도구 형태의 연속 API 호출
서비스 계정이 기존 업무와 무관한 자원을 조회한 기록
여러 리전·계정·구독·프로젝트를 순차적으로 탐색한 흔적
콘솔 로그인 직후 CLI 또는 SDK 기반 호출이 이어지는 패턴
사용자가 평소 접근하지 않던 비밀정보와 로그 설정 조회

단순 조회 이벤트는 정상 운영에서도 많이 발생한다. 이벤트 하나만으로 판단하기보다 사용자, 접속 위치, User-Agent, 호출 속도와 기존 활동 이력을 함께 분석해야 한다.

2. IAM을 이용해 권한을 상승시킨다

클라우드에서 가장 위험한 이동 경로는 네트워크보다 IAM에서 만들어지는 경우가 많다. 공격자는 현재 계정이 직접 관리자 권한을 가지고 있지 않더라도 다음과 같은 간접 권한을 찾는다.

다른 역할을 맡을 수 있는 권한
고권한 역할을 워크로드에 연결할 수 있는 권한
IAM 정책이나 역할 할당을 변경할 수 있는 권한
서비스 계정을 가장하거나 토큰을 발급받을 수 있는 권한
애플리케이션 자격증명을 추가할 수 있는 권한
권한 그룹의 구성원을 변경할 수 있는 권한
고권한 CI/CD 또는 자동화 서비스를 실행할 수 있는 권한

구분	AWS	Azure	GCP
사람 ID	IAM Identity Center, IAM 사용자, 연합 사용자	Entra ID 사용자	Google 계정, 연합 사용자
워크로드 ID	IAM Role	Managed Identity, Service Principal	Service Account
권한 전환	STS AssumeRole	Azure RBAC 및 토큰 발급	Service Account Impersonation
상위 통제	Organizations, SCP	Management Group, Azure Policy	Organization Policy
주요 감사로그	CloudTrail	Activity Log, Entra 감사로그	Cloud Audit Logs

AWS에서 주의할 권한

AWS에서는 sts:AssumeRole뿐 아니라 iam:PassRole도 중요하다. iam:PassRole은 사용자에게 해당 역할의 권한을 직접 부여하는 기능이 아니라, 특정 IAM Role을 EC2나 Lambda 같은 AWS 서비스에 전달할 수 있도록 허용하는 권한이다.

하지만 고권한 역할 전달, 워크로드 생성·수정, 코드 실행 권한이 결합되면 공격자는 자신이 직접 사용할 수 없던 역할을 워크로드에 연결한 뒤 그 권한을 이용할 수 있다.

특히 iam:PassRole은 독립된 API 호출이 아니므로 별도의 CloudTrail 이벤트가 만들어지지 않는다. 역할이 전달된 EC2나 Lambda 등의 자원 생성·변경 이벤트에서 어떤 역할이 지정됐는지 확인해야 한다.

어떤 주체가 iam:PassRole을 가지고 있는가
어떤 역할까지 전달할 수 있는가
어느 서비스에 전달할 수 있는가
해당 서비스를 생성하거나 수정할 권한도 있는가
전달된 역할을 이용해 코드를 실행할 수 있는가

Azure에서 주의할 권한

Azure에서는 구독이나 리소스 그룹의 Owner만 위험한 것이 아니다. 역할 할당 변경, 가상머신 확장 기능 배포, Automation Account나 Function App 수정, 애플리케이션 자격증명 추가, Managed Identity가 연결된 자원의 코드 변경 권한도 권한 상승으로 이어질 수 있다.

Azure의 관리영역과 데이터영역은 별도로 동작할 수 있다는 점도 주의해야 한다. 예를 들어 관리 잠금으로 데이터베이스 자원 삭제를 막아도 데이터영역 권한이 있다면 쿼리를 통해 내부 데이터를 변경하거나 삭제할 수 있다. 관리영역 권한과 데이터영역 권한을 따로 점검해야 하는 이유다.

GCP에서 주의할 권한

GCP에서는 서비스 계정 가장 권한을 중요하게 봐야 한다. 사용자나 다른 서비스 계정이 특정 서비스 계정의 토큰을 발급받을 수 있다면 해당 서비스 계정이 가진 권한으로 자원에 접근할 수 있다.

서비스 계정 가장은 정상적인 임시 권한 부여에도 사용되지만 대상 서비스 계정이 과도한 권한을 가지고 있다면 중요한 권한 상승 경로가 된다. GCP 감사로그는 서비스 계정 가장이 사용된 경우 원래 호출 주체와 가장된 서비스 계정 정보를 함께 기록할 수 있다. 반면 유출된 장기 서비스 계정 키를 직접 사용하면 실제 사용자를 구분하기 어렵다.

3. 공격자는 지속성을 확보한다

공격자는 탈취한 비밀번호나 세션이 언제든 차단될 수 있다는 사실을 알고 있다. 그래서 기존 접근 경로와 별도로 재접속할 수 있는 수단을 만든다.

신규 액세스 키 또는 서비스 계정 키 생성
기존 애플리케이션에 인증서나 클라이언트 시크릿 추가
새로운 IAM 사용자, 역할 또는 서비스 주체 생성
역할 신뢰정책에 외부 계정 추가
외부 IdP 또는 OIDC 연합 관계 추가
기존 권한 그룹에 새로운 계정 추가
서버리스 함수나 자동화 작업에 예약 실행 설정
복구용 계정이나 비상계정에 새로운 인증수단 등록
감사로그 전달 대상이나 수집 필터 변경

정상 운영에서도 키 교체와 역할 생성은 자주 발생한다. 변경 자체보다 누가 어떤 경로로 수행했는지, 승인된 변경과 일치하는지, 새 자격증명이 언제 어디에서 처음 사용됐는지를 확인해야 한다.

4. 관리영역에서 워크로드로 수평이동한다

공격자가 가상머신의 SSH 키나 관리자 비밀번호를 모른다고 해서 해당 서버에 접근할 수 없는 것은 아니다. CSP 관리영역에는 운영 편의를 위해 워크로드에서 명령을 실행하거나 설정을 변경하는 기능이 존재한다.

에이전트 기반 원격 명령 실행
가상머신 확장 기능 설치
사용자 데이터 또는 시작 스크립트 변경
인스턴스 템플릿과 이미지 변경
서버리스 함수 코드 또는 환경변수 변경
컨테이너 작업 정의와 배포 이미지 변경
CI/CD 파이프라인 실행 및 배포 설정 수정
디스크 스냅샷 생성 후 다른 시스템에 연결

이러한 방식은 외부에서 워크로드의 SSH나 RDP 포트로 직접 접속하는 것이 아니다. CSP의 관리 API를 통해 명령이나 설정을 전달한다. 따라서 보안그룹이나 방화벽에서 관리 포트를 차단했더라도 관리영역이 침해되면 워크로드까지 영향을 받을 수 있다.

워크로드에서 공격자가 찾는 정보

인스턴스 또는 Pod에 연결된 워크로드 ID
환경변수와 애플리케이션 설정파일
CI/CD 배포 토큰
데이터베이스 접속정보
비밀정보 관리서비스 접근권한
Kubernetes 서비스 계정 토큰
내부 Git 저장소 자격증명
온프레미스 관리자 또는 도메인 자격증명
다른 VPC·VNet으로 연결된 네트워크 경로

워크로드에 연결된 ID가 현재 공격자가 가진 사용자 계정보다 높은 권한을 보유하고 있다면, 워크로드 침해는 다시 관리영역의 권한 상승으로 이어질 수 있다.

5. 다른 계정·구독·프로젝트로 수평이동한다

기업의 클라우드 환경은 보통 단일 계정으로 구성되지 않는다. AWS 계정, Azure 구독, GCP 프로젝트를 업무·조직·환경별로 분리하지만 중앙 관리와 자동화를 위해 상호 신뢰 관계를 설정한다.

중앙 운영계정에서 다른 계정의 관리 역할 사용
조직 공통 배포 역할을 통한 운영계 접근
관리 구독의 자동화 계정으로 다른 구독 변경
조직 또는 폴더 수준의 서비스 계정 사용
공통 CI/CD 파이프라인을 통한 여러 환경 배포
중앙 보안·백업·모니터링 계정을 통한 접근
계정 간 스냅샷·이미지·스토리지 공유 기능 악용

계정을 분리했더라도 동일한 고권한 역할, 서비스 계정 또는 배포 파이프라인을 공유한다면 실제 침해 범위는 분리되지 않은 것과 비슷할 수 있다. 중앙 배포계정, 네트워크 관리계정, 백업계정, 이미지 배포계정과 Landing Zone 관리 역할은 여러 환경에 접근하므로 공격자에게도 매력적인 수평이동 거점이 된다.

6. Kubernetes 환경으로 수평이동한다

관리형 Kubernetes는 CSP IAM과 Kubernetes RBAC이 함께 사용되기 때문에 권한 관계가 복잡하다. 공격자는 CSP 사용자나 역할이 어떤 Kubernetes 권한으로 매핑되는지, Pod 서비스 계정이 어떤 CSP 권한과 연결되는지 확인한다.

서비스 계정에 cluster-admin 부여
동작 범위가 명확하지 않은 와일드카드 권한
네임스페이스 전체 Secret 조회 권한
Pod 생성과 임의 서비스 계정 지정 권한의 결합
고권한 CSP 워크로드 ID가 연결된 Pod 실행 권한
여러 환경이 공동으로 사용하는 CI/CD 서비스 계정
권한이 큰 기본 서비스 계정의 공동 사용

Kubernetes 감사로그만으로는 최초 침해 주체를 찾기 어려울 수 있다. CSP IAM 로그, Kubernetes 감사로그, 컨테이너 런타임 로그와 CI/CD 실행 기록을 함께 연결해야 한다.

7. 장악한 워크로드를 이용해 네트워크 피벗을 수행한다

워크로드까지 장악한 공격자는 해당 시스템을 내부 네트워크 접근을 위한 경유지로 이용할 수 있다. 이 단계부터는 전통적인 의미의 피벗이라고 할 수 있다.

VPC·VNet 피어링
Transit Gateway 또는 Virtual WAN
Site-to-Site VPN
AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect
관리용 배스천 및 프록시
내부 DNS와 조건부 전달자
온프레미스 Active Directory 연동
다른 CSP로 연결된 멀티클라우드 네트워크

클라우드 워크로드가 온프레미스 DNS, Active Directory, 모니터링, 백업 또는 형상관리 시스템과 통신할 수 있다면 공격자는 이러한 연결을 이용해 침해 범위를 확장할 수 있다.

특히 위험한 구조

개발계와 운영계가 라우팅만으로 연결된 환경
클라우드 워크로드에서 온프레미스 관리망 접근이 가능한 환경
넓은 사설 IP 대역을 일괄 허용한 방화벽 정책
관리자 계정을 클라우드와 온프레미스에서 함께 사용하는 환경
백업·모니터링·배포 서버가 모든 구간에 접근하는 환경
네트워크는 분리했지만 DNS와 인증체계는 공동으로 사용하는 환경

네트워크 방화벽만으로 수평이동과 피벗을 모두 차단하기는 어렵다. IAM, 워크로드 ID, 관리 프로토콜, DNS와 배포 경로를 함께 분리해야 한다.

주요 취약점과 설정 오류

취약점 또는 설정 오류	공격자 관점의 영향	방어 방안
과도한 IAM 권한	다른 역할과 자원으로 권한 확대	최소권한, 사용권한 분석, 정기 회수
와일드카드 리소스 지정	예상하지 못한 고권한 자원 접근	대상 리소스와 조건 구체화
과도한 역할 위임	고권한 역할로 전환	신뢰정책과 위임 대상 제한
정적 액세스 키	장기간 은밀하게 재사용	단기 토큰, 워크로드 ID, 키 생성 제한
느슨한 연합 인증 조건	외부 저장소나 테넌트에서 토큰 발급	issuer, subject, audience 제한
관리자 MFA 미적용	비밀번호만으로 관리영역 접근	피싱 저항성 MFA, 조건부 접근
워크로드 ID 과다 권한	서버 침해 후 관리영역 재진입	워크로드별 전용 ID와 최소권한
CI/CD 계정 과다 권한	파이프라인을 통해 운영환경 장악	환경 분리, 승인 단계, 단기 자격증명
감사로그 분산 저장	로그 삭제 또는 수집 범위 축소	별도 보안계정에 중앙 보관
상위 거부정책 부재	개별 계정 관리자 권한으로 통제 우회	SCP, Azure Policy, Organization Policy
과도한 네트워크 연결	워크로드에서 내부망과 온프레미스로 피벗	세분화, 중계구간, 목적지 기반 허용
Kubernetes RBAC 과다 권한	Secret·Pod·노드를 이용한 확산	네임스페이스 분리와 권한 조합 분석

보안담당자가 우선 탐지해야 할 이벤트

ID와 권한 변경

신규 사용자, 역할, 서비스 계정 또는 서비스 주체 생성
관리자나 소유자 권한 부여
역할 신뢰정책 변경
권한 그룹 구성원 추가
서비스 계정 가장 권한 부여
액세스 키, 인증서 및 클라이언트 시크릿 생성
외부 IdP 또는 연합 인증 설정 변경
MFA 제거 및 인증수단 변경

워크로드 제어와 수평이동

관리 API를 통한 원격 명령 실행
가상머신 확장 기능 추가
시작 스크립트와 사용자 데이터 변경
서버리스 함수 코드·환경변수 변경
컨테이너 이미지 또는 작업 정의 변경
고권한 역할이 연결된 신규 워크로드 생성
평소 사용하지 않던 역할 전환
동일 주체의 여러 계정·구독·프로젝트 접근
고권한 서비스 계정 토큰 발급

데이터 접근과 방어 회피

평소와 다른 주체의 비밀정보 대량 조회
스토리지 정책의 외부 공개 전환
데이터베이스 또는 디스크 스냅샷 생성과 외부 공유
대량 객체 다운로드 또는 다른 리전으로 데이터 복제
감사로그 비활성화 또는 수집 대상 축소
보안서비스 중지와 탐지 규칙 변경
암호화 키 비활성화 또는 삭제 예약
백업 정책과 보존기간 변경
조직 정책이나 관리 잠금 해제

관리영역 침해사고의 대응 순서

1. 침해 ID를 격리한다

의심 계정의 접근 차단
활성 세션과 토큰 취소
액세스 키와 애플리케이션 자격증명 폐기
역할 신뢰정책과 연합 인증 변경 여부 확인
공격자가 생성한 신규 ID와 인증수단 조사

비밀번호만 변경해서는 이미 발급된 토큰, 액세스 키 또는 별도로 등록된 인증서가 남을 수 있다.

2. 권한 상승 경로를 차단한다

신규 역할 할당과 IAM 정책 변경 제한
조직 단위의 명시적 거부정책 적용
고권한 역할 위임 중단
자동화 및 CI/CD 서비스의 배포 권한 제한
비상계정과 로깅 계정의 보호 상태 확인

IAM을 급하게 변경하면 정상적인 복구 작업까지 차단할 수 있다. 비상 접근계정과 사고대응 담당자의 접근 경로를 먼저 확보해야 한다.

3. 수평이동 범위를 확인한다

다른 역할과 서비스 계정 사용 기록
계정·구독·프로젝트 간 접근 기록
신규 워크로드와 배포 이력
관리형 원격 명령 사용 기록
비밀정보 저장소 접근 이력
Kubernetes 감사로그
CI/CD 및 Git 저장소 변경 이력

4. 의심 워크로드를 격리한다

의심 워크로드의 외부 및 내부 통신 제한
연결된 워크로드 ID의 권한 축소
관리형 원격 실행과 배포 기능 사용 이력 확인
메모리, 디스크, 컨테이너 및 감사로그 보존
동일한 이미지나 배포 템플릿을 사용하는 자원 조사

인스턴스를 즉시 삭제하면 공격자가 남긴 흔적도 함께 사라질 수 있다. 증거를 보존한 후 격리하고 신뢰할 수 있는 이미지로 재구축하는 것이 안전하다.

5. 네트워크 피벗 여부를 조사한다

VPC·VNet 피어링 구간의 트래픽
VPN과 전용회선 통신 기록
내부 DNS 조회 기록
온프레미스 인증 및 관리자 계정 사용 기록
배스천과 프록시 접속 이력
내부 관리 포트 접근 기록
다른 CSP로 전달된 트래픽

6. 상위 자격증명부터 교체한다

공격자가 만든 자격증명 제거
고권한 관리계정과 연합 인증 자격증명 교체
CI/CD 및 자동화 계정 교체
워크로드 ID와 애플리케이션 비밀정보 교체
데이터베이스와 외부 서비스 자격증명 교체
장기 키 사용 여부 재점검

하위 자격증명부터 교체하면 상위 관리권한을 가진 공격자가 다시 발급할 수 있다. 반드시 상위 제어권부터 회수해야 한다.

수평이동을 줄이는 설계 원칙

사람과 워크로드의 ID를 분리한다

사람이 사용하는 계정과 애플리케이션이 사용하는 계정을 공유해서는 안 된다. 하나의 서비스 계정을 여러 워크로드가 공동으로 사용하면 한 워크로드의 침해가 다른 서비스로 확산될 수 있다. 워크로드별 전용 ID를 사용하고 접근 대상도 필요한 자원으로 제한해야 한다.

장기 자격증명을 줄인다

인스턴스 및 Pod용 워크로드 ID
단기 역할 세션
CI/CD용 OIDC 연합
승인 기반 임시 관리자 권한
피싱 저항성 MFA

연합 인증도 조건을 느슨하게 설정하면 수평이동 경로가 될 수 있다. 저장소 이름, 브랜치, 조직, 테넌트, audience와 subject 조건을 구체적으로 제한해야 한다.

권한을 개별 항목이 아닌 조합으로 분석한다

클라우드 권한은 개별적으로 보면 위험하지 않아 보여도 여러 권한이 결합되면 권한 상승이 가능해진다.

고권한 역할 전달 + 워크로드 생성 + 코드 실행
서비스 계정 토큰 발급 + 대상 서비스 계정의 관리자 권한
역할 할당 생성 + 상위 리소스 범위 접근
Secret 조회 + 배포 파이프라인 실행
Pod 생성 + 고권한 서비스 계정 지정
스냅샷 생성 + 외부 계정 공유

IAM 점검에서는 Administrator 권한 보유자만 찾는 것으로 끝내면 안 된다. 현재의 권한 조합을 이용해 고권한 ID나 중요한 데이터에 도달할 수 있는 경로를 분석해야 한다.

환경 분리를 신뢰 관계까지 확장한다

계정이나 네트워크만 분리하고 공통 관리계정과 배포계정을 사용하면 실질적인 침해 범위는 줄어들지 않는다. 운영계와 개발계의 관리 역할, CI/CD 파이프라인, 워크로드 ID, 비밀정보 저장소, 백업·모니터링 계정과 온프레미스 관리망 연결까지 함께 분리해야 한다.

감사로그를 별도 계정에 보관한다

조직 전체 로그 중앙 수집
운영계정과 분리된 보안계정에 저장
삭제 및 보존기간 변경 권한 제한
중요 설정 변경 실시간 알림
CSP 로그와 IdP·EDR·DNS·방화벽 로그 연계
로깅 중지와 전달 대상 변경에 대한 별도 탐지

실무 점검 체크리스트

관리자 권한을 가진 사람과 서비스 계정을 모두 파악하고 있는가?
역할 전환과 서비스 계정 가장 경로를 확인할 수 있는가?
고권한 역할을 워크로드에 연결할 수 있는 사용자를 알고 있는가?
장기 액세스 키와 서비스 계정 키의 사용처를 알고 있는가?
CI/CD가 운영환경에 어느 수준까지 접근할 수 있는가?
워크로드가 비밀정보 관리서비스에서 무엇을 읽을 수 있는가?
개발계에서 운영계로 이동할 수 있는 신뢰 관계가 존재하는가?
관리 API를 통한 원격 명령 실행을 탐지하고 있는가?
신규 자격증명의 최초 사용 위치를 추적할 수 있는가?
계정·구독·프로젝트 간 역할 전환을 모니터링하고 있는가?
클라우드에서 온프레미스 관리망으로 접근할 수 있는가?
감사로그 중지와 보안서비스 비활성화를 실시간 탐지하는가?
조직 단위의 명시적 거부정책이 적용돼 있는가?
사고 시 사용할 비상 접근계정과 격리 절차가 준비돼 있는가?

마치며

클라우드의 수평이동은 반드시 서버에서 서버로 이동하는 형태로 나타나지 않는다. 공격자는 IAM 역할, 서비스 계정, 자동화 도구, CI/CD와 관리 API를 이용해 다른 ID와 워크로드로 침해 범위를 확장한다. 이 과정에서는 방화벽 로그보다 IAM 변경 이력과 관리 API 감사로그가 더 중요한 증거가 될 수 있다.

워크로드까지 장악한 이후에는 해당 시스템을 경유지로 사용해 내부망이나 온프레미스에 접근하는 네트워크 피벗이 이어질 수 있다.

관리영역 보안에서 중요한 것은 관리자 계정의 수만 확인하는 것이 아니다. 현재의 사용자와 서비스 계정이 어떤 권한 조합을 통해 더 높은 권한에 도달할 수 있는지, 그리고 그 권한으로 어떤 워크로드와 네트워크를 제어할 수 있는지를 확인해야 한다.

ID 사이의 권한과 신뢰 관계
ID와 워크로드 사이의 제어 관계
워크로드와 다른 네트워크 사이의 연결 관계

이 세 가지를 하나의 공격 경로로 분석해야 권한 상승과 수평이동, 그리고 이후의 네트워크 피벗까지 실질적으로 통제할 수 있다.