AWS Certified Solutions Architect - Associate (SAA-C03) #2 Domain 1-1 안전한 아키텍처: IAM 깊이
#1 시험 소개에서 SAA-C03의 네 도메인 중 보안이 30%로 가장 크다고 했습니다. 그 보안 도메인의 중심에 IAM이 있습니다. IAM은 단순히 “사용자를 만드는 곳"이 아니라, AWS의 모든 요청이 통과하는 인가(authorization) 계층입니다. 시험은 IAM을 “누가, 무엇에, 어떤 조건으로 접근하는가"라는 설계 문제로 변형해 묻습니다.
이 글은 CLF-C02의 IAM 기초 위에 Associate 수준의 깊이를 더합니다. User,Group,Role,Policy의 정의는 빠르게 지나가고, 정책 평가 로직,STS,교차 계정,권한 경계처럼 시험에서 정답을 가르는 지점에 시간을 씁니다.
IAM 네 구성요소 빠른 복습 #
| 구성요소 | 한 줄 정의 | 자격 증명 |
|---|---|---|
| User | 사람 또는 애플리케이션 하나에 대응하는 영구 신원 | 장기 자격 증명(비밀번호, 액세스 키) |
| Group | User의 묶음. 정책을 모아서 부여하는 단위 | 없음 |
| Role | 누구나 일시적으로 “맡을 수 있는” 신원 | 임시 자격 증명(STS 발급) |
| Policy | 권한을 정의한 JSON 문서 | 해당 없음 |
여기서 시험이 반복적으로 노리는 구분은 User와 Role의 자격 증명 차이입니다. User는 영구 액세스 키를 갖지만, Role은 자격 증명을 저장하지 않고 맡는 순간 STS가 임시 자격 증명을 발급합니다. “EC2에서 코드가 S3에 접근해야 한다"는 시나리오의 정답이 항상 “액세스 키를 심는다"가 아니라 “Role을 부여한다"인 이유가 여기에 있습니다.
IAM은 글로벌 서비스입니다. 리전을 선택하지 않으며, User,Role,Policy는 모든 리전에서 동일하게 보입니다.
정책(Policy)의 구조 #
IAM 정책은 JSON 문서이며, 핵심은 Statement 배열입니다. 각 Statement는 다음 요소로 구성됩니다.
- Effect.
Allow또는Deny - Action. 허용/거부할 API 동작 (예:
s3:GetObject) - Resource. 대상 리소스의 ARN
- Condition (선택). 적용 조건 (예: 특정 IP, MFA 사용 시, 특정 태그)
- Principal (리소스 기반 정책에서만). 누구에게 적용되는가
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"Bool": { "aws:MultiFactorAuthPresent": "true" }
}
}
]
}Condition은 SAA에서 자주 등장합니다. “MFA를 사용한 경우에만 허용”, “특정 VPC Endpoint를 통한 접근만 허용”, “특정 태그가 붙은 리소스만 제어” 같은 요구사항은 모두 Condition으로 표현됩니다.
Identity 기반 정책 vs Resource 기반 정책 #
| 구분 | Identity 기반 | Resource 기반 |
|---|---|---|
| 붙는 대상 | User / Group / Role | 리소스(S3 버킷, SQS 큐, KMS 키 등) |
| Principal 요소 | 없음 (이미 신원에 붙음) | 있음 (누구에게 허용할지 명시) |
| 대표 용도 | “이 사용자가 무엇을 할 수 있는가” | “이 리소스에 누가 접근할 수 있는가” |
| 교차 계정 | Role 위임 필요 | 직접 다른 계정 Principal 허용 가능 |
이 구분이 교차 계정 접근 문항의 핵심입니다. 다른 계정에 S3 접근을 주는 방법은 두 가지입니다. (1) 버킷 정책(리소스 기반)에 상대 계정 Principal을 직접 허용하거나, (2) 내 계정에 Role을 만들고 상대 계정이 AssumeRole 하도록 하는 방법입니다.
정책 평가 로직 (시험 단골) #
여러 정책이 동시에 걸릴 때 AWS가 허용/거부를 판단하는 순서는 시험에 거의 항상 나옵니다. 핵심 규칙은 세 가지입니다.
- 기본은 묵시적 거부(implicit deny). 아무 정책도 허용하지 않으면 거부됩니다.
- 명시적 허용(explicit Allow)이 있으면 허용. 단, 거부가 없을 때.
- 명시적 거부(explicit Deny)는 모든 허용을 이긴다. 어디선가 한 번이라도 Deny가 나오면 최종 결과는 거부입니다.
여기에 SCP(Service Control Policy), 권한 경계, 세션 정책이 끼면 평가가 더 복잡해집니다. 그러나 시험에서 외워야 하는 한 문장은 이것입니다.
명시적 Deny는 항상 최우선이다. 하나라도 Deny가 있으면 끝.
Role과 STS: 임시 자격 증명 #
Role은 자격 증명을 저장하지 않는 신원입니다. 누군가 Role을 “맡으면(assume)” AWS Security Token Service(STS)가 임시 자격 증명 세 쌍(액세스 키 ID, 시크릿 키, 세션 토큰)을 발급합니다. 이 자격 증명은 만료 시간이 있어, 유출되어도 피해가 제한됩니다.
신뢰 정책 vs 권한 정책 #
Role에는 서로 다른 두 정책이 붙습니다. 이 둘을 구분하지 못하면 교차 계정 문항에서 흔들립니다.
| 정책 | 질문 | 어디에 |
|---|---|---|
| 신뢰 정책 (Trust Policy) | 누가 이 Role을 맡을 수 있는가 | Role의 AssumeRolePolicyDocument |
| 권한 정책 (Permission Policy) | 이 Role이 무엇을 할 수 있는가 | Role에 attach된 정책 |
신뢰 정책의 Principal에 EC2 서비스가 들어가면 EC2 인스턴스가, 다른 계정 ID가 들어가면 그 계정의 신원이 Role을 맡을 수 있습니다.
AssumeRole의 대표 형태 #
- EC2 → Role (인스턴스 프로파일). EC2에 Role을 붙이면, 인스턴스 메타데이터로 임시 자격 증명이 자동 공급됩니다. 액세스 키를 코드나 인스턴스에 저장할 필요가 없습니다.
- Lambda 실행 역할. Lambda 함수가 다른 서비스에 접근할 때 사용하는 Role입니다.
- 교차 계정 AssumeRole. B 계정 사용자가 A 계정의 Role을 맡아 A의 리소스를 제어합니다.
- 웹 자격 증명 페더레이션(AssumeRoleWithWebIdentity). Cognito나 OIDC 공급자로 인증한 사용자에게 임시 자격 증명을 줍니다.
교차 계정 접근 설계 #
회사가 계정을 여러 개 운영하는 것은 SAA의 기본 전제입니다. 계정 간 접근을 설계하는 두 축을 정리합니다.
- Role 위임 방식. A 계정에 Role을 만들고 신뢰 정책에 B 계정을 넣습니다. B의 사용자는
sts:AssumeRole로 A의 Role을 맡아 A의 리소스를 제어합니다. 제어 권한이 여러 서비스에 걸칠 때 적합합니다. - 리소스 기반 정책 방식. S3 버킷 정책, KMS 키 정책처럼 리소스에 직접 다른 계정 Principal을 허용합니다. 단일 리소스를 공유할 때 간편합니다.
대규모로는 AWS Organizations + IAM Identity Center로 다계정 접근을 중앙에서 관리합니다. SCP는 Organizations 수준에서 **계정이 가질 수 있는 권한의 상한(guardrail)**을 정합니다. SCP는 권한을 부여하지 않고, 허용 가능한 범위를 제한만 한다는 점이 중요합니다.
권한 경계 (Permission Boundary) #
권한 경계는 한 IAM 신원이 가질 수 있는 최대 권한을 제한하는 정책입니다. SCP와 비슷하게 “상한"을 정하지만, 적용 단위가 다릅니다.
| 메커니즘 | 적용 단위 | 역할 |
|---|---|---|
| SCP | Organizations의 계정 / OU | 계정 전체의 권한 상한 |
| Permission Boundary | 개별 IAM User / Role | 그 신원의 권한 상한 |
| Identity 기반 정책 | User / Role | 실제 권한 부여 |
최종 권한은 부여된 정책과 상한(경계,SCP)의 교집합입니다. 예를 들어 관리자에게 권한을 위임하되 “IAM 사용자 생성은 권한 경계 안에서만” 같은 제약을 줄 때 사용합니다.
시험 출제 패턴 #
- “EC2의 애플리케이션이 S3에 접근해야 한다. 가장 안전한 방법은?” → IAM Role(인스턴스 프로파일). 액세스 키 저장 답안은 오답.
- “B 계정의 사용자가 A 계정 리소스를 제어해야 한다.” → A에 Role 생성 + 신뢰 정책에 B 허용 + B가 AssumeRole.
- “여러 정책이 충돌한다. 결과는?” → 명시적 Deny가 있으면 거부.
- “조직 전체에서 특정 리전 사용을 금지하라.” → SCP(권한 부여 아님, 상한 제한).
- “개발자에게 권한을 위임하되 한도를 두고 싶다.” → Permission Boundary.
- “모바일 앱 사용자에게 임시 AWS 접근을 주려면?” → Cognito / AssumeRoleWithWebIdentity(앱에 장기 키 배포 금지).
자주 만나는 함정 #
1) Role에 액세스 키가 있다고 생각 #
Role은 장기 액세스 키가 없습니다. 맡는 순간 STS가 임시 자격 증명을 발급할 뿐입니다.
2) SCP가 권한을 부여한다고 오해 #
SCP는 상한만 정합니다. SCP에 Allow가 있어도 IAM 정책에서 별도로 허용하지 않으면 권한이 없습니다.
3) 신뢰 정책과 권한 정책을 혼동 #
“누가 맡는가"는 신뢰 정책, “무엇을 하는가"는 권한 정책입니다. 교차 계정 문항에서 둘을 바꿔 적용하면 틀립니다.
4) 교차 계정에 IAM User를 복제 #
다른 계정 사용을 위해 그 계정에 User를 또 만드는 답안은 보통 오답입니다. Role 위임이 정석입니다.
5) EC2에 장기 키 저장 #
“코드에서 액세스 키를 환경변수로 읽는다” 류 답안은 SAA에서 거의 항상 오답입니다. Role을 쓰면 키 자체가 없습니다.
정리 #
이번 글에서 잡은 것:
- IAM은 글로벌 인가 계층. User는 영구 자격 증명, Role은 STS 임시 자격 증명
- 정책은 Effect,Action,Resource,Condition(+리소스 기반은 Principal). Condition으로 MFA,IP,태그 조건을 표현
- 평가 로직. 기본 거부, 명시적 Allow로 허용, 명시적 Deny가 모두를 이긴다
- Role에는 **신뢰 정책(누가 맡는가)**과 권한 정책(무엇을 하는가) 두 가지가 붙음
- 교차 계정. Role 위임(AssumeRole) 또는 리소스 기반 정책. 대규모는 Organizations + Identity Center
- 상한 메커니즘. SCP(계정 단위), Permission Boundary(신원 단위). 둘 다 부여가 아니라 제한
다음: Domain 1-2 KMS와 암호화 #
신원과 권한을 잡았으니, 다음은 데이터 자체를 보호하는 암호화입니다.
#3 Domain 1-2 KMS와 암호화에서는 KMS의 키 종류(AWS 관리형,고객 관리형,고객 제공), 봉투 암호화(envelope encryption)의 동작, at rest와 in transit 암호화의 차이, S3,EBS,RDS의 암호화 옵션, 그리고 키 정책과 교차 계정 키 공유까지 정리하겠습니다.