본인확인 연계식별정보 CI/DI 안전 암호화 저장 라이프사이클 설계

왜 CI/DI가 생겼나

• 과거에는 주민등록번호 같은 고유식별정보를 서비스가 직접 다루는 경우가 많았고, 유출 시 피해가 매우 컸습니다.
• 그래서 본인확인기관(휴대폰 본인확인, 아이핀 등)이 인증을 수행하고, 서비스에는 주민등록번호 대신 연계 가능한 식별값(CI/DI) 을 내려주도록 구조가 바뀌었습니다.

CI/DI의 역할

• CI: “이 사람이 누구인지”를 서비스 수준에서 고유하게 식별하기 위한 값
• DI: “이 서비스 안에서 중복 가입이 있는지”를 서비스별로 확인하기 위한 값

CI / DI 정의와 차이

CI (Connecting Information)

• 동일인 = 동일 CI (같은 본인확인기관/규격 기준)
• 여러 서비스 간에도 동일인 여부를 연결할 수 있는 성격(=범용 식별자 성격)
• 결과적으로 개인 식별력이 매우 높음

DI (Duplication Information)

• 동일인이라도 서비스(사이트)마다 DI가 다름
• 서비스 밖으로 나가면 같은 사람인지 비교가 어려움
• 중복 가입 방지(서비스 내부) 에 최적

위험도 결론

• CI가 DI보다 훨씬 위험(중요) 합니다.
  • 이유: 서비스 간 연계 가능성 + 고유 식별력이 압도적으로 큼

“암호화 대상”을 정확히 구분해서 이해하기

(A) 생성 과정에서 암호학적으로 처리되는 대상과 (B) 서비스 저장 시 보호해야 하는 대상은 분리해서 봐야 합니다.

A) CI/DI “생성 과정”에서의 대상

본인확인기관이 CI/DI를 만들 때는 보통 아래와 같은 “실명 기반 정보(본인확인 정보)”를 활용해 암호학적으로 파생값을 생성합니다.

• 주민등록번호(또는 그에 준하는 실명 식별 요소)
• 성명
• 생년월일/성별 등
• 통신사/인증기관의 내부 키(Secret)

즉,

• CI/DI 자체는 복호화해서 주민번호가 나오도록 만든 게 아니라
• 주민번호 등 실명정보를 키 기반/해시 기반으로 파생한 값(재현 가능한 연계값)입니다.

B) 서비스가 “저장/처리”할 때 보호해야 하는 대상

서비스 입장에서 보호 대상은 다음과 같습니다.

1. 법적으로 ‘무조건’ 암호화 저장이 강하게 요구되는 것

• 주민등록번호 (고유식별정보): 법적으로 암호화 저장이 매우 강하게 요구됨(사실상 필수)

2. 법 조문상 ‘주민번호처럼 딱 잘라’ 필수라고 적히진 않아도, 점검·감사·사고 관점에서 ‘필수 수준으로’ 다뤄야 하는 것

• CI: 개인 식별력이 매우 높아 준-고유식별정보급으로 관리하는 게 안전
• DI: 개인정보이며 보호 필요. 다만 CI보다 연계성이 낮아 상대적으로 위험도는 낮음

3. 함께 관리가 자주 필요한 것

• 휴대폰번호, 이메일, 계정ID(개인 식별 가능한 경우), 인증 토큰/세션 등

“뭐가 더 중요해? 법적 필수도 있다던데”에 대한 정답

중요도(보안 리스크) 순서

• 🔴 1순위: CI
• 🟠 2순위: DI
• 🔴 최상위(별도 범주): 주민등록번호(보유 시)

법적 ‘필수’의 핵심

• 주민등록번호는 법적으로 암호화/관리 요건이 매우 강함(사실상 필수)
• CI/DI는 주민등록번호 그 자체는 아니지만
  • 개인을 강하게 식별할 수 있고
  • 유출 시 파급이 크며
  • 다른 정보와 결합 시 식별 가능성이 커서
    → 감사·점검·분쟁·사고 대응 관점에서 “암호화 + 접근통제 + 로그통제”가 사실상 필수 수준으로 요구됩니다.

현실적인 결론

• “조문에 CI는 암호화 필수라고 적혀 있느냐?”와
• “점검에서 CI 평문 저장이 통과되느냐?”는 다릅니다.

300x250

대부분 조직은 CI를 평문으로 저장/로그에 남기면 지적/리스크가 큼으로 봅니다.

권장 아키텍처 (저장/검색/키관리)

절대 권장하지 않는 패턴

• CI를 PK(Primary Key) 로 쓰기
• CI를 인덱스/검색 용도로 평문 저장
• 인증 응답 전문을 로그에 그대로 저장
• 운영자가 DB에서 CI를 직접 조회 가능

권장 패턴: “암호화 컬럼 + 검색용 해시 컬럼” 분리

• ci_enc : CI 원문을 강한 대칭키(AES-256 등)로 암호화한 값(복호화는 제한된 서버만)
• ci_hash: CI 원문을 SHA-256 등으로 해시한 값(검색/조인/중복체크용)

