IAM 정책과 역할, 권한 경계

주체와 정책을 평가해 임시 세션에 필요한 권한을 부여하는 IAM 흐름

IAM(Identity and Access Management)은 AWS 리소스에 누가 어떤 작업을 할 수 있는지를 정의한다. 문제를 풀 때는 정책의 종류를 외우는 데서 멈추지 말고, 요청 주체와 대상 리소스가 같은 계정인지, 임시 권한이 필요한지, 상위 경계 정책이 있는지부터 구분하면 선택지가 좁혀진다.

1. IAM 핵심 구성 요소

IAM
├── User     — 사람 또는 서비스가 직접 사용하는 장기 자격 증명
├── Group    — User의 묶음, 정책을 일괄 적용하기 위한 단위
├── Role     — 임시 자격 증명, EC2·Lambda·다른 계정 등이 가정(Assume)
└── Policy   — 무엇을 허용/거부할지 정의하는 JSON 문서

IAM은 글로벌 서비스다

IAM은 리전을 선택하지 않는다. 생성한 User, Role, Policy는 모든 리전에서 동일하게 사용된다.

2. 정책(Policy) 구조 읽기

SAP 시험에서 정책 JSON을 보여주고 어떤 동작을 허용/거부하는지 묻는 문제가 자주 나온다. JSON을 읽을 수 있어야 한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-2"
        }
      }
    }
  ]
}

각 필드의 의미:

필드	설명
`Version`	정책 언어 버전. 항상 `"2012-10-17"` 사용
`Effect`	`Allow` 또는 `Deny`
`Action`	허용/거부할 AWS API 액션. `*`로 전체 허용 가능
`Resource`	어떤 리소스에 적용할지. ARN으로 지정
`Condition`	추가 조건 (선택). IP 제한, 리전 제한, MFA 요구 등

Explicit Deny는 항상 이긴다

IAM 평가 로직에서 가장 중요한 규칙이다.

최종 권한 결정 순서:
1. 명시적 Deny  → 무조건 거부 (다른 모든 것보다 우선)
2. 명시적 Allow → 허용
3. 기본값        → 묵시적 Deny (아무 정책이 없으면 거부)

선택 근거: A 정책에서 Allow, B 정책에서 Deny가 동시에 적용되면 Deny가 이긴다. 시험에서 "어떤 액션이 가능한가?"를 묻는 문제의 핵심이다.

3. 정책 종류

IAM 정책은 어디에 붙느냐에 따라 종류가 나뉜다.

Identity-based Policy (자격 증명 기반)

User, Group, Role에 직접 붙이는 정책.

AWS 관리형 정책: AWS가 미리 만들어 둔 것 (예: AmazonS3FullAccess)
고객 관리형 정책: 직접 만든 재사용 가능한 정책
인라인 정책: 특정 User/Role에만 1:1로 붙이는 정책. 재사용 불가

Resource-based Policy (리소스 기반)

리소스 자체에 붙이는 정책. 누가 이 리소스에 접근할 수 있는지를 리소스 측에서 정의.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:root"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

Principal 필드가 핵심 — 누가 허용되는지를 명시
Resource-based Policy를 지원하는 대표 서비스: S3, SQS, SNS, Lambda, KMS

선택 근거: 크로스 계정 접근에서 Resource-based Policy가 핵심이다. 계정 A의 S3에 계정 B가 접근하려면, 계정 A의 S3 버킷 정책에 계정 B를 Principal로 명시해야 한다.

4. IAM Role과 AssumeRole

IAM Role은 IAM에서 가장 중요한 개념이다.

User와 Role의 차이

구분	User	Role
자격 증명	장기 (Access Key)	임시 (STS 토큰)
사용 대상	사람, CI/CD 도구	EC2, Lambda, 다른 계정
만료	없음 (직접 비활성화)	15분 ~ 12시간
권장	사람에게만	서비스·자동화에

AssumeRole 흐름

Role을 사용한다는 것은 역할을 가정(Assume) 하는 것이다. STS(Security Token Service)가 이를 처리한다.

EC2 인스턴스
    │
    │  1. AssumeRole 요청
    ▼
  STS (Security Token Service)
    │
    │  2. 임시 자격 증명 발급
    │     (Access Key + Secret Key + Session Token)
    ▼
EC2 인스턴스
    │
    │  3. 임시 자격 증명으로 S3 접근
    ▼
   S3 버킷

