클라우드 저장소에 ‘암호화 사용’이 표시되어 있어도 점검은 끝나지 않는다. 애플리케이션 계정에 데이터 조회와 키 사용 권한이 함께 열려 있다면, 그 계정을 탈취한 공격자가 정상적인 복호화 경로를 이용할 수 있기 때문이다.
암호화 설계에서는 어떤 데이터를 보호하는지와 함께 누가 키를 사용할 수 있는지, 키가 바뀌거나 없어지면 어떤 데이터에 영향이 생기는지를 확인해야 한다. 이 글은 저장 데이터의 암호화와 키 관리 서비스인 KMS의 관계를 중심으로 설명한다.
데이터 키와 키 암호화 키를 나누는 이유
봉투 암호화는 데이터를 암호화하는 키와 그 키를 보호하는 키를 나누는 방식이다. 데이터 암호화 키인 DEK는 실제 데이터를 암호화하고, 키 암호화 키인 KEK는 DEK를 암호화해 보호한다.
- 애플리케이션이나 연동 서비스가 DEK로 데이터를 암호화한다.
- KEK로 DEK를 감싸 암호화된 데이터와 함께 저장한다. 평문 DEK를 그대로 저장하지 않는다.
- 읽을 때는 권한 확인을 거쳐 DEK를 복원하고, 그 DEK로 데이터를 복호화한다.
Google Cloud의 봉투 암호화 예시에서는 KEK가 KMS 밖으로 나오지 않는다. 원문 데이터 전체를 KMS에 보내는 구조가 아니며, 평문 DEK는 처리 과정에서 사용될 수 있다. 구체적인 생성·캐시 방식은 서비스마다 다르다.
키 관리 권한과 복호화 권한을 구분
KMS를 사용한다고 해서 권한이 자동으로 적절하게 나뉘지는 않는다. 예를 들어 AWS KMS는 키 정책을 중심으로 IAM 정책과 grant를 함께 사용해 키 접근을 제어한다. 저장소 접근 권한과 키 사용 권한은 실제 서비스의 연동 방식에 맞춰 각각 확인해야 한다.
실무 설계에서는 키의 설정을 관리하는 역할과 업무 중 데이터를 복호화하는 역할을 구분하는 편이 좋다. 다만 관리자가 키 정책을 바꿔 자신에게 복호화 권한을 줄 수 있다면 역할 이름만 나눈 것으로는 부족하다. 정책 변경 승인과 변경 내역 감시까지 연결해야 한다.
가상 예시로, 주문 처리 애플리케이션은 운영 데이터 복호화가 필요하지만 개발용 배치 계정에는 그 권한이 없어도 된다. 두 계정에 같은 키 사용 권한을 부여하면, 개발 환경의 사고가 운영 데이터 접근으로 이어질 경로가 생긴다. 이 경우 환경별 키 분리와 계정별 권한 제한을 함께 검토할 수 있다.
키 교체 및 재암호화의 차이
키 교체를 켰다는 이유로 과거 데이터까지 모두 새 키로 바뀌었다고 판단하면 안 된다. AWS KMS의 키 재료 교체는 기존 데이터 키를 교체하거나 기존 데이터를 재암호화하지 않는다. 이전 암호문을 읽을 때는 해당 암호화에 사용된 키 재료가 선택된다.
따라서 정기 교체와 유출 대응의 작업 범위는 구분해야 한다. DEK가 노출되었다면 상위 KMS 키의 교체만으로 그 DEK로 암호화한 데이터의 노출을 해결할 수 없다. 어떤 키가 노출되었는지 확인한 뒤 새 DEK 적용, 데이터 재암호화, 기존 키 사용 제한의 범위를 정해야 한다.
키 삭제와 백업 복구를 함께 검증
암호화된 백업 파일이 남아 있어도 복호화에 필요한 키를 사용할 수 없으면 복구가 막힐 수 있다. AWS KMS에서 일반적인 대칭 암호화 키를 영구 삭제하면 그 키에 의존하는 암호문을 복구할 수 없다. 삭제 예약 중에도 해당 KMS 키를 암호 연산에 사용할 수 없으므로, 영향 검토는 영구 삭제 시점보다 먼저 끝나야 한다.
복구 시험에서는 백업 파일의 존재뿐 아니라 복구용 계정의 권한, 대상 리전에서의 키 가용성, 과거 데이터에 필요한 키의 상태를 함께 확인하는 편이 좋다. 사용이 드문 장기 보관 백업도 점검 대상에 넣어야 한다. 최근 사용 기록이 없다는 사실만으로 그 키가 불필요하다고 결론 내리지 않는다.
키 사용 로그는 데이터 조회 로그와 함께 확인
AWS CloudTrail은 KMS의 Decrypt 같은 암호 연산과 키 정책 변경·비활성화 등 관리 작업을 기록한다. 다만 trail 설정에서 KMS 이벤트를 제외할 수 있으므로, 실제 수집 설정도 확인해야 한다.
KMS 호출 기록만으로 업무상 데이터 조회의 적정성까지 판단할 수는 없다. 누가 어떤 고객 정보에 접근했는지 확인하려면 애플리케이션과 저장소의 접근 기록도 함께 대조해야 한다. 점검 시에는 평소와 다른 계정의 키 사용이나 정책 변경을 살펴본다.
실무 점검은 설정값보다 증거를 기준으로 한다
다음 표는 공식 문서의 기능 설명을 바탕으로 구성한 운영 점검안이다. 특정 제품의 필수 설정 목록이 아니라, 우리 환경에서 암호화 통제가 작동하는지 확인하기 위한 질문으로 활용할 수 있다.
| 점검 항목 | 확인할 증거 | 미흡할 때의 조치 |
|---|---|---|
| 데이터와 키의 연결 | 저장소·DB·백업별 사용 키 식별 정보 | 운영·개발·백업의 키 의존성 목록 작성 |
| 복호화 권한 | 업무 계정과 개발 계정의 허용·거부 시험 결과 | 불필요한 계정의 키 사용 권한 축소 |
| 관리 권한 | 키 정책 변경 권한자와 승인·변경 이력 | 자기 권한 확대 경로와 승인 절차 점검 |
| 키 교체 범위 | 교체 설정과 기존 암호문 처리 방식 | 교체·DEK 변경·재암호화 작업 구분 |
| 복구 가능성 | 실제 복구용 계정으로 과거 백업을 읽은 결과 | 키 상태·권한·리전 의존성 보완 |
| 감사 가능성 | KMS와 데이터 접근 로그의 수집·조회 결과 | 누락된 이벤트와 감시 규칙 보완 |
담당 부서가 나뉘어 있다면 키 관리자는 정책과 수명주기를, 서비스 운영자는 복호화 경로와 장애 영향을, 보안 담당자는 권한 검증과 로그 감시를 맡는 식으로 책임을 구체화할 수 있다. 특히 키 비활성화·삭제처럼 서비스에 영향을 주는 작업은 데이터 소유자와 복구 담당자까지 함께 검토하도록 정해 두는 편이 안전하다.
암호화의 완성도는 권한과 복구 시험에서 드러난다
운영 점검의 출발점은 ‘암호화를 켰는가’이지만, 완료 기준은 더 구체적이어야 한다. 불필요한 계정은 복호화하지 못하고, 승인된 계정은 필요한 데이터만 읽으며, 과거 백업도 정해진 절차로 복구할 수 있어야 한다. 이 세 가지를 시험 결과로 남기면 암호화와 키 관리가 실제 통제로 이어지는지 판단할 수 있다.