העסק עבר לענן? מודל האחריות המשותפת שרוב העסקים לא מכירים

השיחה חוזרת על עצמה כמעט מילה במילה. בעל עסק מספר בגאווה שהעביר הכול לענן — Microsoft 365 למיילים ולמסמכים, מערכת CRM בענן, גיבוי אוטומטי, הכול אצל הענקים. ואז מגיעה השאלה: ״ומי אחראי על האבטחה?״. התשובה, כמעט תמיד, זהה: ״הם. זה אצל מיקרוסופט / גוגל / אמזון — הם ענקי טכנולוגיה, הם מטפלים בזה״. זו בדיוק ההנחה שגרמה לחלק ניכר מדליפות המידע הגדולות בעשור האחרון. הענן אכן פותר בעיות אבטחה רבות שהיו לכם בחדר השרתים — אבל הוא לא מעביר אליכם אחריות, הוא מחלק אותה. והחלק שנשאר אצלכם הוא בדיוק החלק שבו מתרחשות רוב הפריצות. במאמר הזה נפרק את מודל האחריות המשותפת (Shared Responsibility Model) כפי שהוא מוגדר במסמכים הרשמיים של אמזון, מיקרוסופט וגוגל — ונתרגם אותו למה שהוא אומר בפועל לעסק ישראלי קטן-בינוני שעובד בענן.

הקו האדום זז לפי סוג השירות: IaaS, PaaS, SaaS

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

• IaaS (תשתית כשירות) — אתם שוכרים שרתים וירטואליים ורשת גולמית (למשל Amazon EC2, Azure Virtual Machines). הספק מאבטח את מרכז הנתונים, החומרה ושכבת הווירטואליזציה (Hypervisor). אתם אחראים על מערכת ההפעלה של השרת ועדכוני האבטחה שלה, הגדרות הרשת והפיירוול, האפליקציות, הזהויות והנתונים. זו נקודת האחריות הגבוהה ביותר עבור הלקוח.
• PaaS (פלטפורמה כשירות) — אתם מריצים אפליקציות בלי לנהל שרתים או מערכות הפעלה (למשל Azure App Service, בסיסי נתונים מנוהלים). הספק מטפל במערכת ההפעלה ובתשתית; אתם עדיין אחראים על קוד האפליקציה והגדרותיה, ניהול הזהויות וההרשאות, והנתונים. חלק מבקרות הרשת הופכות ל״משותפות״.
• SaaS (תוכנה כשירות) — אתם משתמשים באפליקציה מוכנה (Microsoft 365, Google Workspace, מערכת CRM בענן). הספק מאבטח את כל שכבת האפליקציה, מערכת ההפעלה והרשת. אבל — וזו הנקודה הקריטית — אתם עדיין אחראים על הנתונים שלכם, על הזהויות והחשבונות, על ניהול הגישה וההרשאות, ועל הגדרות השיתוף. רוב העסקים הקטנים חיים כמעט לגמרי בעולם ה-SaaS, ובדיוק שם ההנחה ״הם מטפלים בזה״ מסוכנת ביותר.

מיקרוסופט מנסחת את זה חד וברור במסמך האחריות המשותפת הרשמי שלה: יש ארבע קטגוריות של אחריות שנשארות תמיד אצל הלקוח, ללא קשר לסוג הפריסה — הנתונים (Data), נקודות הקצה (Endpoints), החשבונות (Accounts) וניהול הגישה (Access Management). בטבלה הרשמית שלה, בעמודת ה-SaaS, שלוש שורות מסומנות במפורש כאחריות הלקוח: נתוני הלקוח, ההגדרות והתצורות, והזהויות והמשתמשים. במילים אחרות: גם כשהכול ״בענן״, הנתונים והזהויות שלכם — הם שלכם.

מה זה אומר בפועל לעסק שעובד ב-SaaS בלבד

רוב העסקים הקטנים בישראל לא מריצים שרתים משלהם בענן — הם צרכני SaaS. הדואר, המסמכים, השיתוף וההנהלת חשבונות חיים ב-Microsoft 365 או ב-Google Workspace ובעוד כמה מערכות מנוהלות. מבחינת המודל, זה ה״מקרה הקל״ — הספק לוקח על עצמו את רוב השכבות. אבל בדיוק בגלל זה קל לשכוח מה כן נשאר עליכם. הנה חמש האחריות שהמודל משאיר על שולחנכם — וכל אחת מהן היא וקטור פריצה נפוץ:

