גיבויים שעומדים מול ransomware — כלל 3-2-1, אחסון שאי אפשר לשנות, ובדיקה שאפשר לשחזר

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

יש שלוש נקודות מרכזיות: להחזיק עותק אחד שמחשב נגוע לא יכול לשנות, לא להשתמש ב-“Previous Versions” במקום גיבויים, ולבדוק שאפשר באמת לשחזר. כלל 3-2-1 קובע כמה עותקים להחזיק והיכן, אבל לבדו הוא משאיר פערים כהגנה מפני ransomware.

הפקודות במאמר מיועדות ל-Windows בלבד, והפלט שלהן נבדק ב-Command Prompt עם הרשאות Administrator ב-Windows Server 2022. מסכי ההגדרות והמחירים של מוצרים עשויים להשתנות, לכן בדקו את התיעוד העדכני של כל ספק לפני ההטמעה.

לארגונים רבים היו גיבויים והם לא הצליחו לשחזר

סוכנות המשטרה הלאומית של יפן שואלת ארגונים שנפגעו מ-ransomware על מצב הגיבויים שלהם. בדוח שלה למחצית הראשונה של 2025, ל-51 מתוך 53 הארגונים שענו היו גיבויים. אבל מתוך 48 שנשאלו אם הצליחו לשחזר מהגיבוי למצב שלפני ההתקפה, רק 7 הצליחו ו-41 לא הצליחו¹.

מתוך 35 שנתנו סיבה לכך שלא הצליחו לשחזר, 23 ענו “גם הגיבויים הוצפנו”, 8 ענו “כשלים תפעוליים” ו-4 ענו “אחר”¹. אותו דוח כותב שקבוצות ransomware מוחקות את הלוגים והגיבויים של הקורבנות כדי למחוק את העקבות שלהן ולמנוע התאוששות. לאחר מכן הוא מבקש לשמור את הגיבויים בסביבה offline².

flowchart TB
        accTitle: איך יש גיבויים ועדיין אי אפשר לשחזר
        accDescr: דיאגרמה שמראה שגם אם מגבים, הגיבויים מוצפנים יחד עם כל השאר כשהמחשב הנגוע יכול להגיע אליהם, ושאם תהליך השחזור לא נבדק, כשלים תפעוליים מונעים את השחזור.
        A["מבצעים גיבויים"] --> B{"המחשב הנגוע מגיע אליהם?"}
        B -->|"מגיע"| C["מוצפנים או נמחקים גם הם"]
        B -->|"לא מגיע"| D{"תהליך השחזור נבדק?"}
        D -->|"לא נבדק"| E["אי אפשר לשחזר בגלל כשלים תפעוליים"]
        D -->|"נבדק"| F["אפשר לשחזר"]

איור 1: אפשר להשתמש בגיבויים כשהמחשב הנגוע לא מגיע אליהם ותהליך השחזור נבדק.

יש גם מקרים שבהם השחזור הצליח. מהדורה 4.0 של “הנחיות אבטחת מידע לעסקים קטנים ובינוניים” של IPA מביאה מקרה של חברת בנייה ששרתי הקבצים ומערכות אחרות שלה הוצפנו אחרי חדירה דרך התקן VPN. בין השאר מפני שהחברה קיימה תרגולי שחזור פעמיים בשנה, היא החזירה את מערכות הליבה לפעולה מהגיבויים חמישה ימים אחרי גילוי ההתקפה. ובכל זאת נדרשו 41 ימים כדי להחזיר כל אחת מהמערכות הפנימיות לפעולה וארבעה חודשים כדי להחזיר את הגישה מרחוק, והחברה איבדה קצת יותר מ-20 אחוז מהקבצים הפנימיים שלה³. היכולת לשחזר מגיבויים לא מבטלת את הנזק.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 13, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

התוקפים מוחקים את הגיבויים שהם מגיעים אליהם

