클라우드로 시스템을 옮긴 뒤에도 퇴사자 계정이 남고, 저장소가 외부에 공개되거나, 복구할 데이터를 찾지 못할 수 있다. 인프라를 맡겼다는 사실만으로 이런 운영 업무까지 모두 이전되는 것은 아니기 때문이다. 클라우드 도입을 검토하는 담당자라면 비용과 기능을 비교하기 전에, 어떤 일을 사업자가 수행하고 어떤 일을 회사가 계속 맡는지 확인해야 한다.
공동 책임은 일을 반씩 나눈다는 뜻이 아님
Shared Responsibility Model은 클라우드 사업자와 고객이 보안·운영 업무를 어떻게 나누는지 설명하는 모델이다. 책임을 똑같이 절반씩 부담한다는 의미가 아니라, 관리하는 계층과 통제할 수 있는 설정에 따라 수행 업무가 달라진다는 뜻이다.
AWS는 클라우드 기반 인프라의 보호와 고객이 클라우드 안에서 수행하는 보호 업무를 구분한다. 가상머신을 사용하는 고객은 게스트 운영체제 패치와 설치한 애플리케이션, 보안 그룹 설정 등을 관리한다. 반면 관리형 저장소에서는 사업자가 기반 운영체제를 관리하더라도 고객의 데이터 분류와 접근권한 설정은 고객 업무로 남는다. [1]
따라서 ‘이 기능을 제공하는가’와 ‘누가 설정하고 결과를 확인하는가’를 따로 물어야 한다. 다중요소 인증 기능이 있어도 적용 대상을 정하지 않으면 필요한 계정이 제외될 수 있다. 운영 책임표는 이런 빈틈을 찾아내기 위한 출발점이다.
IaaS·PaaS·SaaS에서 달라지는 책임
IaaS는 가상머신 등 기반 자원을, PaaS는 애플리케이션 실행에 필요한 관리형 플랫폼을, SaaS는 완성된 소프트웨어를 제공하는 방식이다. 일반적으로 관리형 서비스로 갈수록 사업자가 운영하는 영역이 늘어난다. Microsoft의 공식 설명에서도 데이터와 사용자·접근 관리에 관한 고객의 역할은 서비스 유형과 관계없이 남는다. [2]
| 확인 영역 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 물리 시설·기반 장비 | 사업자 | 사업자 | 사업자 |
| 게스트 OS·실행 기반 | 고객이 OS 관리 | 사업자가 관리하는 범위 확대 | 사업자가 서비스 기반 관리 |
| 애플리케이션 | 고객이 설치·패치 | 고객 코드·설정과 사업자 플랫폼을 구분 | 사업자 제품 운영과 고객 조직 설정을 구분 |
| 데이터·계정·접근 정책 | 고객의 결정·관리 필요 | 고객의 결정·관리 필요 | 고객의 결정·관리 필요 |
이 표는 도입 검토를 위한 일반화다. 같은 PaaS라도 고객이 관리하는 확장 기능이나 라이브러리, 네트워크 설정이 다를 수 있다. 최종 책임은 서비스 이름만 보고 정하지 말고 해당 제품의 보안 문서, 계약, 선택한 기능과 운영 대행 범위를 확인해 정해야 한다.
가령 가상머신의 데이터베이스를 관리형 데이터베이스로 바꾸면 기반 OS 패치 업무는 줄어들 수 있다. 그래도 접속 계정, 허용된 연결, 데이터 보존 기간, 복구 목표를 정하는 일까지 자동으로 사라지는 것은 아니다. 기능 제공 여부와 고객의 선택·검증 업무를 각각 확인해야 한다.
책임 경계가 비는 세 가지 상황
다음은 특정 사고를 재현한 것이 아닌 가상 예시다. 클라우드 도입 검토에서 책임 누락을 찾기 위해 상황을 단순화했다.
공유 기능은 정상인데 문서가 외부에 노출되는 경우
문서 서비스 자체에는 장애가 없지만 부서가 만든 외부 공유 링크로 자료가 전달될 수 있다. 사업자의 기반 보안만 확인해서는 이 문제를 발견하기 어렵다. 고객은 외부 공유 허용 범위, 예외 승인자, 링크 만료와 회수 방법을 정하고 실제 설정을 확인해야 한다.
가상머신은 작동하지만 패치 담당자가 없는 경우
인프라팀은 개발팀이 패치한다고 생각하고 개발팀은 클라우드 사업자가 처리한다고 생각할 수 있다. IaaS의 게스트 OS를 누가 점검·패치하는지, 서비스 중단을 누가 승인하는지 기록해야 한다. 운영 대행사를 사용한다면 계약에 포함된 대상과 예외를 함께 확인한다.
백업 기능은 있지만 원하는 시점으로 복구하지 못하는 경우
백업 메뉴가 있다는 사실만으로 업무 복구가 가능한지는 알 수 없다. 대상 데이터, 보존 기간, 삭제 후 복구 조건과 복구 권한을 확인해야 한다. 업무 부서가 허용 가능한 데이터 손실과 중단 시간을 정하고, 운영 담당자가 그 조건에 맞춰 복구를 시험하는 방식으로 역할을 연결할 수 있다.
사업자와 나눈 책임을 내부 담당자까지 연결
사업자 문서에 ‘고객 책임’이라고 적혀 있어도 회사 안에서 누가 할지는 별도로 정해야 한다. 다음 표는 중소 규모 조직에서 활용할 수 있는 배분 예시이며, 특정 조직에 일률적으로 적용하는 기준은 아니다. 조직에 따라 한 사람이 여러 역할을 맡더라도 수행자와 승인·확인 역할은 구분해 기록하는 편이 낫다.
| 업무 | 수행 역할 예시 | 승인·확인 역할 예시 | 남길 증적 |
|---|---|---|---|
| 입사·이동·퇴사 권한 변경 | 계정 운영 담당 | 업무 책임자 | 요청·승인·회수 기록 |
| 저장소·문서 외부 공개 설정 | 서비스 운영 담당 | 데이터 소유 부서 | 설정 내역·예외 만료일 |
| OS·고객 코드 패치 | 인프라·개발 담당 | 서비스 책임자 | 대상·적용 결과·예외 |
| 백업·복구 시험 | 서비스 운영 담당 | 업무 책임자 | 복구 결과·목표 충족 여부 |
| 보안 경고 대응 | 관제·서비스 운영 담당 | 사고 대응 책임자 | 알림 수신·조치·연락 기록 |
보안 부서는 기준과 확인 방법을 제시할 수 있지만, 데이터 사용 목적이나 업무 중단 허용 범위를 모두 대신 결정할 수는 없다. 서비스 책임자가 업무 조건을 정하고 운영 담당자가 설정·시험 결과를 제시하도록 연결해야 책임표가 실제 업무에 쓰인다.
Google Cloud도 여러 서비스가 결합된 환경에서는 통제 간 상호작용을 확인해야 하며, 사고 조사와 완화에 고객과 사업자의 협력이 필요한 경우가 있다고 설명한다. [3] 고객 영역만 적어 두지 말고 사업자 지원 요청 권한, 연락 경로, 확보 가능한 로그도 함께 확인하는 것이 실무상 유용하다.
도입 승인 전에 확인할 다섯 가지
- 사용할 서비스와 기능을 구체적으로 적는다. ‘클라우드 사용’ 대신 가상머신, 관리형 DB, 문서 SaaS처럼 대상이 드러나야 한다.
- 제품 문서에서 사업자 수행 범위와 고객 설정 항목을 나누고, 미확인 항목은 확인 담당자와 함께 남긴다.
- 관리자 계정, 외부 공유, 로그, 암호화 관련 선택 사항, 백업·복구 조건을 현재 설정과 대조한다.
- 고객 업무마다 수행자, 승인·확인자, 점검 시점, 남길 증적을 지정한다.
- 퇴사자 접근 차단, 잘못된 공유 회수, 데이터 복구처럼 실제로 가능한 동작을 확인한 뒤 사용 범위를 승인한다.
점검 시점은 일률적인 주기를 복사하기보다 변경 위험에 맞춰 정한다. 인사 이동은 권한 변경의 계기가 되고, 외부 연동 추가나 서비스 요금제 변경은 책임표를 다시 확인할 계기가 된다. 담당자 이름만 적힌 문서보다 언제 다시 확인할지가 적힌 문서가 운영 공백을 줄이는 데 도움이 된다.
실무자 관점: 책임표의 완성도는 증적으로 판단
실무적으로는 ‘고객 책임’이라는 문구보다 누가 어떤 결과를 보여줄 수 있는지가 더 유용한 판단 기준이다. 계정 회수 기록, 설정 변경 이력, 복구 시험 결과가 없다면 업무가 배정됐다는 사실과 실제 수행됐다는 사실을 구분하기 어렵다.
사업자가 제공하는 인증이나 감사 보고서는 사업자 통제 범위를 확인하는 자료로 활용할 수 있다. 다만 그것만으로 고객이 설정한 접근권한이나 업무 복구 준비까지 확인되는 것은 아니다. 서비스 도입 때 사업자 자료와 고객 운영 증적을 함께 요구하는 방식이 적절하다.
결론
클라우드 도입 승인 시에는 ‘사업자가 맡는 영역’, ‘고객이 설정할 항목’, ‘내부 담당자가 제시할 확인 결과’가 연결돼 있어야 한다. 경계가 불분명한 업무는 도입 전에 질문으로 남기고, 데이터 공개나 복구처럼 영향이 큰 항목부터 확인한다. Shared Responsibility Model은 이 책임 경계를 실제 운영 업무로 바꾸는 데 사용할 수 있다.