클라우드 보안, 어디까지가 내 책임인가
책임 공유 모델이 그리는 경계선을 IaaS·PaaS·SaaS 순서로 따라가며, 왜 설정 실수가 사고로 이어지는지 설명합니다.
'클라우드니까 알아서 안전하겠지'라는 오해
클라우드로 옮기고 나면 보안 걱정이 줄어든다는 기대가 있습니다. 절반은 맞습니다. 서버실의 출입 통제, 하드웨어 고장 대응, 물리적 재해 대비처럼 직접 감당하기 어려웠던 영역을 전문 사업자가 맡아 주기 때문입니다. 문제는 나머지 절반입니다.
클라우드 사업자들이 공통으로 안내하는 개념이 책임 공유 모델입니다. 보안 책임 전체를 사업자가 지는 것이 아니라, 층을 나누어 각자 자기 층을 책임진다는 뜻입니다. 흔히 쓰이는 표현을 빌리면 사업자는 '클라우드 자체의 보안'을 맡고, 이용자는 '클라우드 안에서 하는 일의 보안'을 맡습니다.
이 구분을 놓치면 아무도 지키지 않는 층이 생깁니다. 사업자는 자기 층을 지키고 있고 이용자는 사업자가 다 해 줄 것이라 믿고 있는 상태 — 사고가 나는 자리는 대개 그 사이입니다.
경계선을 그리는 기준: 내가 통제할 수 있는가
복잡해 보이는 책임 구분도 기준 하나로 정리됩니다. 내가 설정을 바꿀 수 있는 영역은 내 책임이고, 내가 손댈 수 없는 영역은 사업자 책임입니다. 데이터센터의 잠금장치는 내가 바꿀 수 없으니 사업자 몫이고, 저장소를 외부에 공개할지 여부는 내가 클릭 한 번으로 바꿀 수 있으니 내 몫입니다.
이 기준을 쓰면 새로운 서비스를 도입할 때도 스스로 답을 낼 수 있습니다. 콘솔에서 켜고 끌 수 있는 항목, 권한을 부여하고 회수하는 화면, 암호화 여부를 고르는 선택지 — 눈앞에 선택권이 주어졌다면 그 선택의 결과도 함께 주어진 것입니다.
그리고 어느 형태의 클라우드를 쓰든 끝까지 이용자에게 남는 항목이 있습니다. 누구에게 접근 권한을 줄 것인가, 어떤 데이터를 올릴 것인가, 그 데이터를 누구와 공유할 것인가입니다. 이 세 가지는 사업자가 대신 판단해 줄 수 있는 성격의 문제가 아닙니다.
IaaS·PaaS·SaaS에 따라 이동하는 선
클라우드 서비스는 대개 세 갈래로 나뉩니다. 서버·저장소·네트워크 같은 자원을 빌려 쓰는 IaaS, 그 위에 실행 환경까지 준비된 PaaS, 완성된 소프트웨어를 그대로 쓰는 SaaS입니다. 아래층부터 물리 시설, 하드웨어, 가상화, 운영체제, 실행 환경, 애플리케이션, 데이터 순으로 쌓인 탑을 떠올리면 이해가 쉽습니다. 세 형태의 차이는 그 탑의 어느 높이에서 책임의 선이 그어지느냐입니다.
IaaS에서는 선이 아래쪽에 있습니다. 사업자는 시설과 하드웨어, 가상화까지 책임지고, 그 위에 올리는 운영체제의 보안 업데이트, 방화벽 성격의 접근 제어 설정, 설치한 소프트웨어의 취약점 관리는 이용자 몫입니다. 가상 서버를 하나 만들어 놓고 몇 년 동안 업데이트하지 않았다면, 그 위험은 온전히 이용자 쪽에 쌓입니다.
PaaS에서는 선이 위로 올라갑니다. 운영체제와 실행 환경은 사업자가 관리해 주므로 이용자는 애플리케이션 코드와 데이터, 그리고 접근 권한에 집중하게 됩니다. SaaS에서는 선이 거의 꼭대기까지 올라가지만, 그렇다고 책임이 사라지지는 않습니다. 계정 관리, 공유 설정, 어떤 정보를 입력할지에 대한 판단은 여전히 이용자 몫으로 남습니다.
설정이 곧 보안 상태가 되는 구조
온프레미스 환경에서 서버를 외부에 노출시키려면 물리적인 배선과 장비 설정, 여러 사람의 손을 거쳐야 했습니다. 클라우드에서는 화면의 선택지 하나를 바꾸는 것으로 같은 결과가 만들어집니다. 이 속도와 간편함이 클라우드의 장점이자, 사고 구조가 달라지는 지점입니다.
클라우드 관련 보안 사고를 유형으로 묶어 보면, 정교한 침입보다 설정에서 비롯된 노출이 큰 비중을 차지한다는 이야기가 반복됩니다. 저장소가 의도치 않게 외부에 공개된 상태로 남아 있거나, 시험용으로 넓게 열어둔 접근 권한이 그대로 운영에 넘어가거나, 키와 자격 증명이 코드나 저장소에 함께 올라가는 식입니다. 어느 것도 특별한 기술을 필요로 하지 않습니다.
그래서 클라우드 보안에서는 '설정을 확인하는 일' 자체가 핵심 활동이 됩니다. 기본값이 무엇인지 알고, 공개 범위를 주기적으로 점검하고, 자격 증명을 코드와 분리해 관리하고, 변경 이력이 남도록 해 두는 것입니다. 사람이 매번 눈으로 확인하는 데에는 한계가 있으므로 점검을 자동화하는 방향으로 발전해 왔지만, 무엇을 점검해야 하는지 아는 것은 여전히 사람의 몫입니다.
온프레미스와 무엇이 달라지는가
첫째, 변화의 속도가 다릅니다. 자원을 만들고 없애는 데 몇 분이면 충분하니 현황 파악이 훨씬 어려워집니다. 누가 언제 무엇을 만들었는지 모르는 자원이 조용히 남아 있는 상황이 흔하고, 관리 대상 목록을 최신으로 유지하는 일이 그 자체로 과제가 됩니다.
둘째, 경계라는 개념이 흐려집니다. 내부망과 외부망을 나누던 사고방식만으로는 여러 서비스가 인터넷을 통해 서로를 호출하는 구조를 설명하기 어렵습니다. 그래서 위치가 아니라 신원과 권한을 기준으로 통제하는 접근이 강조되고, 계정과 권한 관리의 비중이 온프레미스 시절보다 훨씬 커집니다.
셋째, 흔적이 남는 방식이 다릅니다. 클라우드는 관리 작업의 대부분이 API 호출로 이루어지므로 기록을 남기기 유리한 구조입니다. 다만 이 기록은 대개 켜 두어야 남고, 보관 기간과 접근 권한을 따로 정해야 합니다. 켜 두지 않았다면 사고가 난 뒤에 되돌아볼 수 있는 것이 거의 없습니다. 클라우드로 옮긴다는 것은 지킬 것이 줄어드는 일이 아니라, 지켜야 할 목록이 다시 쓰이는 일에 가깝습니다.
초보자가 자주 하는 실수
- 클라우드 사업자가 보안 전체를 책임진다고 이해하기 — 사업자와 이용자 사이에 아무도 지키지 않는 층이 생깁니다.
- 시험용으로 넓게 열어둔 접근 권한을 그대로 운영에 넘기기 — 설정 한 줄이 곧 노출 상태가 되는 구조라 그대로 사고 원인이 됩니다.
- 감사 기록을 켜지 않은 채로 운영하기 — 사고가 난 뒤 무슨 일이 있었는지 되짚을 근거가 남지 않습니다.
읽고 나서 체크리스트
- 책임 공유 모델이 무엇을 나누는 개념인지 설명할 수 있다
- 내 책임 영역을 '내가 통제할 수 있는가'로 판단할 수 있다
- IaaS·PaaS·SaaS에서 책임의 선이 어떻게 이동하는지 안다
- 어떤 형태를 쓰든 이용자에게 남는 책임 항목을 말할 수 있다
- 클라우드에서 설정 점검이 왜 핵심 보안 활동인지 안다
자주 묻는 질문
SaaS만 쓰면 보안 담당자가 할 일이 거의 없나요?
줄어드는 것은 인프라 운영 부담이고, 계정과 권한 관리, 공유 설정 점검, 어떤 정보를 그 서비스에 올릴 것인가에 대한 판단은 그대로 남습니다. 오히려 부서마다 개별 도입한 서비스를 파악하는 일이 새로운 과제가 되기도 합니다.
책임 범위는 어디서 확인하나요?
각 클라우드 사업자가 자사 문서와 계약서에 책임 구분을 명시해 두고 있으며, 서비스별로 세부 내용이 다릅니다. 일반적인 설명을 참고하되 실제 적용 범위는 이용 중인 사업자의 공식 문서와 계약 조건에서 확인해야 합니다.
온프레미스가 클라우드보다 안전한가요?
형태의 우열 문제가 아니라 책임 배분과 운영 역량의 문제입니다. 온프레미스는 통제 범위가 넓은 만큼 전부 직접 감당해야 하고, 클라우드는 일부를 위임하는 대신 설정과 권한 관리의 중요도가 커집니다. 어느 쪽이든 관리되지 않으면 위험합니다.
이 글은 입문자 기준으로 이해하기 쉽게 정리한 일반 정보이며, 내용은 운영 과정에서 순차적으로 점검·보완될 수 있습니다. 구체적인 절차나 수치는 해당 기관의 공식 안내를 기준으로 확인해주세요.