공동 책임 모델

문서 기준: 2026년 8월

왜 공동 책임인가

자체 전산센터를 임대 건물에서 운영한다고 가정해 보겠습니다. 건물의 출입 통제, 소방 설비, 전력 공급은 빌딩 관리 업체가 책임집니다. 하지만 서버실 내부의 장비 관리, 데이터 백업, 접근 권한 설정은 입주사인 우리가 책임져야 합니다. 빌딩 관리 업체가 아무리 보안을 잘해도, 서버실 비밀번호를 “1234”로 설정하면 보안 사고는 우리 책임입니다.

클라우드도 동일한 구조입니다. 클라우드를 사용한다고 해서 모든 보안과 운영 책임이 벤더에게 넘어가는 것은 아닙니다. 벤더와 사용자가 각각 책임져야 할 영역이 명확히 나뉘어 있으며, 이를 공동 책임 모델 (Shared Responsibility Model)이라고 합니다.

핵심 개념

벤더의 책임 영역 — “클라우드의 보안 (Security of the Cloud)”

클라우드 벤더는 클라우드 인프라 자체의 보안을 책임집니다.

물리적 보안 — 데이터센터 건물, 출입 통제, CCTV, 생체 인증
하드웨어 — 서버, 스토리지, 네트워크 장비의 관리 및 교체
하이퍼바이저 — 가상화 계층의 보안 및 격리
네트워크 인프라 — 글로벌 백본 네트워크, 리전 간 연결

사용자의 책임 영역 — “클라우드 안에서의 보안 (Security in the Cloud)”

사용자는 클라우드 위에서 운영하는 워크로드의 보안을 책임집니다.

데이터 — 저장 데이터의 암호화, 분류, 접근 제어
애플리케이션 — 코드의 보안 취약점, 패치 관리
접근 제어 — IAM 정책, 사용자 권한, MFA 설정
운영 체제 — OS 패치, 보안 설정 (IaaS의 경우)
네트워크 설정 — 보안 그룹, 방화벽 규칙, VPC 구성

서비스 모델에 따른 책임 경계 변화

사용하는 서비스 모델(IaaS, PaaS, SaaS)에 따라 사용자의 책임 범위가 달라집니다. SaaS로 갈수록 벤더가 더 많은 영역을 관리하고, IaaS로 갈수록 사용자의 관리 영역이 넓어집니다.

영역	IaaS	PaaS	SaaS
데이터	사용자	사용자	사용자
애플리케이션	사용자	사용자	벤더
런타임	사용자	벤더	벤더
미들웨어	사용자	벤더	벤더
운영 체제	사용자	벤더	벤더
가상화	벤더	벤더	벤더
서버/스토리지/네트워크	벤더	벤더	벤더
물리적 보안	벤더	벤더	벤더

예를 들어, EC2(IaaS)를 사용하면 OS 패치부터 사용자 책임이지만, RDS(PaaS)를 사용하면 OS 패치는 AWS가 담당합니다. Google Workspace(SaaS)를 사용하면 애플리케이션 관리까지 Google이 담당하고, 사용자는 데이터와 접근 권한만 관리하면 됩니다.

벤더별 비교

항목	AWS	Azure	Google Cloud	OCI
모델 이름	Shared Responsibility Model	Shared Responsibility	Shared Fate	Shared Security Model
기본 구조	전통적 공동 책임	AWS와 유사	공동 운명 모델	전통적 + 자동화 강조
벤더의 추가 지원	Well-Architected Tool, Trusted Advisor	Defender for Cloud, Secure Score	Security Command Center, Assured Workloads	Cloud Guard, Security Zones
보안 기본값	사용자가 명시적으로 설정	사용자가 명시적으로 설정	보안 기본값이 더 엄격	Security Zones로 자동 강제
공식 문서	AWS	Azure	Google Cloud	OCI

AWS는 가장 전통적인 공동 책임 모델을 제시합니다. “클라우드의 보안” 과 “클라우드 안에서의 보안” 을 명확히 구분하며, 사용자가 자신의 책임 영역을 직접 관리해야 합니다.

AWS는 이를 지원하기 위해 다양한 보안 서비스(GuardDuty, Security Hub, IAM Access Analyzer 등)를 제공하지만, 활성화와 설정은 사용자의 몫입니다. 자세한 내용은 보안 태세 관리를 참고하세요.

모델명: Shared Responsibility Model

실무에서 자주 놓치는 부분

공동 책임 모델을 이해하고 있어도, 실무에서 자주 발생하는 보안 실수가 있습니다.

스토리지 공개 접근 — 버킷을 실수로 퍼블릭으로 설정하여 데이터 유출. 데이터 보호 참고
IAM 과다 권한 — 관리자 권한을 부여하고 축소하지 않음. IAM과 접근 제어 참고
암호화 키 관리 — 벤더 관리 키 vs 고객 관리 키(CMK) vs BYOK 선택. 시크릿 관리 참고

규정 준수

각 국가/산업별 규제에 따라 보안 인증이 필요할 수 있습니다. 각 벤더는 인증 보고서를 직접 다운로드할 수 있는 서비스를 제공합니다.

벤더	인증 보고서 서비스	설명
AWS	AWS Artifact	SOC, ISO, PCI 등 감사 보고서 직접 다운로드
Azure	Service Trust Portal	감사 보고서, 컴플라이언스 가이드
Google Cloud	Compliance Reports Manager	ISO, SOC 보고서 다운로드
OCI	Oracle Cloud Compliance	인증 현황 및 보고서

자주 하는 실수

“클라우드를 쓰면 보안은 벤더 책임이다” — 벤더는 인프라 보안만 책임집니다. 데이터 암호화, 접근 제어, 네트워크 설정은 항상 사용자 책임입니다.
“관리형 서비스면 보안 설정이 필요 없다” — PaaS/SaaS라도 접근 권한, 네트워크 노출, 암호화 설정은 사용자가 직접 구성해야 합니다.
“인증만 받으면 보안이 보장된다” — 벤더의 SOC/ISO 인증은 인프라 수준의 보안을 증명할 뿐, 사용자 워크로드의 보안까지 보장하지 않습니다.

체크리스트

사용 중인 서비스 모델(IaaS/PaaS/SaaS)별로 사용자 책임 영역을 식별했는가?
스토리지(버킷/Blob)의 공개 접근 설정을 점검하고 불필요한 퍼블릭 접근을 차단했는가?
벤더가 제공하는 보안 점검 도구(Trusted Advisor, Defender, Security Command Center 등)를 활성화했는가?

참고하기

표준 및 프레임워크

Cloud Security Alliance — Security Guidance v4 — 클라우드 보안 모범 사례
Cloud Security Alliance — Cloud Controls Matrix (CCM) — 클라우드 보안 통제 프레임워크
NIST SP 800-144 — Guidelines on Security and Privacy in Public Cloud Computing