클라우드 공동 책임 모델 사용자가 직접 책임져야 하는 보안 범위 제대로 알아보기
클라우드 공동 책임 모델은 클라우드를 사용하는 사람이라면 반드시 알아야 하는 보안의 기본 원칙입니다. 클라우드로 옮기면 보안은 AWS나 Azure 같은 대형 사업자가 알아서 해줄 것이라고 기대하기 쉽지만, 실제로는 사업자와 사용자가 책임을 나누어 가지는 구조입니다. 이 경계를 모르면 사용자가 챙겨야 할 설정을 방치하게 되고, 그 빈틈이 데이터 유출이나 계정 탈취로 이어질 수 있습니다.
저도 예전에는 대기업 클라우드에 올려두면 해킹 걱정은 거의 하지 않아도 된다고 생각했습니다. 그런데 클라우드 관련 보안 사고 사례를 찾아보면 데이터센터가 뚫린 경우보다 저장소를 공개로 잘못 설정했거나, 액세스 키가 코드와 함께 외부에 노출된 경우가 훨씬 많았습니다. 결국 사업자가 아무리 튼튼한 건물을 지어도 문을 열어두는 것은 사용자의 몫이라는 것을 알게 되었습니다.
오늘 제가 준비한 포스팅에서는 클라우드 공동 책임 모델을 중심으로 사업자가 책임지는 영역과 사용자가 책임지는 영역, 서비스 모델에 따라 책임 범위가 어떻게 달라지는지, 그리고 사용자가 당장 점검해야 할 보안 항목까지 차근차근 정리해보겠습니다.
핵심을 먼저 말씀드리면 AWS는 이를 "클라우드 자체의 보안(Security of the Cloud)은 AWS가, 클라우드 안에서의 보안(Security in the Cloud)은 고객이 책임진다"고 표현합니다. 물리적 인프라는 사업자가 지키고, 그 위에 무엇을 어떻게 설정하고 저장하는지는 사용자가 지켜야 한다는 뜻입니다.
클라우드 공동 책임 모델이란 무엇인가요
공동 책임 모델(Shared Responsibility Model)은 클라우드 환경의 보안과 규정 준수 책임을 클라우드 사업자와 고객이 나누어 맡는다는 개념입니다. AWS, Microsoft Azure, Google Cloud 모두 공식 문서에서 이 모델을 설명하고 있으며, 표현은 조금씩 달라도 기본 원리는 같습니다.
온프레미스 환경에서는 건물 출입 통제부터 서버 하드웨어, 운영체제, 애플리케이션, 데이터까지 모든 보안을 회사가 책임졌습니다. 클라우드로 옮기면 이 가운데 일부를 사업자가 넘겨받습니다. 하지만 넘겨받는 범위는 전체가 아니라 인프라에 가까운 아래쪽 층에 한정됩니다.
이 모델이 중요한 이유는 보안 사고가 발생했을 때 누가 어떤 조치를 했어야 하는지를 명확히 해주기 때문입니다. 사용자가 공개 설정을 해둔 저장소에서 데이터가 유출되었다면 이는 사업자의 인프라 결함이 아니라 사용자 책임 영역에서 발생한 문제로 판단됩니다.
클라우드로 이전한다고 보안 책임이 사라지는 것이 아니라, 책임의 일부가 사업자에게 넘어가고 나머지는 여전히 사용자에게 남는다는 것이 공동 책임 모델의 핵심입니다.
클라우드 사업자가 책임지는 보안 영역
클라우드 사업자는 서비스를 구성하는 물리적 인프라와 기반 소프트웨어의 보안을 책임집니다. 데이터센터 건물의 출입 통제, 경비, CCTV, 전력과 냉각 설비, 화재 대응 같은 물리 보안이 여기에 포함됩니다. 일반 사용자는 데이터센터의 정확한 위치조차 알 수 없도록 관리됩니다.
또한 서버와 스토리지, 네트워크 장비 같은 하드웨어의 유지 보수와 교체, 여러 고객의 환경을 분리하는 가상화 계층인 하이퍼바이저의 보안도 사업자가 담당합니다. 리전과 가용 영역 사이를 연결하는 글로벌 네트워크의 안정성과 보호 역시 사업자의 책임입니다.
사업자는 이러한 관리 수준을 증명하기 위해 ISO 27001, SOC 보고서 같은 국제 인증과 감사 보고서를 제공합니다. AWS의 경우 AWS Artifact에서 이런 보고서를 내려받을 수 있어, 고객사가 내부 감사나 규제 대응 자료로 활용할 수 있습니다.
사업자는 데이터센터와 하드웨어, 가상화 계층 같은 눈에 보이지 않는 기반을 책임지며, 이 부분은 사용자가 직접 설정하거나 통제할 수 없습니다.
사용자가 반드시 책임져야 하는 보안 영역
사용자가 책임지는 영역은 크게 계정과 권한, 데이터, 네트워크 설정, 그리고 서버 내부 관리로 나눌 수 있습니다. 가장 먼저 계정 보안이 있습니다. 루트 계정에 다단계 인증을 설정하고, 직원마다 필요한 최소한의 권한만 부여하는 것은 사업자가 대신해줄 수 없는 일입니다.
데이터 보호도 사용자의 책임입니다. 어떤 데이터를 암호화할지, 암호화 키를 누가 관리할지, 저장소를 누구에게 공개할지를 결정해야 합니다. 대부분의 클라우드 저장소는 기본적으로 비공개로 생성되지만, 사용자가 설정을 바꾸면 인터넷에 그대로 노출될 수 있습니다.
네트워크 측면에서는 방화벽 역할을 하는 보안 그룹 규칙, 서브넷 구성, 외부 접속 허용 범위를 사용자가 설정합니다. 관리용 SSH나 원격 데스크톱 포트를 모든 IP에 열어두는 설정은 자동화된 공격 도구의 표적이 되기 쉽습니다.
가상 서버를 사용하는 경우 운영체제 보안 패치, 설치한 소프트웨어 업데이트, 백신과 로그 관리도 사용자가 챙겨야 합니다. 사업자는 서버 안에서 어떤 프로그램이 돌아가는지 들여다보지 않기 때문에 오래된 소프트웨어의 취약점은 사용자가 직접 막아야 합니다.
계정 권한, 데이터 공개 설정, 방화벽 규칙, 운영체제 패치는 클라우드 사업자가 대신 관리해주지 않는 사용자 고유의 책임 영역입니다.
서비스 모델에 따라 달라지는 책임 범위 비교
공동 책임의 경계선은 사용하는 서비스 모델에 따라 이동합니다. 제가 정리한 아래 표를 참고해보세요.
| 보안 항목 | IaaS (예: EC2) | PaaS (예: RDS, App Service) | SaaS (예: Microsoft 365) |
|---|---|---|---|
| 물리 인프라·가상화 | 사업자 | 사업자 | 사업자 |
| 운영체제 패치 | 사용자 | 사업자 | 사업자 |
| 애플리케이션 보안 | 사용자 | 사용자 | 사업자 |
| 네트워크 접근 설정 | 사용자 | 사용자(일부 사업자) | 사업자 |
| 데이터 분류·암호화 설정 | 사용자 | 사용자 | 사용자 |
| 계정·권한 관리 | 사용자 | 사용자 | 사용자 |
표를 보면 서비스 모델과 관계없이 끝까지 사용자에게 남는 항목이 있습니다. 바로 데이터와 계정입니다. SaaS처럼 거의 모든 것을 맡기는 경우에도 누구에게 어떤 권한을 줄지, 어떤 데이터를 외부와 공유할지는 사용자가 결정해야 합니다.
같은 사업자 안에서도 서비스마다 경계가 다르다는 점도 기억해야 합니다. 예를 들어 가상 서버에 직접 데이터베이스를 설치하면 데이터베이스 패치가 사용자 책임이지만, 관리형 데이터베이스 서비스를 쓰면 엔진 패치는 사업자가 맡습니다.
공동 책임 모델을 오해해서 생기는 대표적인 보안 사고
가장 흔한 사례는 스토리지 공개 설정 실수입니다. 파일 공유를 편하게 하려고 저장소 전체를 공개로 바꿨다가 고객 정보나 내부 문서가 검색 엔진에 노출되는 사고가 국내외에서 반복적으로 보고되어 왔습니다. 사업자들이 새 저장소의 공개 차단을 기본값으로 바꾼 것도 이런 사고가 많았기 때문입니다.
두 번째는 액세스 키 유출입니다. 개발 과정에서 클라우드 접근용 키를 소스 코드에 넣어둔 채 공개 저장소에 올리면, 이를 자동으로 수집하는 봇이 빠르게 찾아내 가상 서버를 대량으로 생성하는 데 악용할 수 있습니다. 이 경우 사용자에게 막대한 요금이 청구되는 피해로 이어지기도 합니다.
세 번째는 방치된 리소스입니다. 테스트용으로 만든 서버를 잊어버리고 오랫동안 패치 없이 두면 알려진 취약점을 통해 침입 경로가 될 수 있습니다. 누가 만들었는지 모르는 리소스가 많아질수록 관리 공백도 커집니다.
클라우드 보안 사고의 상당수는 사업자 인프라의 결함이 아니라 공개 설정, 키 관리, 방치된 리소스처럼 사용자 책임 영역의 관리 공백에서 시작됩니다.
사용자가 지금 바로 점검해야 할 보안 체크 항목
첫째, 루트 계정과 관리자 계정에 다단계 인증이 설정되어 있는지 확인하세요. 루트 계정은 일상 업무에 사용하지 말고, 별도의 사용자 계정이나 IAM Identity Center 같은 통합 로그인 방식을 이용하는 것이 좋습니다.
둘째, 장기 액세스 키가 꼭 필요한지 검토하세요. 사용하지 않는 키는 비활성화하거나 삭제하고, 애플리케이션에는 가능하면 역할 기반의 임시 자격 증명을 사용하는 것이 안전합니다. 코드 저장소에 키가 포함되어 있지 않은지도 점검해야 합니다.
셋째, 스토리지 공개 차단 설정과 보안 그룹의 인바운드 규칙을 확인하세요. 특히 관리 포트가 0.0.0.0/0으로 열려 있다면 접속이 필요한 IP 대역으로 좁히는 것이 좋습니다. 마지막으로 AWS CloudTrail 같은 활동 기록 기능을 켜두면 문제가 생겼을 때 원인을 추적할 수 있습니다.
클라우드 공동 책임 모델 총정리
클라우드 공동 책임 모델은 물리 인프라와 가상화 계층은 사업자가, 그 위의 계정과 데이터, 네트워크 설정, 서버 내부 관리는 사용자가 책임지는 구조입니다. 서비스 모델이 SaaS에 가까워질수록 사업자의 책임 범위가 넓어지지만, 데이터와 계정 관리 책임은 끝까지 사용자에게 남습니다. 대부분의 사고가 사용자 영역의 설정 실수에서 발생하므로 기본 보안 설정을 정기적으로 점검하는 것이 가장 효과적인 대응입니다.
질문 QnA
클라우드 사업자가 제 데이터를 마음대로 볼 수 있나요?
주요 사업자는 고객 데이터에 대한 접근을 엄격히 제한하고 있으며, 법적 요청 등 정해진 경우를 제외하면 고객 데이터를 열람하지 않는다고 정책에 명시하고 있습니다. 더 높은 수준을 원한다면 고객이 직접 관리하는 키로 데이터를 암호화할 수 있습니다.
관리형 서비스를 쓰면 보안 설정을 전혀 안 해도 되나요?
운영체제와 엔진 패치 같은 부분은 줄어들지만, 접근 권한, 네트워크 공개 여부, 백업 보관 기간, 암호화 설정 등은 여전히 사용자가 결정해야 합니다.
클라우드에서 해킹 피해가 발생하면 사업자가 보상해주나요?
피해 원인이 어느 책임 영역에서 발생했는지에 따라 달라집니다. 사용자 설정 실수로 인한 피해는 원칙적으로 사용자 책임이므로 서비스 약관과 공동 책임 모델 문서를 미리 확인해두는 것이 좋습니다.
개인 공부용 계정도 보안 설정이 필요한가요?
네, 필요합니다. 개인 계정도 탈취되면 요금 폭탄으로 이어질 수 있으므로 다단계 인증과 예산 알림 설정은 규모와 관계없이 가장 먼저 해두는 것이 좋습니다.
공동 책임 모델을 이해하면 클라우드 보안이 막연한 걱정이 아니라 구체적인 체크리스트로 바뀝니다. 사업자가 지켜주는 영역은 믿고 맡기되, 내 계정과 데이터, 설정은 내가 지킨다는 원칙을 세우는 것만으로도 대부분의 사고를 예방할 수 있습니다.
오늘 바로 사용 중인 클라우드 콘솔에 접속해 다단계 인증 설정, 사용하지 않는 액세스 키, 공개된 저장소, 전체 IP에 열린 포트 네 가지만 확인해보세요. 10분 정도의 점검이 나중에 큰 사고를 막아주는 가장 확실한 투자가 될 것입니다.
※ 본 글은 2026년 9월 기준 AWS 공동 책임 모델, Microsoft Azure 및 Google Cloud의 공유 책임 관련 공식 문서를 참고해 작성했으며, 서비스별 책임 범위는 변경될 수 있으니 최신 내용은 각 사업자의 공식 페이지에서 확인해 주세요.