מתי באמת נדרש עותק גיבוי שלישי?

שירותים הקשורים לנושא

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

העיקרון המרכזי: עותק שלישי צריך לשבור תלות

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

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

1. מתחילים מההשפעה העסקית ולא מהטכנולוגיה

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

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

2. לבדוק האם קיימת הפרדה אמיתית של Failure Domain

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

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

3. Immutability חשובה, אבל אינה תשובה מלאה לכל תרחיש

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

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

4. זהויות ניהול הן לעיתים נקודת הכשל הסמויה

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

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

5. Offsite אינו רק מרחק גיאוגרפי

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

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

6. Retention צריך להתאים גם לגילוי מאוחר

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

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

7. בלי בדיקת Restore אין הוכחה שהעותק באמת שימושי

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

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

מסגרת ההחלטה של CSP Networks

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

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

• קריטיות עסקית ו-RPO/RTO
• הפרדת אתר, חשבון ו-Failure Domain
• הפרדת זהויות ו-Management Plane
• Immutability או WORM
• Offsite או יעד עצמאי
• Retention שמכסה גם גילוי מאוחר
• בדיקות שחזור מהעותק המבודד
• Clean Recovery לפני חזרה לייצור

השורה התחתונה

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

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

להעמקה ולקבלת החלטה

• כלי החלטה: האם נדרש עותק גיבוי שלישי? - הערכה קצרה של הצורך בעותק נוסף לפי קריטיות, הפרדה, Immutability ושחזור.
• הערכת מוכנות להתאוששות מאסון - בדיקה רחבה יותר של BIA, RTO/RPO, גיבויים, DR, תפעול ותרגול.
• BIA, תוכניות BCP והתאוששות מאסון - שירות מקצועי לבחינת ארכיטקטורת התאוששות, יעדים ויכולת מימוש.

מקורות מקצועיים

• NIST SP 800-209 - Security Guidelines for Storage Infrastructure - הנחיות לאבטחת תשתיות אחסון, לרבות Data Protection, Isolation ו-Restoration Assurance.
• NIST SP 800-34 Rev. 1 - Contingency Planning Guide for Federal Information Systems - עקרונות לתכנון התאוששות, גיבוי, אחסון מחוץ לאתר ותרגול תוכניות המשכיות.
• CISA / MS-ISAC - Ransomware Guide - המלצות לשמירת גיבויים מבודדים או Offline ולבדיקות שחזור תקופתיות.