고객 관리 키를 지원할 때 키 비활성화, 접근 불가, 교체를 실제 서비스 흐름에 반영하는 방법입니다.
왜 이 문제가 생길까
고객이 암호화 키를 직접 관리하면 통제권은 높아지지만 서비스는 그 키의 가용성에 의존합니다. 키가 비활성화되거나 권한이 바뀌면 새 데이터를 쓰지 못하거나 기존 데이터를 읽지 못할 수 있습니다. '암호화 지원'이라는 기능 소개만으로는 운영 책임의 경계를 설명할 수 없습니다.
시스템은 무엇을 구분해야 할까
데이터 암호화 키와 고객 관리 키의 관계, 키 식별자, 키 버전, 접근 권한을 테넌트 단위로 기록합니다. 키 상태 확인 실패와 실제 암호화 실패를 구분해 모니터링하고, 키 사용 불가 시 읽기·쓰기·백그라운드 작업이 각각 어떻게 동작하는지 정합니다. 교체 과정에서는 새 쓰기를 새 키로 전환하되 과거 데이터 읽기에 필요한 이전 키 접근을 당장 끊지 않습니다. 재암호화 완료 확인, 롤백 가능 시점, 고객 알림까지 하나의 런북으로 관리합니다.
현장에서 적용하면
보안 담당자가 키를 실수로 비활성화했다고 가정해 훈련해 봅니다. 시스템은 테넌트 A의 쓰기만 제한하고 다른 테넌트에는 영향을 주지 않아야 합니다. 운영자는 키 상태 오류를 저장소 장애와 구별하고 고객 관리자에게 복구 방법을 안내해야 합니다. 일정 시간 뒤 자동 재시도를 하더라도 무한 재시도로 큐를 채우지 않도록 제한합니다.
도입할 때 놓치기 쉬운 점
키 교체 버튼이 성공했다고 모든 데이터가 새 키로 암호화된 것은 아닙니다. 백업, 첨부파일, 검색 인덱스, 작업 큐도 영향 범위에 포함될 수 있습니다. 공급자별 키 비활성화 동작은 다르므로 사용 중인 KMS의 실제 제약을 테스트해야 합니다.
시작 전 점검할 세 가지
- 키 사용 불가 시 테넌트별 실패 범위가 정의됐는가
- 이전 키가 필요한 읽기·백업 경로를 파악했는가
- 교체·복구 훈련을 운영 환경과 유사하게 수행했는가
참고 자료: AWS KMS의 사용 불가 키 동작 설명
#SaaS보안 #고객관리키 #CMK #암호화 #키교체 #KMS #멀티테넌트 #데이터보호 #보안운영 #클라우드보안