מדריך ‎#StopRansomware שפרסמו CISA וגופים אמריקאיים נוספים כותב שהרבה סוגי ransomware מחפשים גיבויים נגישים כדי למחוק או להצפין אותם, כך שהקורבן לא יוכל להתאושש בלי לשלם את הכופר. לכן הוא מדגיש שחשוב לשמור את הגיבויים offline⁴.

גם Microsoft כותבת שהתוקפים מתמקדים בהשבתת תוכנות גיבוי ופיצ’רים של מערכת ההפעלה כמו Volume Shadow Copies⁵. בין הגיבויים שמחשב נגוע יכול להגיע אליהם:

• כוננים חיצוניים שמחוברים למחשב כל הזמן
• תיקיות משותפות ב-NAS או בשרת קבצים שממופות לאות כונן
• תיקיות סנכרון בענן שהחשבון היומיומי יכול לכתוב אליהן
• Shadow Copies (Previous Versions) על אותו volume

גם פקודות שמובנות במערכת ההפעלה יכולות למחוק Shadow Copies וקטלוגים של גיבויים. MITRE ATT&CK מסווג את הטכניקה הזו כ-“Inhibit System Recovery” (T1490). מופיעות שם דוגמאות כמו מחיקת כל ה-Shadow Copies עם vssadmin.exe delete shadows /all /quiet ומחיקת קטלוג הגיבויים של Windows עם wbadmin.exe delete catalog -quiet⁶. גם המדריך של CISA מבקש לנטר שימוש חשוד ב-vssadmin.exe, ב-wbadmin.exe, ב-wmic.exe (shadowcopy) ובכלים דומים⁴.

flowchart TB
        accTitle: גיבויים שמחשב נגוע מגיע אליהם ושאינו מגיע אליהם
        accDescr: דיאגרמה שמראה שמחשב נגוע יכול לכתוב לכונן חיצוני שמחובר תמיד, לתיקייה משותפת ממופה, לתיקיית סנכרון ול-Shadow Copies, אבל לא למדיה מנותקת ולא לאחסון שאי אפשר לשנות.
        P["מחשב נגוע"] --> R["מקומות שהוא יכול לכתוב אליהם"]
        P -.-x N["מדיה מנותקת, אחסון שאי אפשר לשנות"]
        R --> A["כונן חיצוני שמחובר תמיד"]
        R --> B["תיקייה משותפת ממופה"]
        R --> C["תיקיית סנכרון בענן"]
        R --> D["Shadow Copies"]

איור 2: גיבויים שנמצאים במקום שמחשב נגוע יכול לכתוב אליו הופכים למטרה של ההתקפה.

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

Previous Versions לא מחליפים גיבויים

Previous Versions של Windows ו-Shadow Copies of Shared Folders משתמשים ב-Volume Shadow Copy Service (VSS). ה-system provider של VSS שמגיע עם Windows עובד בשיטת copy-on-write: לפני שבלוק נדרס, הוא שומר את התוכן שלו באזור הבדלים (diff area), וכך משחזר את ה-volume כפי שהיה בנקודת זמן מסוימת⁷.

בתיעוד של VSS, Microsoft מסבירה את ההבדל בין Shadow Copy לגיבוי כך. כשמעתיקים נתונים מ-Shadow Copy למדיה נשלפת כמו קלטת, התוכן של המדיה הזו הוא הגיבוי. אחרי ההעתקה אפשר למחוק את ה-Shadow Copy עצמו⁷. התיעוד גם כותב שכשאזור ההבדלים מתמלא, ה-Shadow Copies הישנים ביותר נמחקים קודם⁷.

flowchart TB
        accTitle: ההבדל בין Shadow Copy לגיבוי
        accDescr: דיאגרמה שמראה ש-Shadow Copy הוא אוסף הבדלים מה-volume המקורי ונמחק כשנגמר המקום או על ידי תוקף, ואילו גיבוי שהועתק למדיה נפרדת נשאר גם אם ה-volume המקורי אבד.
        V["ה-volume המקורי"] --> S["Shadow Copy (הבדלים)"]
        S --> L["נמחקים מהישן לחדש כשנגמר המקום"]
        S --> K["תוקף מוחק עם vssadmin"]
        S -->|"העתקה למדיה נפרדת"| B["גיבוי"]
        B --> R["נשאר גם אם ה-volume המקורי אבד"]

