גיבויים כחלק מאבטחת המידע


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

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

גיבויים משמשים גם למקרים של אסון, וירוסים, התקפת סייבר, אבל גם במקרה של מחיקה בשוגג או בזדון של מידע בארגון , לדוגמא עובד שפוטר ורוצה להסב נזק לארגון.
            
לכן יש להתכונן לשתי תרחישים אפשריים :
1. אסון שישבית כל חדר השרתים (רעידת אדמה, שריפה, מלחמה, הצפה וכו') .
2.ארוע סייבר שמשבית שרתים ומערכות מסוימות , ע"י פגיעה במסדי נתונים , קבצים וכו' .
                                 
יש כמה דרכים להתכונן לתרחישים האלה , והם צריכים להיות מותאמים לארגון , לפי גודלו , הקריטיות של המשך השימוש במערכות המחשוב (כמה זמן הארגון יכול להמשיך להתנהל ללא מחשוב) והתקציב שהוא יכול להשקיע לשם כך .
אחת הדרכים הנפוצות והיקרות היום , הם להחזיק עוד חדר מחשוב מרוחק, בדרך כלל בשכירות אצל נותן שירותי ענן , או חוות שרתים  או בסניף קיים נוסף שמורחק גאוגרפית מהאתר המרכזי .
זה נקרא 
DRP (Disaster Recovery Planning) תוכנית התאוששות עסקית .
במקרה של הקמת מערך כזה יש צורך גם לבצע בדיקות אחת לכמה חודשים של מעבר לעבודה באתר החלופי , על מנת להיות מוכנים באמת ליום הדין .
                     
גם מערך כזה מחולק לשתי סוגים :
  • active-active – שתי חדרי השרתים פעילים בו זמנית , והעומסים של הפניות לשרתים מתחלקים בין שתיהם.
  • active - passive – חדר שרתים אחד פעיל והחדר השני בהמתנה , הוא עובר להיות פעיל רק במקרה של אסון , בסוג כזה חשוב לעשות תרחישי בדיקה לוודא שבעת הצורך הכל באמת יעבוד כמתוכנן .
במקרה ואין יכולת תקציבית לתכנן DRP יש צורך לתכנן את מערך הגיבויים בצורה כזאת שיהיה גיבוי גם מחוץ לאתר , בין אם זה גיבוי לקלטות והוצאתם החוצה , ובין אם זה גיבוי לאתר מרוחק שיהיה בו התקן אחסון .
לדוגמא לסניף מרוחק של החברה או לשרות ענן , יש שרותי ענן שכמעט לא משלמים בעת הגיבוי , והתמחור הוא לפי גישה לגיבוי , כלומר משלמים רק במקרי שחזור  (לדוגמא 
amazon S3).
בנוסף יש צורך למפות את נכסי המחשוב של החברה , ולדאוג להם לגיבוי מתאים .
לדוגמא דוא"ל ,בסיסי נתונים , קבצים וכו' .
חשוב שהיה אופציה לשחזר גם ברמת פריט בודד מהדוא"ל ומבסיס נתונים אם צריך לשחזר רשומה, וכך בהתאם לכל סוג נכס מחשוב שקיים בארגון.
              
עוד שלב חשוב בתכנון , זה חלון הגיבויים , ובהתאם אליו נקדיש משאבים לפעולת הגיבוי.
ארגון שעובד 24/7 יזדקק למשאבי גיבוי גדולים , על מנת לצמצם את חלון הגיבוי (הזמן שלוקח לפעילות הגיבוי) ולהשפיע כמה שפחות על הארגון (פעולת הגיבוי יוצרת בד"כ עומס ומעטה את המערכות) .
ארגון שעובד כל יום בשעות 8-20 משאיר חלון גיבוי מספיק גדול על מנת לגבות את הארגון משעת סיום הפעילות ועד לתחילת הפעילות למחר , לכן יוכל לצמצם במשאבי הגיבוי ולגבות בחלון ארוך.
                         
בנוסף חשוב לבצע הפרדת הרשאות בגיבויים , בחלק מההתקפות סייבר התוקפים גם מנסים לשבש את הגיבויים , על מנת לגרום למותקף לשלם להם בתמורה לשחרור הקבצים .
לכן יש להקים משתמש ייעודי לגיבויים , ולתת רק למשתמש הזה גישה לאמצעי האחסון של הגיבויים.
פעולה זאת עשויה להציל את הארגון במקרה של מתקפה רחבה. 
                                   
לסיכום אין לזלזל בגיבויים , זה תעודת הביטוח להתאוששות עסקית , כמו שמשלמים על ביטוח מקיף לרכב ומקווים לא לנצל אותו , אבל חשוב מאוד שיהיה לנו ביטוח טוב בעת מקרה צורך .

במקרה של עוד שאלות בנושא ניתן לפנות בדוא"ל :
Info@cyberland.co.il


תגובות

פוסטים פופולריים מהבלוג הזה

מילון מושגים – אבטחת מידע וסייבר חלק ב

מדיה נתיקה - התקפות USB