장점

• 조회/조인은 ci_hash로 해결 → 애플리케이션 대부분이 복호화 필요 없음
• 유출 시에도 ci_enc는 키 없으면 해석 불가
• ci_hash는 원문 복원이 어렵고(역산 불가), “같은 값인지 비교”만 가능

예시(검색용 해시)

import hashlib

def ci_to_hash(ci: str) -> str:
    return hashlib.sha256(ci.encode("utf-8")).hexdigest()

예시(DB 컬럼 구조)

-- 예시: 회원 테이블
ALTER TABLE members
  ADD COLUMN ci_enc VARBINARY(512) NULL,
  ADD COLUMN ci_hash CHAR(64) NULL;

CREATE INDEX idx_members_ci_hash ON members(ci_hash);

암호화 키 관리(핵심)

• 키는 DB에 두지 않기
• 가능하면 KMS/HSM 사용
• 최소한 애플리케이션과 키 저장소 분리
• 키 접근 권한 분리(운영자/개발자/보안관리자)

로그/모니터링/전송 통제 (운영에서 가장 많이 터지는 부분)

로그에 남기면 안 되는 것

• CI / DI 원문
• 본인확인 응답 전문(특히 CI 포함)
• 디버그 모드에서 요청/응답 전체 덤프

안전한 로그 예시(마스킹)

AUTH success user_id=12345 ci_hash=ab12...f9e0

SIEM/로그 수집 파이프라인 점검 포인트

• 수집 에이전트(Filebeat/Fluentbit 등)가 전문을 그대로 올리는지
• APM/Tracing(예: HTTP body capture)이 켜져 있는지
• WAF/Proxy가 요청 파라미터를 기록하는지

외부 전송 시

• 내부/외부 모두 TLS 필수
• API 응답에 CI/DI를 내려줘야 한다면
  • 원칙적으로 최소화
  • 가능하면 ci_hash 등 안전한 형태로 대체
  • 파트너 전송은 계약/목적/보관기간/파기까지 명시

권한/접근통제 (사람이 만든 사고를 막는 장치)

최소권한

• CI 복호화 권한은 “매우 제한된” 서비스 계정만
• 운영자 DB 조회는 원칙적으로 ci_hash만 보이게
• 복호화는 “승인된 절차(티켓/사유/승인자)”를 거치게

DB/관리도구 차단

• Adminer/SQL Client 등에서 평문 조회 가능하면 위험
• DB View/Stored Procedure로 접근 범위를 제한

데이터 수명주기(Lifecycle): 수집→보관→파기

보관 최소화

• 인증에 필요하면 “그 순간”만 쓰고, 저장은 목적에 맞게 최소화
• “중복가입 방지” 목적이면 DI만으로 충분한지 검토
• 계정통합/휴면/부정이용 대응 등 “정당한 목적”이 있을 때만 CI 저장

파기 기준

• 탈퇴/휴면/보관기간 만료 시 CI/DI 파기(또는 비식별)
• 백업 데이터 파기 정책 포함(여기 빠지면 사고 납니다)

내부 점검 체크리스트

저장

1. CI/DI가 DB에 저장되는가?
2. CI는 암호화 저장인가?
3. 검색/조인 때문에 평문 컬럼이 따로 존재하는가? (있으면 위험)
4. 테스트/스테이징 DB에 실데이터가 복제되는가?

키 관리

1. 키가 소스코드/환경변수에 평문으로 박혀있는가?
2. 키 접근 권한이 최소화되어 있는가?
3. 키 로테이션(교체) 계획이 있는가?

로그/전송

1. 앱 로그, WAF 로그, 프록시 로그에 CI/DI가 남는가?
2. APM이 request body를 저장하는가?
3. SIEM에 CI 원문이 적재되는가?

권한/운영

1. 운영자가 CI 원문을 조회할 수 있는가?
2. 조회 이력(누가/언제/왜)이 남는가?
3. 복호화 기능이 있다면 승인 절차가 있는가?

사고 대응 관점 (CI 유출이 특히 위험한 이유)

CI 유출 시 파급력

• 여러 서비스/데이터셋 간 “동일인 연계” 가능
• 계정 상관분석이 쉬워져 2차 피해 확대
• 법적 신고/통지/대외 대응 부담 증가

즉시 대응 포인트

• 유출 범위: CI 원문? 암호문? 해시? 키 유출 여부?
• 로그/백업 포함 여부 확인
• 키 노출 가능성 확인 → 키 교체/재암호화 계획
• 사용자 통지/관계기관 신고 필요성 판단(법무/개인정보 담당과 함께)

핵심 결론

• CI가 DI보다 훨씬 중요(위험)
• 주민등록번호는 법적 암호화 필수 급
• CI는 법 조문 문구와 별개로 “암호화 + 접근통제 + 로그통제”를 사실상 필수 수준으로 해야 안전
•  가장 추천되는 설계는
  • CI 암호화 저장 + CI 해시 별도 저장(검색용)
  • 키는 KMS/HSM 분리
  • 로그에는 ci_hash만