איור 3: Shadow Copies תלויים בנתונים של ה-volume המקורי; מה שמועתק למדיה נפרדת הוא הגיבוי.

Shadow Copies נוחים כדי לאפשר למשתמשים לשחזר בעצמם קובץ שדרסו בטעות. אבל כפי שתואר בסעיף הקודם, תוקפים מוחקים אותם לפעמים. את המנגנון והתפעול אנחנו מסבירים בפירוט ב-“Volume Shadow Copy (VSS): איך זה עובד בפועל”.

כדי לראות אילו Shadow Copies נשארו, הריצו vssadmin list shadows ב-Command Prompt עם הרשאות Administrator. ה-subcommand הזה זמין גם במחשבי לקוח וגם בשרתים⁸.

vssadmin list shadows

גם היסטוריית הגרסאות וסל המיחזור ב-OneDrive וב-SharePoint הם דרך למשתמשים להחזיר קבצים. Microsoft ממליצה ללמד את המשתמשים איך לשחזר את כל ה-OneDrive לנקודת זמן מוקדמת יותר. היא גם ממליצה לאפשר להם לשחזר רק אחרי שבטוחים שהתוקף סולק, ולהיערך למקרה שבו המשתמשים ישחזרו גם את ה-malware⁵.

כלל 3-2-1 קובע כמה עותקים והיכן

כלל 3-2-1 הוא כלל אצבע לאופן שבו מחזיקים עותקי גיבוי. המסמך “Data Backup Options”, שנכתב עבור US-CERT ב-2012, מסביר אותו כך⁹.

• 3: להחזיק שלושה עותקים של קבצים חשובים, המקור ועוד שני גיבויים.
• 2: לשמור אותם על שני סוגי מדיה שונים, כדי להתגונן מפני אסונות מסוגים שונים.
• 1: להחזיק עותק אחד מחוץ לבית או למשרד.

כמקור, המסמך מציין את “The DAM Book”, ספר של הצלם Peter Krogh על ניהול תמונות דיגיטליות⁹. גם Microsoft מביאה את הכלל הזה בתיעוד שלה על גיבויים להגנה מפני ransomware, ומתארת את ה-“1” כ-“offsite or cold copy”⁵.

מה שכלל 3-2-1 דורש הוא להחזיק עותק מחוץ לאתר. הוא לא דורש שהעותק הזה יהיה offline או immutable. לכן אם העותק שמחוץ לאתר נמצא בענן שמחשב נגוע יכול תמיד לכתוב אליו, הוא עלול להיות מוצפן יחד עם העותקים המקומיים. המדריך של CISA והתיעוד של Microsoft מציינים אחסון offline כהגנה מפני ransomware. Microsoft מציינת גם אחסון שאי אפשר לשנות⁴⁵.

flowchart TB
        accTitle: כלל 3-2-1 וההגנה מפני ransomware
        accDescr: דיאגרמה שמראה הוספה של עותק offline או immutable לכלל 3-2-1, כלומר שלושה עותקים, שני סוגי מדיה ועותק אחד מחוץ לאתר, ואחר כך בדיקה שאפשר לשחזר.
        A["שלושה עותקים"] --> B["שני סוגי מדיה"]
        B --> C["אחד מחוץ לאתר"]
        C --> D["אחד offline או immutable"]
        D --> E["לבדוק שאפשר לשחזר"]

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

ספקית תוכנות הגיבוי Veeam מקדמת זאת בשם “כלל 3-2-1-1-0”. בתיעוד של Veeam, ה-“1” הנוסף פירושו להחזיק עותק אחד שהוא offline, air-gapped או immutable, וה-“0” פירושו אפס שגיאות בבדיקות שחזור קבועות¹⁰. זה שם מתיעוד של ספק, ולא תקן רשמי. ובכל זאת, שני הפריטים הנוספים חופפים למה ש-CISA ו-IPA מבקשות.

