טוקניזציה של נתוני PII

Tokenization of PII data

1) מדוע אסימונים ומה בדיוק אנחנו קובעים

המטרה: לשלול גישה למידע אישי ”גולמי” במעגל התפעולי ובאנליטיקה, להפחית את הסיכון לדליפות ולפשט את הציות לדרישות.
דוגמאות: שם מלא, מספר טלפון, דוא "ל, כתובת, דרכון/תעודת זהות, כתובות IP, זיהוי עוגיות, זיהוי תשלומים, תאריך לידה וכו '.

• אינו חושף את הערך המקורי;
• יכול להיות הפיך (באמצעות שירות ניקוי מאובטח) או בלתי הפיך;
• יכול להיות דטרמיניסטי (להצטרפות/חיפוש) או לא דטרמיניסטי (לפרטיות מקסימלית).

2) מודל איום ושליטה על מטרות

סיכונים: מסד נתונים/רישום/דליפות גיבוי, קריאות מידע פנים, מתאם על ידי חזרה על ערכים, דטוקניזציה לא מורשית, התקפות מילון/פורמט (דוא "ל/טלפון), שימוש חוזר בסודות.

1. אזורי אמון נפרדים: היישום עובד עם אסימונים, המקורות - רק בשירות הסמלים.

2. הבטחת חוזק קריפטוגרפי של אסימונים וניהול גירוי.

3. הפחת את רדיוס הפיצוץ בעזרת KMS/HSM, סיבוב וחיטוי קריפטו.

4. ודא התאמה לחיפוש/שמחות/אנליטיקה בסיכון מבוקר.

3) טיפולוגיה של אסימונים

• PII לחיפוש/joynes: דטרמיניסטי הפיך, אזור כבול (דייר/היקף), נצמד לק "מ.
• PII למיסוך מבצעי (UI): אי-נוחות הפיכה עם חיים שלמים כדי להפחית סיכונים לשימוש חוזר.
• עבור ניתוח אזור אפור: בלתי הפיך (מפתח NMAC/מלח hash) או התקבצות DP.

4) ארכיטקטורת טוקניזציה

4. 1 רכיבים

שירות Tokenization (TS): ”tokenization/detokenize/search” API, אזור אמון גבוה.
כספת טוקן (Token Vault): מפה מוגנת 'token' acu מקורית (+ metadata).
KMS/HSM: אחסון מקש שורש (KEK), פעולות עטיפה/חתימה.
מנוע מדיניות: מי, איפה ולמה יכול לסלק; היקף/TTL/rate-limits; MTLS/mTLS + mTLS.
ביקורת וחסינות: יומנים בלתי ניתנים לשינוי של כל פעולות ה-tokenization/detokenization.

4. 2 היררכיית מפתח

Root/KEK ב- KMS/HSM (לכל ארגון/אזור/דייר).
DEK-PII לכל תחום נתונים (דוא "ל/טלפון/כתובת) ו/או נתונים.
סיבוב: חזור לאחור של DEK מבלי להצפין מחדש את כל הוולט; תוכנית ”פשרה מרכזית”.

4. 3 זרימות

1. TS = לקוח (MTLS + A&A) = נורמליזציה של חישוב אסימונים.
2. Detokenize - TS # Cliant # Policy/Reason Check # Source Check (או נדחה).
3. חיפוש/התאמה: סימון דטרמיניסטי מאפשר לך לחפש על ידי אסימון; למייל/טלפון - לנרמל את הפורמט לפני טוקניזציה.

5) עיצובי טוקן (עיצוב קריפטו)

5. 1 הפיך (מומלץ למעגל תפעולי)

