PII məlumatların tokenlaşdırılması

PII məlumatların tokenləşdirilməsi

1) Tokenizasiya nə üçün və tokenizasiya nədir

Məqsəd: əməliyyat dövrəsi və analitikada «xam» şəxsi məlumatlara müraciət istisna etmək, sızma riskini azaltmaq və tələblərə uyğunluğu sadələşdirmək.
PII nümunələri: adı, telefon, email, ünvan, pasport/ID, VÖEN, IP ünvanları, cookie-ID, ödəniş identifikatorları, doğum tarixi və s.

• başlanğıc dəyərini açıqlamır;
• geri döndürülebilir (qorunan detokenizasiya xidməti vasitəsilə) və ya geri dönməz ola bilər;
• müəyyən edilə bilər (join/axtarış üçün) və ya qeyri-müəyyən (maksimum gizlilik üçün).

2) Təhdidlər modeli və nəzarət məqsədləri

Risklər: DB/log/backup sızması, insayder oxunuşları, təkrarlanan dəyərlərlə korrelyasiya, icazəsiz detokenizasiya, lüğət/format hücumları (email/telefon), sirlərin yenidən istifadəsi.

1. Etimad bölgələrini bölün: proqram tokenlərlə işləyir, mənbələr - yalnız token xidmətində.

2. Tokenlərin kriptoqrafik davamlılığını və idarə olunan detokenizasiyanı təmin edin.

3. KMS/HSM, rotasiya və «kriptovalyutası» ilə blast radius azaldın.

4. Nəzarət edilən risk altında/joynes/analitika üçün uyğunluq təmin edin.

3) Tokenlərin tipologiyası

• PII axtarış/Joyns: geri determinik, sahəyə bağlı (tenant/scope), KMS-də bir mandal ilə.
• PII Əməliyyat Maskası (UI): təkrar istifadə riskini azaltmaq üçün həyat müddəti ilə geri çevrilə bilən qeyri-perminized.
• «Boz zonada» analitiklər üçün: geri dönməz (duz ilə açar NMAS/hash) və ya DP aqreqasiyası.

4) Tokenizasiya arxitekturası

4. 1 Komponentlər

Tokenization Service (TS): «tokenize/detokenize/search» API, yüksək etimad zonası.
Token Vault (TV): qorunan mapa 'token → original (+ metadata)'.
KMS/HSM: kök açarları (KEK) saxlama, sarma/imza əməliyyatları.
Policy Engine: kim, harada və nə üçün detokinasiya edə bilər; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutability: Bütün tokenizasiya/detokinizasiya əməliyyatlarının dəyişməz jurnalları.

4. 2 Açar iyerarxiyası

KMS/HSM Root/KEK (təşkilat/region/kirayəçi).
DEK-PII məlumat domenində (email/phone/address) və/və ya dataset.
Rotasiya: bütün voltun şifrəsi olmadan DEK rewrap; «açar güzəşti» planı.

4. 3 axınlar

1. Tokenize: müştəri → TS (mTLS + A&A) → normallaşma → token hesablanması → TV-də qeyd → tokenlə cavab.
2. Detokenize: hüquqlar ilə müştəri → TS → siyasət yoxlama/baza → mənbə verilməsi (və ya imtina).
3. Search/Match: determinizasiya tokenlə axtarmağa imkan verir; email/telefon üçün - tokenizasiyadan əvvəl formatı normallaşdırın.

5) Token dizaynları (kriptovalyutası)

5. 1 Geri qaytarıla bilən (əməliyyat dövrəsi üçün tövsiyə olunur)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; token = 'prefix' nonce 'cipher' tag '.
Formatlar üçün FPE (FF1/FF3-1) (məsələn, ölkə kodu olmayan 10 rəqəmli telefon). Ehtiyatla və düzgün domenlə tətbiq edin (əlifba/uzunluq).

5. 2 Geri dönməz (analitika/anonimləşdirmə)

Keyed HMAC/хэш: `token = HMAC(PII_normalized, key=K_scope)`; duz/pepper - ayrı; kirayəçi və ya tarix.
Bir funksiya (SHA-256/512) və domen seçimi ilə toqquşma riskini minimuma endirin.

5. 3 Determinizm və fəaliyyət sahəsi

