نشانه گذاری داده های PII

نشانه گذاری داده های PII

1) چرا tokenization و دقیقا چه چیزی ما tokenize

هدف: حذف دسترسی به داده های شخصی «خام» در مدار عملیاتی و تجزیه و تحلیل، کاهش خطر نشت و ساده سازی انطباق با الزامات.

PII نمونه: نام و نام خانوادگی، شماره تلفن، ایمیل، آدرس، گذرنامه/ID، TIN، آدرس IP، کوکی ID، شناسه پرداخت، تاریخ تولد، و غیره

• ارزش اصلی را فاش نمی کند ؛
• می تواند برگشت پذیر (از طریق یک سرویس detokenation امن) و یا غیر قابل برگشت.
• میتواند قطعی (برای پیوستن/جستجو) یا غیر قطعی (برای حداکثر حریم خصوصی) باشد.

2) مدل تهدید و اهداف کنترل

خطرات: نشت پایگاه داده/ورود/پشتیبان گیری، خواندن خودی، همبستگی با تکرار مقادیر، detokenization غیر مجاز، حملات فرهنگ لغت/فرمت (ایمیل/تلفن)، استفاده مجدد از اسرار.

1. مناطق اعتماد جداگانه: برنامه با نشانه ها، منابع - فقط در سرویس نشانه کار می کند.

2. تضمین قدرت رمزنگاری از نشانه ها و detokenation مدیریت می شود.

3. کاهش شعاع انفجار با KMS/HSM، چرخش و عقیم سازی رمزنگاری.

4. اطمینان از مناسب بودن برای جستجو/شادی/تجزیه و تحلیل در معرض خطر کنترل شده.

3) نوع شناسی نشانه ها

• PII برای جستجو/شادی: قطعی برگشت پذیر، محدود به منطقه (مستاجر/دامنه)، قفل شده در KMS.
• PII برای پوشش عملیاتی (UI): غیر قابل برگشت با طول عمر برای کاهش خطرات استفاده مجدد.
• برای تجزیه و تحلیل منطقه خاکستری: غیر قابل برگشت (کلید NMAC/هش نمک) و یا تجمع DP.

4) معماری نشانه گذاری

4. 1 قطعات

Tokenization Service (TS): «tokenize/detokenize/search» API، منطقه اعتماد بالا.
Token Vault (TV): نقشه محافظت شده 'token → original (+ metadata)'.
KMS/HSM: ذخیره سازی کلید ریشه (KEK)، عملیات بسته بندی/امضای.
موتور سیاست: چه کسی، کجا و چرا می تواند detokenize ؛ محدوده/TTL/محدودیت نرخ ؛ mTLS/mTLS + mTLS.
حسابرسی و ایمنی: سیاهههای مربوط غیر قابل تغییر از تمام عملیات نشانه گذاری/detokenization.

4. 2 سلسله مراتب کلیدی

ریشه/KEK در KMS/HSM (در هر سازمان/منطقه/مستاجر).
DEK-PII در هر دامنه داده (ایمیل/تلفن/آدرس) و/یا مجموعه داده.

چرخش: بازسازی DEK بدون رمزگذاری مجدد کل ولت ؛ طرح «توافق کلیدی»

4. 3 جریان دارد

1. Tokenize: TS → client (mTLS + A&A) → normalization → token calculation → writing to TV → token response.
2. Detokenize - TS → مشتری → بررسی سیاست/دلیل → بررسی منبع (یا رد).
3. جستجو/مطابقت: نشانه گذاری قطعی اجازه می دهد تا شما را به جستجو توسط نشانه ؛ برای ایمیل/تلفن - قبل از نشانه گذاری فرمت را عادی کنید.

5) طرح های Token (طراحی رمزنگاری)

5. 1 برگشت پذیر (توصیه می شود برای مدار عملیاتی)

پاکت AES-SIV/AEAD: 'رمز = AEAD_Encrypt (DEK، PII، AAD = دامنه' tenant 'field)' ؛ token = 'پیشوند' nonce 'cipher' tag '.
FPE (FF1/FF3-1) برای فرمت های (به عنوان مثال،. تلفن 10 رقمی بدون کد کشور). با احتیاط و دامنه صحیح (الفبا/طول) اعمال کنید.

5. 2 غیر قابل برگشت (تجزیه و تحلیل/ناشناس چهره)

