פרטיות באמצעות עיצוב

פרטיות לפי עיצוב (GDPR)

1) על מה מדובר ומדוע

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

• מזעור האיסוף והעיבוד של נתונים אישיים (PD).
• להבטיח חוקיות, שקיפות, תקינות, הגבלת מטרות ומועדים.
• להפחית סיכונים (טכניים ומשפטיים), לפשט את הביקורות ולהוכיח ציות.

2) תפקידי GDPR, מסגרות משפטיות ועקרונות

2. 1 תפקידים

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

2. 2 עילה חוקית (בחירה ומסמך)

הסכמה, חוזה, אינטרס לגיטימי, חובה משפטית, אינטרסים חיוניים, משימה ציבורית. לכל מטרה, נתונים, שימור, שלילה (לצורך הסכמה).

2. 3 עקרונות עיבוד (Art. 5)

חוקיות, הגינות, שקיפות

מגבלת מטרה

מזעור נתונים

דיוק

הגבלת אחסון

יושרה וסודיות

אחריות - היכולת להוכיח ציות.

3) תהליך PBD ב ־ SDLC (מסגרת ייחוס)

1. חניכה: ניסוח יעדי עיבוד וקרקעות משפטיות, הקצאה של בעלי נתונים ונקודת DPO.
2. מיפוי נתונים (Data Mapping): מקורות = שדות = מודל סודי = = = שבו זרימה = = קורא = = איפה מאוחסנים.
3. הערכת סיכונים/DPIA: LINDDUN-מודל של איומים בפרטיות, הערכת השפעה, אמצעים להקלה.
4. פתרונות ארכיטקטוניים: בחירה של מזעור, פסאודונימיזציה, הצפנה, תוכניות הבחנה.
5. דרישות להודעות UX/consents/: טקסטים ברורים, הסכמה גרנית, הגדרת ברירת מחדל.
6. מימוש: ברירות מחדל פרטיות, טלמטריה מאובטחת, רישום ללא סודות/מח "ש.
7. אימות: בדיקות פרטיות, ניתוח סטטי, בדיקות יחידה פרטיות, פרוטוקולי DPIA.
8. מבצע: תהליכי DSAR, שימור ואופי, ניטור תקריות, ביקורות ספקים.
9. סקירה רגילה: מחדש DPIA בעת שינוי מטרות/טכנולוגיות.

4) דפוסי PBD הנדסיים

4. 1 מזעור ופירוק

לאסוף רק את השדות הדרושים; ליישם פרופיל מתקדם.
זיהוי ותוכן נפרדים: לאחסן את מפתח הקישור בנפרד (token/reference).

4. 2 חיידקים ואנונימיות

שינוי - לאחסן את תעודת הזהות האמיתית בנפרד; שכבת העבודה רואה את האסימון.
אנונימיות: השתמש באנונימיות k, l-גיוון, t-סגירה; עבור אנליטיקה - פרטיות דיפרנציאלית (extreme-budget).

4. 3 בקרת גישה והפרדת תפקידים

POLP, ABAC/RBAC, הפרדה בין חובות, מתווה נפרד לניהול ואנליסטים.
אלה. אמצעים: mTLS, SSO/OIDC, אסימונים מסומנים, חשבונות זמניים לגישה לנתונים אישיים.

4. 4 הצפנה ובידוד

בטרנזיט: TLS 1. 3/mTLS; במנוחה: AEAD/מעטפה + KMS/HSM.
מקשים נפרדים עבור הדייר/נתונים; מחיקה מוצפנת ל ”זכות להישכח”.

4. 5 שימור והסרה

מדיניות TTL מפורשת לשדה/מטרה; טיהור אוטומטי בצינורות; ”מחיקה של שני פאזות” (לוגי = פיזי).
לגיבויים - מפתחות נפרדים וחלונות אחסון קצרים לתמונות אישיות.

4. 6 טלמטריה פרטית וכריתת עצים

ברירת המחדל היא לא מח "ש; השתמש באסימונים/חשיש עם מלח.
מסווה/אסימון של שדות רגישים על המפיק.

4. 7 UX פרטיות והסכמה

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

5) DPIA ו LINDUN (קצר)

