PII მონაცემების ტოქსიკაცია

PII მონაცემების ტოკენიზაცია

1) რატომ არის ტოკენიზაცია და რა არის ტოკენიზირებული

მიზანი: გამორიცხოს „ნედლეული“ პერსონალური მონაცემების მიმართვა ოპერაციულ წრეში და ანალიტიკაში, შეამციროს გაჟონვის რისკი და გაამარტივოს მოთხოვნები.
PII მაგალითები: FIO, ტელეფონი, ელ.ფოსტა, მისამართი, პასპორტი/ID, TIN, IP მისამართები, cookie-ID, გადახდის იდენტიფიკატორები, დაბადების თარიღი და ა.შ.

• არ ავლენს პირვანდელ მნიშვნელობას;
• შეიძლება შექცევადი იყოს (დაცული დეტოკენიზაციის სერვისის საშუალებით) ან შეუქცევადი;
• ეს შეიძლება იყოს დეტერმინირებული (join/ძებნისთვის) ან არარეგულირებული (მაქსიმალური კონფიდენციალურობისთვის).

2) მუქარის მოდელი და კონტროლის მიზანი

რისკები: BD/logs/becap- ის გაჟონვა, ინსაიდერის კითხვა, განმეორებითი მნიშვნელობების კორელაცია, უნებართვო დეტოკენიზაცია, ლექსიკონის/ფორმატის (ელ.ფოსტის/ტელეფონის) შეტევები, საიდუმლოების ხელახალი გამოყენება.

1. გაზიარეთ ნდობის ზონები: განაცხადი მუშაობს ნიშნით, წყაროები - მხოლოდ ნიშნის სერვისში.

2. უზრუნველყოს ტოქსინების კრიპტოგრაფიული წინააღმდეგობა და კონტროლირებადი დეტოკენიზაცია.

3. blast radius- ის შემცირება KMS/HSM გამოყენებით, როტაცია და „კრიპტო სტერილიზაცია“.

4. კონტროლირებადი რისკის მქონე ძებნის/ჯოინის/ანალიტიკის უზრუნველსაყოფად.

3) ტოკენის ტიპოლოგია

• PII საძიებო/ჯოინის მოსაძებნად: შექცევადი დეტერმინები, რომლებიც მიბმული არიან რეგიონთან (მენანტი/სკოპი), თავსახური KMS- ზე.
• PII ოპერატიული შენიღბვისთვის (UI): შექცევადი განუყოფელი სიცოცხლის ხანგრძლივობით, განმეორებითი გამოყენების რისკების შესამცირებლად.
• „ნაცრისფერ ზონაში“ ანალიტიკოსებისთვის: შეუქცევადი (ძირითადი NMAS/ჰეში მარილით) ან DP აგრეგაცია.

4) ტოკენიზაციის არქიტექტურა

4. 1 კომპონენტები

Tokenize Service (TS): API „tokenize/detokenize/search“, გაზრდილი ნდობის ზონა.
Token Vault (TV): დაცული 'token' mapa - ორიგინალი (+ მეტამონაცემები) '.
KMS/HSM: ფესვის გასაღებების (KEK) შენახვა, შეფუთვის/ხელმოწერის ოპერაციები.
Policy Engine: ვინ, სად და რატომ შეუძლია დეტოქსიკაცია; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutability: ყველა ტოკენიზაციის/დეტოკენიზაციის ოპერაციის უცვლელი ჟურნალები.

4. 2 გასაღების იერარქია

Root/KEK in KMS/HSM (ორგანიზაცია/რეგიონი/მოიჯარე).
DEK-PII მონაცემთა დომენზე (email/phone/address) და/ან მონაცემთა ბაზაზე.
როტაცია: rewrap DEK ყველა ტალღის გადაადგილების გარეშე; გეგმა „გასაღების კომპრომისზე“.

4. 3 ნაკადები

