플러스프로젝트 배경
- 문제점 고객정보를 다루는 업무 시스템에서 사고는 대개 암호화를 안 해서 나지 않습니다. 1. 암호문과 복호화 열쇠를 같은 서버에 두어, 서버가 뚫리면 함께 나갑니다 2. 주민등록번호가 상담 화면에 늘 떠 있어 캡처·어깨너머로 새어 나갑니다 3. DB 담당자가 개인정보 평문까지 볼 수 있어, 한 사람이 뚫리면 전부 뚫립니다 4. 고객 정보를 지워도 상담 메모·백업 파일·내려받은 엑셀에 그대로 남
프로젝트 성과
유출 시뮬레이션 — 같은 사고, 다른 결과
암호화만 한 구조는 주민번호가 평문으로 전부 나갑니다. 분리 + 열쇠 별도 보관 구조는 무의미한 참조번호만 나갑니다. 공격자가 같은 시각에 세 곳을 모두 뚫어야 합니다.
시스템관리자가 개인정보를 볼 수 없는 권한 모델
DB를 직접 다루는 사람이 평문까지 볼 수 있으면 그 한 사람이 단일 실패점이 됩니다. 관리 권한과 열람 권한을 분리하고, 열쇠는 어느 역할도 볼 수 없게 했습니다.
파기 — 본체보다 백업에 더 많이 남아 있습니다
보유기간 경과 고객을 본체·상담이력·백업 로그에서 함께 찾아 지웁니다. 지운 건수와 내역을 리포트로 남겨 점검 때 증명할 수 있게 했습니다.
조회 자체가 기록으로 남습니다
주민등록번호는 사유를 입력해야 열립니다. 기록이 남는다는 사실을 아는 것만으로 불필요한 조회가 줄어듭니다.
핵심 기능
유출 시뮬레이션 — 뚫렸을 때 무엇이 나가는가
고객관리 DB가 통째로 유출된 상황을 두 구조로 나란히 비교합니다. 암호화만 한 경우 주민번호가 평문으로 전부 나가고, 분리 + 열쇠 별도 보관 구조는 무의미한 참조번호만 나갑니다.
진행 단계
개인정보 흐름 정리
2026.08.
어디에 저장되고, 누가 보고, 어디로 나가고, 언제 지워지는지를 먼저 그렸습니다. 화면 설계보다 이것이 먼저입니다.
프로젝트 상세
고객정보를 다루는 업무 시스템의 개인정보 보호 체계를 설계하고 구현한 것입니다. CRM 화면 전체를 만드는 대신 개인정보가 지나가는 길만 따라갔습니다. [화면 구성] 1 고객 조회 상담원이 매일 보는 화면. 주민번호는 처음부터 내려보내지 않습니다 2 권한별 차이 같은 고객을 세 역할이 각각 어떻게 보는가 3 저장 구조 고객관리 DB · 개인정보 DB ·
