1. AWS STS (Security Token Service)
🤔 STS가 뭔가요?
비유로 이해하기: STS는 임시 출입증 발급 창구입니다.
- 영구 사원증(Access Key) 대신
- 필요할 때만 임시 출입증(Credentials) 발급
- 유효 기간: 15분 ~ 1시간
STS 핵심 API
┌─────────────────────────────────────────────────────────────────┐
│ AWS STS API │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AssumeRole │ │
│ │ • 가장 많이 사용! │ │
│ │ • 같은 계정 또는 다른 계정의 Role 가정 │ │
│ │ • 임시 자격 증명 반환 (15분 ~ 1시간) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AssumeRoleWithSAML │ │
│ │ • SAML로 로그인한 사용자용 │ │
│ │ • 기업 IdP (Okta, AD FS 등) 연동 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AssumeRoleWithWebIdentity │ │
│ │ • 소셜 로그인 (Google, Facebook...) 사용자용 │ │
│ │ • ⚠️ Cognito Identity Pools 사용 권장! │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ GetSessionToken │ │
│ │ • MFA가 필요한 경우 사용 │ │
│ │ • Root 또는 IAM User의 MFA 인증 후 토큰 발급 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ GetCallerIdentity │ │
│ │ • "나 누구야?" 확인용 │ │
│ │ • 현재 자격 증명의 User/Role 정보 반환 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ DecodeAuthorizationMessage │ │
│ │ • API 거부 시 에러 메시지 디코딩 │ │
│ │ • "왜 거부됐는지" 상세 정보 확인 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘STS API 요약
| API | 용도 | 비고 |
|---|---|---|
| AssumeRole | Role 가정 (같은/다른 계정) | 가장 많이 사용 |
| AssumeRoleWithSAML | SAML IdP 사용자 | 기업 SSO |
| AssumeRoleWithWebIdentity | 소셜 로그인 | Cognito 권장 |
| GetSessionToken | MFA 후 토큰 발급 | User/Root용 |
| GetFederationToken | 연합 사용자 토큰 | - |
| GetCallerIdentity | 현재 자격 증명 확인 | 디버깅용 |
| DecodeAuthorizationMessage | 거부 메시지 디코딩 | 디버깅용 |
2. AssumeRole 상세
🤔 AssumeRole이 뭔가요?
비유로 이해하기: 대리 역할 맡기입니다.
- "오늘 하루 팀장님 대신 결재해주세요" (임시 권한 위임)
- 본인 권한이 아닌 Role의 권한으로 행동
AssumeRole 동작 흐름
┌─────────────────────────────────────────────────────────────────┐
│ AssumeRole 흐름 │
│ │
│ 1. IAM Role 정의 │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Role: S3AdminRole │ │
│ │ │ │
│ │ Trust Policy (누가 이 Role을 사용할 수 있나?): │ │
│ │ { │ │
│ │ "Principal": { │ │
│ │ "AWS": "arn:aws:iam::111111111111:user/Alice" │ │
│ │ }, │ │
│ │ "Action": "sts:AssumeRole" │ │
│ │ } │ │
│ │ │ │
│ │ Permission Policy (무엇을 할 수 있나?): │ │
│ │ { │ │
│ │ "Action": "s3:*", │ │
│ │ "Resource": "*" │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 2. STS AssumeRole API 호출 │
│ ┌─────────────────┐ │
│ │ Alice (IAM User)│ │
│ └────────┬────────┘ │
│ │ │
│ │ AssumeRole(RoleArn: S3AdminRole) │
│ ↓ │
│ ┌─────────────────┐ │
│ │ STS │ │
│ └────────┬────────┘ │
│ │ │
│ ↓ 임시 자격 증명 반환 │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ "AccessKeyId": "ASIA...", │ │
│ │ "SecretAccessKey": "wJalr...", │ │
│ │ "SessionToken": "FwoGZ...", │ │
│ │ "Expiration": "2024-01-15T12:00:00Z" ← 만료 시간 │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 3. 임시 자격 증명으로 AWS 리소스 접근 │
│ ┌─────────────────┐ │
│ │ Alice │ ── S3 Admin 권한으로 ──→ [S3 Bucket] │
│ │ (임시 자격 증명) │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Cross-Account Access (계정 간 접근)
┌─────────────────────────────────────────────────────────────────┐
│ Cross-Account AssumeRole │
│ │
│ Account A (111111111111) Account B (222222222222) │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ │ │ │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │ IAM User │ │ │ │ IAM Role │ │ │
│ │ │ (Alice) │──────────────→│ S3AdminRole │ │ │
│ │ └───────────────┘ │ STS │ └───────────────┘ │ │
│ │ │ Assume │ │ │ │
│ │ │ Role │ ↓ │ │
│ │ │ │ ┌───────────────┐ │ │
│ │ │ │ │ S3 Bucket │ │ │
│ │ │ │ │ (Private) │ │ │
│ │ │ │ └───────────────┘ │ │
│ │ │ │ │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
│ Trust Policy (Account B의 Role): │
│ { │
│ "Principal": { │
│ "AWS": "arn:aws:iam::111111111111:root" ← Account A 허용 │
│ }, │
│ "Action": "sts:AssumeRole" │
│ } │
│ │
└─────────────────────────────────────────────────────────────────┘AWS CLI 예시
# 1. AssumeRole로 임시 자격 증명 받기
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/S3AdminRole \
--role-session-name MySession
# 반환:
# {
# "Credentials": {
# "AccessKeyId": "ASIA...",
# "SecretAccessKey": "wJalr...",
# "SessionToken": "FwoGZ...",
# "Expiration": "2024-01-15T12:00:00Z"
# }
# }
# 2. 환경 변수로 설정
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=wJalr...
export AWS_SESSION_TOKEN=FwoGZ...
# 3. 이제 S3AdminRole 권한으로 S3 접근 가능!
aws s3 ls3. STS with MFA
🤔 MFA와 STS를 어떻게 함께 쓰나요?
GetSessionToken API 사용!
┌─────────────────────────────────────────────────────────────────┐
│ STS with MFA │
│ │
│ 시나리오: "민감한 작업은 MFA 인증 후에만 허용하고 싶어" │
│ │
│ 1. IAM Policy에 MFA 조건 추가 │
│ { │
│ "Version": "2012-10-17", │
│ "Statement": [ │
│ { │
│ "Effect": "Allow", │
│ "Action": "s3:DeleteObject", │
│ "Resource": "*", │
│ "Condition": { │
│ "Bool": { │
│ "aws:MultiFactorAuthPresent": "true" ← MFA 필수! │
│ } │
│ } │
│ } │
│ ] │
│ } │
│ │
│ 2. MFA 인증 후 GetSessionToken 호출 │
│ ┌─────────────────┐ │
│ │ IAM User │ │
│ │ + MFA Device │ │
│ └────────┬────────┘ │
│ │ │
│ │ GetSessionToken( │
│ │ SerialNumber: arn:aws:iam::111111:mfa/Alice, │
│ │ TokenCode: 123456 ← MFA 코드 │
│ │ ) │
│ ↓ │
│ ┌─────────────────┐ │
│ │ STS │ │
│ └────────┬────────┘ │
│ │ │
│ ↓ MFA 인증된 임시 자격 증명 │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AccessKeyId + SecretAccessKey + SessionToken │ │
│ │ + Expiration │ │
│ │ │ │
│ │ → 이 자격 증명은 aws:MultiFactorAuthPresent = true! │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 3. MFA 인증된 자격 증명으로 민감한 작업 수행 가능! │
│ │
└─────────────────────────────────────────────────────────────────┘AWS CLI 예시
# MFA 인증 후 세션 토큰 받기
aws sts get-session-token \
--serial-number arn:aws:iam::111111111111:mfa/Alice \
--token-code 1234564. IAM 정책 평가 로직
🤔 Allow와 Deny가 충돌하면?
정책 평가 순서
┌─────────────────────────────────────────────────────────────────┐
│ IAM 정책 평가 로직 │
│ │
│ 시작: 기본적으로 모든 것이 DENY │
│ │ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 1. 모든 적용 가능한 정책 수집 │ │
│ │ • IAM User 정책 │ │
│ │ • IAM Group 정책 │ │
│ │ • IAM Role 정책 │ │
│ │ • Resource 정책 (S3 Bucket Policy 등) │ │
│ │ • Permission Boundary │ │
│ │ • SCP (Organizations) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 2. Explicit DENY 있는가? │ │
│ │ │ │
│ │ YES → 즉시 DENY! (다른 건 볼 필요 없음) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ NO │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 3. Explicit ALLOW 있는가? │ │
│ │ │ │
│ │ YES → ALLOW! │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ NO │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 4. 기본값: DENY (Implicit Deny) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 핵심: Explicit DENY가 항상 이김! │
│ │
└─────────────────────────────────────────────────────────────────┘IAM Policy + S3 Bucket Policy 예시
┌─────────────────────────────────────────────────────────────────┐
│ 정책 조합 예시 │
│ │
│ 예시 1: IAM Allow + Bucket Policy 없음 │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ IAM Role Policy │ + │ S3 Bucket Policy │ = ✅ ALLOW │
│ │ Allow s3:* │ │ (없음) │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ 예시 2: IAM Allow + Bucket Policy Deny │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ IAM Role Policy │ + │ S3 Bucket Policy │ = ❌ DENY │
│ │ Allow s3:* │ │ Deny IAM Role │ │
│ └──────────────────┘ └──────────────────┘ │
│ → Explicit DENY가 이김! │
│ │
│ 예시 3: IAM 없음 + Bucket Policy Allow │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ IAM Role Policy │ + │ S3 Bucket Policy │ = ✅ ALLOW │
│ │ (S3 권한 없음) │ │ Allow IAM Role │ │
│ └──────────────────┘ └──────────────────┘ │
│ → 둘 중 하나라도 Allow면 OK (같은 계정 내) │
│ │
│ 예시 4: IAM Deny + Bucket Policy Allow │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ IAM Role Policy │ + │ S3 Bucket Policy │ = ❌ DENY │
│ │ Deny s3:* │ │ Allow IAM Role │ │
│ └──────────────────┘ └──────────────────┘ │
│ → Explicit DENY가 이김! │
│ │
└─────────────────────────────────────────────────────────────────┘5. Dynamic Policies (정책 변수)
🤔 사용자마다 다른 폴더에 접근하게 하려면?
비유로 이해하기: 개인 사물함과 같습니다.
- 각자 자기 사물함만 열 수 있음
- 사물함 번호 = 사용자 이름
정책 변수 사용
┌─────────────────────────────────────────────────────────────────┐
│ Dynamic Policy │
│ │
│ ❌ 나쁜 방법: 사용자마다 정책 생성 │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Alice 정책: │ │
│ │ Resource: "arn:aws:s3:::bucket/home/alice/*" │ │
│ │ │ │
│ │ Bob 정책: │ │
│ │ Resource: "arn:aws:s3:::bucket/home/bob/*" │ │
│ │ │ │
│ │ Charlie 정책: │ │
│ │ Resource: "arn:aws:s3:::bucket/home/charlie/*" │ │
│ │ │ │
│ │ → 사용자가 늘어날수록 정책도 늘어남! 😰 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ✅ 좋은 방법: 정책 변수 사용 │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ "Version": "2012-10-17", │ │
│ │ "Statement": [{ │ │
│ │ "Effect": "Allow", │ │
│ │ "Action": ["s3:GetObject", "s3:PutObject"], │ │
│ │ "Resource": [ │ │
│ │ "arn:aws:s3:::bucket/home/${aws:username}/*" │ │
│ │ ] ↑ │ │
│ │ }] │ │ │
│ │ } │ │ │
│ │ │ │ │
│ │ 정책 변수: 실행 시 사용자 이름으로 대체! │ │
│ │ Alice 접근 시: /home/alice/* │ │
│ │ Bob 접근 시: /home/bob/* │ │
│ │ │ │
│ │ → 하나의 정책으로 모든 사용자 커버! 😊 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘주요 정책 변수
| 변수 | 설명 | 예시 |
|---|---|---|
${aws:username} | IAM 사용자 이름 | alice |
${aws:userid} | 사용자 ID | AIDAIOSFODNN7EXAMPLE |
${aws:PrincipalTag/key} | 사용자 태그 값 | department=engineering |
${cognito-identity.amazonaws.com:sub} | Cognito Identity ID | us-east-1:xxx |
6. Managed vs Inline Policies
정책 타입 비교
┌─────────────────────────────────────────────────────────────────┐
│ Policy Types │
│ │
│ 1. AWS Managed Policy (AWS 관리형) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ • AWS가 만들고 관리 │ │
│ │ • 예: AmazonS3ReadOnlyAccess, AdministratorAccess │ │
│ │ • 새 서비스/API 출시 시 자동 업데이트 │ │
│ │ • 직접 수정 불가 │ │
│ │ • 빠른 시작에 유용 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 2. Customer Managed Policy (고객 관리형) ← 권장! │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ • 직접 만들고 관리 │ │
│ │ • 여러 User/Group/Role에 재사용 가능 │ │
│ │ • 버전 관리 지원 (최대 5개 버전) │ │
│ │ • 롤백 가능 │ │
│ │ • 중앙에서 변경 관리 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 3. Inline Policy (인라인) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ • User/Group/Role에 직접 포함 │ │
│ │ • 1:1 관계 (해당 Principal에만 적용) │ │
│ │ • Principal 삭제 시 정책도 삭제됨 │ │
│ │ • 재사용 불가 │ │
│ │ • 특수한 경우에만 사용 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘정책 타입 선택
| 타입 | 용도 | 재사용 | 버전 관리 |
|---|---|---|---|
| AWS Managed | 빠른 시작, 일반적인 권한 | ✅ | AWS 관리 |
| Customer Managed | Best Practice, 세밀한 제어 | ✅ | ✅ |
| Inline | 특정 Principal 전용 | ❌ | ❌ |
7. IAM PassRole
🤔 PassRole이 뭔가요?
비유로 이해하기: 권한 위임 허가입니다.
- EC2에 Role을 붙이려면
- 먼저 "이 Role을 EC2에 줘도 돼?" 권한이 필요
PassRole 동작
┌─────────────────────────────────────────────────────────────────┐
│ iam:PassRole │
│ │
│ 시나리오: Alice가 EC2 인스턴스에 S3AdminRole을 붙이려 함 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Alice의 IAM Policy: │ │
│ │ │ │
│ │ { │ │
│ │ "Effect": "Allow", │ │
│ │ "Action": [ │ │
│ │ "ec2:RunInstances", ← EC2 생성 권한 │ │
│ │ "iam:PassRole" ← Role 전달 권한 (필수!) │ │
│ │ ], │ │
│ │ "Resource": [ │ │
│ │ "*", │ │
│ │ "arn:aws:iam::*:role/S3AdminRole" ← 이 Role만 │ │
│ │ ] │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────┐ PassRole ┌─────────────────┐ │
│ │ Alice │─────────────────→│ S3AdminRole │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ │ EC2 생성 + Role 연결 │ │
│ ↓ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ EC2 Instance │ │
│ │ (S3AdminRole 연결됨) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ⚠️ PassRole 없으면 EC2에 Role 연결 불가! │
│ │
└─────────────────────────────────────────────────────────────────┘Role의 Trust Policy
PassRole만으로는 부족!
Role의 Trust Policy에서 해당 서비스를 허용해야 함
EC2용 Role의 Trust Policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com" ← EC2만 이 Role 사용 가능!
},
"Action": "sts:AssumeRole"
}]
}
→ 이 Role은 EC2에만 전달(PassRole) 가능!
Lambda나 ECS에는 전달 불가8. AWS Directory Services
🤔 Directory Service가 뭔가요?
비유로 이해하기: 회사 직원 명부 + 인증 시스템입니다.
- Microsoft Active Directory를 AWS에서 사용
- 기업 사용자 관리, SSO, 그룹 정책 등
Active Directory 기본 개념
┌─────────────────────────────────────────────────────────────────┐
│ Active Directory (AD) │
│ │
│ Windows Server에서 제공하는 디렉토리 서비스 │
│ │
│ 저장하는 것들: │
│ ├─ 사용자 계정 (이름, 비밀번호) │
│ ├─ 컴퓨터 │
│ ├─ 프린터 │
│ ├─ 파일 공유 │
│ └─ 보안 그룹 │
│ │
│ 구조: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Forest (숲) │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ Domain Tree (트리) │ │ │
│ │ │ ┌─────────────────────────────────────────┐ │ │ │
│ │ │ │ Domain │ │ │ │
│ │ │ │ ┌───────┐ ┌───────┐ ┌───────────┐ │ │ │ │
│ │ │ │ │ Users │ │Groups │ │ Computers │ │ │ │ │
│ │ │ │ └───────┘ └───────┘ └───────────┘ │ │ │ │
│ │ │ └─────────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘AWS Directory Service 종류
┌─────────────────────────────────────────────────────────────────┐
│ AWS Directory Services │
│ │
│ 1. AWS Managed Microsoft AD │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ • AWS에서 실제 AD 운영 │ │
│ │ • 사용자를 AWS에서 직접 관리 │ │
│ │ • On-premise AD와 Trust 관계 설정 가능 │ │
│ │ • MFA 지원 │ │
│ │ │ │
│ │ 사용 사례: │ │
│ │ • AWS 리소스에 AD 인증 필요 │ │
│ │ • On-premise AD와 연동하면서 AWS에도 사용자 있음 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ On-premise AD ←──── Trust ────→ AWS Managed AD │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 2. AD Connector │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ • On-premise AD로 프록시 (리다이렉트) │ │
│ │ • AWS에 사용자 저장 안 함 │ │
│ │ • 인증 요청만 On-premise로 전달 │ │
│ │ • MFA 지원 │ │
│ │ │ │
│ │ 사용 사례: │ │
│ │ • 기존 On-premise AD 유지하면서 AWS 리소스 인증 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ On-premise AD ←──── Proxy ──── AD Connector │ │
│ │ (사용자 저장) (전달만) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 3. Simple AD │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ • AD 호환 (Samba 4 기반) │ │
│ │ • 저렴한 비용 │ │
│ │ • On-premise AD와 연결 불가! │ │
│ │ │ │
│ │ 사용 사례: │ │
│ │ • 간단한 AD 기능만 필요 (소규모) │ │
│ │ • On-premise AD 없음 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Directory Service 비교
| 서비스 | 사용자 저장 위치 | On-premise 연동 | 비용 |
|---|---|---|---|
| AWS Managed AD | AWS | Trust 관계 | 높음 |
| AD Connector | On-premise | Proxy | 중간 |
| Simple AD | AWS | ❌ 불가 | 낮음 |
9. IAM Best Practices 정리
일반 Best Practices
┌─────────────────────────────────────────────────────────────────┐
│ IAM Best Practices │
│ │
│ 🔐 보안 │
│ ├─ Root 계정 사용 금지, MFA 필수 │
│ ├─ 최소 권한 원칙 (절대 "*" 사용 금지!) │
│ ├─ IAM 자격 증명을 코드에 저장 금지 │
│ └─ On-premise 서버는 STS로 임시 자격 증명 사용 │
│ │
│ 🎭 Role 사용 │
│ ├─ EC2 → EC2 Instance Role │
│ ├─ Lambda → Lambda Execution Role │
│ ├─ ECS → ECS Task Role (ECS_ENABLE_TASK_IAM_ROLE=true) │
│ ├─ CodeBuild → Service Role │
│ └─ 서비스당 1개 Role (재사용 금지!) │
│ │
│ 📊 감사 │
│ ├─ CloudTrail로 API 호출 모니터링 │
│ ├─ 특히 Denied 호출 주시 │
│ ├─ IAM Credentials Report 정기 확인 │
│ └─ IAM Access Advisor로 미사용 권한 제거 │
│ │
│ 🔄 Cross-Account │
│ ├─ IAM Role + STS AssumeRole 사용 │
│ ├─ 자격 증명 공유 절대 금지! │
│ └─ 임시 자격 증명 (15분 ~ 1시간) │
│ │
└─────────────────────────────────────────────────────────────────┘핵심 요약
STS API
| API | 용도 |
|---|---|
| AssumeRole | Role 가정 (같은/다른 계정) |
| GetSessionToken | MFA 인증 후 토큰 |
| GetCallerIdentity | 현재 자격 증명 확인 |
정책 평가
Explicit DENY > Explicit ALLOW > Implicit DENY (기본값)정책 변수
| 변수 | 설명 |
|---|---|
${aws:username} | IAM 사용자 이름 |
${cognito-identity.amazonaws.com:sub} | Cognito Identity ID |
Directory Services
| 서비스 | On-premise 연동 |
|---|---|
| AWS Managed AD | Trust 관계 |
| AD Connector | Proxy |
| Simple AD | ❌ 불가 |