חוקי הפרטיות מעצבים את התכנון

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 4 מתוך 6 בפרק איכות נתונים וממשל נתונים, הפרק החמישי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: הכירו את הנתונים שלכם · הבא: הסכמה והזכות להישכח

השאלה שהיחידה הזו עונה עליה: מה רגולציות פרטיות ורגולציות ענפיות דורשות מתכנון ב-Salesforce?

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

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

היחידה הזו היא הנחיה ארכיטקטונית, לא ייעוץ משפטי. הצוותים המשפטיים וצוותי הציות מחליטים אילו חוקים חלים ומה הם דורשים. הארכיטקט הופך את הדרישות האלה לתכנון שאפשר לאכוף.

חוקים לא עוצרים בגבול

קודם כול התפיסה השגויה הגדולה ביותר: “אנחנו לא באירופה, אז GDPR לא חל עלינו.” אולי כן, אולי לא. התחולה הטריטוריאלית של GDPR מגיעה לארגונים מחוץ לאיחוד האירופי שמציעים סחורות או שירותים לאנשים באיחוד, או מנטרים את התנהגותם שם (סעיף 3, Regulation (EU) 2016/679 (opens in a new tab)). אז המקום שבו נמצא המטה של החברה שלכם הוא לא סוף השאלה. איפה הלקוחות שלכם, העובדים, האנשים שאתם מחזיקים את הנתונים שלהם, המערכות שלכם, מעבדי המידע שלכם? לאן הנתונים נוסעים? שוב, זו מפת המערכות מפרק 4. אי אפשר לקבל החלטות פרטיות טובות בלי לדעת לאן הנתונים הולכים.

הרגולציות שכדאי לזהות

הנה השמות שארכיטקט צריך להכיר, עם מה שכל אחד מהם מכסה. זו טבלת זיהוי, לא מטריצת תחולה: אל תקראו אותה ותחליטו “יש לנו לקוחות בקליפורניה, אז דרישה X חלה”. זו ההחלטה של המחלקה המשפטית. התפקיד שלכם הוא לדעת מספיק כדי לשאול את השאלה לפני שהמערכת נבנית.

חוק או תקן	איפה או מה	למה ארכיטקט צריך לזהות אותו
GDPR (opens in a new tab)	האיחוד האירופי	מידע אישי, עיבוד כדין, זכויות הפרט, שמירה, העברות, פרטיות מובנית (privacy by design)
CCPA, as amended by the CPRA (opens in a new tab)	קליפורניה	הזכויות של צרכנים על המידע האישי שעסקים אוספים עליהם
PIPEDA (opens in a new tab)	קנדה	איך ארגונים במגזר הפרטי מטפלים במידע אישי
LGPD (opens in a new tab)	ברזיל	החוק הכללי של ברזיל להגנה על מידע אישי
Privacy Act 1988 (opens in a new tab)	אוסטרליה	איך ארגונים מטפלים במידע אישי, לפי עקרונות הפרטיות האוסטרליים (Australian Privacy Principles)
HIPAA (opens in a new tab)	שירותי הבריאות בארה”ב	מידע רפואי מוגן בהקשרים שהחוק חל עליהם
PCI DSS (opens in a new tab)	כרטיסי תשלום	הגנה על נתוני חשבון של כרטיסי תשלום
Sarbanes-Oxley (SOX) (opens in a new tab)	חברות ציבוריות בארה”ב	הבקרות והראיות שמאחורי הדיווח הכספי
COPPA (opens in a new tab)	ארה”ב, ילדים ברשת	מידע אישי שנאסף ברשת מילדים

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

מה משותף לחוקים

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

זכויות. אנשים יכולים לבקש לראות את הנתונים שלהם, לתקן אותם, למחוק אותם ולקחת אותם איתם; לפי החוקים של קליפורניה וברזיל הם יכולים גם לבקש שלא ימכרו אותם. כל אחת מהבקשות האלה פירושה למצוא את הנתונים של האדם, את כולם.

העברות. GDPR ו-LGPD מפקחים על מידע אישי שיוצא מתחום השיפוט שלהם ודורשים הגנה נאותה במקום שאליו הוא הולך; PIPEDA מצפה לאותה רמת הגנה כשצד שלישי מעבד את הנתונים, איפה שלא יהיה. שוב מפת המערכות: אילו חצים חוצים גבול?

הודעה על פריצת אבטחה. כשמידע אישי נחשף, החוקים מצפים שתודיעו לרשויות, ולפעמים לאנשים שנפגעו, בתוך מועד שמשתנה מחוק לחוק. אי אפשר להודיע על נתונים שלא ידעתם שיש לכם, או להגיד מה נחשף אם אתם לא מוצאים את העותקים.

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

