SAA-C03 Q267 · Security

Question

한 회사가 VPC 내부의 여러 Amazon EC2 인스턴스에 애플리케이션을 호스팅합니다. 이 회사는 각 고객을 위해 전용 Amazon S3 버킷을 만들어 Amazon S3 에 관련 정보를 저장합니다. 이 회사는 EC2 인스턴스에서 실행되는 애플리케이션이 회사의 AWS 계정에 속한 S3 버킷에만 안전하게 액세스할 수 있도록 하려고 합니다. 어떤 솔루션이 최소한의 운영 오버헤드로 이러한 요구 사항을 충족할까요?

Accepted Answer

**문제의 핵심 요구사항:**
1. EC2 → S3 접근을 **자사 AWS 계정 소유 버킷에만** 제한
2. **안전하게** 접근 (인터넷 경유 X)
3. **최소한의 운영 오버헤드**

**정답 C가 충족하는 방식:**

**Step 1: S3 Gateway Endpoint 생성**
- VPC 내부에서 S3로의 트래픽이 AWS 내부 네트워크를 통해 전달됨 (인터넷 불필요)
- 무료이며 설정이 간단 → 운영 오버헤드 최소화

**Step 2: IAM 인스턴스 프로필에 Deny + 조건 키 적용**
- `aws:ResourceAccount` 조건 키를 사용하여 **자사 계정이 아닌 S3 버킷에 대한 접근을 Deny**
- 정책 예시:
```json
{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:ResourceAccount": "123456789012"
    }
  }
}
```
- 이렇게 하면 자사 계정(123456789012) 소유가 아닌 모든 S3 버킷 접근이 거부됨
- 각 고객별 버킷을 일일이 나열할 필요 없이, 계정 수준에서 한 번에 제어 가능

**왜 Deny + 조건 키 조합인가?**
- Allow만으로 특정 버킷을 나열하면 버킷이 추가될 때마다 정책 업데이트 필요
- Deny + `StringNotEquals` 패턴은 **화이트리스트 방식의 반대**: '우리 계정이 아닌 것은 모두 차단'
- 버킷이 늘어나도 정책 변경 불필요 → **운영 오버

📖 해설

✅ 정답 분석

❌ 오답 분석

📘 핵심 개념

🏗️ 아키텍처

⚙️ 운영 관점

💰 비용 관점

🔒 보안 관점

🎯 시험 팁