מעטפת AES-SIV/AEAD: ”צופן = AEAD_Encrypt (DEK, PII, AAD = היקף 'terenant' field')”; אסימון = ”prefix 'nonce' צופן 'tag”.
(FPE (FF1/FF3-1 לפורמטים (למשל. טלפון 10 ספרות ללא קוד מדינה). הפעל בזהירות ובתחום הנכון (אלפבית/אורך).

5. 2 בלתי הפיך (אנליטיקה/אנונימיות פנים)

Keid HMAC/oscape: ”token = HMAC (PII_normalized, מפתח = K _ scope)”; מלח/פלפל - נפרד; לכל דייר או דייט.
מזעור הסיכון של התנגשויות על ידי בחירת פונקציה (SHA-256/512) ותחום.

5. 3 דטרמיניזם והיקף

עבור הצטרפות, השתמש בתרשים דטרמיניסטי עם AAD = ”[דייר 'מטרה' שדה]” = אסימונים שונים באותו ערך המותאמים למטרות שונות.
לאנטי-קורלציה בשירותים שונים - מפתחות/אזורים שונים.

5. 4 למזער התקפות מילון

נורמליזציה (קנוניזציה של דוא "ל/טלפון), פלפל ב-KMS, הגבלת גודל דומיין (לא לתת שגיאות" לא נמצא תיעוד "כערוץ צדדי), הגבלת קצב ו-SARTSNA/proxy עבור נקודות ציבוריות.

6) עיצוב API ושרטוטים

6. 1 מנוחה/gRPC (אפשרות)

'POST/v1/occenize' שדה, ערך, היקף, tenant_id, מטרה '->

(POST/V1/detokenize [token, trogt-> [ערך] (mTLS + OIDC + ABAC; ”מזעור” הוצאה)

'POST/V1/matchfield, value,> token' (נתיב חיפוש דטרמיניסטי)

6. דיאגרמת אחסון 2 (טלוויזיה)

אסימונים (שדה, היקף, , , גרסה, ) "

אינדקסים: על ידי 'token', על ידי '(tenant_id, שדה, hash_index)' עבור דה-כפילות/חיפוש.
אינדקס HASH (HMAC מ-PII מנורמל) מאפשר לך לחפש ללא איתור.

6. 3 צינורות נורמליזציה

דוא "ל: לקצץ, לקצץ, חלק מקומי קנוני (ללא" אכילה "תוקפנית של נקודות לכל התחומים).
טלפון: E.164 (עם קוד מדינה), הסרת דמויות.
כתובת/שם: תרגום לפי כללים, קיצוץ, חללי קריסה.

7) עמידות ובידוד

מפתחות וחפצי שם לכל דייר: KEK/DEK לכל דייר.
מדיניות detokenization: תפקיד + מטרה + סיבה + ביקורת אירועים.
מחיקת קריפטו של נתוני דייר - ביטול KEK והרס DEK * וולט הופכת לחסרת תועלת (עבור הרשומות שלה).

8) אינטגרציות

8. 1 מסדי נתונים ומטמונים

לאחסן אסימונים רק בשולחנות ניתוח.
מקרים נדירים דורשים היווצרות בטוס באמצעות פרוקסי/סוכן.
מטמונים - רק לזכר עם TTL קצר, ללא כתיבה לדיסק.

8. 2 אנליטיקה/BI/ML

ב DWH/Lake, אסימונים או חשיש. הצטרפות מתבצעת על אסימונים דטרמיניסטיים של היקף מתאים.
עבור ML, פסאודונימיזציה ואגרגטים מועדפים; הימנע משיקום אנשים.

8. 3 שירותי תמיכה ואנטי הונאה

UI עם מסכה ('+ 380') ודיאטוקניזציה אפיזודית מסיבה סבירה (קוד סיבה) + גורם שני.

9) סיבוב, גרסאות ואופן חיים

הפרד את גירסת הזיהוי וההצפנה (v1/v2).
חזור אחורה: שנה את KEK מבלי לגעת בנתונים.
תכנית תקרית: פשרה מרכזית = החזרה מיידית, איסור על איתור, רישום ל ”קריאה בלבד”, שיגור חוזר.
TTL tokens: על ידי מדיניות - קבועים (מזהים) או קצרים (קישורים חד-פעמיים/אינטגרציות זמניות).

10) ביצועים ואמינות

תאוצות חומרה (AES-NI/ARMv8), בריכות של חיבורים ל-KMS, מטמון של DEKs עטוף.
סולם אופקי TS; לפצל נתיבי קריאה/כתיבה.
מפתח Idempotency עבור אסימון חזרות עבור דגלי רשת.
ד "ר/הא: רב-שטח, העתק אסינכרוני וולט, בדיקות התאוששות רגילות.
SLO: p99 latency 'occenize' lood 50-100 ms; 'detokenize' all 50 ms; זמינות 99. 9%.

11) יכולת תצפית, ביקורת, ציות

