INFO

ISMS-P 대응 [3편] DATACRYPTO: 암호화 적용은 “범위 + 키 + 운영”이다

PNPSECURE

05 2월 2026 • 13 min read

들어가며

ISMS-P 대응에서 암호화 적용은 암호화 기능을 켰는지가 아니라 ISMS-P 인증기준 2.7(암호화 적용) 관점에서 암호화 범위가 정의되어 있고, 암호키 관리가 운영되고 있으며, 그 결과를 운영 증적으로 제출할 수 있는지를 보는 흐름입니다. ISMS-P 보호대책 요구사항에는 2.7(암호화 적용)이 포함되며, 통상 2.7.1(암호정책 적용)과 2.7.2(암호키 관리) 축으로 준비 체계를 잡는 것이 실무적으로 빠릅니다.

또한 개인정보 보호법 제29조는 내부관리계획 수립 등 안전성 확보조치를 요구하고, 개인정보의 안전성 확보조치 기준 제7조는 개인정보 암호화 대상을 구체적으로 규정합니다. 결국 심사에서 통과를 좌우하는 것은 암호화 여부가 아니라, 어디를 어떤 기준으로 암호화했고 키를 어떻게 통제하며 운영 흔적을 어떻게 남기는가입니다.

암호화 적용에서 흔히 생기는 오해

“암호화 솔루션 도입 = 끝”이 아닌 이유

Q1. ISMS-P 준비하면서 암호화 솔루션만 도입하면 심사는 통과하나요?
A. 통과가 보장되지 않습니다. ISMS-P 2.7(암호화 적용)은 정책과 절차가 실제로 운영되고, 암호화 범위가 정의되어 있으며, 2.7.2(암호키 관리)까지 포함한 운영 증적을 제출할 수 있는지가 핵심입니다. 암호화 적용이 일부 시스템에만 머물거나, 예외가 누적되는데 승인과 보완통제가 남지 않으면 심사에서 약점이 됩니다.

어디를 암호화해야 하는지(범위) 불명확한 문제

Q2. 고객사가 가장 많이 묻는 암호화 적용 질문은 어디를 암호화해야 하냐인데, 답은 뭔가요?
A. 답은 시스템이 아니라 데이터 기준입니다. 개인정보가 저장되거나 이동하는 구간을 기준으로 암호화 범위를 정리해야 합니다. 기본은 저장과 전송이며, 업무 특성상 백업과 연계 구간까지 포함되는 경우가 많습니다. 중요한 것은 목록을 길게 쓰는 것이 아니라, 처리흐름도 기준으로 누락 없이 설명 가능한 범위 정의서를 갖추는 것입니다.

키 관리가 빠져서 운영 통제가 무너지는 문제

Q3. 키 관리는 왜 항상 문제로 지적되나요?
A. 암호화는 했는데 키 관리가 약하면 운영 통제가 무너집니다. 예를 들어 키가 설정파일에 평문으로 남아 있거나, 키 접근권한이 과도하거나, 키 교체와 폐기 절차가 없으면 사고 시 암호화의 실효성이 급격히 떨어집니다. 그래서 2.7.2(암호키 관리) 운영 증적이 함께 있어야 암호화 적용이 심사에서 설득력을 가집니다.

암호화 적용 범위 정의(실무 프레임)

데이터 분류(개인정보/민감/중요) 기준

Q4. 우리 회사는 개인정보가 많은데, 암호화 범위를 어떻게 정의해야 빠르나요?
A. 먼저 데이터 분류 기준부터 확정합니다. 최소 분류는 개인정보, 민감정보, 중요정보입니다. 그다음 법적 암호화 요구가 강한 항목군을 별도 표시합니다. 개인정보의 안전성 확보조치 기준 제7조는 비밀번호, 생체인식정보 등 인증정보를 저장하거나 정보통신망으로 송수신할 때 안전한 암호 알고리즘으로 암호화해야 하고, 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호, 신용카드번호, 계좌번호, 생체인식정보 등은 암호화하여 저장해야 한다는 내용을 포함합니다.

이 분류가 확정되면 범위 정의가 흔들리지 않고, ISMS-P 대응 문서도 일관되게 정리됩니다.

처리흐름도 기반: 저장/전송/백업/연계 구간

Q5. 저장, 전송, 백업, 연계 구간을 실무에서 한 번에 정리하는 방법이 있나요?
A. 처리흐름도 기반으로 정리하면 가장 빠릅니다. 개인정보가 생성, 저장, 조회, 전송, 복제되는 지점을 흐름도에 표시하고 구간별로 통제를 지정합니다.

저장 구간 : DB, 파일서버, 오브젝트 스토리지, 로그 저장소, 검색 인덱스, 캐시
전송 구간 : 사용자 단말과 서비스, 서비스 간 API, 배치 전송, 외부기관 연계
백업 구간 : 백업 파일, 스냅샷, 장기 보관 매체
연계 구간 : ETL, 메시지 큐, 데이터 레이크 적재, 위탁사 전달

이렇게 정리하면 암호화 범위가 기능 목록이 아니라 데이터 흐름 기준으로 설명되어 2.7.1(암호정책 적용) 대응이 쉬워집니다.

키 관리·접근 통제·감사: 심사 대응 포인트

키 권한 분리(업무 분장)와 접근 기록

