מה מצב הגיבוי בארגון שלכם? 9 שאלות של כל CIO צריך לשאול השבוע

תמונה: pexels

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

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

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

1. אסטרטגיית גיבוי לפי צורכי הארגון

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

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

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

 2. תקינות הגיבויים

– האם הגיבויים נבדקים באופן קבוע והם ניתנים לשחזור בפועל?
– האם קיימת מדיניות ברורה לגבי כמות עותקים, באילו מיקומים ובאיזה פורמט?
– האם אנו שומרים גם עותק בלתי ניתן לשינוי (Immutable)?

כדי להבטיח שהגיבויים אכן שמישים ברגע האמת, מומלץ ליישם את אסטרטגיית 3-2-1-1-0: שלושה עותקים של כל נתון חשוב (המקור ועוד שני עותקי גיבוי), בשני סוגי מדיה שונים (למשל, דיסק וענן), עותק אחד מחוץ לאתר, עותק נוסף שהוא בלתי ניתן לשינוי (Immutable) או מבודד (Air Gap), ולבסוף – אפס שגיאות, כלומר ביצוע בדיקות שחזור תקופתיות שמוכיחות שהנתונים אכן ניתנים לשחזור תקין ומלא.

3. גישה לגיבויים

– מי יכול לגשת לגיבויים ובאילו שעות?
– האם קיימת בקרת גישה לפי עקרון "המינימום ההכרחי" (Least Privilege)?
– האם קיימת מדיניות Zero Trust על מערכות הגיבוי?

כדי לצמצם סיכוני גישה לא מורשית יש ליישם את גישת Least Privilege ולהשתמש באימות דו-שלבי (MFA) עבור כל ממשקי הגיבוי, כולל API. חשוב להפריד תפקידים (Separation of Duties) כך שמי שמבצע גיבויים לא יוכל למחוק אותם, וליישם גישה מבוקרת ומדודה כמו Just-in-Time Access, עם ניטור של כל Session ניהולי.

4. הצפנת הגיבויים

– האם כל הגיבויים מוצפנים גם במעבר (in transit) וגם באחסון (at rest)?
– מי מחזיק את מפתחות ההצפנה והאם הם נשמרים בנפרד?
– האם יש תמיכה ב-Bring Your Own Key (BYOK) או HSM?

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

כל עדכוני ה-IT, תשתית וטכנולוגיה בערוץ הטלגרם של ITtime

5. הרשאות למחיקה ושכתוב גיבויים

– האם כל משתמש בעל גישה יכול גם למחוק גיבויים?
– האם יש הגנה מפני מחיקה זדונית או שגויה?
– האם מופעל Object Lock או  Immutable Snapshots

כדי להגן על הגיבויים מפני מחיקה שגויה או זדונית, מומלץ להפעיל מנגנון Object Lock או Immutable Backup לתקופה של 90–180 ימים לפחות. כל מחיקה צריכה לדרוש אימות כפול ואישור נוסף, ויש לתעד כל פעולה במערכת Auditing ברמת הקובץ והמדיניות.

6. הפרדת רשת (Network Segmentation)

– האם שרת הגיבוי מחובר לרשת הייצור כל הזמן?
– האם יש הפרדה פיזית או לוגית (VLAN / Firewall) בין סביבת ייצור לגיבוי?
– האם תוקף שיקבל הרשאות אדמין ל־AD יכול "לראות" את הגיבויים ?

שרת הגיבוי צריך להיות מבודד מהרשת הארגונית – באמצעות Air Gap, אזור Firewalled עם גישה חד-כיוונית בלבד, או חיבור דרך jump server מאובטח. גישה לסביבת הגיבוי צריכה להיעשות באופן מוגבל ומבוקר, למשל באמצעות תהליכי סנכרון חד-צדדי כמו rsync במצב Pull.

תמונה: pexels

7. MDR / SIEM ניטור והגנה לגיבויים

– האם יש חיבור של סביבת הגיבוי ל־SIEM או מערכת  MDR?
– האם נשלחות התראות על גישה חריגה, שינוי מדיניות או נפח חשוד?
– האם יש חתימת התנהגות להצפנה שקטה או מחיקה?

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

8. תרגול DRP (Disaster Recovery Plan)

– האם נערך תרגול שחזור רבעוני או חצי שנתי?
– האם ניתן לשחזר ללא תלות בדומיין, DNS או גישה לרשת הראשית?
– האם קיימת סביבת DR Sandbox לבדיקה?

יש לבצע תרגול תקופתי לשחזור – לפחות פעם ברבעון – כולל Black-Start Test שלא תלוי בייצור. יש לתעד את כל תהליך השחזור, כולל זמני RTO/RPO, ולשלב בתרגול גם צוותים לא-טכניים כמו משפטי, תקשורת והנהלה. סביבת DR Sandbox תאפשר בדיקות בטוחות מבלי להשפיע על המערכות הפעילות.

9. חוקי DLP לגיבויים

– האם המשתמש שמגבה את הנתונים יכול גם לשלוף אותם החוצה?
– האם קיימים חוקים המונעים העתקת גיבויים ל־USB/FTP/שירותי אחסון ענן אישי?
– האם מבוצעת בדיקת מידע אישי או רגיש בגיבוי, מידע פיננסי?

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

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

אתר DR (Disaster Recovery) הוא אתר חלופי – מקומי או בענן – המאפשר המשכיות ורציפות עסקית במקרה של כשל באתר הראשי. עד היום החזיקו בו בעיקר ארגונים קריטיים כמו בנקים, חברות ביטוח, גופי ממשל וספקי שירותי ליבה, שזקוקים לזמינות גבוהה וליכולת התאוששות מהירה, אך בשנים האחרונות השירות הונגש גם בעלויות נמוכות אפילו לחברות SMB. עלות האתר נגזרת מדרישות ה־RTO (תוך כמה זמן חייבים לחזור לפעילות), RPO (כמה מידע ניתן לאבד), סוג האתר (חם, קר או היברידי), היקף המערכות המוגנות, התשתיות הנדרשות ורישיונות התוכנה שצריך לשכפל.

מאי גרין הוא ראש תחום סייבר יזמקו פרו המספקת שירותי אבטחת מידע ו-IT לעסקים