IAM 핵심 정리 — 사용자·역할·정책 한 번에

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 첫 번째 편입니다. 강의를 들으면 거의 항상 첫 단원이 IAM이에요. 처음 들으면 "왜 EC2나 S3 같은 화려한 서비스부터 안 가르치고 권한 관리부터 시작할까?" 하는 생각이 들기 마련인데, 막상 시험 문제를 풀어 보면 그 이유가 와 닿습니다. AWS의 거의 모든 시나리오 문제가 결국 "누가 무엇을 할 수 있게 할 것인가"의 변형이거든요.

EC2 인스턴스가 S3에 접근해야 하는데 어떻게? Lambda가 DynamoDB를 읽으려면? 다른 회사 계정에서 우리 버킷을 쓸 수 있게 하려면? — 전부 IAM 이야기예요. 그래서 IAM을 단단히 잡고 가면 뒤에 나오는 거의 모든 단원이 한결 가벼워집니다.

이 글은 IAM을 처음 보는 분도 따라올 수 있게 천천히 풀어 갑니다. 회사 출입카드 비유를 자주 쓸 거고, 시험에 자주 나오는 함정도 그때그때 짚어 드려요. 한 번에 다 외우려 하지 말고, 흐름과 "왜 이렇게 설계됐는가" 만 머리에 들어와도 충분합니다.

IAM이 도대체 뭘 하는 서비스인가요

IAM이라는 단어를 처음 들으면 뭔가 무뚝뚝한 느낌이죠. 풀어 쓰면 Identity and Access Management — 그러니까 "누가 AWS 안에서 무엇을 할 수 있는지" 관리하는 시스템입니다. 회사로 치면 출입카드와 권한을 발급해 주는 부서랑 비슷해요. 누가 사옥에 들어올 수 있는지, 들어와서 어느 층까지 갈 수 있는지, 어떤 회의실을 예약할 수 있는지 — 이런 걸 정해 주는 부서요.

여기서 가장 먼저 짚어둘 사실이 하나 있어요. IAM은 글로벌 서비스입니다. 이게 무슨 말이냐면 — EC2나 RDS는 서울 리전에서 만들면 서울에서만 보입니다. 도쿄 리전 콘솔에 가면 안 보여요. 그런데 IAM 사용자·그룹·정책은 한 번 만들면 전 세계 어느 리전에서든 그대로 동작합니다. 그래서 콘솔의 리전 선택 드롭다운이 IAM 화면에서는 회색으로 비활성화돼요. 고를 게 없거든요.

이 사실은 시험에 거의 매번 한 번씩 나옵니다. "리전별로 IAM 사용자를 따로 만들어 관리하려면…" 같은 보기는 무조건 함정이에요. 정답은 항상 "그럴 필요가 없다, IAM은 처음부터 글로벌이라 모든 리전에 한 번에 적용된다" 입니다.

여담으로 한 번에 외워두면 좋은 게 — 글로벌 서비스 4총사입니다. IAM · Route 53 · CloudFront · WAF. 이 넷만 글로벌이고 나머지 거의 모든 AWS 서비스는 리전에 묶여 있어요. 시험에서 "리전 종속 여부" 묻는 문제는 이 넷만 머리에 있으면 거의 다 풀립니다.

루트 계정 — 절대로 일상 작업에 쓰지 않습니다

AWS 계정을 처음 만들 때 자동으로 생기는 게 루트(Root) 사용자입니다. 회원가입할 때 쓴 이메일이 그대로 루트 계정이고, 모든 서비스·모든 리소스에 무제한 권한을 가져요. 삭제도 안 되고, 나중에 다른 사람에게 양도도 안 됩니다.

이 막강함이 그대로 위험성이에요. 루트 자격 증명이 한 번 새면 — 가령 깃허브 퍼블릭 레포에 키가 실수로 올라가면 — 계정 자체를 잃을 수 있습니다. 그래서 AWS 모범 사례는 명확해요.

• 루트는 최초 설정·결제 정보 변경 같은 극히 제한된 작업에만 사용
• MFA(2단계 인증)는 무조건 활성화 — 비밀번호가 새도 두 번째 인증이 막아 줍니다
• 일상 작업은 별도의 IAM 사용자(보통 본인용 관리자 계정 하나)를 만들어서 거기서 처리