מתחילים ממה שאישי

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

איפה זה חי?

“ב-Salesforce.” כנראה לא רק ב-Salesforce. האם זה הגיע משותף קמעונאי? הועתק ל-Snowflake, נקלט ב-Data 360, נכתב ללוג של אינטגרציה, יוצא בידי משתמש, נשאר בהיסטוריית השדות, הועבר לארכיון, הועתק ל-sandbox, הועבר לשותף, שימש בשיחה של סוכן? מידע אישי מתפשט. אז כשהמחלקה המשפטית שואלת “איפה אנחנו מחזיקים את המידע של האדם הזה?”, “אנחנו יודעים איפה הערך הנוכחי” זו לא תשובה. אני רוצה את מפת המערכות ואת השושלת: לאן העותקים הלכו.

Click to enlarge

מספר טלפון אחד, עותקים רבים. הפרטיות חלה גם על העותקים.

למה מותר לכם להשתמש בזה?

להחזיק נתונים ולהיות רשאים להשתמש בהם זה לא אותו דבר. ל-Steve Trucking יש מספר טלפון של נמען כדי לתאם את המשלוח של היום. האם זה הופך אותו לרשימת דיוור שיווקית? לא. הבסיס החוקי תלוי בתחום השיפוט ובמצב, והמחלקה המשפטית מכוונת את זה, אבל הארכיטקטורה צריכה לשאת את התשובה: למה זה נאסף, איזה שימוש אושר, האם נדרשה הסכמה, האם היא ניתנה או נמשכה, ולאיזה ערוץ, כתובת ומטרה. ההרשאה להשתמש בנתונים חייבת להיות ניתנת לייצוג כנתונים, כי מסמך מדיניות לא יכול לקבל החלטה בזמן ריצה. היחידה הבאה ממדלת את זה.

לאסוף פחות זו החלטה ארכיטקטונית

אחת מבקרות הפרטיות החזקות ביותר היא לא לאסוף את הנתונים, או לא להעתיק אותם למקום שבו לא צריך אותם. האם Snowflake צריך את מספר הטלפון של הנמען? האם האנליטיקה צריכה את הכתובת המלאה? האם ה-sandbox צריך תמונות משלוח אמיתיות? האם סוכן צריך את הפרטים האישיים של הנמען כדי לענות על השאלה הזו? אם לא, הבקרה החזקה ביותר אולי היא לא לשים אותם שם. כל עותק שאתם לא יוצרים הוא עותק שלא צריך לאבטח, לשמור, למחוק, לעקוב אחרי ההסכמה שלו, לבקר או לדווח עליו בפריצה. המידע הרגיש הכי זול לנהל הוא המידע שמעולם לא העתקתם.

השמירה היא חלק מהמודל

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

מאונמז, מפוסאודונם, מוצפן, ממוסך

החליפו את “Jane Smith” ב-7F92A1. האם Jane עברה אנונימיזציה? לא, אם טבלה אחרת עדיין אומרת 7F92A1 = Jane Smith. זו פסאודונימיזציה: המזהה הישיר מוחלף, אבל אפשר לקשר את הנתונים מחדש בעזרת מידע שנשמר בנפרד, ולפי GDPR מידע שעבר פסאודונימיזציה הוא עדיין מידע אישי (סעיף 4(5)). אנונימיזציה הולכת רחוק יותר: כבר אי אפשר באופן סביר לקשר את הנתונים לאדם (פסקת מבוא (Recital) 26). אז כשמישהו אומר “לא צריך למחוק את זה, פשוט נסיר את השם”, היזהרו. אם עדיין אפשר באופן סביר לזהות את האדם, לא חציתם את הקו הזה. האם התוצאה עומדת בחוק זו ההחלטה של המחלקה המשפטית; התפקיד של הארכיטקט הוא להגיד בדיוק מה המערכת עושה: האם אפשר לקשר מחדש, אילו מפתחות נשארים, איפה המיפויים?

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

הרגולציה הופכת לדרישות

המחלקה המשפטית לא צריכה להגיד לי ליצור ערכת הרשאות; זה הצד שלי של הקו. המחלקה המשפטית יכולה להגיד “רק עובדים עם צורך עסקי לגיטימי רשאים לגשת לקטגוריה הזו של מידע אישי”. ואז אני מתרגם: מי הם, איך מזהים את הקטגוריה, איך ניתנת הגישה, מה קורה כשמישהו מחליף תפקיד, האם אינטגרציה יכולה לקרוא את זה, האם סוכן יכול, האם אפשר לייצא את זה, ואיך מוכיחים מי ראה את זה? הבעלים קובעים מדיניות; הארכיטקטים אוכפים אותה. הצוותים המשפטיים וצוותי הציות קובעים את החובה, בעלי הנתונים קובעים את המדיניות העסקית, והארכיטקט מתכנן את האכיפה.

