클라우드 보안, 어디까지가 내 책임인가

'클라우드니까 알아서 안전하겠지'라는 오해

클라우드로 옮기고 나서 '이제 보안은 사업자가 알아서 해 주겠지' 하고 마음을 놓으신 적 있으시죠. 그런데 막상 점검 요청이 오면 어디까지가 우리 몫인지 몰라 답이 막혀요. 이 글에서는 책임의 선이 어디에 그어지는지, 그래서 무엇부터 확인하면 되는지 순서대로 풀어 드릴게요.

클라우드로 옮기면 보안 걱정이 줄어든다는 기대, 절반은 맞아요. 서버실 출입 통제, 하드웨어 고장 대응, 물리적 재해 대비처럼 직접 감당하기 버거웠던 영역을 전문 사업자가 맡아 주니까요. 실제로 이 부분은 확실히 편해져요. 문제는 나머지 절반이에요.

클라우드 사업자들이 공통으로 안내하는 개념이 책임 공유 모델이에요. 보안 책임 전체를 사업자가 지는 게 아니라, 층을 나눠 각자 자기 층을 책임진다는 뜻이에요. 흔히 쓰는 표현을 빌리면 사업자는 '클라우드 자체의 보안'을 맡고, 이용자는 '클라우드 안에서 하는 일의 보안'을 맡아요.

근데 말이죠, 이 구분을 놓치면 아무도 지키지 않는 층이 생겨요. 사업자는 자기 층을 지키고 있고, 이용자는 사업자가 다 해 줄 거라 믿고 있는 상태예요. 사고가 나는 자리는 대개 그 사이고요. 반대로 선만 그어 두면 걱정이 꽤 많이 줄어들어요.

경계선을 그리는 기준: 내가 통제할 수 있는가

그냥 딱 잘라 말해서, 복잡해 보이는 책임 구분도 기준 하나면 정리돼요. 내가 설정을 바꿀 수 있는 영역은 내 책임, 내가 손댈 수 없는 영역은 사업자 책임이에요. 데이터센터의 잠금장치는 내가 바꿀 수 없으니 사업자 몫이고요. 저장소를 외부에 공개할지 여부는 내가 화면에서 한 번만 바꿔도 되니 내 몫이에요.

하나만 기억하시면 돼요. 이 기준을 쓰면 새 서비스를 도입할 때도 스스로 답을 낼 수 있어요. 콘솔에서 켜고 끌 수 있는 항목, 권한을 주고 거두는 화면, 암호화 여부를 고르는 선택지처럼 눈앞에 선택권이 주어졌다면, 그 선택의 결과도 함께 주어진 거예요.

아, 그리고 하나 더. 어느 형태의 클라우드를 쓰든 끝까지 이용자에게 남는 항목이 있어요. 누구에게 접근 권한을 줄 것인가, 어떤 데이터를 올릴 것인가, 그 데이터를 누구와 공유할 것인가예요. 이 세 가지는 사업자가 대신 판단해 줄 수 있는 성격의 문제가 아니에요.

IaaS·PaaS·SaaS에 따라 이동하는 선

클라우드 서비스는 대개 세 갈래로 나뉘어요. 서버·저장소·네트워크 같은 자원을 빌려 쓰는 IaaS, 그 위에 실행 환경까지 준비된 PaaS, 완성된 소프트웨어를 그대로 쓰는 SaaS예요. 아래층부터 물리 시설, 하드웨어, 가상화, 운영체제, 실행 환경, 애플리케이션, 데이터 순으로 쌓인 탑을 떠올려 보세요. 세 형태의 차이는 그 탑의 어느 높이에서 책임의 선이 그어지느냐예요.

IaaS에서는 선이 아래쪽에 있어요. 사업자는 시설과 하드웨어, 가상화까지 책임져요. 그 위에 올리는 운영체제의 보안 업데이트, 방화벽 성격의 접근 제어 설정, 설치한 소프트웨어의 취약점 관리는 이용자 몫이고요. 가상 서버를 하나 만들어 놓고 몇 년 동안 업데이트하지 않았다면, 그 위험은 온전히 이용자 쪽에 쌓여요. 그 취약점과 패치 정보는 한국인터넷진흥원의 보호나라에서 확인할 수 있어요.