1. Tokenize: TS კლიენტი (mTLS + A&A) - ნიშნის ნორმალიზება - გაანგარიშება - ჩანაწერი TV- ში - ნიშნის პასუხი.
2. Detokenize: TS უფლებების მქონე კლიენტი - პოლიტიკის/საფუძვლის შემოწმება - წყაროს გაცემა (ან უარის თქმა).
3. Search/Match: დეტერმინისტული დოქენიზაცია საშუალებას გაძლევთ მოძებნოთ docken; ელექტრონული/ტელეფონისთვის - ფორმატის ნორმალიზება ტოკენიზაციამდე.

5) ტოქსინების დიზაინი (კრიპტო დიზაინი)

5. 1 შექცევადი (რეკომენდებულია ოპერაციული წრისთვის)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; ნიშანი = 'prefix' nonce 'cipher' tag '.
FPE (FF1/FF3-1) ფორმატებისთვის (მაგ., 10 - ნიშნა ტელეფონი ქვეყნის კოდის გარეშე). გამოიყენეთ სიფრთხილით და სწორი დომენით (ანბანი/სიგრძე).

5. 2 შეუქცევადი (ანალიტიკა/ანონიმიზაცია ზღვარზე)

Keyed HMAC/хэш: `token = HMAC(PII_normalized, key=K_scope)`; მარილი/pepper - ცალკე; მოიჯარეზე ან დათქმაზე.
შეჯახების რისკი მინიმუმამდე დაიყვანოს ფუნქციის არჩევით (SHA-256/512) და დომენით.

5. 3 დეტერმინიზმი და მოქმედების სფერო

Join- ისთვის გამოიყენეთ დეტერმინისტული სქემა AAD = '{tenant' purpose 'field' 'და იგივე მნიშვნელობის სხვადასხვა ნიშნები შეესაბამება სხვადასხვა მიზნებს.
სხვადასხვა სერვისებში ანტი-კორელაციისთვის - სხვადასხვა გასაღებები/სფეროები.

5. 4 ჩვენ მინიმუმამდე დავიყვანთ შეტევებს ლექსიკონში

ნორმალიზაცია (email/ტელეფონის კანონიზაცია), KMS- ში pepper, დომენის ზომების შეზღუდვა (შეცდომების დაშვება „არ არის ნაპოვნი“, როგორც გვერდითი არხი), rate-limit და CARTSNA/მარიონეტული საზოგადოებრივი წერტილებისთვის.

6) API და სქემების დიზაინი

6. 1 REST/gRPC (ვარიანტი)

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

`POST /v1/detokenize { token, purpose } -> { value }` (mTLS + OIDC + ABAC; ექსტრადიციის „შემცირება“)

'POST/v1/match {field, value} -> {token}' (დეტერმინისტული საძიებო გზა)

6. 2 შენახვის სქემა (TV)

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

ინდექსები: 'token', '(tenant _ id, vield, hash _ index)' დე-დუპლიკაციის/ძიებისთვის.
Hash index (HMAC ნორმალიზებული PII- დან) საშუალებას გაძლევთ მოძებნოთ დეტოკენიზაციის გარეშე.

6. 3 კონვეიერები ნორმალიზებისთვის

email: lowercasing, trim, canonic ადგილობრივი ნაწილი (ყველა დომენისთვის აგრესიული „ჭამის“ წერტილების გარეშე).
phone: E.164 (ქვეყნის კოდით), ფორმატის სიმბოლოების მოცილება.
address/name: ტრანსლიტერაცია წესების მიხედვით, trim, collapse spaces.

7) მრავალფეროვნება და იზოლაცია

გასაღებები და namespaces მოიჯარეებისთვის: KEK/DEK per tenant.
დეტოქსიკაციის პოლიტიკა: როლი + მიზანი + მიზეზი + ღონისძიების აუდიტი.
მოიჯარის მონაცემების კრიპტო წაშლა - KEK- ის მიმოხილვა და DEK- ის განადგურება - ვოლტი უსარგებლო ხდება (მისი ჩანაწერებისთვის).

8) ინტეგრაცია

8. 1 მონაცემთა ბაზა და ქეში

