AWS IAM 권한 상승: 공격 경로는 어떻게 형성되고 어떻게 차단하는가

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

거의 모든 심각한 AWS 사고는 같은 방식으로 전개됩니다. 공격자는 낮은 권한의 아이덴티티, 즉 유출된 액세스 키, 탈취된 CI 역할, 애플리케이션 자격 증명에 발을 디디고, 몇 단계 만에 관리자가 됩니다. 이런 사례 대부분에 제로데이는 없습니다. 공격자는 계정이 의도적으로 내준 권한을, 아무도 의도하지 않은 조합으로 사용합니다.

그 조합이 바로 IAM 권한 상승 경로입니다. 이 글에서는 AWS에서 그런 경로가 어떻게 형성되는지, 이를 만들어 내는 권한 조합은 무엇인지, 왜 일반적인 검토에서는 숨어 있는지, 그리고 어떻게 찾아 차단하는지를 살펴봅니다.

IAM 권한 상승이란 무엇인가

IAM 권한 상승은 아이덴티티가 이미 가진 접근 권한을 사용해 스스로에게 더 많은 접근 권한을 부여하거나, 애초에 가져서는 안 될 접근 권한에 도달하는 것입니다. AWS에서는 워크로드를 뚫는 방식이 아니라, 거의 언제나 아이덴티티와 권한을 관리하는 API 영역인 컨트롤 플레인에서 일어납니다.

AWS는 여러분이 지시한 그대로 동작합니다. 아이덴티티가 정책을 수정하거나 역할을 전달하거나 키를 생성할 수 있다면, AWS는 그것을 허용합니다. 권한 상승은 대개 의도적으로 부여된 권한에서 비롯되며, 아무도 추적하지 않은 이차적 효과를 동반합니다.

권한 상승 경로는 어떻게 형성되는가

대부분의 AWS 권한 상승 경로는 몇 가지 유형으로 나뉩니다. 그중 어느 것도 관리자 권한을 요구하지 않습니다. 각 유형은 좁은 쓰기 권한 하나를 폭넓은 권력으로 바꿔 놓습니다.

자신이 제어하는 서비스에 역할 전달하기

가장 흔한 것은 컴퓨팅 서비스와 결합된 iam:PassRole입니다. 아이덴티티가 권한이 높은 역할을 EC2 인스턴스, Lambda 함수, ECS 작업, Glue 작업에 전달할 수 있고 그 서비스를 실행할 수도 있다면, 그 권한이 높은 역할로 코드를 실행하여 역할의 권한을 물려받을 수 있습니다. 아이덴티티가 자신에게 없던 권한을 가진 역할을 빌려 온 것입니다. 바로 이 때문에 iam:PassRole은 가장 면밀히 주시해야 할 권한이며, 어떤 역할을 어떤 서비스에 전달할 수 있는지로 항상 제약해야 합니다.

수정이 허용된 정책 다시 쓰기

아이덴티티에 iam:CreatePolicyVersion이 있으면, 원하는 권한을 담은 고객 관리형 정책의 새 버전을 게시하고 그 버전을 기본값으로 설정할 수 있습니다. 버킷 하나에 읽기 접근을 부여하던 정책이 모든 것을 부여하는 정책으로 바뀝니다. 인라인 정책의 경우 iam:PutUserPolicy, iam:PutRolePolicy, iam:PutGroupPolicy에도 같은 원리가 적용됩니다. 이 권한은 일상적인 정책 관리처럼 보이지만, 해당 정책이 부여하는 것은 무엇이든 다시 쓸 수 있습니다.

더 강력한 정책 연결하기

iam:AttachUserPolicy, iam:AttachRolePolicy, iam:AttachGroupPolicy 같은 권한을 사용하면 아이덴티티가 기존 관리형 정책을 자신 또는 자신이 제어하는 주체에 연결할 수 있습니다. AdministratorAccess를 연결하면 단 한 번의 호출로 상승이 끝납니다. 이는 권한의 범위가 지나치게 넓게 설정되어 있기 때문에 가능합니다.

더 강력한 아이덴티티를 위한 새 자격 증명 생성하기

여러 권한이 이미 더 높은 권한을 가진 주체에 새 자격 증명을 생성하도록 허용합니다. 다른 사용자에 대한 iam:CreateAccessKey는 그 사용자에게 새 키를 발급합니다. iam:CreateLoginProfile은 콘솔 비밀번호가 없는 사용자에게 비밀번호를 설정합니다. iam:UpdateLoginProfile은 비밀번호를 재설정합니다. 각 경우에 공격자는 이미 가진 아이덴티티에 권한을 더하는 대신, 인증에 사용할 더 강력한 아이덴티티를 손에 넣습니다.

신뢰 정책 느슨하게 만들기

역할의 신뢰 정책은 누가 그 역할을 가로챌 수 있는지 결정합니다. 아이덴티티가 권한이 높은 역할에 대해 iam:UpdateAssumeRolePolicy를 가지고 있으면, 그 신뢰 정책을 자신을 허용하도록 다시 쓴 다음 sts:AssumeRole을 호출하여 그 역할이 될 수 있습니다. 이와 관련된 위험은 이미 지나치게 넓게 신뢰하는 역할, 즉 와일드카드 주체나 계정 전체를 신뢰하는 역할입니다. 이 경우 역할을 가로채는 데 아무것도 수정할 필요조차 없습니다.

