익명 화 및 노출
1) 이용 약관 및 주요 차이
명목화: 합리적인 노력으로 피험자를 직간접 적으로 식별 할 수없는 형태로 집합을 돌이킬 수없는 감소. 정확한 익명화 후 데이터는 개인 데이터가되지 않습니다.
앨리어싱: 직접 식별자 (이름, 전화, 이메일, 계정 번호) 를 별칭 (토큰) 으로 대체합니다. 통신은 별도로 저장되며 암호화 및 액세스 절차에 의해 보호됩니다. 법적으로 이것은 여전히 개인 데이터입니다.
준 식별자: 무해한 기능 (생년월일, 색인, 성별, 도시, 장치) 의 조합은 사람을 고유하게 나타낼 수 있습니다.
재 식별: 외부 소스에 접착하거나 희귀 한 기능 조합을 분석하여 대상과의 통신 복원.
2) 건축 목표 및 요구 사항
1. 기본적으로 개인 정보 보호: 수집 최소화, 필요한 필드 만 저장, 엄격한 TTL.
2. 윤곽 분리: 생산 식별자는 분석 및 ML 윤곽과 분리됩니다. 알아야 할 원칙에 따라 링크 테이블에 액세스합니다.
3. 감사 및 추적 성: 누가, 언제, 왜 다시 식별 할 수 있는지.
4. 재사용 정책: 파트너/외부 연구원에게 제공되는 데이터에는 공식적인 개인 정보 보증 및 응용 프로그램 라이센스가 있어야합니다.
5. 위험 평가: 엔지니어링 SLO로서의 정량적 측정 항목 (k- 익명 성, 매치업 확률, 차등 개인 정보 보호 정책).
3) 식별 해제 기술
3. 1 앨리어싱 (가역적)
토큰 화: "토큰 레지스트리" 에 저장 일치합니다.
형태: 결정 론적 (하나의 입력 → 하나의 토큰), 무작위 화됨 (입력 → 소금과 컨텍스트가있는 다른 토큰).
적절한 경우: 결제 식별자, 계정, 이벤트 간의 장기 링크.
FPE (형식 보존 암호화) - 형식 보존 암호화 (예: 16 자리 PAN → 16 자리 암호문). 법적 제도 및 검증을위한 편리함.
HMAC/Deterministic Encryption: joynes에 안정적인 별칭을 제공하지만 키 및 응용 프로그램 도메인 관리 (컨텍스트 바인딩) 가 필요합니다.
해싱: 강한 소금으로 만 그리고 가역성이 필요없는 경우에만 허용됩니다. 드문 도메인 (전화, 이메일) 의 경우 순수한 해싱은 무차별적인 힘에 취약합니다.
3. 2 무의미화 (돌이킬 수없는)
k- 익명 성: 각각 기록 된 "quasi-portrait" 는 10k 번 발생합니다. 일반화 (연령 → 연령 _ band) 및 희귀 조합 억제에 의해 달성됩니다.
l- 다양성: 각각의 k- 그룹에서, 민감한 속성은 균일 한 클러스터에 걸친 공개를 피하기 위해 상이한 값을 갖는다.
t-closeness-k- 그룹의 민감한 속성을 전역에 "가까이" 분배합니다 (정보 누출 제약).
차등 개인 정보 보호 (DP): 개인 정보 보호를 통해 집계 또는 교육 모델에 수학적으로 제어되는 노이즈 추가 (λ-DP). 공격자에 대한 임의의 외부 지식에 대한 공식적인 보증을 제공합
마스킹/순열/믹싱: 데모/지원 환경에 적합합니다.
합성 데이터: 누출 테스트를 통해 실제 대상 (GAN/VAE/표 신디사이저) 과 연결되지 않은 "유사한" 개발/연구 키트 생성.
4) 건축 패턴
4. 입구에 1 개의 개인 정보 게이트웨이
스레드: 클라이언트 → API 게이트웨이 → 프라이버시 게이트웨이 → 이벤트/스토리지 버스
함수:- 회로의 정규화;
- 민감한 필드 강조 (PII/PHI/Finance)
- 적용 규칙: 토큰 화/FPE/마스킹;
- 정책 로깅 (policy _ id, 키 버전, 처리 이유).
4. 2 토큰 금고
HSM/KMS와 별도의 서비스/데이터베이스.
API를 통한 RBAC/ABAC; 모든 작업은 감사 할 수 있습니다.
하나의 토큰을 상황과 혼동 할 수 없도록 토큰 화 "도메인" (이메일/결제/사용자 _ id) 을 분리합니다.
투명한 마이그레이션으로 키 회전 및 토큰 버전 ('token _ v1', 'token _ v2').
4. 3 이중 루프 분석
루프 A (운영): PII는 비즈니스 토큰을 위해 최소한으로 저장됩니다.
컨투어 B (분석): 익명화 된 데이터 세트/집계 만; 안전한 노트북 액세스; DP 게이트를 통해 외부로 수출합니다.
4. 프라이버시가 포함 된 4 ML 컨베이어
단계: 수집 → 청소 → 가명 → 익명화/DP 집계 → 훈련.
개인화 된 모델의 경우 토큰에 기능을 저장하고 기능의 "밝기" (카디널리티, 테일 트리밍, DP 정규화 캡) 를 제한합니다.
5) 프로토콜 및 흐름 (예)
이메일 알리아싱 프로토콜:1. API는 '이메일' 을받습니다
2. 프라이버시 게이트웨이
3. 응용 프로그램은 이메일 대신 '이메일 _ token' 을 저장합니
4. 알림의 경우-감사와 함께 사례별로 "해독" 할 권리가있는 별도의 서비스.
익명화 프로토콜보고:1. 분석가는 쇼케이스에 대한 요청을 구성합니다 (토큰/무감각 필드 만).
2. 엔진은 준 식별자 ('국가, 연령 _ 대역, 장치 _ 클래스') 에 k- 익명화를 적용합니다.
3. 공개 위험이있는 지표의 경우 DP 노이즈가 추가됩니다.
4. 내보내기는 예산과 함께 'anonymization _ pro필 _ id' 로 표시됩니다.
6) 위험 지표 및 검증
k- 익명 성: 동등한 클래스의 최소 크기 (대상: 도메인에 따라 k 이하 5/10/20).
l-diversity/t-closure: k 클래스 내에서 민감한 값의 누출을 제어합니다.
독창성 점수: 자산 중 고유 한 인물 사진의 비율은 일반화로 줄이는 것입니다.
연결성/주입 위험: 레코드가 외부 세트와 비교 될 확률 (공격 시뮬레이션에 의해 추정 됨).
DP λ- 예산: 주제/데이터 세트에서 "개인 정보 보호 예산" 을 시작하고 소비를 추적하십시오.
공격 시뮬레이션: 테스트 컷에서 다시 식별하기위한 일반적인 "빨간색 명령".
7) 키, 암호화 및 작동 회로
KMS/HSM: FPE/Deterministic Encryption/HMAC 용 키 생성 및 스토리지.
버전: 'key _ id', '만들기', '상태 = 활성' 퇴직 '퇴직'. 가역성을 위해 데이터에 'kid' 를 저장하십시오.
회전: 계획 (분기 별) 및 강제 (사고). 마이그레이션 기간 동안 "이중 암호화" 를 지원합니다.
접근 정책: 대량 해독 금지; RPS/볼륨은 필수 '목적' 을 제한합니다.
감사: 서명이 포함 된 수정되지 않은 로그 (WORM/추가 전용).
8) 마이크로 서비스 및 프로토콜로의 통합
'pii: 직접' quasi '민감한', 'policy _ id' 가있는 프로토 타임/JSON-Schema-Tag 필드.
이벤트: "원시" (내부 윤곽) 및 "비인간" (분석/파트너 용) 의 두 가지 주제 세트.
파트너 게이트: 익명화 프로파일이있는 출구 서비스 (규칙 세트 + 위험 메트릭 + 버전).
통나무/흔적: PII 제외; 토큰/해시를 사용하고 상관 관계에서 FPE/HMAC을 사용하십시오.
9) 반 패턴
토큰/키 근처에 소스 PII를 저장합니다.
다단계 뿌리 뽑기 및 로깅없이 하나의 "슈퍼 액세스" 를 신뢰하십시오.
위험 지표가없고 공식적인 보증없이 "비 개인적" 데이터 세트를 제공하십시오.
소금/컨텍스트가없는 해싱 이메일/전화에만 해당됩니다.
외부 소스를 변경할 때 수정없이 "한 번에 영원히" 익명화하십시오 (누수는 연결의 위험을 증가시킵니다).
k- 익명 성은 텍스트/시간 시리즈/지리 트랙에 충분하다고 생각하십시오. DP/자르기 및 합성이 필요합니다.
10) 애플리케이션 사례 (핀 테크/게임 산업 포함)
사기 방지 및 행동 기능: 접착 세션 및 장치를위한 결정 론적 토큰 및 민감한 필드는 별도의 회로로 이동합니다.
지역별로보고: 준 식별자 (연령 그룹, 지역 클러스터, 지불 방법 유형) 의 k- 익명화, 수익 지표에 대한 DP 노이즈.
A/B 테스트 및 마케팅: 사용자 토큰, DP 클리핑을 통한 소프트 잠재 고객 및 최소 감사 로그.
공급자와의 데이터 공유: 익명화 프로파일 및 증분 재구성에 대한 법적 제한이있는 출구 게이트를 통해서만 가능합니다.
11) 미니 레시피 (의사 코드)
도메인 소금으로 결정 론적 토큰 (이메일)
function email_token(email, domain_key, context):
norm = normalize (email )//lower, trim, punycode salt = HMAC (domain_key, context )//context bound to use-case return BASE32 (HMAC (salt, norm) )//stable, non-brute force tokenPAN 용 FPE (약)
cipher = FPE_AES_FF1(kid="pay_v2")
enc_pan = cipher. encrypt(pan, tweak=merchant_id)
store(enc_pan, kid="pay_v2")희귀 바구니 억제로 <> k- 익명화
groups = groupBy(dataset, [age_band, region3, device_class])
filtered = filter(groups, count >= k)
suppressed = replaceRare(groups, with="")DP 집계 지표
function dp_sum(values, epsilon, sensitivity=1):
noise = Laplace(0, sensitivity/epsilon)
return sum(values) + noise12) 테스트 및 관찰 가능성
정책의 단위 테스트: 토큰의 재현성, '어린이' 의 올바른 회전, 권리없이 해독 할 수 없음.
개인 정보 보호 CI: 각 PR-PII 누출에 대한 체계 및 코드의 정적 분석 (태그/로그/내보내기 검사).
측정 항목: PII 태그가있는 열의 비율, 표적에 의한 해독 수, 세트에 의한 k-min, λ- 소비.
경고: 해독 시도의 급증, "얇은" 바구니의 출현 (k가 임계 값 아래), 익명화 프로파일없이 내보냅니다.
13) 법률 프로세스 회로 (높은 수준)
DPIA/TRA: 새로운 스트림에 대한 개인 정보 보호 영향 평가.
데이터 유지: TTL 및 대리 및 레지스트리 제거 정책.
주제 요청: 내부 토큰 화 키/논리를 노출시키지 않고 데이터 사본을 발행하는 기능.
파트너와의 계약: 재 식별 금지, 외부 세트와의 조인 제한, 필수 개인 정보 보호 지표.
14) 건축가 점검표
1. PII/준 식별자가 다이어그램으로 정의되고 표시됩니까?
2. 입력 프라이버시 게이트웨이는 정책을 결정적으로 적용하고 버전을 로그합니까?
3. 토큰 레지스트리 격리 (KMS/HSM, RBAC, 감사, 한계)?
4. 윤곽은 작동, 분석, ML, 탈출로 나뉩니다
5. 위험 지표 (k, l, t, λ) 와 임계 값 SLO가 구성되어 있습니까?
6. 주요 교체 계획과 가역 토큰 마이그레이션이 있습니까?
7. 외부로의 수출은 익명화 프로파일과 DP 노이즈를 거칩니까?
8. 로그/흔적에 PII가 포함되어 있지 않습니까?
9. 정기적 인 "적색 팀" 재 식별 시뮬레이션?
10. 주요 누출/타협 사건에 대한 문서화 된 런북입니까?
15) 관련 아키텍처 및 프로토콜 섹션 패턴
토큰 화 및 키 관리
휴식/대중 교통 암호화
지리 라우팅 및 현지화
관찰 가능성: 로그, 메트릭, 추적 (PII 없음)
개인 정보 보호 및 준수를위한 SLO/SLA
결론
명목화 및 가명화는 열에서 단일 작업이 아니라 정책, 서비스, 키, 감사, 위험 지표 및 개발 문화와 같은 체계적인 아키텍처 능력입니다. 비즈니스 프로세스에 대한 강력한 가명과 분석 및 교환에 대한 공식 개인 정보 보장 (DP, k-/l-/t 기준) 을 결합하여 "혁신에 대한 브레이크" 에서 개인 정보를 경쟁 우위와 필수 품질 계층으로 전환합니다. 플랫폼.