შეინახეთ მხოლოდ ნიშნები ოპერაციულ ცხრილებში.
იშვიათი შემთხვევებისთვის, თქვენ გჭირდებათ დეტოკენიზაცია „ფრენისთვის“ მარიონეტული/აგენტის მეშვეობით.
ტოკენის ქეში მხოლოდ მეხსიერებაში მოკლე TTL- ით, დისკზე ჩაწერის გარეშე.

8. 2 ანალიტიკა/BI/ML

DWH/ტბაში - ნიშნები ან ჰეშები. Join ხორციელდება შესაბამისი scope- ის დეტერმინირებული ნიშნით.
ML- სთვის - სასურველია ფსევდონიზაცია და აგრეგატები; თავიდან აიცილოთ პიროვნების აღდგენა.

8. 3 დამხმარე და ანტიფროდიული მომსახურება

UI ნიღაბი ('+ 380') და ეპიზოდური დეტოკენიზაცია გამართლებული მიზეზის გამო (reason code) + მეორე ფაქტორი.

9) როტაცია, ვერსიები და სასიცოცხლო ციკლი

გაიზიარეთ ნიშნის იდენტიფიკატორი და დაშიფვრის ვერსია (v1/v2).
Rewrap: ჩვენ ვცვლით KEK- ს მონაცემების შეხების გარეშე.
ინციდენტის გეგმა: კლავიშების კომპრომისი, მყისიერი მიმოხილვა, დეტოკენიზაციის აკრძალვა, დაბრუნება „read-only“, rewrap- ის გაშვება.
TTL ნიშნები: პოლიტიკაში - მუდმივი (იდენტიფიკატორები) ან მოკლე (ერთჯერადი ბმულები/დროებითი ინტეგრაცია).

10) პროდუქტიულობა და საიმედოობა

აპარატურის აჩქარება (AES-NI/ARMv8), ნაერთების აუზები KMS- ზე, გახვეული DEK- ის ქეში.
ჰორიზონტალური სკალირება TS; read/write ბილიკების გამიჯვნა.
Idempotence-key tokenize გამეორებისთვის ქსელის flaps.
DR/HA: მრავალსაფეხურიანი, ასინქრონული ვოლტის რეპლიკა, რეგულარული აღდგენის ტესტები.
SLO: ლატენტობის p99 'tokenize' 50-100 ms; "detokenize '50 ms; ხელმისაწვდომობა 99. 9%.

11) დაკვირვება, აუდიტი, შესაბამისობა

მეტრიკა: QPS მეთოდების მიხედვით, A&A შეცდომები, დეტოქსიკაციის წილი (როლები/მიზნები), hit-rate ქეში, KMS ოპერაციების დრო.
აუდიტი (უცვლელი): თითოეული დეტოქსიკაცია 'who/what/what/where', hash მოთხოვნა, შედეგი.
შენახვის პოლიტიკა და WORM ჟურნალისთვის (იხ. აუდიტი და უცვლელი ჟურნალები).
შესაბამისობა: GDPR (მინიმალიზაცია, კრიპტო-წაშლის საშუალებით მოცილების უფლება), PCI DSS (PAN- სთვის - FPE/ფსევდონიმი), ISO/SOC მოხსენება.

12) ტესტირება და უსაფრთხოება

კრიპტო - ერთეულის ტესტები: დეტერმინისტული ნიშნების სტაბილურობა, AAD- ის შემოწმება და მისი შეუსაბამობის უარყოფა.
უარყოფითი ტესტები: ლექსიკონის მიერ შეტევები, საპირისპირო ფორმატში, საბაზო-ლიმიტი, CSRF (ვებ - პანელებისთვის), SSRF ბეკენდებზე.
ქაოსი: KMS/ვოლტი, მოძველებული გასაღები, ნაწილობრივი რეპლიკაცია მიუწვდომელია.
პერიოდული წითელი გუნდის მცდელობები დეტოქსიკაციის გარეშე და გვერდითი არხებით.

13) მინი რეცეპტები

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) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