고립된 권한은 왜 경로를 숨기는가

정책 검토에서 이 권한 중 하나를 따로 보면 합당해 보입니다. 배포 아이덴티티에는 iam:PassRole이 필요합니다. 플랫폼 팀은 정책을 관리해야 합니다. 자동화 사용자는 키를 교체해야 합니다. 각 부여에는 그럴듯한 사연이 있습니다.

권한 상승은 그 부여를 그것이 도달할 수 있는 대상과 연결했을 때 비로소 드러납니다. iam:PassRole은 어떤 역할을 전달할 수 있는지, 그리고 그 아이덴티티가 역할을 실행할 서비스까지 시작할 수 있는지 묻기 전까지는 무해합니다. 관리형 정책 수정은 그 정책이 관리자 역할에 연결되어 있다는 것을 알아차리기 전까지는 괜찮습니다. 경로는 그래프 전체를 볼 때만 드러나며, 정책을 하나씩 검토하는 방식으로는 결코 드러나지 않습니다. 그래서 검토가 수백 개의 발견 항목을 내놓고도 관리자에 도달하는 체인은 놓칠 수 있는 것입니다.

이를 매핑하는 도구들

이것을 손으로 일일이 추론할 필요는 없습니다. AWS IAM Access Analyzer는 외부 접근과 미사용 접근을 보고하고 정책을 검증할 수 있습니다. 오픈 소스 도구들은 관계를 모델링합니다. PMapper는 누가 누구에게 도달할 수 있는지 그래프로 구축하고, Cloudsplaining은 권한 상승에 취약한 권한을 가진 정책을 표시하며, Pacu 같은 공격용 프레임워크는 알려진 권한 상승 기법을 열거합니다. 이들은 유용하며, 효과가 있을 법한 수단인 후보를 매핑합니다.

대부분의 도구는 입증 직전에서 멈춥니다. 아이덴티티에 iam:PassRole이 있다는 사실을 아는 것은, 현재 적용 중인 모든 정책과 경계, 서비스 제어 정책을 고려할 때 그 아이덴티티가 오늘 관리자에 도달할 수 있는지를 아는 것과는 다릅니다. 그것을 확인하는 일이 후보를 검증된 경로로 바꿔 놓습니다.

방어자는 이런 경로를 어떻게 차단하는가

체인에 관한 좋은 소식은 에지 하나만 끊으면 된다는 점입니다. 몇 가지 견고한 조치로 대부분의 권한 상승 경로를 막을 수 있습니다.

아이덴티티가 특정 역할만 전달할 수 있도록 iam:PassRole을 제약하고, Lambda용 역할이 EC2에 전달되지 못하도록 iam:PassedToService 조건을 추가하세요. iam: 쓰기 작업, 특히 정책 수정과 연결, 자격 증명 생성을 높은 권한으로 취급하고 좁게 부여하세요. IAM 쓰기 권한을 반드시 가져야 하는 아이덴티티에는 권한 경계를 두어 상한선을 넘지 못하게 하세요. 서비스 제어 정책을 사용해 조직 전반에서 유효 권한에 상한을 두면, 잘못 구성된 계정조차 관리자에 도달할 수 없습니다. 역할 신뢰 정책을 조여 정확한 주체를 명시하고, 계정만 적거나 와일드카드를 쓰는 일은 절대 하지 마세요. 그런 다음 CloudTrail에서 결정적 신호가 되는 호출을 모니터링하세요. 평소 그런 호출을 하지 않는 아이덴티티에서 발생한 CreatePolicyVersion, AttachRolePolicy, UpdateAssumeRolePolicy, CreateAccessKey가 그것입니다.

어려운 부분은 모든 통제가 상호작용한 뒤에 어떤 경로가 남는지 아는 것, 그리고 정책이 날마다 바뀌는 와중에 그 답을 최신으로 유지하는 것입니다.

Pathbreak의 접근 방식

Pathbreak는 IAM을 공격자처럼, 즉 정책의 목록이 아니라 도달 가능성의 그래프로 다룹니다. 실제 아이덴티티와 역할, 정책, 경계, 신뢰 관계를 추론한 다음 권한을 해석하여 어떤 아이덴티티가 관리자로 상승하거나 민감한 데이터에 도달할 수 있는지 확인합니다. 이 과정을 읽기 전용으로 수행합니다. 여러분의 계정에 대해 실행되는 것도 없고 변경되는 것도 없습니다.

경로가 성립하면 Pathbreak는 전체 체인을 보여 주고 이를 차단하는 단 하나의 변경 사항을 제시합니다. 제거할 PassRole 부여, 조여야 할 정책, 닫아야 할 신뢰 관계가 그것입니다. 여러분은 순위도 매겨지지 않은 수천 개의 발견 항목을 분류하는 대신 그 에지만 수정하면 됩니다. 작동 원리는 작동 방식 페이지에서, 우리가 다루는 체인은 공격 경로 페이지에서, 접근을 다루는 방식은 신뢰 및 보안 페이지에서 확인할 수 있습니다.

자주 묻는 질문