fix: 하네스 제거 및 keycloak 문서 보강

raw/official-docs/gdpr-cryptographic-erasure-envelope-key-pattern.md

@@ -1 +0,0 @@
-../../vault/20-evidence/official-docs/gdpr-cryptographic-erasure-envelope-key-pattern.md

raw/official-docs/gdpr-cryptographic-erasure-envelope-key-pattern.md

@@ -0,0 +1,159 @@
+---
+title: Per-Principal Envelope Key for GDPR Art.17 Cryptographic Erasure (NIST SP 800-88)
+source_type: official-doc
+status: raw
+confidence: medium
+url: https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final
+archive_url:
+tags: [ca-privacy, gdpr, art-17, nist-sp-800-88, envelope-encryption, cryptographic-erasure]
+related_branches: [feature-data-retention-privacy-contract]
+related_projects: [ca-skeleton-operational-contract]
+created: 2026-05-22
+last_reviewed: 2026-05-27
+---
+
+# Per-Principal Envelope Key for GDPR Art.17 Cryptographic Erasure (NIST SP 800-88)
+
+> Layer: `raw/official-docs/` — NIST SP 800-88 § 2.5 Cryptographic Erase + GDPR Art.17 + KMS envelope encryption 패턴을 ca-tmpl backup retention + GDPR 단건 erasure gap 보강 후속 결정 input 으로 결합한 raw.
+
+## Parent / 활용 branch (필수)
+
+| Branch | 이 자료가 정당화하는 결정 |
+|---|---|
+| [[raw/branch-notes/feature-data-retention-privacy-contract]] | ca-tmpl pseudonymization 기본값 (HMAC-SHA-256 + 90d salt rotation) 가 GDPR Art.17 backup 단건 erasure 를 충족하지 못한다는 gap 인식 + per-principal envelope key 후보안 (a/b/c) 도입 결정 근거 |
+| [[raw/project-notes/ca-skeleton-operational-contract]] | ca-tmpl Phase C2 의 cryptographic erase 대안 선택 (per-principal CMK / per-principal DEK + master CMK / tenant-level CMK) 의 비교 input |
+
+## 컨텍스트
+
+ca-tmpl `feature-data-retention-privacy-contract` 의 pseudonymization 기본값은 **HMAC-SHA-256 + 90일 salt rotation** 으로 결정되어 있다. 이 결정은 GDPR Art.25 (privacy by design) 와 호환되나, **GDPR Art.17 (right to erasure)** 요건 — 특히 **backup·snapshot 까지 포함한 단건 삭제** — 에는 충분하지 않다. HMAC-with-rotating-salt 는 새로 기록되는 데이터에 대해서만 forward security 를 제공하며, 이미 작성된 backup 안의 PII 는 그대로 남는다. 복원(restore) 시점에 삭제된 사용자 데이터가 되살아나면 Art.17 위반이다.
+
+NIST SP 800-88 Rev.1 § 2.5 는 **Cryptographic Erase (CE)** — encryption key 폐기로 매체 sanitization 을 대체하는 방식 — 를 정식 sanitization technique 으로 인정한다. AWS KMS / Google Cloud KMS 의 **envelope encryption** 패턴(Data Encryption Key 를 별도 Key Encryption Key 로 감싸는 구조) 을 **per-principal**(주체별) 로 적용하면, 특정 사용자의 삭제 요청 시 그 사용자의 envelope key 만 폐기해도 모든 backup/snapshot 안의 해당 사용자 ciphertext 가 자동으로 unreadable 상태가 된다. 본 raw 는 ca-tmpl 의 backup 정합(retention 30 daily + 6 monthly) 과 GDPR Art.17 단건 erasure 사이의 gap 을 메우기 위한 후속 결정 input 이다.
+
+## 출처 / Source
+
+- 원본 URL (NIST SP 800-88 Rev.1): https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final
+- 보조 (GDPR Art.17 / Right to erasure, EUR-Lex): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679#d1e2606-1-1
+- 보조 (GDPR Art.17 / gdpr-info.eu 미러): https://gdpr-info.eu/art-17-gdpr/
+- 보조 (AWS KMS envelope encryption): https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping
+- 보조 (Google Cloud KMS envelope encryption): https://cloud.google.com/kms/docs/envelope-encryption
+- 보조 (ENISA Pseudonymisation Techniques and Best Practices, 2019-11): https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices
+- 보조 사례 (per-tenant CMK 패턴):
+  - Stripe Radar / data infra: https://stripe.com/blog/encryption-envelope
+  - Twilio Privacy & Security: https://www.twilio.com/docs/glossary/what-is-data-encryption
+  - Shopify Engineering: https://shopify.engineering/
+- 아카이브 URL: (미수집)
+- 저자 / 조직: NIST (SP 800-88), EU (GDPR), AWS / GCP
+- 발행일: NIST SP 800-88 Rev.1 = 2014-12, GDPR = 2016-04 (발효 2018-05)
+- 마지막 확인일: 2026-05-27
+
+## 핵심 인용 / Key quotes (verbatim)
+
+### NIST SP 800-88 Rev.1 § 2.5 — Cryptographic Erase 정의
+
+> [§2.5] "Cryptographic Erase (CE) leverages the encryption of target data by enabling sanitization of the target data's encryption key. This leaves only the ciphertext remaining on the media, effectively sanitizing the data by preventing read-access."
+
+> [§2.5] "For CE to be effective, the cryptographic algorithm and all of its parameters (e.g., key length, mode) must be at security strength of 112 bits or higher (e.g., AES-128 or higher)."
+
+> [§2.5] "After CE is used to sanitize media, the encrypted data remaining on the media cannot be feasibly recovered or read because the encryption key has been sanitized."
+
+### GDPR Art.17(1) — Right to erasure
+
+> [§Art.17(1)] "The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies"
+
+### AWS KMS — envelope encryption 구조
+
+> [§Envelope encryption] "Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key."
+
+> [§Envelope encryption] "The top-level plaintext key encryption key is known as the master key."
+
+## Claims Extracted / 추출된 주장
+
+| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
+|---|---|---|---|---|---|
+| GDPR-CE-ENV-C1 | NIST SP 800-88 § 2.5 는 Cryptographic Erase (CE) 를 **encryption key 의 sanitization 으로 target data 자체를 sanitize** 하는 방식으로 정의 — ciphertext 는 media 에 잔존하나 read-access 가 차단됨 | [§2.5] "Cryptographic Erase (CE) leverages the encryption of target data by enabling sanitization of the target data's encryption key. This leaves only the ciphertext remaining on the media, effectively sanitizing the data by preventing read-access." | `official-standard` | media sanitization 일반. backup tape, SSD, cloud blob 등 ciphertext 가 잔존해도 무방한 케이스 | "CE 후 ciphertext 가 영구적으로 read-impossible" 의 정확한 시한 (양자컴퓨터 / 미래 attack) 은 본 인용 범위 밖. 본 표준은 현재 cryptographic strength 하에서의 보증 |
+| GDPR-CE-ENV-C2 | CE 가 effective 하려면 cryptographic algorithm 과 모든 parameter (key length, mode) 가 **security strength 112-bit 이상** (예: AES-128 이상) 이어야 한다 | [§2.5] "For CE to be effective, the cryptographic algorithm and all of its parameters (e.g., key length, mode) must be at security strength of 112 bits or higher (e.g., AES-128 or higher)." | `official-standard` | CE 를 정식 sanitization 으로 주장하려는 모든 시스템 | AES-256, ChaCha20 등 더 강한 알고리즘이 필요하다는 뜻은 아님 — 112-bit 가 **최소 요건** |
+| GDPR-CE-ENV-C3 | CE 사용 후 media 의 encrypted data 는 encryption key 가 sanitize 되었으므로 **feasibly recoverable 하지 않음** | [§2.5] "After CE is used to sanitize media, the encrypted data remaining on the media cannot be feasibly recovered or read because the encryption key has been sanitized." | `official-standard` | key destruction 이 정확히 수행된 경우 | key 가 단순 marking 만 되고 실제 destroy 되지 않은 경우 (KMS 의 일부 soft-delete 모드 등) 는 본 보증 밖 |
+| GDPR-CE-ENV-C4 | GDPR Art.17(1) 은 data subject 가 controller 로부터 자신의 personal data **erasure 를 obtain 할 권리** 를 부여하며, controller 는 **undue delay 없이 erase 할 의무** 를 가진다 (특정 grounds 충족 시) | [§Art.17(1)] "The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies" | `official-standard` | EU 또는 EU residents data 를 처리하는 controller | "erasure" 가 **물리적 삭제** 만을 의미한다는 뜻은 아님 — Recital 26 및 후속 가이드는 anonymisation/cryptographic erase 등을 포함 가능으로 해석 |
+| GDPR-CE-ENV-C5 | AWS KMS envelope encryption 은 plaintext data 를 data key 로 암호화한 뒤 그 data key 를 **또 다른 key (master key)** 로 암호화하는 패턴 | [§Envelope encryption] "Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key." | `official-vendor-doc` | AWS KMS / 동일 envelope 패턴 사용 KMS | per-principal envelope key 가 AWS 의 권장 best practice 라는 뜻은 아님 — envelope 구조 자체의 정의일 뿐 |
+
+## Usage Boundaries / 적용 경계
+
+- **이 자료가 직접 증명하는 것**:
+  - `GDPR-CE-ENV-C1`/`C2`/`C3`: NIST 표준의 CE 정의, 최소 112-bit strength, sanitization 후 복구 불가능성
+  - `GDPR-CE-ENV-C4`: GDPR Art.17 erasure 권리/의무의 존재
+  - `GDPR-CE-ENV-C5`: AWS KMS envelope encryption 의 정확한 구조 정의
+- **이 자료가 증명하지 않는 것**:
+  - "per-principal envelope key 가 GDPR Art.17 단건 erasure 의 **권장 방식**" 이라는 EU 공식 입장 — 본 raw 의 3종 후보 (a/b/c) 는 **운영 결정 후보** 이지 EU 공식 권장이 아님
+  - per-principal CMK 의 cost 가 실제 large-scale 서비스에서 비현실적이라는 정량 근거 — AWS KMS pricing 은 시점/region 별 변동
+  - GDPR Art.17 의 "undue delay" 가 정확히 30 일이라는 SLA — Art.12(3) 의 "within one month" 와 결합 해석 필요
+  - 모든 backup tape 의 ciphertext 가 key 폐기 즉시 unreadable 이라는 보장 — backup 의 별도 key escrow / replicated key 가 있으면 무효
+- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
+  - ca-tmpl Phase C2 의 (a)/(b)/(c) 중 채택안 (또는 hybrid: B2C=b, B2B=c)
+  - master CMK rotation 주기, DEK store (DynamoDB / Postgres) 자체의 erasure 책임 경계
+  - per-principal key lifecycle 의 KMS API cost 정량 측정
+  - EU regulator (DPA) 가 본 패턴을 GDPR Art.17 충족으로 명시 수용한 의견서 존재 여부
+
+## HMAC + salt rotation vs envelope key 비교 표
+
+> 본 표는 위 Claims 에서 직접 인용된 사실 + 운영 해석의 결합. 비교 자체는 본 raw 의 합성 (자료 직접 인용 아님).
+
+| 항목 | HMAC-SHA-256 + 90d salt rotation | Per-principal envelope key (CE) |
+| --- | --- | --- |
+| 분류 (ENISA/IAPP 기준) | pseudonymization | encryption + cryptographic erasure |
+| Forward security (신규 기록 시점 이후) | 제공 (rotation 시점 이전 hash 는 새 salt 로 무효화) | 제공 (key 폐기 후 어떤 신규 복호화도 불가) |
+| Backward erasure (이미 작성된 backup 단건 삭제) | **불가능** — 기존 backup 안의 hash 는 그대로 존재 | **가능** — 해당 principal key 폐기 시 모든 backup ciphertext 가 동시에 unreadable |
+| Backup rewriting 필요성 | 필요 (단건 삭제하려면 backup tape 자체 rewrite) | 불필요 (ciphertext 잔존 허용, key 부재로 read 불가) |
+| GDPR Art.17 단건 erasure 정합 | 부분 — DB row 삭제는 가능, backup 은 retention 만료까지 잔존 | 정합 — NIST SP 800-88 § 2.5 정식 인정 sanitization |
+| Re-identification risk (brute-force input space) | 존재 (휴대폰 11자리 등 좁은 input space) | 매우 낮음 (AES-128+ ciphertext) |
+| Key management 복잡도 | 낮음 (salt store + rotation policy) | 높음 (per-principal KMS key, key lifecycle, KMS cost, audit) |
+| 운영 비용 | 낮음 (HMAC 연산 / salt store) | 높음 (KMS API 호출 / per-key cost / wrap-unwrap latency) |
+| 적용 범위 | 로그·DB 컬럼의 식별자 마스킹 | 저장된 PII payload 자체(파일·DB blob·backup) |
+
+> 핵심: HMAC + salt rotation 은 forward security 만 제공한다. backup 의 GDPR Art.17 단건 erasure 는 cryptographic erase + per-principal envelope key 구조가 사전에 설계되어 있을 때에만 가능하다.
+
+## ca-tmpl 결정 후보 3종
+
+> 본 섹션은 ca-tmpl Phase C2 결정 input — 자료 직접 인용 아님.
+
+ca-tmpl `feature-data-retention-privacy-contract` 에 backup retention(30d daily + 6m monthly) 이 정의되어 있는 한, 아래 중 1종은 선택되어야 GDPR Art.17 정합을 주장할 수 있다.
+
+### (a) Per-principal CMK on KMS
+
+- 구조: principal(user) 한 명당 KMS Customer Master Key 1개. PII payload 는 CMK 로 직접 암호화.
+- DSR delete = `kms:ScheduleKeyDeletion` (AWS) / `cryptoKeyVersions destroy` (GCP).
+- 장점: 단건 erasure 가장 명확. NIST SP 800-88 § 2.5 정합 강함.
+- 단점: KMS key 수가 user 수에 비례 → 비용 폭증 (AWS KMS CMK $1/month/key 기준). large-scale 서비스에서는 비현실적.
+
+### (b) Per-principal DEK + master CMK envelope
+
+- 구조: principal 당 별도 Data Encryption Key (DEK) 생성, DEK 는 공용 KMS master CMK 로 wrap(envelope encryption). PII payload 는 DEK 로 암호화.
+- DSR delete = wrapped DEK record 를 ciphertext store 에서 삭제 + KMS audit log 기록. master CMK 는 살아 있음.
+- 장점: KMS key 수는 master 1개로 고정. DEK 는 일반 storage 비용. AWS KMS / GCP KMS 권장 패턴(envelope encryption 정의 그대로).
+- 단점: 삭제된 DEK record 가 어떤 backup·replica 에도 잔존하지 않도록 wrapped DEK store 자체에 erasure 책임이 옮겨감(메타-erasure 문제). DEK store 의 backup 정책이 별도로 필요.
+
+### (c) Tenant-level CMK (cheaper)
+
+- 구조: 사용자 단위가 아닌 **tenant(B2B 고객사)** 단위 CMK. 한 tenant 의 모든 사용자 PII 가 하나의 CMK 로 보호.
+- 장점: KMS key 수 = tenant 수 (수십~수백 수준). 비용/관리 가능. Stripe / Twilio / Shopify 류 SaaS 에서 일반적인 패턴.
+- 단점: 단일 사용자(end user) 단위 erasure 에는 cryptographic erase 가 직접 적용되지 않음. tenant 단위 offboarding/계약 종료 시에만 CE 효과. 개별 user erasure 는 여전히 row delete + pseudonymization 보조 필요.
+
+> ca-tmpl Phase C2 결정 시 (a)/(b)/(c) 중 채택안 + hybrid 가능성(예: B2C 서비스는 (b), B2B 는 (c)) 명시 필요. 본 raw 는 결정안을 강제하지 않음.
+
+## 메모
+
+- ENISA Pseudonymisation Techniques and Best Practices (2019-11) 는 pseudonymization 과 encryption 을 명시적으로 구분한다. cryptographic erasure 는 encryption-based 방법이며 pseudonymization 과 결합되어 사용될 수 있다.
+- AWS KMS envelope encryption 은 DEK / KEK 구분이 핵심. GCP KMS 도 동일한 envelope 패턴 (`encryptedDataEncryptionKey` 메타데이터). per-principal 패턴은 두 KMS 모두에서 SDK 수준에서 직접 구현 가능.
+- ca-tmpl 미결정: (a)/(b)/(c) 중 채택안, master CMK rotation 주기, DEK store(예: DynamoDB / Postgres) 자체의 erasure 책임 경계.
+
+## Related / 관련
+
+- 같은 주제 다른 official-doc:
+  - [[raw/official-docs/privacy-cryptographic-erasure-nist-sp800-88]] — NIST SP 800-88 § 2.5 CE 선행 raw
+  - [[raw/official-docs/privacy-gdpr-article-25-design]] — GDPR Art.25 (privacy by design) ca-tmpl legal basis
+- 인용하는 branch:
+  - [[raw/branch-notes/feature-data-retention-privacy-contract]]
+- canonical contract 섹션:
+  - [[raw/project-notes/ca-skeleton-operational-contract]] (#18. Control Plane Contract)
+- 대안 그룹: **Group G-J — Privacy / File / Domain Modeling** (data retention / privacy)
+- 본 source 의 위치: **Group G-J 후속 보강** — backup 의 GDPR Art.17 단건 erasure 정합을 위한 per-principal envelope key 패턴. ca-tmpl 결정 미확정 (status `raw`, confidence `medium`), Phase C2 에서 (a)/(b)/(c) 선택 예정.
+- 인용하는 wiki: (미작성)