PII Veri Tokenizasyonu

PII verilerinin tokenizasyonu

1) Neden tokenizasyon ve tam olarak neyi tokenize ediyoruz

Amaç: Operasyonel devrede ve analitikte "ham" kişisel verilere erişimi dışlamak, sızıntı riskini azaltmak ve gereksinimlere uyumu basitleştirmek.
PII örnekleri: tam ad, telefon numarası, e-posta, adres, pasaport/kimlik, TIN, IP adresleri, çerez kimliği, ödeme tanımlayıcıları, doğum tarihi vb.

• Orijinal değeri açıklamaz;
• Geri dönüşümlü (güvenli bir detokenasyon servisi aracılığıyla) veya geri dönüşümsüz olabilir;
• Deterministik (katılma/arama için) veya deterministik olmayan (maksimum gizlilik için) olabilir.

2) Tehdit modeli ve kontrol hedefleri

Riskler: Veritabanı/log/yedekleme sızıntıları, içeriden okumalar, değerleri tekrarlayarak korelasyon, yetkisiz detokenizasyon, sözlük/format saldırıları (e-posta/telefon), sırların yeniden kullanımı.

1. Ayrı güven bölgeleri: uygulama belirteçlerle, kaynaklarla çalışır - yalnızca belirteç hizmetinde.

2. Belirteçlerin kriptografik gücünü ve yönetilen detokenasyonu garanti edin.

3. KMS/HSM, rotasyon ve kripto sterilizasyonu ile patlama yarıçapını azaltın.

4. Kontrollü risk altında arama/joyns/analitik için uygunluğunu sağlamak.

3) Belirteçlerin tipolojisi

• Arama/joynes için PII: geri dönüşümlü deterministik, bölgeye bağlı (kiracı/kapsam), KMS üzerine sabitlenmiş.
• Operasyonel maskeleme için PII (UI): Yeniden kullanım risklerini azaltmak için ömür boyu geri dönüşümlü nondeterministik.
• Gri bölge analizi için: geri dönüşümsüz (anahtar NMAC/tuz hash) veya DP toplamları.

4) Tokenization mimarisi

4. 1 Bileşenler

Tokenization Service (TS): "tokenize/detokenize/search" API, yüksek güven bölgesi.
Token Vault (TV): korumalı harita 'token> original (+ metadata)'.
KMS/HSM: kök anahtar depolama (KEK), sarma/imzalama işlemleri.
Politika Motoru: kim, nerede ve neden detokenize olabilir; kapsam/TTL/oran-limitleri; mTLS/mTLS + mTLS.
Denetim ve Bağışıklık: Tüm tokenizasyon/detokenizasyon işlemlerinin değişmez günlükleri.

4. 2 Anahtar hiyerarşisi

KMS/HSM'de Kök/KEK (kuruluş/bölge/kiracı başına).
Veri alanı (e-posta/telefon/adres) ve/veya veri kümesi başına DEK-PII.
Rotasyon: Tüm voltu yeniden şifrelemeden DEK'i yeniden sarmak; "Anahtar uzlaşma" planı.

4. 3 Akışlar

1. Tokenize: TS> istemci (mTLS + A&A) - normalleştirme - belirteç hesaplama - TV'ye yazma - belirteç yanıtı.
2. Detokenize - TS - Client - Policy/Reason Check - Source Check (or Reject).
3. Arama/Eşleştirme: deterministik tokenization, token ile arama yapmanızı sağlar; E-posta/telefon için - tokenizasyondan önce formatı normalleştirin.

5) Token tasarımları (kripto tasarımı)

5. 1 Tersinir (çalışma devresi için önerilir)

AES-SIV/AEAD zarfı: 'şifre = AEAD_Encrypt (DEK, PII, AAD = scope' tenant 'field)'; token = 'prefix' nonce 'cipher' tag '.
Formatlar için FPE (FF1/FF3-1) (örn. Ülke kodu olmayan 10 haneli telefon). Dikkatli ve doğru etki alanı (alfabe/uzunluk) ile uygulayın.

5. 2 Geri dönüşümsüz (analitik/yüz anonimleştirme)

Anahtarlı HMAC/хэш: 'Token = HMAC (PII_normalized, key = K _ scope)'; tuz/karabiber - ayrı; kiracı veya veri kümesi başına.
Bir fonksiyon (SHA-256/512) ve bir etki alanı seçerek çarpışma riskini en aza indirin.

5. 3 Determinizm ve Kapsam

Katılmak için, AAD = '{tenant' purpose 'field}'ile deterministik bir şema kullanın - aynı değerdeki farklı belirteçler farklı hedeflere karşılık gelir.
Farklı hizmetlerde anti-korelasyon için - farklı anahtarlar/alanlar.

