Tokenizacja danych PII

Tokenizacja danych PII

1) Dlaczego tokenizacja i co dokładnie tokenizujemy

Cel: wyłączenie dostępu do „surowych” danych osobowych w obiegu operacyjnym i analizie, zmniejszenie ryzyka wycieków oraz uproszczenie zgodności z wymogami.
Przykłady PII: pełna nazwa, numer telefonu, e-mail, adres, paszport/ID, NIP, adresy IP, identyfikator pliku cookie, identyfikatory płatności, data urodzenia itp.

• nie ujawnia pierwotnej wartości;
• mogą być odwracalne (za pośrednictwem bezpiecznej usługi detokenacji) lub nieodwracalne;
• może być deterministyczne (do przyłączenia/wyszukiwania) lub nie-deterministyczne (dla maksymalnej prywatności).

2) Model zagrożenia i cele kontroli

Ryzyko: wycieki bazy danych/dziennika/kopii zapasowych, odczyty poufne, korelacja przez powtarzające się wartości, nieautoryzowana detokenizacja, ataki słownika/formatu (e-mail/telefon), ponowne wykorzystanie tajemnic.

1. Oddzielne strefy zaufania: aplikacja działa z żetonami, źródła - tylko w serwisie tokenowym.

2. Gwarancja wytrzymałości kryptograficznej żetonów i zarządzanej detokenacji.

3. Zmniejszyć promień wybuchu z KMS/HSM, rotacji i sterylizacji krypto.

4. Zapewnienie przydatności do wyszukiwania/joyns/analityki w kontrolowanym ryzyku.

3) Typologia żetonów

• PII dla wyszukiwania/joynes: odwracalny deterministyczny, związany regionalnie (najemca/zakres), zamykany na KMS.
• PII do maskowania operacyjnego (UI): odwracalny nondeterministyczny z okresem życia w celu zmniejszenia ryzyka ponownego użycia.
• W przypadku analizy strefy szarej: nieodwracalne (hash klucz NMAC/sól) lub agregacje DP.

4) Architektura tokenizacji

4. 1 Składniki

Usługa tokenizacji (TS): „tokenize/detokenize/search” API, strefa wysokiego zaufania.
Token Vault (TV): mapa chroniona 'token → oryginał (+ metadane)'.
KMS/HSM: pamięć główna klucza (KEK), operacje pakowania/podpisywania.
Silnik polityki: kto, gdzie i dlaczego może detokenizować; zakres/TTL/limity stawek; mTLS/mTLS + mTLS.
Audyt i odporność: niezmienne dzienniki wszystkich operacji tokenizacji/detokenizacji.

4. 2 Kluczowa hierarchia

Korzeń/KEK w KMS/HSM (według organizacji/regionu/najemcy).
DEK-PII dla domeny danych (e-mail/telefon/adres) i/lub zbioru danych.
Obrót: rewrap DEK bez ponownego szyfrowania całego woltu; Plan „kluczowy kompromis”.

4. 3 Przepływy

1. Tokenize: TS → klient (mTLS + A&A) → normalizacja → obliczanie tokenu → pisanie do TV → odpowiedź na token.
2. Detokenize - TS → Klient → Zasady/Powód Sprawdź → Sprawdzenie źródła (lub odrzucić).
3. Wyszukiwanie/dopasowanie: tokenizacja deterministyczna pozwala na wyszukiwanie przez token; dla e-maila/telefonu - znormalizować format przed tokenizacją.

5) Wzory tokenów (projekt kryptograficzny)

5. 1 Odwracalny (zalecany do obwodu operacyjnego)

koperta AES-SIV/AEAD: „szyfr = AEAD_Encrypt (DEK, PII, AAD = zakres 'najemca' field')”; token = 'prefix' nonce 'cipher' tag '.
FPE (FF1/FF3-1) dla formatów (np. 10-cyfrowy telefon bez kodu kraju). Należy stosować ostrożnie i prawidłowo (alfabet/długość).

5. 2 Nieodwracalne (analityka/anonimizacja twarzy)

Klawisz HMAC/мич: 'token = HMAC (PII_normalized, key = K _ scope)'; sól/pieprz - oddzielne; na najemcę lub zestaw danych.
Zminimalizuj ryzyko kolizji wybierając funkcję (SHA-256/512) i domenę.

5. 3 Determinizm i zakres

Do przyłączenia użyj schematu deterministycznego z AAD = '{lokator' cel 'pole}' → różne żetony tej samej wartości odpowiadają różnym celom.
Do zwalczania korelacji w różnych usługach - różne klucze/obszary.

5. 4 Zminimalizuj ataki słownika

Normalizacja (kanonizacja e-maila/telefonu), pieprz w KMS, ograniczenie wielkości domeny (nie podawać błędów „nie znaleziono rekordu” jako kanał boczny), limit stawki i SARTSNA/proxy dla punktów publicznych.

6) projektowanie i schematy API