کلید HMAC/хэш: 'token = HMAC (PII_normalized, key = K _ scope)'; نمک/فلفل - جداگانه ؛ در هر مستاجر یا مجموعه داده.
به حداقل رساندن خطر برخورد با انتخاب یک تابع (SHA-256/512) و یک دامنه.

5. 3 جبرگرایی و محدوده

برای پیوستن، استفاده از یک طرح قطعی با AAD = '{مستاجر' هدف 'درست} → نشانه های مختلف از همان مقدار مربوط به اهداف مختلف است.
برای ضد همبستگی در خدمات مختلف - کلید های مختلف/مناطق.

5. 4 به حداقل رساندن حملات فرهنگ لغت

عادی سازی (کانونیزه کردن ایمیل/تلفن)، فلفل در KMS، محدودیت اندازه دامنه (خطاهای «بدون رکورد یافت شده» را به عنوان یک کانال جانبی ندهید)، محدودیت نرخ و SARTSNA/پروکسی برای نقاط عمومی.

6) طراحی و نقشه های API

6. 1 REST/gRPC (گزینه)

'POST/v1/tokenize {فیلد، ارزش، دامنه، tenant_id، هدف} -> {نشانه، متا}'

'POST/v1/detokenize {token, purpose} -> {value}' (mTLS + OIDC + ABAC; «به حداقل رساندن» صدور)

'POST/v1/match {field, value} -> {token}' (مسیر جستجوی قطعی)

6. 2 نمودار ذخیره سازی (تلویزیون)

'tokens (field, scope, , token, , version)'

شاخص ها: توسط «نشانه»، توسط «(tenant_id، زمینه، hash_index)» برای تکثیر/جستجو.
Hash index (HMAC از PII نرمال شده) به شما امکان می دهد بدون detokenization جستجو کنید.

6. 3 خطوط لوله عادی

ایمیل: کوچک، تر و تمیز، متعارف محلی بخش (بدون تهاجمی «خوردن» از نقاط برای تمام دامنه).
تلفن: E.164 (با کد کشور)، حذف شخصیت های قالب بندی.
آدرس/نام: ترجمه توسط قوانین، تر و تمیز، فضاهای فروپاشی.

7) چند اجاره و انزوا

کلیدها و فضاهای نام برای هر مستاجر: KEK/DEK برای هر مستاجر.
سیاست های Detokenization: نقش + هدف + علت + حسابرسی رویداد.
حذف رمزنگاری داده مستاجر - ابطال KEK و تخریب DEK → ولت بی فایده می شود (برای سوابق آن).

8) ادغام

8. 1 پایگاه داده ها و انبارها

فقط نشانه ها را در جداول عملیاتی ذخیره کنید.
موارد نادر نیاز به detokenization در پرواز از طریق یک پروکسی/عامل.
حافظه های پنهان توکن - فقط در حافظه با TTL کوتاه، بدون نوشتن روی دیسک.

8. 2 تجزیه و تحلیل ترافیک/BI/ML

در DWH/دریاچه، نشانه ها یا هش ها. Join بر روی توکنهای قطعی حوزه مربوطه انجام میشود.

برای ML، pseudonymization و aggregates ترجیح داده می شود ؛ اجتناب از بازگرداندن افراد

8. 3 خدمات پشتیبانی و ضد تقلب

UI با ماسک («+ 380») و detokenization اپیزودیک برای یک دلیل منطقی (کد دلیل) + عامل دوم.

9) چرخش، نسخه ها و چرخه عمر

جدا کردن شناسه نشانه و نسخه رمزگذاری (v1/v2).
Rewrap: تغییر KEK بدون دست زدن به داده ها.
طرح حادثه: سازش کلیدی → یادآوری فوری، ممنوعیت detokenization، بازگشت به «فقط خواندنی»، راه اندازی مجدد.
نشانه TTL: توسط سیاست - دائمی (شناسه) و یا کوتاه (یک بار لینک/ادغام موقت).

10) عملکرد و قابلیت اطمینان

شتاب سخت افزاری (AES-NI/ARMv8)، استخر از اتصالات به KMS، کش از DEKs پیچیده شده است.
مقیاس افقی TS ؛ تقسیم مسیرهای خواندن/نوشتن.
Idempotency-کلید برای تکرار tokenize برای پرچم های شبکه.
DR/HA: multi-area, asynchronous volt replica, تستهای بازیابی منظم.
SLO: تاخیر p99 'tokenize' ≤ 50-100 میلی ثانیه ؛ 'detokenize' ≤ 50 خانم ؛ دسترسی ≥ 99 9%.