EC2에 Role을 붙이는 것 = EC2가 STS에서 임시 토큰을 자동으로 발급받아 사용하는 구조다. Access Key를 코드에 하드코딩하는 것보다 훨씬 안전하고, SAP에서도 이 방식이 정답이다.

5. 크로스 계정 접근 (Cross-Account Access)

SAP에서 자주 나오는 엔터프라이즈 시나리오다. 대기업은 계정을 여러 개로 나누어 관리하기 때문에 계정 간 접근이 필수다.

방법 1: Role + AssumeRole (권장)

계정 A (신뢰하는 계정, Trusting Account)
  └── IAM Role 생성
        ├── Trust Policy: "계정 B가 이 Role을 Assume할 수 있다"
        └── Permission Policy: "S3 접근 허용"

계정 B (신뢰받는 계정, Trusted Account)
  └── User/Role에 sts:AssumeRole 권한 부여
        └── 계정 A의 Role ARN을 지정

Trust Policy 예시 (계정 A의 Role에 붙임):

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::계정B_ID:root"
  },
  "Action": "sts:AssumeRole"
}

방법 2: Resource-based Policy

S3처럼 Resource-based Policy를 지원하는 서비스는 Role 없이도 직접 접근 가능. 단, Role 방식이 더 유연하고 감사(Audit)에 유리하다.

선택 근거: "A 계정의 Lambda가 B 계정의 DynamoDB에 접근해야 한다" → DynamoDB는 Resource-based Policy를 지원하지 않으므로 Role + AssumeRole 방식이 유일한 선택이다.

6. Permission Boundary (권한 경계)

Permission Boundary는 IAM Entity(User/Role)가 가질 수 있는 최대 권한의 상한선이다.

왜 필요한가?

개발팀에게 IAM 관리 권한을 위임할 때 문제가 생긴다. 개발자가 자기 자신에게 AdministratorAccess를 부여해버리면 모든 통제가 무너진다.

Permission Boundary로 이를 방지한다.

실제 권한 = Identity Policy ∩ Permission Boundary

예시:
- Identity Policy: S3 전체 + EC2 전체 + IAM 전체
- Permission Boundary: S3 전체 + EC2 전체
- 실제 권한: S3 전체 + EC2 전체  (IAM은 Boundary에 없으므로 불가)

위임된 관리자 패턴

관리자
  └── 개발자에게 IAM User 생성 권한 부여
        └── 단, Permission Boundary 조건 필수
              └── 개발자가 만드는 User는 최대 S3, EC2만 가능

선택 근거: "개발자가 자신의 권한보다 높은 권한의 사용자를 만들지 못하게 해야 한다" → Permission Boundary가 정답이다.

7. SCP (Service Control Policy)

SCP는 IAM 정책이 아니라 AWS Organizations의 기능이지만, IAM과 함께 이해해야 한다.

SCP는 Organization 단위(OU) 또는 계정 전체에 적용되는 최상위 권한 제한이다.

권한 결정 계층:
SCP → Permission Boundary → Identity Policy → Resource Policy

각 단계에서 교집합(AND)으로 최종 권한 결정

SCP vs IAM Policy 차이

구분	SCP	IAM Policy
적용 대상	OU 또는 계정 전체	특정 User/Role
루트 사용자	제한 가능	제한 불가
우선순위	더 높음	낮음
허용 방식	허용 목록 or 거부 목록	허용 목록

SCP 예시 — 서울 리전 외 리소스 생성 금지:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": "ap-northeast-2"
    }
  }
}

선택 근거: SCP는 멤버 계정의 관리자(root 포함)도 제한할 수 있다. 단, Organizations 관리 계정에는 SCP가 적용되지 않는다. "특정 멤버 계정에서 특정 리전 외 서비스 사용을 원천 차단" → SCP가 정답이다.

8. IAM Best Practices (시험 단골 출제)

원칙	내용
루트 계정 미사용	루트는 MFA 설정 후 잠금. 일상 작업 금지
최소 권한 원칙 (Least Privilege)	필요한 권한만, 필요한 기간만 부여
Access Key 미사용	EC2, Lambda엔 Role 사용. Access Key는 로컬 개발 최소화
MFA 활성화	특히 특권 계정은 필수
정기 권한 검토	IAM Access Analyzer, Access Advisor 활용

