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