AWS Certified Developer - Associate (DVA-C02) #7 Domain 2-1 보안: 인증과 인가
#6 SDK 개발 패턴에서 “프로덕션 자격 증명은 IAM Role"이라고 했습니다. 보안 도메인은 그 주제를 정면으로 다룹니다. DVA의 보안은 SAA처럼 거대한 네트워크 설계가 아니라, 애플리케이션이 자격 증명을 어떻게 얻고, 사용자를 어떻게 인증하고, 임시 권한을 어떻게 발급하는가라는 코드에 가까운 질문입니다.
먼저 인증(authentication)과 인가(authorization)를 구분합니다. **인증은 “너는 누구인가”, 인가는 “너는 무엇을 할 수 있는가”**입니다. Cognito는 주로 인증을, IAM은 인가를 담당합니다.
IAM Role을 개발자 관점에서 #
#6에서 본 대로, 코드가 AWS 서비스에 접근할 때는 장기 액세스 키를 저장하지 말고 IAM Role을 사용합니다. 실행 환경마다 Role을 공급하는 방식이 다릅니다.
| 실행 환경 | Role 공급 방식 |
|---|---|
| EC2 | 인스턴스 프로파일(Instance Profile) |
| ECS | 태스크 역할(Task Role) |
| Lambda | 실행 역할(Execution Role) |
| EKS 파드 | IRSA(서비스 계정용 IAM Role) |
이 Role들은 모두 STS가 발급한 임시 자격 증명을 코드에 자동 공급합니다. SDK 자격 증명 공급 체인이 이를 마지막 단계에서 집어 옵니다. “Lambda가 DynamoDB에 쓰려면?“의 답은 “실행 역할에 dynamodb:PutItem 권한을 준다"입니다.
STS: 임시 자격 증명 #
**Security Token Service(STS)**는 만료 시간이 있는 임시 자격 증명(액세스 키 ID,시크릿 키,세션 토큰)을 발급합니다. 유출돼도 피해가 제한됩니다.
AssumeRole. 다른 Role을 맡아 그 권한을 임시로 얻습니다. 교차 계정 접근의 정석입니다.AssumeRoleWithWebIdentity. Google,Facebook,Cognito 같은 OIDC/웹 자격 증명으로 인증한 사용자에게 임시 자격 증명을 줍니다.GetSessionToken. MFA가 적용된 임시 자격 증명 발급 등.
핵심 원칙: 앱이나 모바일 기기에 장기 IAM 키를 배포하지 않습니다. 대신 페더레이션으로 임시 자격 증명을 발급합니다.
Cognito: 두 개의 풀 #
Cognito는 DVA 보안에서 가장 자주 나오는 서비스이며, User Pool과 Identity Pool을 혼동하면 거의 반드시 틀립니다.
| 구분 | User Pool | Identity Pool(Federated Identities) |
|---|---|---|
| 역할 | 인증(로그인,회원가입) | 인가(임시 AWS 자격 증명 발급) |
| 결과물 | JWT 토큰(ID/Access/Refresh) | STS 임시 AWS 자격 증명 |
| 질문 | “이 사용자가 누구인가” | “이 사용자가 AWS 리소스에 어떻게 접근하나” |
| 대표 용도 | 앱 사용자 디렉터리, API Gateway 오서라이저 | 로그인한 사용자가 S3/DynamoDB에 직접 접근 |
User Pool #
사용자 디렉터리이자 인증 제공자입니다. 회원가입,로그인,MFA,비밀번호 정책,소셜 로그인 연동(Google 등),호스팅 UI를 제공하고, 로그인에 성공하면 JWT를 발급합니다. 이 JWT를 API Gateway의 Cognito 오서라이저가 검증해 API 접근을 허용합니다.
Identity Pool #
인증된(또는 게스트) 사용자에게 STS 임시 AWS 자격 증명을 발급합니다. 사용자는 이 자격 증명으로 S3 버킷이나 DynamoDB 테이블에 직접 접근할 수 있습니다. 인증 소스로 User Pool, 소셜 IdP, SAML 등을 받습니다.
결정적 구분: “로그인/토큰"이면 User Pool, “사용자에게 AWS 리소스 직접 접근(임시 자격 증명)“이면 Identity Pool입니다. 둘을 함께 쓰는 패턴도 흔합니다. User Pool로 로그인 → 그 토큰을 Identity Pool에 넘겨 AWS 자격 증명 획득.
자주 나오는 인증 시나리오 #
- 웹/모바일 앱 로그인. User Pool(인증) + API Gateway Cognito 오서라이저.
- 로그인한 사용자가 자기 폴더에만 S3 업로드. Identity Pool로 임시 자격 증명 + IAM 정책 변수(
${cognito-identity.amazonaws.com:sub})로 사용자별 격리. - 서드파티 OAuth로 로그인. User Pool 소셜 연동 또는 Lambda 오서라이저.
- 서비스 간(서버 to AWS). IAM Role, Cognito 불필요.
시험 출제 패턴 #
- “모바일 앱 사용자가 로그인 후 S3에 직접 업로드할 임시 AWS 자격 증명이 필요하다.” → Identity Pool.
- “앱에 로그인,회원가입,JWT가 필요하다.” → User Pool.
- “API Gateway에서 로그인한 사용자만 허용.” → User Pool + Cognito 오서라이저.
- “Lambda가 DynamoDB에 접근해야 한다.” → 실행 역할에 권한 부여(키 저장 아님).
- “다른 계정 리소스를 코드로 제어.” → STS AssumeRole.
- “사용자마다 자기 S3 prefix에만 접근.” → Identity Pool + IAM 정책의 정책 변수.
자주 만나는 함정 #
1) User Pool과 Identity Pool 혼동 #
User Pool은 인증(토큰), Identity Pool은 인가(AWS 임시 자격 증명)입니다. “AWS 리소스 직접 접근"이면 Identity Pool입니다.
2) 앱에 IAM 사용자 키 배포 #
모바일,웹에 장기 키를 넣는 답안은 항상 오답입니다. 페더레이션으로 임시 자격 증명을 발급합니다.
3) Lambda에 액세스 키를 환경변수로 #
Lambda는 실행 역할이 자격 증명을 자동 공급합니다. 키를 넣을 이유가 없습니다.
정리 #
이번 글에서 잡은 것:
- 인증(“누구인가”) vs 인가(“무엇을 하나”). Cognito는 인증, IAM은 인가
- 코드의 AWS 접근은 IAM Role(EC2 프로파일,ECS 태스크,Lambda 실행 역할). 모두 STS 임시 자격 증명
- STS. AssumeRole(교차 계정), AssumeRoleWithWebIdentity(페더레이션)
- Cognito User Pool(로그인,JWT) vs Identity Pool(임시 AWS 자격 증명) 구분이 핵심
- 앱,모바일에 장기 키 배포 금지
다음: Domain 2-2 암호화와 시크릿 #
신원과 권한을 정리했으니, 다음은 데이터와 비밀값 자체의 보호입니다. #8 암호화와 시크릿에서는 KMS와 봉투 암호화, S3,Lambda 환경변수 암호화, 그리고 Secrets Manager와 Parameter Store의 차이(자동 회전 포함)를 정리하겠습니다.