join üçün AAD = '{tenant' purpose 'field}' → ilə müəyyən edilmiş sxemdən istifadə edin.
Müxtəlif xidmətlərdə anti-korrelyasiya üçün - müxtəlif açarlar/sahələr.

5. 4 Lüğət hücumlarını minimuma endirin

Normallaşma (email/telefon kanonizasiyası), KMS-də pepper, domen ölçüsünün məhdudlaşdırılması (sayd-kanal kimi «səhv tapılmadı»), rate-limit və SARTSNA/ictimai nöqtələr üçün proxy.

6) API dizaynı və sxemləri

6. 1 REST/gRPC (variant)

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

`POST /v1/detokenize { token, purpose } -> { value }` (mTLS + OIDC + ABAC; emissiyanın «minimallaşdırılması»)

'POST/v1/match {field, value} -> {token}' (axtarış üçün müəyyən edilmiş yol)

6. 2 Saxlama sxemi (TV)

Таблица `tokens(field, scope, tenant_id, token, created_at, version, wrapped_key_id, hash_index)`

Indekslər: 'token', '(tenant_id, field, hash_index)' duplikasiya/axtarış üçün.
Hash index (normallaşdırılmış PII-dən HMAC) detokinasiyasız axtarışa imkan verir.

6. 3 Normallaşdırma konveyerləri

email: lowercasing, trim, canonical local-part (bütün domenlər üçün aqressiv «yemək» nöqtələri olmadan).
phone: E.164 (ölkə kodu ilə), format simvollarını silmək.
address/name: transliterasiya qaydaları, trim, collapse spaces.

7) Çox icarə və izolyasiya

Kirayəçi üçün açarlar və namespaces: KEK/DEK per tenant.
Detokenizasiya siyasəti: rol + məqsəd + səbəb + tədbir-audit.
Kirayəçi məlumatlarının kriptovalyutası - KEK geri çağırılması və DEK → voltun məhv edilməsi faydasız olur (onun qeydləri üçün).

8) İnteqrasiya

8. 1 Verilənlər bazası və caches

Yalnız tokenləri əməliyyat cədvəllərində saxlayın.
Nadir hallar üçün proxy/agent vasitəsilə «uçuşda» detokenizasiya lazımdır.
Tokenların keşləri - yalnız qısa TTL yaddaşında, diskə yazılmadan.

8. 2 Analitika/BI/ML

DWH/göldə - tokenlər və ya hash. Join müvafiq scope determinated tokenləri ilə həyata keçirilir.
ML üçün - daha çox təxəllüs və aqreqatlar; fərdlərin bərpasından çəkinmək.

8. 3 Dəstək və antifrod xidmətləri

Maska ilə UI ('+ 380') və əsaslı səbəbdən epizodik detokenizasiya (reason code) + second factor.

9) Rotasiya, versiyaları və həyat dövrü

Token identifikatoru və şifrələmə versiyasını (v1/v2) bölün.
Rewrap: məlumatlara toxunmadan KEK-i dəyişdiririk.
Hadisə planı: açarların pozulması → dərhal geri çağırılması, detokenizasiyanın qadağan edilməsi, «read-only» -ə geri çəkilməsi, rewrap-ın başlaması.
TTL tokenləri: siyasət - daimi (identifikatorlar) və ya qısa (birdəfəlik linklər/müvəqqəti inteqrasiyalar).

10) Performans və etibarlılıq

Aparat sürətləndirmələri (AES-NI/ARMv8), KMS-ə qoşulma hovuzları, DEK-ə sarılmış cache.
Üfüqi ölçmə TS; ayrılması read/write yolları.
Şəbəkə qapaqlarında tokenize təkrarları üçün idempotency-key.
DR/HA: multi-zonallıq, voltun asenxron replikası, müntəzəm bərpa testləri.
SLO: p99 latentlik 'tokenize' ≤ 50-100 ms; 'detokenize' ≤ 50 ms; mövcudluğu ≥ 99. 9%.

11) Müşahidə, audit, uyğunluq

Metriklər: QPS metodları, A&A səhvləri, detokenizasiyaların payı (rollar/məqsədlər üzrə), hit-rate cache, KMS əməliyyatlarının vaxtı.
Audit (dəyişməz): Hər detokinasiya ilə 'who/what/why/where', hash sorğu, nəticə.
Jurnal üçün saxlama və WORM siyasəti (bax: «Audit və dəyişməz jurnallar»).
Uyğunluq: GDPR (minimallaşdırma, kriptovalyuta silmə hüququ), PCI DSS (PAN üçün - FPE/təxəllüs), ISO/SOC hesabat.

