שירותי מחשוב לארגונים עם דרישות GDPR מאפשרים עמידה בתקנות הפרטיות האירופיות. קנסות של עד 4 אחוזים מהמחזור השנתי מאיימים על ארגונים שאינם ערוכים, ותשתית IT מקצועית מצמצמת את הסיכון משמעותית.
תוכן עניינים
- מה כוללים שירותי מחשוב לארגונים עם דרישות GDPR ולמי הם רלוונטיים?
- עקרונות יסוד בשירותי מחשוב לארגונים עם דרישות GDPR
- תשתית טכנולוגית מאובטחת – הבסיס של שירותי מחשוב לארגונים עם דרישות GDPR
- ניהול גישה והרשאות בשירותי מחשוב לארגונים עם דרישות GDPR
- גיבוי, שחזור וזכות המחיקה בשירותי מחשוב לארגונים עם דרישות GDPR
- ניטור ודיווח על אירועי אבטחה במסגרת GDPR
- ההבדלים בין תקנות GDPR האירופיות לחוק הגנת הפרטיות הישראלי
- בחירת ספק לשירותי מחשוב לארגונים עם דרישות GDPR
- הכשרת עובדים ומודעות לפרטיות – הגורם האנושי
- סיכום – תשתית IT שעומדת בדרישות הרגולציה
מה כוללים שירותי מחשוב לארגונים עם דרישות GDPR ולמי הם רלוונטיים?
תקנות GDPR (General Data Protection Regulation) שנכנסו לתוקף במאי 2018 מסדירות את אופן עיבוד המידע האישי של תושבי האיחוד האירופי.
הטעות הרווחת היא להניח שמדובר ברגולציה אירופית בלבד שאינה נוגעת לארגון ישראלי, אך המציאות שונה.
שירותי מחשוב לארגונים עם דרישות GDPR מקיפים את כל מערכי ה-IT שצריכים לתמוך באיסוף, עיבוד, אחסון, גיבוי ומחיקה של מידע אישי בצורה שעומדת בתקנות, כולל בקרות אבטחה טכניות, ניהול הרשאות, תיעוד פעולות, גיבוי מאובטח, יכולות שחזור והליכי דיווח על אירועי אבטחה.
אנחנו ב-IP מחשבים, עם למעלה משני עשורים של פעילות בתחום ה-שירותי IT לעסקים, מלווים ארגונים שנדרשים להתמודד בו זמנית עם רגולציה אירופית וישראלית, מה שדורש תשתית הנדסית מאוזנת.
התקנה חלה על כל ארגון שמעבד מידע על תושבי האיחוד, גם אם הוא יושב בישראל ולא במדינה חברה.
זה כולל בין השאר את הסוגים הבאים של ארגונים:
- חברות e-commerce שמוכרות לקהל אירופי או באתרים בשפות אירופיות
- חברות SaaS וסטארטאפים עם משתמשים בקרב תושבי האיחוד
- חברות שירותים מקצועיים שמייצגות לקוחות אירופיים (משרדי עורכי דין, רואי חשבון, יועצים)
- סוכנויות תיירות, נסיעות ומלונאות שמטפלות באורחים אירופיים
- מפעלים ויצרנים עם שותפים, ספקים או לקוחות באירופה
- חברות פארמה ומחקר רפואי המנהלות נסיונות קליניים בינלאומיים
- נותני שירותי ענן, מארחים וספקי תשתית עבור גופים אירופיים
התקנה אינה מבחינה בין ארגון גדול לקטן.
חברה ישראלית קטנה שמוכרת מוצר לחמישה לקוחות בגרמניה כפופה לאותן דרישות בסיסיות שחלות על תאגיד רב לאומי, אם כי בהיקפים מותאמים לסיכון.
חשוב להבין שגם פעולות שנראות שגרתיות לחלוטין נכנסות לתחולה – שליחת ניוזלטר ללקוח אירופי, קליטת קורות חיים ממועמד אירופי, או שיתוף פעולה עסקי עם חברה שיש לה נציגים באיחוד – כל אלה מחייבים תשתית IT שעומדת בדרישות.
בנוסף, פסקי דין בערכאות אירופיות הרחיבו לאחרונה את הפרשנות וקבעו שגם איתור גאוגרפי באמצעות קוקיז, יצירת פרופיל התנהגותי, או פנייה שיווקית מותאמת אישית – יוצרים חבות מלאה גם לארגון שיושב פיזית מחוץ לאיחוד.
לכן הצעד הראשון הוא תמיד מיפוי מקיף – אילו סוגי מידע אישי הארגון אוסף, מאיפה הוא מגיע, איפה הוא נשמר, מי ניגש אליו, ומתי הוא צריך להימחק.
המיפוי הזה (Data Inventory או Data Mapping) הוא נכס ארגוני שמתעדכן באופן שוטף ומהווה את הבסיס לכל החלטה טכנולוגית בהמשך.
ארגון שאינו יודע איזה מידע אישי הוא מחזיק, איפה הוא יושב ומי ניגש אליו, איננו מסוגל לעמוד בדרישות GDPR גם אם ישקיע בטכנולוגיה מתקדמת.
עקרונות יסוד בשירותי מחשוב לארגונים עם דרישות GDPR
התקנה האירופית בנויה על שורת עקרונות יסוד שכל מערך מחשוב חייב לתמוך בהם במישור הטכני, לא רק ברמת המדיניות.
לפני שאנחנו ניגשים לתכנון תשתית, אנחנו פורסים בפני הלקוחות את חמשת העקרונות המרכזיים שעל פיהם נבנית ארכיטקטורת המחשוב כולה:
חוקיות, הוגנות ושקיפות (Lawfulness, Fairness, Transparency)
כל איסוף מידע אישי חייב לעמוד על בסיס חוקי ברור, להיות הוגן כלפי נושא המידע ולהיות שקוף לחלוטין.
מבחינה טכנית, זה מתרגם למערכות שמסוגלות לנהל הסכמה (Consent Management), להציג דוחות גישה ולספק רשומה מלאה של פעולות עיבוד.
מערכת ה-CRM, מערכת ה-ERP ומערכות המידע התפעוליות חייבות להיות מסוגלות לתעד הסכמה רגעית, לעדכן אותה ולהציג היסטוריה.
הגבלת מטרה (Purpose Limitation)
מידע שנאסף למטרה אחת אסור לעבד למטרה אחרת ללא הסכמה נוספת.
ברמת ה-IT, זה אומר חיץ לוגי בין מערכות, הפרדת בסיסי נתונים לפי קונטקסט עסקי וניהול קפדני של זרימות המידע בין מערכות.
מינימיזציה של מידע (Data Minimization)
אספו רק את המידע הנחוץ, לא יותר.
זה אתגר תכנוני עיקרי בעולם ה-ERP – מערכות כמו Priority, SAP ו-חשבשבת תוכננו בעבר לאסוף ולשמור כל דבר.
ביישום ERP לארגונים עם דרישות GDPR, אנחנו עוברים שדה אחר שדה ומגדירים מה חובה, מה רצוי ומה מיותר.
דיוק ועדכניות (Accuracy)
המידע חייב להיות מדויק ומעודכן.
מערכות הסנכרון בין מערכות שונות (Master Data Management), תהליכי ניקוי נתונים תקופתיים ויכולת עדכון מהירה של רשומות כאשר נושא המידע פונה הם חובה תפעולית.
הגבלת אחסון (Storage Limitation)
מידע שלא נחוץ עוד צריך להימחק או להפוך לאנונימי.
זה דורש מנגנוני רטנציה מובנים, פוליסות מחיקה אוטומטיות, ויכולת מחיקה מסונכרנת בכל מערכות הארגון, כולל גיבויים ארוכי טווח, מה שאנחנו נדון בו בהמשך.
שלמות וסודיות (Integrity and Confidentiality)
זה הליבה הטכנית של ההגנה, שמתורגמת ל-אבטחת מידע וסייבר לעסקים בכל הרמות, מהרשת ועד נקודת הקצה.
אחריותיות (Accountability)
בעל מאגר חייב להיות מסוגל להוכיח שהוא עומד בכל העקרונות.
בעצם זה אומר תיעוד, תיעוד ועוד תיעוד.
מערכות לוגינג מרכזיות, דוחות אבטחה תקופתיים, רשומות פעולת עיבוד (Records of Processing Activities) ויכולת להציג את הכל לרשות הפיקוח בעת בקרה – כל אלה הם חלק בלתי נפרד מתשתית IT שעומדת בדרישות.
ה-Records of Processing Activities, או רשומת פעולות עיבוד, היא מסמך חי שצריך לכלול לפחות את הפרטים הבאים: שם ופרטי הקשר של בעל המאגר ושל הממונה על הגנת הפרטיות, מטרות העיבוד, סוגי נושאי המידע וסוגי המידע, סוגי הנמענים שהמידע מועבר אליהם, פרטים על העברות לחו"ל אם רלוונטי, לוחות הזמנים החזויים למחיקת הסוגים השונים של המידע ותיאור כללי של אמצעי האבטחה הטכניים והארגוניים.
תיעוד זה אינו "טופס" שממלאים פעם ושוכחים, אלא משאב שמתעדכן בכל שינוי משמעותי בארגון או במערכות שלו.
תשתית טכנולוגית מאובטחת – הבסיס של שירותי מחשוב לארגונים עם דרישות GDPR
סעיף 32 לתקנה האירופית מחייב יישום של "אמצעים טכניים וארגוניים מתאימים" לרמת אבטחה ההולמת את הסיכון, ובכלל זה הצפנה, יכולת לשמור על סודיות, שלמות, זמינות וגמישות מערכות העיבוד, וכן יכולת לשחזר את הגישה למידע באירוע פיזי או טכני.
מבחינה הנדסית, זה מתורגם לכמה שכבות:
הצפנה במעבר ובאחסון
כל המידע האישי מוצפן הן בעת מעבר (TLS 1.2 ומעלה לכל תקשורת) והן באחסון (Disk Encryption, Database Encryption, File System Encryption).
בשירותי מחשוב ענן לעסקים שאנחנו מספקים מחוות השרתים הפרטית בראשון לציון, ההצפנה מיושמת ברמת ה-Storage כברירת מחדל ומפתחות ההצפנה נשמרים בנפרד ממאגר המידע.
נושא ניהול מפתחות (Key Management) חשוב לא פחות מההצפנה עצמה.
מפתח שנשמר באותו שרת עם המידע המוצפן, או מפתח שזמין לכל מנהל מערכת, מבטל למעשה את ההגנה.
פתרון Hardware Security Module (HSM) או Key Management Service מנוהל הם הסטנדרט בארגונים שלוקחים את הנושא ברצינות, ומאפשרים סבבוב מפתחות אוטומטי, הפרדת תפקידים בגישה למפתחות והגנה פיזית עליהם.
חשוב להחיל הצפנה גם על תקשורת פנימית בין מערכות, לא רק על תקשורת חיצונית.
מתקיף שמצליח לחדור לרשת הפנימית מצפה למצוא תעבורה לא מוצפנת בין שרתים, ובסיסי נתונים שמשתמשים בפרוטוקולים ישנים שמעבירים סיסמאות בטקסט.
ארגון בוגר בתחום, מצפין את הכל – מהמייל בין שני עובדים ועד התקשורת בין שרת האפליקציה לבסיס הנתונים.
סגמנטציה של רשת
מערכות שמחזיקות מידע אישי רגיש לא צריכות להיות באותה רשת לוגית עם מערכות שלא מחזיקות מידע כזה.
מיקרו סגמנטציה, VLANs, חומות אש פנימיות ופוליסות Zero Trust מצמצמים את שטח התקיפה ומקיפים את כל מערך הגישה למידע.
בעידן של עבודה היברידית, סגמנטציה אינה רק עניין של רשת פיזית פנימית.
היא כוללת גם את האופן שבו עובדים מרחוק מתחברים, איך מערכות SaaS מתממשקות זו עם זו, ואיך גישה בין אזורים גאוגרפיים מנוהלת.
ארגון מודרני בנוי כשרשרת של "מובלעות" קטנות שכל אחת מהן מאובטחת בנפרד, במקום חומה חיצונית אחת גדולה – מודל שהוכח כלא יעיל מול תוקפים מתחכמים.
הגנת נקודת קצה מתקדמת
נקודות הקצה (תחנות עבודה, ניידים, שרתים) הן הוקטור הנפוץ ביותר לחדירה.
פתרון EDR/XDR שמזהה התנהגות חשודה בזמן אמת הוא אבן יסוד, ואנחנו פורסים אצל לקוחותינו את פתרון SentinelOne כפלטפורמת ה-EDR המרכזית, יחד עם NinjaOne RMM לניהול וניטור צי המכשירים.
חשוב להבין שאנטי וירוס "קלאסי" שמבוסס על חתימות אינו מתאים לסביבת רגולציה.
תקיפות מודרניות עוקפות בקלות חתימות סטטיות, ומה שמבדל פתרון EDR איכותי הוא היכולת לנתח התנהגות תהליכים, לזהות אנומליות ולהפעיל תגובה אוטומטית עוד לפני שהאיום מתממש.
הצפנה ללא ניהול מפתחות תקין שווה כמעט אפס, ופתרון EDR ללא תהליך תגובה מוגדר לא מונע נזק כלל.
גיבויים מאובטחים ומבודדים
גיבוי שיושב באותה רשת עם המערכת שהוא מגבה אינו עמיד בפני מתקפת כופר.
פתרון גיבוי בענן לעסקים עם בידוד לוגי ופיזי, גרסאות מרובות וקריפטוגרפיה איתנה, הוא רכיב חובה בכל ארכיטקטורה שמיועדת לעמוד בדרישות.
לקוחותינו נהנים מתשתית גיבוי הירארכית שמשלבת גיבוי מקומי לזמן שחזור מהיר, גיבוי בענן הפרטי שלנו בראשון לציון לגיבוי לטווח בינוני, וגיבוי במיקום שלישי לפי דרישת הלקוח לגיבוי לטווח ארוך.
ארכיטקטורה זו מבטיחה ש-RPO ו-RTO של הארגון נשמרים גם בתרחישים קיצוניים, ובמקביל היא נותנת מענה לדרישת ההפרדה הגאוגרפית של מערכות גיבוי.
ניטור ותחזוקה שוטפת
תשתית בטוחה היום עלולה להפוך לפגיעה מחר אם לא מתחזקים אותה.
תיקוני אבטחה (Patching), עדכוני מערכות הפעלה, סריקות פגיעות תקופתיות וטסטי חדירה הם חלק מהשגרה.
לפי תקנות הגנת הפרטיות (אבטחת מידע) הישראליות מ-2017, גם בעלי מאגר ברמת אבטחה רגילה נדרשים לבצע ביקורות פנימיות תקופתיות, ויישום הוראות אלו תומך באופן ישיר גם בעמידה בדרישות GDPR.
| ⭐טיפ זהב⭐
כשאתם בוחנים את תשתית ה-IT שלכם מול דרישות GDPR, אל תסתפקו בבדיקה של "מה יש". בנו תרשים זרימה מלא של המידע האישי בארגון מהנקודה שבה הוא נכנס (אתר אינטרנט, טופס, אינטגרציה) דרך המקומות שבהם הוא נשמר, מי ניגש אליו, לאן הוא מועתק (גיבוי, BI, אנליטיקס) ועד מתי הוא נמחק. ברגע שיש לכם תרשים כזה, פתאום הפערים זועקים מעצמם. |
ניהול גישה והרשאות בשירותי מחשוב לארגונים עם דרישות GDPR
עקרון Need to Know הוא ליבת הגישה למידע אישי לפי GDPR.
משתמש מקבל גישה רק למידע שהוא חייב כדי לבצע את תפקידו, לא יותר ולא פחות.
ברמה הטכנית זה דורש כמה שכבות שעובדות יחד:
ניהול זהויות מרכזי
לקראת יישום ניהול גישה תקין בארגון, אנחנו מנחים את לקוחותינו לבסס את התשתית הבאה:
ספק זהויות יחיד (Identity Provider)
שימוש בספק זהויות מרכזי כמו Microsoft Entra ID (Azure AD לשעבר) מאפשר ניהול עקבי של משתמשים, פוליסות אימות, סיומת חיים של חשבונות ודיווח על פעילות.
אימות רב גורמי (MFA) בכל מקום
MFA הוא לא אופציה אלא דרישת בסיס.
לכל המערכות שמחזיקות מידע אישי, לכל ערוצי הגישה (פנים ארגוני, VPN, שירותי ענן), ולכל סוגי המשתמשים.
הרשאות מבוססות תפקיד (RBAC)
במקום להעניק הרשאות אישית לכל משתמש, מגדירים תפקידים ומקצים משתמשים לתפקידים.
כך, כאשר יש שינוי בארגון, מעבר תפקיד או עזיבה, ניתן להסיר או לעדכן הרשאות במכה אחת מבלי להשאיר "שאריות" מסוכנות.
גישת זהות מועדפת (Privileged Access)
חשבונות מנהל הם המטרה החביבה של תוקפים.
פתרון PAM (Privileged Access Management), הפרדה בין חשבון משתמש יומיומי לחשבון מנהל וכיסוי ב-Just In Time access מצמצמים את הסיכון משמעותית.
ניהול היפרדות (Offboarding) מסודר
ארגונים רבים נכשלים דווקא בנקודת היציאה של עובדים.
חשבון של עובד שעזב לפני שנה ועדיין פעיל הוא פצצה מתקתקת, וזה נכון במיוחד בארגונים עם שירותי ענן רבים שלא משולבים זה בזה.
שירותי מיקור חוץ IT שמסופקים על ידינו כוללים תהליך offboarding סטנדרטי שמבטל גישה לכל המערכות הרלוונטיות תוך שעות מהדיווח על עזיבה.
סקירת הרשאות תקופתית
פעם ברבעון או בחצי שנה, אחראי המידע צריך לעבור על רשימת ההרשאות במערכות הקריטיות ולאשר או לשנות.
תהליך זה (Access Review) נדרש גם לפי מדריך מקצועי של רשות הגנת הפרטיות וגם בדרישות GDPR.
ההמלצה שלנו ללקוחות היא להקצות אחראי תפעולי לכל מערכת קריטית – לא בהכרח מנהל IT – שמכיר את התוכן העסקי של המידע ויודע לזהות הרשאה שנראית "תקינה טכנית" אך אינה הגיונית עסקית.
משתמש שיש לו גישה לשכר של כל הארגון כאשר הוא עובד במחלקת לוגיסטיקה הוא הרשאה שאיש IT לא יזהה אבל ראש מחלקת משאבי אנוש כן.
תיעוד מלא של פעולות גישה
מעבר להגדרת הרשאות, כל פעולת גישה למידע אישי רגיש צריכה להיות מתועדת באופן שמאפשר התחקות.
מי ראה איזה רשומה, מתי, מאיזה IP, ובאיזה הקשר.
תיעוד זה הוא נכס אדיר ברגע של אירוע – הוא מאפשר להבין במדויק מה נחשף, ולכן גם מה צריך לדווח ולמי.
ללא תיעוד, ארגון נדרש להניח את התרחיש החמור ביותר ולדווח בהיקף נרחב, מה שמגדיל את החשיפה התדמיתית והרגולטורית.
גיבוי, שחזור וזכות המחיקה בשירותי מחשוב לארגונים עם דרישות GDPR
אחת הסוגיות המורכבות ביותר ב-GDPR היא "הזכות להישכח" (Right to Erasure, סעיף 17 לתקנה).
לפי סעיף זה, נושא המידע יכול לבקש מחיקה של כל המידע האישי שלו, והארגון חייב להיענות תוך 30 יום, אלא אם יש בסיס חוקי אחר לשמירה.
ההתנגשות המוכרת היא בין הצורך לשמור גיבויים ארוכי טווח לבין הצורך למחוק מידע מסוים על פי דרישה.
איך מוחקים אדם בודד מגיבוי בן שלוש שנים בלי לפגוע באלפי רשומות אחרות?
הפתרון אינו פשוט ודורש תכנון אדריכלי:
אסטרטגיית גיבוי 3-2-1-1
שלוש עותקות של המידע, על שני מדיות שונות, אחת מהן מחוץ לאתר, ולפחות אחת מבודדת לחלוטין (Immutable Backup).
ארכיטקטורת הגיבוי שלנו מחוות השרתים הפרטית בראשון לציון מבוססת על עיקרון זה ומותאמת לדרישות הרגולציה.
החשיבות של עותק מבודד עלתה משמעותית בשנים האחרונות בעקבות גל מתקפות הכופר.
תוקפים מתקדמים יודעים לחפש קודם את מערכות הגיבוי, להצפין אותן ורק אחר כך לפנות למערכות הפרודקציה – כך שהארגון מוצא את עצמו בלי דרך לשחזר.
עותק מבודד פיזית או לוגית (Air-Gapped או Immutable) הוא הביטוח הסופי שמבטיח שיש לפחות גרסה אחת שלא ניתן לפגוע בה גם בתרחיש הקטסטרופלי ביותר.
רטנציה מדורגת
לא כל המידע צריך להישמר 7 שנים.
מדיניות רטנציה מובנית במערכת הגיבוי מאפשרת לכל סוג מידע מחזור חיים משלו – מידע תפעולי שוטף, מידע משפטי שצריך להישמר זמן רב, ומידע אישי של לקוחות שניתן להפוך אנונימי כעבור תקופה מסוימת.
מחיקה לוגית ופיזית
במקום למחוק רשומה בודדת מגיבוי קיים (פעולה מורכבת ולעיתים בלתי אפשרית), אנחנו ממליצים לבעלי מאגרים לתעד בקשת מחיקה במערכת ייעודית.
כאשר הגיבוי שמכיל את הרשומה מגיע לסוף הרטנציה ונמחק במהלך השוטף, הרשומה נמחקת איתו.
עד אז, הרשומה מסומנת כ"מוגנת ממחיקה לפי GDPR" ולא משוחזרת אם וכאשר יש שחזור כללי.
פסאודונימיזציה ואנונימיזציה
החלפת מזהים אישיים במזהים אקראיים (פסאודונימיזציה) מאפשרת לשמור מידע סטטיסטי ולנתח מגמות בלי לחשוף זהויות.
פעולה אנונימיזציה מלאה – שאחריה אי אפשר בשום אופן לקשר רשומה לאדם ספציפי – מוציאה את המידע מתחולת התקנה כליל.
אנונימיזציה אמיתית קשה לביצוע ממה שנדמה.
מחקרים אקדמיים בתחום הוכיחו שגם כאשר מסירים שם, מספר זהות וכתובת מאוסף נתונים, עדיין ניתן לרוב לזהות אדם מתוך שילוב של פרטים דמוגרפיים כמו מין, תאריך לידה ואזור מגורים.
לכן אנונימיזציה אמיתית דורשת טכניקות כמו K-Anonymity, Differential Privacy או הוספת רעש סטטיסטי באופן מבוקר, ולא רק הסרת שדות "מזהים" באופן נאיבי.
תרגילי שחזור (DR Drills)
היכולת לגבות איננה היכולת לשחזר.
תרגיל שחזור תקופתי שמדמה כשל אמיתי הוא הדרך היחידה לדעת שהתשתית באמת עובדת.
תרגיל איכותי מתבצע על סביבה מבודדת, מסמלץ תרחישים שונים (כופר, אסון חומרה, שגיאה אנושית), מודד את הזמן המעשי לשחזור מול היעד הרצוי (RTO), ובודק את שלמות המידע המשוחזר.
מומלץ לבצע תרגיל מקיף לפחות פעם בשנה, ותרגילים נקודתיים נוספים פעמיים בשנה לפחות.
לפי הנחיות הרשות להגנת הפרטיות בנושא העברת מידע מחוץ לגבולות המדינה, מי שמחזיק מידע על תושבי האיחוד צריך לוודא שהמנגנונים הללו פועלים גם כאשר המידע מאוחסן בענן בינלאומי.
שמירה על שלמות הגיבוי (Integrity)
גיבוי שלא ניתן לשחזר אינו גיבוי – הוא קובץ זבל שתופס מקום אחסון.
לכן בנוסף לתהליך השחזור עצמו, יש לבצע ולידציה אוטומטית של קבצי גיבוי, לחשב Hash על כל קובץ, ולוודא שלא קרה שינוי בלתי מאושר.
פלטפורמות גיבוי מודרניות מבצעות זאת אוטומטית, אך חשוב לאמת שזה אכן רץ אצלכם ולקבל דוחות תקופתיים.
ניטור ודיווח על אירועי אבטחה במסגרת GDPR
סעיף 33 לתקנה האירופית מחייב דיווח לרשות הפיקוח על אירוע אבטחת מידע שמשפיע על נושאי מידע תוך 72 שעות מרגע גילוי האירוע.
72 שעות הן זמן קצר במיוחד, ובוודאי אם הארגון לא ערוך מבעוד מועד.
כדי לעמוד בדרישה זו, צריך שתהיה תשתית ניטור פעילה, נהלים ברורים ויכולת לשתף את המידע במהירות עם הרשויות:
תשתית לוגינג מרכזית
כל המערכות, מהפיירוול ועד מערכות ה-ERP, צריכות לשלוח לוגים למרכז ניהול לוגים אחד (SIEM או פתרון דומה).
בלי לוגים מרוכזים, איתור פעולה חשודה בארגון יכול לארוך ימים, וזה זמן שאין.
זיהוי אירועים ותגובה
ה-SIEM צריך להיות מוגדר עם כללי זיהוי שמסמנים פעילות חריגה – גישה למידע רגיש מחוץ לשעות עבודה, ניסיון הורדה המונית של רשומות, או חיבור ממיקום גאוגרפי לא צפוי.
פלטפורמות מודרניות משלבות גם רכיב של למידת מכונה (UEBA – User and Entity Behavior Analytics) שמזהה אנומליות התנהגותיות גם כאשר אין כלל כתוב מראש.
לדוגמה, עובד שכרגיל מוריד עשר רשומות ביום ופתאום מוריד אלף בשעה – זה דפוס שמחייב התראה גם אם הוא מורשה טכנית לבצע את הפעולה.
לקוחותינו נהנים משירותי Help Desk פרואקטיביים שכוללים ניטור בזמן אמת ויכולת התערבות מהירה כאשר עולה אזהרה.
תהליך תגובה לאירוע (Incident Response)
מעבר לטכנולוגיה, הארגון חייב נוהל כתוב שמגדיר מי עושה מה כאשר מתרחש אירוע.
מי בודק, מי מסלים, מי מקבל החלטה לדווח, מי כותב את הדיווח, מי מוסר אותו לרשות.
נוהל IR (Incident Response) טוב כולל לפחות חמישה שלבים: זיהוי האירוע, בלימה ראשונית, חקירה והערכת היקף, מיגור ותיקון, ושלב הלקחים שלאחר האירוע.
לכל שלב צריך להיות בעלים, זמני יעד מוגדרים וכלים זמינים.
ארגונים שאינם תרגלו את הנוהל פעם בשנה לפחות, יגלו בערוץ הקרב שהנוהל "על הנייר" לא תואם את המציאות התפעולית, וזה בדיוק הרגע הלא נכון לגלות זאת.
הערכת השפעה (Impact Assessment)
לא כל אירוע אבטחה מחייב דיווח לרשות הפיקוח.
התקנה דורשת לדווח אם יש סבירות גבוהה לפגיעה בזכויות וחירויות של נושאי המידע.
לכן צריך תהליך הערכה זריז שמעריך את האירוע ומחליט אם הוא חוצה את הסף.
שעון ה-72 שעות מתחיל לתקתק מרגע שהארגון מודע לאירוע, לא מרגע ההחלטה שזה אירוע מדווח, ולכן השעה הראשונה היא קריטית.
תיעוד לאחר האירוע
גם אירוע שלא דווח לרשות צריך להיות מתועד פנימית.
התיעוד כולל מה קרה, מתי, מה היו הפעולות שננקטו ומה השיעורים שנלמדו.
מסמך זה נדרש להציג בעת ביקורת מצד הרשות הפיקוחית.
תקשורת לנושאי המידע
כאשר אירוע אבטחה עלול לפגוע בזכויות וחירויות של נושאי המידע, יש חובה להודיע לא רק לרשות הפיקוח אלא גם לנושאי המידע עצמם.
ההודעה צריכה להיות בשפה ברורה ולכלול את אופי האירוע, את ההשלכות הצפויות, את האמצעים שננקטו ואת פרטי הקשר של הממונה על הגנת הפרטיות.
ניסוח של הודעת אירוע (Notification Letter) הוא משימה רגישה שמשלבת היבטים משפטיים, מקצועיים וציבוריים, וכדאי להכין תבניות מראש כדי שביום הקרב לא יהיה צורך להתחיל מאפס.
ההבדלים בין תקנות GDPR האירופיות לחוק הגנת הפרטיות הישראלי
אחת השאלות הנפוצות שאנחנו נשאלים היא: "אם אנחנו עומדים בחוק הגנת הפרטיות החדש בישראל, האם זה אומר שאנחנו עומדים גם ב-GDPR?".
התשובה היא: ברוב הדרישות הטכניות, יישום הוראות הרגולציה הישראלית מקרב אתכם מאוד למה שנדרש באירופה, אך יש פערים מהותיים שצריך להכיר.
הטבלה הבאה מסכמת את ההבדלים המרכזיים בין שתי הרגולציות בארבעה היבטים שמשפיעים על תכנון תשתית ה-IT:
| היבט | GDPR (האיחוד האירופי) | חוק הגנת הפרטיות הישראלי (אחרי תיקון 13) | השלכה תפעולית |
|---|---|---|---|
| חובת מינוי DPO | חובה לבעלי מאגרים גדולים או רגישים | חובה החל מ-2025 לפי קריטריונים מוגדרים | תפקיד ארגוני ייעודי, נפרד מתפקידי IT |
| חלון דיווח על אירוע | 72 שעות מרגע גילוי | דיווח מהיר ככל הניתן (מסגרת זמן מוגדרת) | תשתית ניטור ותגובה במצב כוננות מתמיד |
| זכות להישכח | מובנית בתקנה (סעיף 17) | הוגדרה מחדש בתיקון 13 עם תנאים | מנגנון מחיקה רוחבי בכל המערכות והגיבויים |
| העברת מידע לחו"ל | מותרת רק למדינות מורשות או במנגנונים חוזיים | דורשת תנאים והסכמים מסוימים | בחירה מושכלת של מיקום הסטוראג' בענן |
| סנקציות מקסימליות | עד 4 אחוזים מהמחזור העולמי השנתי | קנסות מנהליים משמעותיים לפי תיקון 13 | סיכון פיננסי שמצדיק השקעה בתשתית |
תיקון 13 לחוק הגנת הפרטיות אישר את החקיקה הישראלית והכניס שורה של שינויים מהותיים שמיישרים קו חלקי עם GDPR, כולל חובת מינוי ממונה הגנת פרטיות בארגונים מסוימים והגברת סמכויות אכיפה של הרשות להגנת הפרטיות.
עם זאת, ארגון ישראלי שמעבד מידע על תושבי האיחוד נדרש לקיים את שתי הרגולציות במקביל.
פתרון של שירותי DPO חיצוני הוא דרך אפקטיבית עבור ארגונים בינוניים שאינם זקוקים לתפקיד פנימי במשרה מלאה.
חשוב לציין גם את תקנות הגנת הפרטיות בנוגע למידע שהועבר מהאזור הכלכלי האירופי שנכנסו לתוקף ב-2023.
התקנות הללו מסדירות במיוחד את הטיפול במידע שמגיע מהאיחוד לישראל, וקריאה זהירה שלהן יכולה לחסוך התלבטויות רבות בעת תכנון התשתית.
ישראל זכתה במעמד של "מדינה ראויה" (Adequacy Decision) מהאיחוד האירופי, מה שמאפשר העברה חופשית של מידע ממדינות חברות לישראל ללא צורך במנגנונים חוזיים מורכבים.
זהו יתרון אסטרטגי משמעותי לחברות ישראליות שעובדות מול שותפים אירופיים, אך הוא מותנה בכך שישראל ממשיכה לעמוד בסטנדרטים שהוגדרו על ידי האיחוד – וזו אחת מהסיבות לחקיקת תיקון 13 ולשידרוג רמת ההגנה על המידע בישראל.
פגיעה במעמד זה – אם תקרה בעתיד – הייתה משבשת רבות מהפעילויות העסקיות של חברות ישראליות מול אירופה, ולכן ההשקעה בעמידה בדרישות אינה רק עניין של ארגון בודד אלא גם עניין לאומי.
בחירת ספק לשירותי מחשוב לארגונים עם דרישות GDPR
בחירת ספק שירותי מחשוב בקונטקסט של GDPR אינה פעולה רוטינית.
לפי סעיף 28 לתקנה, בעל מאגר נותר אחראי באופן מלא גם כשהוא מפנה את העיבוד לספק חיצוני (Processor).
לכן השאלות שצריך לשאול ספק פוטנציאלי הן שאלות מהותיות, לא טכניות בלבד:
- היכן נמצאים השרתים פיזית, האם בישראל או בענן בינלאומי, ובאיזה מדינה ספציפית?
- האם הספק מסוגל לחתום על Data Processing Agreement (DPA) שעומד בדרישות סעיף 28?
- אילו תקנים בינלאומיים הספק מחזיק (ISO 27001, ISO 27701, SOC 2 Type II)?
- איך נראה תהליך הדיווח על אירוע אבטחה מהספק לארגון, וכמה זמן הוא לוקח?
- האם יש לספק יכולת טכנית למחוק מידע אישי לפי בקשה, כולל מגיבויים?
- מי נגיש למידע אצל הספק, וכיצד הוא מתעד את הגישה?
- האם הספק עובד עם קבלני משנה, ואם כן – איך מוסדרת אחריותם?
- איזה ביטוח אחריות מקצועי וביטוח סייבר הספק מחזיק?
ניסיון של שני עשורים בליווי מאות לקוחות, חוות שרתים פרטית, שותפויות ישירות עם יצרני אבטחה מובילים ומענה אנושי מקצועי הם הקריטריונים שאנחנו ב-IP מחשבים בנינו את הפעילות סביבם, וזה גם מה שאנחנו ממליצים ללקוחותינו לחפש בכל ספק שירותי IT.
מעבר לשאלות הטכניות, צריך לבחון גם את הזמינות התפעולית של הספק.
ארגון שנמצא בעיצומו של אירוע אבטחה לא יכול להמתין שעות לתשובה ממוקד שירות שמסונן באמצעות בוט אוטומטי.
SLA כתוב שמגדיר זמני תגובה במצבי חירום, ערוץ הסלמה אנושי וזמינות 24/7 לאירועי משבר הם פרמטרים שחשובים יותר ממחיר חודשי נמוך.
בנוסף, חשוב לבחון את התרבות הארגונית של הספק.
האם הוא מתפעל את עצמו לפי אותם תקנים שהוא דורש מהלקוחות, או שהוא "סנדלר ההולך יחף"?
ספק שירותי מחשוב שמייעץ ללקוחות על אבטחת מידע אך בעצמו לא עומד ב-ISO 27001, אינו מבצע סריקות פגיעות אצל עצמו ואינו מקיים תרגילי שחזור פנימיים, הוא דגל אדום שלא כדאי להתעלם ממנו.
| ⚠️זהירות, מוקש!⚠️ הסכם DPA "סטנדרטי" שספק מציג בשנייה אחרי שאתם מבקשים אינו בהכרח DPA שעומד בדרישות סעיף 28. ספקים רבים מציגים מסמך גנרי שלא מתייחס למאפיינים הספציפיים של עיבוד המידע אצלכם. דרשו תמיד DPA שמתייחס במפורש לסוגי המידע, מטרות העיבוד, משך השמירה ומיקום הסטוראג', וקראו אותו בעיון יחד עם יועץ משפטי לפני החתימה. |
הכשרת עובדים ומודעות לפרטיות – הגורם האנושי
התשתית הטכנית המתקדמת ביותר נופלת בפני עובד שאינו מודע לכללי הפרטיות.
מחקרים בתחום אבטחת המידע מצביעים שוב ושוב על כך שהגורם האנושי הוא הסיבה השכיחה ביותר לאירועי דליפת מידע, ובעולם של GDPR זה תרגום ישיר לסיכון רגולטורי משמעותי.
לכן הכשרה ומודעות הם רכיב בלתי נפרד משירותי מחשוב לארגונים עם דרישות GDPR, ולא רק "תוספת נחמדה":
הכשרה תקופתית מובנית
לפחות פעם בשנה, וברצוי פעמיים, צריך לבצע הכשרה רוחבית לכל עובדי הארגון שמכסה את העקרונות הבסיסיים של פרטיות, את הסיכונים, ואת הנהלים הפנימיים.
ההכשרה צריכה להיות תפורה לתפקיד – מכירות מקבלים תכנים אחרים ממה שמקבלים אנשי פיתוח, ושני אלה אחרים ממה שמקבלים עובדי שירות לקוחות.
סימולציות פישינג
תקיפות פישינג ממוקדות הן הדרך הנפוצה ביותר שתוקפים משיגים גישה למידע אישי.
שליחה של מיילים מבחנים פנים ארגוניים, מעקב אחרי מי לוחץ, ושיחת תיקון אישית עם מי שנכשל – כל אלה הם מנגנון לימוד מהשטח שמשפר את עמידות הארגון בפועל.
תיעוד ההכשרות
מבחינה רגולטורית, חשוב לתעד מי השתתף באיזו הכשרה, מתי, ומה הוא הציון בבדיקה שמוצגה לו בסוף.
תיעוד זה הוא חלק מהוכחת ה"אחריותיות" (Accountability) שהתקנה האירופית דורשת.
תרבות ארגונית של "Privacy by Design"
המטרה האולטימטיבית היא שכל פרויקט חדש בארגון – מערכת CRM חדשה, אתר אינטרנט מחודש, אינטגרציה עם ספק – יוצא מנקודת מוצא של פרטיות.
זה כולל ביצוע הערכת השפעה על פרטיות (DPIA) בכל פרויקט שמעבד מידע אישי בהיקף משמעותי, ובחירת ארכיטקטורה שמינימליסטית לגבי איסוף מידע מלכתחילה.
המעבר ל-Privacy by Design דורש שינוי תפיסה אצל מנהלי המוצר, ראשי הפיתוח ובעלי העניין העסקיים, ולא רק אצל אנשי IT ואבטחת מידע.
פרויקט שתוכנן ללא היבטי פרטיות יידרש לתיקונים יקרים בהמשך – לעיתים בעלות גבוהה פי עשרה מההשקעה שהייתה נדרשת אילו הוכנס השיקול מההתחלה.
ארגונים שמיישמים את העיקרון הזה בצורה מובנית, בדרך כלל גם נהנים מתוצרים טובים יותר מבחינה פונקציונלית.
תכנון מינימליסטי לגבי איסוף מידע מוביל לאפליקציות פשוטות יותר, חוויית משתמש נקייה יותר, ועומסי תפעול נמוכים יותר על מערכות התשתית.
פרטיות אינה אויב של חדשנות, אלא דווקא ממוקדת את החדשנות במה שבאמת חשוב לעסק.
תרגום פעיל של עיקרון Privacy by Design למשרה תפעולית כולל שילוב בודק פרטיות במסגרת ועדת אדריכלות, חתימת ממונה ההגנה על פרויקטים מסוימים, ושימוש בכלי תיעוד אוטומטיים שמייצרים DPIA כחלק מתהליך הפיתוח.
נקודת קשר ייעודית לבקשות נושאי מידע
נושאי המידע זכאים לפעול לפי שורת זכויות שהתקנה מעניקה להם: זכות עיון, זכות תיקון, זכות מחיקה, זכות הגבלת עיבוד, זכות לקבל את המידע בפורמט נייד וזכות התנגדות לעיבוד.
הארגון חייב לספק ערוץ נגיש, מתועד וזמין שדרכו ניתן להגיש בקשות אלה.
בפועל זה אומר טופס באתר, כתובת דוא"ל ייעודית או שילוב של השניים, יחד עם תהליך פנימי שמטפל בבקשה תוך 30 יום (עם אפשרות הארכה במקרים מורכבים).
הזנחת הערוץ הזה היא טעות נפוצה.
נושאי מידע שלא מקבלים מענה, פונים לרשות הפיקוח – וזה כמעט תמיד הטריגר לבקרה רגולטורית.
סיכום – תשתית IT שעומדת בדרישות הרגולציה
שירותי מחשוב לארגונים עם דרישות GDPR אינם פרויקט חד פעמי אלא תהליך מתמשך שמשלב טכנולוגיה, נהלים ואנשים.
ארכיטקטורה נכונה בונה את היכולת ברמה הטכנית, נהלים מסודרים מבטיחים שהתפעול עומד בכללים יום אחר יום, ותרבות ארגונית של מודעות לפרטיות שומרת על המערך לאורך זמן.
הסיכון בעמידה לא נאותה אינו רק פיננסי – הוא מוניטיני, משפטי ולעיתים אישי, שכן תיקון 13 בישראל מאפשר אכיפה גם כלפי נושאי משרה.
מנגד, ארגון שמשקיע נכון בתשתית IT עמידה נהנה מיתרון תחרותי משמעותי – יכולת לעבוד עם לקוחות אירופיים ובינלאומיים, אמון מצד שותפים, ועמידה נינוחה בביקורת רגולטורית.
אנחנו ב-IP מחשבים מלווים ארגונים במרכז הארץ, ראשון לציון וגוש דן בבניית תשתיות שעומדות בשתי הרגולציות במקביל, באמצעות חוות שרתים פרטית, פלטפורמת אבטחת מידע מתקדמת ותהליכי תפעול שמותאמים לדרישות הרגולציה.
הניסיון שצברנו עם פתרונות ERP מובילים כמו Priority, SAP ו-חשבשבת מאפשר לנו לתת מענה אינטגרטיבי שמכסה את כל מערכות המידע התפעוליות של הארגון, ולא רק את שכבת התשתית הבסיסית.
המסע לעמידה בדרישות GDPR מתחיל באבחון מקיף, ממשיך בתכנון אדריכלי מפורט, ומסתיים בהטמעה ובתחזוקה שוטפת.
זה אינו פרויקט שמסתיים, אלא פעילות שוטפת שמתעדכנת בהתאם לשינויי טכנולוגיה, רגולציה ועסק.
ליצירת קשר עם הצוות שלנו לבחינה ראשונית של תשתית ה-IT בארגונכם מול דרישות GDPR והרגולציה הישראלית, ולקבלת מפת דרכים מותאמת שתבטיח עמידה בכל הדרישות.
