PII ma’lumotlarni tokenlashtirish

PII-ma’lumotlarni tokenlashtirish

1) Tokenizatsiya nima uchun va aynan nimani tokenlashtiramiz

Maqsad: operatsion konturda va tahlilda «xom» shaxsiy maʼlumotlarga murojaat qilishni istisno qilish, sizib chiqish xavfini kamaytirish va talablarga muvofiqlikni soddalashtirish.
PII-misollar: F.I.O., telefon, email, manzil, pasport/ID, STIR, IP-manzillar, cookie-ID, to’lov identifikatorlari, tug’ilgan sanasi va boshqalar.

• boshlang’ich qiymatni oshkor qilmaydi;
• qaytarib olinadigan (himoyalangan detokenizatsiya xizmati orqali) yoki qaytarib bo’lmaydigan bo’lishi mumkin;
• determinirlangan (join/qidirish uchun) yoki eterminirlanmagan (maksimal maxfiylik uchun) bo’lishi mumkin.

2) Tahdidlar modeli va nazorat maqsadlari

Xavf-xatarlar: DB/loglar/bekaplarning sizib chiqishi, insayder o’qishlari, takrorlanuvchi qiymatlar bo’yicha korrelyatsiya, ruxsatsiz detokenizatsiya, lug’at/format bo’yicha hujumlar (email/telefon), sirlardan qayta foydalanish.

1. Ishonch zonalarini ajratish: dastur tokenlar bilan ishlaydi, manbalar faqat token xizmatida.

2. Tokenlarning kriptografik barqarorligini va boshqariladigan detokenizatsiyani kafolatlash.

3. KMS/HSM, rotatsiya va «kripto-sterilizatsiya» yordamida blast radiusni kamaytirish.

4. Nazorat qilinadigan tavakkalchilikda/joylarni/tahlillarni izlash uchun yaroqliligini ta’minlash.

3) Tokenlar tipologiyasi

• Qidirish/joylar uchun PII: teskari determinirlangan, sohaga bogʻlangan (tenant/scope), KMSda qulflangan.
• PII operativ niqoblash uchun (UI): qayta foydalanish xavfini kamaytirish uchun o’z umr ko’rish muddati bilan qaytarib berilishi mumkin bo’lmagan.
• «Kulrang zonada» tahlilchilar uchun: qaytarib bo’lmaydigan (asosiy NMAS/tuz bilan xesh) yoki DP-agregatsiyalar.

4) Tokenizatsiya arxitekturasi

4. 1 Komponentlar

Tokenization Service (TS): API «tokenize/detokenize/search», yuqori ishonch zonasi.
Token Vault (TV): himoyalangan mapa’token → original (+ meta maʼlumotlar)’.
KMS/HSM: ildiz kalitlarini saqlash (KEK), oʻrash/imzo operatsiyalari.
Policy Engine: kim, qaerda va nima uchun detokenizatsiya qilishi mumkin; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutability: barcha tokenizatsiya/detokenizatsiya operatsiyalarining oʻzgarmas jurnallari.

4. 2 Kalitlar ierarxiyasi

KMS/HSM da Root/KEK (tashkilotga/mintaqaga/ijarachiga).
DEK-PII ma’lumotlar domeniga (email/phone/address) va/yoki dataset.
Rotatsiya: butun voltni qayta ochmasdan rewrap DEK; «kalitni buzish» rejasi.

4. 3 Oqimlar

1. Tokenize: mijoz → TS (mTLS + A&A) → normallashtirish → tokenni hisoblash → TVga yozish → javob token.
2. Detokenize: huquqli mijoz → TS → siyosatni/asoslarni tekshirish → manbani berish (yoki rad etish).
3. Search/Match: determinizatsiya tokenni qidirish imkonini beradi; email/telefon uchun - tokenizatsiyadan oldin formatni normallashtiramiz.

5) Tokenlar konstruksiyalari (kripto-dizayn)

5. 1 Qaytariladigan (operatsion kontur uchun tavsiya etiladi)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; token =’prefix’nonce’cipher’tag’.
FPE (FF1/FF3-1) formatlar uchun (masalan, mamlakat kodisiz 10 belgili telefon). Ehtiyotkorlik va toʻgʻri domen (alifbo/uzunlik) bilan qoʻllash.

5. 2 Qaytarib bo’lmaydigan (tahlil qilish/anonimlashtirish)

