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

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

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

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

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

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

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

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

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

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

קובעים סדרי עדיפויות וזמני יעד

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

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

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

בונים שכבות הגנה לפני שמתרחש האירוע

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

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

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

מתעדים את מה שאי אפשר לזכור בלחץ

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

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

מגדירים נוהל תגובה לאירוע

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

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

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

מתכננים חזרה מדורגת ובטוחה

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

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

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

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

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

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

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

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