PaaS에서는 선이 위로 올라가요. 운영체제와 실행 환경은 사업자가 관리해 주니, 이용자는 애플리케이션 코드와 데이터, 접근 권한에 집중하면 돼요. SaaS에서는 선이 거의 꼭대기까지 올라가요. 그렇다고 책임이 사라지지는 않아요. 계정 관리, 공유 설정, 어떤 정보를 입력할지에 대한 판단은 여전히 이용자 몫으로 남아요.

설정이 곧 보안 상태가 되는 구조

온프레미스에서 서버를 외부에 노출시키려면 물리적인 배선과 장비 설정, 여러 사람의 손을 거쳐야 했어요. 클라우드에서는 화면의 선택지 하나만 바꿔도 같은 결과가 나와요. 이 속도와 간편함이 클라우드의 큰 장점이면서, 동시에 사고의 구조가 달라지는 지점이에요.

클라우드 관련 보안 사고를 유형으로 묶어 보면, 정교한 침입보다 설정에서 비롯된 노출이 큰 비중을 차지한다는 이야기가 반복돼요. 저장소가 의도치 않게 외부에 공개된 채 남아 있거나, 시험용으로 넓게 열어둔 접근 권한이 그대로 운영에 넘어가거나, 키와 자격 증명이 코드와 함께 올라가는 식이에요. 어느 것도 특별한 기술이 필요한 일이 아니에요.

그래서 클라우드 보안에서는 '설정을 확인하는 일' 자체가 핵심 활동이 돼요. 방법은 간단해요. 기본값이 무엇인지 알고, 공개 범위를 주기적으로 점검하고, 자격 증명을 코드와 분리해 두고, 변경 이력이 남게 해 두시면 돼요. 사람이 매번 눈으로 확인하는 데는 한계가 있어서 점검을 자동화하는 방향으로 발전해 왔어요. 다만 무엇을 점검해야 하는지 아는 것은 여전히 사람의 몫이에요.

온프레미스와 무엇이 달라지는가

첫째, 변화의 속도가 달라요. 자원을 만들고 없애는 데 몇 분이면 되니 현황 파악이 훨씬 어려워져요. 누가 언제 무엇을 만들었는지 모르는 자원이 조용히 남아 있는 상황도 흔하고요. 그래서 관리 대상 목록을 최신으로 유지하는 일이 그 자체로 하나의 과제가 돼요.

둘째, 경계라는 개념이 흐려져요. 내부망과 외부망을 나누던 사고방식만으로는 여러 서비스가 인터넷을 통해 서로를 호출하는 구조를 설명하기 어려워요. 그래서 위치가 아니라 신원과 권한을 기준으로 통제하는 접근이 강조돼요. 계정과 권한 관리의 비중이 온프레미스 시절보다 훨씬 커진 이유예요.

셋째, 흔적이 남는 방식이 달라요. 클라우드는 관리 작업 대부분이 API 호출로 이뤄져서 기록을 남기기에 유리해요. 다만 이 기록은 대개 켜 두어야 남고, 보관 기간과 접근 권한도 따로 정해야 해요. 켜 두지 않았다면 사고가 난 뒤 되돌아볼 게 거의 없어요.

이제 이렇게 해보시면 돼요. 오늘은 우리가 쓰는 서비스가 IaaS·PaaS·SaaS 중 어디인지만 적어 보세요. 그다음 '내가 화면에서 바꿀 수 있는 항목'을 하나씩 세어 보시면, 그게 곧 우리 점검 목록이 돼요. 접근 권한·공개 범위·기록 켜기 세 가지만 확인해도 상당히 든든해져요. 클라우드로 옮긴다는 건 지킬 것이 줄어드는 일이 아니라 지켜야 할 목록이 다시 쓰이는 일이에요. 목록이 새로 정리되면 오히려 관리가 한결 명확해집니다.