" נשרפו שרתי משרד המשפטים; נזק עצום נגרם לעבודת משרד המשפטים ושלוחותיו ", The-Marker, 12.11.2008

כולנו משוכנעים שלנו זה לא יקרה !

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

אז מה בדיוק קרה במשרד המשפטים ?

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

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

אבל מה היה שונה בין חברת אפל למשרד המשפטים?

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

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

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

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

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

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

פעילות זו מכונה BCP – או Business Continuity Plan. זהו השלב "העסקי" בהיערכות הארגון לשעת אסון או חירום, וכוללת בדרך כלל את השלבים הבאים:

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

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

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

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

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

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

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

עם אישור תוכנית ההיערכות למצבי חירום בהנהלה, ולעיתים אף התגברות על מכשולים שונים, כגון התנגדות של אנשים שנפגעו מכך שלא נקבעו כחיוניים במיוחד, יש ליישם את התוכנית ע"י שלב המכונה DRP – או Disaster Recovery Plan.

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

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

· בחירת משרדים חליפיים בהיקף מצומצם יחסית (כולל אפשרות להפעלת חדר מחשב) שיהיו זמינים בשעת חירום – "אתר חירום".

o בד"כ אין שוכרים מקום חליפי העומד ריק בכל השנה, אלא ניתן לדוגמא להשתמש בסניף של החברה, או לשלם עבור מקום ב- time share אצל חברות המתמחות בהקצאת שטחי משרד וחדרי מחשב לחברות לעת חירום.

· רכש ציוד נדרש והפעלת אתר החירום.

· ניסוי מעבר לאתר החירום.

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

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

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

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

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

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

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

לא תמיד חייבים סכומי כסף גדולים בהיערכות לשעת אסון.

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

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

· קיום תוכנית היערכות עסקית לשעת חירום (BCP)

· התאמת תוכנית ה-BCP ליעדיו העסקיים של הארגון

· עדכון התוכנית בהתאמה לשינויים בארגון

· השקעת משאבים סבירים ביישום טכנולוגי של ההיערכות (DRP)

· הקמת אתר DRP מתאים במרחק סביר מהמשרדים הראשיים של הארגון

· שדרוג תקופתי של מערך המחשוב באתר ושמירת התאימות למערכות המחשוב קיום ועדכון מתמיד של נהלי תפעול וניהול מתאימים למערך ה- DRP

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

· ביצוע ניסויים תקופתיים בהיקף סביר לווידוא פעילות תקינה של המערכות באתר החירום

· הפקת לקחים בעקבות הניסויים, ועדכון תוכניות החירום עפ"י הלקחים.

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

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

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