להגן, לשמור ולהוכיח

🌐 זמין גם ב-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)

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

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

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

השאלה שהיחידה הזו עונה עליה: איך מגינים על נתונים, שומרים אותם כל עוד צריך, ומוכיחים את זה?

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

ממשל הנתונים הולך אחרי הנתונים

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

איסוף ← סיווג ← הגנה ← שימוש ← שמירה ← מחיקה ← ביקורת

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

Click to enlarge

שבע שאלות לאורך חיי הנתונים. הכלים תומכים במדיניות; הם לא מגדירים אותה.

הגנה: התאימו את הבקרה לנתונים

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

הצפנה היא בקרה, לא ציות

לנתונים מוסדרים, ייתכן שתידרש הצפנה במנוחה (at rest), והעמדה שלי היא ש-Shield הוא התשובה לדרישות רגולטוריות מרכזיות כמו זו. Shield Platform Encryption מצפין שדות וקבצים במנוחה. אבל “הצפנו את זה, אז אנחנו עומדים בדרישות” שגוי פעמיים. הצפנה היא בקרה אחת לצד גישה, שמירה, ביקורת, הסכמה, ניטור, צמצום ומחיקה. ויש לה פשרות פונקציונליות שמתכננים בשבילן מראש. עם סכמת ברירת המחדל, הסתברותית (probabilistic), אי אפשר להשתמש בשדה מוצפן בסעיפי SOQL WHERE, GROUP BY או ORDER BY או במסננים של ניהול נתונים; הצפנה דטרמיניסטית (deterministic) מוותרת על קצת חוזק כדי שתוכלו לסנן לפי השדה. שדות מוצפנים לא יכולים להניע כללי שיתוף מבוססי קריטריונים, ואי אפשר למיין לפיהם תצוגות רשימה (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). אז הצפנה היא לא תיבת סימון בסוף. היא החלטה ארכיטקטונית. פרק אבטחת הנתונים נכנס לעומק.

אל תעתיקו את הסיכון של סביבת הייצור ל-sandbox

סביבת הייצור נעולה. ואז מישהו מרענן full sandbox, ועכשיו למפתחים, לבודקים, לקבלנים ולאינטגרציות בדיקה יש עותקים של מידע אישי אמיתי שהם אף פעם לא היו צריכים. הסביבה השתנתה; הרגישות של הנתונים לא. כלי המיסוך של Salesforce קיימים בדיוק בשביל זה. שימו לב לשינוי: החבילה המנוהלת Data Mask מגיעה לסוף השירות ב-31 בדצמבר 2026, והיורשת שלה היא Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). אבל הכלי תומך במדיניות, והשאלה באה קודם: האם הסביבה הזו בכלל צריכה נתונים רגישים אמיתיים? אם נתונים מציאותיים ולא רגישים יכולים לשמש לבדיקות, זו התשובה הטובה יותר.

שימוש: הרשאה היא לא רק עניין של אנשים

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

שמירה: לשמור הכול לנצח זה לא ניטרלי

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

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

מחיקה: מחזור החיים צריך יציאה

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

גם היסטוריה היא נתונים

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

מעקב היסטוריית שדות (field history tracking) הסטנדרטי עוקב אחרי עד 20 שדות לכל אובייקט ושומר שינויים עד 18 חודשים, ועד 24 חודשים רק דרך ה-API, עם Data Loader או queryAll() (Field History Tracking Overview (opens in a new tab)). ובשדות טקסט ארוכים הוא רושם רק שהשדה נערך, לא מה היה כתוב בו: פער, אם אלה הראיות שלכם. Field Audit Trail, חלק מ-Shield או נרכש בנפרד, עוקב אחרי עד 200 שדות לכל אובייקט ושומר את ההיסטוריה עד שתמחקו אותה, בארכיון שניגשים אליו דרך ה-API (Field Audit Trail (opens in a new tab)). העמדה שלי: היסטוריית השדות הסטנדרטית היא ברירת המחדל; השתמשו ב-Field Audit Trail כשרגולציה או חובת ציות דורשות היסטוריה ארוכה יותר שאפשר להוכיח. לא כי “ביקורת נשמע טוב”.

ביקורת וניטור הם לא אותו דבר

היסטוריית שדות עונה על שאלות על שינויים בשדות נבחרים. שאלות רחבות יותר (מי התחבר, מי ייצא נתונים, אילו APIs נקראו, מי צפה במה) הן ניטור, וזה Event Monitoring. מהניסיון שלי, בדרך כלל צריך אותו אצל לקוחות מוסדרים יותר, והנה העמדה הכי נחרצת שלי בפרק הזה: הגדירו אותו לפני שאתם צריכים אותו, והזרימו את האירועים מראש למאגר, כמו Splunk או SIEM אחר.

והנה למה. קובצי יומן האירועים נשמרים יום אחד בלי התוסף, ורק לחלק מסוגי האירועים; 30 יום כברירת מחדל עם Shield או עם התוסף Event Monitoring, ועד 365 יום אם מאריכים את השמירה (Event Monitoring FAQ (opens in a new tab)). כל מה שישן יותר נעלם, אלא אם ייצאתם אותו. ואי אפשר לשלוף את הלוגים בתשלום לשום תקופה שלפני תחילת החוזה שלכם (אותו FAQ): לקנות את התוסף אחרי האירוע לא מחזיר את העבר. אז אחת השיחות הכי גרועות שארכיטקט יכול לנהל הולכת כך: “אפשר לראות מה קרה לפני שישה חודשים?” “לא.” “למה לא?” “לא אספנו את זה.” לא רוצים להיתקל בבעיה ורק אז לגלות שלא אספתם ולא שמרתם את האירועים האלה. עד אז התשובה פשוט נעלמה.

Click to enlarge

הגדירו את זה לפני שאתם צריכים.

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

הוכיחו את הבקרה, לא רק את ההגדרות

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

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

Steve Trucking: מחזור החיים על שדה אחד

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

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

ממשל נתונים אף פעם לא נגמר

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

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

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

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

להרחבה

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) ו-Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Field Audit Trail (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).