GH GambleHub

פרטיות באמצעות עיצוב: עקרונות עיצוב

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)

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

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/במנוחה ובהצפנת מעבר

Contact

צרו קשר

פנו אלינו בכל שאלה או צורך בתמיכה.אנחנו תמיד כאן כדי לעזור.

Telegram
@Gamble_GC
התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

בלחיצה על הכפתור אתם מסכימים לעיבוד הנתונים שלכם.