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

클라우드 침해사고를 살펴볼 때 가상머신 한 대가 장악되었다는 사실만으로 영향 범위를 판단하기는 어렵다. 특히 공격자가 CSP의 관리영역(Control Plane)에 접근할 수 있는 사용자나 서비스 계정의 권한까지 확보했다면, 그 계정으로 어디까지 제어할 수 있는지를 함께 봐야 한다.

침해된 클라우드 ID가 IAM 권한을 확대하고 VM·컨테이너 워크로드에 접근한 뒤 워크로드 토큰이나 비밀정보를 통해 조건부로 관리영역에 재진입할 수 있는 흐름도

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

관리영역은 가상머신과 스토리지, 네트워크, IAM, 데이터베이스 같은 클라우드 자원을 생성하고 변경하는 영역이다. 공격자가 이곳에 접근하면 확보한 권한에 따라 다른 계정이나 워크로드로 이동할 수 있다. 연결 구조에 따라 내부망이나 온프레미스까지 영향이 이어질 가능성도 있다.

이런 이동을 통틀어 ‘피벗’이라고 부르기도 하지만, 실제로는 권한을 얻는 과정과 다른 자원으로 이동하는 과정, 네트워크를 경유하는 과정이 섞여 있다. 이 글에서는 다음과 같이 구분한다.

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

관리영역 침해 이후 어떤 권한을 확보하고 다른 자원으로 이동할 수 있는지, 운영 환경에서는 무엇을 확인해야 하는지 정리해 보았다. 장악한 워크로드를 경유해 내부망으로 접근하는 단계에는 피벗이라는 용어를 사용한다.

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

온프레미스 침해사고에서는 서버 한 대에 접근한 뒤 내부 네트워크를 탐색하고, 취약한 시스템으로 이동하는 흐름을 흔히 생각한다.

클라우드에서는 서버에 직접 접속하지 않고도 영향을 줄 경로가 있다. 관리영역의 자격증명을 확보한 공격자는 허용된 권한 안에서 정상적인 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을 통한 이동이다. 현재 계정에 관리자 권한이 직접 부여되어 있지 않더라도, 다른 ID의 권한을 사용하거나 고권한 서비스를 제어할 수 있다면 상황이 달라진다.

다른 역할을 맡을 수 있는 권한
고권한 역할을 워크로드에 연결할 수 있는 권한
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도 살펴볼 필요가 있다. PassRole은 사용자에게 그 역할의 권한을 바로 주는 기능이 아니다. 특정 IAM Role을 EC2나 Lambda 같은 AWS 서비스에 전달할 수 있도록 허용하는 권한이다.

그런데 고권한 역할을 전달할 수 있고, 워크로드를 생성하거나 수정한 뒤 코드를 실행할 수도 있다면 여러 권한이 연결된다. 공격자는 직접 사용하지 못하던 역할을 워크로드에 붙이고, 그 워크로드를 통해 해당 권한을 이용할 수 있다.

로그를 볼 때도 주의할 부분이 있다. iam:PassRole은 독립적인 API 호출이 아니므로 그 자체의 CloudTrail 이벤트가 따로 생성되지 않는다. EC2나 Lambda 등의 자원 생성·변경 이벤트에서 어떤 역할이 지정되었는지 확인해야 한다.

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

Azure에서 주의할 권한

Azure도 구독이나 리소스 그룹의 Owner만 확인해서 끝낼 수는 없다. 역할 할당 변경, 가상머신 확장 배포, Automation Account나 Function App 수정, 애플리케이션 자격증명 추가 권한을 함께 살펴봐야 한다. Managed Identity가 연결된 자원의 코드를 바꿀 수 있는지도 중요한 부분이다.

관리영역과 데이터영역의 권한도 구분해서 봐야 한다. 관리 잠금으로 데이터베이스 자원 삭제를 막았더라도, 데이터영역 권한이 있다면 쿼리로 내부 데이터를 변경하거나 삭제할 수 있다. 자원 자체를 보호하는 것과 그 안의 데이터를 보호하는 것은 같은 통제가 아니다.