11) مشاهده، حسابرسی، انطباق

معیارها: QPS توسط روش ها، خطاهای A&A، سهم detokenations (توسط نقش ها/اهداف)، نرخ ضربه کش، زمان عملیات KMS.
حسابرسی (تغییر ناپذیر): هر detokenation با «چه کسی/چه/چرا/کجا»، هش پرس و جو، نتیجه.
نگهداری و سیاست های WORM برای ورود به سیستم (نگاه کنید به Auditing و Immutable Logs).
انطباق: GDPR (به حداقل رساندن، حق حذف از طریق پاک کردن رمزنگاری)، PCI DSS (برای PAN - FPE/pseudonymization)، گزارش ISO/SOC.

12) تست و ایمنی

تست واحد رمزنگاری: ثبات توکن های قطعی، تأیید AAD و شکست در صورت عدم مطابقت.
تست های منفی: حملات فرهنگ لغت، معکوس فرمت، محدود کردن نرخ، CSRF (برای پانل های وب)، SSRF برای backends.
هرج و مرج: 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

عادی سازی "به صورت تصادفی. "Canonization هماهنگ نشده جستجو/joynes را تجزیه می کند.
Detokenization بدون علت/محدودیت. همیشه کد، حسابرسی و محدودیت نرخ را در نظر بگیرید.
FPE به عنوان یک نوش دارو فقط زمانی که فرمت واقعا مورد نیاز است و با دامنه/کلید درست استفاده کنید.
کش های طولانی مدت بر روی دیسک حافظه پنهان فقط در حافظه با TTL.
بدون فرآیند بازخوانی. چرخش KEK بدون خرابی اجباری است.

15) چک لیست

قبل از فروش

• پروفایل های نشانه انتخاب شده در هر زمینه/هدف (برگشت پذیری/تعیین/دامنه).
• سلسله مراتب کلیدی (KEK/DEK)، سیاست های KMS، حسابرسی عملیات کلیدی پیکربندی شده است.
• عادی سازی ورودی، خط لوله اعتبار سنجی فرمت اجرا شده است.
• محدودیت نرخ، کدهای دلیل، حسابرسی تغییر ناپذیر فعال شده است.
• تست برای حملات فرهنگ لغت/فرمت/دسترسی مبتنی بر نقش گذشت.
• DR/ماکت ولت و طرح سازش کلیدی.

عملیات

• گزارش ماهانه detokenation (چه کسی/چرا/چقدر).
• چرخش دوره ای KEK/فلفل، بازسازی DEK.
• قرمز تیم برای کانال های غیر مجاز detokenation/سمت.
• با ظهور فرمت ها/مناطق جدید، عادی سازی را اصلاح کنید.

16) سوالات متداول

س: نشانه گذاری = ناشناس ؟

اوه نه. نشانه گذاری - pseudonymization. منبع خواهد شد ترمیم (یا قابل مقایسه) اگر کلید/ولت وجود دارد. برای خروج از حوزه GDPR نیاز به ناشناس قابل اعتماد است.

س: چگونه می توان از طریق ایمیل/تلفن بدون detokenization جستجو کرد ؟

A: نشانه گذاری Deteminated با canonization. برای آدرس ها/نام های کامل - شاخص های هش/کلید های جستجو و جداول کمکی.

س: چه زمانی FPE مورد نیاز است ؟

A: هنگامی که یک قرارداد/طرح خارجی نیاز به فرمت (طول/حروف الفبا). در موارد دیگر، توکن های معمولی AEAD ساده تر و ایمن تر هستند.

س: آیا می توان یک نشانه برای همه اهداف داشت ؟

A: دامنه های مختلف بهتر (دامنه/هدف): همان PII می دهد نشانه های مختلف برای وظایف مختلف → خطر همبستگی را کاهش می دهد.

س: چگونه از «حق حذف» استفاده می کنید ؟

A: حذف رمزنگاری: KEK/DEK را برای مجموعه مربوطه لغو کنید و/یا ورودی را در ولت حذف کنید + کلید های زمینه/حزب را از بین ببرید ؛ در تجزیه و تحلیل - TTL/تجمع/depersonalization.

• «مدیریت مخفی»
• «رمزگذاری در حالت استراحت»
• «در رمزگذاری حمل و نقل»
• حریم خصوصی از طریق طراحی (GDPR)
• «گزارش های حسابرسی و تغییر ناپذیر»
• «مدیریت کلید و چرخش»