Files

T

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

2026-07-25 12:53:13 +09:00

8.7 KiB

Raw Blame History

title, source_type, status, confidence, url, archive_url, tags, related_branches, related_projects, created, last_reviewed

title

source_type

status

confidence

url

archive_url

NIST SP 800-88 Rev.1 — Guidelines for Media Sanitization (Cryptographic Erase)

Layer: raw/official-docs/ — NIST SP 800-88 Rev.1 § 2.5 Cryptographic Erase (CE) 정식 정의. ca-tmpl backup 의 PII 단건 erasure 결정 (row delete vs key destruction) 의 1차 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-data-retention-privacy-contract	ca-tmpl backup retention (30d daily + 6m monthly) 안에서 DSR delete SLA 30일이 "DB row 삭제" 가 아닌 "encryption key 삭제 (CE)" 로 충족될 수 있다는 근거
raw/project-notes/ca-skeleton-operational-contract	ca-tmpl Group G-J (Privacy / File / Domain Modeling) 의 cryptographic erase 선행 입력 자료

컨텍스트

ca-tmpl 의 DSR delete SLA 30일이 "DB row 삭제" 를 의미하는지 "encryption key 삭제" 로 충분한지가 미정. NIST SP 800-88 은 Cryptographic Erase(CE) 를 정식 sanitization technique 으로 인정. ca-tmpl backup retention (30일 daily + 6개월 monthly) 에서 backup 안의 PII 를 어떻게 "삭제" 할지 결정할 때 직접 영향.

출처 / Source

원본 URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf
아카이브 URL: (미수집)
저자/조직: NIST (US National Institute of Standards and Technology), Richard Kissel et al.
발행일: 2014-12 (Rev.1)
마지막 확인일: 2026-05-27
보조: ENISA "Cryptographic erasure" briefing, AWS KMS docs ("Deleting customer master keys")
참고: 2025-09-26 부로 본 Rev.1 은 withdrawn 되고 Rev.2 로 superseded. 본 raw 의 quote/Claim 은 Rev.1 § 2.5 기준이며, 후속 작업에서 Rev.2 텍스트 대조 필요.

핵심 인용 / Key quotes (verbatim)

[§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."

[§2.5] "Verification of CE is typically performed by validating that the key destruction occurred per the manufacturer or vendor's specifications."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
NIST-CE-C1	Cryptographic Erase (CE) 는 target data 의 encryption key 를 sanitize 하여 target data 자체의 sanitization 효과를 내는 기법 — 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`	NIST 가 인정하는 media sanitization 의 대안 기법 (clear/purge/destroy 외)	CE 가 모든 매체/모든 시나리오에서 충분하다는 뜻은 아님 — NIST 문서는 데이터 분류 + threat model 별로 clear/purge/destroy 매칭 표 제공
NIST-CE-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 technique 으로 주장하려는 모든 시스템	더 강한 알고리즘 요구 (AES-256, ChaCha20 등) 라는 뜻은 아님 — 112-bit 는 최소 요건
NIST-CE-C3	CE 후 media 에 남은 encrypted data 는 encryption key 가 sanitize 되었기 때문에 feasibly 복구·읽기 불가	[§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 모드 등) 는 본 보증 밖. key escrow / replicated key 존재 시도 무효
NIST-CE-C4	CE 의 verification 은 manufacturer / vendor 의 specification 에 따라 key destruction 이 실제로 발생했음을 validate 하는 방식으로 수행됨	[§2.5] "Verification of CE is typically performed by validating that the key destruction occurred per the manufacturer or vendor's specifications."	`official-standard`	CE 를 운영 절차로 채택한 모든 환경	"validate 방법" 의 통일된 표준 절차가 NIST 에 직접 명시되어 있다는 뜻은 아님 — vendor specification 위임

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- NIST-CE-C1: CE 의 정식 정의 (ciphertext 잔존 허용 + read-access 차단)
- NIST-CE-C2: CE 의 최소 cryptographic strength 요건 (112-bit / AES-128 이상)
- NIST-CE-C3: CE 후 데이터 복구 불가성 (cryptographic 보증)
- NIST-CE-C4: CE verification 의 일반 절차 (vendor spec validation)
이 자료가 증명하지 않는 것:
- "CE 는 GDPR Art.17 의 erasure 요건을 자동으로 충족" — EU regulator 의 공식 확인은 본 NIST 표준 범위 밖
- per-principal 또는 per-tenant envelope key 가 권장 패턴 — 본 표준은 key destruction 자체의 효과만 정의
- cloud KMS (AWS KMS / GCP KMS) 의 ScheduleKeyDeletion 등 구체적 API 가 CE verification 요건을 충족 — vendor 별 별도 검증 필요
- quantum-resistant 미래 시점에서도 ciphertext 가 영구적으로 read-impossible — 현재 cryptographic strength 하에서의 보증
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 DSR delete 옵션 A (row delete) vs 옵션 B (CE) 중 채택안
- per-principal envelope key vs per-tenant key 의 cost/운영 trade-off (별도 raw gdpr-cryptographic-erasure-envelope-key-pattern 참조)
- NIST SP 800-88 Rev.2 (2025-09-26 supersession) 의 CE 관련 변경 사항 검토
- KMS vendor 가 제공하는 "key destruction validation" 메커니즘이 NIST NIST-CE-C4 요건 (vendor spec validation) 을 충족하는지

메모

ca-tmpl 적용 (자료 직접 인용 아님):
- DSR delete 옵션 A (row delete): DB row 자체 삭제. backup 에 남는 row 는 retention 만료 시까지 잔존 → GDPR Art. 17 "right to erasure" 위배 가능.
- DSR delete 옵션 B (cryptographic erase): principal 별 envelope key 를 KMS 에서 destroy. backup 에 ciphertext 는 남지만 복호화 불가 → NIST SP 800-88 이 정식으로 인정하는 sanitization.
- ca-tmpl 의 "tombstone/pseudonymization allowed" 결정은 cryptographic erase 와 호환되나 per-principal key 구조가 전제되어야 함.
트레이드오프:
- cryptographic erase 는 backup-friendly (rewriting backups 불필요) 하지만 key management 복잡도 증가 (per-principal key, key rotation, KMS cost).
- row delete 는 simple 하지만 backup retention 기간 동안 GDPR 노출.
ca-tmpl 미결정: per-principal envelope key vs per-tenant key. 본 raw 는 후속 결정 input.

같은 주제 다른 official-doc:
- raw/official-docs/gdpr-cryptographic-erasure-envelope-key-pattern — per-principal envelope key 후보 (a/b/c) 합성
- raw/official-docs/privacy-gdpr-article-25-design — GDPR Art.25 (privacy by design)
인용하는 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 의 위치: 대안 1 — NIST SP 800-88 Cryptographic Erase (backup 의 PII delete: row delete vs key destruction)
인용하는 wiki: (미작성)

8.7 KiB Raw Blame History