PII деректерін токенизациялау

PII-деректерді токендеу

1) Токенизациялау не үшін және нені токенизациялаймыз

Мақсаты: операциялық контур пен талдауда «шикі» дербес деректерге жүгінуді болдырмау, ағу қаупін төмендету және талаптарға сәйкестікті оңайлату.
PII-мысалдар: аты-жөні, телефоны, email, мекенжайы, төлқұжаты/ID, ЖСН, IP-мекенжайлары, cookie-ID, төлем сәйкестендіргіштері, туған күні және т.б.

• бастапқы мәнін ашпайды;
• қайтарымды (детокенизацияның қорғалған сервисі арқылы) немесе қайтарымсыз болуы мүмкін;
• анықталуы (join/іздеу үшін) немесе анықталмауы (максималды құпиялылық үшін) мүмкін.

2) Қатерлер моделі және бақылау мақсаттары

Тәуекелдер: ДБ/логтардың/бэкаптардың жылыстауы, инсайдерлік оқулар, қайталанатын мәндер бойынша корреляция, рұқсатсыз детокенизация, сөздік/формат бойынша шабуылдар (email/телефон), құпияларды қайта пайдалану.

1. Сенім аймақтарын бөлісу: қолданба токендермен жұмыс істейді, бастапқы құралдар тек токен сервисінде.

2. Токендер мен басқарылатын детокенизацияның криптографиялық беріктігіне кепілдік беру.

3. KMS/HSM, ротация және «крипто-стерильдеу» көмегімен blast radius азайту.

4. Бақыланатын тәуекел кезінде іздеу/джойндар/талдау үшін жарамдылықты қамтамасыз ету.

3) Токендер типологиясы

• Іздеу/джойндарға арналған PII: кері қайтарылатын детерминирленген, (tenant/scope) аумағына байланған, KMS-те ілгегі бар.
• Жедел бүркемелеуге арналған PII (UI): қайта пайдалану қаупін төмендету үшін өмір сүру мерзімімен кері шектелмеген.
• «Сұр аймақта» талдау үшін: қайтарымсыз (негізгі НМАС/тұзбен хэш) немесе DP-агрегациялар.

4) Токенизациялау архитектурасы

4. 1 Компоненттер

Tokenization Service (TS): API «tokenize/detokenize/search», жоғары сенім аймағы.
Token Vault (TV): қорғалған мапа 'token → түпнұсқа (+ метадеректер)'.
KMS/HSM: негізгі кілттерді сақтау (KEK), орау/қолтаңба операциялары.
Policy Engine: кім, қайда және неге детокенизациялай алады; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutability: барлық токенизация/детокенизация операцияларының өзгермейтін журналдары.

4. 2 Кілттер иерархиясы

KMS/HSM Root/KEK (ұйымға/өңірге/жалға алушыға).
DEK-PII деректер доменіне (email/phone/address) және/немесе dataset.
Ротация: rewrap DEK бүкіл волтты қайта шифрлаусыз; «кілтті компрометациялау» жоспары.

4. 3 Ағындар

1. Tokenize: клиент → TS (mTLS + A&A) → қалыпқа келтіру → токенді есептеу → TV-ге жазу → токенмен жауап беру.
2. Detokenize: құқықтарымен клиент → TS → саясатты/негіздерді тексеру → бастапқы беру (немесе бас тарту).
3. Search/Match: детерминирленген токенизация токен бойынша іздеуге мүмкіндік береді; email/телефон үшін - токенизациялау алдында форматты қалыпқа келтіреміз.

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 және САРТСНА/көпшілік нүктелері үшін прокси.

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, field, hash_index)' дубликаттау/іздеу үшін.
Hash index (қалыпқа келтірілген PII-ден HMAC) детокенизациясыз іздеуге мүмкіндік береді.

6. 3 Қалыпқа келтіру конвейерлері

email: lowercasing, trim, canonical local-part (барлық домендер үшін нүктелерді агрессивті «жеусіз»).
phone: E.164 (ел коды бар), пішімдеуші таңбаларды жою.
address/name: ереже бойынша транслитерация, trim, collapse spaces.

7) Көп жалдау және оқшаулау

Жалға алушыға кілттер мен namespaces: KEK/DEK per tenant.
Детокенизация саясаты: рөлі + мақсаты + себебі + event-аудит.
Жалға алушының деректерін крипто-жою - KEK қайтарып алу және DEK → volt жою пайдасыз болады (оның жазбалары үшін).

8) Интеграция

8. 1 Дерекқорлар мен кэштер

Тек токендерді операциялық кестелерде сақтаңыз.
Сирек кездесетін кейстер үшін прокси/агент арқылы «ұшуда» детокенизациялау қажет.
Токендер кэштері - тек жадында қысқа TTL, дискіге жазылмай.

8. 2 Талдау/BI/ML

DWH/көлде - токендер немесе хэштер. Join тиісті scope детерминирленген белгілері бойынша орындалады.
ML үшін - псевдонимдеу және агрегаттар; адамдарды қалпына келтіруден аулақ болу.

8. 3 Қолдау қызметтері және антифродтар

UI маскасымен ('+ 380') және негізделген себеп бойынша эпизодтық детокенизациямен (reason code) + second factor.

9) Ротация, нұсқалар және өмірлік цикл

