IAM의 이중성: 중복 권한이 만드는 보안 착시

본 포스팅은 fwd:cloudsec(2025.7) " The Duplicitous Nature of AWS Identity and Access Management (IAM)" 주제로 발표된 내용에 대한 포스팅입니다. 발표 영상은 https://youtu.be/gQw586n5W9s?si=2JCi_0GdiKI405o8를 통해서 확인하실 수 있습니다.

---

AWS IAM 중복 권한 - 우리가 반드시 이해해야 할 보안의 숨겨진 리스크

AWS 환경에서 보안의 중심에는 항상 IAM이 존재합니다. IAM은 단일 서비스가 아니라, 클라우드 운영 전반의 권한 부여와 접근 제어를 담당합니다.

2020년 약 7,000개 수준이던 IAM 권한은 2024년 기준 18,000개를 넘어 폭발적으로 증가했고, 권한 설계·관리·감사의 복잡성 역시 기하급수적으로 증가하였습니다. 이런 환경에서 보안팀이 반드시 이해해야 할 중요한 개념이 바로 "중복 권한"입니다.

---

1. IAM이란?

IAM은 Identity and Access Management의 약자로, AWS 리소스에 대한 접근을 정의하고, 제어하며, 관리하는 AWS의 핵심 보안 서비스입니다. 또한, 클라우드 환경에서 "누가 어떤 조건에서 무엇을 할 수 있는가"를 결정하는 권한 관리 시스템의 중심입니다.

• 누가(Identity) - 사용자(User), 역할(Role), 서비스 계정 등 리소스를 요청하는 주체를 식별합니다.
• 어떤 조건에서(Conditions) - 특정 IP 주소, 특정 시간대, 리소스 태그 등 권한 적용에 필요한 제약 조건을 설정합니다.
• 무엇을(Access) - API 호출, 리소스 액세스 등 어떤 작업을 수행할 수 있는지를 정의합니다.
• 허용 또는 거부(Allow/Deny) - 최소 권한 원칙에 기반하여 접근을 명시적으로 허용하거나 거부합니다.

 

IAM은 사실상 모든 AWS 서비스의 API 호출을 관할하는 보안 관문입니다. 즉, 어떤 리소스를 생성하거나 데이터를 조회하는 모든 행위는 IAM의 검증을 거쳐야 합니다.

따라서 IAM이 올바르게 설정되지 않는다면, 특정 리소스 수준을 넘어 클라우드 환경 전체가 위험에 노출될 수 있습니다. IAM은 단순한 설정 도구가 아니라, AWS 보안 전체를 지탱하는 가장 중요하고 복잡한 인프라 구성 요소인 이유가 여기에 있습니다. 그리고 바로 이 중요하고 복잡한 IAM 시스템에 "중복 권한"이라는 구조적이고 치명적인 보안 리스크가 존재합니다.

 

---

2. 중복 권한이란?

중복 권한(Duplicate Permissions)이란, AWS IAM 환경 내에서 서로 다른 이름을 가진 두 개 이상의 IAM 권한이 최종적으로 동일하거나, 겹치는 리소스 접근 결과를 만들어내는 경우를 의미합니다. 이는 단순히 하나의 사용자나 역할에 같은 정책이 중복으로 연결된 문제를 넘어선, 구조적인 보안 취약점으로 작용합니다.

중복 권한의 가장 심각한 리스크는 보안 통제의 핵심인 명시적 거부(Deny)의 효과를 무력화시킬 수 있다는 점입니다. IAM 권한 평가는 기본적으로 가장 강력한 Deny 원칙을 따르지만, 중복 권한 상황에서는 다음과 같은 문제가 발생합니다: 

•  ex) 관리자가 특정 작업을 차단하기 위해 권한 A를 정책에서 명시적으로 거부(Deny)했습니다. 하지만 동일한 효과를 가진 권한 B가 다른 정책에서 허용(Allow) 상태로 남아있다면, 최종적으로 해당 작업은 차단되지 않고 허용될 수 있습니다.

