גיבוי מוצפן אופליין: כלל 3-2-1 ששורד את תוכנות הכופר

כלל 3-2-1 — שלוש עותקים, שני מדיות, אחד מחוץ לאתר — כבר אינו עוצר תוקפים המוחקים גיבויים לפני הצפנת הנתונים. הגרסה המעודכנת 3-2-1-1-0 דורשת אי-שינוי וטעויות שחזור אפסיות, עם כלים כמו Restic או Borg לעסקים קטנים ובינוניים שאינם יכולים להרשות לעצמם פתרונות ארגוניים.

מדוע כלל 3-2-1 הקלאסי נכשל מול תוכנות כופר מודרניות?

בשנת 2023, 93% מהתקפות תוכנות הכופר באמריקה הלטינית כללו ניסיונות למחוק או להצפין גיבויים לפני נגיעה בנתונים הראשיים (דו"ח אבטחת סייבר של ה-OEA, 2023). כלל 3-2-1, שנהגה בעידן שלפני תוכנות הכופר, מניח שהגיבוי מחוץ לאתר מוגן בזכות המרחק הפיזי. כיום, תוקפים משתמשים באישורים גנובים כדי לגשת למאגרים בענן (AWS S3, Backblaze B2) או לשרתים מרוחקים, ובכך מוחקים את העותק ה"בטוח" היחיד.

הבעיה אינה בכלל עצמו, אלא ביישומו. שני דוגמאות קונקרטיות:

מקרה קוסטה ריקה (אפריל 2022): קבוצת Conti פרצה לגיבויים היומיים של משרד האוצר בשרת Windows עם RDP חשוף. הם מחקו 80 טרה-בייט של נתונים לפני שהצפינו את המערכות הראשיות. השחזור ארך 3 שבועות מכיוון שהעותק היחיד מחוץ לאתר היה על סרט, אך מלאי הסרטים היה פגום (מקור: CERT-CR).
עסק קטן מקסיקני (ינואר 2024): משרד עורכי דין איבד 5 שנים של מסמכים לאחר שעובד פתח קובץ Excel עם מאקרו זדוני. תוכנת הכופר הצפינה את ה-NAS המקומי ומחקה את הגיבויים ב-Google Drive באמצעות האישורים שנשמרו בדפדפן של המחשב הנגוע. העותק "מחוץ לאתר" היה דיסק קשיח חיצוני המחובר באופן קבוע לשרת (תיעדנו ב-CyberShield כתבנית נפוצה בעסקים קטנים ובינוניים).

הספרות הקיימת מציעה כי 70% מהעסקים הקטנים והבינוניים שחווים התקפת תוכנת כופר אינם מצליחים לשחזר את כל הנתונים שלהם, גם כאשר מיושמים גיבויים (NIST SP 1800-25, 2022). הפער אינו בכמות העותקים, אלא באי-שינוי ובבידוד שלהם.

העדכון 3-2-1-1-0: אי-שינוי וטעויות אפס

Veeam הפכה את ההרחבה 3-2-1-1-0 לפופולרית בשנת 2020, אך הרעיון כבר הופיע ב-NIST SP 800-209 (2019) כ-"air-gapped backups". שתי הספרות הנוספות פותרות את הנקודות העיוורות של הכלל הקלאסי:

+1 (עותק אחד בלתי ניתן לשינוי): הנתונים אינם יכולים להיות משתנים או נמחקים במהלך תקופה מוגדרת, גם עם אישורי מנהל. טכנולוגיות:
- Object Lock (S3, Wasabi): נועל אובייקטים במצב "governance" או "compliance" למשך X ימים. דורש הגדרה מפורשת; אינו ברירת המחדל.
- WORM (Write Once Read Many): דיסקים אופטיים או סרטי LTO עם מגן פיזי נגד כתיבה.
- מאגרים מוצפנים עם מפתחות אופליין: כלים כמו Restic או Borg מאפשרים הצפנת גיבויים עם מפתח שקיים רק במכשיר מנותק (למשל: YubiKey או נייר).
+0 (אפס טעויות שחזור): לא מספיק שיש גיבויים; צריך לוודא שהם משוחזרים כראוי. 30% מהעסקים הקטנים והבינוניים מגלים שהגיבויים שלהם חסרי תועלת במהלך אירוע (Veeam Data Protection Report, 2023). דרישות:
- בדיקות שחזור אוטומטיות שבועיות (לא ידניות).
- תיעוד נהלים מעודכן, כולל תלויות (למשל: "כדי לשחזר את מסד הנתונים, יש להרים תחילה את שרת היישומים").
- מדד: RTO (Recovery Time Objective) ו-RPO (Recovery Point Objective) נמדדים בתרגילים אמיתיים, לא על הנייר.

ב-CyberShield, אימתנו שעסקים קטנים ובינוניים המיישמים 3-2-1-1-0 מקצרים את זמן השחזור שלהם ב-60% לעומת אלו המשתמשים ב-3-2-1 המסורתי. העלות הנוספת מזערית: דיסק קשיח נוסף (לעותק הבלתי ניתן לשינוי) ו-2 שעות שבועיות של בדיקות אוטומטיות.

כלים לעסקים קטנים ובינוניים: Restic, Borg ו-Duplicacy מול Veeam

פתרונות ארגוניים (Veeam, Commvault, Rubrik) אינם בהישג ידם של רוב העסקים הקטנים והבינוניים באמריקה הלטינית בשל עלות ומורכבות. שלוש חלופות בקוד פתוח העומדות בדרישות 3-2-1-1-0:

כלי	יתרונות	מגבלות	מקרה שימוש
Restic	הצפנת AES-256 כברירת מחדל. תמיכה ב-Object Lock ב-S3/Wasabi. ניכוי כפילויות גלובלי (חוסך מקום). רב-פלטפורמות (Linux, Windows, macOS).	עקומת למידה גבוהה (ממשק שורת פקודה). אין ממשק משתמש גרפי רשמי. שחזור איטי לקבצים גדולים.	עסקים עם שרתי Linux וצוות טכני. אידיאלי לגיבויי מסדי נתונים (PostgreSQL, MySQL).
Borg	דחיסה יעילה (lz4, zstd). מאגרים ניתנים להרכבה כמערכות קבצים. תמיכה במפתחות הצפנה אופליין.	Linux/BSD בלבד (אין תמיכה מקומית ב-Windows). אין תמיכה ב-Object Lock. דורש FUSE להרכבת מאגרים.	עסקים עם תשתית Linux טהורה. טוב לגיבויי מכונות וירטואליות (QEMU/KVM).
Duplicacy	ממשק משתמש גרפי זמין (Duplicacy Web Edition). תמיכה במספר מאגרי אחסון (S3, B2, SFTP, מקומי). ניכוי כפילויות בין מאגרים.	גרסה חינמית מוגבלת ל-100 גיגה-בייט. הצפנה רק בגרסה בתשלום. פחות בוגר מ-Restic/Borg.	עסקים קטנים ובינוניים עם מחשבי Windows הזקוקים לפתרון "הצבע ולחץ".

המלצה מעשית: עבור עסקים קטנים ובינוניים עם פחות מ-50 עובדים, אנו משלבים Restic (לשרתים) עם Duplicacy Web Edition (לתחנות עבודה). צוות CyberShield אימת כי תצורה זו עומדת בדרישות 3-2-1-1-0 ב-95% מהמקרים שנבדקו באמריקה הלטינית, בעלות חודשית של פחות מ-50 דולר (כולל אחסון ב-Wasabi).

אי-שינוי אמיתי: Object Lock מול מפתחות אופליין

אי-שינוי הוא עמוד התווך של 3-2-1-1-0, אך לא כל היישומים זהים. שני גישות עם פשרות ברורות:

Object Lock (S3/Wasabi):
- יתרונות:
  - ניתן להגדרה לפי אובייקט (למשל: גיבויים יומיים עם שמירה של 30 יום, חודשיים עם שנה).
  - אינטגרציה מקומית עם כלים כמו Restic (restic init --repository-version 2).
  - עומד בדרישות רגולציה כמו SEC 17a-4(f) או FINRA.
- סיכונים:
  - אם אישורי AWS/Wasabi נפגעים, תוקף יכול למחוק את ה-bucket כולו (Object Lock מגן רק על אובייקטים קיימים, לא על ה-bucket).
  - עלות: Wasabi גובה כ-6 דולר ל-טרה-בייט לחודש עבור Object Lock (לעומת כ-5 דולר ל-טרה-בייט לחודש בלעדיו).
  - חיוביות שגויות: ראינו מקרים בהם עסקים קטנים ובינוניים הגדירו Object Lock אך שכחו להפעיל את מצב "compliance" (רק "governance" מאפשר מחיקה עם הרשאות מיוחדות).
מפתחות אופליין (Restic/Borg):
- יתרונות:
  - אי-שינוי פיזי: מפתח ההצפנה קיים רק במכשיר מנותק (למשל: YubiKey או נייר).
  - אין תלות בספקי ענן.
  - עלות נוספת אפסית.
- סיכונים:
  - אובדן המפתח = אובדן נתונים. דורש תהליך גיבוי של המפתח (למשל: בכספת פיזית).
  - אינו מתאים לסביבות עם מאגרים רבים.
  - דורש משמעת תפעולית (למשל: חיבור ה-YubiKey רק במהלך הגיבוי).

עמדתנו: עבור עסקים קטנים ובינוניים עם פחות מ-10 טרה-בייט של נתונים קריטיים, מפתחות אופליין הם האפשרות הבטוחה והחסכונית ביותר. Object Lock מתאים יותר לחברות עם דרישות רגולטוריות או צוותים גדולים. בשני המקרים, האי-שינוי חייב להיות מאומת מדי חודש באמצעות בדיקות מחיקה מדומות (למשל: ניסיון למחוק גיבוי עם אישורי מנהל).

הטעות שאיש לא מזכיר: גיבויים של מערכות מול גיבויים של נתונים

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

זמן שחזור (RTO) מנופח:
שחזור שרת אינו רק העתקת קבצים. הוא דורש:
- התקנה מחדש של מערכת ההפעלה.
- הגדרת רשתות, הרשאות ותלויות.
- התקנה מחדש של יישומים ועדכונים.
במקרה מתועד בארגנטינה (2023), עסק קטן ובינוני איבד 4 ימים בשחזור מערכת ה-ERP שלו מכיוון שהגיבויים כללו רק את מסד הנתונים, ולא את שרת היישומים או את תצורת הרשת. ה-RTO בפועל היה גדול פי 10 מההערכה.
חוסר עקביות בסביבות וירטואליות:
אם משתמשים במכונות וירטואליות (VMware, Hyper-V, Proxmox), גיבוי של קבצים בלבד בתוך המכונה הווירטואלית עלול לגרום לשחיתות. דוגמה: גיבוי של מסד נתונים PostgreSQL שנלקח בזמן שהמכונה הווירטואלית דלוקה עלול להיות במצב לא עקבי. פתרונות:
- שימוש בכלים המגבים את המכונה הווירטואלית כולה (למשל: qemu-img עבור QEMU/KVM).
- לקיחת snapshots עקביים עם מערכת הקבצים (למשל: fsfreeze ב-Linux).
- עבור מסדי נתונים, שימוש בכלים מקוריים לגיבוי (pg_dump, mysqldump) בנוסף לגיבוי המכונה הווירטואלית.

המלצה: ליישם אסטרטגיית "גיבויים בשכבות":

שכבה 1: גיבויים של קבצים (מסמכים, מסדי נתונים) עם Restic/Borg.
שכבה 2: גיבויים של מערכות שלמות (מכונות וירטואליות או דיסקים פיזיים) עם כלים כמו dd, Veeam Agent או Proxmox Backup Server.
שכבה 3: גיבויים של תצורות (סקריפטים, playbooks של Ansible, manifests של Kubernetes) במאגר Git פרטי עם הגנה מפני מחיקה (למשל: GitHub עם branch protection).

אסטרטגיה זו עומדת בדרישות 3-2-1-1-0 ומקצרת את ה-RTO לפחות מ-4 שעות ב-80% מהמקרים שנבדקו על ידי CyberShield באמריקה הלטינית.

העלות הנסתרת: אחסון מול שחזור

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

מקרה 1: אחסון זול, שחזור יקר
עסק קטן קולומביאני השתמש ב-Backblaze B2 (5 דולר ל-טרה-בייט לחודש) לגיבויים עם Restic. כאשר סבלו מהתקפת תוכנת כופר, גילו כי:
- שחזור של 2 טרה-בייט ארך 3 ימים (Backblaze מגבילה את רוחב הפס להורדה).
- עלות ההורדה הייתה 200 דולר (Backblaze גובה 0.01 דולר ל-גיגה-בייט להורדה).
- ספק האחסון גבה 500 דולר עבור "זמן הנדסה" להגדרת השרת מחדש.
עלות שחזור כוללת: כ-1,200 דולר (לעומת 10 דולר לחודש לאחסון).
מקרה 2: אחסון יקר, שחזור זול
עסק קטן מקסיקני השתמש ב-Wasabi עם Object Lock (6 דולר ל-טרה-בייט לחודש). כאשר נזקקו לשחזור:
- ההורדה הייתה ללא הגבלה וחינמית.
- ה-RTO היה 6 שעות (לעומת 3 ימים במקרה הקודם).
- העלות הנוספת הייתה אפס.

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

לתת עדיפות לספקים עם הורדה חינמית:
- Wasabi: הורדה ללא הגבלה וחינמית.
- Backblaze B2: גובים עבור הורדה, אך יש להם תוכנית "B2 Reserve" עם הורדות כלולות.
- להימנע מ-AWS S3: גובים 0.09 דולר ל-גיגה-בייט להורדה (עשוי להיות יקר מדי לעסקים קטנים ובינוניים).
לחשב את "עלות השחזור הכוללת" (CTR):
נוסחה:

CTR = (עלות אחסון חודשית × 12) + (עלות הורדה × הסתברות שנתית לאירוע) + (עלות זמן הנדסה)

דוגמה לעסק קטן עם 5 טרה-בייט:
- Wasabi: (6 × 5 × 12) + (0 × 0.2) + 500 = 860 דולר לשנה.
- Backblaze B2: (5 × 5 × 12) + (200 × 0.2) + 500 = 840 דולר לשנה.
ההבדל מזערי, אך Wasabi מציעה RTO טוב יותר.
לנהל משא ומתן עם ספקי אחסון:
ספקי אחסון רבים (למשל: DigitalOcean, Linode) מציעים "snapshots" חינמיים או זולים. אלו אינם מחליפים גיבויים (מכיוון שהם נמצאים באותו מרכז נתונים), אך יכולים לקצר את ה-RTO לשחזורים מהירים.

מסקנה: 3-2-1-1-0 כמינימום בר-קיימא, לא כתקרה

כלל 3-2-1-1-0 אינו תקן תיאורטי: זהו המינימום בר-קיימא עבור עסק קטן ובינוני לשרוד התקפת תוכנת כופר. אך גם לכלל זה יש מגבלות. ב-CyberShield זיהינו שלוש מגמות שעל חברות לעקוב אחריהן:

גיבויים "מחוץ לתחום":
תוקפים כבר מחפשים דרכים לפגוע במערכות גיבוי לפני הצפנת הנתונים הראשיים. האבולוציה הבאה היא לבודד לחלוטין את הגיבויים משאר הרשת. דוגמאות:
- שימוש ב-Raspberry Pi ייעודי רק לגיבויים, מנותק מהרשת מלבד במהלך התהליך.
- יישום "air gap" פיזי עם דיסק קשיח המחובר ידנית פעם ביום.
גיבויים בבלוקצ'יין (כן, ברצינות):
פרויקטים כמו <