9.8 KiB
title, source_type, status, confidence, url, archive_url, tags, related_branches, related_projects, created, last_reviewed
| title | source_type | status | confidence | url | archive_url | tags | related_branches | related_projects | created | last_reviewed | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IAPP / ENISA — Pseudonymization techniques (HMAC vs tokenization) | company-tech-blog | raw | medium | https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices |
|
|
|
2026-05-22 | 2026-05-27 |
ENISA / IAPP — Pseudonymisation techniques and best practices (HMAC vs tokenization)
Layer:
raw/company-tech-blogs/— ENISA (EU Agency) 의 pseudonymisation 가이드 + IAPP 의 operational impacts 해설을 결합. ca-tmpl HMAC-SHA-256 + 90d salt rotation 결정의 비교 reference. 주의: ENISA 자체는 EU agency publication 이나, IAPP 는 industry/professional association — 본 raw 는 둘을 함께 묶어 보관하므로company-tech-blog로 분류 (공식 표준이 아닌 best-practice 가이드 성격).
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-data-retention-privacy-contract | ca-tmpl 의 HMAC-SHA-256 + 90d salt rotation 채택 결정의 비교 reference (tokenization / FPE 대안과의 trade-off) |
| raw/project-notes/ca-skeleton-operational-contract | ca-tmpl Group G-J 의 pseudonymization 알고리즘 선택 input |
컨텍스트
ca-tmpl 이 HMAC-SHA-256 + 90일 salt rotation 을 선택한 근거. 대안으로 (1) tokenization service (Vault Transform, AWS Tokenization), (2) format-preserving encryption (FF1/FF3), (3) deterministic encryption 이 있고 각자 trade-off 가 다름. ENISA 는 EU 공식 가이드 이나 industry best-practice 성격으로, IAPP 는 professional association 의 operational 해설.
출처 / Source
- 원본 URL: https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices (ENISA 2019)
- 아카이브 URL: (미수집)
- 보조: IAPP "Top 10 operational impacts of the GDPR: Pseudonymization" — https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-8-pseudonymization/
- 보조: AWS docs "Data tokenization vs encryption vs masking" — https://aws.amazon.com/blogs/security/
- 저자/조직: ENISA (EU Agency for Cybersecurity), IAPP
- 발행일: 2019-11 (ENISA), 2016 (IAPP)
- 마지막 확인일: 2026-05-27
- WebFetch 결과 (2026-05-27): ENISA publication page 는 metadata + PDF 링크만 노출. PDF 본문 verbatim 은 본 raw 의 quote 가 기존 보관본 기준 — 향후 PDF 직접 대조 후 검증 필요.
핵심 인용 / Key quotes (verbatim)
[§ENISA — keyed-hash technique] "A keyed-hash function with a secret key (e.g., HMAC-SHA-256) is a basic but effective pseudonymisation technique. However, when the same key is used for a long period, it becomes vulnerable to dictionary attacks if the input space is small (e.g., phone numbers)."
[§ENISA — salt rotation] "Salt rotation and periodic re-pseudonymisation reduce the risk of cross-dataset linkage attacks."
[§IAPP — tokenization] "Tokenization replaces sensitive data with non-sensitive tokens, while the mapping is stored in a secure vault. Unlike encryption, the token has no mathematical relationship to the original."
[§ENISA — choice criteria] "The choice between hashing-based and tokenization-based pseudonymisation depends on (a) need for reversibility, (b) collision tolerance, (c) operational simplicity, (d) attack surface of the lookup table."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| ENISA-PSE-C1 | HMAC-SHA-256 같은 keyed-hash function 은 basic 하지만 effective 한 pseudonymisation 기법이며, 동일 key 를 장기간 사용 하면 input space 가 좁을 때 (예: 휴대폰 번호) dictionary attack 에 취약 | [§ENISA — keyed-hash technique] "A keyed-hash function with a secret key (e.g., HMAC-SHA-256) is a basic but effective pseudonymisation technique. However, when the same key is used for a long period, it becomes vulnerable to dictionary attacks if the input space is small (e.g., phone numbers)." | engineering-blog |
pseudonymisation 알고리즘 선택 시 input space 평가 | 90일 salt rotation 이 충분한 mitigation 인지는 본 인용 범위 밖 — "장기간" 의 정량 기준이 없음 |
| ENISA-PSE-C2 | salt rotation 과 periodic re-pseudonymisation 은 cross-dataset linkage attack 의 risk 를 감소시킴 | [§ENISA — salt rotation] "Salt rotation and periodic re-pseudonymisation reduce the risk of cross-dataset linkage attacks." | engineering-blog |
다중 dataset 이 동일 식별자를 공유할 수 있는 환경 | rotation 주기 (30d / 90d / 1y) 의 권장값을 본 인용은 제시하지 않음 |
| ENISA-PSE-C3 | tokenization 은 sensitive data 를 non-sensitive token 으로 치환 하고 mapping 은 secure vault 에 저장. encryption 과 달리 token 은 원본과 수학적 관계 없음 | [§IAPP — tokenization] "Tokenization replaces sensitive data with non-sensitive tokens, while the mapping is stored in a secure vault. Unlike encryption, the token has no mathematical relationship to the original." | engineering-blog |
vault-backed tokenization service (Vault Transform / AWS Tokenization 류) | tokenization 이 모든 시나리오에서 hashing 보다 우월하다는 뜻은 아님 — choice criteria (ENISA-PSE-C4) 참조 |
| ENISA-PSE-C4 | hashing-based 와 tokenization-based pseudonymisation 의 선택은 (a) reversibility 필요성, (b) collision tolerance, (c) operational simplicity, (d) lookup table attack surface 4가지에 의존 | [§ENISA — choice criteria] "The choice between hashing-based and tokenization-based pseudonymisation depends on (a) need for reversibility, (b) collision tolerance, (c) operational simplicity, (d) attack surface of the lookup table." | engineering-blog |
pseudonymisation 알고리즘 선택의 의사결정 framework | 4가지 외의 요소 (예: GDPR Art.17 backup erasure 호환성, latency, cost) 가 무시 가능하다는 뜻은 아님 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
ENISA-PSE-C1: HMAC + 장기 key 사용 시 small input space 에서의 dictionary attack 취약성ENISA-PSE-C2: salt rotation 의 cross-dataset linkage attack 완화 효과 (정성적)ENISA-PSE-C3: tokenization 의 정의 (vault-backed, no mathematical relationship)ENISA-PSE-C4: 알고리즘 선택의 4가지 결정 기준
- 이 자료가 증명하지 않는 것:
- ca-tmpl 의 90일 salt rotation 이 ENISA 권장값이라는 점 — ENISA 는 정량 주기를 본 인용에서 제시하지 않음
- HMAC-SHA-256 이 GDPR Art.17 backup 단건 erasure 를 충족 — 별도 cryptographic erase 결합 필요 (
NIST-CE-C1참조) - tokenization service outage 시 운영 영향의 정량 평가
- FF3-1 의 Hoang et al. 2017 attack 의 본 자료 직접 언급 — 별도 NIST SP 800-38G 가이드 보강 필요
- 본 자료를 공식 best practice 로 인용할 수 없음 — ENISA 는 가이드, IAPP 는 industry association. CLAUDE.md §5
company-tech-blog정책에 따라 "사례/관점" 으로만 사용 가능
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 90일 salt rotation 의 적정성을 ca-tmpl 의 input space (휴대폰 번호, 이메일 hash 등) 별로 정량 평가
- tokenization service 채택 시 vault outage 의 SLA 영향 분석
- SHA-256 truncation (예: 64-bit prefix) 사용 시 collision rate 재계산
- ENISA PDF 본문 verbatim 의 직접 대조 (WebFetch metadata 만 노출됨)
메모
- ca-tmpl 의 HMAC-SHA-256 결정 분석 (자료 직접 인용 아님):
- 장점: stateless (lookup table 불필요), 빠름, key rotation 으로 forward secrecy 일부 확보.
- 단점: input space 가 작으면 (예: 한국 휴대폰 11자리) brute-force attack 가능. salt rotation 으로 완화하나 old salt 90일 retain → 그 기간 동안 동일 plaintext 가 동일 token 으로 mapping.
- 대안 1: Tokenization service (Vault Transform / AWS DynamoDB Encryption SDK)
- 장점: brute-force 불가 (random token), reversal 은 vault 접근권한자만.
- 단점: vault outage = pseudonymization 자체가 unavailable, per-request latency 추가.
- 대안 2: Format-preserving encryption (FF1/FF3-1, NIST SP 800-38G)
- 장점: 원본과 동일 format (DB schema 변경 없이 in-place pseudonymization).
- 단점: 키 관리 복잡, FF3-1 은 일부 attack 발견 사례 있음 (Hoang et al. 2017).
- ca-tmpl 의 "collision rate < 1e-9" 가정은 SHA-256 출력 길이 (256-bit) 에서 birthday bound ≈ 2^128 → 통상 운영 dataset 에서는 충분. 단 truncation 시 (예: 64-bit prefix) 재계산 필요.
- old salt 90일 retain 은 ENISA 가 권장하는 "periodic re-pseudonymisation" 과 호환. 단 90일은 ca-tmpl 자체 결정값이고 ENISA 가 90일을 권장한 것은 아님.
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/privacy-gdpr-article-25-design — Art. 25(1) pseudonymisation legal basis
- raw/official-docs/gdpr-cryptographic-erasure-envelope-key-pattern — HMAC vs envelope key 비교
- raw/official-docs/privacy-cryptographic-erasure-nist-sp800-88 — NIST CE 표준
- 인용하는 branch:
- canonical contract 섹션:
- raw/project-notes/ca-skeleton-operational-contract (#18. Control Plane Contract)
- 대안 그룹: Group G-J — Privacy / File / Domain Modeling (data retention / privacy)
- 본 source 의 위치: ca-tmpl 채택안 (HMAC-SHA-256 + 90d salt rotation) 비교 reference — ENISA/IAPP, tokenization 대안
- 인용하는 wiki: (미작성)