즉, 보안 관점에서 의도적으로 설정한 Deny가 중복된 권한 경로 때문에 예상대로 작동하지 않을 수 있는 구조적 위험이 있는 것입니다. 이러한 중복 권한은 보안 관리자가 모든 권한의 미묘한 교집합과 상호작용을 깊이 이해하지 못하면, 쉽게 간과할 수 있는 IAM의 복잡한 문제 중 하나입니다.

 

---

3. 중복 권한이 위험한 이유는?

AWS 환경에서 중복 권한은 단순한 관리 부실을 넘어, 클라우드 보안 모델 자체를 위협하는 치명적인 리스크를 내포합니다.

1. Deny 우선순위 원칙 무력화

IAM의 권한 평가 기본 원칙은 명시적 거부(Deny)가 명시적 허용(Allow)보다 항상 우선시 됩니다. 이는 보안 관리자가 특정 위험 행위를 가장 강력하게 차단할 수 있도록 보장하는 핵심 안전장치입니다. 그러나 명시적 거부 대상이 아닌 다른 권한 경로가 존재한다면, 이 원칙은 의미를 잃게 되며 중복 권한은 이 원칙을 우회합니다. 

• ex) 보안 관리자가 외부 계정의 접근을 막기 위해 sqs:AddPermission 권한을 명시적으로 Deny 했습니다. 하지만 동일한 정책 변경 기능을 수행하는 sqs:SetQueueAttributes 권한이 Allow 되어 있다면, 공격자는 이 우회 경로를 통해 SQS 큐 정책 전체를 변경하여 외부 계정에 접근 권한을 부여할 수 있습니다.

 

2. 우회 경로 파악의 어려움

AWS는 수많은 서비스에서 수천 개의 권한을 독립적으로 관리하며, 이 권한들은 끊임없이 업데이트됩니다. 여기에 API 버전 변경, 서비스 리브랜딩, 콘솔 전용 권한 설계 등이 결합되면서 동일 기능을 수행하는 권한들이 각기 다른 명칭과 분류로 혼재되는 구조적 복잡성이 심화되었습니다.

결과적으로 이러한 권한 간의 미묘한 상호작용과 잠재적 우회 경로를 완벽히 파악하여 선제적으로 차단하는 것은 사실상 불가능에 가까우며, 이는 거대한 시스템 속에서 아주 작은 보안 결함을 찾아내야 하는 '바늘구멍 찾기'와 같은 과제가 되었습니다.

 

3. 기존 IAM 감사 및 탐지 모델의 붕괴

대부분의 IAM 감사 도구와 보안 탐지 모델은 권한을 "권한 이름 기반" 또는 AWS가 제공하는 "카테고리 기반"으로 평가하고 위험도를 산정합니다. 하지만 중복 권한의 존재는 AWS가 제공하는 공식 분류 체계만으로는 보안 취약점을 완전히 통제할 수 없음을 의미합니다. 

• ex) SQS Queue 정책을 변경할 수 있는 두 가지 권한 비교
  • sqs:AddPermission은 주로 '권한 관리(Permissions Management)' 카테고리로 분류될 수 있습니다.
  • sqs:SetQueueAttributes는 주로 '쓰기(Write)' 카테고리로 분류될 수 있습니다.

해당 두 권한은 모두 외부 계정에 접근 권한을 부여하며 정책 변경이 가능한데도 분류가 다르기 때문에, 감사 도구가 하나의 카테고리만 검토할 경우 다른 하나를 놓칠 수 있습니다. 이처럼 중복 권한은 보안 분석의 기본 전제를 흔들어, 탐지 회피와 미인가 접근의 가능성을 높일 수 있습니다.

 

---

4. 중복의 근본 원인과 실제 사례

중복 권한은 AWS 서비스의 지속적인 발전과 설계 과정에서 발생하는 필연적인 결과입니다. 주요 발생 원인과 그에 따른 실제적인 보안 리스크를 살펴보겠습니다.

1. 콘솔 전용 vs API 전용 및 서비스 리브랜딩

