גיבוי הוא רכיב בתוכנית התאוששות. כדי להחזיר פעילות נדרשים גם סדר פעולות, גישות, תשתית, בעלי אחריות ובדיקות. DRP מרכז את אלה לתוכנית שניתן לתרגל ולעדכן.
מה זה DRP ולמה כל עסק צריך אחד
DRP (Disaster Recovery Plan) הוא מסמך ותהליך שמגדיר כיצד הארגון ישחזר את מערכות ה-IT שלו לאחר אירוע קיצוני: מתקפת כופרה, כשל חומרה קריטי, שרפה, הצפה, כשל בספק ענן, או כל תרחיש שמשבית את הפעילות.
DRP הוא לא מסמך שיושב במגירה. הוא תוכנית פעולה חיה שנבדקת באופן קבוע. ארגון בלי DRP עובד — כמו נהג בלי ביטוח: הכל בסדר עד שזה לא.
DRP מול BCP — ההבדל
DRP עוסק בשחזור מערכות IT. BCP (Business Continuity Plan) עוסק בהמשכיות עסקית כוללת: כוח אדם, מיקום פיזי, תקשורת עם לקוחות, ספקי משנה. DRP הוא חלק מ-BCP, לא תחליף לו.
חמישה רכיבים חיוניים של DRP
1. הגדרת תרחישי אסון
לא כל אירוע הוא אסון. DRP מגדיר את התרחישים שדורשים הפעלת התוכנית:
אפשר לבחון תרחישים כגון כופרה, כשל באחסון, שרפה, הפסקת חשמל, כשל בשירות ענן ומחיקת נתונים. הסבירות וההשפעה אינן קבועות לכל עסק; מעריכים אותן לפי הסביבה והתהליכים שנפגעים.
לכל תרחיש: מה הנזק הצפוי? כמה זמן הארגון יכול לעבוד בלי המערכת? מי מושפע ראשון?
2. יעדי שחזור — RTO ו-RPO
שני המדדים הקריטיים ביותר ב-DRP:
RTO (Recovery Time Objective) הוא יעד למשך ההתאוששות של מערכת. הוא נקבע במסגרת התכנון ואינו הוכחה שהמערכת תשוחזר בזמן הזה בכל אירוע.
RPO (Recovery Point Objective) מגדיר את נקודת הזמן שאליה רוצים להיות מסוגלים להשיב את המידע, ומבטא את חלון אובדן הנתונים שניתן לשאת. תדירות גיבוי לבדה אינה מוכיחה שהיעד הושג: בודקים הצלחה, זמינות ושלמות של נקודות השחזור.
מגדירים יעדים עם בעלי התהליכים במסגרת בחינת ההשפעה העסקית, התלות והמשאבים. לדוגמה בלבד, ארגון עשוי להגדיר למערכת מסוימת יעד חזרה של כמה שעות וחלון אובדן מידע קצר יותר; עליו לבדוק שהתשתית והתרגול תומכים בכך. אין RPO אפס אוטומטי לדואר או ל־M365 מעצם קיומו של שכפול. ראו מדריך התכנון של NIST SP 800-34.
3. צוות DRP
תפקידים שחייבים להיות מוגדרים לפני שהאירוע קורה:
- מוביל DRP — מי שמחליט להפעיל את התוכנית. בדרך כלל מנהל IT או CISO.
- צוות שחזור טכני — מי שמבצע את השחזור בפועל. פנימי, ספק MSP, או שילוב.
- מתקשר ניהולי — מי שמדווח להנהלה ולבעלי עניין.
- מתקשר חיצוני — מי שמדווח ללקוחות, ספקים, ובמידת הצורך — לרגולטור.
- מתאם לוגיסטי — מי שמטפל בתשתית פיזית (חדר שרתים חלופי, חיבורי רשת, ציוד).
4. Runbook — מדריך שחזור צעד-אחר-צעד
Runbook הוא הלב של DRP. מסמך טכני שמפרט בדיוק: מה עושים, בסדר מה, ועם אילו כלים.
מבנה Runbook מוצלח: 1. אימות שהאירוע אכן דורש הפעלת DRP 2. הודעת הפעלה לצוות (מספרי טלפון, ערוצי תקשורת חלופיים) 3. בידוד מערכות נגועות (במקרה של מתקפת סייבר) 4. שחזור מערכות לפי סדר עדיפות — מערכות קריטיות קודם 5. אימות שלמות מידע לאחר שחזור 6. העברת תעבורה למערכות המשוחזרות 7. מעקב ותיעוד
בדיקת שימושיות: מתרגלים את ה־Runbook עם הגורמים המורשים שצפויים להשתמש בו. מוודאים שהם מחזיקים בידע, בהרשאות ובכלים הנדרשים, ושיש חלופה מתוכננת להיעדרות בעל תפקיד.
5. בדיקות DRP
DRP שלא נבדק — לא קיים. נקודה.
סוגי בדיקות: - Tabletop Exercise — דיון בתרחיש לבחינת אחריות, תקשורת ותלות בין גורמים. - בדיקת שחזור חלקית — שחזור נתונים או מערכת בסביבה מתאימה ובדיקת תקינות. - תרגיל התאוששות רחב — בדיקת כמה מערכות ותהליכים, כולל מעבר וחזרה כשנכללו בהיקף.
תדירות, משך והיקף הבדיקות נקבעים לפי קריטיות, שינויים, דרישות רלוונטיות והסיכון לתפעול. מתעדים תוצאות, פערים ומי אחראי לתקן.
אסטרטגיית אתר חלופי
המונחים Hot, Warm ו־Cold מתארים רמות שונות של מוכנות ומשאבים. היכולת לעבור לאתר אחר תלויה בתצורה, בתלות ובבדיקות; שם החלופה אינו מבטיח זמן התאוששות או מעבר אוטומטי.
בוחנים אילו תשתיות זמינות מראש, מה צריך להקים או לשחזר בעת אירוע ומהי העלות השוטפת. משווים את החלופות ליעדים העסקיים ומתכננים גם חזרה לסביבה הרגילה.
DRP בענן — האם זה משנה את הכללים?
כן ולא. ענן מקל על חלק מהאתגרים (אין חדר שרתים פיזי שנשרף) אבל מוסיף אחרים: - כשל באזור ענן — מה יקרה אם האזור שבו פועלת המערכת לא יהיה זמין? בודקים זמינות שירותים ותוכנית התאוששות באזור חלופי מתאים. - Lock-in — האם אתם יכולים לשחזר ל-AWS אם Azure לא זמין לפרק זמן ארוך? - גישה — האם יש לכם גישה לכלי הניהול אם ה-VPN נפל?
צ׳קליסט מהיר: האם ה-DRP שלכם מוכן?
- [ ] תרחישי אסון מוגדרים ומתועדים
- [ ] RTO ו-RPO מוגדרים לכל מערכת קריטית
- [ ] צוות DRP ממונה עם פרטי קשר עדכניים
- [ ] Runbook מעודכן לאחר שינויים רלוונטיים
- [ ] תרגיל Tabletop בוצע בהתאם לתוכנית הבדיקות
- [ ] שחזור מגיבוי נבדק ותוצאותיו תועדו בהתאם לתוכנית
- [ ] משאבי ההתאוששות שנבחרו מתועדים וזמינים ברמת המוכנות המתוכננת
- [ ] תקשורת חלופית מוגדרת (לא תלויה בתשתית הראשית)
איך DLTS בונה DRP לעסקים
אנחנו לא כותבים מסמך ושמים אותו במגירה. התהליך שלנו: 1. סקר תשתיות — מיפוי כל המערכות, תלויות, ונקודות כשל 2. הגדרת RTO/RPO — עם ההנהלה, לא רק עם IT 3. כתיבת Runbook — פעולות, הרשאות ובעלי תפקידים מתאימים 4. תכנון משאבי התאוששות — הקמה או התאמה של סביבה לפי הצורך וההיקף שסוכם 5. בדיקות מתוכננות — סוג, תדירות והיקף בהתאם להסכמה 6. עדכון שוטף — כל שינוי תשתית → עדכון DRP
שאלות נפוצות
כמה עולה לבנות DRP? בונים הצעה לפי המערכות, התלות, יעדי ההתאוששות והיקף הבדיקות. מפרידים בין מיפוי ותכנון, תשתית ורישוי, תרגול ותחזוקה. לוח הזמנים נקבע לאחר מיפוי הצרכים והמשאבים.
מה ההבדל בין DRP ל-BCP? DRP מתמקד בשחזור מערכות IT. BCP מכסה את כל ההיבטים של המשכיות עסקית: צוות, מיקום, תקשורת, ספקים, לוגיסטיקה. DRP הוא רכיב אחד בתוך BCP.
כמה פעמים צריך לבדוק DRP? מגדירים תוכנית בדיקות לפי הקריטיות, השינויים והדרישות החלות על הארגון. אחרי שינוי משמעותי בוחנים אם נדרשת בדיקה נוספת, ולא מסתפקים בתאריך של התרגיל האחרון.
למה חשוב לתרגל
תרגיל יכול לחשוף הרשאות חסרות, גיבוי שאינו מתאים, תלות שלא תועדה או קושי בתקשורת. הוא גם מאפשר להשוות את זמן ההתאוששות בפועל ליעד ולתעד פעולות לשיפור. יש לתכנן את התרגיל כך שהסיכון לפעילות ייבחן מראש.
שלוש רמות בדיקה
- תרגיל שולחני: בוחנים עם בעלי התפקידים את התרחיש ואת סדר ההחלטות.
- סימולציה בסביבת בדיקה: בוחנים שחזור ופעולות טכניות בגבולות שנקבעו.
- תרגיל מעבר לפעילות חלופית: בוחנים תהליך עסקי ואת החזרה לשגרה, כשנדרש ואושר.
משך הבדיקה תלוי בהיקפה. תוצאה טובה בתרחיש אחד אינה הבטחה לכל תרחיש עתידי.
קראו גם: גיבוי ושחזור | תכנון גיבוי 3-2-1