시험에 "관리자가 일상 운영 작업을 어떻게 해야 하는가" 같은 시나리오가 나오면, 답은 항상 "루트 말고 IAM 사용자/역할 사용" 입니다. 루트 계정 보호 방법을 묻는 문제의 정답은 거의 100% MFA고요.

IAM의 네 가지 부품 — 왜 이렇게 나눠놨을까요

IAM의 핵심 구성 요소는 네 가지로 끝납니다 — 사용자(User)·그룹(Group)·역할(Role)·정책(Policy). 처음 보면 다 비슷해 보이는데 각자 존재 이유가 달라요. 회사 비유로 한 번 풀어 봅니다.

사용자(User) — 직원증 같은 것

사용자(User) 는 실제 사람 한 명에 대응하는 엔터티입니다. 회사로 치면 직원증이에요. 직원이 30명이면 직원증이 30장, 한 사람당 하나가 원칙. 자격 증명을 둘이 같이 쓰지 않습니다(만약 보안 사고가 나면 누구 책임인지 추적이 안 되니까).

사용자에게는 콘솔 로그인용 비밀번호를 부여할 수 있고, CLI/SDK용 액세스 키도 발급할 수 있어요. 그룹에 안 속해도 단독으로 존재할 수 있지만, 관리 효율을 위해 거의 항상 어떤 그룹에 넣어 둡니다.

그룹(Group) — 부서 같은 것

그룹(Group) 은 사용자 여러 명을 묶어 권한을 한꺼번에 관리하는 단위입니다. 회사로 치면 부서예요. 마케팅팀 30명에게 동일한 정책을 일일이 붙이는 대신, "마케팅팀 그룹"에 정책을 한 번 붙이면 끝입니다.

여기서 시험에 자주 나오는 함정이 두 개 있어요.

첫째, 그룹에는 사용자만 들어갑니다. 다른 그룹을 그룹 안에 중첩(Nesting)할 수는 없어요. 회사 비유로 치면 — "마케팅 그룹 안에 디자인팀 그룹을 통째로 넣을 수는 없다"는 뜻입니다. 시험에 "Admins 그룹 안에 Developers 그룹을 넣으려면…" 같은 보기가 나오면 무조건 오답.

둘째, 한 사용자는 동시에 여러 그룹에 속할 수 있고, 그 모든 그룹의 정책이 합집합으로 누적됩니다. 한 사람이 마케팅팀이면서 동시에 사이드 프로젝트팀에 속할 수 있고, 두 팀 모두의 권한을 갖는 거예요.

역할(Role) — 빌려 쓰는 통행증

역할(Role) 이 처음에 가장 헷갈리는데, 한 줄로 풀면 "사람이 아닌 주체(AWS 서비스나 다른 계정)가 일시적으로 권한을 빌려 쓸 때 사용" 합니다. 회사 비유로 치면 — 외부 협력사 직원이 잠깐 우리 사옥 들어올 때 받는 방문자 출입증 같은 거예요. 영구 직원증이 아니라 그 날만 유효한 임시 통행증.

EC2 인스턴스가 S3에 파일을 올려야 한다고 합시다. 인스턴스 안에 액세스 키를 박아두면? 키가 새는 순간 끝입니다. 대신 EC2에 IAM 역할을 붙이면 — 정확히 말하면 인스턴스 프로파일(Instance Profile) 이라는 컨테이너로 — AWS가 알아서 만료되는 임시 자격 증명을 자동 갱신해 줍니다. 시간이 지나면 자동으로 키가 새 키로 교체돼요.

정책(Policy) — 권한 명세서

정책(Policy) 은 위 셋(사용자·그룹·역할) 중 누군가에게 "어떤 리소스에 어떤 작업을 허용하거나 거부할지"를 적은 JSON 문서입니다. 회사로 치면 권한 명세서예요. "이 직원은 3층 회의실 예약 가능, 5층은 불가" 같은 규칙을 적은 종이.

정책 자체는 권한을 가진 주체가 아닙니다. 항상 누군가에게 붙여서 동작해요. 그리고 모든 정책 작성의 큰 원칙은 최소 권한의 원칙(Principle of Least Privilege) 입니다 — 필요한 만큼만 주고, 그 이상은 주지 않는다. 시험에서 "어떤 권한을 줘야 하는가" 묻는 문제는 거의 항상 가장 좁은 권한이 정답이에요.

여기까지를 한 줄로 정리하면 — 사람은 사용자, 묶음은 그룹, 빌려 쓰기는 역할, 권한 명세는 JSON 정책.

