개인정보 암호화, 어디까지 해야 하나 — 대상과 방법 정리
“개인정보는 암호화해야 한다”는 말은 익숙한데, 정확히 무엇을 어디까지 해야 하는지는 헷갈립니다. 전부 암호화하면 성능이 떨어지고, 안 하면 위반입니다.
이 글에서는 반드시 암호화해야 하는 대상과 저장·전송 구간별 요구사항을 정리하겠습니다.
왜 암호화가 특별한가
암호화는 다른 안전조치가 뚫렸을 때 마지막으로 남는 방어선입니다. 서버가 털려도 데이터가 암호화돼 있으면 피해가 크게 줄어듭니다.
실무적으로 더 중요한 이유가 있습니다. 사고가 났을 때 암호화 여부가 책임 판단에 영향을 줍니다. 안전조치 의무를 다했는지 판단하는 핵심 기준 중 하나이기 때문입니다.
무엇을 암호화해야 하나
암호화 대상 | 업로드 파일 : l1.png
| 대상 | 요구 수준 | 비고 |
| 주민등록번호 | 반드시 암호화 저장 | 최우선 대상 |
| 여권번호·운전면허번호·외국인등록번호 | 암호화 저장 | 고유식별정보 |
| 비밀번호 | 일방향 암호화 | 복호화 불가해야 함 |
| 바이오정보 | 암호화 저장 | 지문·홍채·얼굴 등 |
| 신용카드번호·계좌번호 | 암호화 저장 | 금융 정보 |
저장 위치를 넓게 보십시오. 운영 DB뿐 아니라 업무용 PC, 모바일 기기, 백업본, 로그 파일, 다운로드 받은 엑셀에도 개인정보가 남아 있을 수 있습니다. 앞서 다룬 정보자산 목록에서 “어디에 개인정보가 있는가”를 파악해 두어야 하는 이유입니다.
저장할 때와 전송할 때
| 구간 | 요구사항 | 실무 예 |
| 저장(DB) | 대상 항목 암호화 | 컬럼 암호화, TDE |
| 저장(파일) | 파일 또는 디스크 암호화 | 문서 암호화, 디스크 암호화 |
| 저장(단말) | PC·모바일 저장 시 암호화 | DRM, 디스크 암호화 |
| 전송(외부) | 정보통신망 전송 시 암호화 | HTTPS(TLS) |
| 전송(내부) | 중요 정보는 내부 구간도 검토 | 서버 간 암호화 통신 |
| 백업 | 백업본도 동일 수준 | 백업 암호화 |
전송 구간에서 가장 흔한 누락은 관리자 페이지입니다. 대고객 서비스는 HTTPS인데 내부 관리자 화면은 HTTP인 경우가 의외로 많습니다.
일방향 암호화란
비밀번호는 복호화가 가능하면 안 됩니다. 관리자조차 원래 값을 알 수 없어야 합니다.
| 구분 | 양방향 암호화 | 일방향 암호화(해시) |
| 복원 | 가능 | 불가능 |
| 용도 | 주민번호, 계좌번호 등 | 비밀번호 |
| 확인 방법 | 복호화해서 비교 | 입력값을 해시해서 비교 |
단순 해시만으로는 부족합니다. 같은 비밀번호는 같은 해시값이 되므로, 솔트(salt)를 적용하고 충분히 안전한 알고리즘을 사용해야 합니다. 오래된 알고리즘을 쓰고 있다면 교체 계획을 세우십시오.
키 관리가 진짜 문제입니다
암호화를 적용해도 키가 노출되면 의미가 없습니다. 실무에서 가장 자주 지적되는 부분이기도 합니다.
| 항목 | 요구사항 |
| 키 저장 위치 | 암호화된 데이터와 분리 보관 |
| 소스코드 | 키를 하드코딩하지 않음 |
| 접근 권한 | 키 접근 권한을 최소한으로 |
| 키 교체 | 교체 주기와 절차를 규정에 명시 |
| 백업 | 키 백업과 복구 절차 마련 |
| 기록 | 키 접근·변경 이력 보관 |
소스코드에 키가 박혀 있는 경우가 매우 흔합니다. 형상관리 저장소에 올라가면 그 순간 통제를 벗어납니다. 별도 키 관리 체계(KMS 등) 도입을 검토하십시오.
자주 하는 실수
| 실수 | 문제 |
| 운영 DB만 암호화 | 백업·로그·개발 DB에 평문이 남아 있음 |
| 개발·테스트 환경은 예외 | 운영 데이터를 복사해 쓰면 동일한 위험 |
| 관리자 페이지 HTTP | 전송 구간 암호화 누락 |
| 비밀번호를 양방향 암호화 | 복호화 가능하면 위반 |
| 키를 소스코드에 하드코딩 | 암호화 의미 상실 |
| 암호화 적용 후 점검 없음 | 설정이 풀렸는지 아무도 모름 |
점검 체크리스트
| 항목 | 확인 |
| 주민등록번호가 암호화 저장되어 있는가 | ☐ |
| 고유식별정보가 암호화 저장되어 있는가 | ☐ |
| 비밀번호가 일방향 암호화되어 있는가 | ☐ |
| 솔트가 적용되어 있는가 | ☐ |
| 외부 전송 구간이 암호화되어 있는가 | ☐ |
| 관리자 페이지도 암호화 적용되었는가 | ☐ |
| 백업본이 암호화되어 있는가 | ☐ |
| 업무용 PC·모바일 저장분이 보호되고 있는가 | ☐ |
| 암호화 키가 데이터와 분리 보관되는가 | ☐ |
| 소스코드에 키가 하드코딩되어 있지 않은가 | ☐ |
| 키 교체 절차가 규정에 있는가 | ☐ |
| 정기 점검을 수행하고 기록하는가 | ☐ |
마치며
암호화는 적용하는 것보다 유지하는 것이 어렵습니다. 시스템을 개편하거나 새 기능을 붙이면서 예외가 생기고, 그 예외가 방치되는 경우가 많습니다.
정기 점검을 규정에 넣고 실제로 수행하는 것이 결국 가장 확실한 방법입니다.
이 글은 개인정보의 안전성 확보조치 기준 등 공개된 고시와 실무 경험을 바탕으로 정리한 일반 정보입니다. 대상 항목과 기술 요구사항은 고시 개정에 따라 달라질 수 있으므로 최신 고시를 반드시 확인하시기 바랍니다. 법률자문이 아닙니다.
태그
#개인정보암호화 #안전성확보조치 #고유식별정보 #일방향암호화 #키관리 #개인정보보호법 #보안실무 #ISMSP