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

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

בשנת 2019, 93% מהתקפות תוכנות הכופר באמריקה הלטינית כללו מחיקת גיבויים כשלב ראשון, לפי דו"ח של ה-OEA המצוטט בCyberShield. כלל 3-2-1 — שנוסח בשנת 2005 על ידי הצלם פיטר קרוג — מניח שהתוקף אינו יכול לגשת למדיות הגיבוי. כיום, הנחה זו אינה נכונה: קבוצות כמו LockBit ו-BlackCat משתמשות באישורים גנובים כדי לגשת ל-NAS, שרתי גיבוי ואפילו לדליים של S3 עם מדיניות שמירה לא מוגדרת כראוי.

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

הספרות הקיימת מצביעה על כך ש-68% מהחברות שחוות התקפת תוכנת כופר אינן יכולות לשחזר את הנתונים שלהן במלואם, גם עם גיבויים (NIST SP 1800-25, 2020). הסיבה העיקרית: הגיבויים לא היו בלתי ניתנים לשינוי.

העדכון 3-2-1-1-0: מה משמעות כל מספר

Veeam הפכה לפופולרית בשנת 2021 את ההרחבה 3-2-1-1-0, שמוסיפה שני דרישות קריטיות:

אי-שינוי הוא השינוי המשבש ביותר. במונחים טכניים, זה אומר שהגיבוי חייב לעמוד ב:

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

כלים ליישום 3-2-1-1-0 בעסק קטן ובינוני: Restic, Borg ו-Duplicacy

כלי הגיבוי המסורתיים (כמו Veeam או Acronis) יקרים עבור חברות עם פחות מ-50 עובדים. חלופות קוד פתוח כמו Restic, Borg ו-Duplicacy מציעות הצפנה בצד הלקוח, אי-שינוי ותמיכה ביעדים מרובים, אך דורשות הגדרה ידנית. הנה פירוט טכני:

1. Restic: הסטנדרט לגיבויים מוצפנים ובלתי ניתנים לשינוי

Restic הוא בינארי יחיד שנכתב ב-Go התומך ב:

דוגמה לפקודה לגיבוי בלתי ניתן לשינוי ב-Wasabi (S3 תואם עם נעילת אובייקטים):

restic -r s3:https://s3.wasabisys.com/mi-bucket backup /datos \
  --with-lock 30d \
  --password-file /ruta/a/password.txt

הדגל --with-lock 30d מפעיל את נעילת האובייקטים למשך 30 יום, ומונע מחיקות או שינויים אפילו עם אישורים תקפים. Restic תומך גם ב-"prune" בטוח: הוא מוחק רק תמונות ישנות שאינן נעולות.

2. Borg: ניכוי כפילויות יעיל ומאגרים מוצפנים

Borg הוא התפתחות של Attic, מותאם לניכוי כפילויות. יתרונותיו:

לשם אי-שינוי עם Borg, הפתרון הוא להשתמש ביעד התומך בנעילת אובייקטים (כמו S3) ולהעלות את מאגר Borg במצב קריאה בלבד. דוגמה:

borg init --encryption=repokey /mnt/backup/repo
borg create /mnt/backup/repo::lunes-2025-04-01 /datos

לאחר מכן, סנכרון ל-S3 עם נעילת אובייקטים באמצעות rclone:

rclone sync /mnt/backup/repo s3:mi-bucket --s3-object-lock-mode governance --s3-object-lock-retain-until-date "2025-05-01"

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

3. Duplicacy: גיבויים מצטברים אמיתיים

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

דוגמה לגיבוי עם Duplicacy ל-Backblaze B2 עם נעילת אובייקטים:

duplicacy init -e mi-repo b2:mi-bucket
duplicacy set -storage mi-repo -key b2_id -value "mi-id"
duplicacy set -storage mi-repo -key b2_key -value "mi-key"
duplicacy backup -storage mi-repo -object-lock 30d

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

אסטרטגיית אי-שינוי: נעילת אובייקטים מול נתק אווירי

ישנן שתי דרכים להשיג אי-שינוי בגיבויים:

  1. נעילת אובייקטים (אי-שינוי לוגי): האחסון (כמו S3) חוסם מחיקות או שינויים למשך תקופה מוגדרת. יתרונות:
    • אינו דורש התערבות אנושית (אידיאלי לאוטומציה).
    • נתמך על ידי כלים כמו Restic ו-Duplicacy.
    • עומד בדרישות רגולציות כמו HIPAA או GDPR.
    חסרונות:
    • תלוי בספק הענן (אם הספק נפגע, ניתן לעקוף את נעילת האובייקטים).
    • עלויות נוספות עבור אחסון עם נעילת אובייקטים (למשל, Wasabi גובה $0.005/GB/חודש נוסף).
  2. נתק אווירי (אי-שינוי פיזי): הגיבוי מנותק מהרשת. יכול להיות:
    • דיסקים חיצוניים המוחלפים ידנית.
    • סרטי LTO (בשימוש על ידי 30% מהחברות באמריקה הלטינית לפי IDC, 2023).
    • שרתי גיבוי כבויים וללא חיבור לרשת.
    יתרונות:
    • חסינות מוחלטת מפני התקפות מרחוק.
    • עלות נמוכה (דיסק חיצוני של 5TB עולה כ-$100).
    חסרונות:
    • דורש משמעת תפעולית (מישהו צריך לחבר/לנתק את הדיסקים).
    • סיכון לאובדן או נזק פיזי.
    • לא ניתן להרחבה לגיבויים תכופים.