1. זהות ואימות (MFA). ניהול המשתמשים והחשבונות הוא שלכם. הפעלת אימות רב-שלבי לכל חשבון, במיוחד למנהלי המערכת, היא ההגנה הבודדת החשובה ביותר. לפי מדידה של מיקרוסופט, MFA חוסם מעל 99% ממתקפות השתלטות החשבון — הרחבנו על כך במדריך ה-MFA לעסק.
2. הרשאות וקישורי שיתוף. מי רואה מה, ומי מקבל הרשאת ניהול. ההגדרה ״כל מי שיש לו את הקישור יכול לצפות״ היא ידידותית לשיתוף — ומסוכנת: קובץ עם רשימת לקוחות שהופץ בקישור פתוח יושב זמין לכל מי שהקישור הגיע אליו, לרבות מנועי חיפוש.
3. גריעת עובדים (Offboarding). כשעובד עוזב, החשבון שלו לא מתבטל מעצמו. חשבון פעיל של עובד לשעבר — עם גישה למייל, לקבצים ולקישורי שיתוף — הוא דלת פתוחה. הפכנו את זה לצ׳קליסט עזיבת עובד מסודר.
4. גיבוי הנתונים שלכם. זו ההפתעה לרוב העסקים: הספק לא מגבה עבורכם את הנתונים לטווח ארוך. מיקרוסופט כותבת בהסכם השירות שלה במפורש: ״אנו ממליצים שתגבו באופן קבוע את התוכן והנתונים שלכם״. סל המיחזור מוגבל בזמן ואינו תחליף לגיבוי. הפתרון הוא גיבוי צד-שלישי עצמאי, לפי אסטרטגיית 3-2-1.
5. סקירת הגדרות ותצורה. ברירות המחדל של השירות אינן בהכרח המאובטחות ביותר. מדיניות שיתוף חיצוני, כללי העברת דואר אוטומטית, אפליקציות צד-שלישי שקיבלו הרשאות — כל אלה הגדרות שאתם, ולא הספק, אחראים לסקור ולהקשיח.

התבנית הקלאסית: פריצות ״הענן״ שהן בעצם טעות הגדרה

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

אלה אינם מקרי קצה. לפי דוח Verizon DBIR 2025 — שניתח מעל 12,000 פרצות מאומתות — מעורבות של צד שלישי בפרצות הוכפלה תוך שנה ל-30%, בין היתר בשל סביבות SaaS שהוגדרו לא נכון והיעדר הגדרות מאובטחות כברירת מחדל. הדוח מנסח את זה בחדות: ״הענן מקל על סקיילינג — אבל גם מקל על הגדרה שגויה, והתוקפים סומכים על זה״. במקביל, גרסת 2026 של אותו דוח מצאה שהגורם האנושי מעורב ב-62% מהפרצות. המשותף לכל אלה: לא נדרשה כאן פריצה מתוחכמת לתשתית של הספק — הספיקה טעות אנוש בצד שנמצא, לפי המודל, באחריותכם.

הזהות היא הגבול החדש

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

השכבה הישראלית: ספק הענן הוא ״מחזיק״ לפי תיקון 13

מעבר לאחריות הטכנית, לענן יש שכבת אחריות רגולטורית שעסקים ישראליים חייבים להכיר. כשאתם מעלים לענן מידע אישי על לקוחות או עובדים, ספק הענן הופך למעשה למחזיק (Processor) של המידע מטעמכם — בעוד שאתם, העסק, נותרים הבעלים (Controller) ונושאים באחריות המשפטית העליונה עליו. תיקון 13 לחוק הגנת הפרטיות, שנכנס לתוקף ב-14 באוגוסט 2025, מחדד את זה: אם מחזיק (ספק) מפר את החוק והבעלים אינו פועל להפסקת ההפרה, ניתן להטיל את אותו עיצום כספי גם על הבעלים. כלומר — הענן לא ״מוריד מכם״ את האחריות על המידע, הוא מוסיף לכם צד שצריך לפקח עליו.

בפועל זה אומר שני דברים. ראשית, נדרש הסכם עיבוד מידע מסודר מול הספק, שמגדיר מה מותר לו לעשות במידע, אילו אמצעי אבטחה הוא מפעיל, ומה קורה באירוע. שנית, יש לשים לב למיקום המידע ולהעברתו לחו״ל: מרבית ספקי הענן מאחסנים מידע מחוץ לישראל, והעברת מידע אישי אל מחוץ לגבולות המדינה כפופה לתקנות העברת המידע. את מלוא הצ׳קליסט לחוזה מול AWS, גוגל או ספק SaaS ישראלי ריכזנו במאמר נפרד — ספקי ענן אחרי תיקון 13.

היגיינת ענן: סקירה רבעונית של 30 דקות

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

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

השורה התחתונה

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

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