AWS 교차 계정 신뢰 공격: 역할 체이닝은 어떻게 핵심 자산에 도달하는가

Pathbreak 팀 작성 · 2026년 8월 11일 · 6분 읽기

멀티 계정 AWS는 대규모 환경을 운영하는 권장 방식이며, 교차 계정 IAM 역할이 이를 하나로 묶어 줍니다. 보안 계정은 모든 워크로드 계정에서 로그를 읽습니다. 공유 서비스 계정은 다른 계정에 배포합니다. 벤더는 자사 제품을 실행하기 위해 역할을 가로챕니다. 이 모든 것이 설계된 대로 동작하는 교차 계정 신뢰입니다.

이것은 동시에 공격자가 따라가는 지도이기도 합니다. 한 계정에 발을 디디고, 다음 계정에서 가로챌 수 있는 역할을 찾고, 이를 반복합니다. 이 글에서는 교차 계정 신뢰가 어떻게 악용되는지, 역할 체이닝이 어떻게 핵심 자산에 도달하는지, 그리고 단 하나의 변경으로 그 경로를 어떻게 차단하는지를 다룹니다.

교차 계정 신뢰는 어떻게 작동하는가

모든 IAM 역할에는 두 가지 정책이 있습니다. 권한 정책은 그 역할이 무엇을 할 수 있는지 규정합니다. 신뢰 정책, 즉 assume-role 정책은 누가 그 역할이 될 수 있는지 규정합니다. 역할로 이동하려면 주체가 sts:AssumeRole을 호출하여 임시 자격 증명을 얻는데, 이는 대상 역할의 신뢰 정책이 그 주체를 허용하고 호출자에게 sts:AssumeRole 권한이 있는 경우에 한합니다.

신뢰 정책이 누가 들어올 수 있는지를 통제하므로, 교차 계정 보안은 여러분이 허용하는 주체를 얼마나 정확하게 명시하느냐에 달려 있습니다.

신뢰는 어디에서 잘못되는가

신뢰 정책의 와일드카드 주체

가장 위험하면서도 가장 오해받는 신뢰 정책은 와일드카드 주체입니다. "Action": "sts:AssumeRole"과 함께 "Principal": { "AWS": "*" }을 허용하는 구문은 여러분 계정 내 아무 아이덴티티를 뜻하지 않습니다. 그 역할을 전 세계 모든 AWS 계정에 열어 둡니다. 두 번째 요건이 있어서, 호출하는 아이덴티티에도 그 역할에 대한 sts:AssumeRole 권한이 있어야 하지만, 바로 그 점 때문에 와일드카드가 실질적인 위험이 됩니다. 공격자는 자신의 AWS 계정에서 스스로에게 그 권한을 부여하므로, 두 번째 요건을 공짜로 충족합니다. 팀은 와일드카드를 "우리 팀 모두"로 읽고 배포합니다. 그렇게 공개한 것은 공격자가 자신이 제어하는 계정에서 가로챌 수 있는 역할입니다. 의미 있는 권한을 가진 역할이라면, 그것은 그 역할이 할 수 있는 모든 것을 내주는 셈입니다. 넓은 주체가 꼭 필요하다면 aws:PrincipalAccount나 aws:PrincipalOrgID 같은 Condition으로 제약하고, 더 나아가 신뢰하려는 정확한 역할 ARN을 명시하세요.

서드파티 역할의 혼동된 대리자 문제

SaaS 벤더가 여러분 계정의 역할을 가로채도록 허용하면, 그 벤더는 하나의 AWS 계정으로 여러 고객에게 서비스를 제공합니다. 여러분의 신뢰 정책이 벤더의 계정만 명시한다면, 그 벤더의 또 다른 고객이 벤더를 꾀어 여러분의 역할을 가로채게 할 수 있습니다. 해결책은 external ID, 즉 조건에 담는 공유 비밀값이거나, 역할 가로채기를 여러분만의 특정 관계에 묶어 두는 aws:SourceArn 또는 aws:SourceAccount 조건입니다. 그것이 없는 서드파티 역할은 전형적인 혼동된 대리자 노출입니다.

계정 전반의 역할 체이닝

한 번의 홉으로 목표에 도달하는 경우는 드물기 때문에, 실제 경로는 체인을 이룹니다. 공격자는 개발 계정의 역할을 가로채고, 그 역할은 마침 공유 서비스 계정의 역할이 신뢰하며, 그 역할은 프로덕션의 역할을 가로챌 수 있고, 그 역할은 Secrets Manager에 있는 데이터베이스 자격 증명을 읽을 수 있습니다. 네 번의 정당한 sts:AssumeRole 호출만으로, 가장 덜 중요한 계정의 발판이 가장 중요한 데이터에 대한 접근으로 바뀐 것입니다.