Токен идентификаторы мен шифрлау нұсқасын бөліңіз (v1/v2).
Rewrap: KEK-ті деректерге тиіспей өзгертеміз.
Тосын оқиғалар жоспары: кілттерді сындыру → дереу қайтарып алу, детокенизациялауға тыйым салу, «read-only» дейін қайтару, rewrap іске қосу.
TTL токендер: саясат бойынша - тұрақты (сәйкестендіргіштер) немесе қысқа (бір реттік сілтемелер/уақытша интеграциялар).

10) Өнімділік және сенімділік

Аппараттық үдеулер (AES-NI/ARMv8), KMS қосылыстар пулы, DEK ораған кэш.
TS көлденең масштабтау; read/write жолдарын бөлу.
Желілік флаптарда tokenize қайталау үшін idempotency-key.
DR/HA: көп аймақтық, вулттың асинхронды репликасы, тұрақты қалпына келтіру тестілері.
SLO: p99 латенттілігі 'tokenize' ≤ 50-100 мс; 'detokenize' ≤ 50 мс; қол жетімділік ≥ 99. 9%.

11) Бақылау, аудит, комплаенс

Өлшемдері: әдістер бойынша QPS, A&A қателері, детокенизация үлесі (рөлдер/мақсаттар бойынша), hit-rate кэш, KMS-операциялар уақыты.
Аудит (өзгермейтін): әрбір детокенизация 'who/what/why/where', хэш сұрау, нәтиже.
Журнал үшін сақтау және WORM саясаты («Аудит және өзгермейтін журналдарды» қараңыз).
Сәйкестік: GDPR (барынша азайту, крипто-өшіру арқылы жою құқығы), PCI DSS (PAN үшін - FPE/псевдонимдеу), ISO/SOC есептілігі.

12) Тестілеу және қауіпсіздік

Крипто-юнит-тесттер: детерминирленген токендердің тұрақтылығы, AAD тексеру және ол сәйкес келмеген кезде бас тарту.
Теріс тесттер: сөздік шабуылдары, формат бойынша реверс, rate-limit, CSRF (веб-панельдер үшін), SSRF бекендтерге.
Chaos: KMS/volt қол жетімді емес, ескірген кілт, ішінара репликалау.
Мерзімді Red-team негізсіз және бүйірлік арналар бойынша детокенизациялау әрекеттері.

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, аудит және rate-limit.
FPE панацея ретінде. Пішім қажет болғанда және дұрыс доменмен/кілттермен қолдану.
Дискідегі ұзақ мерзімді кэштер. Тек TTL жадындағы кэш.
rewrap процесінің болмауы. КЕК-ті тоқтаусыз ротациялау міндетті.

15) Чек парақтары

Азық-түлік алдында

• Таңдалған per өрісі/мақсаты (қайтарымдылық/детерминизм/аумақ).
• Кілттердің иерархиясы (KEK/DEK), KMS саясаты, негізгі операциялардың аудиті теңшелді.
• Кірістерді қалыпқа келтіру, форматтарды валидациялау конвейері іске асырылды.
• rate-limit, reason-codes, өзгермейтін аудит енгізілген.
• Сөздік шабуылдарына/пішіміне/рөлге негізделген қолжетімділікке арналған тестілер өтті.
• DR/волт репликасы және кілттерді сындыру жоспары.

Пайдалану

• Детокенизация бойынша ай сайынғы есеп (кім/неге/қанша).
• KEK/pepper, rewrap DEK мерзімді ротациясы.
• Рұқсат етілмеген детокенизацияға/бүйірлік арналарға Red-team.
• Жаңа пішімдер/өңірлер пайда болған кезде қалыпқа келтіруді қайта қарау.

16) FAQ

С: Токенизация = анонимдеу?
О жоқ. Токенизация - бүркеншік атау. Бастапқы кілт/волт болған жағдайда қалпына келтіреміз (немесе салыстырамыз). GDPR аясынан шығу үшін сенімді анонимдеу қажет.

С: Детокенизациясыз электрондық пошта/телефон арқылы қалай іздеуге болады?
О: Канонизациямен детеминирленген токенизация. Мекенжайлар/ТАӘ үшін - хэш-индекстер/іздеу кілттері және қосалқы кестелер.

С: FPE қашан қажет?
О: Сыртқы келісімшарт/схема форматты талап еткенде (ұзындығы/әліпби). Басқа жағдайларда - әдеттегі AEAD-токендер оңай және қауіпсіз.

В: Барлық мақсаттар үшін бір токен болуы мүмкін бе?
О: Жақсы әртүрлі аймақтар (scope/purpose): бір PII түрлі тапсырмалар үшін әртүрлі белгілерді береді → корреляция қаупін азайтады.

С: «Жою құқығын» қалай орындау керек?
О: Крипто-жою: тиісті теру үшін KEK/DEK қайтарып аламыз және/немесе жазуды өшіреміз + өріс/партия кілттерін жоямыз; талдауда - TTL/агрегаттау/иесіздендіру.

• «Құпия менеджменті»
• «At Rest шифрлау»
• «In Transit шифрлау»
• «Privacy by Design (GDPR)»
• «Аудит және өзгермейтін журналдар»
• «Кілттерді басқару және ротация»