SAA-C03에서 보안은 전체의 약 30%를 차지합니다. 그 중에서도 "누가 무엇에 접근할 수 있는가"를 설계하는 것이 첫 번째 과제입니다. IAM을 단순한 사용자 관리 도구로 생각하면 시험에서 틀립니다. IAM은 AWS 전체를 관통하는 보안 심장입니다.
IAM이란 무엇인가요?
건물 보안 시스템에 비유해 봅시다. 회사 건물에 들어가려면 출입증이 있어야 합니다. 출입증마다 "1층 카페는 OK, 3층 서버실은 금지"처럼 접근 범위가 달라집니다. AWS IAM이 바로 이런 역할을 합니다.
IAM(Identity and Access Management)은 AWS 리소스에 대한 접근을 제어하는 서비스입니다. "이 사람(또는 서비스)이 이 자원에 이런 행동을 할 수 있는가?"를 결정합니다.
IAM에는 네 가지 주요 구성 요소가 있습니다:
사용자(User): 실제 사람 한 명을 나타냅니다. 개인 출입증과 같습니다. 그룹(Group): 여러 사용자를 묶는 부서 개념입니다. "개발팀" 그룹에 권한을 주면 팀원 모두가 그 권한을 얻습니다. 역할(Role): 사람이 아닌 서비스나 애플리케이션에 부여하는 임시 출입증입니다. EC2 서버가 S3에 접근해야 할 때 역할을 사용합니다. 정책(Policy): 실제 권한 내용이 담긴 JSON 문서입니다. "S3 버킷 읽기 허용"처럼 구체적인 규칙입니다.
IAM 정책의 네 가지 종류
정책은 어디에 "붙이느냐"에 따라 종류가 달라집니다.
자격 증명 기반 정책은 사용자·그룹·역할에 직접 붙이는 권한입니다. "이 직원은 S3를 읽을 수 있다"처럼 사람이나 역할에 권한을 부여합니다.
리소스 기반 정책은 반대로 자원에 붙이는 정책입니다. S3 버킷 정책이 대표적입니다. "이 버킷은 특정 계정의 사용자만 접근 가능"처럼 자원 쪽에서 접근 규칙을 정합니다.
권한 경계(Permission Boundary)는 출입증의 최대 범위를 제한하는 장치입니다. 아무리 많은 권한을 받아도 권한 경계가 허용하는 범위를 넘을 수 없습니다.
SCP(Service Control Policy)는 건물 전체에 적용되는 마스터 규칙입니다. AWS Organizations에서 하위 계정 전체에 적용됩니다. SCP가 막으면 IAM에서 아무리 허용해도 접근이 불가능합니다.
!IAM 정책 4가지 유형
정책 평가 로직 — 어떤 순서로 판단할까요?
AWS는 접근 요청이 들어오면 이 순서로 판단합니다:
1단계: 명시적 거부(Explicit Deny)가 있으면 즉시 차단합니다. 어떤 허용이 있어도 무조건 거부입니다.
2단계: 명시적 허용(Explicit Allow)이 있으면 접근을 허용합니다.
3단계: 위 두 가지 모두 없으면 기본 거부(Implicit Deny)입니다. AWS는 기본적으로 모든 것을 막습니다.
핵심: 명시적 Deny는 어떤 Allow보다 항상 우선합니다.
멀티 계정 관리 — AWS Organizations
대기업은 개발, 운영, 보안, 재무 등 여러 AWS 계정을 운영합니다. AWS Organizations는 이 계정들을 하나의 조직으로 묶어 관리하는 서비스입니다.
OU(Organizational Unit)는 부서처럼 계정을 그룹으로 묶는 단위입니다. "개발 OU", "운영 OU"처럼 용도별로 나눕니다.
SCP는 이 OU나 개별 계정에 적용하는 최대 권한 제한입니다. 예를 들어 "개발 계정에서는 프로덕션 데이터베이스 삭제 명령 자체를 막겠다"고 설정하면, 그 계정의 어떤 IAM 사용자도 그 작업을 할 수 없습니다.
AWS Control Tower는 Organizations를 기반으로 여러 계정 환경을 모범 사례에 따라 자동으로 설정해주는 서비스입니다. 가드레일(필수/권고 규칙)을 통해 조직 전체의 거버넌스를 유지합니다.
크로스 계정 접근 — STS AssumeRole
A 계정의 Lambda 함수가 B 계정의 S3 버킷에 접근해야 한다면 어떻게 할까요? 이때 사용하는 것이 크로스 계정 역할과 STS(Security Token Service)입니다.
과정은 이렇습니다:
1단계: 리소스가 있는 B 계정에 IAM 역할을 만들고, 신뢰 정책에 "A 계정에서 이 역할을 사용할 수 있다"고 명시합니다.
2단계: A 계정의 Lambda가 STS AssumeRole을 호출하여 임시 자격 증명(15분~36시간)을 받습니다.
3단계: 그 임시 자격 증명으로 B 계정의 S3에 접근합니다.
임시 자격 증명은 만료되면 자동으로 사라지므로, 영구 키를 공유하는 것보다 훨씬 안전합니다.
연합 인증 — 외부 로그인 연동
회사 직원이 매번 AWS 콘솔에 별도 로그인하는 것은 번거롭습니다. 이미 회사 Active Directory 계정이 있다면, 그걸로 AWS에도 로그인할 수 있습니다. 이것이 연합 인증(Federation)입니다.
IAM Identity Center(구 AWS SSO)는 여러 AWS 계정에 단일 로그인을 제공합니다. Microsoft Active Directory, Google Workspace 등 외부 IdP와 연동합니다.
Amazon Cognito는 모바일·웹 앱의 사용자 인증을 담당합니다. User Pools는 사용자 가입·로그인을 관리하고, Identity Pools는 인증된 사용자에게 AWS 리소스 접근 권한을 부여합니다.
시험 핵심 정리
"최소 권한 원칙" — 모든 접근 설계의 기본 원칙, 필요한 것만 허용
"하위 계정에서 특정 서비스 사용 금지" — SCP (IAM을 아무리 허용해도 SCP가 막으면 불가)
"SCP와 IAM 정책이 모두 허용해야 접근 가능" — 정책 교차 평가
"다른 계정의 리소스에 접근" — 크로스 계정 역할 + STS AssumeRole
"여러 계정 SSO" — IAM Identity Center
"모바일/웹 앱 사용자 인증" — Amazon Cognito
"EC2가 S3에 접근해야 할 때" — IAM 역할 (인스턴스 프로파일), 절대 액세스 키 하드코딩 금지
"IAM 사용자의 최대 권한 한도" — 권한 경계 (Permission Boundary)
명시적 Deny는 어떤 Allow보다 항상 우선한다