정책 JSON 구조 — 한 번만 제대로 보면 평생 갑니다

정책은 JSON으로 작성합니다. 처음 보면 복잡해 보이는데 구조 한 번만 잡으면 그다음부턴 다 똑같아요. 더 깊이 파고들고 싶다면 IAM 정책 레퍼런스 공식 문서 를 곁에 두고 보면 좋습니다. 실제 예시를 한 번 보고 갑니다.

{
  "Version": "2012-10-17",
  "Id": "policy-id",
  "Statement": [
    {
      "Sid": "statement-id",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/Alice"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-2"
        }
      }
    }
  ]
}

복잡해 보이지만, Statement 한 개를 한 문장처럼 읽으면 됩니다.

> "Effect(허용/거부) 에 따라, Principal(누가) 이 Resource(어떤 리소스에) Action(무슨 작업을), Condition(어떤 조건에서) 한다."

위 예시를 한국어로 풀면 — "Alice가 my-bucket 안의 객체에 대해 GetObject·PutObject를 ap-northeast-2(서울) 리전에서 호출할 때만 허용한다." 정도가 돼요.

각 키의 역할을 표로 한 번 정리합니다.

요소	필수 여부	설명
Version	권장	정책 언어 버전 (2012-10-17 고정으로 박아두면 됨)
Effect	필수	Allow 또는 Deny
Action	필수	허용/거부할 API 호출 (예: s3:GetObject)
Resource	필수	작업 대상 ARN
Principal	리소스 기반 정책에서만 필수	정책이 적용되는 주체
Condition	선택	적용 조건 (IP·리전·MFA 등)