IAM Access Analyzer

의도치 않은 외부 접근을 자동으로 탐지하는 도구.

S3 버킷이 public으로 열려 있는지
Role이 외부 계정에서 Assume 가능한지
등을 지속적으로 모니터링

선택 근거: "계정 외부에서 접근 가능한 리소스를 자동으로 파악하려면?" → IAM Access Analyzer

9. SAP 시험 출제 유형 정리

유형 1 — 최소 권한 설계

"개발자가 특정 S3 버킷에만 업로드할 수 있고, 다른 버킷은 접근 불가해야 한다."

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::dev-bucket/*"
}

다른 버킷에 대한 명시적 Deny 또는 다른 Allow 없음

유형 2 — 크로스 계정 접근

"계정 A의 Lambda가 계정 B의 S3 버킷에서 파일을 읽어야 한다. 가장 안전한 방법은?"

계정 A: Lambda에 Role 부여 + sts:AssumeRole 권한 → 계정 B의 Role ARN 지정
계정 B: Role 생성 + Trust Policy에 계정 A 명시 + S3 읽기 권한

유형 3 — 권한 위임 제한

"팀 리더에게 팀원의 IAM User를 생성할 수 있는 권한을 주되, 팀 리더 자신보다 높은 권한을 가진 User를 만들지 못하게 해야 한다."

→ Permission Boundary 정책 생성 + 팀 리더에게 "Permission Boundary가 첨부된 경우에만 CreateUser 허용" 조건 부여

10. AccessDenied를 푸는 실전 순서

권한 문제는 정책 JSON을 처음부터 모두 읽기보다, 요청을 네 가지 요소로 쪼개면 빠르게 좁힐 수 있다.

Principal — 어떤 User·Role·Role Session이 요청했는가?
Action — 정확히 어떤 API 작업이 거부됐는가?
Resource — 리소스 ARN과 리전이 정책의 Resource·Condition과 맞는가?
Context — 조직의 SCP, Permission Boundary, Session Policy, VPC Endpoint Policy, MFA·IP 조건이 추가로 적용되는가?

그다음에는 아래 순서로 확인한다.

CloudTrail의 실패 요청 확인
  → 명시적 Deny와 조건(리전·IP·MFA) 검색
    → IAM Policy Simulator로 최소 정책 재현
      → IAM Access Analyzer로 외부 공유·신뢰 정책 검토

여러 정책에 Allow가 있어도 적용 가능한 정책 집합에 Allow가 없으면 거부된다. 반대로 적용 범위에 명시적 Deny가 하나라도 있으면 Allow보다 Deny가 우선한다. 크로스 계정 요청은 호출 계정의 권한과 대상 계정의 Trust/Resource 정책을 함께 확인해야 한다.

이 글의 정책 평가 순서는 시험에서 빠르게 판단하기 위한 단순화다. 실제 요청은 요청 유형과 리소스 정책에 따라 평가 경로가 달라질 수 있으므로, 최종 확인은 공식 평가 로직과 CloudTrail 결과를 기준으로 한다.

11. 공식 문서로 다시 확인하기

IAM 정책 평가 로직 — 암묵적 거부·명시적 거부·정책 조합
IAM 모범 사례 — 루트 계정, 임시 자격 증명, 최소 권한
IAM Access Analyzer — 외부 접근 가능성 분석

이 시리즈에서 이어 읽기

01. 글로벌 인프라와 장애 경계 — 리전·AZ 선택과 공동 책임 모델
03. VPC와 네트워크 경계 — 보안 그룹·NACL·엔드포인트 권한 연결

정리

개념	핵심 한 줄
Explicit Deny	항상 이긴다. Allow와 충돌하면 Deny 승리
Role	서비스·자동화에는 User 대신 Role. 임시 자격 증명
AssumeRole	STS가 임시 토큰 발급. 크로스 계정 접근의 핵심
Permission Boundary	권한의 천장. 위임된 관리자가 권한을 초과하지 못하게 제한
SCP	Organization 레벨 권한 제한. 멤버 계정의 루트도 제한 가능
Access Analyzer	외부 노출 리소스 자동 탐지

AWS에서 네트워크를 직접 설계하는 개념으로, SAP에서 빠지지 않는 주제다. 서브넷, 라우팅, IGW, NAT, VPN, Direct Connect, VPC Peering, Transit Gateway까지 다룰 예정이다.