✅ 태스크 설명 1: AWS 리소스에 대한 보안 액세스를 설계합니다
✅ 핵심 목표
AWS 환경에서 최소 권한 원칙(Least Privilege) 기반으로 사용자, 리소스, 계정 간 보안 액세스를 설계합니다.
IAM 역할/정책, 리소스 기반 정책, 역할 전환, 다중 계정 보안 전략에 중점을 둡니다.
🧩 핵심 개념 정리
1️⃣ IAM 역할(Role) 설계 및 적용
💡 언제 사용하는가?
- EC2, Lambda, ECS, CodeBuild 등 AWS 서비스가 다른 리소스에 접근할 때
- 사용자가 직접 자격 증명을 쓰지 않도록 하기 위해 (예: S3, DynamoDB 접근)
- 역할 전환(Switch Role)을 통해 다중 계정 간 권한 위임
✅ 핵심 포인트
- IAM 사용자보다 역할 우선: 사용자에 권한 부여보다 역할 할당이 더 안전하고 유연함
- 신뢰 정책(Trust Policy): 누가 역할을 가정(assume) 할 수 있는지 정의
- 정책 연결 위치:
- 인라인 정책은 일회성, 권장되지 않음
- 관리형 정책은 재사용성 및 일관성 유지에 적합
2️⃣ 리소스 기반 정책 (Resource-based Policy)
💡 언제 사용하는가?
- S3, SNS, SQS, Lambda, API Gateway 같은 리소스에서 직접 권한 부여가 필요할 때
- 다른 계정에서 접근하도록 허용할 때
✅ 핵심 포인트
- IAM 정책 vs 리소스 정책 구분:
- IAM 정책은 “누가 어떤 리소스에” 접근
- 리소스 정책은 “이 리소스에 누가 접근 가능한가” 정의
- Cross-account 접근 시 필수
3️⃣ AWS Organizations 및 SCP (Service Control Policies)
💡 언제 사용하는가?
- 여러 계정을 통합 관리하고, 계정 간 제어를 중앙화할 때
- 민감 리소스에 대한 하위 계정의 접근을 제한하고자 할 때
✅ 핵심 포인트
- SCP는 최대 권한의 상한선을 정의
- 조직 내 모든 계정은 SCP + IAM 정책을 동시에 만족해야 해당 서비스 접근 가능
- 기본적으로 Deny 우선 적용
4️⃣ 시나리오 기반 보안 설계 사례
🔐 예시 1: S3 접근 제어
- ✅ S3에 특정 VPC에서만 접근 → 리소스 정책에
aws:SourceVpc조건 사용 - ✅ 타 계정의 Lambda 함수가 내 S3 버킷 접근 → 리소스 기반 정책으로 계정 ID 허용
🔐 예시 2: ALB + WAF 설계
- ALB는 공개 접근 허용하지만, 특정 IP만 접근 가능하도록 → WAF ACL로 필터링
- SQL Injection 차단 → WAF Managed Rule 적용
🔐 예시 3: Lambda + SQS 트리거
- Lambda가 SQS 메시지를 읽으려면?
- Lambda에 SQS Read 권한을 부여
- SQS에 Lambda를 invoker로 허용하는 리소스 정책 필요
📝 시험 유형 요약
| 개념 | 출제 가능성 | 자주 나오는 유형 |
|---|---|---|
| IAM 역할, 역할 위임 | 매우 높음 | EC2, Lambda, ECS에서 다른 리소스 접근 |
| 리소스 정책 | 매우 높음 | S3, SQS, SNS의 cross-account 접근 |
| AWS Organizations + SCP | 높음 | 하위 계정 제한, OU 기반 제어 |
| WAF, S3 조건부 접근 | 높음 | 특정 조건 기반 허용/차단 정책 구성 |
| 루트 사용자 / STS 세부 구조 | 낮음 | 시험에서 직접 출제는 드묾 |
🎯 관련 문제
📘 문제 1
한 회사는 Amazon EC2 인스턴스에서 애플리케이션을 운영 중이며, 해당 애플리케이션은 Amazon S3 버킷에 데이터를 저장합니다. EC2 인스턴스만 해당 버킷에 접근할 수 있도록 보안을 설정해야 합니다.
이 요구사항을 충족하기 위한 가장 적절한 방법은 무엇입니까?
A. IAM 사용자를 만들고 액세스 키를 생성한 후, 애플리케이션에 키를 설정한다.
B. S3 접근 권한이 있는 IAM 역할을 생성하고, EC2 인스턴스에 역할을 연결한다.
C. S3 버킷 정책을 설정하여 모든 사용자에게 접근을 허용한다.
D. 리소스 기반 정책을 사용하여 모든 사용자에게 접근을 부여한다.
✅ 정답: B
EC2 인스턴스에서 S3 버킷에 안전하게 접근하려면, IAM 역할을 EC2에 연결하고 해당 역할에 S3 권한을 부여하는 것이 가장 안전하고 권장되는 방식이다.
❌ 오답 해설
- A: 액세스 키를 애플리케이션에 하드코딩하면 보안 위협
- C: 퍼블릭 접근은 보안상 매우 위험
- D: 리소스 기반 정책은 특정 조건하에서는 유용하지만 “모든 사용자 허용”은 위험
📘 문제 2
Dev 계정에서 Prod 계정에 있는 Amazon S3 버킷에 접근해야 합니다. 두 계정은 별도로 운영되고 있습니다.
이런 상황에서 가장 안전하게 교차 계정 접근을 구현하는 방법은 무엇입니까?
A. Prod 계정에 IAM 사용자를 만들고 자격 증명을 Dev 계정에 전달한다.
B. IAM 역할과 버킷 정책을 이용해 교차 계정 접근을 설정한다.
C. 두 계정 간 S3 복제를 활성화한다.
D. AWS SSO를 이용하여 두 계정을 연결한다.
✅ 정답: B
Prod 계정에 역할 생성 → Dev 계정에서 역할 전환 설정 → S3 버킷 정책에서 접근 허용 구성은 AWS에서 권장하는 교차 계정 접근 방식이다.
❌ 오답 해설
- A: 자격 증명 공유는 보안상 금지
- C: 복제는 단방향 데이터 동기화일 뿐 직접 접근을 대체하지 못함
- D: AWS SSO는 사용자 인증 목적, 교차 계정 리소스 접근 설정과는 다름
📘 문제 3
한 회사는 Amazon S3 버킷에서 객체 삭제를 막고 싶어 합니다.
삭제를 방지하기 위한 가장 적절한 방법은 무엇입니까?
A. 모든 주체(Principal)의 DeleteObject 작업을 거부하는 버킷 정책을 적용한다.
B. S3 버킷에서 버전 관리를 활성화한다.
C. S3 버킷에서 MFA 삭제(MFA Delete)를 활성화한다.
D. S3 라이프사이클 정책을 설정하여 삭제를 방지한다.
✅ 정답: A
명시적인 Deny 정책은 가장 강력하며, 어떤 사용자도 삭제할 수 없도록 설정할 수 있다.
❌ 오답 해설
- B: 버전 관리는 복원은 가능하지만 삭제 자체는 막지 못함
- C: MFA 삭제는 root 사용자만 설정 가능하고, 자동화 어려움
- D: 라이프사이클 정책은 삭제 “예약”이지 방지는 아님
📘 문제 4
AWS 루트 사용자 계정에 대한 보안 관리를 위한 모범 사례는 무엇입니까?
A. 루트 계정을 일상적인 관리 작업에 사용한다.
B. 루트 자격 증명을 최소 두 명의 관리자에게 공유한다.
C. 루트 계정에 MFA를 설정하고, 일상 업무에는 사용하지 않는다.
D. 루트 계정을 사용하여 IAM 역할을 생성한다.
✅ 정답: C
루트 계정은 MFA 필수 + 사용 제한이 보안 모범 사례다.
❌ 오답 해설
- A: 루트 계정은 긴급한 상황 외에는 사용 금지
- B: 자격 증명 공유는 절대 금지
- D: IAM 역할은 관리자 권한 사용자로도 충분히 생성 가능
📘 문제 5
AWS Organizations를 사용하여 여러 계정을 운영 중인 회사가 있습니다. 보안 팀은 특정 AWS 리전에서 리소스 생성을 방지하고자 합니다.
어떤 접근 방식이 가장 효과적입니까?
A. 개발자 그룹에 해당 리전을 제한하는 IAM 정책을 설정한다.
B. AWS Config를 사용해 해당 리전의 리소스 생성을 감지한다.
C. 해당 리전의 모든 작업을 거부하는 SCP(Service Control Policy)를 생성한다.
D. 리소스에 태그를 설정하고 CloudWatch로 모니터링한다.
✅ 정답: C
특정 리전에서 리소스를 생성하지 못하게 하려면, SCP를 통해 명시적으로 Deny 하는 것이 가장 효과적이다.
❌ 오답 해설
- A: IAM 정책은 우회 가능성이 있고, OU 전체에 적용 불가
- B: Config는 감지만 가능하고 차단은 불가능
- D: 모니터링은 예방이 아닌 사후 대응
📘 문제 6
외부 벤더가 자사 AWS 계정 내 특정 리소스에 접근할 수 있어야 합니다. 벤더는 자체 ID 공급자(IdP)를 사용합니다. 벤더에게 임시 자격 증명을 제공하면서 보안을 유지하려면 어떤 방식이 적절합니까?
A. IAM 사용자를 생성하고 자격 증명을 벤더에 전달한다.
B. SAML 기반 연동과 IAM 역할을 이용한다.
C. AWS SSO를 벤더와 연동한다.
D. 액세스 키를 생성하여 이메일로 전송한다.
✅ 정답: B
외부 IdP(예: Okta, AD 등)를 사용하는 경우, SAML + IAM 역할 매핑을 통해 보안적으로 안전한 연동이 가능하다.
❌ 오답 해설
- A, D: 자격 증명 공유는 보안상 매우 위험
- C: SSO는 주로 내부 사용자에게 사용하며, 외부 연동엔 부적절
핵심 차이점
| 구분 | 리소스 수정/접근 권한 | 리소스 자체 권한 |
|---|---|---|
| 대상 | 외부 리소스(S3, RDS) | 서비스(EC2, Lambda) |
| 목적 | 리소스 조작 제어 | 서비스의 동작 권한 부여 |
| 예시 | 사용자의 S3 버킷 삭제 권한 제한 | Lambda 함수의 CloudWatch 로그 기록 권한 |
이처럼 IAM 역할은 크게 리소스 접근 제어와 서비스 자체의 동작 권한을 동시에 관리하는 도구로 활용됩니다.
