
תוקפים שמגיעים למערכת לא תמיד מסתפקים בקבצי העבודה. לפעמים הם מנסים לפגוע גם בגיבויים, כדי להשאיר אתכם בלי דרך חזרה. לכן יצירת עותק היא רק חלק מהעבודה: צריך גם להגן עליו. שתי גישות מרכזיות הן גיבוי מנותק וגיבוי בלתי ניתן לשינוי, ולכל אחת יש תפקיד משלה.
הפרדה והגנה משלימות
- ניתוק מצמצם גישה
- אי־שינוי מגביל פגיעה
- הרשאות ושחזור נבדקים
Air Gap, גיבוי מנותק, ו־Immutable, גיבוי בלתי ניתן לשינוי, נועדו לצמצם פגיעה לא מורשית בעותקים. הן עושות זאת בדרכים שונות: אחת מפרידה את הגיבוי, והשנייה מגבילה שינוי ומחיקה שלו. נבחן את החוזקות והמגבלות כדי להבין איך לבחור, ומתי לשלב.
גיבוי מנותק: העותק שנשאר מחוץ לרשת
הרעיון של גיבוי מנותק פשוט: ליצור הפרדה פיזית או לוגית בין עותק הגיבוי לבין הסביבה שעלולה להיפגע. ככל שההפרדה מתאימה לתרחיש האיום, קשה יותר לתוקף להגיע לעותק דרך המערכת שנפרצה.
איך הוא עובד?
יוצרים הפרדה בין מידע הגיבוי לבין הרשת הראשית או סביבת האחסון. המקור מבחין בין שתי דרכים:
- ניתוק פיזי: ניתוק מדיית הגיבוי, למשל קלטות או כוננים חיצוניים, מכל רשת או מערכת. לעיתים מאחסנים אותם מחוץ לאתר כדי למנוע גישה מרחוק.
- הפרדה לוגית: שמירת המידע בסביבה מוגבלת שדורשת פרטי גישה או הרשאות מיוחדים. זו הפרדה וירטואלית, שממשיכה להסתמך על בקרות גישה לצורך שמירת הבידוד.
חוזקות
היתרון הבולט הוא הבידוד, במיוחד כשהמדיה מנותקת פיזית. כונן שלא מחובר לרשת אינו נגיש לתוקף דרך אותו חיבור. לפעמים דווקא הכבל שלא מחובר עושה עבודה חשובה.
ניתוק פיזי מספק גם עצמאות ממנגנוני אבטחה שמבוססים על הרשת, ולכן מפחית את החשיפה במקרה של פגיעה רחבה ברשת.
אתגרים
- מורכבות תפעולית: ניתוק פיזי דורש לעיתים טיפול ידני, הובלה ואחסון מדיה. הדבר צורך זמן ומאמץ ומוסיף אפשרות לטעות אנוש.
- יכולת גידול: ככל שנפח המידע עולה, ניהול המדיה והתחזוקה שלה יכולים להפוך למסורבלים.
- זמן התאוששות: הבאת המדיה הפיזית ושחזור ממנה עשויים להאריך את הזמן עד לחזרת הפעילות.
- איומים פנימיים בהפרדה לוגית: פרטי גישה שנגנבו או הגדרות שגויות עשויים לאפשר גישה לא מורשית.
גיבוי בלתי ניתן לשינוי: מחובר, אבל נעול
בגיבוי בלתי ניתן לשינוי, העותק יכול להישאר מחובר. ההגנה נמצאת במקום אחר: מנגנון שנאכף בשכבת האחסון מונע שינוי, דריסה או מחיקה בתקופת השימור שנקבעה. חשוב שהנעילה המתאימה תהיה מוגדרת ונאכפת כראוי.
איך הוא עובד?
טכנולוגיות בשכבת האחסון, כגון Object Lock במערכות תואמות S3, אוכפות מדיניות שמונעת שינוי בתקופה מוגדרת. מטרתן להגן גם מפני שינויים מקריים וגם מפני שינויים זדוניים.
בניגוד לניתוק פיזי, ההגנה מבוססת על תצורת האחסון ומדיניות השימור. המידע יכול להישאר בסביבה מחוברת ונגישה לשחזור.
חוזקות
- הגנה מפני שינוי בידי כופרה: המקור מדגיש שכאשר הנעילה נאכפת, גם תוקף שקיבל גישת מנהל אינו אמור לשנות או למחוק את העותק הנעול.
- גמישות ויכולת גידול: אפשר ליישם את הגישה בענן ובמערכות מקומיות, בהתאם לפתרון, ולשלב אותה בסביבות היברידיות.
- פשטות תפעולית: אכיפה אוטומטית של מדיניות השימור יכולה להפחית טיפול ידני וסיכוני טעות.
- שחזור יעיל: עותקים שנמצאים באחסון פעיל ונגיש יכולים להיות זמינים לשחזור מהר יותר ממדיה שצריך להביא ממקום אחר.
אתגרים
הנעילה טובה כמו ההגדרה והאכיפה שלה. תצורה שגויה עלולה להשאיר את המידע פגיע, ותקופת שימור ארוכה מדי עלולה להגדיל עלויות ולהחזיק מידע שכבר אין צורך לשמור. לכן בודקים גם את מנגנון ההגנה וגם את משך השימור, לא רק אם האפשרות מסומנת.
לפי המקור, בסביבות שדורשות הגנה חזקה מכופרה והתאוששות מהירה, היתרונות עשויים לעלות על האתגרים האלה.
לפני שמפעילים Object Lock: מה צריך לבדוק?
Object Lock יכול להגן על גרסת אובייקט מפני שינוי או מחיקה במשך תקופת שימור, כשהאחסון והתצורה תומכים בכך. לפני ההפעלה, בדקו מה בדיוק ננעל, מי יכול לבצע פעולות ומה קורה כשצריך לשחזר. שם התכונה הוא התחלה; ההגדרות הן אלה שעושות את העבודה.
- תמיכה ותאימות: ודאו ששירות האחסון ותוכנת הגיבוי תומכים במנגנון הנדרש ובדרך שבה אתם משתמשים בו.
- מצב הנעילה: בדקו את ההבדל בין מצבי Governance ו־Compliance כאשר הם קיימים בשירות. במצבים מסוימים אפשר להעניק הרשאות עקיפה; במצבים מחמירים יותר לא ניתן לקצר את ההגנה במהלך התקופה. יש לבדוק את ההתנהגות המדויקת בשירות ובתצורה שלכם.
- תקופת השימור: התאימו אותה לצורכי השחזור, למדיניות ולדרישות החלות על המידע. לפני נעילה ארוכה, העריכו גם את הנפח ואת העלות.
- פעולות בלתי הפיכות: בררו אילו הגדרות מותר לשנות לאחר ההפעלה ואילו עותקים לא ניתן למחוק או לשחרר לפני הזמן. אל תבנו על כפתור ״בטל״ שלא קיים.
- יכולת שחזור: בדקו שיש למורשים גישה לעותק ולמפתחות הדרושים, ושאפשר לשחזר בלי לבטל את ההגנה.
נעילה לא מחליפה הצפנה, בקרת הרשאות, אימות מתאים לחשבונות הניהול או ניטור. היא גם לא מוכיחה שהעותק נקי מנוזקה. שלבו את המנגנון בתוכנית שכוללת התראות ובדיקות שחזור, ובדקו את התצורה בסביבה מתאימה לפני שימוש בייצור.
אם הנפח גדל, ייתכן שלא ניתן יהיה לפנות עותקים נעולים מיד. לכן חשוב לתכנן קיבולת ולנטר אותה מראש. להמשך: מדריך לניטור גיבויים יומי.
מה משתנה בעבודה היומיומית?
| נושא | גיבוי מנותק | גיבוי בלתי ניתן לשינוי |
|---|---|---|
| בידוד | הפרדה פיזית או לוגית מהרשת | מניעת שינוי ומחיקה בשכבת האחסון |
| נוחות תפעול | טיפול ידני או בקרת גישה מחמירה | אוטומציה המבוססת על מדיניות |
| יכולת גידול | עשויה להיות מוגבלת בשל קיבולת ומורכבות ניהול המדיה | ניתנת להרחבה בענן ובמערכות מקומיות, בהתאם לפתרון |
| איומים פנימיים | בידוד לוגי תלוי בהגנה על הגישה | הנעילה עשויה להגן גם כאשר חשבון נפרץ, בהתאם למצב האכיפה |
| מהירות שחזור | הבאת מדיה פיזית יכולה לעכב את השחזור | אחסון פעיל יכול לאפשר גישה מהירה לעותק |
| עלות | עלות מדיה, אחסון וטיפול תפעולי | המקור מציג יתרון עלות, במיוחד בענן; העלות בפועל תלויה בנפח ובשימור |
למה המחבר מעדיף נעילה אוטומטית?
עבור ספקים שמנהלים סביבות לקוח מגוונות, המקור מציג חמישה יתרונות:
- אכיפה אוטומטית: פחות עומס תפעולי ופחות טעויות הנובעות מטיפול ידני.
- גמישות היברידית: יישום בענן ובמערכות מקומיות.
- הגנה יזומה מכופרה: נעילת הנתונים באחסון כדי להגן על העותק גם מול גישה לא מורשית.
- סיוע בעמידה בדרישות: מדיניות שימור מובנית יכולה לסייע בשמירת מידע לתקופות הדרושות.
- שחזור מהיר יותר: עותקים בסביבה פעילה מאפשרים גישה לשחזור מידע קריטי בלי להביא מדיה פיזית.
המקור טוען שהסתמכות על תהליכים ידניים, זמני שחזור ארוכים ומגבלות גידול הופכת גיבוי מנותק לפחות מעשי בחלק מסביבות ה־IT הדינמיות.
מה מתאים לסביבה שלכם?
מה עדיף? תלוי בסיכונים ובדרך שבה עובדים. מחבר המקור מעדיף גיבוי בלתי ניתן לשינוי כשחשובים גידול בנפח, השתלבות בתשתית והתאוששות מהירה לצד הגנה מכופרה. זו עמדתו, ולא הוראה לבחור באותה דרך בכל עסק.
המקור מסכם שהגישה האוטומטית יכולה לסייע בהגנה על מידע הלקוחות גם מול איומים מתפתחים.
לפני שמחליטים, שאלו מי יכול להגיע לעותק, מי יכול למחוק אותו וכמה זמן ייקח לשחזר. אפשר גם לשלב ניתוק ונעילה. הביטחון מגיע מהתכנון ומהבדיקה, לא מהשם האנגלי שעל התכונה.
נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.
מקור: Air-Gap Backups vs. Immutable Backups_ A Guide for MSPs.pdf מאת MSP360. למאמר המקורי.


