רוב הארגונים חושבים ש״התאוששות מאירוע״ זה לשחזר קבצים. זו תפיסת עולם ישנה. בעולם של הענן, העבודה, ההרשאות והגישה למערכות יושבות על שכבה אחת שמנהלת את הכול: זהויות. אם שכבת הזהות נפגעה, כל שאר הגיבויים יכולים להיות מושלמים ועדיין תמצאו את עצמכם תקועים מול מסך כניסה.
השכבה הזאת נקראת Microsoft Entra ID, מה שנקרא בעבר Azure AD. זו הדלת של הארגון. דלת לדואר, לקבצים, ל Teams, ל SharePoint, ל CRM, לספקי שירות ולכל אפליקציית SaaS שעוברת אצלכם דרך SSO. תוקף חכם לא חייב להצפין לכם כלום. לפעמים הוא רק צריך לשבור את המפתח.
המיתוס הכי מסוכן: אם זה בענן אז זה כבר מוגן
הענן באמת חזק. הוא יציב, יתכן שהוא אפילו מאובטח יותר ממה שיש להרבה עסקים בחדר שרתים. אבל כאן מגיע המשפט שמנהל חייב לחרוט לעצמו: ספק הענן אחראי על התשתית. אתם אחראים על הנתונים ועל היכולת להתאושש. זו בדיוק המשמעות של מודל האחריות המשותפת בענן.
וזה לא נגמר בדאטה. זהויות ותצורות הן דאטה לכל דבר. רק שהן דאטה מסוג מסוכן יותר, כי הן קובעות מי יכול לראות, למחוק, להוריד, לשתף ולהתחבר.
מה Entra ID נותן לכם כברירת מחדל, ולמה זה לא מספיק
מיקרוסופט לא משאירה אתכם בלי כלום. יש יכולות התאוששות בסיסיות. אובייקטים שנמחקו יכולים להיכנס למצב מחיקה רכה ולהיות זמינים לשחזור בחלון זמן מוגבל. לפי מיקרוסופט, פריטים כאלה עוברים ל פח מחזור, נשמרים עם המאפיינים שלהם, וניתן לשחזר אותם דרך הפורטל או דרך Microsoft Graph. אבל יש מחיר: האובייקטים לא זמינים לשימוש בזמן שהם במצב מחיקה רכה, ואם הם לא משוחזרים בתוך 30 יום הם נמחקים לצמיתות.
את זה אפשר לקרוא ישירות במסמך הרשמי Recoverability best practices in Microsoft Entra ID.
עכשיו החלק שחשוב להבין: חלון של 30 יום לא מציל עסק. זה חלון שמתאים לטעות קטנה, לא לאירוע סייבר מתמשך. כופרה מודרנית יושבת בשקט, לומדת את הסביבה, ורק אז מבצעת מחיקה רחבה או שינויי תצורה שמקשים עליכם לשחזר.
שלושה תרחישים שמפילים ארגון גם כשיש לו גיבוי לקבצים
1. תוקף משיג הרשאות ואז משנה את חוקי המשחק
זה מתחיל בסיסמה שדלפה, פישינג, או כניסה דרך מכשיר לא מנוהל. התוקף מתקדם להרשאות גבוהות, ואז עושה מהלך אחד שמזכיר לכולנו למה זהות היא לב הסיפור: שינוי מדיניות גישה או הוספת הרשאות לאפליקציה זדונית. פתאום משתמשים ננעלים, או להפך, נפתחת כניסה למקומות שלא אמורים להיות פתוחים.
אם אתם רוצים להבין איך שרשרת כזו מתפתחת, זה מאמר חובה אצלנו ב 010: מ Credential Leak לפריצה מלאה: מסלול התקיפה שארגונים מפספסים.
2. מחיקה זדונית של קבוצות והרשאות שמורידה את הארגון מהאוויר
תוקף עם הרשאות, או אפילו גורם פנימי ממורמר, לא חייב להצפין. הוא פשוט מוחק קבוצות גישה, משתמשים או אובייקטים קריטיים. כן, אפשר לשחזר אובייקטים שנמחקו בחלון זמן מוגבל, למשל לפי מדריך מיקרוסופט על שחזור משתמשים שנמחקו. אבל בתפעול אמיתי, גם אם אפשר לשחזר, הזמן שבו הכול נעול הוא זמן שבו העסק מדמם כסף, שירות ומוניטין.
3. טעות אדמיניסטרטיבית קטנה שמתרגמת לכאוס גדול
התרחיש הכי נפוץ לא מתחיל בהאקר. הוא מתחיל באדמין שמנקה הרשאות, מוחק קבוצות לא בשימוש, או מסיר אפליקציה שלא זיהה נכון. ברגע שנשבר חיבור SSO או הוסרה קבוצה שעליה נשען שירות, אתם בבעיה. לרוב זה מתגלה רק כשמישהו צריך לבצע פעולה קריטית ומגלה שאין לו גישה.
כאן מגיע משפט שמציל מנהלים מצרות: אם אתם לא מתרגלים שחזור זהויות, אין לכם יכולת שחזור.
אז מה עושים בפועל: תוכנית התאוששות לזהויות, בשבעה צעדים
- מיפוי זהות. רשמו אילו מערכות תלויות ב Entra ID. דואר, קבצים, CRM, פורטלים ללקוחות, ספקים חיצוניים. ברגע שתראו את הרשימה, תבינו למה זה קריטי.
- הגדרה של יעדי התאוששות. כמה זמן אתם יכולים להיות בלי כניסה ל Microsoft 365 לפני שהעסק נעצר. זו שאלה של הנהלה, לא של IT.
- חשבונות חירום. שני חשבונות הנהלה שמוגנים בצורה מקסימלית ומנותקים ככל האפשר מהשגרה. לא משתמשים בהם ביום יום.
- צמצום הרשאות. פחות הרשאות קבועות, יותר הרשאות לפי צורך וביקורת. כל הרשאה מיותרת היא צינור לתוקף.
- ניטור שינויים. מחיקות מרובות, שינויי הרשאות, וחיבורים חדשים לאפליקציות צריכים להדליק התראה. זה בדיוק המקום שבו SOC עושה הבדל.
- גיבוי ייעודי לזהויות. כי פח מחזור לא נבנה לאירוע כופרה. הוא נבנה לטעות אנוש קטנה.
- תרגול שחזור. תרגיל קצר וקבוע שבו אתם משחזרים אובייקטים קריטיים ובודקים שהגישה חוזרת. מי שלא מודד זמן התאוששות, לא יודע מה מצב החוסן שלו.
איפה אנחנו ו-Keepit נכנסים לתמונה
אם יש משהו שאנחנו לא מוכנים לשמוע זה ״אני בענן אז זה מגובה״. בענן צריך גיבוי ייעודי ל SaaS. אבל אם כבר משקיעים בגיבוי SaaS, חייבים להסתכל גם על שכבת הזהות.
בדיוק בגלל זה בדף Keepit ב 010 שמנו דגש על גיבוי לא רק של שירותי Microsoft 365 אלא גם של Google Workspace, Salesforce ו Microsoft Dynamics 365, ובנוסף גם על גיבוי Entra ID עבור זהויות משתמשים, קבוצות והרשאות. זו לא תוספת נחמדה. זו הדרישה הבסיסית כדי ששחזור הדאטה יהיה שימושי.
יש כאן עוד שכבה שמעניינת מנהלים: הגיבוי נשמר עד 10 שנים אחורה ונשמר בשני מרכזי אחסון שונים, עם הצפנה מקצה לקצה. המשמעות היא יכולת חזרה אחורה גם כשאירוע מתגלה באיחור, וגם בסיס הרבה יותר חזק לדרישות ציות ולחקירה אחרי אירוע.
איך זה מתחבר לכופרה ולסיבה שתוקפים אוהבים למחוק גיבויים
העיקרון פשוט: תוקפים רוצים לוודא שלא תוכלו להשתקם. לכן הם מחפשים את הגיבויים שלכם, מנסים למחוק או להצפין אותם, ומנסים לשבש את יכולת ההתחברות כדי להאריך את זמן ההשבתה. זו אחת הסיבות ש CISA מדגישה במדריכים שלה את הצורך בגיבויים מנותקים, מוצפנים, ובתרגול שחזור קבוע. אפשר לקרוא על זה במדריך StopRansomware של CISA.
גיבוי של זהויות הוא חלק בלתי נפרד מחוסן מול כופרה, לא בונוס.
שורה תחתונה
ב 2026 התאוששות היא שחזור שליטה, לא שחזור קבצים. אם אין לכם גיבוי לזהויות, לקבוצות ולהרשאות, אתם יכולים לגלות ביום האמת שיש לכם עותק יפה של הדאטה אבל אין מי שייכנס אליו.
רוצים לבדוק אם אתם באמת מכוסים. תתחילו מהשאלה הכי פשוטה: מה יקרה אם מחר בבוקר אין לכם כניסה ל Entra ID. אם התשובה היא ״נראה״, זה סימן שאתם צריכים לסגור פער. זו הסיבה שהמערכת שלנו היא נקודת פתיחה פרקטית, אנו מחברים בין גיבוי שירותי SaaS לבין גיבוי שכבת הזהות, בצורה שמאפשרת שחזור מהיר ומדויק.
