보안 백서를 실제 코드와 계속 일치시키는 방법

보안 백서는 한번 잘 써두면 끝나는 소개 자료가 아니다. 서비스가 바뀌는데 문서가 그대로면 실제 통제보다 강한 약속이 남는다. 반대로 구현한 보호 장치가 문서에 없으면 고객은 존재를 알 수 없다.

우리는 공개 보안 백서를 갱신하면서 문장부터 다듬지 않았다. 먼저 각 주장이 어디에서 실행되고 누가 책임지는지를 코드, IaC, 클라우드 설정과 계약 문서에서 다시 찾았다.

문장을 claim inventory로 바꾼다

“안전하게 보호합니다” 같은 문장은 검증할 수 없다. 이를 작은 주장으로 분해했다.

• 외부 요청은 TLS로 전달되는가
• 사용자와 챗봇 권한은 어느 서버 경계에서 확인하는가
• 저장 데이터 암호화는 Google 관리 키인가, 고객 관리 키인가
• 대화 비저장은 어떤 저장 경로에 적용되는가
• 백업이 존재하는가, 특정 RTO·RPO까지 보장하는가
• AI 공급자에게 어떤 데이터가 전달되고 어떤 예외가 있는가
• GCP 인증과 우리 SaaS의 인증 상태는 어떻게 다른가

주장이 작아지면 근거와 반례를 연결할 수 있다. 하나의 문장에 인증, 암호화와 보존을 모두 넣지 않는다.

근거는 다섯 층에서 찾는다

우리는 각 주장 옆에 evidence를 붙였다.

README나 과거 이슈만으로 현재 통제를 확정하지 않았다. 실행 코드와 실환경이 다르면 문서에 보장을 추가하는 것이 아니라 차이를 먼저 기록했다.

기본 암호화와 CMEK를 구분한다

Google Cloud는 고객 콘텐츠를 기본적으로 저장 계층에서 암호화한다. 이 사실을 “모든 저장소에 고객 관리형 키가 적용됐다”로 확대하면 안 된다.

그래서 백서에는 현재 “암호화됨”이 Google 소유·관리 키를 사용하는 기본 저장 암호화를 포함하며, 모든 계층에 CMEK가 적용됐다는 뜻은 아니라고 명시했다. 향후 Cloud KMS를 적용하더라도 어느 저장소, backup과 log까지 포함하는지 범위를 다시 써야 한다.

제품 기능 이름보다 key ownership, rotation 통제와 audit 가능 범위를 설명하는 편이 정확하다.

GCP 인증은 SaaS 인증이 아니다

기반 클라우드가 보유한 인증과 그 위에서 운영하는 SaaS의 인증 상태는 다르다. 물리 데이터센터와 관리형 storage의 통제를 상속할 수 있어도 애플리케이션 인증, 권한, 데이터 흐름, 설정과 고객 계약은 우리 책임이다.

인증 취득을 준비 중이라는 사실도 인증 완료와 구분했다. 공개 문서에는 준비 활동이 특정 등급, 범위나 취득 시점을 보장하지 않는다고 적었다. 보안 문서가 영업 문구를 뒷받침하려다 법적·운영적 약속을 앞서가면 안 된다.

수치가 없는 보장은 만들지 않는다

자동 backup과 복구 기반이 있어도 실제 복구 훈련과 계약이 없다면 특정 RTO·RPO를 쓸 수 없다. 로그 보존도 저장소마다 설정과 법적 목적이 다르면 하나의 숫자로 일반화할 수 없다.

근거가 부족한 주장은 세 가지 중 하나로 처리했다.

1. 확인된 현재 통제만 범위를 좁혀 쓴다.
2. 고객 설정이나 계약에 따라 달라지는 조건을 명시한다.
3. 검증할 수 없으면 문서에서 제거하고 내부 감사 항목으로 남긴다.

“업계 최고 수준”, “완벽한 격리”, “절대 저장하지 않음”처럼 반례 하나로 깨지는 표현은 사용하지 않는다.

공개 범위와 검증 가능성을 함께 지킨다

세부 토폴로지, 내부 도메인, service account, 실제 보존값과 탐지 임계값을 모두 공개할 필요는 없다. 그렇다고 “보안상 비공개”라는 문장으로 통제 전체를 가릴 수도 없다.

공개 백서에는 다음 수준을 남겼다.

• 통제의 목적과 적용 계층
• 고객과 서비스 제공자의 책임 경계
• 현재 보장하지 않는 것
• 기능·계약에 따라 달라지는 조건
• 기준일과 문서 버전
• 검증 가능한 공급자 공식 자료

세부 evidence는 내부 감사표에서 유지하고, 적법한 비밀유지 절차가 필요한 경우에만 별도로 제공한다.

문서도 release artifact로 관리한다

백서에는 기준일과 변경 이력을 둔다. source 문서와 공개 PDF가 같은 version인지 확인하고, 배포된 download link도 함께 검증한다.

변경 때는 단순 문장 diff만 보지 않는다.

claim 변경
  → 코드·IaC evidence 재확인
  → 개인정보처리방침·약관 충돌 확인
  → 공개 위험 검토
  → PDF render와 링크 검증
  → version history 기록

보안 기능 배포가 문서보다 먼저 갈 수 있고, 문서 갱신 중 발견한 과장 표현이 코드 개선 과제로 돌아갈 수도 있다. 중요한 것은 두 방향을 모두 추적하는 것이다.

지금 다시 한다면

백서를 쓰기 전부터 claim inventory를 기계가 읽을 수 있는 표로 관리할 것이다. 각 행에 owner, evidence 경로, 마지막 확인일, 공개 문구와 재검토 조건을 둔다. 권한, 보존, 공급자나 배포 경계가 바뀌면 관련 claim만 다시 감사한다.

핵심은 더 강해 보이는 문서를 만드는 것이 아니다. 현재 실행되는 통제와 고객에게 하는 약속 사이의 거리를 계속 0에 가깝게 유지하는 것이다.

Cloudturing에서는

Cloudturing은 고객에게 제공하는 보안 설명과 실제 시스템 통제를 일치시키기 위해 공개 문서의 주장마다 적용 범위와 근거를 연결하고 있다. 새로운 서비스의 ISO·CSAP 대응을 위한 보안 설계에도 같은 문서화 원칙을 반영하고 있다.

참고 자료

• Google Cloud 보안 개요와 공동책임
• Google Cloud 기본 저장 암호화
• KISA 클라우드서비스 보안인증제 소개