עבור עסק קטן ובינוני, ההמלצה היא לשלב את שניהם: נעילת אובייקטים לגיבויים יומיים (עם Restic או Duplicacy) ונתק אווירי לגיבויים שבועיים או חודשיים (דיסקים חיצוניים מוצפנים). צוות CyberShield אימת שגישה זו מקצרת את זמן השחזור (RTO) ב-70% בהשוואה לנעילת אובייקטים בלבד.

כיצד לוודא שהגיבויים שלך ניתנים לשחזור (כלל האפס)

ה-"0" ב-3-2-1-1-0 פירושו אפס שגיאות באימות. זה כולל:

  1. בדיקות שחזור אוטומטיות: כלים כמו Restic מאפשרים לוודא את תקינות הגיבויים עם restic check ולבדוק שחזורים עם restic restore latest --target /tmp/restore-test. מומלץ להפוך זאת לאוטומטי עם cron job שישלח התראות במקרה של כישלון.
  2. בדיקות ידניות רבעוניות: שחזור מדגם אקראי של קבצים (למשל, 10% מהנתונים) ואימות תקינותם. עבור מסדי נתונים, שחזור עותק בסביבה מבודדת ובדיקת שאילתות קריטיות.
  3. תיעוד התהליך: לכלול בתוכנית ההמשכיות העסקית (BCP) את השלבים המדויקים לשחזור, כולל:
    • מיקום מפתחות ההצפנה (לעולם לא באותו מקום עם הגיבויים!).
    • סדר השחזור (למשל, תחילה מערכת ההפעלה, לאחר מכן היישומים, ולבסוף הנתונים).
    • זמני שחזור משוערים (RTO) ונקודת שחזור (RPO).

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

דוגמה קונקרטית: יישום בעסק קטן ובינוני עם 20 עובדים

מקרה: חברת ייעוץ בפרו עם 20 עובדים, 5 שרתים (2 פיזיים, 3 בענן), ונתונים קריטיים ב-PostgreSQL וקבצים משותפים. תקציב מוגבל אך עם מנהל מערכת במשרה חלקית.

1. תשתית

2. תצורה טכנית

הכלי שנבחר: Restic (בזכות התמיכה המקורית בנעילת אובייקטים וקלות השימוש).

# התקנת Restic
sudo apt-get install restic


אתחול מאגר ב-Wasabi

export AWS_ACCESS_KEY_ID="mi-access-key"
export AWS_SECRET_ACCESS_KEY="mi-secret-key"
restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo init --repository-version 2


גיבוי יומי של /datos ו-PostgreSQL (dump)

pg_dump -U postgres -Fc mi_bd > /tmp/mi_bd.dump
restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo backup /datos /tmp/mi_bd.dump --with-lock 30d


אימות אוטומטי

restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo check
restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo restore latest --target /tmp/restore-test --include /datos/importante.txt


גיבוי שבועי לדיסק חיצוני (נתק אווירי)

restic -r /mnt/disco-externo/repo backup /datos --password-file /ruta/a/password.txt

3. עלויות

סה"כ: כ-$10/חודש + $140/שנה לחומרה. פחות מ-0.5% מתקציב ה-IT השנתי של החברה.

4. תוצאות

מסקנה: כלל 3-2-1-1-0 אינו אופציונלי ב-2025

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

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

מקורות

  1. NIST Special Publication 1800-25 (2020). Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events. URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf.
  2. Veeam (2023). 3-2-1-1-0 Backup Rule: Modern Data Protection Strategy. נייר עמדה. URL: https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html.
  3. תיעוד Restic (2024). Restic Backup Tool. URL: https://restic.readthedocs.io/en/latest/.
  4. תיעוד Borg Backup (2024). Deduplicating Archiver with Compression and Encryption. URL: https://borgbackup.readthedocs.io/en/stable/.
  5. OEA/CICTE (2019). Ciberseguridad: Riesgos, Avances y el Camino a Seguir en América Latina y el Caribe. URL: https://www.oas.org/es/sms/cicte/docs/Informe_Ciberseguridad_2019_ES.pdf.
  6. IDC (2023). Latin America Storage Market 2023–2027 Forecast. מסמך #LA49823523.
  7. Wasabi Technologies (2024). Object Lock Pricing. URL: https://wasabi.com/pricing/.
  8. מקרה ציבורי: מרפאה במקסיקו (2022). אובדן תיקים רפואיים בעקבות תוכנת כופר. דיווח ב-El Universal: https://www.eluniversal.com.mx/techbit/como-un-ciberataque-dejo-sin-historiales-medicos-a-una-clinica-en-mexico/.
  9. מקרה ציבורי: עסק קטן ובינוני בארגנטינה (2023). מחיקת גיבויים ב-Backblaze B2. דיווח ב-La Nación:

    Lecturas recomendadas

    CVEs críticas 2026: cómo priorizar parches sin saturar al equipo
    CVE

    CVEs críticas 2026: cómo priorizar parches sin saturar al equipo

    Ciberseguridad 24/7 para PYMES — agente endpoint, CVE watch, monitoreo continuo.

    Phishing y Business Email Compromise: defensa multicapa
    Ciberseguridad

    Phishing y Business Email Compromise: defensa multicapa

    Ciberseguridad 24/7 para PYMES — agente endpoint, CVE watch, monitoreo continuo.

    Auditoría cyber para PyMEs: checklist 2026 con marco regulatorio
    Compliance

    Auditoría cyber para PyMEs: checklist 2026 con marco regulatorio

    Ciberseguridad 24/7 para PYMES — agente endpoint, CVE watch, monitoreo continuo.

    IA defensiva: detección de anomalías y respuesta automática
    Ciberseguridad

    IA defensiva: detección de anomalías y respuesta automática

    Ciberseguridad 24/7 para PYMES — agente endpoint, CVE watch, monitoreo continuo.