체이닝을 위험하게 만드는 것은 각 홉이 허가되어 있고, 아무것도 익스플로잇되지 않으며, 자격 증명이 임시적이고 예상된 것이라는 점입니다. CloudTrail에는 역할들이 제 일을 하는 것처럼 보입니다. 그 위험을 알아보는 유일한 방법은 각 신뢰 관계를 따로 판단하는 대신, 체인 전체를 한 번에 살펴보고 그것이 어디서 끝나는지 묻는 것입니다.

AWS가 마찰을 더하기는 합니다. 체이닝된 역할 세션은 최대 한 시간으로 제한되며 추가 체이닝으로 갱신할 수 없습니다. 이는 세션 수명을 제한하지만, 경로를 닫지는 못합니다.

계정 경계가 실제보다 더 안전하게 느껴지는 이유

팀은 계정 경계를 보안 경계로 취급하며, 폭발 반경 측면에서는 좋은 경계입니다. 문제는 교차 계정 역할이 그 경계를 의도적으로 관통하도록 뚫려 있고, 각 역할은 해당 계정의 소유자가 고립된 채로 검토하므로 아무도 체인 전체를 검토하지 않는다는 점입니다. 개발 팀의 편리한 신뢰 관계와 플랫폼 팀의 공유 역할은 각각은 합당하지만, 둘이 합쳐지면 어느 팀도 자기 자리에서는 볼 수 없는 경로를 이룹니다. 고립된 검토가 교차 계정 경로를 놓치는 이유는 IAM 권한 상승을 놓치는 이유와 같습니다. 위험은 역할들이 어떻게 연결되는가에 있으며, 역할을 하나씩 검토하는 방식으로는 결코 그것이 드러나지 않습니다.

이를 매핑하는 도구들

그래프 기반 도구가 도움이 됩니다. PMapper와 Cartography는 계정 전반의 역할과 신뢰 관계를 모델링할 수 있고, AWS IAM Access Analyzer는 여러분이 잊었을 수 있는 교차 계정 신뢰를 포함해 역할에 대한 외부 접근을 보고합니다. 이들은 후보 에지를 제공합니다. 남는 질문은 그 후보 체인 가운데 어느 것이, 적용 중인 모든 홉과 모든 조건, 모든 권한 정책을 거쳐, 여러분이 신경 쓰는 대상까지 성립하는가입니다. 민감하지 않은 곳으로 이어지는 신뢰 에지는 소음이고, 여러분의 프로덕션 데이터로 이어지는 네 홉짜리 체인이 바로 고쳐야 할 대상입니다.

체인을 끊는 방법

어떤 경로든 마찬가지로, 에지 하나만 끊으면 충분합니다. 신뢰 정책의 루트 계정 주체를 정확한 역할 ARN으로 교체하세요. 모든 서드파티 역할에 external ID 또는 aws:SourceArn 조건을 요구하세요. 더 이상 목적에 쓰이지 않는 교차 계정 신뢰를 삭제하세요. 휴면 상태의 벤더 역할은 흔히 발견됩니다. 가능한 경우 서비스 제어 정책을 사용해 특정 부류의 계정 전체가 민감한 역할을 가로채지 못하도록 막으세요. 그런 다음 예상치 못한 출처에서 중요한 역할로 들어오는 AssumeRole 호출에 대해 경보를 설정하세요.

판단이 필요한 지점은 어느 에지를 끊을 것인가입니다. 올바른 에지는 정당한 것을 전혀 건드리지 않으면서 공격자의 경로를 끊어 내고, 잘못된 에지는 파이프라인을 망가뜨립니다. 그러려면 각 체인이 어디로 이어지는지 알아야 합니다.

Pathbreak의 접근 방식

Pathbreak는 여러분의 AWS 계정 전반에 걸친 완전한 신뢰 그래프를 구축하고, 공격자가 그러하듯 그것을 하나로 연결된 공간으로 다룹니다. 각 AssumeRole 홉을 실제 신뢰 정책과 권한 정책, 조건에 비추어 해석한 다음, 어떤 체인이 프로덕션 데이터나 백업, 조직 관리 같은 핵심 자산에 도달하는지 확인합니다. 읽기 전용으로 동작하므로, 신뢰를 매핑하는 과정이 그것을 건드리는 일은 결코 없습니다.

성립하는 모든 체인에 대해 Pathbreak는 홉들을 보여 주고 이를 차단하는 단 하나의 신뢰 에지를 짚어 줍니다. 대개 지나치게 넓은 신뢰 정책 하나이거나 잊힌 벤더 역할 하나입니다. 우리가 다루는 체인은 공격 경로 페이지에서, 작동 원리는 작동 방식에서, 최소 권한 접근을 다루는 방식은 신뢰 및 보안 페이지에서 확인할 수 있습니다. 같은 추론이 한 계정 안에서 어떻게 적용되는지는 AWS IAM 권한 상승에 관한 글을 참고하세요.

자주 묻는 질문