גיבוי לעסק: המדריך לבדיקת שחזור המידע והחזרה לעבודה אחרי תקלה

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

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

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

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

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

מגדירים שני יעדים שונים

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

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

בודקים מה בדיוק נשמר ומי יכול להגיע אליו

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

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

מתרגלים בסביבה נפרדת

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

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

מגדירים מבחן הצלחה שמישהו מהעסק בודק

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

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

יום תקלה אינו הזמן לחפש את הטלפון של הספק

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

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

ממשיכים לעבוד גם בלי המערכת, אבל בלי לאבד שליטה

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

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

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

הסכם השירות צריך לענות על שאלות תפעוליות

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

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

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

מצאתם טעות או תוכן לא ראוי? דווחו לנו >>