정책·역할·권한 경계로 완전 정복하는 IAM 권한 모델
_Category: Identity & Access_
AWS 보안의 모든 것은 결국 IAM으로 귀결됩니다. 누가(Principal) 어떤 서비스에(Resource) 무엇을(Action) 할 수 있는지를 결정하는 IAM은 보안 아키텍처의 기반이자 SCS-C03 시험에서 가장 많이 등장하는 도메인입니다. 교차 계정 접근 실패, 권한 경계와 SCP 혼동, 신뢰 정책 누락 같은 실무 함정을 짚으며 핵심을 정리합니다.
---
IAM 권한 모델의 핵심: Principal, Action, Resource, Condition
IAM이 권한을 결정하는 방식은 네 가지 요소의 조합입니다. 마치 건물 출입 시스템처럼 생각하면 이해하기 쉽습니다.
Principal: 누가 요청하는가. IAM 사용자, IAM 역할, AWS 서비스, 외부 계정 등이 될 수 있습니다. Action: 무엇을 하려는가. , , 같은 API 호출입니다. Resource: 어느 리소스에 대해. ARN으로 특정 버킷, 역할을 지정합니다. Condition: 어떤 조건에서. IP 주소, 시간대, MFA 인증 여부, 리전, 태그 등을 조건으로 걸 수 있습니다.
IAM 정책은 이 네 요소를 JSON으로 기술한 문서입니다. 하나의 Statement 블록에 Effect(Allow/Deny), Principal, Action, Resource, Condition을 담습니다. 자주 등장하는 조건 키를 알아두면 시험 시나리오를 빠르게 읽을 수 있습니다.
— 기간 한정 접근 자동 차단. Allow 문에 조건을 거는 방식으로, 조건 불충족 시 암묵적 Deny가 적용됩니다. — MFA 인증 여부 검사. 장기 자격 증명 요청 시 항상 false이므로 일 때 Deny를 걸면 됩니다. — 리전 제한. 글로벌 서비스(IAM, CloudFront, Route 53)는 반드시 으로 제외해야 합니다. — 조직 외부 계정 일괄 차단. + — VPC 범위 + 태그 강제를 AND로 결합.
---
IAM 정책의 6가지 종류
IAM에서 권한을 제어하는 정책은 적용 대상과 방식에 따라 여섯 가지로 구분됩니다. 각각이 권한 평가의 서로 다른 레이어를 담당하므로, 어느 레이어에서 어떤 정책이 작동하는지를 정확히 알아야 합니다.
| 정책 종류 | 적용 대상 | 주요 역할 | 교차 계정 적용 | |-----------|-----------|-----------|---------------| | Identity-based Policy | IAM 사용자, 그룹, 역할 | 해당 주체가 할 수 있는 작업 정의 | 불가 | | Resource-based Policy | S3 버킷, KMS 키, SQS 큐 등 | 리소스에 접근할 수 있는 Principal 정의 | 가능 (Principal 지정) | | Permission Boundary | IAM 사용자, 역할 (개인 단위) | 최대 권한 상한선 제한 | 불가 | | SCP (Service Control Policy) | AWS Organizations OU, 계정 | 계정 전체 최대 허용 범위 제한 | Organizations 전체 | | Session Policy | STS 임시 세션 | 세션 단위 추가 권한 제한 | 불가 | | ACL (Access Control List) | S3, 일부 서비스 | 구형 접근 제어 방식 (권장하지 않음) | 가능 |
비유로 이해하면 이렇습니다. Identity-based Policy는 직원 개인 출입 권한 목록, Resource-based Policy는 회의실 문에 붙은 "이 사람만 입장 가능" 안내문, Permission Boundary는 "최대 허용 구역: 3층까지" 신입 출입증, SCP는 회사 전체 출입 규정, Session Policy는 외부 방문자 임시 출입증입니다.
Resource-based Policy는 해당 리소스 자체에 붙기 때문에 교차 계정 접근을 허용하는 유일한 수단입니다. Permission Boundary와 SCP는 허용 범위를 줄이는 역할만 하며 스스로 권한을 부여하지 않습니다.
---
정책 평가 로직: 명시적 거부 우선과 평가 순서
AWS는 요청이 들어오면 모든 관련 정책을 수집하여 일정 순서로 평가합니다. 핵심 원칙은 하나입니다. 명시적 Deny는 어디서 나오든 모든 Allow보다 우선합니다.
평가 순서는 ① 명시적 Deny → ② SCP(Organizations 환경) → ③ Permission Boundary → ④ Resource-based Policy → ⑤ Identity-based Policy 순입니다. 모든 단계에서 Allow가 없으면 암묵적 Deny로 거부됩니다.
동일 계정과 교차 계정 접근의 차이가 핵심입니다.
| 접근 유형 | 필요 조건 | |-----------|----------| | 동일 계정 S3 접근 | Identity-based Policy OR Resource-based Policy 중 하나만 Allow이면 허용 | | 교차 계정 S3 접근 | Identity-based Policy AND Resource-based Policy(버킷 정책) 양쪽 모두 Allow 필요 |
AdministratorAccess를 가진 역할도 다른 계정 버킷에 버킷 정책 허용이 없으면 접근할 수 없습니다. 또 하나의 함정은 S3 ARN 수준입니다. 는 반드시 (객체 ARN)으로 지정해야 합니다. 버킷 ARN만 지정하면 Access Denied가 발생합니다.
---
Role과 AssumeRole: 교차 계정·서비스 간 임시 권한 모델
IAM Role은 임시로 발급하는 "타 부서 임시 출입증"입니다. STS(Security Token Service)가 발급하는 임시 토큰으로 최소 15분에서 최대 12시간 내에 자동 만료됩니다.
역할에는 반드시 두 가지 정책이 필요합니다.
신뢰 정책(Trust Policy): 누가 이 역할을 맡을 수 있는지 정의합니다. Principal에 AWS 계정, IAM 역할, 또는 AWS 서비스를 지정합니다. 권한 정책(Permission Policy): 역할을 맡은 후 할 수 있는 작업을 정의합니다.
EC2가 S3에 접근하려면 권한 정책에 s3 권한 + 신뢰 정책에 이 필요합니다. 신뢰 정책에 서비스가 없으면 역할 인수 자체가 실패합니다.
교차 계정 AssumeRole: 대상 계정 역할의 신뢰 정책에 소스 계정 허용 + 소스 계정 IAM 주체의 권한 정책에 — 두 조건 모두 충족해야 성공합니다.
AWS CLI 자격 증명 우선순위: 환경 변수 > credentials 파일 > config 프로파일 > IMDS(역할). EC2에 역할이 연결되어 있어도 credentials 파일이 있으면 파일이 우선 적용됩니다.
주요 임시 자격 증명 발급 메커니즘: EC2 인스턴스 프로파일(IMDS 자동 순환), Cognito Identity Pool(게스트 포함 STS 기반), IAM Roles Anywhere(온프레미스 X.509 인증서 기반 장기 키 대체).
---
Permission Boundary vs SCP: 가장 헷갈리는 두 개념의 차이
Permission Boundary와 SCP는 둘 다 "권한을 제한"하는 도구인데, 적용 대상과 범위가 전혀 다릅니다. 이 둘을 혼동하면 시험에서 자주 틀립니다.
| 항목 | Permission Boundary | SCP | |------|--------------------|---------| | 적용 대상 | 개별 IAM 사용자 또는 역할 | AWS Organizations OU 또는 계정 전체 | | 설정 위치 | IAM 콘솔 (사용자/역할 단위) | Organizations 관리 콘솔 | | 권한 부여 여부 | 권한 부여 불가, 상한선만 정의 | 권한 부여 불가, 최대 허용 범위만 정의 | | 유효 권한 계산 | Identity-based Policy ∩ Permission Boundary | SCP ∩ Identity-based Policy ∩ Permission Boundary | | 주요 사용 사례 | 개발팀이 생성한 역할의 권한 상한 제어 | 조직 전체 리전/서비스 제한 |
Permission Boundary는 개발팀에게 역할 생성 자율성을 주면서 관리자 권한 탈취를 막는 데 씁니다. 보안팀이 Boundary 정책을 만들고 에 조건으로 연결을 강제합니다. 개발팀이 AdministratorAccess 역할을 만들어도 Boundary가 초과 권한을 차단합니다.
SCP는 Organizations 전체 또는 OU에 적용됩니다. 관리 계정에는 SCP가 적용되지 않습니다. SCP는 권한을 부여하는 수단이 아니라 최대 허용 범위를 정의합니다. 개인 단위 제한에는 SCP가 아닌 Permission Boundary를 사용해야 합니다.
!Permission Boundary vs SCP
Federation과 IAM Identity Center: 외부 ID 통합과 SSO
직원마다 IAM 사용자를 만드는 방식은 비효율적이고 보안 위험도 큽니다. 기존 Active Directory나 외부 IdP를 AWS와 연동하는 Federation이 대안입니다.
SAML 2.0 Federation은 IdP에서 인증받은 SAML Assertion을 STS가 검증하여 임시 자격 증명을 발급합니다. 계정이 여러 개라면 각 계정마다 개별 설정이 필요해 관리 부담이 커집니다.
OIDC 기반 Federation(Web Identity Federation)은 Cognito를 통해 구현하며 로 임시 자격 증명을 받습니다. 모바일 앱 소셜 로그인 사용자에게 AWS 리소스 접근을 허용할 때 씁니다.
IAM Identity Center(구 AWS SSO)는 Organizations와 통합하여 수백 개 계정에 단일 자격 증명으로 접근하는 SSO를 중앙 관리합니다. AD Connector는 기존 온프레미스 AD를 클라우드에 동기화하지 않고 프록시 방식으로 인증합니다.
Identity Center 구성 순서: Organizations 관리 계정에서 활성화 → ID 소스 선택 → Permission Set 생성 → 사용자·그룹에 계정 할당. Permission Set에 Customer Managed Policy를 포함하려면 해당 정책이 대상 멤버 계정에 미리 생성되어 있어야 합니다. 없으면 할당이 실패합니다.
---
시험에서 헷갈리는 IAM 시나리오
실제 시험 문제에서 자주 등장하는 함정을 정리합니다.
교차 계정 S3 접근 실패: 워크로드 계정의 IAM 역할에 S3 권한이 있어도 중앙 계정 버킷 정책에 해당 Principal이 없으면 거부됩니다. 버킷 정책에 역할 ARN 또는 계정 ID를 명시적으로 허용해야 합니다.
루트 사용자 ARN 혼동: 루트 사용자는 형식입니다. 는 root라는 이름의 IAM 사용자로 전혀 다릅니다. S3 명시적 Deny는 루트 사용자도 차단합니다.
Lambda 로그 없음: 실행 역할에 , 만 있으면 로그가 기록되지 않습니다. 쓰기 권한 세 가지(, , )가 필요합니다. 이 이를 포함합니다.
AssumeRole 실패: 신뢰 정책 Principal이 올바른데도 실패한다면, 호출자 측 권한 정책에 이 있는지 확인하세요. 신뢰 정책과 권한 정책 양쪽 모두 충족해야 합니다.
EC2 역할 무시: EC2에 역할이 연결됐는데 장기 자격 증명이 사용된다면 파일을 확인하세요. credentials 파일이 IMDS보다 우선순위가 높습니다.
KMS를 이용한 직무 분리: 운영팀이 S3 접근 권한을 가져도 SSE-KMS 객체를 읽으려면 KMS 복호화 권한이 추가로 필요합니다. 보안팀이 KMS 키 정책을 제어하면 운영팀의 독단적 데이터 접근을 막을 수 있습니다. SSE-S3는 AWS 자동 관리이므로 이런 직무 분리가 불가능합니다.
---