12) Test və təhlükəsizlik

Kriptovalyuta testləri: determinizasiya edilmiş tokenlərin sabitliyi, AAD yoxlaması və uyğunsuzluq zamanı imtina.
Mənfi testlər: lüğət hücumları, format tərs, rate-limit, CSRF (veb panellər üçün), SSRF-lər.
Chaos: KMS/volt, köhnəlmiş açar, qismən replikasiya mövcud deyil.
Dövri Red-team səbəbsiz və yan kanallar vasitəsilə detokinasiya cəhdləri.

13) Mini reseptlər

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) Tez-tez səhvlər və onlardan necə qaçmaq olar

Loglarda tokenlər. Maskalamaq və tokenlər özünüz (xüsusilə geri qaytarıla bilən) həssas məlumatlardır.
"Hər şey üçün 'bir açar. Kirayəçilər/sahələr/məqsədlər üzrə bölün; AAD istifadə edin.
Normallaşma «olduğu kimi». Razılaşdırılmamış kanonizasiya axtarış/coynları pozur.
Səbəbsiz/məhdudiyyətsiz detokenizasiya. Həmişə reason code, audit və rate-limit.
FPE panacea kimi. Yalnız düzgün domen/açar formatına ehtiyac olduqda tətbiq edin.
Uzun ömürlü disk caches. Yalnız TTL yaddaşında cache.
Rewrap prosesi yoxdur. Kəsilmədən KEK-in rotasiyası tələb olunur.

15) Çek vərəqləri

Məhsuldan əvvəl

• Seçilmiş token profilləri per sahəsi/hədəf (dönüşümlülük/determinizm/sahə).
• Açar iyerarxiyası (KEK/DEK), KMS siyasəti, açar əməliyyatların auditi.
• Giriş normallaşdırılması, formatların validasiya konveyeri həyata keçirildi.
• rate-limit, reason-codes, dəyişməz audit daxildir.
• Lüğət hücumları/format/rola əsaslanan giriş testləri keçdi.
• DR/volt replikası və açar güzəşt planı.

Əməliyyat

• Detokenizasiya üzrə aylıq hesabat (kim/niyə/nə qədər).
• Dövri rotasiya KEK/pepper, DEK rewrap.
• Icazəsiz detokinizasiya/yan kanallara Red-team.
• Yeni formatların/regionların yaranması zamanı normallaşmanın yenidən nəzərdən keçirilməsi.

16) FAQ

S: Tokenization = anonimləşdirmə?
A: Yox. Tokenizasiya - təxəllüsləşmə. Mənbəyi açar/volt olduqda bərpa edəcəyik (və ya müqayisə edəcəyik). GDPR sahəsindən çıxmaq üçün etibarlı anonimləşdirmə tələb olunur.

S: Detokenizasiya olmadan e-poçt/telefon vasitəsilə necə axtarmaq olar?
A: Kanonizasiya ilə deteminləşdirilmiş tokenizasiya. Ünvanlar/tam adları üçün - hash indeksləri/axtarış açarları və köməkçi cədvəllər.

S: FPE nə vaxt lazımdır?
A: Xarici müqavilə/sxem format tələb zaman (uzunluq/əlifba). Digər hallarda - adi AEAD tokenləri daha asan və təhlükəsizdir.

S: Bütün məqsədlər üçün bir token mümkündürmü?
A: Fərqli sahələr daha yaxşıdır (scope/purpose): eyni PII müxtəlif vəzifələr üçün fərqli tokenlər verir → korrelyasiya riskini azaldır.

S: «silinmə hüququ» necə yerinə yetirilir?
A: Kriptovalyutası: Müvafiq dəst üçün KEK/DEK-i geri çağırın və/və ya volt girişini silin + sahə/partiya açarlarını məhv edin; analitikada - TTL/aqreqasiya/anonimləşdirmə.

• «Sirlərin menecmenti»
• «At Rest şifrələmə»
• «In Transit Şifrələmə»
• «Privacy by Design (GDPR)»
• «Audit və dəyişməz jurnallar»
• «Açarların idarə edilməsi və rotasiya»