AWS가 기능을 출시할 때 사용자 인터페이스(Console)와 프로그래밍 인터페이스(API)에 필요한 권한을 분리하여 설계하거나, 시간이 지나며 서비스 리브랜딩 또는 기능이 확장되면서 중복이 발생합니다.

a. AWS 계정 정보 수정 사례

AWS 계정의 연락처 정보를 수정하는 단일 작업에서 두 가지의 서로 다른 권한이 존재합니다. 이는 Console과 API에 대한 권한을 분리하여 관리하던 AWS의 초기 설계 패턴을 보여줍니다.

기능	권한 (Console 기반)	권한 (API 기반)
연락처 수정	aws:Portal:ModifyAccount	account:PutContactInformation / accout:PutAlternateContact

b. AWS IAM Identity Center (구 AWS SSO) 사례

서비스 리브랜딩 및 확장으로 인해, 기능이 유사한 권한들이 서로 다른 서비스 접두사를 단 채 Identity Center 내에 중복 존재하고 있습니다.

기능	권한 (1)	권한 (2)
권한 세트 정책 추가	sso:PutPermissionPolicy	sso:PutInIinePolicyToPermissionSet
그룹 멤버십 관리	identity-store:CreateGroupMembership	sso-directory:AddMemberTopGroup

 

2. API 버전 차이: Amazon Simple Email Service (SES)

한 서비스가 V1과 V2와 같이 여러 버전의 API를 동시에 지원하면서, 기능적으로 동일하지만 이름이 다른 권한이 다수 생성되는 경우입니다. 이는 API 버전 간의 하위 호환성 유지가 권한 복잡성을 어떻게 야기하는지 명확히 보여줍니다.

기능	권한 (V1 API)	권한 (V2 API)
원본 이메일 발송	ses:SendRawEmail	ses:SendEmail
템플릿 이메일 발송	ses:SendTemplatedEmail	ses:SendEmail
계정 발송 설정 관리	ses:UpdateAccountSendingEnabled	ses:PutAccountSendingAttributes

 

3. 여러 기능 동시 담당 설계: Amazon Simple Queue Service (SQS)

해당 사례는 단일 API 호출이 여러 보안 관련 기능을 포괄할 때 발생하는 위험을 보여줍니다.

기능	권한	설명
Queue의 리소스 기반 정책 변경	sqs:AddPermission	특정 주체에게 권한을 추가하는 방식 (세부 제어)
	sqs:SetQueueAttributes	전체 정책 문서를 덮어쓰는 방식 (전체 제어)

여기서 만약 보안팀이 sqs:AddPermission만 차단했다면, 공격자는 여전히 sqs:SetQueueAttributes를 이용해 정책을 통째로 변경하여 외부 계정에 데이터 접근 권한을 부여할 수 있습니다. 

 

4. 권한 부여 메커니즘: AWS Key Management Service (KMS)

동일한 리소스에 대한 접근 제어를 여러 메커니즘(ex: 키 정책 vs 키 권한 부여)으로 제공할 때 중복성이 발생하는 사례입니다. 여기서 KMS란 민감한 암호화 키를 관리하며, 키 권한 부여(Key Grant)라는 메커니즘을 통해 키에 대한 특정 권한을 다른 주체에게 위임할 수 있습니다. 이는 주로 다른 AWS 서비스가 사용자를 대신하여 작업을 수행할 때 사용됩니다.

이 키 권한 부여를 통해 부여된 접근 권한을 제거하는 데 두 가지 권한이 존재합니다. 이는 키 접근 제어를 관리하는 두 가지 방식 때문에 중복성이 발생하는 구조를 보여줍니다.

기능	권한 (1)	권한 (2)
키 권한 부여를 통해 접근 권한 제거	kms:RetireGrant	kms:RevokeGrant

 

---

5. 보안 운영의 한계와 대응 전략

AWS의 복잡한 중복 권한은 보안 기록을 확인하는 과정을 방해하고 실제 보안 업무를 어렵게 만듭니다.