להחזיק עותק אחד שמחשב נגוע לא יכול לשנות

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

לנתק את המדיה מהמחשב ולאחסן אותה

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

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

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

להשתמש באחסון ענן שאי אפשר לשנות

לשירותי אחסון בענן יש פיצ’רים שמונעים שינוי או מחיקה של נתונים לתקופה מוגדרת. הם שומרים את הנתונים במצב שנקרא WORM (Write Once, Read Many).

ב-immutable storage של Azure Blob Storage, אחרי שמגדירים time-based retention policy, אפשר ליצור ולקרוא נתונים במהלך התקופה, אבל אי אפשר לשנות או למחוק אותם¹³. policy נוצרת קודם במצב לא נעול, ונועלים אותה אחרי בדיקה. אי אפשר למחוק policy נעולה, ואפשר להאריך את תקופת השמירה שלה אבל לא לקצר אותה¹³. Microsoft מסבירה שגם משתמשים עם הרשאות Administrator בחשבון לא יכולים לשנות או למחוק את הנתונים¹³.

ל-Object Lock של Amazon S3 יש שני מצבים. ב-compliance mode אף אחד, כולל ה-root user של חשבון ה-AWS, לא יכול לדרוס או למחוק גרסת אובייקט בתקופת השמירה. ב-governance mode רק משתמשים עם הרשאות מיוחדות יכולים לשנות או להסיר את הגדרות השמירה¹⁴. אפשר להשתמש ב-Object Lock רק ב-buckets שבהם S3 Versioning מופעל¹⁴.

