שרת קבצים שלא עולה בבוקר, חשבון Microsoft 365 שננעל בעקבות מתקפת פישינג, הצפה במשרד או תקיפת כופרה שמצפינה תיקיות משותפות – בכל אחד מהמקרים האלה השאלה אינה רק אם יש גיבוי. השאלה היא כמה זמן העסק יוכל לעבוד בלי המערכות שלו, מי יקבל החלטות תחת לחץ, ומה בדיוק יקרה בדקות ובשעות הראשונות. תוכנית התאוששות מאסון לעסק נועדה לתת תשובה מעשית לשאלות האלה, לפני שהן הופכות לאירוע תפעולי, כספי ותדמיתי.
עבור משרד עורכי דין, למשל, אובדן גישה למסמכי תיקים ולדוא"ל עלול לעכב דיון או עסקה. עבור חברת יבוא, השבתה של מערכת הזמנות יכולה לפגוע במשלוחים ובגבייה. גם עסק של 15 עובדים תלוי כיום במערכות רבות: מחשבים, ענן, קבצים, טלפוניה, גישה מרחוק, מערכות הנהלת חשבונות וספקים. לכן התאוששות מאסון אינה פרויקט טכני שמניחים במגירה. זו החלטה ניהולית על רציפות עסקית.
מה כוללת תוכנית התאוששות מאסון לעסק
תוכנית התאוששות מאסון, או DR, היא מסמך עבודה ותהליך מתוחזק שמגדירים כיצד מחזירים שירותים קריטיים לפעילות לאחר אירוע חמור. האירוע יכול להיות תקיפת סייבר, תקלה בשרת, מחיקה בשוגג, כשל אצל ספק, נזק פיזי למשרד או טעות אנוש. התוכנית מגדירה סדרי עדיפויות, בעלי תפקידים, זמני יעד, מערכות חלופיות ונהלי תקשורת.
גיבוי הוא רכיב חיוני, אך הוא אינו התוכנית כולה. גיבוי עונה על השאלה האם קיימת עותק של המידע. תוכנית התאוששות עונה גם על שאלות מורכבות יותר: האם העותק נקי מהצפנה? היכן הוא נשמר? תוך כמה זמן אפשר לשחזר אותו? מי מורשה לבצע את השחזור? האם העובדים יכולים להמשיך לעבוד מהבית אם המשרד או הרשת אינם זמינים?
גם מערכת ענן אינה פוטרת מהיערכות. Microsoft 365, למשל, מספקת זמינות גבוהה של השירות, אך אינה בהכרח מחליפה מדיניות גיבוי עצמאית לדואר, ל-OneDrive ול-SharePoint. מחיקה מכוונת או שגויה, הרשאות שנפגעו או חשבון שנפרץ עלולים להשפיע על המידע גם כאשר פלטפורמת הענן עצמה פעילה.
מתחילים מהשפעת ההשבתה, לא מהטכנולוגיה
הטעות הנפוצה היא לבחור מוצר גיבוי ורק לאחר מכן לנסות להבין מה הוא אמור להגן עליו. הסדר הנכון הפוך: קודם ממפים את הפעילות העסקית, ואז בונים את הפתרון הטכנולוגי המתאים.
אילו מערכות חייבות לחזור ראשונות
לא כל מערכת צריכה לחזור באותה מהירות. רשמו את השירותים שהשבתתם מונעת מהעסק למכור, לתת שירות, לשלם לספקים, לעמוד ברגולציה או לתקשר עם לקוחות. ברוב העסקים הרשימה כוללת דוא"ל, קבצים משותפים, מערכת הנהלת חשבונות או CRM, גישה מרחוק, טלפוניה ומערכות ייעודיות לענף.
לאחר המיפוי, מדרגים את המערכות לפי קריטיות. ייתכן שקבצי המחלקה המשפטית חייבים להיות זמינים בתוך שעה, בעוד שארכיון ישן יכול להמתין יום. הדירוג מונע מצב שבו צוות ה-IT משקיע זמן בשחזור רכיב שולי בזמן שהמערכת שמכניסה כסף עדיין מושבתת.
RTO ו-RPO בשפה עסקית
שני מדדים צריכים להופיע בכל תוכנית. RTO הוא זמן ההתאוששות המרבי שהעסק מוכן לספוג עד שמערכת חוזרת לפעול. RPO הוא כמות המידע המרבית שמקובל לאבד, הנמדדת בזמן.
אם ה-RTO של מערכת ההזמנות הוא שעתיים, פתרון שמאפשר שחזור רק למחרת אינו מתאים, גם אם הוא זול. אם ה-RPO הוא 15 דקות, גיבוי לילי משאיר חשיפה ליום עבודה שלם. אין מספר נכון לכולם: משרד קטן יכול לבחור RTO של ארבע שעות למערכת מסוימת, בעוד חברה פיננסית תידרש לזמני התאוששות קצרים יותר. ההחלטה צריכה לשקף את עלות ההשבתה, את חובות השירות ואת רגישות המידע.
בונים שכבות הגנה שאפשר באמת לשחזר מהן
תשתית התאוששות טובה משלבת כמה שכבות, ולא נשענת על דיסק אחד במשרד או על חשבון ענן יחיד. העיקרון המקובל הוא לשמור כמה עותקים של המידע, על סוגי מדיה שונים, כאשר לפחות עותק אחד נמצא מחוץ לאתר ומוגן מפני שינוי או מחיקה.
בפועל, זה עשוי לכלול גיבוי מקומי מהיר לשחזור קבצים נפוצים, עותק מוצפן בענן או באתר מרוחק, ועותק מבודד שאינו נגיש באופן שוטף מהרשת הארגונית. הבידוד משמעותי במיוחד מול כופרה: אם התוקף מגיע עם הרשאות מנהל גם למאגר הגיבוי, הוא עלול למחוק או להצפין את העותקים לפני שמתגלה התקיפה.
יש להגן לא רק על מסמכים. תוכנית מלאה בוחנת גם את תצורות השרתים, הגדרות הרשת, חשבונות והרשאות, מכונות וירטואליות, מערכות טלפוניה, תחנות קצה ומידע בענן. שחזור תיקיית קבצים אינו מספיק אם אין דרך להחזיר משתמשים לעבודה, להתחבר למערכות או לקבל שיחות מלקוחות.
בחירה בין שרת מקומי, ענן פרטי, שירותי ענן ציבורי או סביבת התאוששות חלופית תלויה בתקציב וביעדים שהוגדרו. שכפול מלא של כל השרתים לסביבה זמינה מיד יקר יותר, אך מקצר את זמן החזרה לפעילות. לעסק אחר יספיק גיבוי מנוהל ושחזור מדורג. המטרה אינה לקנות את הפתרון המורכב ביותר, אלא להתאים את רמת ההגנה למחיר האמיתי של עצירה.
המסמך שחייב לעבוד גם ב-03:00 בלילה
תוכנית טובה אינה מסתפקת בתרשים רשת או ברשימת סיסמאות. היא מתארת פעולה ברורה: מי מזהה אירוע, מי מוסמך להכריז על מצב התאוששות, מי פונה לספקים, מי מעדכן עובדים ולקוחות, ומי מאשר שהמערכת חזרה לפעילות תקינה.
המסמך צריך להכיל פרטי קשר עדכניים של בעלי תפקידים וספקים, סדר שחזור של המערכות, הוראות גישה למאגרי הגיבוי, תלות בין שירותים, ותבניות קצרות לתקשורת פנימית וחיצונית. לדוגמה, לפני שחזור שרת קבצים יש לוודא שמערך הזהויות, הגישה מרחוק והגדרות הרשת זמינים. אחרת, השרת עשוי לפעול אך המשתמשים לא יוכלו להשתמש בו.
כדאי להגדיר גם נקודות החלטה. בתקיפת כופרה, למשל, לא ממהרים להחזיר מידע לפני שמבודדים את מקור החדירה ובודקים שהגיבוי נקי. שחזור מהיר מדי לסביבה שנשארה נגועה עלול להחזיר את התקיפה יחד עם הנתונים. במקרים כאלה, אבטחת מידע והתאוששות מאסון חייבות לפעול יחד.
בדיקות התאוששות: המקום שבו מתגלה הפער בין הבטחה למציאות
גיבוי שלא נבדק הוא הנחה, לא תוכנית. בדיקת התאוששות תקופתית מאמתת שהמידע אכן קיים, שההרשאות נשמרו, שהזמן הנדרש עומד ביעד, ושאנשי הקשר יודעים מה תפקידם.
לא כל בדיקה מחייבת השבתה של העסק. אפשר להתחיל בשחזור מדגמי של קבצים, דואר או תיקייה בענן לסביבה מבודדת. בהמשך נכון לבצע תרגיל רחב יותר: לדמות אובדן שרת, להחזיר מערכת חלופית ולבדוק עם משתמשים אמיתיים אם אפשר לבצע פעולות עסקיות קריטיות. תרגיל כזה חושף לעיתים פרטים קטנים עם השפעה גדולה, כמו סיסמה חסרה, רישיון שלא חודש, תלות במחשב פיזי או מספר טלפון של ספק שאינו מעודכן.
תדירות הבדיקות תלויה בקצב השינויים. עסק שעבר מיגרציה ל-Microsoft 365, החליף מערכת ERP או פתח סניף חדש צריך לעדכן ולבדוק את התוכנית מיד לאחר השינוי. גם החלפת עובד מפתח או שינוי בהרשאות מחייבים בחינה מחדש. תוכנית מלפני שנתיים שאינה משקפת את סביבת העבודה ההיברידית של היום עלולה להכשיל את ההתאוששות דווקא כשנדרשת פעולה מהירה.
טעויות שמאריכות השבתות
הטעות הראשונה היא להסתמך על אדם אחד שמכיר את כל הסיסמאות והשרתים. חופשה, מחלה או עזיבה הופכות אותו לנקודת כשל. הידע צריך להיות מתועד, מנוהל ומוגן כך שבעלי הרשאה יוכלו להשתמש בו בעת הצורך.
טעות שנייה היא להתמקד רק בשרתים ולשכוח שירותי ענן, מחשבי עובדים ומכשירים ניידים. טעות שלישית היא להניח שספק הגיבוי מטפל אוטומטית בכל תרחיש. יש להבהיר מראש מה כלול בשירות: ניטור גיבויים, זמן תגובה, סיוע בשחזור, זמינות מחוץ לשעות העבודה ואחריות על תרגול התוכנית.
טעות נוספת היא לא למדוד את העלות. שעה של השבתה אינה רק עלות של אנשי IT. היא כוללת עובדים שאינם יכולים לעבוד, לקוחות שממתינים, עסקאות שמתעכבות, פגיעה באמון ולעיתים גם הפרת התחייבויות חוזיות. כשמחשבים את העלות הזו, קל יותר לקבל החלטה מאוזנת על רמת ההשקעה הנדרשת.
תוכנית מנוהלת שומרת על מוכנות לאורך זמן
תוכנית התאוששות דורשת תחזוקה רציפה: ניטור שהגיבויים מסתיימים בהצלחה, בדיקת נפחי אחסון, עדכון לאחר שינוי תשתית, תיעוד של משתמשים חדשים ובדיקות שחזור. ללא בעלות ברורה, משימות אלה נדחקות בדרך כלל מפני הדחוף של היומיום.
ספק IT מנוהל יכול לקחת אחריות על שכבת המוכנות הזו במסגרת SLA מוגדר: ניטור, טיפול בתקלות גיבוי, תיעוד, תרגול וליווי בעת אירוע. ב-Cloud360 הגישה היא לחבר בין הגיבוי, אבטחת המידע, הענן והתמיכה השוטפת, כדי שלא יהיה פער בין מי שמכיר את התשתית לבין מי שנדרש להחזיר אותה לפעולה.
היעד אינו להבטיח שלא יתרחש אירוע. אין הבטחה כזו. היעד הוא שהעסק ידע בדיוק מה לעשות כשמתרחש אירוע, יחזיר את המערכות הנכונות לפי סדר עדיפויות, וימשיך לשרת לקוחות גם תחת לחץ. זו מוכנות שמעניקה להנהלה שליטה – ולצוותים את היכולת להתמקד בעבודה במקום בניחושים.
