51. 클라우드 기반 서비스 평가할 때 먼저 그려보는 보안 체크 그림

요즘 진행되는 개인정보 영향평가를 보면
온프레미스 시스템뿐 아니라
클라우드(IaaS, PaaS, SaaS)를 활용하는 서비스가
꾸준히 늘어나는 걸 체감하게 된다.

클라우드 엔지니어처럼
깊게 설계를 하는 역할은 아니지만,
평가 관점에서 구조를 듣다 보면
자연스럽게 “어디부터 체크해야 할까”를
다시 정리하게 된다.

어디까지가 클라우드이고, 어디까지가 우리 책임인지

먼저 보는 건
이 서비스에서 클라우드가 어디까지 들어와 있는지다.

• 애플리케이션 서버만 클라우드에 있는지
• DB·스토리지까지 클라우드에 있는지
• 인증·알림·로그 같은 주변 기능이
  별도 클라우드 서비스(SaaS)를 쓰는지

이걸 먼저 정리해 두면
책임 소재를 나누기가 쉬워진다.

• 클라우드 사업자가 책임지는 보안 영역
• 우리가 설계·설정해야 하는 보안 영역
• 우리와 파트너가 함께 나눠 가져야 할 영역

이렇게 세 구역으로 나눠 놓고 보면
영향평가 보고서도 구조가 훨씬 깔끔해진다.

계정·권한 구조가 온프레미스와 어떻게 연결되는지

클라우드로 가면
계정·권한 관리가 한 번 더 복잡해진다.

온프레미스 시스템만 있을 때는
사내 계정과 권한 체계만 보면 됐지만,
클라우드가 끼어들면

• 클라우드 콘솔 계정(관리자, 운영자)
• 서비스 운영 계정(애플리케이션이 사용하는 키·토큰)
• 제3의 파트너·개발사 계정

이따위로 주체가 늘어난다.

그래서 평가할 때는

• 누가 콘솔에 어디까지 접근하는지
• 키·토큰이 어디에 저장돼 있고
  어떤 식으로 순환·회수되는지
• 외부 파트너 계정이 있다면
  어떤 조건으로 열고 닫는지

이 흐름이 정리되어 있는지 먼저 확인하게 된다.

암호화와 로그가 “클라우드 안/밖” 둘 다 보이는지

클라우드 환경에서는
암호화·로그도 두 층으로 나뉘어 보인다.

• 클라우드 사업자 레벨의 기능
  (디스크 암호화, 관리형 키, 기본 감사 로그 등)
• 우리가 애플리케이션·DB·네트워크 레벨에서
  추가로 설정하는 부분

둘 중 하나만 봐서는 부족하고,
두 층이 어떻게 이어져 있는지가 중요하다고 느낀다.

예를 들어,

• 저장 데이터는
  스토리지 암호화 + DB 레벨 암호화가
  서로 겹쳐서 적용되는지
• 접속 기록은
  클라우드 감사 로그 + 서비스 접속 로그가
  서로 보완 관계에 있는지

이런 걸 확인해 두면
나중에 사고·점검 시
“어디까지 추적이 가능한지”를 설명하기가 훨씬 수월하다.

네트워크 구조를 너무 복잡하게 그리지 않으려고 하기

클라우드 네트워크 다이어그램을 그리다 보면
VPC, Subnet, Security Group, Peering, VPN, 전용선 등
용어부터가 부담스럽다.

그래도 평가 관점에서는
기본적인 질문은 간단하다.

• 인터넷에서 바로 노출되는 구간이 어디인지
• 내부 시스템과의 통신은
  전용선·VPN·API 게이트웨이 중 무엇을 쓰는지
• 관리용 접속(운영자, 개발자)은
  어떤 경로로 들어오는지

이 세 가지를 먼저 정리해 둔 뒤에
세부 설정으로 들어가는 게
개인적으로는 훨씬 이해하기 쉬웠다.

마무리

클라우드 기반 서비스는
구성이 다양해서 항상 새로 공부해야 하지만,
개인적으로는 평가할 때

• 어디까지가 클라우드이고, 책임이 어떻게 나뉘는지
• 클라우드 계정·권한 구조가 온프레미스와 어떻게 연결되는지
• 암호화·로그가 클라우드 안/밖에서 어떻게 겹쳐지는지
• 네트워크 구조를 단순한 질문으로 먼저 정리해 보는 것

이 네 가지를 기준으로 본다.

아직 클라우드 전문가는 아니지만,
이 기준을 가지고 케이스를 계속 쌓다 보면
언젠가는 “클라우드 기반 개인정보 영향평가”도
조금 더 자신 있게 할 수 있을 거라고 생각하고 있다.