פרטיות באמצעות עיצוב: עקרונות עיצוב
1) מדוע היא נחוצה (מטרה ואזור)
PBD מבטיח כי הפרטיות מובנית לתוך המוצר כברירת מחדל, לא ”מודבקת” למעלה. עבור iGaming, היא מפחיתה סיכונים רגולטוריים (GDPR/ePrivacy/local laws), מגנה על משתמשים פגיעים, מגבירה את האמון ומפחיתה את עלויות התקריות. סיקור: web/mobile, KYC/AML/RG, תשלומים, שיווק/CRM, אנליטיקה/DWH, יומנים/AWP, שותפים/ספקים.
2) שבעה עקרונות (וכיצד להנחית אותם במבצעים)
1. פרואקטיביות, אי-ריאקטיביות
מודל איום (LINDUN/STRIDE) בשלב הגילוי.
קריטריונים של קבלת פרטיות בתבנית ג 'ירה/יחסי ציבור.
2. פרטיות כברירת מחדל
כל מתגי שיווק/התאמה אישית כבויים עד שאין הסכם.
לאסוף רק מזהים ברירת מחדל ”הכרחיים”.
3. הפרטיות מובנית בתכנון
PII מאוחסן במעגל האזורי (תושבות נתונים), מטוס בקרה - ללא מח "ש.
טוקניזציה/ניכור של מפתחות באירועי שירות.
4. פונקציונליות מלאה (win-win)
מצבים של ”אנליטיקה אנונימית” ו ”התאמה אישית בהסכמה”.
שווה UX ללא אפליה של אלה שסירבו מעקב.
5. אבטחה דרך אופני החיים
הצפנה במנוחה/במעבר; BYOK/HYOK; קטעי רשת; ניהול סודי.
יומני תולעת לראיות וביקורת.
6. שקיפות
מדיניות קצרה ו ”תיבת סיכום” של תנאי מפתח; פנל פרטיות בפרופיל.
דיווח: מי/מה/מתי/מדוע ניגש לנתונים.
7. אוריינטציית משתמש
טקסטים פשוטים, חוסר בדפוסים אפלים, זמינות של WCAG AA +.
נסיגה קלה של הסכמה וערוצי DSAR נוחים.
3) תפקידים ו ־ RACI
DPO/ראש הציות מדיניות PBD, DPIA/TRA, בקרת סיכון. (א)
אבטחה/עופרת אינפרה - קריפטוגרפיה, גישה, יומנים, ספקים. (R)
מוצר/UX - דרישות פרטיות בתכונות, היעדר דפוסים אפלים. (R)
הנדסה/ארכיטקטורה - אסימון, בידוד דייר/אזור, חוזי API. (R)
נתונים/אנליטיקה - צינורות דה-פיי, PETS, צבירה. (R)
עילה חוקית, טקסטים ומקומות. (C)
שיווק/CRM - הסכמה/דיכוי, תקשורת כנה. (R)
ביקורת פנימית - דגימות חפץ, CAPA. (C)
4) סיווג וטקסונומיה של נתונים
שם מלא, דואר אלקטרוני, טלפון, כתובת, תאריך לידה, IP/ID של המכשיר.
PII רגיש: ביומטריה (סלפי/פרנסה), מסמכי KYC, פרטי תשלום, סטטוסים של RG/SE.
חדרי ניתוח: אירועי משחק, רישומים/שבילים (PII-ללא ברירת מחדל).
שיווק/אנליטיקה: עוגיות/SDKs (בהסכמה).
חוקים: מזעור, אחסון נפרד, מטרה מפורשת וחיי מדף.
5) אופן חיים של נתונים
1. אוסף - רק שדות נדרשים; CIW/הסכמה; בדיקות גיל.
2. שידור - TLS 1. 2 +/mTLS, חתימת webhook, ניתוב אזורי.
3. אחסון - הצפנה, אסימון, סיבוב מפתח, בידוד שוק.
4. שימוש - RBAC/ABAC, צריך לדעת, PETS לאנליטיקה.
5. החלפה - DPA/SCC, מינימום סטים, ערוצים מבוקרים.
6. שימור/הסרה - מונח לפי קטגוריה; קסקייד למחוק עבודות קריפטו למחוק ארכיונים.
7. דיווח/ביקורת - רישומי גישה ויצוא, פריטי DPIA/DSAR.
6) DPIA/TRA (איך לעשות את זה בקצרה)
טריגרים: קטגוריות PII חדשות, קטגוריות מיוחדות, ספקים חדשים, שידורים חוצי גבולות, סיכוני RG/ביומטריה גבוהים.
תבנית DPIA: תכלית * קטגוריה של נתונים * בסיס חוקי * זורם/מפה * סיכונים * צעדים (tech/org) * החלטה בסיכון שיורי.
חפצים: תרשים זרימה, רשימת שטח, טבלת סיכונים, פרוטוקול אישור.
7) דפוסים ארכיטקטוניים של PBD
דייר/איזור בידוד: הפרדה פיזית/לוגית של מסדי נתונים, מפתחות וסודות.
בקרה נגד מישור הנתונים: שליטה גלובלית - לא מח "ש; מח "ש רק באופן מקומי.
צינור דה-פיי: לפני הייצוא ל-DWH - חשיש/מלח, טראונקציה, k-אנונימיות/קוהורטציה.
אסימונים במקום מזהים ראשוניים באוטובוס השירות.
קצה ללא PII: CDN/Edge cache - תוכן ציבורי בלבד.
אל-כשל: לא ידוע 'player _ region' = פעולות PII אינן מורשות.
8) אמצעים טכניים וסטנדרטים
הצפנה: AES-256/GCM במנוחה; TLS 1. 2+/1. 3; PFS.
מפתחות: KMS, BYOK/HYOK, סיבוב, גישה על ידי תפקידי HSM, רישום של פעולות מפתח.
גישה: RBAC/ABAC, גישות JIT, תפקידי ניהול וביקורת נפרדים.
יומנים: בלתי ניתנים לשינוי (תולעת), שרשראות חשיש, אחסון באזור.
סודות בכספת, SAST/DAST, ספינטר שטח PII, בדיקות פרטיות במצ "ח.
נתוני מבחן: ברירת מחדל סינתטית; אם המידע מחדש הוא דה-זיהוי ושימור קצר.
9) PETS (פרטיות-שיפור טכנולוגיות)
חייזרים: החלפת תעודת זהות באסימונים; מפת מפתחות מאוחסנת בנפרד.
אנונימיות: אגרגטים, k- anonimnost/expost - מגוון, בכפפות/קוהורטות.
פרטיות דיפרנציאלית: רעש על דוחות, ”תקציב פרטיות”.
מודלים מקומיים, יצוא משקולות/אגרגטים בלבד.
מיסוך/עריכה: למחוק את EXIF, לטחון שדות במסמכי KYC.
10) UX ללא תבניות אפלות
ראות שווה ”לדחות את הכל ”/” לקבל את הכל ”/” להתאים אישית ”.
נקה טקסטים ודוגמאות לשימוש בנתונים.
אי התאמה אישית אינה פוגעת בחוויה הבסיסית.
לוח פרטיות ב1-2 קליקים מכל מקום; זמינות של אלכוהוליסטים אנונימיים.
11) ספקים והעברת נתונים
רישום ספקים: DC, תת-מעבדים, אישור, אזורי אחסון, DPA/SCC/IDTA.
מדיניות ”מינימום מוגדר”: רק שדות נדרשים, לא יצוא חופשי.
הודעה ושינויים בעת שינוי מיקומים/תת-מעבדים.
12) נתונים ואירועים (מודל מינימלי)
data_asset{id, category{KYC PCI RG CRM LOG ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}
13) KPI/KRI ו ־ PBD לוח מחוונים
אינדקס מזעור PII (מספר ממוצע של שדות PII לכל תכונה).
כיסוי תושבות (% מהרשומות באזור הנכון).
שיעור ההצדקה לייצוא.
DSAR SLA (ביצועים/דיוק חציוניים).
תג הפרות ירי.
ציון שמיעה (% מהמקרים עם חבילת חפצים מלאה).
תקריות/ממצאים.
14) רשימות בדיקה
א. לפני העיצוב
[ ] המטרות והעילה המשפטית של העיבוד מוגדרות.
[ ] מפת נתונים ורשימת שטח מסומנים PII/רגיש.
[ ] DPIA/TRA הוצאו להורג; סיכונים שיוריים מתקבלים.
[ ] ”מצב אנונימי” או מצב עם מינימום נתונים נחשב החוצה.
B. לבנות/לשחרר
[ ] סודות במנהל, מפתחות/הצפנה מוגדרים.
[ ] בולי עץ ללא מח "ש; אירועים וביקורת מתאפשרת.
[ מדיניות הניתוב והשימור האזורית ] פעילה.
[ ] בדיקות: הסכמה-שערים, מכחיש-ידי-ברירת מחדל לתגים, מחיקה-נתיב.
C. במבצעים
[ ] רבעון ביקורות גישה ויצוא.
[ ] פיקוח על הפרות ירי ובקשות מעבר לגבול.
[ ] מחיקות/DSARs מבוצעות בזמן; חפצים נשמרים.
15) תבניות (הכנסת זריזות)
תבנית DPIA (קצר)
קטגוריות נתונים: ____ (PII: כן/לא)
סיבה: ____
נחלים/מיקומים: ____
סיכון/השפעה: ____
מדידות: אלה (צופן/אסימונים/בידוד), org (RBAC/training)
סיכון שרידי: ____ החלטה: לאשר/למחזר
B) מדיניות מזעור שדה
שדות תקפים עבור פונקציה הם [... ]. כל תחום חדש דורש עדכון ובדיקה משפטית.
C) סעיף עם ספק (מחויבות PBD)
D) תגובת DSAR (מהירות תריס)
16) טעויות תכופות וכיצד להימנע מהן
אוסף "ליתר ביטחון. □ מדיניות מזערית + סקירת קוד של תוכניות.
רישומים גולמיים עם PII ב- APM. # מסכה/עריכה על הסוכן, חנויות מקומיות.
Global DWH עם PII. # De-PII aggregates/diames בלבד.
אין פריטי DPIA/הסכמה. = מאגר תולעת, אוטומטי-תמונות של UI/טקסטים.
ספקים נעדרים/SDK. רישום רבעוני, איסור על קשרים ”אפורים”.
17) תוכנית יישום של 30 יום
שבוע 1
1. לאשר מדיניות PBD ותבניות DPIA/TRA.
2. בנה מפה של נתונים/זרמים על ידי אזורי מפתח (KYC/PCI/RG/CRM/Logs).
3. הדגש היקפים אזוריים (EU/UK/...); הגדר את מודל המפתח (BYOK/HYOK).
שבוע 2
4) אפשר צינורות tokenization/de-PII והכחשת ברירת מחדל לתגים.
5) הגדרת יומני תולעת (גישה/יצוא/הסכמה/מחיקה).
6) חוזי ספקים מעודכנים (DPA/SCC, מיקומים, תת-מעבדים).
שבוע 3
7) לבצע בדיקות פרטיות ב-CI (מקוון PII, קיבעון מסך CMP, מחק-E2E).
8) שחרור לוח הפרטיות בפרופיל; לשפר טקסטים ומקומות.
9) צוותי רכבת (Product/Eng/Data/CS/Legal).
שבוע 4
10) סקירת DPIA של המאפיין העליון, סגירת CAPA.
11) להתחיל את לוח המחוונים של KPI/KRI (תושבות, יצוא, DSAR SLA).
12) תכנית V1. 1: דיפ. פרטיות לדיווחים, צינורות פדרליים.
18) קטעים קשורים
GDPR: ניהול הסכמת משתמש/עוגיות ומדיניות CMP
לוקליזציה של נתונים על ידי תחום שיפוטName
אימות גיל ומסנני גיל
AML/KYC ואחסון חפצים
ציות ללוח מחוונים וניטור/דו "חות רגולטוריים
ביקורת פנימית/חיצונית ורשימות ביקורת
BCP/DRP/במנוחה ובהצפנת מעבר