IAM 권한 평가 구조
AWS는 7가지 정책 유형을 지원한다.
•
Identity-based policies
•
Resource-based policies
•
Permissions boundaries
•
AWS Organizations SCPs
•
Resource Control Policies(RCPs)
•
ACLs
•
Session policies
요청 발생
│
▼
① 명시적 Deny 존재? ──── YES ──→ 즉시 거부 (어떤 Allow도 무효)
│ NO
▼
② SCP가 허용하는가?
│ NO ──────────────────────────→ 거부
│ YES
▼
③ Resource-based Policy가 허용하는가?
│ YES ─────────────────────────→ 허용 (동일 계정 내)
│ NO
▼
④ Permission Boundary가 허용하는가?
│ NO ──────────────────────────→ 거부
│ YES
▼
⑤ Identity-based Policy가 허용하는가?
│ YES ─────────────────────────→ 허용
│ NO ──────────────────────────→ 거부 (묵시적 Deny)
Plain Text
복사
핵심 공식: 유효 권한 = SCP ∩ Permission Boundary ∩ Identity Policy
세 가지 모두가 허용해야 최종 허용. 하나라도 막히면 거부.
Permission Boundary
Permission Boundary(권한 경계)는 관리형 정책을 사용해 IAM 엔터티(사용자 또는 역할)가 가질 수 있는 최대 권한을 설정하는 고급 기능이다. 엔터티의 유효 권한은 Identity-based policy와 Permission Boundary 양쪽 모두에서 허용하는 작업만 수행할 수 있다.
핵심 개념 — 교집합(∩)
Identity-based Policy Permission Boundary
(부여된 권한) (최대 허용 한도)
┌──────────────┐ ┌──────────────┐
│ S3:* │ │ S3:Get* │
│ EC2:* │ ∩ │ S3:Put* │
│ IAM:* │ │ │
└──────────────┘ └──────────────┘
│
▼
유효 권한: S3:Get*, S3:Put* 만 가능
(EC2:*, IAM:* 는 Boundary에 없으므로 차단)
Plain Text
복사
주요 usecase — 개발자에게 IAM 역할 생성 권한 위임
개발자가 자신보다 높은 권한을 가진 역할을 만드는 것을 방지할 때 사용
시나리오:
•
개발자에게 IAM 역할 생성 권한(iam:CreateRole) 부여
•
단, 생성하는 역할에 반드시 Permission Boundary 적용 조건 추가
→ 개발자는 역할을 만들 수 있지만, 자신보다 강한 권한의 역할은 생성 불가
개발자가 권한 상승을 못 하게 막으면서 IAM 권한은 줘야 한다 → Permission Boundary
Cross-Account Role & STS AssumeRole
동작 원리
크로스 계정 접근 시, 주체(Principal)가 역할로 전환하면 원래 권한을 포기하고 가정한 역할에 할당된 권한을 사용하게 된다. STS의 AssumeRole API를 호출하면 임시 보안 자격증명(Temporary Credentials)이 반환된다.
[Account A — 신뢰하는 계정] [Account B — 신뢰받는 계정]
IAM User/Role IAM Role "CrossAccountRole"
│ │
│ 1. sts:AssumeRole 호출 │
│──────────────────────────────────→ │
│ │ Trust Policy:
│ 2. 임시 자격증명 반환 │ Principal: Account A
│←────────────────────────────────── │ Action: sts:AssumeRole
│
│ 3. 임시 자격증명으로 Account B 리소스 접근
Plain Text
복사
Cross Account 접근 방법 비교
방법 | 설명 | 주체 권한 |
AssumeRole | 역할로 전환 | 원래 권한 포기, 역할 권한만 사용 |
Resource-based Policy | S3 버킷 정책 등 | 원래 권한 유지 + 리소스 권한 추가 |
A 계정 사용자가 B 계정 S3에 접근하되 A 계정 권한도 유지하고 싶다 → Resource-based Policy
완전히 다른 계정처럼 동작해야 한다 → AssumeRole
Role Chaining
Role Chaining(역할 체인)은 AWS CLI나 API를 통해서만 사용 가능하며, AWS Management Console에서는 사용할 수 없다. 또한 각 AssumeRole 호출마다 임시 자격증명의 최대 유효 시간이 1시간으로 재설정된다
External ID
•
파트너사가 내 계정에 접근할 때, Confused Deputy 공격 방지를 위해 사용
•
Trust Policy의 Condition에 sts:ExternalId 조건 추가
AWS Organizations & SCP
Organizations 구조
Root
├── Management Account (SCP 적용 안 됨 ⚠️)
├── OU: Security
│ └── Account: Security-Prod
├── OU: Production
│ ├── Account: App-Prod-1
│ └── Account: App-Prod-2
└── OU: Sandbox
└── Account: Dev-Test
Plain Text
복사
SCP (Service Control Policy)
SCP는 IAM 권한 정책과 유사하지만, 권한을 부여하지 않는다. 대신 조직 내 IAM 사용자 및 역할이 사용할 수 있는 최대 권한을 지정하는 액세스 제어 수단이다. SCP는 관리 계정의 사용자 및 역할에는 영향을 미치지 않으며, 멤버 계정에만 적용된다.
SCP 평가는 deny-by-default 모델을 따른다. 특정 계정에 권한이 허용되려면 Root부터 해당 계정까지의 모든 레벨(OU 포함)에서 명시적인 Allow가 있어야 한다.
SCP vs IAM Policy vs Permission Boundary
항목 | SCP | IAM Policy | Permission Boundary |
권한 부여 | (한도만 설정) | | (한도만 설정) |
적용 범위 | 계정/OU 전체 | 특정 사용자/역할 | 특정 사용자/역할 |
Root User 적용 | | | |
관리 계정 적용 | | | |
목적 | 조직 가드레일 | 실제 권한 부여 | 권한 상승 방지 |
SCP 전략
1.
Deny List 전략 (기본값)
•
FullAWSAccess SCP 유지 (모두 허용)
•
특정 위험 작업만 명시적 Deny 추가
•
예: “루트 계정 사용 금지”, “특정 리전 외 리소스 생성 금지”
2.
Allow List 전략
•
FullAWSAccess SCP 제거
•
허용할 서비스만 명시적 Allow
•
더 강력하지만 관리 복잡
SCP는 Management Account에 적용되지 않는다. 따라서 보안 정책 관리는 Management Account가 별도의 Security OU에서 하는 것이 Best Practice이다.
AWS Control Tower
AWS Control Tower는 조직 구조를 위한 논리적 경계/조직 단위를 생성해 공통 가드레일이 적용되어야 하는 AWS 계정을 그룹화할 수 있는 계정 조직 구조를 생성한다.
Guardrails
•
Preventive Guardrails (예방적)
→ SCP로 구현
→ 특정 작업 자체를 불가능하게 차단
예: “S3 퍼블릭 접근 설정 변경 금지”
•
Detective Guardrails (탐지적)
→ AWS Config Rules로 구현
→ 위반 발생 후 탐지 및 알림
예: “MFA 미설정 IAM 사용자 탐지”
Control Tower 핵심 구성 요소
구성요소 | 역할 |
Landing Zone | 멀티계정 환경의 전체 설정 기반 |
Account Factory | 신규 계정 자동 프로비저닝 템플릿 |
Guardrails | SCP + Config Rules 기반 정책 |
Log Archive Account | CloudTrail, Config 로그 중앙 저장 |
Audit Account | 보안 감사 도구 배포 전용 |
새 계정 생성 시 자동으로 보안 정책 적용 → Control Tower Account Factory
기존 Organizations에 Control Tower 적용 가능 → 가능 (Enroll existing accounts)
AWS KMS & Envelope Encryption
KMS 키 유형
직접 생성하는 키는 Customer Managed Keys다. 키 정책, IAM 정책, Grant 설정, 활성화/비활성화, 키 교체, 태그, 별칭 생성, 삭제 예약까지 완전한 통제권을 갖는다.
키 유형 | 관리 주체 | 비용 | 교차 계정 공유 | 용도 |
Customer Managed Key | 고객 | 월 $1/키 + 사용료 | 가능 | 규정 준수, 완전 제어 |
AWS Managed Key | AWS | 사용료만 | | 기본 암호화 |
AWS Owned Key | AWS (서비스 계정) | 무료 | | DynamoDB 기본 등 |
Envolope Encryption
봉투 암호화(Envolope Encryption)는 평문 데이터를 데이터 키(Data Key)로 암호화하고, 그 데이터 키를 다시 또 다른 키(KMS Key)로 암호화하는 방식이다.
[암호화 과정]
① KMS에 GenerateDataKey 요청
│
▼
② KMS가 반환:
- Plaintext Data Key (메모리에서만 사용)
- Encrypted Data Key (KMS Key로 암호화된 것)
│
▼
③ Plaintext Data Key로 실제 데이터 암호화
│
▼
④ Plaintext Data Key 즉시 메모리에서 삭제
│
▼
⑤ 저장: 암호화된 데이터 + Encrypted Data Key (함께 저장)
[복호화 과정]
① Encrypted Data Key를 KMS로 전송
② KMS가 Plaintext Data Key 반환
③ Plaintext Data Key로 데이터 복호화
Plain Text
복사
왜 봉투 암호화를 사용하는가?
•
대용량 데이터를 KMS로 직접 암호화하면 느리고 비쌈
•
빠른 대칭키(Data Key)로 데이터 암호화, KMS는 키만 보호
•
KMS Key는 AWS 외부로 절대 평문 상태로 나가지 않음 ← 핵심
KMS 키 자동 교체 (Key Rotation)
•
Customer Managed Key: 연 1회 자동 교체 가능 (활성화 필요)
•
교체해도 이전 암호화 데이터는 이전 키 재료로 복호화 가능 (AWS가 보관)
•
AWS Managed Key: 3년마다 자동 교체 (변경 불가)
AWS CloudHSM vs KMS
항목 | AWS KMS | AWS CloudHSM |
관리 형태 | 완전 관리형 | 고객이 HSM 직접 관리 |
FIPS 인증 | 140-3 Level 3 | 140-2 Level 3 |
멀티테넌트 | (공유 인프라) | (전용 HSM 하드웨어) |
비용 | 저렴 | 높음 ($1.45/시간/HSM) |
키 통제 | AWS와 공유 | 고객 완전 독점 |
사용 사례 | 일반 암호화 | 규제 요건, 고객만 키 접근 |
“HSM 하드웨어를 우리만 전용으로 써야 한다” or “AWS도 키에 접근할 수 없어야 한다”
→ CloudHSM
나머지 대부분 → KMS
IAM Identity Center (구 AWS SSO)
기업 IdP (Okta, Azure AD, SAML 2.0)
│
▼ SAML 연동
AWS IAM Identity Center
│
├── Permission Set A (AdministratorAccess)
│ └── Account 1, Account 2
├── Permission Set B (ReadOnlyAccess)
│ └── Account 3, Account 4
└── Permission Set C (DeveloperAccess)
└── Account 5
Plain Text
복사
•
Permission Set: 역할처럼 동작, 각 계정에 임시 자격증명 발급
•
SCIM: Azure AD 등에서 사용자/그룹 자동 프로비저닝
•
하나의 IdP로 수백 개 계정 SSO 접근 가능
멀티 계정에 대한 중앙집중식 SSO + 임시 자격증명 → IAM Identity Center + Permission Sets
개별 계정마다 IAM User 생성은 안티패턴
Summary
개념 | 한 줄 요약 |
Permission Boundary | IAM의 최대 권한 한도. 권한 부여 안 함, 상한선만 설정 |
SCP | 계정/OU의 최대 권한 가드레일. Root User에도 적용. 관리계정 제외 |
AssumeRole | 임시 자격증명 발급. 원래 권한 포기하고 역할 권한만 사용 |
Role Chaining | 역할에서 또 다른 역할 AssumeRole. 콘솔 불가, API/CLI만 |
Preventive Guardrail | SCP로 구현. 사전 차단 |
Detective Guardrail | Config Rules로 구현. 사후 탐지 |
봉투 암호화 | 데이터→Data Key 암호화, Data Key→KMS Key 암호화 |
CMK | 고객 관리. 교차계정 공유 가능. 연 $1/키 |
CloudHSM | 전용 HSM. AWS도 키 접근 불가. FIPS 140-2 L3 |
IAM Identity Center | 멀티계정 SSO. Permission Set으로 임시 자격증명 발급 |