여기서 시험에 자주 나오는 S3 ARN 함정을 짚고 갑니다. S3는 작업 단위가 두 종류라서 ARN 끝에 /* 가 붙는지 안 붙는지가 갈려요.

작업 레벨	Action 예시	ARN 형식
버킷 레벨	s3:ListBucket	arn:aws:s3:::bucket-name (끝에 슬래시 없음)
객체 레벨	s3:GetObject, s3:PutObject, s3:DeleteObject	arn:aws:s3:::bucket-name/ (끝에 /)

ListBucket은 "버킷 자체"에 대한 작업이라 버킷 ARN이고, GetObject는 "버킷 안의 객체 하나"에 대한 작업이라 객체 ARN입니다. 의미를 알면 안 헷갈려요. 시험에 "정책이 동작하지 않는 이유"를 묻는 문제의 정답이 자주 이 ARN 패턴 오류입니다.

정책 평가 — 명시적 Deny가 무조건 이깁니다

여러 정책이 한 사용자에게 붙어 있을 때 — 그룹에서 받은 정책 + 직접 붙인 정책 + 리소스 기반 정책 + SCP까지 — "이 작업은 허용일까 거부일까"를 결정하는 평가 규칙이 있어요. 이 규칙이 시험 함정의 본진이라 한 번 천천히 풀어 갑니다.

핵심을 두 줄로 요약하면:

1. 명시적 Deny가 항상 이깁니다. Allow가 100개여도 Deny 한 줄이 있으면 결과는 거부.
2. 명시적 Allow가 없으면 자동으로 거부입니다. IAM 사용자는 만들자마자 아무 권한도 없는 상태로 시작해요.

비유하자면 — 회사 출입 시스템에서 "출입 금지" 도장이 한 번이라도 찍혀 있으면, 다른 부서장이 "허락한다" 도장을 100번 찍어도 못 들어갑니다. 그리고 아무 도장도 안 찍혀 있으면 기본은 "출입 금지"예요.

평가 순서를 정확히 짚으면 다음 6단계입니다.

1. 모든 정책에서 명시적 Deny가 있는지 먼저 확인 — 있으면 그 순간 끝, 거부
2. Organizations SCP — 조직 정책으로 막혀 있는지
3. 리소스 기반 정책 — S3 버킷 정책 같은 게 있는지
4. Identity 기반 정책 — 사용자/그룹/역할에 붙은 정책
5. Permission Boundary — 사용자에게 최대 권한 경계가 걸려 있는지
6. 세션 정책 — AssumeRole 시 일시적으로 좁혀진 정책

이 6단계를 모두 통과해야 비로소 작업이 허용됩니다. 시험에서 "사용자에게 분명히 Allow 정책이 붙어 있는데 왜 작업이 거부됐을까?" 같은 시나리오가 나오면, 답은 거의 항상 상위 SCP에 Deny가 있다 또는 권한 경계에서 막혔다입니다.

정책의 종류 — 어디에 붙느냐의 차이

정책은 누구(또는 무엇)에 붙이느냐에 따라 두 부류로 나뉩니다.

Identity 기반 정책은 사용자·그룹·역할에 붙여요. 다시 둘로 갈리는데 — 관리형(Managed) 정책(AWS가 만든 것이나 우리가 만든 것, 여러 엔터티에 재사용 가능)과 인라인(Inline) 정책(특정 엔터티 하나에 1:1로 직접 박힘, 그 엔터티가 사라지면 같이 사라짐)이 있어요. 일반적으로 관리형 정책을 쓰고, 인라인은 정말 그 한 엔터티에만 적용해야 하는 특수한 경우에만 사용합니다.

리소스 기반 정책은 리소스 자체에 붙입니다. S3 버킷 정책이 가장 대표적이고, Lambda·SQS·SNS·API Gateway 같은 서비스도 자기 리소스에 정책을 붙일 수 있어요. 이때는 Principal 키로 "누가 이 리소스에 접근할 수 있는가" 를 명시합니다. 이 점이 교차 계정 접근에서 결정적인데, 그 부분은 뒤 STS 단락에서 따로 풀게요.

Condition Key — 정책에 조건을 다는 도구

Condition 절에 들어가는 키들은 정말 많지만, 시험에서 마주치는 건 거의 정해져 있어요. 6개만 외워두면 됩니다.

Condition Key	사용 사례
aws:SourceIp	"사무실 IP 대역에서만 접근 허용"
aws:RequestedRegion	"특정 리전에서만 리소스 생성 허용"
ec2:ResourceTag	"특정 태그가 붙은 EC2만 Start/Stop 허용"
aws:PrincipalTag	요청 주체의 태그 기반 제어 (ABAC의 기반)
aws:MultiFactorAuthPresent	"MFA 인증 안 했으면 EC2 Terminate 거부"
aws:PrincipalOrgID	"Organizations 내 계정만 S3 접근 허용"

특히 마지막에서 두 번째인 aws:MultiFactorAuthPresent: false → Deny 패턴은 시험 단골이에요. 위험한 작업(Terminate·Delete)을 MFA 인증된 세션에서만 허용하는 표준 안전장치입니다. "MFA 인증 시에만 위험한 작업 허용" 시나리오가 나오면 이 키를 떠올리시면 돼요.

MFA — 비밀번호 한 번 새도 못 들어가게 하는 자물쇠

MFA(다중 요소 인증)는 비밀번호(아는 것) + 물리적 장치(소유한 것) 를 묶어 인증하는 방식입니다. 비밀번호 하나가 새도 두 번째 인증이 막아 줘요. 루트 계정과 관리자 권한 IAM 사용자에게는 사실상 필수입니다.

지원되는 장치 종류는 네 가지:

유형	예시
가상 MFA 앱	Google Authenticator, Authy (한 앱에 여러 계정 등록 가능)
U2F 보안 키	YubiKey (USB, 여러 계정 지원)
하드웨어 TOTP	Gemalto
GovCloud 전용	SurePassID 키 포브

사용자 한 명당 최대 8개까지 등록할 수 있고, 가상 MFA를 처음 설정할 때는 동기화 확인 차원에서 연속된 두 개의 코드를 입력하라고 합니다. 새 폰을 잃어버릴 경우를 대비해서 백업 장치를 등록해 두는 게 좋아요.

Access Key — 한 번 보여주고 사라집니다

CLI나 SDK로 AWS에 접근할 때 쓰는 게 액세스 키입니다. 두 부분으로 구성돼요 — Access Key ID(사용자명 역할)와 Secret Access Key(비밀번호 역할).

여기서 가장 중요한 룰 하나 — Secret Access Key는 생성 직후 단 한 번만 표시됩니다. 그 화면을 닫으면 다시는 볼 수 없어요. 잃어버리면 기존 키를 삭제하고 새로 만드는 수밖에 없습니다.

당연한 결론으로:

• 키를 다른 사람과 공유하지 않습니다
• 코드에 하드코딩하지 않습니다
• 깃허브 같은 공개 레포에 절대 올리지 않습니다 (실제로 사고가 자주 나는 영역이에요)

시험에서 "EC2 안의 애플리케이션이 S3에 접근하려면 어떻게 해야 하나?"의 정답은 항상 IAM 역할(Instance Profile) 입니다. 액세스 키 하드코딩 보기는 무조건 오답.

콘솔 안에 내장된 AWS CloudShell도 알아두면 편합니다. 브라우저 기반 터미널인데 무료이고, 로그인한 계정의 IAM 권한을 자동 상속해서 aws configure를 따로 안 해도 돼요. 홈 디렉토리도 영구 보존돼서 세션 끝나도 파일이 살아있고요. 다만 모든 리전에서 쓸 수 있는 건 아니라는 점만 알아두면 됩니다.

STS와 AssumeRole — 임시 자격 증명의 정체

이제 IAM에서 가장 헷갈리는 부분 — STS와 AssumeRole입니다. 한 번에 이해되도록 천천히 풀어 갑니다.

STS(Security Token Service) 는 임시 자격 증명을 발급하는 서비스예요. 회사 비유로 치면 — 방문자 출입증 발급 데스크입니다. 외부에서 온 사람에게 "이 시간 동안만 유효한 출입증"을 만들어 주는 곳.

가장 많이 쓰는 API가 sts:AssumeRole인데, 흐름이 단순해요.

1. 사용자(또는 서비스)가 sts:AssumeRole을 호출하며 "이 역할을 빌려 쓰겠다"고 요청
2. STS가 임시 자격 증명 세트 — Access Key ID + Secret Access Key + Session Token — 를 돌려줌
3. 그 임시 자격 증명으로 대상 역할의 권한을 가진 채 작업
4. 정해진 시간이 지나면 자동 만료

여기서 정말 중요한 포인트가 하나 있어요. 역할을 수임(Assume)하는 순간 원래 자기 권한은 모두 포기됩니다. Alice가 EC2FullAccess 권한을 가지고 있다가 S3ReadOnly 역할을 수임하면, 그 세션 동안 Alice는 S3ReadOnly만 됩니다. EC2를 만들 수 없어요.

비유하자면 — Alice의 직원증을 데스크에 맡기고 방문자 출입증을 받는 거예요. 방문자 출입증으로는 정해진 곳만 갈 수 있고, 자기 원래 직원증의 권한은 그 동안 못 씁니다.

이 특성 때문에 교차 계정 접근에서 결정적인 차이가 생깁니다. 시험 단골이라 천천히 풀게요.

A 계정에서 DynamoDB를 읽고, 그 데이터를 B 계정 S3에 써야 하는 작업을 생각해 봅시다. 만약 AssumeRole로 B 계정 역할을 수임한다면? — 그 순간 A 계정 DynamoDB 권한이 사라져요. 동시에 두 계정 권한이 필요한 시나리오에서는 AssumeRole로 못 풉니다.

리소스 기반 정책으로 풀어야 합니다. B 계정 S3 버킷의 버킷 정책에서 "A 계정의 이 사용자에게 PutObject 허용"을 명시하면, A 계정 사용자는 자기 권한을 그대로 유지하면서 B 계정 S3에 쓸 수 있어요.

방법	원래 권한 유지 여부	사용 사례
IAM 역할 수임 (AssumeRole)	포기	단순 교차 계정 작업
리소스 기반 정책	유지	A 계정 DynamoDB 읽기 + B 계정 S3 쓰기처럼 두 계정 권한 동시 필요

시험에 "동시에 두 계정의 리소스에 접근해야 한다"는 시나리오가 나오면 답은 무조건 리소스 기반 정책입니다.

추가로 EventBridge가 이벤트를 다른 서비스로 보낼 때도 두 방식을 섞어 써요. 이 표는 그대로 외워둘 가치가 있습니다.

권한 방식	대상 서비스
리소스 기반 정책	Lambda, SNS, SQS, S3, API Gateway
IAM 역할	Kinesis Data Streams, EC2 Auto Scaling, SSM Run Command, ECS Task

Permission Boundary — 권한의 천장을 정한다

권한 경계(Permission Boundary) 는 처음 들으면 헷갈리는 개념인데, 한 줄로 풀면 "이 사용자/역할이 가질 수 있는 최대 권한의 천장" 입니다.

회사 비유로 — 신입 매니저에게 부서장이 "이 권한 안에서만 일할 수 있어"라고 정해 둔 한도예요. 신입 매니저가 자기 부하 직원에게 권한을 부여할 수 있지만, 자기 한도를 넘는 권한을 만들 수는 없게 막는 거죠.

권한 경계 자체는 권한을 부여하지 않습니다. Identity 기반 정책과 권한 경계의 교집합이 실제 유효 권한이에요. 예를 들어:

• Identity 기반 정책: EC2FullAccess + S3FullAccess
• 권한 경계: S3FullAccess + RDSFullAccess
• 실제 유효 권한: 교집합인 S3FullAccess만

EC2와 RDS 권한은 둘 다 한쪽에만 있고 교집합이 아니라서 빠져요.

언제 쓰느냐 — 시니어 개발자에게 IAM 사용자/역할을 만들 권한을 위임할 때, 그 사람들이 자기 자신에게 슈퍼 권한을 부여하지 못하게 막을 때 사용합니다. 이걸 권한 상승(Privilege Escalation) 방지라고 불러요.

또 하나 시험 함정 — 권한 경계는 사용자와 역할에만 붙고 그룹에는 못 붙습니다. 그룹에 붙이려는 보기는 항상 오답이에요.

IAM 보안 도구 — Credential Report와 Access Advisor

이 둘이 시험에서 헷갈리는 단골 페어입니다. 짝을 지어 외우면 한 번에 끝나요.

Credential Report 는 계정 수준 도구입니다. 계정 안 모든 사용자의 자격 증명 상태(MFA 활성화 여부, 비밀번호 마지막 변경, 액세스 키 사용 이력 등)를 한 번에 CSV로 뽑아 줍니다. 회사로 치면 전 직원 보안 점검 보고서예요. "전 사용자의 MFA 적용 여부를 감사하라" 같은 시나리오의 정답이 이쪽입니다.

Access Advisor 는 사용자 수준 도구입니다. 특정 사용자/역할/그룹이 어떤 서비스에 마지막으로 접근했는지 보여 줘요. 회사로 치면 개별 직원의 출입 기록입니다. "이 사용자에게 부여한 권한 중 실제로 사용되지 않는 것을 찾아 제거하라" — 즉 최소 권한 원칙 적용의 정답이 이쪽이에요.

> 한 줄 암기 — Credential = 계정 전체 보안 감사 / Access Advisor = 사용자별 최소 권한 진단.

AWS Organizations와 SCP — 회사 전체를 한 번에 통제

회사가 커지면 AWS 계정이 여러 개로 늘어납니다 — 개발 계정, 스테이징 계정, 프로덕션 계정, 결제 전용 계정 같이 분리해 두는 게 일반적이에요. 이걸 한 곳에서 묶어 관리하는 게 AWS Organizations 입니다.

조직에는 관리 계정(Management Account) 하나(조직 생성·결제 담당)와 여러 멤버 계정(Member Accounts) 이 있어요. 한 AWS 계정은 오직 하나의 조직에만 속할 수 있습니다.

계정을 그룹화하는 단위로 OU(Organizational Unit) 가 있고, OU 안에 OU를 중첩할 수도 있어요. 예를 들어 Root → Prod OU → Finance OU 처럼.

장점은 — 통합 결제(Consolidated Billing) 로 여러 계정 청구서를 묶어 볼륨 할인 받기, Reserved Instance / Savings Plans 할인 조직 전체 공유, CloudTrail 중앙화, 태깅 표준 강제, 새 계정 자동 생성까지.

SCP — 멤버 계정에 거는 상한선

여기서 시험 단골 주제 — SCP(Service Control Policies) 입니다. SCP는 OU나 멤버 계정에 적용해서 "이 계정에서는 이 작업을 못 한다" 는 상한선을 거는 정책이에요.

핵심 특징 네 가지:

• 관리 계정에는 SCP가 절대 적용되지 않습니다 (안전장치 — 관리 계정마저 막히면 복구 불가)
• SCP가 걸린 멤버 계정은 루트 사용자조차도 그 제한을 받아요 (이게 IAM Policy와의 결정적 차이)
• 상위 OU의 Deny는 하위 계정에서 Allow로 뒤집을 수 없어요
• 기본은 FullAWSAccess SCP라 따로 안 만지면 모든 권한 허용

활용 패턴은 두 가지입니다.

방식	설명
차단 목록(Blocklist)	모든 것 허용 + 특정 서비스만 Deny
허용 목록(Allowlist)	특정 서비스만 명시적 Allow + 나머지 차단

조직 전체에 태그 표준을 강제할 때는 태그 정책(Tag Policies) 을 써요. 다만 함정 — 태그 정책은 태그가 없는(Untagged) 리소스 생성 자체를 차단하지 않습니다. 태그를 달 때 어떤 키/값을 써야 하는지만 강제해요. 태그 없이 만들면 그냥 통과되는데, 비규격 태그가 발견되면 EventBridge로 알림을 받아 사후 처리하는 게 일반적입니다.

Permission Boundary vs SCP 비교 — 시험 단골

이 둘이 헷갈리지 않게 표로 정리해 둡니다.

비교	Permission Boundary	SCP
적용 대상	개별 IAM 사용자/역할	OU 또는 계정 전체
그룹 적용	불가	(OU 단위 가능)
루트 사용자 제한	불가	가능
주요 목적	사용자 권한 상승 방지	계정/OU 단위 서비스 사용 제한

특정 사용자 한 명만 제한 = Permission Boundary, 계정 전체나 OU 단위로 제한 = SCP. 이걸로 80%는 풀려요.

IAM Identity Center — 통합 로그인의 표준

조직 안에서 사용자가 여러 AWS 계정에 들어가야 하는데, 계정마다 IAM 사용자를 따로 만들고 비밀번호를 따로 관리하면 — 정말 끔찍합니다. 30개 계정에 사용자 30명이면 IAM 사용자가 900개가 돼요. 이걸 해결하는 게 IAM Identity Center(옛 AWS SSO) 입니다.

한 번 로그인하면 여러 AWS 계정과 외부 비즈니스 앱(Salesforce·Office 365 등)에 자동으로 접근할 수 있고, SAML 2.0 도 지원해요. Organizations 관리 계정에 설정해서 전체 OU를 관리하는 식이고요.

자격 증명 공급자(IdP)는 두 가지 방식:

• 기본 제공되는 IAM Identity Center Store
• 외부 IdP 연결 — Microsoft Active Directory · Okta · OneLogin

핵심 구성 요소가 권한 세트(Permission Set) 입니다. IAM 정책 모음을 권한 세트로 정의해 두고, "이 사용자/그룹이 이 AWS 계정에서는 이 권한 세트를 쓴다"고 매핑해요. 사용자가 포털에서 로그인하면 해당 계정에 자동으로 IAM 역할이 생성되고 수임됩니다.

ABAC — 속성 기반 접근 제어

여기서 함께 등장하는 게 ABAC(Attribute-Based Access Control) 입니다.

> ABAC — 사용자 속성(부서·직함·비용 센터 등) 기반의 세분화된 접근 제어. 권한 세트를 한 번 정의해 두고, 사용자 속성값만 바꿔도 접근 권한이 자동 조정돼요. 사용자가 부서 이동할 때 정책을 다시 만들 필요가 없습니다.

회사 비유로 — "마케팅팀이라는 태그가 붙은 사람만 광고 데이터에 접근" 같은 규칙을 한 번 만들어 두면, 새로 들어온 사람에게 마케팅팀 태그만 붙이면 자동으로 권한이 생기는 식이에요.

시험 키워드 정리:

• "여러 AWS 계정 + SAML 2.0 단일 로그인" → IAM Identity Center
• "Active Directory/Okta 연동" → IAM Identity Center
• "사용자 속성 기반 접근 제어" → ABAC
• 핵심 구성 요소 → 권한 세트(Permission Sets)

Directory Service — Active Directory 통합 3가지

기업 환경에서 이미 Microsoft Active Directory를 쓰고 있다면, AWS와 어떻게 통합할지가 문제가 됩니다. AWS Directory Service에는 세 가지 옵션이 있어요. 더 자세한 옵션과 제약 조건은 IAM 사용자 가이드 에 잘 정리돼 있고, 여기서는 비교표로 한 번 정리하고 키워드로 외워 둡시다.

서비스	특징	사용 사례
AWS Managed Microsoft AD	실제 Microsoft AD를 AWS에 생성. 온프레미스 AD와 양방향 트러스트(Trust) 가능, MFA 지원	온프레↔AWS 사용자 양방향 공유
AD Connector	인증 요청을 온프레미스 AD로 프록시(전달). 클라우드에 사용자 정보 미저장	"자격 증명을 클라우드에 저장하면 안 됨" 같은 보안 요구사항
Simple AD	Samba 4 기반 AD 호환 독립 실행형. 온프레미스 연결 불가	온프레미스 AD 없이 가벼운 AD가 필요할 때

키워드 매칭으로 외우는 게 가장 빨라요.

• "신뢰 관계(Trust) + 양방향 사용자 공유" → AWS Managed Microsoft AD
• "클라우드에 자격 증명 저장 금지 + 프록시" → AD Connector
• "온프레미스 AD 없음 + 독립형" → Simple AD

AWS Control Tower — 다중 계정 자동 설정

회사 단위로 새 AWS 계정을 매번 만들 때 보안 기준·로깅·SCP를 일일이 수동으로 설정하면 일관성이 떨어지고 누락이 생기기 마련입니다. Control Tower 는 모범 사례 기반의 다중 계정 환경을 빠르게 설정·관리해 주는 서비스예요. 내부적으로 Organizations·Config·SNS·Lambda를 오케스트레이션하고, 중앙 대시보드로 모든 계정의 규정 준수 상태를 한 번에 봅니다.

여기서 등장하는 게 가드레일(Guardrails) 인데, 두 부류로 나뉘어요.

구분	예방적 가드레일	탐지적 가드레일
목적	정책 위반 사전 차단	정책 위반 사후 탐지·알림
사용 기술	SCP (Organizations)	AWS Config
예시	특정 리전 외 리소스 생성 차단	태그 없는 리소스 식별
대응	즉시 Deny	SNS 알림 또는 Lambda 자동 수정

시험 키워드 — "사전 차단" → 예방적(SCP), "사후 탐지 + 자동 수정" → 탐지적(Config), "다중 계정 자동 설정 + 대시보드" → Control Tower.

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 IAM 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요. 이 부분만 시험 전날 한 번 더 읽으면 거의 다 떠오릅니다.

• IAM은 글로벌 서비스 (리전 드롭다운 비활성)
• 글로벌 서비스 4총사 = IAM · Route 53 · CloudFront · WAF
• 루트는 일상 작업 X, MFA 필수, 삭제 불가
• 그룹에는 사용자만 들어감 — 그룹 중첩 불가
• IAM 사용자 기본 = Default Deny (아무 권한 없음으로 시작)
• 정책 평가 — 명시적 Deny > 명시적 Allow > 암묵적 Deny
• S3 ARN — ListBucket은 bucket-name(버킷), GetObject는 bucket-name/*(객체)
• 액세스 키 = 생성 시 단 한 번만 표시, 코드에 하드코딩 X, EC2는 Instance Profile
• AssumeRole = 원래 권한 포기 / 리소스 기반 정책 = 원래 권한 유지
• "두 계정 동시 권한 필요" → 리소스 기반 정책
• Permission Boundary = 사용자/역할에만 (그룹 X), 유효 권한 = Identity 정책 ∩ 경계
• Credential Report = 계정 전체 감사 / Access Advisor = 사용자 최소 권한 진단
• SCP는 관리 계정에 적용 안 됨, 멤버 계정 루트도 제한, 상위 Deny는 하위에서 못 풂
• 태그 정책 = 태그 없는 리소스 생성은 차단하지 않음
• 여러 계정 + SAML 단일 로그인 = IAM Identity Center + 핵심은 권한 세트
• 사용자 속성 기반 = ABAC (aws:PrincipalTag)
• 양방향 트러스트 = AWS Managed Microsoft AD / 프록시 = AD Connector / 독립형 = Simple AD
• 사전 차단 = 예방적 가드레일(SCP) / 사후 탐지 = 탐지적 가드레일(Config)

여기까지가 SAA-C03 시험의 첫 단원 IAM의 전부예요. 노트로 보면 단순해 보이지만, 실제 문제를 풀 때마다 "그래서 SCP에서 막힌 건지, 권한 경계에서 막힌 건지, 리소스 기반 정책이 비어 있는 건지" 헷갈리기 쉬운 영역입니다. 한두 번 정독으로 끝내지 말고, 표를 직접 손으로 다시 그려보면서 머리에 새겨두면 다음 단원부터 훨씬 편해집니다.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — IAM (현재 글)
• 2편 — EC2 / Storage
• 3편 — ELB · ASG
• 4편 — S3 (스토리지)
• 5편 — Databases
• 6편 — Networking
• 7편 — Messaging
• 8편 — Containers · Serverless
• 9편 — Monitoring
• 10편 — Analytics · ML
• 11편 — Security
• 12편 — DR · Migration
• 13편 — Architectures
• 14편 — Exam Prep (완)