Click to enlarge

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

וציות הוא לא מוצר. אי אפשר לקנות “ציות: מופעל”. הצפנה יכולה לתמוך בדרישה, יכולות ביקורת מספקות ראיות, כלי שמירה מבצעים מדיניות, נתוני הסכמה תומכים בשימוש מותר, אבל רישוי של פיצ’ר לא הופך ארכיטקטורה לעומדת בדרישות. הציות מגיע מכל התכנון: אנשים, מדיניות, תהליך, נתונים, בקרות וראיות. Salesforce הוא חלק מזה, לא כל זה. ואם מדיניות חשובה מספיק כדי לאכוף אותה, שאלו אם היא חשובה מספיק כדי להוכיח אותה: מי ניגש לרשומה הזו ב-17 במרץ, מי שינה את השדה הזה, מה הכיל הייצוא ההוא? יחידה 6 עוסקת בראיות.

הפרטיות משנה את מפת המערכות

ב-Steve Trucking, המידע האישי של הנמען מגיע דרך שלוש אינטגרציות של שותפים. Salesforce צריך אותו כדי להפעיל את המשלוחים; הצוותים צריכים חלק ממנו, רק בעצירות שלהם, רק ביום עצמו; Snowflake רוצה אנליטיקה של משלוחים; הכספים צריכים מספיק כדי לחייב, אבל לא את מה שהצוות רואה. ושותף קמעונאי אחד לעולם לא יכול לראות את הנמענים של שותף אחר. הפרטיות משנה את החצים: שדות מסוימים לא הולכים ל-Snowflake, האנליטיקה מקבלת גרסה פחות מזהה, הצוותים רואים רק את העצירות שלהם, השמירה במורד הזרם שונה מהשמירה התפעולית. דרישת הפרטיות לא יושבת ליד תרשים מפת המערכות. היא משנה אותו.

שאלות שיחיו יותר מהרגולציות

רגולציות משתנות, אז החזיקו סט קבוע של שאלות לכל מידע רגיש או מוסדר:

• מה זה? מידע אישי, רגיש, כספי, רפואי, של תשלומים, של ילדים, או מוסדר בדרך אחרת?
• איפה זה חי? כל עותק: אינטגרציות, היסטוריה, אנליטיקה, ארכיונים, סביבות sandbox, לוגים, שימוש ב-AI.
• למה מותר לנו להשתמש בזה? איזו מטרה ואיזה בסיס חוקי חלים? האם יש הסכמה בתמונה?
• מי רשאי להשתמש בזה? אנשים, מערכות, שותפים, אינטגרציות, סוכנים.
• כמה זמן שומרים את זה, ומה קורה בסוף?
• האם האדם יכול לממש את הזכויות שלו לגבי זה? עיון, תיקון, מחיקה, ניוד, התנגדות, כפי שהחוק קובע.
• האם אנחנו יכולים להוכיח מה קרה? גישה, שינויים, ייצואים, הסכמה, מחיקה, שמירה.

ממשל AI הופך לחוק

ה-AI מוסיף עוד צרכן של נתונים מנוהלים. האם מערכת AI יכולה להשתמש בנתונים האלה, לאיזו מטרה, כעיגון בנתונים (grounding), בשילוב עם מה, בחזרה עליהם בפלט שלה, ברישום ללוג איפה, ולכמה זמן? הממשל על AI עובר ממדיניות של חברות אל החוק: חוק ה-AI של האיחוד האירופי (AI Act) (Regulation (EU) 2024/1689 (opens in a new tab)) הוא הדוגמה הרחבה הראשונה. מה שהוא דורש תלוי במערכת ובשימוש. הכיוון לארכיטקטים ברור: ה-AI לא יושב מחוץ לממשל הנתונים; הוא עוד צרכן של נתונים מנוהלים.

מה הארכיטקט מחליט כאן

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

רגולציות לא הופכות לארכיטקטורה כששמים את השמות שלהן על שקופית. הן הופכות לארכיטקטורה כשהן משנות את האופן שבו נתונים נאספים, מסווגים, מועברים, מוגנים, נשמרים, נמחקים ומוכחים.

להרחבה

• המקורות הרשמיים של הרגולציות מקושרים בטבלה למעלה (באנגלית, נבדק ב-2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): סעיף 3 (תחולה טריטוריאלית), סעיף 4(5) (פסאודונימיזציה), פסקת מבוא (Recital) 26 (מידע אנונימי).
• Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab), EUR-Lex.