개인정보 안전성 확보조치: 비밀번호·생체정보·식별정보 암호화 구분

1장 개념과 보호 목표#

개인정보의 안전성 확보조치는 내부 관리계획, 접근 권한과 통제, 접속기록, 암호화, 악성프로그램 대응과 물리적 보호 등을 포함합니다. 적용 의무는 개인정보 보호법과 현행 고시의 대상·환경·정보 종류에 따라 확인해야 합니다.

2장 원리와 구분#

비밀번호는 복원이 어렵도록 일방향 저장을 적용하고 비밀번호 전용 KDF를 검토합니다. 생체정보는 비밀번호와 같은 단순 해시 저장이라고 일반화할 수 없습니다. 인증에 사용하는 생체인식정보는 특성과 안전한 템플릿·키 보호를 고려해야 합니다. 고유식별정보와 결제정보도 저장·전송 환경과 고시 요구를 구분해야 하며 모든 개인정보에 같은 양방향 방식이 의무라고 단정하면 안 됩니다.

3장 비교와 판단 기준#

정보·통제	점검 방향	주의할 점
비밀번호	복원이 어려운 일방향 저장	전용 KDF·Salt
생체인식정보	안전한 암호화·템플릿 보호	단순 해시라고 일반화 금지
고유식별정보	적법성·저장·전송 조건	법적 근거와 암호화 별개
접근·로그	최소 권한·행위 추적	권한 회수·기록 보호

4장 암호화 대상은 데이터 흐름으로 찾는다#

가입 화면에서 받은 정보는 데이터베이스뿐 아니라 요청 로그, 메시지 큐, 분석 저장소, 고객 상담 화면과 백업에도 남을 수 있습니다. 저장 위치를 하나만 점검하면 복제된 자료가 보호 범위 밖으로 빠집니다. 수집부터 파기까지 정보가 이동하는 경로를 먼저 그립니다.

flowchart LR
 U[수집] --> A[애플리케이션]
 A --> D[업무 저장소]
 A --> L[로그·메시지]
 D --> B[백업]
 D --> E[외부 제공]

각 경로에는 처리 목적, 정보 종류, 접근자와 암호화 방식을 연결합니다. 원문이 필요한 곳과 불필요한 곳을 구분하면 암호화 이전에 수집·복제를 줄일 수 있습니다.

5장 비밀번호 저장과 전송은 다른 문제다#

로그인 비밀번호의 전송은 TLS 등으로 보호하고 저장은 복원을 전제로 하지 않는 비밀번호 전용 해시 방식으로 처리합니다. TLS를 적용했다고 데이터베이스의 비밀번호 저장이 안전해지는 것은 아닙니다.

사용자별 솔트와 비용 설정을 적용한 비밀번호 해시를 사용합니다. 로그인 비교는 입력값을 같은 조건으로 계산하는 과정입니다. 비밀번호를 복호화하여 보여주는 기능은 이 구조와 맞지 않습니다.

6장 생체정보는 비밀번호처럼 교체하기 어렵다#

생체 원본 이미지와 인증용 특징값은 형태가 다르지만, 특징값이라고 해서 보호할 필요가 없어지는 것은 아닙니다. 저장·전송 범위와 인증 구조를 확인하고 장치 내부 처리 등 외부 노출을 줄이는 구조를 검토합니다.

유출 후 재발급이 어려운 특성을 고려해 필요한 최소 자료만 처리합니다. 암호 키와 복호화 권한의 관리, 등록·삭제 절차, 인증 실패와 우회 경로까지 확인해야 합니다.

7장 식별정보의 종류와 처리 근거#

고유식별정보와 주민등록번호는 적용 요건을 구분해야 합니다. 암호화했다는 이유만으로 수집·이용의 법적 근거가 생기지 않습니다. 먼저 처리가 허용되는지 확인하고 그다음 안전조치를 설계합니다.

정보주체의 구분, 정보 종류, 인터넷 구간·DMZ·내부망 등 저장 환경에 따라 적용되는 세부 조항을 확인합니다. 모든 정보를 하나의 예외 규칙으로 묶으면 누락이나 과도한 단정이 생깁니다.

8장 전송 암호화의 끝점을 확인한다#

브라우저와 프록시 사이의 HTTPS만 확인해서는 프록시와 애플리케이션, 애플리케이션과 데이터베이스의 통신을 판단할 수 없습니다. TLS 종료 위치와 종료 이후의 평문 구간을 각각 살펴봅니다.

인증서 검증을 끈 내부 통신은 암호화 여부와 상대방 신뢰의 문제가 분리됩니다. 관리용 전송, 파일 교환과 백업 이동도 실제 경로에 포함합니다.

9장 저장 암호화와 접근통제의 역할#

디스크 암호화는 저장 매체의 탈취 등에 대응하지만 실행 중인 서비스가 가진 읽기 권한까지 제한하지는 않습니다. 데이터베이스 암호화와 응용 수준 암호화 역시 보호 범위와 키 접근 주체가 다릅니다.

