אסטרטגיית גיבוי
אסטרטגיית גיבוי עמידה היא קו ההגנה האחרון מפני אובדן נתונים הנגרם מתוכנות כופר, כשלי חומרה, אסונות טבע, טעויות אנוש, השחתת נתונים או התקפות זדוניות ההורסות מערכות ייצור - ללא גיבויים נאותים, אירוע שניתן היה לפתור באמצעות שחזור של מספר שעות עלול להפוך לאובדן קבוע של נתונים קריטיים, להשבתה של ימים או שבועות, ובסופו של דבר אף לקריסת העסק. כלל היסוד 3-2-1 (3 עותקים של הנתונים, ב-2 סוגי מדיה שונים, עם עותק אחד מחוץ לאתר) נותר תקף אך יש להרחיבו לסביבות מודרניות באמצעות מושגים כגון גיבוי בלתי ניתן לשינוי להגנה מפני תוכנות כופר (גיבויים שלא ניתן למחוק או לשנות אפילו על ידי מנהלי מערכת במהלך תקופת השמירה), בדיקות שחזור סדירות כדי לוודא שהגיבויים אכן פועלים בעת הצורך (ארגונים רבים מגלים שהגיבויים שלהם פגומים רק כשהם זקוקים להם בחירום), הגדרה ברורה של RPO (Recovery Point Objective - כמה נתונים אנו יכולים לאבד, נמדד בזמן מאז הגיבוי האחרון) ו-RTO (Recovery Time Objective - כמה זמן אנו יכולים להישאר מנותקים עד לשחזור המערכת), הפרדת אישורי הגיבוי מהדומיין הראשי כדי למנוע ממתקיף שפורץ ל-Active Directory להשמיד גם את כל הגיבויים, ואוטומציה של תהליכי הגיבוי עם ניטור והתראות כדי להבטיח שהגיבויים מתבצעים כמצופה. טעות נפוצה היא להתייחס לגיבוי כאל "set and forget" - גיבויים דורשים תשומת לב מתמשכת, אימות, עדכון נהלים ככל שהתשתית מתפתחת, ובעיקר: תרבות ארגונית המעריכה את הגנת הנתונים באותה מידה כמו פיתוח features חדשים.
כלל 3-2-1: יסודות היתירות
כלל 3-2-1 קובע שעליכם לשמור 3 עותקים של הנתונים שלכם (ייצור + 2 גיבויים), ב-2 סוגי מדיית אחסון שונים, עם עותק אחד מחוץ לאתר המופרד גאוגרפית. לדוגמה: נתוני ייצור על SAN (Storage Area Network), גיבוי ראשי על NAS (Network Attached Storage) באותו datacenter, וגיבוי משני על cloud storage (S3, Azure Blob) באזור שונה. גיוון המדיה מגן מפני כשלים ספציפיים לטכנולוגיה - אם כל הגיבויים שלכם על קלטות מגנטיות ואתם מגלים שה-tape drive הפסיק לעבוד, ייתכן שלא תוכלו לשחזר גם אם יש לכם את הקלטות. העותק מחוץ לאתר מגן מפני אסונות מקומיים (שריפה, הצפה, גניבה, התקפה פיזית על ה-datacenter) - אם כל הגיבויים נמצאים באותו בניין שנשרף, איבדתם הכל. ההתפתחות המודרנית של 3-2-1 היא 3-2-1-1-0: 3 עותקים, 2 מדיה, 1 מחוץ לאתר, 1 בלתי ניתן לשינוי, 0 שגיאות (מאומת על ידי בדיקות שחזור). ליישום: הגדירו את תוכנת הגיבוי (Veeam, Commvault, Bacula, Acronis, AWS Backup, Azure Backup) ליצירת snapshots יומיים של המערכות הקריטיות, שכפלו את הגיבויים הללו לאחסון מקומי (עותק ראשון), שלחו עותק לענן (עותק שני מחוץ לאתר), וסמנו את עותקי הענן כבלתי ניתנים לשינוי באמצעות Object Lock (S3) או Immutable Blobs (Azure). חשבו את האחסון הנדרש בהתבסס על: גודל הנתונים × תקופת השמירה × קצב השינוי - אם יש לכם 10TB של נתונים, אתם רוצים לשמור גיבויים למשך 30 יום, ו-10% מהנתונים משתנים מדי יום, תזדקקו לכ-10TB + (10TB × 0.1 × 30) = 40TB של אחסון לגיבויים. השתמשו ב-deduplication ובדחיסה כדי להפחית עלויות, אך היזהרו מ-crypto ransomware שעלול לגרום לנתונים להיראות אקראיים ולהפחית את יעילות ה-dedupe.
גיבוי בלתי ניתן לשינוי נגד תוכנות כופר
תוכנות כופר מודרניות אינן רק מצפינות נתוני ייצור אלא מחפשות ומשמידות באופן פעיל גיבויים כדי למקסם את הלחץ על הקורבן לשלם את הכופר - תוקפים משתמשים באישורים מנהליים שנפרצו כדי למחוק snapshots, להשבית שירותי גיבוי, להשחית backup catalogs, ואף להצפין את הגיבויים עצמם. גיבוי בלתי ניתן לשינוי (הנקרא גם WORM - Write Once Read Many, או air-gapped backup) מונע זאת בכך שהוא הופך את הגיבויים לבלתי אפשריים למחיקה או שינוי במהלך ה-retention period המוגדר, אפילו על ידי מנהלי מערכת עם הרשאות מקסימליות. יישומים: AWS S3 Object Lock במצב Compliance (אפילו ה-root account אינו יכול למחוק אובייקטים לפני ה-expiration date), Azure Blob Immutable Storage עם legal hold או time-based retention policies, גיבויי קלטות המוסרים פיזית ונשמרים ב-vault מחוץ לאתר, ו-backup appliances עם WORM mode (Dell EMC Data Domain, Cohesity). הגדירו retention period מתאים - בדרך כלל 30-90 ימים בהתאם ל-RPO שלכם ולמשך הזמן שעליכם לשמור גרסאות היסטוריות. חשוב: אי-שינוי מונע מחיקה אך אינו מונע יצירת גיבויים פגומים חדשים - אם תוקף פורץ למערכת במשך שבועות לפני הפעלת תוכנת הכופר, הגיבויים הבלתי ניתנים לשינוי שלכם עלולים להכיל נתונים נגועים מראש. פתרון: שמרו גרסאות מרובות של גיבויים (לא רק את האחרון), השתמשו ב-backup validation המזהה חריגות בנתונים (עלייה פתאומית באנטרופיה עשויה להעיד על encryption), ושקלו "air gap" פיזי שבו הגיבויים מועתקים מעת לעת לאחסון המנותק לחלוטין מהרשת. בדקו באופן סדיר את השחזור של גיבויים בלתי ניתנים לשינוי משום שבמערכות מסוימות יש bugs שבהם אי-השינוי מונע אפילו legitimate restore operations.
בדיקות שחזור ואימות
גיבוי שלא נבדק הוא גיבוי שאינו אמין - ישנם מקרים מתועדים רבים של חברות שביצעו גיבויים בקפדנות במשך שנים וגילו במהלך disaster recovery שהגיבויים פגומים, התצורה שגויה, המדיה התדרדרה, או שתהליך השחזור פשוט לא עבד. יישמו תוכנית רשמית של backup testing: שחזור מלא של הייצור בסביבת בדיקה מדי חודש (full system restore), שחזור של VMs/מסדי נתונים קריטיים מדי שבוע (partial restore), ואימות של backup job logs מדי יום (לוודא שהגיבויים הושלמו ללא שגיאות). הפכו את הבדיקות לאוטומטיות באמצעות scripts אשר: מתחילים שחזור בסביבה מבודדת, מאמתים את שלמות הנתונים המשוחזרים (checksums, database consistency checks), מודדים את זמן השחזור (מאמת אם אתם יכולים לעמוד ב-RTO), ומפיקים reports עם מדדים. עבור מסדי נתונים, השתמשו ב-backup restore validation של ה-DBMS עצמו: SQL Server RESTORE VERIFYONLY, MySQL mysqlcheck, PostgreSQL pg_restore --list. עבור גיבויי אפליקציות, שחזרו והריצו smoke tests אוטומטיים המאמתים פונקציונליות קריטית. תעדו כל בדיקה: תאריך, מערכות שנבדקו, תוצאה (הצלחה/כישלון), זמן שחלף, בעיות שנמצאו, ופעולות מתקנות. התייחסו לכשלים ב-restore tests כאל P0 incidents - אם בדיקת גיבוי נכשלת, הניחו שאין לכם גיבוי תקין עד לתיקון. שקלו לבצע "surprise restore drills" שבהם אתם מודיעים לצוות ללא התראה מוקדמת שעליהם לשחזר את מערכת X תוך Y שעות, תוך הדמיית חירום אמיתי. בנוסף לאימות הגיבויים, תרגילים אלה מאמנים את הצוות בנהלי recovery ומזהים gaps בתיעוד או באוטומציה.
RPO ו-RTO: הגדרת יעדי Recovery
RPO (Recovery Point Objective) הוא כמות הנתונים המרבית שאתם יכולים לאבד, נמדדת בזמן - אם ה-RPO שלכם הוא 4 שעות, עליכם לבצע גיבויים לפחות כל 4 שעות, ובמקרה של אסון אתם עלולים לאבד עד 4 שעות של עסקאות. RTO (Recovery Time Objective) הוא הזמן המרבי שמערכת יכולה להיות מנותקת עד לשחזורה - אם ה-RTO שלכם הוא שעתיים, יש לכם שעתיים מרגע זיהוי האירוע ועד שהמערכת תהיה תפעולית שוב. RPO ו-RTO חייבים להיות מוגדרים על פי business requirements (כמה נתונים אבודים וכמה downtime העסק סובל) והם מכתיבים את ארכיטקטורת הגיבוי: אפליקציות tier-1 קריטיות עשויות לדרוש RPO=0 (אפס אובדן נתונים באמצעות שכפול סינכרוני) ו-RTO של דקות (high availability cluster), אפליקציות tier-2 עשויות לסבול RPO=1h (גיבויים אינקרמנטליים שעתיים) ו-RTO=4h, אפליקציות tier-3 עשויות להיות בעלות RPO=24h (גיבויים ליליים) ו-RTO=8h. חשבו עלות מול סיכון: RPO קטן יותר דורש גיבויים תכופים יותר (יותר אחסון, יותר overhead של ביצועים), RTO קטן יותר דורש מערכות recovery מתוחכמות יותר (hot standby, automated failover). דוגמה לארכיטקטורה עבור tiers שונים: Tier-1 (ERP, Payment Processing) - שכפול סינכרוני ל-DR site + snapshots של 15 דקות + גיבוי יומי בלתי ניתן לשינוי, RPO קטן מ-15 דקות, RTO קטן מ-1h; Tier-2 (CRM, Email) - גיבויים אינקרמנטליים של 1h + גיבוי full יומי, RPO=1h, RTO=4h; Tier-3 (File Shares, Logs) - גיבוי יומי, RPO=24h, RTO=8h. תעדו RPO/RTO עבור כל מערכת ב-Disaster Recovery Plan, השיגו sign-off מ-business stakeholders (כדי להבטיח התאמת ציפיות), ונטרו אם אתם יכולים לעמוד ביעדים שהוגדרו (עקבו אחר actual recovery times באירועים).
הפרדת אישורי גיבוי
מתקיף שפורץ ל-Active Directory עם הרשאות Domain Admin עשוי לגשת ולהשמיד את כל הגיבויים אם ה-backup system משתמש באישורים מאותו AD - זהו וקטור נפוץ בהתקפות תוכנות כופר שבהן התוקף תחילה מבסס persistence ב-AD, לאחר מכן ממפה את כל תשתית הגיבוי, ולבסוף משמיד את הגיבויים לפני הפעלת ה-encryption. הפחיתו זאת באמצעות הפרדת אישורים: צרו דומיין נפרד או workgroup standalone עבור ה-backup infrastructure, השתמשו ב-service accounts מקומיים במקום ב-domain accounts במידת האפשר, הגדירו backup appliances עם אימות עצמאי משלהם בלתי תלוי ב-AD, יישמו MFA לגישה ל-backup console ולאחסון, והשתמשו ב-API keys עם הרשאות מוגבלות עבור גיבויי ענן במקום אישורים בעלי גישה רחבה. עבור סביבות Veeam, יישמו "hardened Linux repository" שבו ה-backup server הוא Linux (מחוץ ל-AD של Windows) הנגיש רק דרך SSH עם key-based auth וללא אפשרות למחיקת גיבויים דרך ה-Veeam console (immutability enforced ברמת ה-Linux filesystem). עבור גיבויי AWS, השתמשו ב-cross-account backup vault שבו הגיבויים נשלחים ל-AWS account נפרד הנשלט על ידי צוות אחר עם אישורים שאינם משותפים, והגדירו Vault Lock כדי למנוע מחיקה. יישמו את עקרון ה-least privilege: החשבון שמבצע גיבויים זקוק רק ל-read access בייצור ול-write access ב-backup destination, אינו זקוק ל-delete permissions. נטרו גישות ל-backup infrastructure כאל high-value targets - כל ניסיון גישה מחוץ לשעות הגיבוי או מ-IPs בלתי צפויים צריך לייצר התראת אבטחה. במקרים קיצוניים, שקלו "offline backup admin" שבו אישורי הניהול של הגיבויים אינם קיימים בצורה דיגיטלית - הם מאוחסנים ב-vault פיזי ונגישים רק במצבי חירום.