5. 4 Sözlük saldırılarını en aza indirin

Normalleştirme (e-posta/telefonun kanonlaştırılması), KMS'de biber, alan büyüklüğü sınırlaması (yan kanal olarak "kayıt bulunamadı" hataları vermeyin), oran sınırı ve genel noktalar için SARTSNA/proxy.

6) API tasarımı ve şemaları

6. 1 REST/gRPC (isteğe bağlı)

'POST/v1/tokenize {field, value, scope, tenant_id, purpose} -> {token, meta}'

'POST/v1/detokenize {token, purpose} -> {value}' (mTLS + OIDC + ABAC; "minimize" verilmesi)

'POST/v1/match {field, value} -> {token}' (deterministik arama yolu)

6. 2 Depolama diyagramı (TV)

Таблица belirteçleri (alan, kapsam, tenant_id, belirteç, created_at, sürüm, wrapped_key_id, hash_index)

Dizinler: Çoğaltma/arama için 'belirteç', '(tenant_id, alan, hash_index)'ile.
Hash indeksi (normalleştirilmiş PII'den HMAC) detokenizasyon olmadan arama yapmanızı sağlar.

6. 3 Normalleştirme boru hatları

E-posta: küçük harf, kesim, kanonik yerel bölüm (tüm alanlar için noktaların agresif "yemesi" olmadan).
telefon: E.164 (ülke koduyla), biçimlendirme karakterlerini kaldırma.
adres/ad: kurallara göre transliterasyon, trim, daraltma uzayları.

7) Çok kiracılık ve izolasyon

Kiracı başına anahtarlar ve ad alanları: Kiracı başına KEK/DEK.
Detokenizasyon politikaları: rol + hedef + neden + olay denetimi.
Kiracı verilerinin kripto silinmesi - KEK iptali ve DEK imhası - voltlar işe yaramaz hale gelir (kayıtları için).

8) Entegrasyonlar

8. 1 Veritabanları ve önbellekler

Yalnızca belirteçleri işletim tablolarında saklayın.
Nadir durumlarda, bir proxy/ajan aracılığıyla anında detokenizasyon gerektirir.
Token önbellekleri - sadece kısa bir TTL ile bellekte, diske yazmadan.

8. 2 Analitik/BI/ML

DWH/gölde, belirteçler veya hashler. Katılma, ilgili kapsamın deterministik belirteçleri üzerinde gerçekleştirilir.
ML için, takma ad ve agregalar tercih edilir; İnsanları restore etmekten kaçının.

8. 3 Destek hizmetleri ve dolandırıcılıkla mücadele

Maske ile UI ('+ 380') ve makul bir nedenden dolayı epizodik detokenizasyon (sebep kodu) + ikinci faktör.

9) Rotasyon, versiyonlar ve yaşam döngüsü

Belirteç kimliğini ve şifreleme sürümünü ayırın (v1/v2).
Rewrap: KEK'i verilere dokunmadan değiştirin.
Olay planı: anahtar uzlaşma - anında geri çağırma, detokenizasyonun yasaklanması, "salt okunur'a geri dönme, yeniden sarma başlatma.
TTL belirteçleri: politikaya göre - kalıcı (tanımlayıcılar) veya kısa (bir kerelik bağlantılar/geçici entegrasyonlar).

10) Performans ve güvenilirlik

Donanım hızlandırmaları (AES-NI/ARMv8), KMS'ye bağlantı havuzları, sarılmış DEK'lerin önbelleği.
Yatay ölçeklendirme TS; Okuma/yazma yollarını bölün.
Ağ bayrakları için tokenize tekrarları için idempotency-key.
DR/HA: çok alanlı, asenkron volt kopyası, düzenli kurtarma testleri.
SLO: p99 gecikme 'tokenize' ≤ 50-100 ms; 'detokenize' ≤ 50 ms; kullanılabilirlik ≥ 99. 9%.

11) Gözlemlenebilirlik, denetim, uyumluluk

Metrikler: Yöntemlere göre QPS, A&A hataları, detokenasyonların paylaşımı (rollere/hedeflere göre), önbellek isabet oranı, KMS işlem süresi.
Denetim (değişmez):'kim/ne/neden/nerede'ile her detokenasyon, sorgu hash, sonuç.
Günlüğe ilişkin saklama ve WORM ilkeleri (bkz. Denetim ve Değişmez Günlükler).
Uyumluluk: GDPR (minimization, right to delete via crypto erasure), PCI DSS (for PAN - FPE/pseudonymization), ISO/SOC raporlama.

12) Test ve güvenlik