Keyed HMAC/хэш: `token = HMAC(PII_normalized, key=K_scope)`; tuz/pepper - alohida; ijaraga oluvchi yoki sanasetga.
Konflikt xavfini funksiyani tanlash (SHA-256/512) va domen bilan minimallashtirish.

5. 3 Determinizm va harakatlar sohasi

Join uchun AAD =’{tenant’purpose’field}’bilan determinatsiya qilingan sxemadan foydalaning.
Turli xizmatlarda anti-korrelyatsiya uchun - turli kalitlar/sohalar.

5. 4 Hujumlarni lugʻat boʻyicha minimallashtiramiz

Normalizatsiya (email/telefon kanonizatsiyasi), KMSdagi pepper, domen oʻlchamlarini cheklash (sayd-kanal sifatida «xato topilmadi»), rate-limit va ommaviy nuqtalar uchun SARTSNA/proksi.

6) API dizayni va sxemalari

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; «minimallashtirish»)

’POST/v1/match {field, value} -> {token}’ (qidirish uchun aniqlangan yoʻl)

6. 2 Saqlash sxemasi (TV)

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

Indekslar:’token’,’po’(tenant_id, field, hash_index)’de-duplikatsiya/qidirish uchun.
Hash index (normallashtirilgan PII dan HMAC) detokenizatsiyasiz qidirish imkonini beradi.

6. 3 Normallashtirish konveyerlari

email: lowercasing, trim, canonical local-part (barcha domenlar uchun nuqtalarni tajovuzkor «yeymasdan»).
phone: E.164 (mamlakat kodi bilan), formatlovchi belgilarni olib tashlash.
address/name: transliteratsiya qoidalari, trim, collapse spaces.

7) Ko’p ijara va izolyatsiya

KEK/DEK per tenant.
Detokenizatsiya siyosati: rol + maqsad + sabab + tadbir-audit.
Ijarachining kripto-ma’lumotlarini olib tashlash - KEKni chaqirib olish va DEK → voltni yo’q qilish foydasiz bo’lib qoladi (uning yozuvlari uchun).

8) Integratsiya

8. 1 Maʼlumotlar bazasi va kesh

Faqat tokenlarni operatsion jadvallarda saqlang.
Kamdan-kam hollarda proksi/agent orqali detokenizatsiya qilish kerak.
Tokenlarning keshlari faqat qisqa TTL xotirasida, diskka yozilmagan.

8. 2 Tahlilchi/BI/ML

DWH/ko’lda - tokenlar yoki xeshlar. Join tegishli scope determinatsiyalangan tokenlari boʻyicha bajariladi.
ML uchun - afzalroq taxallus va agregatlar; shaxslarni tiklashdan qochish.

8. 3 Qo’llab-quvvatlash va antifrod xizmatlari

UI niqobli (’+ 380’) va asosli sababga ko’ra epizodik detokenizatsiya qilingan (reason code) + second factor.

9) Rotatsiya, versiyalar va hayot sikli

Token identifikatori va shifrlash versiyasini (v1/v2) ajrating.
Rewrap: maʼlumotlarga tegmasdan KEKni oʻzgartiramiz.
Hodisalar rejasi: kalitlarni buzish → bir zumda chaqirib olish, detokenizatsiyani taqiqlash, «read-only» ga qaytish, rewrap-ni ishga tushirish.
TTL tokenlari: siyosat bo’yicha - doimiy (identifikatorlar) yoki qisqa (bir martalik havolalar/vaqtinchalik integratsiyalar).

10) Unumdorlik va ishonchlilik

Apparat tezlashuvi (AES-NI/ARMv8), KMSga ulanish pullari, DEK o’ralgan kesh.
TS gorizontal masshtablash; yo’llarning read/write bo’linishi.
Tarmoq flaplarida tokenize takrorlash uchun idempotency-key.
DR/HA: ko’p zonalilik, o’lchamning asinxron nusxasi, muntazam tiklanish testlari.
SLO: p99 latentlik’tokenize’≤ 50-100 ms;’detokenize’≤ 50 ms; foydalanish imkoniyati ≥ 99. 9%.

11) Kuzatuv, audit, komplayens

Metrikasi: usullar bo’yicha QPS, A&A xatolari, detokenizatsiya ulushi (rollar/maqsadlar bo’yicha), kesh hit-rate, KMS operatsiyalari vaqti.
Audit (o’zgarmas): har bir detokenizatsiya’who/what/why/where’, so’rov xeshi, natija.
Jurnal uchun saqlash siyosati va WORM («Audit va o’zgarmas jurnallar» ga qarang).
Muvofiqlik: GDPR (minimallashtirish, kripto-o’chirish orqali olib tashlash huquqi), PCI DSS (PAN uchun - FPE/taxalluslashtirish), ISO/SOC hisobotlari.