Q6. 심사에서 키 관리 운영 증적은 구체적으로 뭘 내야 하나요?
A. 최소 제출 단위는 키 목록과 접근 통제, 접근 기록입니다. 즉 누가 어떤 키에 접근할 수 있는지, 접근이 기록되는지, 기록을 점검하는지가 핵심입니다. 키 권한 분리, 키 접근권한 최소화, 키 접근 로그, 정기 점검 리포트가 갖춰지면 2.7.2(암호키 관리) 운영 증적으로 방어력이 높아집니다.

키 교체/폐기/복구 절차(운영 증적)

Q7. 키 로테이션이나 키 폐기, 키 복구도 꼭 필요한가요?
A. 필요합니다. 운영 단계에서 키 교체와 폐기, 복구 체계가 불명확하면 사고 대응이 약해집니다. 최소 운영 증적으로는 아래 구성이 실무적으로 안전합니다.

키 로테이션 정책: 주기, 트리거, 책임자, 영향 평가
키 폐기 절차: 폐기 승인, 폐기 방법, 폐기 확인 기록
키 복구 절차: 복구 권한자, 복구 테스트 기록, 소산 보관 증적
키 관리대장: 현행화 점검 기록

이 항목들이 있으면 암호화 적용이 일회성이 아니라 운영되고 있다는 메시지가 됩니다.

솔루션 도입 제안

DATACRYPTO 적용 시나리오(정책/키/감사)

Q8. DATACRYPTO는 ISMS-P 암호화 적용에서 어떤 역할을 하나요?
A. DATACRYPTO는 ISMS-P 2.7 대응을 범위 + 키 + 운영 관점에서 정리하고 실행하는 데 도움이 되는 선택지입니다. 다만 실제 적용 범위와 방식은 고객 환경과 요구수준에 따라 설계가 필요합니다.

범위: 2.7.1 기준으로 정의된 암호화 범위에 맞춰 데이터 저장 구간을 중심으로 적용 범위를 단계적으로 확장할 수 있도록 지원
키: 2.7.2 관점에서 키 접근권한 최소화, 키 접근 기록, 키 교체와 폐기 등 키 관리 운영 체계를 정리하는 데 기여
운영: 정책 변경, 암호화 수행 이력 등 운영 증적을 체계적으로 남길 수 있도록 감사 관점의 기록을 정리하는 데 도움

핵심은 제품 도입 자체가 아니라, 정책 문서와 운영 기록이 같이 남도록 설계하는 것입니다.

단계적 도입

Q9. 기존 시스템에 무리 없이 붙이기 위해 어떻게 시작하면 좋나요?
A. ISMS-P 대응 관점에서 가장 안전한 단계는 법적 요구가 강한 영역부터 시작하는 것입니다. 개인정보의 안전성 확보조치 기준 제7조에서 요구하는 인증정보와 특정 고위험 개인정보 항목을 우선 대상으로 정하고, 이후 처리흐름도 기준으로 저장, 전송, 백업, 연계 구간으로 범위를 확장합니다. 이때 예외는 리스크 수용 절차와 보완통제를 함께 남겨 운영 증적으로 관리하는 것이 중요합니다.

체크리스트

암호화 범위 정의 템플릿

Q12. 암호화 범위 정의 템플릿에는 무엇이 꼭 들어가야 하나요?
A. 최소 구성은 아래입니다.

데이터 분류 기준: 개인정보, 민감정보, 중요정보, 법적 암호화 대상 항목군
처리흐름도: 저장, 전송, 백업, 연계 구간 표시
구간별 통제: 적용 방식, 적용 위치, 운영 책임자
예외 목록: 사유, 승인, 기간, 보완통제, 재평가 주기
운영 증적 계획: 점검 항목과 리포트 주기

키 관리 운영 체크리스트

Q13. 키 관리 운영 체크리스트에서 가장 먼저 봐야 할 건 뭔가요?
A. 순서는 이렇습니다.

키가 어디에 있고 누가 관리하는지 키 관리대장이 있는가
키 접근권한이 최소화되어 있는가, 승인 근거가 있는가
키 접근 로그가 남는가, 정기 점검 리포트가 있는가
키 로테이션, 키 폐기, 키 복구 절차가 있는가
개발과 운영의 키가 분리되어 있는가
소스코드와 설정파일에 키가 평문으로 남지 않도록 통제하고 점검하는가

마무리

ISMS-P 암호화 적용을 준비할 때 가장 빠른 길은 암호화 기능만 보지 않고 2.7.1(암호정책 적용) 관점의 범위 정의, 2.7.2(암호키 관리) 관점의 키 통제, 그리고 운영 증적을 한 세트로 설계하는 것입니다. 개인정보 보호법 제29조 안전조치 의무와 개인정보의 안전성 확보조치 기준 제7조 암호화 요구를 근거로 범위를 정의하고, 키 권한 분리와 접근 기록, 키 교체와 폐기, 정책 변경 검증까지 운영 증적으로 묶으면 심사 대응이 훨씬 안정됩니다.

다음 3편에서는 개인정보 접속기록 관리가 왜 반복 지적되는지, 접속기록 수집, 보관, 점검, 리포트까지 운영 증적으로 완성하는 방법을 INFOSAFER 관점의 고객 질문 형태로 정리하겠습니다.