키관리 시스템ISMS-P 암호키 관리KMSISMS-P 인증기준 2.7.1암호키 통제

키관리 시스템과 ISMS-P 인증: CISO가 놓치는 암호키 통제 실패 지점

ISMS-P 인증기준 2.7.1 암호키 관리 요건을 중심으로, 키관리 시스템 부재 시 발생하는 심사 지적 사례와 실무적 대응 방향을 분석합니다.

C
ComplixShield 편집팀
··읽는 시간 1

키관리 시스템과 ISMS-P 인증: CISO가 놓치는 암호키 통제 실패 지점

ISMS-P 심사에서 암호 통제 영역 지적 건수는 2023년 기준 전체 결함 중 상위 5개 영역에 지속적으로 이름을 올리고 있습니다. 그중에서도 "암호키를 생성했지만, 누가 언제 교체했는지 이력이 없다"는 지적은 중견 규모 이상 기업에서 반복적으로 등장합니다. 암호화 자체는 구현했지만, 키를 관리하는 체계가 없는 경우입니다.


ISMS-P 인증기준이 요구하는 암호키 관리 수준

ISMS-P 인증기준 **2.7.1(암호정책 적용)**은 암호화 알고리즘과 키 길이 기준 수립만을 요구하지 않습니다. 세부 점검항목은 암호키의 생성·배포·저장·교체·파기 전 주기에 걸친 통제 절차 수립과 그 이행 증적을 심사합니다.

구체적으로 심사자가 확인하는 항목은 다음과 같습니다.

  • 암호키 생성 시 승인 절차 존재 여부
  • 키 보관 위치가 암호화 대상 데이터와 분리되어 있는지
  • 정기적인 키 교체 주기가 정책에 명시되고 실제 이행되는지
  • 키 파기 시 복구 불가능한 방식으로 삭제되었음을 확인할 수 있는 증적
  • 키에 대한 접근 권한이 최소 권한 원칙에 따라 부여되었는지

이 다섯 가지 중 두 개 이상에서 증적이 불충분하면 결함으로 연결될 가능성이 높습니다.


키관리 시스템(KMS) 없이 운영할 때 발생하는 실제 문제

많은 조직이 HSM(Hardware Security Module)이나 클라우드 KMS 도입 없이 자체 스크립트나 설정 파일로 암호키를 관리합니다. 이 방식이 기술적으로 불가능하다는 것이 아닙니다. 문제는 심사 가능한 이력과 통제 증적을 만들기 어렵다는 점입니다.

예를 들어, 데이터베이스 암호화 키를 애플리케이션 서버의 설정 파일에 하드코딩 방식으로 보관하는 구조는 세 가지 결함 포인트를 동시에 내포합니다.

  1. 키 저장 위치 분리 실패 — 암호화 대상과 키가 같은 서버에 존재
  2. 접근 통제 불가 — 서버 접근 권한이 있는 모든 계정이 키를 열람 가능
  3. 교체 이력 부재 — 키 교체 시 설정 파일 수정만 이루어지므로 이전 키 사용 기간 확인 불가

개인정보 보호법 제29조(안전조치 의무) 및 동법 시행령 제30조 제1항 제7호(암호화 조치)는 개인정보 암호화를 명시하고 있지만, 키 관리 체계까지 법령 조문에 명시되어 있지 않기 때문에 "암호화는 했으니 괜찮다"고 판단하는 경향이 있습니다. 그러나 ISMS-P 인증기준은 암호화 구현보다 키 통제 체계를 더 세밀하게 들여다봅니다.


반론: "클라우드 KMS를 쓰면 다 해결되지 않나요?"

AWS KMS, Azure Key Vault, GCP Cloud KMS 같은 클라우드 관리형 서비스를 도입하면 키 저장 분리와 접근 제어 문제는 상당 부분 해소됩니다. 그러나 심사 현장에서 지적이 사라지지 않는 이유가 있습니다.

클라우드 KMS 도입 자체가 증적이 되지 않습니다. 심사자는 다음을 추가로 요구합니다.

  • KMS 내 키 접근 로그가 수집되고 있는가
  • 키 교체 정책이 서비스 정책에 명시되었고, 실제로 교체된 이력이 있는가
  • KMS 접근 권한 부여·회수 이력이 IAM 감사 로그로 남아 있는가
  • 퇴직자 또는 역할 변경자의 키 접근 권한이 즉시 회수되었는가

클라우드 KMS는 도구이고, ISMS-P가 요구하는 것은 그 도구를 운영하는 프로세스와 증적입니다. 도입만으로는 충분하지 않습니다.


CISO가 취해야 할 실무적 시사점

암호키 통제를 ISMS-P 심사 시즌에만 점검하는 것은 구조적 위험을 방치하는 것입니다. 평상시 운영 체계에 다음 세 가지가 내재화되어 있는지 확인할 필요가 있습니다.

첫째, 키 생명주기 전 단계에 대한 절차서가 존재하고, 해당 절차서가 실제 운영 환경과 일치하는지 연 1회 이상 검토해야 합니다. 인증기준 2.7.1의 세부 점검항목은 "절차 수립"과 "이행"을 모두 확인합니다.

둘째, 키 접근 권한 목록을 분기 단위로 검토하는 프로세스를 인사 시스템과 연동해야 합니다. 퇴직자나 부서 이동자의 키 접근 권한이 자동으로 검토 대상에 포함되는 구조가 없으면, 결함으로 이어집니다.

셋째, 키 교체 이력은 티켓 시스템이나 변경관리 시스템에 남겨야 합니다. 단순 메모나 구두 보고는 심사 증적으로 인정되지 않습니다.


암호키 관리는 보안 기술 수준의 문제라기보다, 운영 체계 설계의 문제입니다. 기술 스택이 아무리 견고해도 운영 프로세스와 증적 체계가 따라오지 않으면 ISMS-P 심사에서 결함으로 기록됩니다.

키 관리 통제 현황 점검부터 인증기준 전 항목의 증적 관리 자동화까지, 구조적으로 접근하고 싶다면 ComplixShield가 그 출발점이 될 수 있습니다.

기본 제도와 의무 대상이 궁금하다면

ISMS-P 개요, 대상 여부, 준비 순서를 먼저 정리하고 싶다면 ISMS-P 가이드에서 한 번에 확인할 수 있습니다.

ComplixShield

ISMS-P 준비를 엑셀과 메신저 대신 한 곳에서 관리하세요

체크리스트, 증적 예시, 정책문서 초안, 주간 보고까지 이어지는 실무형 워크플로를 ComplixShield에서 바로 시작할 수 있습니다.

101개 항목 추적정책문서 템플릿증적 관리보고서 자동화
ComplixShield 살펴보기