기업이 클라우드 서비스를 도입하면 서버실, 물리 서버, 네트워크 장비와 같은 인프라를 직접 관리해야 하는 부담은 크게 줄어든다. 하지만 이것이 보안 책임까지 클라우드 사업자에게 이전된다는 의미는 아니다.
클라우드에서는 클라우드 서비스 제공자(Cloud Service Provider, CSP)와 이용 기업이 보안 책임을 나누어 갖는 '공유 책임 모델(Shared Responsibility Model)'이 적용된다. 어느 영역을 사업자가 관리하고 어느 영역을 기업이 직접 관리해야 하는지는 사용하는 서비스가 IaaS, PaaS, SaaS 중 무엇인지에 따라 달라진다.
이 책임 경계를 제대로 이해하지 못하면 "클라우드 사업자가 보안을 해줄 것"이라고 생각하면서 계정 권한, 데이터 공개 설정, 로그 모니터링 등 정작 기업이 관리해야 할 영역이 방치될 수 있다.
클라우드 공유 책임 모델의 기본 개념
온프레미스 환경에서는 기업이 데이터센터 시설부터 서버, 운영체제, 네트워크, 애플리케이션, 데이터까지 대부분의 영역을 직접 관리한다.
클라우드에서는 이 가운데 일부가 클라우드 사업자에게 이전된다. AWS는 이를 Security of the Cloud와 Security in the Cloud라는 개념으로 구분한다. 사업자는 클라우드 자체를 구성하는 물리 시설, 하드웨어, 네트워크와 기반 인프라를 보호하고, 고객은 자신이 클라우드 위에서 사용하는 시스템과 데이터 및 설정을 보호한다.
중요한 점은 '공유'가 모든 보안 업무를 사업자와 고객이 절반씩 담당한다는 의미가 아니라는 것이다. 실제 책임 경계는 선택한 서비스와 구성 방식에 따라 달라진다.
IaaS·PaaS·SaaS에 따라 달라지는 책임 범위
클라우드 서비스가 관리형 서비스에 가까워질수록 클라우드 사업자가 담당하는 영역은 넓어진다.
| 구분 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 물리 데이터센터 | 사업자 | 사업자 | 사업자 |
| 물리 서버·기반 네트워크 | 사업자 | 사업자 | 사업자 |
| 가상화·서비스 기반 플랫폼 | 주로 사업자 | 사업자 | 사업자 |
| 운영체제 | 주로 기업 | 주로 사업자 | 사업자 |
| 애플리케이션 | 주로 기업 | 기업·사업자 역할 분담 | 주로 사업자 |
| 계정·접근권한 | 기업 | 기업 | 기업 |
| 데이터 관리 | 기업 | 기업 | 기업 |
| 서비스 설정 | 기업 | 기업 | 기업 |
이는 일반적인 책임 구조이며 실제 경계는 서비스별로 다를 수 있다. 따라서 단순히 "IaaS이므로 여기까지", "SaaS이므로 여기부터"라고 판단하기보다 사용하는 서비스의 공식 보안 문서를 확인해야 한다. Microsoft 역시 고객 책임이 IaaS, PaaS, SaaS에 따라 달라지며 데이터, 계정, 접근 관리와 같은 영역은 클라우드 환경에서도 고객이 계속 관리해야 한다고 설명한다.
IaaS에서는 기업의 관리 범위가 넓다
IaaS는 가상 서버, 스토리지, 네트워크 같은 인프라 자원을 제공받는 방식이다. 클라우드 사업자가 물리 서버와 데이터센터를 운영하더라도 기업은 일반적으로 가상 서버의 운영체제, 보안 패치, 설치된 애플리케이션, 계정, 방화벽·보안 그룹 설정 등을 관리해야 한다.
즉 물리 서버를 가상 서버로 바꿨다고 해서 기존 서버 보안 업무가 모두 사라지는 것은 아니다. AWS도 EC2와 같은 IaaS 환경에서는 고객이 게스트 운영체제 업데이트와 보안 패치, 애플리케이션, 보안 그룹 설정 등을 담당한다고 설명한다.
PaaS에서는 운영체제 관리가 줄어든다
PaaS에서는 클라우드 사업자가 운영체제나 런타임과 같은 플랫폼 영역까지 관리한다. 따라서 기업은 운영체제를 직접 설치하거나 패치해야 하는 부담을 줄일 수 있다. 대신 자신이 개발한 애플리케이션의 보안, 계정 및 권한, 데이터 보호, 서비스 설정 등은 계속 관리해야 한다.
관리할 인프라가 줄어드는 것이지 기업의 보안 책임 자체가 없어지는 것은 아니다.
SaaS에서도 보안 책임은 남아 있다
SaaS는 사업자가 애플리케이션까지 운영하기 때문에 고객의 기술적 관리 범위가 가장 작다. 하지만 SaaS에서도 사용자 계정, 접근권한, 데이터, 서비스 설정과 같은 영역은 기업의 책임으로 남는다.
따라서 SaaS를 사용한다는 이유만으로 별도의 보안 관리가 필요하지 않다고 판단하면 안 된다.
기업이 직접 관리해야 하는 핵심 보안 영역
1. 계정과 접근권한
클라우드 사업자가 IAM, MFA, 역할 기반 접근통제와 같은 기능을 제공하더라도 실제로 누구에게 어떤 권한을 부여할지는 고객이 결정한다. 관리자 권한을 필요 이상으로 부여하거나 퇴직자의 계정을 제거하지 않는 문제는 클라우드 사업자가 자동으로 해결해 주는 영역이 아니다.
따라서 최소권한 원칙, 관리자 계정 분리, MFA 적용, 계정 생성·변경·삭제 절차가 필요하다.
2. 데이터 관리
데이터가 저장되는 인프라는 사업자가 운영할 수 있지만 어떤 데이터를 클라우드에 저장할지, 누가 접근할 수 있는지, 얼마나 오래 보관할지에 대한 책임은 기업에 있다.
기업은 최소한 데이터 분류, 접근통제, 암호화 설정, 보존 기간, 삭제 정책 등을 관리해야 한다. 특히 개인정보나 중요정보를 처리한다면 기술적인 클라우드 보안뿐 아니라 관련 법률과 내부 정책에 따른 보호조치도 함께 검토해야 한다.
3. 클라우드 서비스 설정
클라우드 사업자가 안전한 기능을 제공하는 것과 고객이 그 기능을 올바르게 설정하는 것은 별개의 문제다. 외부에 공개할 필요가 없는 저장소를 인터넷에 공개하거나, 네트워크 접근 범위를 과도하게 허용하거나, 관리 인터페이스에 불필요한 접근을 허용하면 클라우드 인프라 자체가 안전하더라도 보안 문제가 발생할 수 있다.
4. 로그와 보안 모니터링
클라우드 사업자는 다양한 감사 로그와 보안 이벤트를 제공하지만 로그가 존재한다는 것과 기업이 이를 실제로 모니터링하는 것은 다르다. 기업은 필요한 로그를 활성화하고 수집 범위를 정의하며 중요 이벤트에 대한 탐지·알림·분석 체계를 구성해야 한다.
기업에서 SIEM이나 통합 보안 모니터링 체계를 운영한다면 클라우드 계정 활동, 관리자 작업, 인증 이벤트, 네트워크 및 주요 서비스 로그를 기존 보안 모니터링 체계와 어떻게 연동할지 검토해야 한다.
5. 백업과 복구
클라우드 서비스가 높은 내구성과 가용성을 제공한다고 해서 기업의 백업 정책까지 자동으로 해결되는 것은 아니다. 기업은 업무 중요도에 따라 필요한 복구 시점과 복구 시간을 정하고 백업 보존 기간, 삭제 방지, 별도 계정 또는 영역 보관, 실제 복구 테스트 등을 설계해야 한다.
서비스 자체의 장애 대비와 고객 데이터의 논리적 삭제·랜섬웨어·관리자 실수에 대한 복구는 서로 다른 문제로 봐야 한다.
6. 규제와 컴플라이언스
클라우드 사업자가 다양한 보안 인증이나 규제 준수 인증을 보유하고 있더라도 이를 이용하는 기업이 자동으로 규제를 충족하는 것은 아니다. 사업자가 담당하는 인프라 영역의 통제와 고객이 담당하는 데이터·권한·서비스 설정의 통제는 구분해서 확인해야 한다.
따라서 클라우드 도입 시에는 기술 검토뿐 아니라 계약 조건, 데이터 저장 위치, 로그 보존, 접근권한, 사고 대응, 서비스 종료 시 데이터 처리 방식 등을 함께 검토하는 것이 필요하다.
공유 책임 모델에서 자주 발생하는 오해
가장 대표적인 오해는 "클라우드 사업자가 보안을 담당하므로 기업의 보안 업무가 줄어든다"는 생각이다. 일부 업무가 줄어드는 것은 맞다. 물리 서버 유지관리나 데이터센터 시설 보안과 같은 업무는 클라우드 사업자로 이동한다.
하지만 그만큼 보안의 중심은 다른 영역으로 이동한다. 서버실의 물리 통제보다 IAM 정책이 중요해지고, 장비 설정보다 클라우드 리소스 구성 관리가 중요해진다. 서버 로그뿐 아니라 API 호출과 관리자 활동을 추적해야 하고, 물리 자산 목록 대신 클라우드 리소스를 지속적으로 파악해야 한다.
따라서 클라우드 전환은 보안 업무가 없어지는 과정이라기보다 보안 관리 대상이 변화하는 과정으로 보는 편이 정확하다.
실무에서는 책임 영역을 문서화해야 한다
기업에서 공유 책임 모델을 실제 운영에 적용하려면 개념을 이해하는 것만으로는 부족하다. 우선 사용하는 클라우드 서비스를 IaaS, PaaS, SaaS 등으로 분류하고 서비스별로 사업자와 기업의 책임을 확인해야 한다.
이후 계정, 데이터, 네트워크, 운영체제, 애플리케이션, 로그, 백업, 사고 대응과 같은 통제 영역별 담당 부서를 지정하는 것이 좋다. 특히 클라우드 운영팀, 정보보안팀, 애플리케이션 담당자 사이의 역할이 불명확하면 문제가 발생했을 때 "누가 관리하는 영역인지"부터 확인해야 하는 상황이 생길 수 있다.
중요 서비스라면 클라우드 사업자 → 사내 클라우드 운영 담당 → 정보보안 담당 → 애플리케이션 담당 → 데이터 소유 부서의 관계를 기준으로 각 통제 항목에 대해 누가 설정하고, 누가 점검하며, 사고 발생 시 누가 대응할 것인지를 명확하게 정의해야 한다.
실무자 관점에서 보는 공유 책임 모델
클라우드 보안에서 실제로 중요한 것은 "사업자가 어디까지 해주는가"보다 우리 회사가 무엇을 해야 하는지를 정확하게 파악하는 것이다. 사업자의 데이터센터 보안 수준이 아무리 높아도 관리자 계정에 과도한 권한을 부여하거나 스토리지를 공개 상태로 설정한다면 기업의 정보는 보호되지 않는다.
반대로 모든 보안을 기업이 직접 수행해야 한다고 생각하면 관리형 서비스를 사용하는 장점을 제대로 활용하기 어렵다. 따라서 클라우드 보안 운영에서는 공급자와 고객의 책임을 단순히 둘로 나누기보다 서비스별 책임 경계를 확인하고 고객 책임 영역에 실제 통제가 적용되어 있는지를 지속적으로 확인하는 체계가 중요하다.
멀티클라우드 환경에서는 더욱 그렇다. AWS, Microsoft Azure, Google Cloud가 모두 공유 책임 모델을 사용하지만 서비스별 세부 책임과 제공 기능은 동일하지 않다. 특정 사업자의 책임 구조를 그대로 다른 클라우드에 적용하기보다는 실제 사용하는 서비스의 공식 문서를 기준으로 판단해야 한다.
결론
클라우드로 이전한다고 해서 기업의 보안 책임이 사라지는 것은 아니다. 클라우드 사업자는 데이터센터, 물리 서버, 기반 네트워크와 같은 클라우드 인프라를 보호하고, 기업은 자신이 관리하는 계정, 접근권한, 데이터, 서비스 설정과 워크로드를 보호해야 한다.
IaaS에서 PaaS, SaaS로 이동할수록 사업자가 관리하는 기술 영역은 넓어지지만 기업이 보유한 데이터와 사용자 접근에 대한 책임까지 모두 이전되는 것은 아니다.
따라서 클라우드 보안의 출발점은 보안 솔루션을 추가하는 것이 아니라 현재 사용하는 서비스에서 클라우드 사업자와 우리 회사의 책임 경계를 명확하게 정의하는 것이다. 그 책임 경계가 명확해야 IAM, 로그 모니터링, 데이터 보호, 백업, 사고 대응과 같은 실제 보안 통제를 올바르게 설계할 수 있다.
참고자료
- AWS — 공동 책임 모델
- Microsoft Azure — Shared responsibility in the cloud
- Google Cloud — 책임 공유 및 공통된 운명
- CISA — Cloud Security Technical Reference Architecture