6. 1 REST/gRPC (opcja)

„POST/v1/tokenize {pole, wartość, zakres, tenant_id, cel} -> {token, meta}”

„POST/v1/detokenize {token, purpose} -> {value}” (mTLS + OIDC + ABAC; emisja „minimalizująca”)

'POST/v1/match {pole, value} -> {token}' (ścieżka wyszukiwania deterministycznego)

6. 2 Schemat przechowywania (TV)

Таблий 'tokens (pole, zakres, tenant_id, token, created_at, wersja, wrapped_key_id, hash_index) "

Indeksy: przez 'token', przez '(tenant_id, pole, hash_index)' dla de-dublowania/wyszukiwania.
Indeks hash (HMAC ze znormalizowanego PII) pozwala na wyszukiwanie bez detokenizacji.

6. 3 Rurociągi normalizacyjne

e-mail: lowercasing, trim, canonical local-part (bez agresywnego „jedzenia” punktów dla wszystkich domen).
telefon: E.164 (z kodem kraju), usuwanie znaków formatowania.
adres/nazwa: transliteracja według reguł, wykończenie, zawalenie przestrzeni.

7) Wielopoziomowość i izolacja

Klucze i obszary nazw na najemcę: KEK/DEK na najemcę.
Polityka detokenizacji: rola + cel + przyczyna + kontrola zdarzeń.
Crypto usunięcie danych najemcy - odwołanie KEK i DEK zniszczenie → woltów staje się bezużyteczne (dla jego rekordów).

8) Integracja

8. 1 Bazy danych i bufory

Przechowywać tylko żetony w tabelach operacyjnych.
Rzadkie przypadki wymagają detokenizacji podczas lotu przez pełnomocnika/agenta.
Token caches - tylko w pamięci z krótkim TTL, bez zapisu na dysku.

8. 2 Analityka/BI/ML

W DWH/jeziorze, żetony lub hashes. Połączenie wykonywane jest na żetonach deterministycznych odpowiedniego zakresu.
W przypadku ML preferowana jest pseudonimizacja i agregaty; unikać przywracania osób.

8. 3 Usługi wsparcia i zwalczania nadużyć finansowych

Interfejs użytkownika z maską ('+ 380') i epizodycznym detokenizacją z rozsądnego powodu (kod przyczyny) + drugi czynnik.

9) Obrót, wersje i cykl życia

Oddziel identyfikator tokena i wersję szyfrowania (v1/v2).
Wrap: zmień KEK bez dotykania danych.
Plan incydentu: kluczowy kompromis → natychmiastowe wycofanie, zakaz detokenizacji, odwrócenie do „tylko do odczytu”, uruchomienie wraku.
TTL tokeny: według zasad - stałe (identyfikatory) lub krótkie (jednorazowe linki/tymczasowe integracje).

10) Wydajność i niezawodność

Akceleracje sprzętowe (AES-NI/ARMv8), puli połączeń z KMS, pamięć podręczną owiniętych DEK.
Poziomy skalowanie ST; podzielone ścieżki odczytu/zapisu.
Idempotencja-klucz do tokenizacji powtórzeń dla flag sieciowych.
DR/HA: wielopolowa, asynchroniczna replika woltu, regularne testy odzysku.
SLO: p99 latency „tokenize” ≤ 50-100 ms; „detokenize” ≤ 50 ms; dostępność ≥ 99. 9%.

11) Obserwowalność, audyt, zgodność

