1. 공동 책임 모델이란?
온프레미스 환경에서는 데이터센터의 물리적 잠금장치부터 애플리케이션 코드까지 모든 보안을 고객이 책임졌지만 클라우드로 전환하면 이 책임이 AWS와 고객 사이에 분할됩니다.
AWS는 이를 "클라우드 자체의 보안(Security OF the Cloud)"과 "클라우드 내부의 보안(Security IN the Cloud)"으로 구분합니다.
그림 1. AWS 공동 책임 모델 공식 다이어그램. 위(파란색)는 고객 책임 영역, 아래(주황색)는 AWS 책임 영역.
고객 책임 영역
- 고객 데이터
- 플랫폼, 애플리케이션, ID 및 접근 관리(IAM)
- 운영 체제, 네트워크, 방화벽 구성
- 클라이언트 사이드 데이터 암호화 및 무결성 인증
- 서버 사이드 암호화 (파일 시스템 및 데이터)
- 네트워크 트래픽 보호 (암호화, 무결성, 신원 확인)
AWS 책임 영역
- 글로벌 인프라 (리전, 가용 영역, 엣지 로케이션)
- 하드웨어 (서버, 스토리지, 네트워킹 장비)
- 컴퓨팅, 스토리지, 데이터베이스, 네트워킹 서비스
- 하이퍼바이저 및 가상화 레이어
- 데이터센터 물리적 보안
- 관리형 서비스의 기반 소프트웨어
2. 서비스 유형별 책임 범위
공동 책임의 경계는 사용하는 서비스 유형에 따라 달라집니다. 관리형 서비스일수록 AWS가 더 많은 책임을 집니다.
| 책임 항목 | IaaS (EC2 등) | 컨테이너 (ECS/EKS) | PaaS (RDS, Lambda 등) | SaaS (S3, DynamoDB 등) |
|---|---|---|---|---|
| 데이터 분류 및 암호화 | 고객 | 고객 | 고객 | 고객 |
| IAM 설정 및 권한 관리 | 고객 | 고객 | 고객 | 고객 |
| OS 패치 및 업데이트 | 고객 | AWS | AWS | |
| 네트워크 방화벽 설정 | 고객 | 고객 | 고객 | 고객 |
| 애플리케이션 보안 패치 | 고객 | 고객 | 고객 | AWS |
| 데이터베이스 엔진 패치 | 고객 | 고객 | AWS | AWS |
| 물리적 인프라 보안 | AWS | AWS | AWS | AWS |
| 하이퍼바이저 보안 | AWS | AWS | AWS | AWS |
| 가용성 및 내결함성 | 고객 (설계 책임) | AWS (SLA 보장) |
3. 공동 책임 모델이 주는 것
고객 입장에서의 이점
| 이점 | 설명 |
|---|---|
| 보안 부담 분산 | 물리적 보안, 하이퍼바이저, 네트워크 하드웨어는 AWS가 전담. 고객은 데이터·애플리케이션 보안에 집중. |
| 규정 준수 증적 간소화 | ISMS-P, PCI-DSS 심사 시 AWS Artifact에서 SOC 2·ISO 27001 보고서를 다운로드해 AWS 관할 영역의 증적으로 제출 가능. |
| 보안 투자 최적화 | 데이터센터 물리 보안에 투자할 비용을 애플리케이션 보안·모니터링에 집중 투자 가능. |
| 글로벌 인프라 보안 수준 활용 | AWS의 수천 명 보안 전문가와 글로벌 인증 수준의 인프라 보안을 그대로 상속. |
책임 경계가 명확해야 하는 이유 — 사고 시 책임 분쟁
보안 침해 발생 시 "AWS가 책임져야 하는 것 아닌가?"라는 분쟁이 자주 발생합니다. 아래 사례는 경계가 얼마나 명확한지를 보여줍니다.
| 시나리오 | 책임 소재 | 이유 |
|---|---|---|
| S3 버킷 퍼블릭 설정으로 데이터 유출 | 고객 | 버킷 접근 제어 설정은 고객 책임 |
| EC2 인스턴스 OS 취약점 침해 | 고객 | EC2 OS 패치는 고객 책임 |
| AWS 데이터센터 물리 침입 | AWS | 물리적 보안은 AWS 책임 |
| RDS 엔진 취약점(패치 전) 침해 | AWS | 관리형 서비스 엔진 패치는 AWS 책임 |
| IAM 키 유출로 인한 리소스 삭제 | 고객 | 자격증명 관리는 고객 책임 |
| 하이퍼바이저 취약점으로 VM 탈출 | AWS | 가상화 레이어는 AWS 책임 |
4. Well-Architected Framework 설계 시 공동 책임 모델 적용
AWS Well-Architected Framework는 6개 기둥(Pillar)으로 클라우드 아키텍처를 평가합니다. 각 기둥에서 고객이 직접 설계·구현해야 하는 영역을 공동 책임 모델 관점에서 살펴봅니다.
보보안 (Security)
- IAM 최소 권한 원칙
- MFA 전체 계정 적용
- 저장·전송 데이터 암호화
- VPC 계층 분리, Security Group 최소화
- CloudTrail·Config 활성화
- GuardDuty·Security Hub 연동
안안정성 (Reliability)
- 멀티 AZ 배포 설계
- 자동 복구(Auto Scaling, ALB 헬스체크)
- 백업 정책 및 복구 테스트 (RTO/RPO 정의)
- 리전 간 DR(재해 복구) 시나리오
- 의존성 격리 및 Circuit Breaker 패턴
성성능 효율성 (Performance)
- 워크로드에 맞는 인스턴스 유형 선택
- CloudFront CDN 활용
- RDS Read Replica / ElastiCache 캐싱
- 서버리스(Lambda) 적재적소 활용
- 성능 지표 CloudWatch 모니터링
비비용 최적화 (Cost)
- Reserved Instance / Savings Plans 활용
- 미사용 리소스 자동 종료 정책
- Cost Explorer 및 예산 알람 설정
- S3 Intelligent-Tiering 스토리지 계층화
- Spot Instance 활용 (배치, CI/CD)
운운영 우수성 (Operations)
- IaC (Terraform, CloudFormation) 전환
- 변경 관리 프로세스 및 롤백 계획
- 운영 지표(SLI/SLO) 정의 및 측정
- 장애 후 회고(Post-Mortem) 문화
- Systems Manager로 운영 자동화
지지속 가능성 (Sustainability)
- 최소 필요 리소스만 프로비저닝
- Graviton 프로세서 활용 (에너지 효율)
- 수명 주기 종료 리소스 정리 자동화
- 관리형 서비스 우선 (인프라 공유로 탄소 감소)
5. 고객 책임 영역 실전 체크리스트
공동 책임 모델에서 고객이 반드시 직접 구성해야 하는 핵심 항목입니다.
aws:SecureTransport 조건, RDS SSL 강제 설정.6. 컴플라이언스 심사에서 공동 책임 모델 활용
ISMS-P, PCI-DSS, ISO 27001 심사 시 심사관은 물리적 보안·하이퍼바이저 등 AWS 관할 영역에 대한 증적을 요구합니다.
| 심사 요구사항 | 제출 자료 | 출처 |
|---|---|---|
| 데이터센터 물리적 보안 | AWS SOC 2 Type II 보고서 | AWS Artifact (무료 다운로드) |
| 인프라 정보보호 관리체계 | AWS ISO 27001 인증서 | AWS Artifact |
| 국내 정보보호 인증 | AWS K-ISMS 인증서 (서울 리전) | AWS Artifact |
| 하이퍼바이저 보안 | AWS Nitro System 백서 | AWS 공식 문서 |
| 고객 설정 보안 현황 | Security Hub CIS Benchmark 준수 리포트 | 고객이 직접 생성 |
| API 감사 로그 | CloudTrail 로그 | 고객이 직접 제공 |
7. 마무리
공동 책임 모델은 클라우드 보안의 출발점입니다. AWS가 인프라를 완벽하게 보호해도 고객이 S3를 퍼블릭으로 열어두거나 IAM에 과도한 권한을 부여하면 침해가 발생합니다.
Well-Architected Framework의 6개 기둥 중 보안 기둥은 공동 책임 모델에서 고객 책임 영역 전체를 체계적으로 다루고 있습니다. 설계 단계에서 AWS Well-Architected Tool을 실행해 고위험 항목(HRI)을 사전에 파악하는 것이 가장 효율적인 접근 방법입니다.
"AWS가 알아서 해주겠지"가 가장 위험한 가정입니다. 공동 책임 모델을 이해하는 순간, 클라우드 보안의 절반은 이미 해결된 것이고 나머지 절반은 온전히 여러분의 손에 달려 있습니다.