מאת עידן צברי · יועץ אבטחת מידע והגנת פרטיות · מומחה תיקון 13
קישור שיתוף שאינו מוגבל למשתמשים מורשים עלול לחשוף מידע אישי רגיש גם בארגון שמחזיק במערכות אבטחה מתקדמות ובהסמכת ISO 27001. כדי למנוע זאת, לא מספיק להגן על השרתים ועל תחנות העבודה. צריך לשלוט בהרשאות השיתוף, בהוצאת מידע ממערכות עסקיות, בגישה של גורמים חיצוניים וביכולת לזהות חריגות.
ב־8 באוקטובר 2026 פרסמה הרשות להגנת הפרטיות את ממצאי הפיקוח בעניין משרד החינוך, בעקבות חשיפת מידע אישי ורפואי של כ־21,000 תלמידי חינוך מיוחד.
מדובר במקרה שממחיש בעיה שאני חושב שארגונים רבים עדיין לא מקדישים לה מספיק תשומת לב.
אפשר להשקיע ב־Firewall, במערכות EDR, בגיבויים ובמבדקי חדירה, ובאותו זמן לאפשר לעובד לשתף קובץ רגיש באמצעות קישור שכל מי שמקבל אותו יכול לפתוח.
מבחינת הארגון, זו פעולה של שיתוף מידע.
מבחינת אבטחת מידע, זו עשויה להיות חשיפה של מאגר שלם.
מה מצאה הרשות להגנת הפרטיות במשרד החינוך?
על פי הודעת הרשות מ־8 באוקטובר 2026, מידע אישי ורגיש שהופק ממערכת של משרד החינוך לצורך שיבוץ תלמידים היה נגיש לגורמים בלתי מורשים באמצעות קישור פתוח.
המידע כלל שמות, מספרי תעודות זהות, תאריכי לידה, אזורי מגורים, מוסדות לימוד, השתייכות דתית ומידע רפואי על מוגבלויות של תלמידי חינוך מיוחד.
המידע דלף והופץ.
במסגרת הפיקוח נמצאו כמה ליקויים משמעותיים.
המידע הועבר ללא אמצעי הצפנה מתאימים וללא הגבלת גישה לקבצים. בנוסף, נמצא שהמידע הופק מהמערכת על ידי עובדת שלא נכללה ברשימת בעלי ההרשאות התקפות.
הרשות מצאה גם כי במועד הרלוונטי לא היו בידי המשרד מסמך הגדרות מאגר ונוהל אבטחת מידע העומדים בדרישות התקנות, וכי לא בוצע סקר סיכוני אבטחת מידע למערכת כנדרש.
בסיום ההליך קבעה הרשות כי משרד החינוך הפר את סעיף 17 לחוק הגנת הפרטיות וכן הוראות בתקנות הגנת הפרטיות (אבטחת מידע), הנוגעות בין היתר לניהול הרשאות, סקר סיכונים, ניהול מערכות והעברת מידע ברשת. [מקור]
חשוב לדייק: האירוע והליך הפיקוח החלו לפני כניסת תיקון 13 לתוקף. לכן אין להציג את המקרה כאילו מדובר בעיצום כספי חדש שהוטל מכוח תיקון 13.
החשיבות שלו היא בקביעות המקצועיות והרגולטוריות שפורסמו כעת.
לא צריך האקר כדי שיתרחש אירוע אבטחה חמור
זו בעיניי אחת הנקודות החשובות ביותר בהחלטת הרשות.
כשמנהלים שומעים את הביטוי “אירוע סייבר”, הם בדרך כלל חושבים על תוקף חיצוני.
מישהו שפרץ לשרת, גנב סיסמה, ניצל חולשה או החדיר נוזקה.
אבל דליפת מידע יכולה להתרחש גם בלי אף אחת מהפעולות האלה.
עובד מורשה יכול לייצא מידע ממערכת עסקית. קובץ יכול לעבור לתיקיית ענן לצורך עבודה משותפת. הרשאת השיתוף יכולה להיפתח בטעות לכל מי שמחזיק בקישור.
מאותו רגע, ייתכן שהמידע נגיש לאנשים שאין להם הרשאה לקבל אותו.
הרשות הבהירה בהחלטתה שהשימוש במידע והעברתו ללא הרשאה עשויים להוות אירוע אבטחה חמור, גם כאשר לא מדובר במתקפת סייבר. [מקור]
המשמעות ברורה: לא כל אירוע אבטחת מידע מתחיל בפריצה, ולא כל אירוע חמור יפעיל את מערכות ההגנה המסורתיות.
לכן ארגון שמודד את רמת ההגנה שלו רק לפי מספר ניסיונות התקיפה שנחסמו, מפספס חלק משמעותי מהסיכון.
הבעיה האמיתית בקישורים פתוחים
מה המשמעות של Anyone with the Link?
במערכות שיתוף קבצים כמו SharePoint ו־OneDrive קיימות אפשרויות שונות להגדרת הרשאות.
לדוגמה, אפשר לאפשר גישה למשתמשים מסוימים בלבד, למשתמשים בתוך הארגון או לכל אדם המחזיק בקישור.
האפשרות האחרונה מוכרת בשם Anyone with the Link.
כאשר האפשרות מופעלת, מי שמחזיק בקישור יכול לגשת לתוכן ללא הזדהות, בהתאם להגדרות ולתוקף הקישור.
Microsoft מסבירה במפורש שקישור מסוג זה ניתן להעברה לאנשים נוספים, ושלא ניתן לזהות באופן אישי את כל מי שניגש באמצעותו כפי שניתן לזהות משתמשים מאומתים. [מקור]
חשוב גם להבחין בין שני מצבים: יצירת קישור פתוח אינה הופכת בהכרח את הקובץ לזמין במנועי חיפוש. עם זאת, מרגע שהקישור מגיע לאדם בלתי מורשה, הוא עשוי לאפשר גישה לתוכן ללא אימות זהות.
דוגמה פשוטה מארגון עסקי
נניח שמנהלת כספים צריכה להעביר לרואה חשבון חיצוני קובץ הכולל פרטי עובדים ושכר.
היא שומרת אותו ב־OneDrive, לוחצת על Share ומעתיקה קישור.
אם הגדרת ברירת המחדל מאפשרת גישה לכל מי שמחזיק בקישור, הקובץ עלול להיות זמין גם למי שאליו יועבר הקישור בהמשך.
היא אולי התכוונה לשתף את הקובץ עם אדם אחד בלבד.
אבל ההרשאה שהוגדרה אינה בהכרח משקפת את הכוונה.
הפתרון אינו להפסיק להשתמש בענן.
הפתרון הוא לוודא שהשיתוף מתבצע עם זהות מוגדרת, הרשאה מתאימה ובקרה על משך הגישה.
האם הצפנה פותרת את בעיית השיתוף?
לא בהכרח.
צריך להבחין בין הצפנה לבין בקרת גישה.
הצפנה מגינה על המידע בהקשרים שונים, למשל בעת העברתו ברשת או בעת אחסונו.
בקרת גישה קובעת מי רשאי לראות את המידע ומה הוא יכול לעשות איתו.
קובץ עשוי להיות מוצפן במנוחה ולהישלח באמצעות חיבור HTTPS תקין, ועדיין להיות נגיש לכל מי שמחזיק בקישור ציבורי.
זו אינה סתירה.
המערכת פשוט מאפשרת גישה משום שכך הוגדרה הרשאת השיתוף.
לכן מבחינה מקצועית חשוב לבדוק את שני הנושאים בנפרד.
הצפנה אינה מחליפה הרשאות, והרשאות אינן מחליפות הצפנה.
יש לכם ISO 27001? זה לא אומר שהנושא סגור
ממצא נוסף בהחלטת הרשות ראוי לתשומת לב מיוחדת של הנהלות ודירקטוריונים.
משרד החינוך טען כי הסמכתו לתקן ISO/IEC 27001 מאפשרת לו להסתמך על התקן במקום על דרישות מסוימות בתקנות הגנת הפרטיות.
הרשות דחתה את הטענה בנסיבות שנבדקו.
אבל חשוב להבין את ההבחנה המשפטית.
האם ISO 27001 יכול להחליף דרישות בתקנות הגנת הפרטיות?
קיימת בישראל הנחיית רשם מאגרי המידע מספר 03/2018, שפורסמה מכוח תקנה 20(ב) לתקנות הגנת הפרטיות (אבטחת מידע).
ההנחיה מאפשרת, בתנאים מסוימים, לראות בארגון שהוסמך לתקן ISO/IEC 27001 כמי שמקיים את הוראות התקנות ביחס למאגרים שעליהם חלה ההסמכה.
אולם ההכרה מותנית, בין היתר, בעמידה בבקרות הרלוונטיות ובהוראות מפורשות שנקבעו בהנחיה, לרבות דרישות מסוימות שנותרות לבדיקה עצמאית. [מקור]
כלומר, קיימת אפשרות להסדר של הכרה בתקן.
לא קיים פטור אוטומטי מעצם הצגת תעודת הסמכה.
נקודה נוספת שדורשת תשומת לב היא שההנחיה משנת 2018 מתייחסת במפורש לגרסת ISO/IEC 27001:2013, בעוד שהגרסה העדכנית של התקן היא ISO/IEC 27001:2022.
לכן ארגון שמבקש להסתמך על ההנחיה צריך לבדוק את תחולתה ואת התנאים החלים עליו, ולא להניח שמעבר לגרסת התקן החדשה יוצר אוטומטית הכרה משפטית זהה. [מקור]
מה הייתי בודק בארגון מוסמך?
ראשית, את היקף ההסמכה.
תעודת ISO 27001 אינה בהכרח מכסה כל חברה בקבוצה, כל מערכת וכל מאגר מידע.
שנית, האם קיימת התאמה מתועדת בין הבקרות שיושמו במסגרת התקן לבין דרישות הדין החלות על מאגרי המידע.
שלישית, האם הארגון מסוגל להציג ראיות ליישום הבקרות בפועל.
תעודה בתוקף היא ראיה למערכת ניהול אבטחת מידע שהוסמכה בתחום מוגדר.
היא אינה הוכחה לכך שכל הרשאה שהוגדרה במערכת הארגונית נכונה.
איך מונעים חשיפה של מידע באמצעות SharePoint ו־OneDrive?
בארגונים המשתמשים ב־Microsoft 365 קיימים מנגנונים מובנים שמאפשרים לנהל את הסיכון.
הקושי הוא שלא תמיד מגדירים אותם בהתאם לרגישות המידע ולצרכים העסקיים.
1. שינוי ברירת המחדל של שיתוף קבצים
ב־SharePoint Admin Center ניתן לקבוע את מדיניות השיתוף החיצוני ברמת הארגון.
אפשר לאפשר שיתוף עם משתמשים מזוהים בלבד, להגביל שיתוף לדומיינים מסוימים או לחסום שיתוף חיצוני במקומות שבהם הוא אינו נדרש.
למערכות שמכילות מידע רגיש הייתי מגדיר כברירת מחדל שיתוף באמצעות Specific People, כאשר שיתוף ציבורי מותר רק במקרים מאושרים ומוגדרים.
Microsoft מאפשרת להגדיר מדיניות גם ברמת האתר, בכפוף למגבלות הארגוניות. [מקור]
זו המלצה מקצועית לניהול סיכונים, ולא דרישה גורפת בתקנות להשתמש דווקא בהגדרה זו.
2. הגבלת משך הזמן שבו קישור נשאר פעיל
בארגונים רבים קיימים קישורי שיתוף שנוצרו לפני חודשים ואף שנים.
לעיתים העובד שיצר אותם כבר עזב את החברה.
Microsoft מאפשרת להגדיר תוקף לקישורים אנונימיים וכן להגביל את ההרשאות שהם מעניקים.
כך אפשר לצמצם את הסיכון שקובץ ששיתפו לצורך משימה זמנית יישאר נגיש ללא צורך. [מקור]
3. הפרדה בין הרשאת צפייה להרשאת עריכה
לא כל מי שצריך לראות מסמך חייב לקבל גם הרשאה לשנות אותו.
בעת הגדרת שיתוף כדאי לבחון האם הנמען נדרש לצפות במידע, לערוך אותו או להוריד אותו.
הגבלת הרשאות מצמצמת גם חשיפה למידע וגם סיכון לפגיעה בשלמותו.
4. סקירת קישורים והרשאות קיימות
שינוי מדיניות עתידית אינו מספיק.
צריך לבדוק גם שיתופים קיימים.
בפרט הייתי מתמקד בספריות המכילות מידע פיננסי, מסמכי עובדים, מידע רפואי, פרטי לקוחות ומסמכים משפטיים.
המטרה היא לזהות הרשאות רחבות שאינן מוצדקות מבחינה עסקית.
5. ניטור וחריגות
הגדרה נכונה של הרשאות היא רק שכבת הגנה אחת.
חשוב גם לזהות פעולות חריגות: יצוא כמויות גדולות של מידע, שיתוף מסמכים רגישים עם גורמים חיצוניים, שינויי הרשאות והורדות בהיקפים חריגים.
בחלק מסביבות Microsoft 365 ניתן לשלב יכולות Audit, DLP וסיווג מידע לצורך צמצום הסיכון, בהתאם לרישוי ולהגדרות הקיימות.
המלצה שלי היא להתחיל במיפוי ההרשאות והסיכונים, ורק לאחר מכן להחליט אילו יכולות נוספות נדרשות.
ומה לגבי Google Drive?
אותם עקרונות חלים גם על ארגונים המשתמשים ב־Google Workspace.
מנהל המערכת יכול לקבוע מדיניות לשיתוף חיצוני באמצעות הגדרות Drive and Docs ב־Google Admin Console.
ניתן להגביל שיתוף מחוץ לארגון, לשלוט באפשרויות השיתוף ולהשתמש במנגנוני בקרה נוספים בהתאם למהדורת השירות.
Google מציינת כי שיתוף חיצוני עשוי להיות חיוני לשיתוף פעולה עסקי, אך גם כרוך בסיכון לדליפת מידע. [מקור]
מבחינה ניהולית אין הבדל מהותי בין שתי הסביבות.
בשני המקרים צריך לדעת מי יכול לשתף, עם מי, איזה מידע ולכמה זמן.
הקשר לתקנות הגנת הפרטיות ולתיקון 13
תקנות הגנת הפרטיות (אבטחת מידע), התשע”ז–2017, מחייבות ארגונים שעליהם הן חלות לקיים אמצעי אבטחה בהתאם לרמת האבטחה של מאגרי המידע.
הדרישות כוללות, בהתאם לרמת המאגר ולנסיבות, ניהול הרשאות, זיהוי ואימות, תיעוד גישה, סקרי סיכונים, נהלי אבטחה ואבטחת תקשורת.
במקרה משרד החינוך, הרשות מצאה ליקויים בכמה מהתחומים האלה.
אולם אין בתקנות הוראה כללית שאוסרת באופן מוחלט להשתמש בכל קישור שיתוף ציבורי.
הבחינה צריכה להתבסס על סוג המידע, רמת האבטחה של המאגר, זהות הגורמים המורשים והיכולת להבטיח שהמידע יגיע רק למי שרשאי לקבלו.
תיקון 13, שנכנס לתוקף באוגוסט 2025, הרחיב משמעותית את סמכויות הפיקוח והאכיפה בתחום הפרטיות.
אבל החובות הבסיסיות להגנה על מידע ולניהול הרשאות לא נולדו בתיקון הזה.
הן קיימות בתקנות כבר שנים.
לכן ארגון שמטפל בנושא רק בעקבות תיקון 13 צריך להיזהר שלא להתייחס אליו כאל פרויקט רגולטורי חד־פעמי.
ניהול הרשאות ושיתוף מידע הוא תהליך שצריך להתקיים בשגרה.
מה עושים אם מתגלה קובץ רגיש ששותף בקישור פתוח?
ראשית, צריך לצמצם את החשיפה ללא דיחוי.
במקביל, חשוב לשמור את התיעוד הרלוונטי כדי להבין מה התרחש: מי יצר את השיתוף, מתי נוצר, איזה מידע היה נגיש, אילו הרשאות הוגדרו ומה ניתן ללמוד מרישומי הפעילות.
יש לבדוק גם אם הקישור הופץ לגורמים נוספים, האם בוצעה גישה למידע, ומה היקף האנשים שהמידע עליהם היה חשוף.
לא תמיד ניתן יהיה לדעת בוודאות מי פתח קישור אנונימי.
אם מדובר במידע אישי, יש להעריך האם נסיבות האירוע עומדות בהגדרת אירוע אבטחה חמור לפי התקנות והאם קמה חובת דיווח מיידית לרשות להגנת הפרטיות.
ההחלטה תלויה בנסיבות ובדרישות החלות על המאגר. לא כל יצירת קישור ציבורי מחייבת בהכרח דיווח, אך גם אין להמתין לסיום חקירה מלאה כאשר כבר מתקיימת חובת דיווח.
בשלב הזה צריכים להיות מעורבים הגורמים המתאימים בארגון, לרבות מנהל אבטחת המידע, הגורמים האחראים להגנת הפרטיות והייעוץ המשפטי בהתאם לצורך.
חמש בדיקות שהייתי מבקש לבצע כבר השבוע
| הבדיקה | מה צריך לקבל בפועל |
|---|---|
| הרשאות שיתוף | צילום או יצוא של הגדרות השיתוף ב־SharePoint, OneDrive או Google Workspace |
| קישורים ציבוריים | רשימת קבצים ותיקיות רגישים המשותפים באמצעות קישור שאינו דורש אימות |
| הרשאות חיצוניות | סקירה של משתמשים ואורחים חיצוניים בעלי גישה למידע רגיש |
| יצוא מידע | בדיקה מי רשאי להפיק דוחות ולהוציא מידע ממערכות CRM, ERP ומערכות עסקיות אחרות |
| ניטור ובקרה | דוגמה לאירוע שיתוף או שינוי הרשאות שניתן לזהות, לבדוק ולתעד |
זו אינה רשימת חובות סטטוטורית אחת המופיעה בתקנות.
זו תוכנית בדיקה מקצועית שנועדה לאתר את הסיכונים שהתגלו באירוע משרד החינוך ולבחון את היכולת של הארגון להתמודד עם תרחישים דומים.
התוצרים חשובים יותר מהצהרה כללית של ספק שהמערכת מאובטחת.
האחריות לא מסתיימת אצל מנהל ה־IT
החלטות על שיתוף מידע מתקבלות מדי יום במחלקות כספים, משאבי אנוש, מכירות, תפעול ושירות.
לעיתים הן מתקבלות בכלל במסגרת פרויקט זמני או עבודה מול ספק חיצוני.
לכן לא מספיק שמנהל ה־IT יגדיר מדיניות טכנית.
ההנהלה צריכה לקבוע איזה מידע מותר לשתף, מי רשאי לאשר חריגות, כיצד בודקים הרשאות ומי אחראי לטפל בממצאים.
מנהל אבטחת המידע צריך לתרגם את ההחלטות לבקרות ולתהליך בקרה שוטף.
במקרים הרלוונטיים, ממונה הגנת הפרטיות צריך לבחון את ההשלכות על עיבוד המידע האישי ועל חובות הארגון.
החלוקה הזאת מאפשרת לארגון להמשיך לעבוד, לשתף מידע ולשתף פעולה עם ספקים, בלי להפוך כל מסמך למקור סיכון בלתי מבוקר.
השורה התחתונה
הלקח מפרשת משרד החינוך אינו שצריך להפסיק לשתף קבצים בענן.
הוא גם לא שהסמכת ISO 27001 חסרת ערך.
הלקח הוא שאבטחת מידע אינה מסתיימת בהתקנת מערכות הגנה, בהשלמת מבדק או בקבלת תעודת הסמכה.
היא נבחנת גם בפעולות השגרתיות ביותר.
הוצאת דוח ממערכת עסקית.
שמירת קובץ בתיקייה משותפת.
שליחת קישור לספק.
הענקת הרשאת גישה לעובד זמני.
אלה פעולות קטנות שיכולות לחשוף מידע על אלפי אנשים.
לכן, לפני שרוכשים מערכת אבטחה נוספת, הייתי מציע להנהלה לשאול שאלה פשוטה:
האם אנחנו יודעים אילו קבצים רגישים בארגון שלנו נגישים היום לאנשים מחוץ לארגון, והאם הגישה הזאת באמת נדרשת?
אם אין תשובה ברורה, זו בדיקה שכדאי לבצע.
שאלות ותשובות נפוצות
האם ISO 27001 פוטר מעמידה בתקנות הגנת הפרטיות?
לא באופן אוטומטי. הנחיית רשם מאגרי המידע 03/2018 מאפשרת הכרה מותנית בהסמכה לתקן, ביחס למאגרים הרלוונטיים ובהתקיים התנאים שנקבעו בה. יש לבדוק את תחולתה ואת ההתאמה לגרסת התקן ולהוראות הדין הרלוונטיות. [מקור]
האם שיתוף קובץ באמצעות Anyone with the Link נחשב לפרצת אבטחה?
לא בהכרח. עצם קיומו של קישור ציבורי אינו מוכיח שהתרחש אירוע אבטחה. אולם כאשר הקישור מאפשר גישה למידע רגיש לגורמים בלתי מורשים, עלולה להיווצר חשיפה משמעותית המחייבת בדיקה וטיפול.
האם SharePoint ו־OneDrive בטוחים לשימוש עסקי?
כן, כאשר הם מוגדרים ומנוהלים בהתאם לצורכי הארגון. המערכות כוללות אפשרויות לשליטה בהרשאות ובשיתוף חיצוני. רמת האבטחה בפועל תלויה גם בהגדרות, בסוג המידע ובאופן השימוש. [מקור]
האם אפשר לחסום קישורים ציבוריים ב־Microsoft 365?
כן. אפשר להגביל או למנוע יצירת קישורי Anyone באמצעות הגדרות השיתוף ב־SharePoint וב־OneDrive. ניתן גם לקבוע הגדרות מחמירות יותר לאתרים מסוימים.
האם הצפנה מספיקה כדי להגן על מסמך משותף?
לא. הצפנה ובקרת גישה מטפלות בסיכונים שונים. מסמך שמועבר בערוץ מוצפן עדיין עלול להיות נגיש למי שאינו מורשה אם הרשאות השיתוף הוגדרו באופן רחב מדי.
האם אירוע אבטחה חמור מחייב מתקפת סייבר?
לא. הרשות להגנת הפרטיות הבהירה במקרה משרד החינוך שגם שימוש במידע והעברתו ללא הרשאה עשויים להוות אירוע אבטחה חמור, בהתאם לנסיבות ולהגדרת התקנות. [מקור]
האם כל ארגון חייב לבצע סקר סיכונים?
הדרישות לסקרי סיכונים לפי התקנות תלויות ברמת האבטחה של המאגר ובהוראות החלות עליו. ללא קשר לחובה המסוימת, סקר סיכונים הוא כלי מקצועי מרכזי לזיהוי פערים בניהול הרשאות, שיתוף מידע ומערכות עסקיות.
עידן צברי — יועץ אבטחת מידע והגנת פרטיות
מייסד SEC-IT, עם מעל 15 שנות ניסיון. משלב רקע משפטי (תואר במשפטים) עם ניסיון IT מבצעי ומומחיות סייבר (CISM, CISO), ומתמחה ביישום תיקון 13 והגנת פרטיות לעסקים קטנים ובינוניים. עוד על עידן ←