GCP에서 주의할 권한

GCP에서는 서비스 계정 가장(Impersonation) 권한을 살펴볼 필요가 있다. 사용자나 다른 서비스 계정이 특정 서비스 계정의 토큰을 발급받을 수 있다면, 그 서비스 계정의 권한으로 자원에 접근할 수 있다.

서비스 계정 가장은 정상적인 임시 권한 부여에도 사용하는 기능이다. 다만 대상 계정에 과도한 권한이 있다면 권한 상승 경로가 될 수 있다.

감사로그에서는 가장을 요청한 원래 주체와 대상 서비스 계정 정보를 함께 확인할 수 있는 경우가 있다. 반대로 유출된 장기 서비스 계정 키를 직접 사용했다면 실제로 누가 사용했는지 구분하기 어려워진다.

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

탈취한 비밀번호나 세션이 차단되면 기존 접근은 끊길 수 있다. 공격자는 이에 대비해 별도의 자격증명이나 신뢰 관계를 만들어 다시 들어올 수 있는 경로를 남기려 할 수 있다.

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

키 교체와 역할 생성 자체는 정상적인 운영 작업이기도 하다. 따라서 누가 어떤 경로로 변경했는지, 승인된 작업과 일치하는지 확인하는 것이 중요하다. 새로 만든 자격증명이 언제 어디에서 처음 사용되었는지도 함께 살펴보면 좋겠다.

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

SSH 키나 관리자 비밀번호를 모른다고 서버에 영향을 줄 수 없는 것은 아니다. CSP에는 운영 편의를 위해 워크로드에서 명령을 실행하거나 설정을 바꾸는 관리 기능이 있다.

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

이런 방식은 외부에서 SSH나 RDP 포트로 직접 접속하는 것과 다르다. 관리 API를 통해 명령이나 설정을 전달하므로, 해당 기능의 실행 조건과 권한이 충족된다면 관리 포트를 차단한 워크로드에도 영향을 줄 수 있다.

방화벽에서 접속을 막았다는 것과 관리영역을 통한 제어까지 막았다는 것은 구분해야 한다.

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

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

워크로드에 연결된 ID가 처음 탈취한 사용자 계정보다 높은 권한을 가지고 있다면, 서버 침해가 다시 관리영역의 권한 상승으로 이어질 수 있다. 워크로드의 취약점과 IAM 권한을 따로만 점검하기 어려운 이유다.

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

기업에서는 AWS 계정, Azure 구독, GCP 프로젝트를 업무와 조직, 운영·개발 환경에 따라 나누어 사용하는 경우가 많다. 동시에 중앙 관리와 자동화를 위해 환경 사이에 신뢰 관계를 설정하기도 한다.

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

계정이 나뉘어 있어도 같은 고권한 역할이나 서비스 계정, 배포 파이프라인을 공유한다면 침해 영향은 경계를 넘어갈 수 있다. 중앙 배포계정, 네트워크 관리계정, 백업계정, 이미지 배포계정과 Landing Zone 관리 역할처럼 여러 환경에 접근하는 주체를 함께 살펴봐야 한다.

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

관리형 Kubernetes에서는 CSP IAM과 Kubernetes RBAC의 관계까지 확인해야 한다. CSP 사용자나 역할이 클러스터 안에서 어떤 권한을 갖는지, 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와 워크로드 사이의 제어 관계
워크로드와 다른 네트워크 사이의 연결 관계

이 세 관계를 따로 점검하는 데서 끝내지 않고 하나의 경로로 이어서 볼 필요가 있다. 그래야 계정 하나나 워크로드 하나가 침해되었을 때 어디까지 영향을 줄 수 있는지, 어느 지점에서 차단해야 할지 더 구체적으로 판단할 수 있을 것이다.