보호 수단	함께 확인할 사항
저장 암호화	원문을 읽을 수 있는 서비스·관리자
접근통제	업무별 권한과 권한 회수
마스킹	원문 조회 예외와 화면·내보내기
접속기록	누가 어떤 업무로 접근했는지

10장 키 관리가 빠지면 암호화도 약해진다#

암호 키를 암호문과 같은 설정 파일이나 백업에 넣으면 함께 유출될 수 있습니다. 키 저장 위치, 사용 권한, 교체와 복구 절차를 별도로 관리합니다. 법정 키 관리 절차의 적용 대상도 조직 조건에 맞게 확인합니다.

교체는 새 데이터에 새 키를 사용하는 일과 기존 데이터를 다시 암호화하는 일을 구분합니다. 이전 키를 너무 일찍 삭제하면 백업을 복원할 수 없습니다.

11장 상담 업무의 원문 조회 사례#

상담원이 고객 확인에 필요한 일부 항목만 볼 수 있도록 기본 화면을 마스킹합니다. 예외적인 원문 조회는 업무상 필요, 승인 또는 통제 절차와 접속기록을 연결합니다. 화면에서 가렸더라도 다운로드 파일과 API 응답에 원문이 남는지 확인해야 합니다.

12장 로그와 백업의 사각지대#

비밀번호·인증 토큰·불필요한 식별정보가 오류 로그에 기록되지 않도록 수집 단계에서 제거합니다. 백업도 접근 권한, 암호화, 보관과 파기, 복원 시 원문 노출을 함께 검토합니다.

13장 점검은 정상·실패·복원으로 나눈다#

정상 조회만 시험하지 않고 권한 없는 사용자, 만료한 키, 장애 처리, 데이터 내보내기와 백업 복원을 시험합니다. 설계 문서의 암호화 표시보다 실제 데이터와 권한의 경로가 검증의 근거가 됩니다.

14장 적용 사례와 운영 방법#

서비스의 데이터 흐름을 그린 후 수집·전송·저장·백업·로그별로 대상 정보를 표시합니다. 암호화 키를 같은 데이터베이스에 평문으로 넣지 않고 권한을 분리합니다. 접속기록은 사용자·시간·대상·행위를 조사할 수 있게 유지하고 무단 변경을 제한합니다.

15장 2026년 시행 기준의 암호화 대상을 나눠 읽기#

2026년 7월 1일 시행된 「개인정보의 안전성 확보조치 기준」 제7조는 인증정보, 이용자 정보, 이용자가 아닌 정보주체의 정보, 전송 구간과 기기 저장을 구분합니다. 비밀번호 저장은 복호화되지 않는 방식이 필요합니다. 이용자의 주민등록번호·여권번호·운전면허번호·외국인등록번호·신용카드번호·계좌번호·생체인식정보는 저장 암호화 대상을 확인해야 합니다.

이용자가 아닌 정보주체의 고유식별정보는 저장 구간과 조건을 나누며, 내부망의 일부 정보에 대한 적용 판단도 고시의 조건에 따릅니다. 생체정보를 비밀번호와 동일한 해시 처리로 일반화하거나 내부망이면 모든 암호화 의무가 없다고 설명하면 안 됩니다. 법적 구분을 실제 서비스와 매핑하는 것이 우선입니다.

16장 암호화 증거는 코드·설정·복원 결과로 확보한다#

처리 항목별로 수집→전송→저장→백업→로그→파기 경로를 작성하고 각 구간의 적용 기준과 구현을 붙입니다. 비밀번호는 전용 KDF·Salt·비용 설정, 복원할 정보는 안전한 암호 방식과 별도 키 권한을 확인합니다. 키 관리 절차의 별도 의무 대상도 고시의 사업자 유형·규모 조건에 따라 검토합니다.

평문 사본·시험 데이터·오류 로그는 본 DB의 암호화 여부와 무관하게 노출될 수 있습니다. 복호화 권한과 감사기록, 키 교체 후 과거 백업 복원까지 검증하면 정책 문서의 암호화 선언을 실제 통제로 연결할 수 있습니다.

17장 적용 전 확인할 사항#

정보 종류와 처리 구간별 요구를 현행 고시에 매핑한다
데이터와 키의 접근 권한을 분리한다
로그·백업·시험 환경에 남은 개인정보도 점검한다

18장 자주 묻는 질문#

주민등록번호는 업무상 필요하면 언제나 저장할 수 있나요?#

암호화 여부와 수집·처리의 적법성은 별개입니다. 법에서 허용하는 처리 근거를 먼저 확인하고 필요한 경우에만 보호조치를 갖춰 처리해야 합니다.

TLS를 쓰면 DB의 저장 암호화 의무도 충족하나요?#

전송 구간 보호와 저장 데이터 보호는 다릅니다. 항목·구간·대상별 의무를 각각 매핑하고 검증해야 합니다.

DB 전체 암호화면 개인정보 접근 권한 검토를 생략하나요?#

정상 권한의 애플리케이션은 데이터를 복호화할 수 있습니다. 최소 권한·접근통제·기록·키 정책은 별도로 적용해야 합니다.