우선, 사고 원인을 분석할 때 중요한 CloudTrail 로그와 실제 사용된 권한 이름이 서로 딱 맞아떨어지지 않아, 즉 IAM 권한 간의 일대일 매핑이 무너지면서 보안 조사의 효율성이 급격히 저하시킵니다. 예를 들어, SQS 정책 변경을 추적하기 위해 AddPermission뿐만 아니라 SetQueueAttributes와 같은 우회 경로를 함께 검색해야 하거나, SetContactAddress처럼 권한 명칭과 이벤트 이름이 아예 일치하지 않는 경우도 빈번합니다. 이러한 불일치는 보안팀이 일일이 정보를 대조하며 수동으로 분석해야 하고, 결국 분석의 정확도를 떨어뜨리고 대응 시간을 지연시키는 결과를 초래합니다.

또한, AWS가 기능적으로 동일한 권한을 '권한 관리'와 '쓰기' 등 서로 다른 카테고리로 분류함에 따라, 자동화된 분석 도구가 실제 위험 수준을 잘못 판단하는 일이 발생합니다. 최근 일부 권한에 복수 카테고리를 부여하는 등 분류 체계의 정교화가 진행되고 있으나, 이는 오히려 기존에 쓰던 도구들과 부딪히거나 관리에 혼란을 주기도 합니다.

이러한 이유로 AWS의 기본 분류를 맹목적으로 신뢰하기보다는, 각 권한이 실제로 시스템에 어떤 영향을 주는지 직접 확인하고 미리 대비하는 전략이 필요합니다. sqs:SetQueueAttributes처럼 정상적인 운영과 보안 위협의 경계에 있는 권한에 대해서는 무조건적인 Deny보다는 '허용 후 정밀 모니터링'과 같은 전략적 선택이 필요합니다. 더불어 개별적인 설정 실수가 큰 사고로 번지지 않도록 조직 전체에 미리 안전장치(SCP)를 걸어두고, 보안 도구 업체와 협력해 이러한 복잡한 권한 차이까지 정확히 찾아낼 수 있도록 성능을 계속해서 개선해 나가야 합니다.

 

---

6. 목표와 결론: 선제적인 보안 철학으로의 전환

중복 권한에 대한 종합적인 분석은 우리에게 보안 철학의 근본적인 전환을 요구합니다. 이제는 단순히 권한의 이름을 아는 것을 넘어, 그 권한이 초래하는 실제적인 뉘앙스와 결과를 이해하고자 합니다.

권한 기반 모델에서 결과 기반 모델로

우리는 반응적인(Reactive) 권한 기반 모델에서 벗어나, 선제적인(Proactive) 결과 기반 모델로 나아가야 합니다.

기존 질문 (권한 기반)	새로운 질문 (결과 기반)
"이 역할이 이 작업을 수행할 수 있는가?"	"의도된 비즈니스 결과는 무엇이며,  이를 달성하기 위한 절대 최소한의, 중복되지 않는 권한 집합은 무엇인가?"

이러한 접근 방식은 중복성을 고려한 전체적인 IAM 전략을 구축하도록 이끌어줍니다.

이러한 복잡성에 성공적으로 대응하려면, 보안팀, 개발팀, 외부 보안 파트너 간의 긴밀한 협력을 통해 복잡한 상호작용에 대한 공유된 이해를 구축하는 것이 필수적입니다. 중복 권한 문제에 대한 깊이 있는 이해는 AWS 환경에서 최소 권한 원칙을 구현하는 데 있어 가장 중요한 첫걸음이 될 것입니다.

---

Beaver Dam 팀은 공격자의 시선에서 바라보는 Cloud 보안인, Offensive Cloud Security 분야를 연구하고 학습하고 있는 팀입니다. 매월 무료 세미나를 개최하며, 다양한 정보 아래 링크들에서 공유드리고 있으니 많은 관심을 부탁드립니다.

• LinkedIn : https://www.linkedin.com/groups/14865006/
• Kakao Open Chat : https://open.kakao.com/o/gVh8CYYh