🔐 AWS IAM & 임시 자격증명
1️. AWS 보안의 출발점: 자격증명(Credentials)
AWS 보안의 핵심은 “누가 어떤 권한으로 얼마나 오래 접근하는가”
AWS에서 리소스에 접근하려면 반드시 자격증명이 필요하며,
이 자격증명은 크게 영구 자격증명과 임시 자격증명으로 나뉜다.
2️. 영구 자격증명 (Access Key Pair)
IAM User에 발급되는 장기 자격증명
구성
- Access Key ID
- Secret Access Key
특징
- IAM 사용자당 최대 2개
- 만료 개념 ❌
- 삭제하지 않는 한 계속 사용 가능
- CLI, SDK, 서버 애플리케이션에서 사용
⚠️ 보안 문제
- 코드 하드코딩
- GitHub 유출 사고 빈번
- 탈취 시 장기 악용 가능
3️. 임시 자격증명 (Temporary Credentials)
AWS STS(Security Token Service)가 발급하는 시간 제한 자격증명
핵심 특징
- 유효기간 존재 (15분 ~ 12시간)
- 자동 만료
- 필요할 때만 동적 생성
- 로테이션 관리 불필요
- 보안 사고 시 피해 범위 최소화
구성 요소
AWS_ACCESS_KEY_ID (ASIA…)
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
💡 Access Key ID가 ASIA로 시작하면 임시 자격증명
4️. AssumeRole 개념 (AWS 보안의 핵심 메커니즘)
권한을 “부여”받는 것이 아니라 “빌려서 쓰는 구조”
동작 흐름
- Identity(IAM User, 서비스, 외부 사용자)가 존재
- STS에
AssumeRole요청 - Role의 권한 + 제한 정책 적용
- 임시 자격증명 발급
- 해당 Role 권한으로 AWS 접근
Identity
↓ sts:AssumeRole
IAM Role
↓ Temporary Credentials
AWS Resource
5️. Role의 본질
권한은 사용자에 있지 않고 Role에 있다
- User / 서비스 / 외부 사용자 → Role을 Assume
- 동일 사용자라도 다른 Role을 입으면 다른 권한 획득
- 멀티 계정, 서버리스, EC2, 외부 연동의 핵심 구조
6️. IAM 정책(Policy)의 역할
IAM 정책은 “권한을 정의하는 문서”
정책의 본질
- 누가(Who)
- 무엇을(Action)
- 어디에(Resource)
- 어떤 조건에서(Condition)
- 허용/거부(Effect)
를 정의한 JSON 문서
7️. IAM 정책의 두 가지 큰 분류
👤 Identity-based Policy
IAM User / Group / Role에 부착
- 해당 자격증명이 무엇을 할 수 있는지 정의
- 가장 일반적인 정책
🪣 Resource-based Policy
리소스에 직접 부착
- 해당 리소스에 누가 접근 가능한지 정의
- Principal 필수
- 예: S3 Bucket Policy, KMS Key Policy
8️. “권한을 제한하는” 정책들 (중요)
권한을 늘리는 게 아니라 상한선을 만드는 정책
⏱ Session Policy
- AssumeRole 시 함께 전달
- 임시 자격증명의 권한을 추가로 제한
- Role 권한보다 넓어질 수 없음
🧱 Permissions Boundary
- IAM User / Role의 최대 권한 제한
- 실제 권한 = 정책 허용 ∩ Boundary 허용
🏢 SCP (Service Control Policy)
- AWS Organizations 단위 정책
- 계정 전체의 절대 권한 상한선
- Root 사용자도 예외 ❌
9️. IAM 권한 평가 규칙 (절대 중요)
IAM은 항상 보수적으로 판단
- 명시적 Deny → 무조건 거부
- Allow 없음 → 암시적 Deny
- Allow 존재 → 허용
- SCP / Boundary / Session Policy는 항상 상한선
10. IAM JSON 정책 구조
{
"Version":"2012-10-17",
"Statement":[ ...]
}Statement 하나 = 하나의 권한 규칙
1️1. Statement 구성 요소
| 요소 | 설명 |
|---|---|
| Sid | Statement 식별자 (선택) |
| Effect | Allow / Deny |
| Action | 수행 가능한 AWS API |
| Resource | 대상 리소스 ARN |
| Principal | 요청 주체 (리소스 기반 정책 전용) |
| Condition | 조건부 제어 |
1️2. Action / NotAction
Action
"Action":"s3:GetObject"NotAction
특정 Action만 제외하고 전부
"NotAction":"s3:DeleteBucket"1️3. Resource / NotResource
Resource
"Resource":"arn:aws:s3:::my-bucket/*"NotResource
특정 리소스만 제외
"NotResource":"arn:aws:s3:::critical-bucket/*"1️4. Condition (보안의 핵심 레버)
Condition을 쓰는 순간 정책의 정밀도가 달라진다
주요 유형
- String (Equals, Like)
- Numeric
- Date
- Bool
- IpAddress
- ArnEquals
- IfExists
예시: IP 제한
"Condition":{
"IpAddress":{
"aws:SourceIp":"203.0.113.0/24"
}
}1️5. Wildcard 사용 원칙
- : 모든 값
?: 한 글자- 편리하지만 과도하면 위험
💡 Wildcard는 초기엔 넓게, 운영 단계에선 점점 좁히는 전략이 현실적
1️6. 전체 흐름 정리
[ Identity ]
↓ AssumeRole
[ IAM Role ]
↓ (Identity Policy)
↓ (Session Policy)
↓ (Permissions Boundary)
↓ (SCP)
[ Temporary Credentials ]
↓
[ AWS Resource ]
최종 권한 = 모든 정책의 교집합
📌 핵심 요약
🔑 AWS 보안 설계의 정답은 “Role + 임시 자격증명”
- Access Key 직접 사용 ❌
- Role 중심 설계 ⭕
- 임시 자격증명 기본 사용 ⭕
- 정책은 “허용”보다 “제한”이 더 중요
- JSON 한 줄 한 줄이 실제 보안 규칙