flowchart TB
        accTitle: שתי דוגמאות לאחסון שאי אפשר לשנות
        accDescr: דיאגרמה שמראה שב-immutable storage של Azure Blob Storage אי אפשר למחוק policy נעולה ולא לקצר את תקופת השמירה, ושב-S3 Object Lock גם ה-root user לא יכול למחוק ב-compliance mode, ואילו ב-governance mode הרשאות מיוחדות מאפשרות שינויים.
        W["אחסון שאי אפשר לשנות"] --> AZ["immutable storage של Azure Blob Storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["אי אפשר לקצר את השמירה אחרי נעילה"]
        S3 --> C["Compliance mode"]
        S3 --> G["Governance mode"]
        C --> C1["גם ה-root user לא יכול למחוק"]
        G --> G1["הרשאות מיוחדות מאפשרות שינוי"]

איור 5: שני סוגי האחסון דוחים שינוי ומחיקה לתקופה מוגדרת; עד כמה בחומרה תלוי בהגדרות.

ב-Azure, גם אם מגלים טעות בהגדרות אחרי נעילת policy, אי אפשר לקצר את תקופת השמירה¹³. המדריך של CISA מציין שחלק מספקי הענן מציעים אחסון שאי אפשר לשנות, ומזהיר שהגדרה שגויה עלולה לגרום לעלויות משמעותיות. הוא מציין גם שאחסון כזה עלול לא לעמוד בדרישות של רגולציות מסוימות⁴. אם מגדירים תקופת שמירה ארוכה ונועלים אותה, אי אפשר למחוק את הנתונים במהלך התקופה, ועלויות האחסון ממשיכות להצטבר. התחילו במצב לא נעול או בתקופה קצרה, בדקו שאפשר לשחזר, ורק אז החילו את הגדרות הייצור.

להפריד את ההרשאות לניהול הגיבויים

גם כשמשתמשים באחסון שאי אפשר לשנות, אם אפשר לשנות את הגדרות הגיבוי וה-policies בחשבון ה-Administrator היומיומי, תוקף עלול לשנות אותם. Microsoft ממליצה לדרוש צעד נוסף, כמו MFA או security PIN, לפני שינוי או מחיקה של גיבויים online. היא גם ממליצה להגביל פעולות גיבוי ושחזור למשתמשים בתפקידים מוגדרים, ולצמצם file shares שבהם משתמשים רבים יכולים לכתוב ולמחוק⁵.

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

לשמור כמה דורות

ההנחיות של IPA מציינות “ניהול דורות”, כלומר שמירת גיבויים מכמה נקודות זמן. כך אפשר לחזור לנקודת זמן מסוימת כשנתונים נפגמים או אובדים¹². כפי שתואר בסעיף קודם, אם לוקח זמן לשים לב להצפנה, הגיבויים האחרונים כבר מכילים נתונים מוצפנים. קבעו כמה דורות לשמור לפי הזמן שעשוי לעבור עד שמבחינים בהצפנה ולפי עלות האחסון.

flowchart TB
        accTitle: שלושה אמצעים להחזקת עותק שאי אפשר לשנות
        accDescr: דיאגרמה שמראה אחסון של מדיה מנותקת או שימוש באחסון שאי אפשר לשנות, הפרדה של ההרשאות לניהול הגיבויים מהחשבונות היומיומיים, ושמירה של כמה דורות.
        A["עותק שאי אפשר לשנות"] --> B["אחסון מדיה מנותקת"]
        A --> C["אחסון שאי אפשר לשנות"]
        B --> D["הפרדת הרשאות הניהול"]
        C --> D
        D --> E["שמירת כמה דורות"]

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

לבדוק שאפשר לשחזר

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

ההנחיות של IPA מחלקות את תפעול הגיבויים לשלושה חלקים: ביצוע, אחסון ושחזור. בשחזור הן מבקשות להכין תוכנית התאוששות ולבדוק שאפשר לשחזר כראוי³. למערכות קריטיות לעסק, הן מבקשות להתאים את ביצוע הגיבויים ואת הנהלים ל-Recovery Time Objective‏ (RTO) ול-Recovery Point Objective‏ (RPO), ולבדוק את האפקטיביות בתרגולים. RTO הוא הזמן שנדרש כדי לחזור לרמת היעד, ו-RPO הוא נקודת הזמן שאליה חוזרים, כלומר זמן הגיבוי האחרון¹⁵. גם המדריך של CISA מבקש, לקראת Disaster Recovery, לבדוק באופן קבוע שהגיבויים זמינים ושלמים⁴.

flowchart TB
        accTitle: איך מבצעים restore test
        accDescr: דיאגרמה שמראה את הרצף של קביעת סדר השחזור, שחזור לסביבה נפרדת, השוואה של הזמן שנדרש ושל הנקודה ששוחזרה ל-RTO ול-RPO, ותיקון ה-runbook.
        A["לקבוע את סדר השחזור"] --> B["לשחזר לסביבה נפרדת"]
        B --> C["להשוות את הזמן שנדרש ל-RTO"]
        B --> D["להשוות את הנקודה ששוחזרה ל-RPO"]
        C --> E["לתקן את ה-runbook"]
        D --> E
        E -.->|"הבדיקה הבאה"| A

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

מה לבדוק

על סמך התיעוד של IPA ו-Microsoft, אפשר לארגן את מה שצריך לבדוק כך.

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

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

זהירות בשחזור אחרי התקפה

אחרי התקפה אמיתית, הסירו את ה-ransomware עצמו מהסביבה לפני השחזור⁵. Microsoft ממליצה לבחור גיבוי מנקודת זמן שידוע שלא הייתה נגועה, ולסרוק את הגיבוי לאיתור malware לפני השחזור⁵. הדוח של סוכנות המשטרה הלאומית כותב שקבוצות ransomware מתקינות לפעמים תוכנה לשליטה מרחוק כ-backdoor, כדי שיוכלו לחזור גם אחרי שנקודת הכניסה נסגרה². לפני השחזור צריך לבדוק את נתיב החדירה ואת מה שהתוקפים השאירו.

flowchart TB
        accTitle: סדר השחזור מגיבוי אחרי התקפה
        accDescr: דיאגרמה שמראה הסרה של ה-ransomware עצמו ושל נתיב החדירה, בחירה של גיבוי מנקודת זמן לא נגועה, סריקה שלו לאיתור malware, ואז שחזור של המערכות בעדיפות הגבוהה ביותר קודם.
        A["להסיר את ה-ransomware עצמו"] --> B["לבדוק את נתיב החדירה ומה שנשאר"]
        B --> C["לבחור נקודת זמן לא נגועה"]
        C --> D["לסרוק את הגיבוי"]
        D --> E["לשחזר קודם את העדיפות הגבוהה"]

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

באיזו תדירות לבדוק

גם ההנחיות של IPA וגם המדריך של CISA מבקשים לבדוק “באופן קבוע” שאפשר לשחזר, אבל לא נותנים מספר¹¹⁴. החברה במקרה של IPA שהוצג קודם קיימה תרגולי שחזור פעמיים בשנה³. החליטו כמה זמן העסק יכול להיות מושבת ועד כמה ישנה יכולה להיות הנקודה שאליה משחזרים, ובדקו בתדירות שמאפשרת לוודא שאתם עומדים בהם.

מה להחליט קודם

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

flowchart TB
        accTitle: הסדר שבו מחליטים על גיבויים שעומדים מול ransomware
        accDescr: דיאגרמה שמראה את הסדר של קביעת ההיקף, קביעת מיקום העותקים והעותק שאי אפשר לשנות, קביעת ההרשאות והדורות, קביעת ה-RTO וה-RPO, ובדיקה שאפשר לשחזר.
        A["לקבוע את ההיקף"] --> B["לקבוע היכן לשמור עותקים"]
        B --> C["לקבוע את העותק שאי אפשר לשנות"]
        C --> D["לקבוע הרשאות ודורות"]
        D --> E["לקבוע RTO ו-RPO"]
        E --> F["לבדוק שאפשר לשחזר"]

איור 9: מחליטים על הכול ברצף אחד, מההיקף ועד הבדיקה האחרונה שאפשר לשחזר.

במהדורה 4.0 של ההנחיות של IPA נוסף “גבו את הנתונים!” ל-“5 כללי אבטחת המידע” שמתחילים בהם, והם הפכו ל-6 כללים¹⁶. איך לעבוד עם ההנחיות כולן מוסבר ב-“Where Should SMEs Start on Security?”. אם אתם מתכננים להחליף שרתים, ראו גם את “Preparing for Windows Server 2016 End of Support”.

מאמרים קשורים

• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• Volume Shadow Copy (VSS): איך זה עובד בפועל — למה תוכנת גיבוי מצליחה להעתיק קבצים שבשימוש
• Preparing for Windows Server 2016 End of Support

קישורי עיון

מאמרים קשורים

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

נושאים קשורים

אלה דפי נושא הקרובים לנושא הזה. מהמאמר אפשר להמשיך לשירותים קשורים ולמאמרים אחרים.

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

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בהתייעצויות בנושא המאמר.

אם אני מגבה, האם אוכל לשחזר הכול אחרי הדבקה ב-ransomware?

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

אם יש ב-Windows את Previous Versions, האם עדיין צריך גיבויים?

כן. Previous Versions הם Volume Shadow Copies, כלומר הבדלים שנשמרים על ה-volume המקורי. Microsoft מגדירה כגיבוי את הנתונים שהועתקו מ-Shadow Copy למדיה כמו קלטת. ransomware מוחק לפעמים Shadow Copies בעזרת כלים כמו vssadmin, ולכן צריך לשלב אותם עם גיבויים על מדיה נפרדת.

האם עמידה בכלל 3-2-1 מספיקה כהגנה מפני ransomware?

לא תמיד. כלל 3-2-1 דורש שלושה עותקים, שני סוגי מדיה ועותק אחד מחוץ לאתר, אבל הוא לא דורש שהעותק שמחוץ לאתר יהיה offline או immutable. עותק בענן שמחשב נגוע יכול תמיד לכתוב אליו עלול להיות מוצפן באותה צורה. הוסיפו עותק אחד על מדיה offline או באחסון שאי אפשר לשנות.

באיזו תדירות כדאי לבדוק שאפשר לשחזר מהגיבויים?

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

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

נציג KomuraSoft LLC

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