ნიშნები ლოგებში. შენიღბეთ და თავად ნიშნები (განსაკუთრებით შექცევადი) - ეს მგრძნობიარე მონაცემებია.
ერთი გასაღები „ყველაფრისთვის“. გაზიარეთ მოიჯარეები/მინდვრები/მიზნები; გამოიყენეთ AAD.
ნორმალიზაცია „როგორც აღმოჩნდა“. არაკოორდინირებული კანონიზაცია არღვევს ძებნას/ჯოინს.
დეტოქსიკაცია მიზეზების/შეზღუდვების გარეშე. ყოველთვის reason code, აუდიტი და საბინაო-ლიმიტი.
FPE, როგორც პანაცეა. გამოიყენეთ მხოლოდ ფორმატის რეალური საჭიროების შემთხვევაში და სწორი დომენით/კლავიშებით.
გრძელი ქეში დისკზე. კეში მხოლოდ TTL- ს მეხსიერებაშია.
rewrap პროცესის არარსებობა. KEK როტაცია სისუსტის გარეშე სავალდებულოა.

15) ჩეკის ფურცლები

გაყიდვამდე

• შეირჩა წინა ველის/სამიზნე ნიშნების პროფილები (შექცევადობა/დეტერმინიზმი/რეგიონი).
• შეიქმნა საკვანძო იერარქია (KEK/DEK), KMS პოლიტიკოსები და ძირითადი ოპერაციების აუდიტი.
• განხორციელდა შესასვლელების ნორმალიზება, ფორმატის სავალდებულო კონვეიერი.
• შედის rate-limit, reason-codes, უცვლელი აუდიტი.
• ტესტები ლექსიკურ შეტევებზე/ფორმატში/როლზე დაფუძნებული წვდომა გაიარა.
• DR/ვოლტის რეპლიკა და გასაღებების კომპრომისების გეგმა.

ოპერაცია

• ყოველთვიური ანგარიში დეტოქსიკაციის შესახებ (ვინ/რატომ/რამდენი).
• პერიოდული როტაცია KEK/pepper, rewrap DEK.
• წითელი გუნდი უნებართვო დეტოკენიზაციისთვის/გვერდითი არხებისთვის.
• ნორმალიზაციის გადასინჯვა ახალი ფორმატების/რეგიონების გამოჩენისას.

16) FAQ

გ: ტოკენიზაცია = ანონიმიზაცია?
ო: არა. ტოკენიზაცია - ფსევდონიმი. წყარო აღდგება (ან შედარებულია) კლავიშების/ვოლტის თანდასწრებით. GDPR სფეროს გასასვლელად საჭიროა საიმედო ანონიმიზაცია.

გ: როგორ ვეძებოთ ელ.ფოსტა/ტელეფონი დეტოკენიზაციის გარეშე?
ო: დეტემინირებული ტოქსიკაცია კანონიზაციით. მისამართებისთვის/FIO - მძიმე ინდექსები/საძიებო გასაღებები და დამხმარე ცხრილი.

გ: როდის გჭირდებათ FPE?
ო: როდესაც გარე კონტრაქტი/სქემა მოითხოვს ფორმატს (სიგრძე/ანბანი). სხვა შემთხვევებში - ჩვეულებრივი AEAD ნიშნები უფრო მარტივი და უსაფრთხოა.

გ: შესაძლებელია თუ არა ყველა მიზნისთვის ერთი ნიშანი?
O: უმჯობესია სხვადასხვა სფეროები (scope/purpose): ერთი და იგივე PII იძლევა სხვადასხვა ნიშანს სხვადასხვა ამოცანისთვის, ხოლო კორელაციის რისკი მცირდება.

გ: როგორ შევასრულოთ „მოხსნის უფლება“?
O: Crypto მოცილება: ჩვენ ვხსნით KEK/DEK- ს შესაბამისი ნაკრებისთვის, ან/ან ამოიღეთ ჩანაწერი ვოლტა + -ში, გაანადგურეთ ველის/თამაშის გასაღებები; ანალიტიკაში - TTL/აგრეგაცია/ანონიმურობა.

• საიდუმლო მენეჯმენტი
• „დაშიფვრა At Rest“
• „დაშიფვრა In Transit“
• «Privacy by Design (GDPR)»
• „აუდიტი და უცვლელი ჟურნალები“
• „კლავიშების მართვა და როტაცია“