Wskaźniki: QPS metodami, błędy A&A, udział detokenacji (według ról/celów), szybkość trafienia w pamięci podręcznej, czas pracy KMS.
Audyt (niezmienny): każda detokenacja z 'kto/co/dlaczego/gdzie', hash zapytania, wynik.
Zasady przechowywania i WORM dla dziennika (patrz Audyt i dzienniki niezmienne).
Zgodność: RODO (minimalizacja, prawo do usunięcia poprzez usunięcie krypto), PCI DSS (dla PAN - FPE/pseudonimizacja), raportowanie ISO/SOC.

12) Badania i bezpieczeństwo

Testy jednostek kryptograficznych: stabilność żetonów deterministycznych, weryfikacja AAD i awaria, jeśli nie pasuje.
Testy negatywne: ataki słownikowe, format odwrotny, limit szybkości, CSRF (dla paneli internetowych), SSRF dla backendów.
Chaos: KMS/Volt niedostępny, klucz spuścizny, częściowa replikacja.
Okresowy zespół Czerwony próbuje zdetokenizować bez powodu i przez kanały boczne.

13) Mini przepisy kulinarne

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) Częste błędy i sposób ich unikania

Żetony w logach. Zamaskować same żetony (szczególnie odwracalne) - są to dane wrażliwe.
Pojedynczy klucz "dla wszystkiego. "Podziel przez najemcę/pole/cel; używać AAD.
Normalizacja "przypadkowo. "Nieskoordynowana kanonizacja załamuje poszukiwania/joynes.
Detokenizacja bez przyczyny/ograniczenia. Zawsze kod uzasadnienia, audyt i limit stawki.
FPE jako panaceum. Użyj tylko wtedy, gdy format jest naprawdę potrzebny i z właściwą domeną/klawiszami.
Długotrwałe bufory na dysku. Pamięć podręczna tylko w pamięci z TTL.
Brak przeróbki. Rotacja KEK bez przestoju jest obowiązkowa.

15) Listy kontrolne

Przed sprzedażą

• Wybrane profile tokenowe na pole/cel (odwracalność/determinizm/zakres).
• Skonfigurowano kluczową hierarchię (KEK/DEK), zasady KMS, audyt kluczowych operacji.
• Normalizacja danych wejściowych, wdrożony rurociąg walidacji formatu.
• Dopuszczalna stawka, kody uzasadnienia, możliwość niezmiennego audytu.
• Przeszedł test na ataki słownikowe/format/dostęp oparty na rolach.
• DR/replika woltu i kluczowy plan kompromisowy.

Operacja

• Miesięczny raport detokenacji (kto/dlaczego/ile).
• Okresowa rotacja KEK/pieprzu, rewrap DEK.
• Czerwony zespół do nieautoryzowanego detokenacji/kanałów bocznych.
• Przegląd normalizacji w miarę powstawania nowych formatów/regionów.

16) FAQ

P: Tokenizacja = anonimizacja?
Och nie. Tokenizacja - pseudonimizacja. Źródło zostanie przywrócone (lub porównywalne), jeśli istnieją klawisze/wolt. Wyjście z sfery RODO wymaga niezawodnej anonimizacji.

P: Jak wyszukiwać przez e-mail/telefon bez detokenizacji?
Odp.: Detemined tokenization with canonization. Dla adresów/pełnych nazw - indeksy hash/klucze wyszukiwania i tabele pomocnicze.

P: Kiedy potrzebny jest FPE?
Odp.: Gdy zewnętrzna umowa/schemat wymaga formatu (długość/alfabet). W innych przypadkach regularne żetony AEAD są prostsze i bezpieczniejsze.

P: Czy możliwe jest posiadanie jednego żetonu we wszystkich celach?
Odp.: Lepsze różne zakresy (zakres/cel): ten sam PII daje różne żetony dla różnych zadań → zmniejsza ryzyko korelacji.

P: Jak korzystać z „prawa do usunięcia”?
Odp.: Deletion Crypto: cofnij KEK/DEK dla odpowiedniego zestawu i/lub usuń wpis w wolcie + zniszczyć klucze pola/strony; w analityce - TTL/agregacja/depersonalizacja.

• „Tajne zarządzanie”
• „W odpoczynku szyfrowanie”
• „W szyfrowaniu tranzytu”
• „Prywatność według projektu (RODO)”
• „Audyt i niezmienne kłody”
• „Kluczowe zarządzanie i rotacja”