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

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

מהי מוכנות לאסון בפועל?

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

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

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

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

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

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

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

גיבוי קיים אינו בהכרח גיבוי שניתן לשחזר

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

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

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

בדקו את נקודות הכשל שאינן שרתים

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

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

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

תרגיל קצר חושף פערים גדולים

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

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

תרחישים נוספים שכדאי לבדוק לאורך השנה כוללים:

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

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

האנשים וההרשאות הם חלק מתוכנית ההתאוששות

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

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

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

מדדים שמראים אם המוכנות משתפרת

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

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

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

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