12) Test sinovlari va xavfsizlik

Kripto-yunit testlari: determinizatsiya qilingan tokenlarning barqarorligi, AAD tekshiruvi va uning nomuvofiqligi rad etilishi.
Salbiy testlar: lug’at hujumlari, format bo’yicha revers, rate-limit, CSRF (veb-panellar uchun), SSRF bekendlar.
Chaos: KMS/volt, eskirgan kalit, qisman replikatsiya mavjud emas.
Davriy Red-team asossiz va yon kanallar orqali detokenizatsiya qilishga urinishlar.

13) Mini-retseptlar

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 xatolar va ulardan qanday qochish mumkin

Loglardagi tokenlar. O’zingizni kamuflyaj qiling (ayniqsa qaytariladigan) - bu sezgir ma’lumotlar.
Hamma narsaga bitta kalit. Ijarachilar/dalalar/maqsadlar bo’yicha taqsimlang; AAD’dan foydalaning.
Normal holatga kelish. Kelishilmagan kanonizatsiya qidiruv/joylarni buzadi.
Sababsiz/cheklovlarsiz detokenizatsiya qilish. Har doim reason code, audit va rate-limit.
FPE panatseya sifatida. Faqat formatni istalgan vaqtda va toʻgʻri domen/kalitlar bilan qoʻllash.
Diskda uzoq davom etadigan keshlar. Faqat TTL xotirasida kesh.
Rewrap jarayonining yoʻqligi. KEKni to’xtovsiz almashtirish majburiydir.

15) Chek-varaqlar

Sotishdan oldin

• Tanlangan tokenlarning profillari per/maqsad (qaytariluvchanlik/determinizm/hudud).
• Kalitlar ierarxiyasi (KEK/DEK), KMS siyosati, asosiy operatsiyalar auditi sozlandi.
• Kirishlarni normallashtirish, formatlarni validatsiya qilish konveyeri amalga oshirildi.
• rate-limit, reason-codes, o’zgarmas audit kiritilgan.
• Lugʻat hujumlari/format/rolga asoslangan kirish sinovlari oʻtkazildi.
• DR/volt nusxasi va kalitlarni buzish rejasi.

Foydalanish

• Detokenizatsiya bo’yicha har oylik hisobot (kim/nima uchun/qancha).
• KEK/pepper davriy rotatsiyasi, DEK rewrap.
• Ruxsat etilmagan detokenizatsiya/yon kanallar uchun Red-team.
• Yangi formatlar/hududlar paydo bo’lganda normallashtirishni qayta ko’rib chiqish.

16) FAQ

V: Tokenizatsiya = anonimlashtirish?
A: Yo’q. Tokenizatsiya - taxalluslashtirish. Kalit/volt mavjud boʻlsa, manbani tiklaymiz (yoki taqqoslaymiz). GDPR sohasidan chiqish uchun ishonchli anonimlashtirish talab etiladi.

S: Detokenizatsiyasiz elektron pochta/telefon orqali qanday izlash mumkin?
O: Kanonizatsiya bilan deteminlangan tokenlash. Manzillar/F.I.O. uchun - xesh-indekslar/qidiruv kalitlari va yordamchi jadvallar.

S: FPE qachon kerak?
O: Tashqi kontrakt/sxema formatni talab qilganda (uzunligi/alifbosi). Boshqa hollarda - oddiy AEAD tokenlari osonroq va xavfsizroq.

V: Barcha maqsadlar uchun bitta token boʻlishi mumkinmi?
O: Yaxshiroq turli sohalar (scope/purpose): bir xil PII turli vazifalar uchun turli tokenlarni beradi → korrelyatsiya xavfi kamayadi.

V: «Olib tashlash huquqini» qanday bajarish kerak?
O: Kripto-olib tashlash: tegishli to’plam uchun KEK/DEKni qaytarib olamiz va/yoki voltdagi yozuvni olib tashlaymiz + maydon/partiya kalitlarini yo’q qilamiz; tahlilda - TTL/agregatsiya/anonimlashtirish.

• «Sirlar menejmenti»
• «At Rest shifrlash»
• «In Transit shifrlash»
• «Privacy by Design (GDPR)»
• «Audit va o’zgarmas jurnallar»
• «Kalitlarni boshqarish va rotatsiya»