Metrics: QPS על ידי שיטות, A&A שגיאות, נתח של detokenations (על ידי תפקידים/מטרות), cache hit-rate, KMS operation time.
ביקורת (immutable): כל גילוי עם 'מי/מה/למה/איפה', שאילתה חשיש, תוצאה.
מדיניות שימור ו-WORM עבור הרישום (ראו: Auditing ו-Immutable Logs).
ציות: GDPR (מזעור, זכות למחוק באמצעות מחיקת קריפטו), PCI DSS (עבור PAN - FPE/pseudonimization), ISO/SOC.

12) בדיקות ובטיחות

מבחני יחידת ההצפנה: יציבות אסימונים דטרמיניסטיים, אימות AAD וכישלון אם אינו תואם.
מבחנים שליליים: התקפות מילון, היפוך פורמט, הגבלת קצב, CSRF (ללוחות רשת), SSRF לקצוות אחוריים.
כאוס: KMS/Volt לא זמין, מפתח מורשת, שכפול חלקי.
צוות אדום תקופתי מנסה להתנתק ללא סיבה ובאמצעות תעלות צדדיות.

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) טעויות תכופות וכיצד להימנע מהן

אסימונים ביומנים. מסווה האסימונים עצמם (במיוחד אלה הפיכים) - אלה נתונים רגישים.
מפתח אחד "לכל דבר. "לחלק בדייר/שדה/מטרה; השתמש באיי-אד.
נורמליזציה "באקראי. "קנוניזציה לא מתואמת מפרק את החיפוש/joynes.
ניקוי ללא סיבה/הגבלה. תמיד קוד ההיגיון, ביקורת חשבונות והגבלת קצב.
FPE כמו פנסיאה. השתמש רק כאשר הפורמט באמת נחוץ ועם התחום/מפתחות הנכונים.
מטמונים ארוכי חיים על דיסק. מטמון רק בזיכרון עם TTL.
אין תהליך רישום חוזר. סיבוב של KEK ללא השבתה הוא חובה.

15) רשימות בדיקה

לפני המכירה

[ ] פרופילי אסימון נבחרים לשדה/מטרה (reversity/determinism/scope).

[ ] היררכיית מפתח (KEK/DEK), מדיניות KMS, פעולות מפתח ביקורת מוגדרות.

[ נורמליזציה ] הכנסת, צינור אימות פורמט מיושם.

[ ] מגבלת קצב, סיבת קודים, ביקורת בלתי ניתנת לשינוי מופעלת.

[ ] מבחנים להתקפות מילון/פורמט/גישה מבוססת תפקידים עברו.

[ ] ד "ר/העתק וולט ותוכנית פשרה מרכזית.

מבצע

[ ] דו "ח ניקיון חודשי (מי/למה/כמה).

[ סיבוב תקופתי ] של KEK/pper, ריפ מחדש DEK.

[ ] צוות אדום לערוצי איתור/צד לא מורשים.

[ ] Revise נורמליזציה כאשר פורמטים/אזורים חדשים צצים.

16) FAQ

Q: טוקניזציה = אנוניזציה?
אה לא אסימון - פסאודונימיזציה. המקור ישוחזר (או ניתן להשוואה) אם יש מפתחות/וולט. כדי לצאת מהמרחב של GDPR דרושה אנונימיות אמינה.

Q: כיצד ניתן לחפש בדוא "ל/טלפון ללא חיטוי?
אסימון מנותק עם קנוניזציה. עבור כתובות/שמות מלאים - אינדקסים חשיש/מפתחות חיפוש וטבלאות עזר.

ש: מתי יש צורך ב-FPE?
A: כאשר חוזה/סכימה חיצונית דורשת פורמט (אורך/אלפבית). במקרים אחרים, אסימונים רגילים של AEAD פשוטים ובטוחים יותר.

קיו: האם אפשר לקבל אסימון אחד לכל דבר ועניין? ‏

A: סקופים שונים טובים יותר (היקף/מטרה): אותו PII נותן אסימונים שונים עבור משימות שונות _ מפחית את הסיכון של קורלציה.

ש: כיצד אתה מפעיל את ”הזכות להסיר”? ‏

A: למחוק קריפטו: לבטל את KEK/DEK עבור הקבוצה המתאימה ו/או למחוק את הכניסה בוולט + להרוס את מפתחות השדה/צד; באנליטיקה - TTL/צבירה/דפרסונליזציה.

• ‏ ”ניהול סודי” ‏
• ”בהצפנת מנוחה”
• ”בהצפנת מעבר”
• ”פרטיות בעיצוב (GDPR)”
• ”ביקורת ויומנים בלתי ניתנים לשינוי”
• ”ניהול מפתח וסבב”