AWS IAM (Identity & Access Management) 정리
1. IAM 개요
🤔 IAM이 뭔가요?
비유로 이해하기: IAM은 AWS의 신분증 + 출입 권한 시스템입니다.
- 회사 건물 출입: 사원증(신분증) + 출입 권한(어느 층까지)
- AWS: IAM User(신분증) + IAM Policy(권한)
IAM = Identity and Access Management
┌─────────────────────────────────────────────────────────────────┐
│ IAM의 역할 │
│ │
│ Identity (신원) │
│ ├─ 누구인가? (Users, Groups, Roles) │
│ │ │
│ Access Management (접근 관리) │
│ └─ 뭘 할 수 있는가? (Policies) │
│ │
│ ⚠️ IAM은 Global 서비스! (리전과 무관하게 전체 적용) │
│ │
└─────────────────────────────────────────────────────────────────┘IAM 핵심 구성 요소
| 구성 요소 | 설명 | 비유 |
|---|---|---|
| Users | 실제 사람 | 사원증 |
| Groups | 사용자 모음 | 부서 |
| Roles | AWS 서비스용 권한 | 직책 (대리 역할) |
| Policies | 권한 정의 (JSON) | 출입 권한증 |
2. IAM Users & Groups
🤔 User와 Group이 뭔가요?
비유로 이해하기: 회사 조직도와 같습니다.
- User = 직원 (Alice, Bob, Charlie...)
- Group = 부서 (개발팀, 운영팀, 감사팀...)
Users (사용자)
┌─────────────────────────────────────────────────────────────────┐
│ IAM Users │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Alice │ │ Bob │ │ Charlie │ │ David │ │
│ │ (개발자) │ │ (개발자) │ │ (DevOps)│ │ (DevOps)│ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ 특징: │
│ • 실제 사람 1명 = IAM User 1개 │
│ • AWS Console 로그인용 비밀번호 │
│ • CLI/SDK용 Access Key │
│ │
└─────────────────────────────────────────────────────────────────┘Groups (그룹)
┌─────────────────────────────────────────────────────────────────┐
│ IAM Groups │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Developers Group │ │ Operations Group │ │
│ │ │ │ │ │
│ │ [Alice] [Bob] │ │ [Charlie] [David] │ │
│ │ │ │ │ │
│ │ 정책: EC2 읽기, │ │ 정책: EC2 전체, │ │
│ │ S3 읽기/쓰기 │ │ CloudWatch │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
│ ┌─────────────────────┐ │
│ │ Audit Team │ ← Charlie는 2개 그룹에 속함! │
│ │ │ │
│ │ [Charlie] │ │
│ │ │ │
│ │ 정책: 읽기 전용 │ │
│ └─────────────────────┘ │
│ │
│ ⚠️ 그룹에는 User만! (그룹 안에 그룹 불가) │
│ ⚠️ User는 그룹 없이도 존재 가능 │
│ ⚠️ User는 여러 그룹에 속할 수 있음 │
│ │
└─────────────────────────────────────────────────────────────────┘Root Account
⚠️ Root Account 주의사항!
Root Account = AWS 계정 생성 시 만들어지는 최초 계정
특징:
├─ 모든 권한을 가짐 (제한 불가!)
├─ 계정 삭제, 결제 변경 등 가능
└─ 매우 위험!
Best Practice:
├─ 일상 업무에 Root 사용 금지!
├─ Root에 MFA 필수 설정
├─ Root Access Key 만들지 말 것
└─ IAM User를 만들어서 사용3. IAM Policies
🤔 Policy가 뭔가요?
비유로 이해하기: 권한 명세서입니다.
- "이 사람은 서버실 출입 가능, 금고실 출입 불가"
- JSON 형식으로 "뭘 할 수 있는지" 정의
Policy 구조
{
"Version": "2012-10-17",
"Id": "S3-Account-Permissions",
"Statement": [
{
"Sid": "AllowS3Read",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/Alice"
},
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
"Condition": {
"IpAddress": {
"aws:SourceIp": "192.168.1.0/24"
}
}
}
]
}Policy 구성 요소
┌─────────────────────────────────────────────────────────────────┐
│ Policy 구조 분석 │
│ │
│ { │
│ "Version": "2012-10-17", ← 정책 언어 버전 (고정값) │
│ "Id": "...", ← 정책 ID (선택) │
│ "Statement": [...] ← 권한 명세 (필수!) │
│ } │
│ │
│ Statement 구성: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ "Sid": "...", ← Statement ID (선택) │ │
│ │ "Effect": "Allow", ← 허용/거부 (Allow/Deny) │ │
│ │ "Principal": {...}, ← 누구에게 (선택, 리소스 정책용) │ │
│ │ "Action": [...], ← 어떤 동작 (필수) │ │
│ │ "Resource": [...], ← 어떤 리소스에 (필수) │ │
│ │ "Condition": {...} ← 조건 (선택) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Policy 상세 설명
| 요소 | 설명 | 예시 |
|---|---|---|
| Version | 정책 언어 버전 | "2012-10-17" (항상 이 값) |
| Id | 정책 식별자 | 선택적 |
| Sid | Statement 식별자 | "AllowS3Read" |
| Effect | 허용/거부 | "Allow" 또는 "Deny" |
| Principal | 적용 대상 | User, Role, Account |
| Action | 허용/거부할 API | "s3:GetObject" |
| Resource | 대상 리소스 | "arn:aws:s3:::my-bucket/*" |
| Condition | 조건 | IP 주소, 시간 등 |
Policy 상속 예시
┌─────────────────────────────────────────────────────────────────┐
│ Policy 상속 │
│ │
│ Developers Group ──────── Policy A (EC2 읽기) │
│ │ │
│ ├── Alice ──────── Policy A (그룹에서 상속) │
│ │ + Policy C (개인 정책) │
│ │ │
│ └── Bob ────────── Policy A (그룹에서 상속) │
│ │
│ Operations Group ──────── Policy B (EC2 전체) │
│ │ │
│ └── Charlie ────── Policy B (그룹에서 상속) │
│ + Policy D (Inline 정책) │
│ │
│ 최종 권한 = 그룹 정책 + 개인 정책 + Inline 정책 │
│ │
└─────────────────────────────────────────────────────────────────┘최소 권한 원칙 (Least Privilege)
⚠️ AWS 보안의 핵심 원칙!
❌ 나쁜 예:
{
"Effect": "Allow",
"Action": "*", ← 모든 동작 허용
"Resource": "*" ← 모든 리소스에
}
✅ 좋은 예:
{
"Effect": "Allow",
"Action": [
"s3:GetObject", ← 필요한 동작만
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-bucket/*" ← 특정 버킷만
}
원칙: 필요한 최소한의 권한만 부여!4. IAM Roles
🤔 Role이 뭔가요?
비유로 이해하기: 대리 권한과 같습니다.
- 비서에게 "내 대신 회의실 예약해줘" (비서가 나의 권한으로 행동)
- EC2에게 "내 대신 S3에서 파일 가져와" (EC2가 Role의 권한으로 행동)
Role vs User
| 항목 | User | Role |
|---|---|---|
| 사용자 | 사람 | AWS 서비스, 애플리케이션 |
| 인증 | 비밀번호, Access Key | 임시 자격 증명 (STS) |
| 수명 | 영구 | 임시 (15분 ~ 12시간) |
Role 동작 방식
┌─────────────────────────────────────────────────────────────────┐
│ IAM Role 동작 │
│ │
│ 1. EC2 인스턴스가 S3에 접근하려면? │
│ │
│ ❌ 나쁜 방법: EC2에 Access Key 하드코딩 │
│ ┌─────────────────────────────────────────┐ │
│ │ EC2 │ │
│ │ ├─ Access Key: AKIA... (위험!) │ │
│ │ └─ Secret Key: xyz... │ │
│ └─────────────────────────────────────────┘ │
│ │
│ ✅ 좋은 방법: IAM Role 사용 │
│ ┌─────────────────────────────────────────┐ │
│ │ EC2 Instance │ │
│ │ │ │ │
│ │ │ IAM Role 연결 │ │
│ │ ↓ │ │
│ │ ┌─────────────────────┐ │ │
│ │ │ IAM Role │ │ │
│ │ │ (S3 읽기 권한) │ │ │
│ │ └─────────────────────┘ │ │
│ │ │ │ │
│ │ ↓ 임시 자격 증명 자동 발급 │ │
│ │ │ │
│ │ → S3 접근 가능! │ │
│ └─────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘자주 사용하는 Role
| Role | 용도 |
|---|---|
| EC2 Instance Role | EC2가 다른 AWS 서비스 접근 |
| Lambda Execution Role | Lambda가 다른 AWS 서비스 접근 |
| ECS Task Role | ECS 컨테이너가 AWS 서비스 접근 |
| CloudFormation Role | CloudFormation이 리소스 생성 |
| Cross-Account Role | 다른 AWS 계정에서 접근 |
Role 생성 예시
┌─────────────────────────────────────────────────────────────────┐
│ Lambda Execution Role │
│ │
│ Trust Policy (누가 이 Role을 사용할 수 있는가): │
│ { │
│ "Version": "2012-10-17", │
│ "Statement": [{ │
│ "Effect": "Allow", │
│ "Principal": { │
│ "Service": "lambda.amazonaws.com" ← Lambda만 사용 가능 │
│ }, │
│ "Action": "sts:AssumeRole" │
│ }] │
│ } │
│ │
│ Permission Policy (무엇을 할 수 있는가): │
│ { │
│ "Version": "2012-10-17", │
│ "Statement": [{ │
│ "Effect": "Allow", │
│ "Action": [ │
│ "dynamodb:PutItem", │
│ "dynamodb:GetItem" │
│ ], │
│ "Resource": "arn:aws:dynamodb:*:*:table/MyTable" │
│ }] │
│ } │
│ │
└─────────────────────────────────────────────────────────────────┘5. IAM Security
Password Policy (비밀번호 정책)
┌─────────────────────────────────────────────────────────────────┐
│ Password Policy 설정 │
│ │
│ ✅ 최소 길이: 8자 이상 │
│ ✅ 대문자 필수: A-Z │
│ ✅ 소문자 필수: a-z │
│ ✅ 숫자 필수: 0-9 │
│ ✅ 특수문자 필수: !@#$%^&* │
│ ✅ 비밀번호 만료: 90일 │
│ ✅ 재사용 방지: 최근 5개 비밀번호 재사용 금지 │
│ ✅ 본인 변경 허용: 사용자가 직접 비밀번호 변경 가능 │
│ │
└─────────────────────────────────────────────────────────────────┘MFA (Multi-Factor Authentication)
비유로 이해하기: 이중 잠금 장치입니다.
- 비밀번호만 = 열쇠 1개 (도난 시 위험)
- 비밀번호 + MFA = 열쇠 + 지문 인식 (둘 다 필요!)
┌─────────────────────────────────────────────────────────────────┐
│ MFA 인증 과정 │
│ │
│ 1. 비밀번호 입력 (Something you know) │
│ └─ "myP@ssw0rd!" │
│ │
│ 2. MFA 코드 입력 (Something you have) │
│ └─ "123456" (30초마다 변경) │
│ │
│ 3. 둘 다 맞으면 → 로그인 성공! │
│ │
│ 장점: 비밀번호가 유출되어도 계정 안전! │
│ │
└─────────────────────────────────────────────────────────────────┘MFA 디바이스 종류
| 종류 | 설명 | 예시 |
|---|---|---|
| Virtual MFA | 스마트폰 앱 | Google Authenticator, Authy |
| U2F Security Key | USB 보안 키 | YubiKey |
| Hardware MFA | 전용 하드웨어 | Gemalto |
추천: Virtual MFA (무료, 편리)
1. Google Authenticator 또는 Authy 설치
2. AWS Console → IAM → MFA 설정
3. QR 코드 스캔
4. 6자리 코드 2번 입력하여 등록 완료!6. AWS 접근 방법
3가지 접근 방법
┌─────────────────────────────────────────────────────────────────┐
│ AWS 접근 방법 │
│ │
│ 1. AWS Management Console (웹 브라우저) │
│ └─ 인증: 비밀번호 + MFA │
│ │
│ 2. AWS CLI (명령줄) │
│ └─ 인증: Access Key │
│ │
│ 3. AWS SDK (프로그래밍) │
│ └─ 인증: Access Key │
│ │
└─────────────────────────────────────────────────────────────────┘Access Key
┌─────────────────────────────────────────────────────────────────┐
│ Access Key 구조 │
│ │
│ Access Key ID: AKIASK4E37PV4983d6C │
│ ↑ │
│ username과 유사 │
│ │
│ Secret Access Key: AZPN3zojWozWCndIjhB0Unh8239a1bzbzO5fqqkZq │
│ ↑ │
│ password와 유사 (생성 시 1회만 표시!) │
│ │
│ ⚠️ 주의사항: │
│ • 절대 공유하지 말 것! │
│ • 코드에 하드코딩하지 말 것! │
│ • Git에 커밋하지 말 것! │
│ • 주기적으로 교체할 것! │
│ │
└─────────────────────────────────────────────────────────────────┘AWS CLI
# AWS CLI 설정
aws configure
AWS Access Key ID [None]: AKIASK4E37PV4983d6C
AWS Secret Access Key [None]: AZPN3zoj...
Default region name [None]: ap-northeast-2
Default output format [None]: json
# CLI 사용 예시
aws s3 ls # S3 버킷 목록
aws ec2 describe-instances # EC2 인스턴스 목록AWS SDK
// TypeScript/JavaScript 예시
import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";
// 자격 증명은 환경 변수 또는 IAM Role에서 자동 로드
const client = new S3Client({ region: "ap-northeast-2" });
const command = new ListBucketsCommand({});
const response = await client.send(command);
console.log(response.Buckets);SDK 자격 증명 우선순위:
1. 코드에 직접 지정 (비권장!)
2. 환경 변수 (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
3. ~/.aws/credentials 파일
4. IAM Role (EC2, Lambda 등) ← 권장!7. IAM Security Tools
IAM Credentials Report (계정 수준)
┌─────────────────────────────────────────────────────────────────┐
│ Credentials Report │
│ │
│ 전체 계정의 모든 사용자 보안 상태를 CSV로 다운로드 │
│ │
│ 포함 정보: │
│ ├─ User 이름 │
│ ├─ 비밀번호 사용 여부 / 마지막 사용 / 마지막 변경 │
│ ├─ MFA 활성화 여부 │
│ ├─ Access Key 활성화 여부 / 마지막 사용 / 마지막 교체 │
│ └─ 인증서 상태 │
│ │
│ 용도: │
│ • 보안 감사 │
│ • 미사용 계정 찾기 │
│ • MFA 미설정 사용자 찾기 │
│ • Access Key 교체 필요 여부 │
│ │
└─────────────────────────────────────────────────────────────────┘IAM Access Advisor (사용자 수준)
┌─────────────────────────────────────────────────────────────────┐
│ Access Advisor │
│ │
│ 특정 사용자가 어떤 서비스에 마지막으로 접근했는지 확인 │
│ │
│ 예시: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ User: Alice │ │
│ │ │ │
│ │ Service Last Accessed │ │
│ │ ─────────────────────────────────────────────────── │ │
│ │ Amazon S3 Today │ │
│ │ Amazon EC2 3 days ago │ │
│ │ Amazon RDS Never ← 불필요? │ │
│ │ AWS Lambda Never ← 불필요? │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 용도: │
│ • 사용하지 않는 권한 찾기 │
│ • 최소 권한 원칙 적용 │
│ • 불필요한 권한 제거 │
│ │
└─────────────────────────────────────────────────────────────────┘8. IAM Best Practices
✅ 해야 할 것
1. Root 계정 보호
├─ 일상 업무에 사용 금지
├─ MFA 활성화 필수
└─ Access Key 생성 금지
2. 사용자 관리
├─ 1명 = 1 IAM User
├─ 그룹으로 권한 관리
└─ 공유 계정 금지
3. 권한 관리
├─ 최소 권한 원칙
├─ IAM Role 사용 (EC2, Lambda)
└─ 주기적 권한 검토 (Access Advisor)
4. 보안 강화
├─ 강력한 비밀번호 정책
├─ MFA 의무화
└─ Access Key 주기적 교체
5. 감사
├─ Credentials Report 정기 확인
└─ CloudTrail로 API 호출 기록❌ 하지 말아야 할 것
1. Root 계정 일상 사용
2. Access Key를 코드에 하드코딩
3. Access Key를 Git에 커밋
4. IAM User/Access Key 공유
5. 과도한 권한 부여 (Admin 남발)
6. MFA 미설정
7. 비밀번호/Access Key 미교체9. Shared Responsibility Model
IAM에서의 책임 분담
┌─────────────────────────────────────────────────────────────────┐
│ Shared Responsibility │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AWS 책임 │ │
│ │ │ │
│ │ • 글로벌 인프라 보안 │ │
│ │ • IAM 서비스 자체의 보안 │ │
│ │ • 취약점 분석 및 패치 │ │
│ │ • 규정 준수 인증 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 고객 책임 │ │
│ │ │ │
│ │ • Users, Groups, Roles, Policies 관리 │ │
│ │ • MFA 활성화 │ │
│ │ • Access Key 관리 및 교체 │ │
│ │ • IAM 도구 활용 (Credentials Report, Access Advisor) │ │
│ │ • 접근 패턴 분석 및 권한 검토 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘핵심 요약
IAM 구성 요소
| 구성 요소 | 용도 | 인증 방법 |
|---|---|---|
| User | 사람 | 비밀번호, Access Key |
| Group | User 묶음 | - |
| Role | AWS 서비스 | 임시 자격 증명 |
| Policy | 권한 정의 | - |
Policy 핵심 요소
| 요소 | 필수 | 설명 |
|---|---|---|
| Effect | ✅ | Allow 또는 Deny |
| Action | ✅ | 어떤 동작 |
| Resource | ✅ | 어떤 리소스 |
| Condition | ❌ | 조건 |
보안 도구
| 도구 | 수준 | 용도 |
|---|---|---|
| Credentials Report | 계정 | 전체 사용자 보안 상태 |
| Access Advisor | 사용자 | 서비스 접근 기록 |