Kripto birim testleri: deterministik belirteçlerin kararlılığı, AAD'nin doğrulanması ve eşleşmezse başarısızlık.
Negatif testler: sözlük saldırıları, format ters, hız sınırı, CSRF (web panelleri için), arka uçlar için SSRF.
Kaos: KMS/Volt kullanılamıyor, eski anahtar, kısmi çoğaltma.
Periyodik Kırmızı takım sebepsiz ve yan kanallar aracılığıyla detokenize olmaya çalışır.

13) Mini tarifler

pii_norm = normalize(value)
aad   = scope          tenant          field dek   = kms. unwrap(kek_id, wrapped_dek_for_field)
token = aead_siv_encrypt (dek, pii_norm, aad) # deterministically store_vault (token, pii_norm, meta)
return token

pii_norm = normalize(value)
pepper  = kms. get_secret("pepper/"+tenant+"/"+field)
token = HMAC_SHA256 (pepper, pii_norm) # deterministically within scope return base64url (token)

allow if role in {SupportL2, Risk, DPO} and purpose in {KYC, Chargeback, DSAR}
and mTLS and OIDC_claims match tenant and reason_code provided and ticket_id linked rate_limit per actor <= N/min

kms. disable_key(kek_tenant)
access to unwrap is blocked → detoxification is not possible schedule_destroy (kek_tenant, hold_days=7)

14) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı

Günlüklerde belirteçler. Belirteçlerin kendilerini (özellikle geri dönüşümlü olanları) maskeleyin - bunlar hassas verilerdir.
Her şey için tek anahtar. "Kiracı/alan/hedefe göre böl; AAD kullan.
Normalleştirme "rastgele. Koordinasyonsuz kanonizasyon arama/sevinç yıkar.
Sebep/sınırlama olmadan detokenizasyon. Her zaman sebep kodu, denetim ve oran sınırı.
Her derde deva olarak FPE. Yalnızca format gerçekten gerekli olduğunda ve doğru etki alanı/anahtarlarla kullanın.
Diskte uzun ömürlü önbellekler. Önbellek sadece TTL ile bellekte.
Rewrap işlemi yok. KEK'in kesinti olmadan döndürülmesi zorunludur.

15) Kontrol listeleri

Satmadan önce

• Alan/hedef başına seçilen belirteç profilleri (tersinirlik/determinizm/kapsam).
• Anahtar hiyerarşisi (KEK/DEK), KMS politikaları, anahtar işlem denetimi yapılandırılmıştır.
• Giriş normalleştirme, format doğrulama boru hattı uygulandı.
• Rate-limit, reason-codes, immutable audit etkin.
• Sözlük saldırıları için testler/biçim/rol tabanlı erişim geçti.
• DR/replica volt ve anahtar uzlaşma planı.

Operasyon

• Aylık detokenasyon raporu (kim/neden/ne kadar).
• KEK/biber periyodik rotasyon, DEK rewrap.
• Yetkisiz detokenasyon/yan kanallar için kırmızı takım.
• Yeni formatlar/bölgeler ortaya çıktıkça normalleştirmeyi gözden geçirin.

16) SSS

S: Tokenization = anonimleştirme?
Oh hayır. Tokenization - takma isim. Anahtarlar/volt varsa kaynak geri yüklenir (veya karşılaştırılabilir). GDPR alanından çıkmak için güvenilir anonimleştirme gerekir.

S: Detokenizasyon olmadan e-posta/telefonla nasıl arama yapılır?
C: Kanonlaşma ile detemine tokenizasyon. Adresler/tam adlar için - karma dizinler/arama anahtarları ve yardımcı tablolar.

S: FPE ne zaman gereklidir?
C: Harici bir sözleşme/şema format (uzunluk/alfabe) gerektirdiğinde. Diğer durumlarda, normal AEAD belirteçleri daha basit ve daha güvenlidir.

S: Tüm amaçlar için bir jetona sahip olmak mümkün mü?
C: Daha iyi farklı kapsamlar (kapsam/amaç): Aynı PII, farklı görevler için farklı belirteçler verir - korelasyon riskini azaltır.

S: "Kaldırma hakkını" nasıl kullanıyorsunuz?
C: Kripto silme: Karşılık gelen set için KEK/DEK'i iptal edin ve/veya volttaki girişi silin + alanı/parti anahtarlarını yok edin; Analitikte - TTL/toplama/depersonalizasyon.

• "Gizli yönetim"
• "Dinlenme Şifreleme"
• "Transit Şifrelemede"
• "Tasarıma Göre Gizlilik (GDPR)"
• "Denetim ve değişmez günlükler"
• "Anahtar Yönetimi ve Rotasyon"