DPIA (Data Protection Impact Assession): נדרש בסיכון גבוה (ניטור בקנה מידה גדול, הערכה, טכנולוגיה חדשה). הוא מורכב מתיאור של עיבוד, הכרח/מידתיות, הערכת סיכונים, אמצעים להפחתה.
LINDUN (LINDUN): Linkability, Identifiability, Non-Refectability, Detectability, Discure of Information, Unaudity, Non-Compression. לכל איום - אמצעי נגד (מזעור, פסאודונימיזציה, DP, שקיפות, ניהול הסכמה, ביקורת חשבונות).

6) העברות חוצות גבולות

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

7) ספקים ומעבדים (ניהול ונדור)

מעבדי DPA/מקוננים, אמצעים טכניים וארגוניים, תת-מעבדים תחת שליטה.
ביקורות וביקורות רגילות; הזכות לבדיקה; תוכנית יצוא נתונים.

8) זכויות נושא המידע (DSAR)

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

9) פתרונות אוטומטיים ופרופיל (Art. 22)

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

10) אבטחת עיבוד (אמנות, 32) ותקריות (אמנות. 33/34)

אמצעים מונחי סיכון: הצפנה, שלמות, עמידות, תוכניות התאוששות (RTO/RPO).
תקריות PD: * triage exchange procession accession procession = = הערכת סיכונים = = הודעה של הרגולטור 72 שעות (היכן שנדרש) ונבדקים (אם הסיכון גבוה).
חוברת משחקים נפרדת, רשימת אנשי קשר, תבניות הודעה.

11) פרטיות ו ־ ML/אנליטיקה

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

12) דיאגרמות ארכיטקטוניות (תבניות)

12. 1 ארכיטקטורת זיהוי ”לולאה כפולה”

לולאה A (PDS - Personal Data Store): מידע זיהוי אמיתי (RID), גישה - מוגבל לחלוטין, מפתחות/הצפנה/ביקורת.
מתווה ב '(תפעולי): מידע עסקי עם אסימונים; תקשורת באמצעות ברוקר סמלי עם גבולות וביקורת.

12. 2 שירות הסכמה

שירות מרכזי המאחסן גרסאות הסכמה והיסטוריה.
SDK: ”can _ use (קטגוריה, מטרה)” - פתירות בזבוב; הכל מחובר.

12. 3 מדיניות שמירה כקוד

YAML Configuration - Intenty # Field # TTL # Action (אנונימי/מחק/Coarse).
הלוח זמנים מבצע עבודות, דיווח זמין למנהל התפעול.

13) מתכונים קטנים

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) תיעוד ואחריות

(ROPA (Records of Processing Activity - רשם פעולות: מטרה, בסיס משפטי, קטגוריות של נתונים/נושאים, העברות, תקופות שימור, אמצעים.
מדיניות: פרטיות, עוגיות, הודעות מידע במוצר (בשפה פשוטה).
אימוני צוות וביקורות שנתיות.

15) שגיאות תכופות

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

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

[ ] מטרת העיבוד והבסיס החוקי נקבעים; מעודכן על ידי ROPA.

[ ] מיפוי נתונים ו-DPIA בוצעו (במידת הצורך).

[ ] מימוש מזערי, חייזרים, הצפנה (בדרך/במנוחה).

[ קונסנטים ] הם גרנולריים, עם UX ברור; ברירות המחדל פרטיות.

[ ] הגדרת את מדיניות השמירה כקוד; מחיקה/אנונימיות בדקו.

[ ] לוגים/טלמטריה - לא מח "ש; מיסוך מופעל.

[ ] ווים ויצוא של DSAR.

[ אימוני צוות ] ואישור DPO הושלם.

[ סקירה רבעונית ] של חזרות ועילות משפטיות.

[ ] מעבד תקופתי/ביקורת מעבד משנה.

[ ] ניטור אירועים ומוכנות להודעה על 72 שעות.

[ ] Revision of DPIA עם שינויים בתהליך/טכנולוגיה.

[ אחסון ] של חפצי ציות (DPIA, ROPA, דוחות בדיקה).

17) FAQ

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

קיו: האם זהות בדויה מספיקה? ‏

א ': לא, זה עדיין מידע אישי. כדי לצאת מספירת GDPR, יש צורך בעילום שם אמין (בדוק את חוסר האפשרות של זיהוי מחדש).

קיו: מה עם אם-אל והתאמה אישית?
A: מזעור תכונות, שימוש בגישות DP/federated, רישום החלטות, הבטחת הזכות להתערבות אנושית ואי-פרופיל.

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

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