גיבוי הוא רכיב קריטי — אבל הוא לא תכנית התאוששות
אירוע כופרה, כשל חומרה, השבתת ספק ענן, שריפה, הצפה או טעות אנוש יכולים לעצור פעילות עסקית בתוך דקות. גם כאשר קיים גיבוי תקין, עדיין צריך לדעת לאן משחזרים, באיזה סדר, מי מאשר את התהליך, אילו מערכות עולות ראשונות וכמה זמן העסק מסוגל לתפקד במצב חלקי.
תכנית התאוששות מאסון (DRP) מגדירה את הפעולות הטכניות הנדרשות להחזרת מערכות, שירותים ומידע. תכנית המשכיות עסקית (BCP) עוסקת ביכולת הארגון להמשיך לעבוד בזמן ההפרעה. יחד הן יוצרות גישת BCDR — Business Continuity & Disaster Recovery.
שני חלקים של אותה משימה
תכנית המשכיות עסקית — BCP
מגדירה איך העסק ממשיך לפעול כאשר סביבת העבודה הרגילה אינה זמינה: עבודה מאתר חלופי, עבודה מרחוק, סדרי עדיפויות, אנשי קשר, תקשורת עם לקוחות והפעלת שירותים חיוניים.
תכנית התאוששות מאסון — DRP
מגדירה איך משחזרים את שכבת ה־IT: שרתים, תחנות, מכונות וירטואליות, נתונים, הרשאות, רשת, אפליקציות וקישוריות.
6 פעולות שמכינות את הארגון להתאוששות אמיתית
הדרכת משתמשים
העובדים צריכים להבין מהו אירוע חירום, איך מדווחים עליו ולמי. תרגול קצר עדיף על מסמך שאיש אינו מכיר.
מיפוי תהליכים קריטיים
מזהים אילו תהליכים מייצרים הכנסה, אילו מערכות נדרשות עבורם ואיזה ידע קריטי נמצא אצל אדם יחיד.
היערכות לאיום צפוי
כאשר קיימת התרעה מוקדמת — למשל מזג אוויר קיצוני או עבודת תשתית — מבצעים פעולות מניעה, כיבוי מסודר והגנה על ציוד.
תיעוד שיטתי
מתעדים נקודות כשל, תלויות, בעלי תפקידים ונהלים. לא חייבים מסמך ענק; חייבים מסמך שאפשר לבצע ממנו פעולות.
מיפוי מידע וגיבויים
בודקים איפה נמצא המידע: תחנות, שרתים, VM, ענן, Microsoft 365, Google Workspace, NAS ומערכות נוספות.
בדיקה, בדיקה ושוב בדיקה
גיבוי שלא נוסה בשחזור הוא הנחה, לא ודאות. מבצעים שחזורי קובץ, שרת ומערכת מלאה לפי לוח בדיקות קבוע.
בזמן אירוע — סדר פעולות חשוב לא פחות מהכלים
כופרה יוצרת לחץ, והלחץ גורם לטעויות: כיבוי לא מבוקר, שחזור מוקדם מדי לסביבה נגועה, מחיקת ראיות, שימוש בסיסמאות שנפרצו או חיבור מחדש של מערכות לפני שהגורם התוקף סולק.
“בזמן אירוע לא ממציאים תהליך — מפעילים תהליך שכבר תרגלנו.”
- מי מוסמך להכריז על אירוע?
- מי מבודד מערכות?
- מי מאשר התחלת שחזור?
- מה עולה ראשון?
- מי מתקשר מול הנהלה, לקוחות וספקים?
8 שלבי התגובה לכופרה
הסדר הבא הופך אירוע כאוטי למסלול פעולה ברור: קודם עוצרים את ההתפשטות ומבינים מה קרה, אחר כך בונים שחזור מבוקר, ורק בסוף מחזירים מערכות לייצור ומפיקים לקחים.
תרשים זרימה — מהזיהוי ועד חזרה לשגרה
הגדירו את היקף התקיפה
מזהים אילו תחנות, שרתים, חשבונות, תיקיות, שירותי ענן או מאגרי מידע הושפעו. חשוב להפריד בין “מה נראה מוצפן” לבין “מה עלול להיות בסיכון”. ממפים גם מערכות מחוברות שעדיין לא הראו סימני פגיעה.
- רשימת נכסים שנפגעו
- זמן משוער לתחילת האירוע
- חשבונות והרשאות שהיו פעילים
- בדיקה האם הגיבויים עצמם נגישים ושלמים
בודדו את המערכות שנפגעו
מפסיקים את התפשטות האירוע בצורה מבוקרת: ניתוק מהרשת, השבתת שיתוף קבצים, חסימת חשבונות שנפרצו והפרדת VLAN/סגמנטים לפי הצורך. לא רצים מיד לפרמט או למחוק — ייתכן שיידרשו ראיות לניתוח.
- ניתוק נקודות קצה נגועות
- חסימת חשבונות חשודים
- עצירת סנכרון שעלול להפיץ קבצים מוצפנים
- שמירת מידע פורנזי לפני פעולות הרסניות
העריכו את היקף הנזק והיכולת להתאושש
בודקים אילו נתונים נפגעו, מהי נקודת השחזור האחרונה הנקייה, אילו גיבויים זמינים ומהו פער המידע הצפוי. בשלב זה מחפשים גם גיבויים בלתי־ניתנים לשינוי, עותקים מחוץ לאתר ועותקים שאינם מחוברים ישירות לסביבה.
בצעו דיווח והתראות לפי צורך
אירוע כופרה עשוי לערב חובות דיווח חוזיות, רגולטוריות או משפטיות. מפעילים את גורמי ההנהלה, הייעוץ המשפטי, הביטוח והאבטחה לפי מדיניות הארגון. תקשורת חיצונית צריכה להיות מדויקת ומתואמת — לא ספקולטיבית.
בנו תכנית שחזור לפני שמתחילים לשחזר
מחליטים מהו סדר העדיפויות: זהויות והרשאות, רשת, תשתיות ליבה, שרתים קריטיים, בסיסי נתונים, אפליקציות ותחנות. קובעים את נקודת השחזור, יעד השחזור והבדיקות שיבוצעו לפני פתיחת הגישה למשתמשים.
שחזרו את הנתונים והמערכות לסביבה נקייה
מבצעים שחזור לפי התכנית ומוודאים שהיעד נקי. במידת האפשר מתחילים בסביבה מבודדת או זמנית, מבצעים סריקות, בדיקות תקינות ובדיקות משתמשים ורק לאחר מכן מחזירים את המערכת לייצור.
- אימות תקינות גיבוי
- שחזור למיקום נקי
- בדיקת אפליקציה ושירותים
- אימות הרשאות, DNS, רשת וגישה
בצעו ביקורת אבטחה ותקנו את נקודת הכניסה
אחרי שהעסק חזר לעבוד, בודקים איך התוקף נכנס: פישינג, חשבון שנפרץ, שירות חשוף, חולשה שלא עודכנה, הרשאות עודפות או גורם אחר. שינוי סיסמאות לבדו אינו מספיק אם לא מטפלים בשורש האירוע.
צרו דוח אירוע והפכו את הלקחים לשיפור קבוע
מתעדים ציר זמן, מערכות שנפגעו, החלטות, זמני התאוששות, אובדן מידע, פעולות שבוצעו ומה יש לשנות. הדוח צריך להסתיים ברשימת משימות עם בעלים ותאריך יעד — אחרת הלקחים יישארו על הנייר.
ארכיטקטורת שחזור עמידה לכופרה
RTO ו־RPO: הופכים “צריך מהר” למספר שאפשר לתכנן סביבו
Recovery Time Objective
כמה זמן העסק יכול להיות בלי מערכת מסוימת. לדוגמה: מערכת ERP קריטית — עד שעתיים; שרת ארכיון — עד 24 שעות.
Recovery Point Objective
כמה מידע מקסימום מותר לאבד בזמן. RPO של 15 דקות דורש תדירות גיבוי או רפליקציה גבוהה יותר מ־RPO של 24 שעות.
איך בונים לוח בדיקות שחזור
בדיקות שחזור צריכות להיות שגרת תחזוקה, לא אירוע שנתי חגיגי. אפשר לבצע חלק גדול מהבדיקות בלי להפריע למשתמשים — למשל שחזור קבצים למיקום חלופי, הפעלת VM מבודד או Restore Verification אוטומטי.
| תדירות | בדיקה | מטרה |
|---|---|---|
| שבועי | שחזור קובץ/תיקייה | לוודא זמינות ותקינות גרסאות |
| חודשי | בדיקת גיבויים, התראות ו־Retention | לגלות כשלים שקטים |
| רבעוני | שחזור שרת או VM | לאמת RTO ולבדוק תלותי מערכת |
| שנתי | תרגיל BCDR מלא | לבדוק אנשים, תהליכים, תקשורת ותשתית חלופית |
צ'קליסט תכנית התאוששות מאסון
אנשים ותפקידים
- בעל תפקיד שמכריז על אירוע
- אחראי IT / אבטחה / שחזור
- אנשי קשר לספקי ענן, אינטרנט וחומרה
- איש קשר להנהלה ותקשורת
- רשימת טלפונים זמינה גם מחוץ למערכת
נכסים ומידע
- רשימת שרתים, VM ותחנות קריטיות
- מיפוי SaaS, Microsoft 365 ו־Google Workspace
- מיקום גיבויים ופרטי Retention
- מיפוי תלות בין מערכות
- תיעוד סיסמאות חירום באופן מאובטח
שחזור
- RTO ו־RPO לכל מערכת
- סדר עליית שירותים
- יעד חלופי לשחזור
- בדיקת Boot / Application
- נוהל חזרה מהסביבה הזמנית לייצור
אבטחה ועמידות
- MFA לחשבונות ניהול
- הפרדת הרשאות גיבוי מה־Domain
- Immutable / Object Lock
- עותק Off-site
- בדיקות שחזור מתוזמנות ומתועדות
איך הופכים את התכנית ליכולת שחזור בפועל
תכנית BCDR טובה צריכה להתחבר למנגנוני הגיבוי והשחזור עצמם. בסביבת BackupONE ניתן לבנות שכבת הגנה שמתאימה למחשבים, שרתים, מכונות וירטואליות ושירותי ענן, תוך שילוב גיבוי מקומי וענני, שמירת גרסאות, הגנה על עותקי גיבוי ובדיקות שחזור.
Image-Based Backup
גיבוי מלא של מערכת ההפעלה, אפליקציות, הגדרות ונתונים מאפשר שחזור מערכת מלאה — לא רק קבצים.
Immutable Backup
עותק מוגן מפני שינוי או מחיקה מצמצם את הסיכון שהכופרה תצליח לפגוע גם ביכולת ההתאוששות.
Hybrid / Off-site
שילוב עותק מקומי לשחזור מהיר עם עותק חיצוני לענן יוצר שכבת עמידות נוספת במקרה של פגיעה באתר.
Instant Recovery
במקרים מתאימים ניתן להפעיל מערכת מגיבוי כמכונה וירטואלית ולהחזיר שירותים קריטיים לפני השלמת שחזור מלא.
Retention
שמירת מספר נקודות זמן עוזרת לחזור לגרסה נקייה מלפני תחילת ההצפנה — גם כאשר האירוע התגלה באיחור.
Restore Verification
בדיקת שחזור מתוכננת מספקת ביטחון שהגיבוי אינו רק “הצליח”, אלא באמת ניתן להפעלה ושימוש.
היעד אינו “לשרוד כופרה” — אלא לחזור לפעילות בצורה נשלטת
הגנה מושלמת מפני כל אירוע אינה מציאותית. מה שכן אפשרי הוא לצמצם משמעותית את ההשפעה: להבין מה קריטי, לבנות גיבויים עמידים, להגדיר תפקידי חירום, לתעד סדר שחזור, לתרגל אותו ולדעת מראש מה עושים כאשר האירוע מגיע.
תכנית טובה היא קצרה מספיק כדי שאפשר יהיה להשתמש בה — ומדויקת מספיק כדי שלא נצטרך לנחש.