התפיסה המקובלת בעולם העסקים המודרני אומרת שהמעבר לענן פתר את בעיית אובדן המידע. מנהלים רבים בטוחים כי ברגע שהשרתים עברו לחברות ענק כמו אמזון, מיקרוסופט או גוגל, הנתונים שלהם חסינים לחלוטין. המציאות בשטח, כפי שפוגשים מהנדסי שחזור המידע יום-יום במעבדה, שונה לחלוטין. מידע הולך לאיבוד גם בענן וגם בשרתים מקומיים, אך הדרך להציל אותו משתנה מקצה לקצה.
בשורה התחתונה, ההבדל המרכזי שוכב בין החומר לרוח. בשחזור שרת מקומי האתגר הוא פיזי ולוגי ועוסק בגישה ישירה לרכיבי המדיה ובנייה מחדש של מערכי דיסקים קורסים. בשחזור ענן, האתגר הופך לארכיטקטוני ולוגאריטמי, שבו המידע מבוזר, מוצפן ומקוטע בין אלפי שרתים וירטואליים, ללא כל גישה פיזית לחומרה. מדובר בשני עולמות הנדסיים שונים לחלוטין, הדורשים סט כלים ומומחיות ייחודיים לכל זירה.
עולם השרתים המקומיים: המאבק בברזלים ובמערכי ה-RAID
כאשר חדר שרתים של חברה קורס, בין אם בגלל שרפה, הצפה, קצר חשמלי או כשל מכני, המידע עדיין נמצא פיזית בתוך המבנה. האתגר ההנדסי כאן מתחיל בטיפול בחומרה עצמה וממשיך אל תוך המבנה הלוגי של מערכות האחסון הארגוניות.
האתגר הפיזי: עבודה בחדר נקי ושינוי ארכיטקטורת רכיבים
כוננים קשיחים של שרתים, במיוחד במערכות אחסון ארגוניות גדולות, עובדים תחת עומס עבודה עצום ובמהירויות סיבוב גבוהות במיוחד. כשל מכני קטן ביותר יכול לגרום לראש הקריאה והכתיבה לשרוט את פלטות המגנט המכילות את המידע.
במקרים כאלה, מהנדס שחזור המידע נדרש לפתוח את הכונן בתוך חדר נקי בתקן מחמיר כדי למנוע מכל חלקיק אבק להרוס את המדיה. העבודה כוללת החלפת ראשי קריאה תחת מיקרוסקופ, תיקון כרטיסים אלקטרוניים פגומים והתגברות על נעילות קושחה של היצרנים. בשנים האחרונות, עם המעבר המאסיבי לכונני SSD וטכנולוגיות NVMe מהירות, האתגר הפיזי השתנה. אין יותר חלקים נעים, אך ישנם שבבי זיכרון מורכבים ובקרים מתוחכמים שמצפינים את המידע ברמת החומרה. שחזור כזה דורש קריאה ישירה של שבבי ה-NAND והרכבת המידע מחדש באמצעות אלגוריתמים מתמטיים מורכבים.
פאזל ה-RAID: בנייה מחדש של מערכי דיסקים קורסים
רוב השרתים המקומיים משתמשים במערכי RAID כדי להבטיח רציפות עבודה. המערכים הללו מחלקים את המידע בין מספר כוננים ומייצרים יתירות. הבעיה מתחילה כאשר יותר מכונן אחד קורס בו-זמנית, או כאשר בקר ה-RAID עצמו חווה תקלה ומאבד את הגדרות המערך.
במצב זה, המהנדס מקבל לידיו עשרה, עשרים או אפילו מאה כוננים שונים. המטרה היא לקרוא את תוכן כל הכוננים ברמת הביט הבודד, ולאחר מכן לפצח את הלוגיקה של המערך. המהנדסים צריכים לגלות את סדר הכוננים המדויק, גודל הבלוקים ששימשו לכתיבה, ואת כיוון הפריסה של נתוני הזוגיות. טעות של קובץ אחד או בלוק אחד במקום הלא נכון, וכל בסיס הנתונים הארגוני יהפוך לרצף של תווים חסרי משמעות.
עולם שחזור הענן: האתגר הווירטואלי והסיוט של ביזור המידע
בענן, הכללים משתנים. חברות שמחזיקות מידע בתשתיות ענן ציבוריות או פרטיות לא יכולות לגשת לדאטה סנטר, לשלוף כונן פגום ולהביא אותו למעבדה. הגישה לחומרה חסומה לחלוטין מטעמי אבטחה ופרטיות של שאר הלקוחות באותו ענן. השחזור כאן מתבצע כולו בשכבות התוכנה והווירטואליזציה הגבוהות ביותר.
שכבות הווירטואליזציה והרשת הנסתרת
מידע בענן אינו נשמר כקובץ פשוט על דיסק. הוא עובר דרך מספר עצום של שכבות הפשטה. מערכות אחסון מבוססות תוכנה מחלקות כל קובץ לחתיכות קטנות, מייצרות להן העתקים ומפזרות אותן בין שרתים פיזיים שונים, לעיתים באזורים גיאוגרפיים שונים לגמרי.
כאשר מתרחשת תקלה לוגית עמוקה, פגיעת כופרה מתוחכמת או מחיקה זדונית של תשתיות, המהנדסים צריכים להתמודד עם האתגרים הבאים.
- פענוח מבני קבצים וירטואליים מורכבים כמו VMDK או VHDX שנפגעו ברמת המטא-דאטה שלהם.
- התמודדות עם מערכות קבצים מבוזרות שבהן המפתח שמחבר בין חלקי הקובץ השונים אבד או הושחת.
- עבודה מול פרוטוקולי תקשורת וממשקי API של ספקיות הענן, המגבילים את מהירות משיכת המידע הגולמי מטעמי הגנת רשת.
אתגר ריבוי הדיירים ומחסום האבטחה
ספקיות הענן הגדולות מפעילות סביבות של ריבוי דיירים. המשמעות היא שהמידע של החברה שלכם עשוי לשבת על אותם כוננים פיזיים יחד עם מידע של מאות חברות אחרות. מסיבה זו, ספקיות הענן לעולם לא יאפשרו לבצע אימג' גולמי לרמת החומרה.
הגבלה זו מייצרת אתגר הנדסי חסר תקדים. מהנדס השחזור חייב לעבוד בתוך מגבלות הסביבה הווירטואלית, למצוא פרצות לוגיות חוקיות המאפשרות שחזור של מטא-דאטה, ולשחזר גרסאות קודמות מתוך שכבות האחסון העמוקות של הענן, מבלי לפגוע בפרטיות של משתמשים אחרים ומבלי להפעיל מנגנוני הגנה אוטומטיים של הענן שיכולים לנעול את החשבון לצמיתות.
| פרמטר | שרת מקומי (On-Premise) | שרת ענן (Cloud Infrastructure) |
| נגישות למדיה | ישירה. ניתן לפרק כוננים ולהביאם למעבדה. | עקיפה בלבד. דרך ממשקי תוכנה ורשת. |
| סוג התקלה הנפוץ | כשל מכני, קריסת חומרה, הפסקות חשמל. | מחיקות לוגיות, באגים בתוכנה, כופרות, אובדן מפתחות הצפנה. |
| מבנה המידע | מרוכז במערך דיסקים מקומי (RAID). | מבוזר ומקוטע בין שרתים ומרכזי נתונים שונים. |
| הצפנה | לרוב ברמת קובץ או דיסק מלא ניתנת לניהול מקומי. | מנוהלת על ידי שירותי ניהול מפתחות מורכבים בענן. |
| זמן תגובה ראשוני | תלוי במהירות הבאת המדיה הפיזית למעבדה. | מיידי, דורש הקמת סביבות עבודה וירטואליות במקביל. |
נקודה למחשבה: פרדוקס ההצפנה בענן הצפנת מידע היא חיונית לאבטחה, אך היא האויב הגדול ביותר של שחזור המידע. בענן, המידע מוצפן לרוב הן במעבר והן במנוחה. אם מפתחות ההצפנה הארגוניים המנוהלים בענן נפגעים או נמחקים במהלך מתקפת סייבר, המידע הופך לרעש אקראי לחלוטין. במצב כזה, גם אם נצליח לשחזר את כל הביטים מהענן, לא ניתן יהיה לפענח אותם ללא המפתחות המקוריים. לכן, הנדסת שחזור מודרנית מחייבת מומחיות עמוקה גם במערכות הצפנה וניהול מפתחות.
האתגרים ההנדסיים המשותפים בעידן ההיברידי
חברות רבות כיום לא בוחרות רק בענן או רק בשרת מקומי, אלא משלבות ביניהם בארכיטקטורה היברידית. המידע מסתנכרן באופן רציף בין המשרד המקומי לבין הענן. מצב זה מייצר אתגר הנדסי חדש ומסוכן: שחזור מידע משרשרת סנכרון פגועה.
לולאות סנכרון והפצת שחיתות נתונים
כאשר קובץ משתבש או ננעל על ידי כופרה בשרת המקומי, מערכת הסנכרון האוטומטית מזהה זאת כשינוי לגיטימי ומעתיקה את הגרסה הפגומה ישירות לענן בתוך שבריר שנייה. התוצאה היא הרס כפול של המידע בשני הקצוות.
העבודה ההנדסית במקרה זה כוללת ניתוח של ציר הזמן של הסנכרון. המהנדסים נדרשים לבצע עצירה מוחלטת של תעבורת הרשת, לנתח את קבצי היומן (Logs) של מערכת הסנכרון, ולמצוא את נקודת הזמן המדויקת שבה המידע היה תקין. השחזור מתבצע במקביל: תיקון המטא-דאטה בענן והצלת הנתונים הפיזיים מהשרת המקומי, תוך כדי מניעה מהמערכות לדרוס אחת את השנייה פעם נוספת.
מתקפות כופר מתוחכמות המיועדות להרוס גיבויים
ההאקרים של היום מבינים היטב בארכיטקטורת רשת. כאשר הם חודרים לארגון, הם לא רק מצפינים את השרת המקומי, אלא מחפשים את נתיבי הגישה לענן. הם משתמשים בהרשאות גנובות כדי למחוק את תמונות המצב הווירטואליות (Snapshots) ואת הגיבויים ההיסטוריים שנשמרו בענן.
שחזור המידע במצבים אלו דורש הבנה עמוקה בפורנזיקה דיגיטלית. המהנדסים מנסים לאתר שאריות של מידע שלא נמחק לחלוטין בשכבות נמוכות של מערכות האחסון בענן, או לחלץ חלקי קבצים מתוך זיכרון המחשב וחללים לא מנוצלים בכוננים המקומיים.
שאלות ותשובות בנושא שחזור מידע
האם חברות הענן הגדולות לא משחזרות את המידע עבורי אם יש תקלה?
ספקיות הענן פועלות תחת מודל של אחריות משותפת. הן אחראיות על תקינות התשתית הפיזית, זמינות החשמל והחומרה של הדאטה סנטר. המידע עצמו, הגיבויים שלו, מערכת הקבצים וההגנה מפני מחיקות או כופרות נמצאים באחריות המלאה של הלקוח. אם מחקתם מידע או שהחשבון שלכם נפגע מלוגיקה פגומה, חברת הענן לא תבצע עבורכם עבודת שחזור הנדסית.
מה קשה יותר לשחזר, שרת מקומי או שרת ענן?
אין תשובה חד משמעית, שכן מדובר באתגרים שונים. שרת מקומי מציב אתגרים פיזיים קשים שדורשים מעבדות מתקדמות, ציוד מכני עדין ויכולת הנדסית לפרק ולהרכיב חומרה פגומה. שרת ענן מציב אתגרים לוגיים מופשטים, שבהם נדרש פיצוח מתמטי ותוכנתי של מערכות מבוזרות. לעיתים קרובות, חוסר הגישה הפיזית לענן הופך את השחזור למורכב ומתוחכם יותר ברמת הקוד.
האם ניתן לשחזר מידע משרת מקומי שנשרף לחלוטין?
ברוב המקרים כן. גם כאשר שרת חווה שרפה קשה או הצפה, פלטות המגנט שבתוך הכוננים הקשיחים, או שבבי הזיכרון שבתוך כונני ה-SSD, מסוגלים לשרוד תנאים קיצוניים. המפתח להצלחה הוא הבאת המדיה בהקדם האפשרי למעבדת שחזור מקצועית, מבלי לנסות לייבש או להדליק את הציוד באופן עצמאי, דבר שעלול לגרום לנזק סופי ובלתי הפיך.
כיצד מערכות הגנת מידע מודרניות משפיעות על יכולת השחזור?
מערכות אבטחה מודרניות עושות שימוש רב בארכיטקטורת אפס אמון ובהצפנות קצה לקצה. בעוד שהדבר מגן על הארגון מפני פריצות, הוא מקשה מאוד על תהליך השחזור במקרה של קריסה. מהנדס שחזור כיום חייב להיות גם מומחה אבטחת מידע כדי לדעת כיצד לנווט בתוך פרוטוקולי האבטחה הללו מבלי להפעיל מנגנונים שמשמידים את המידע באופן אוטומטי בעת זיהוי גישה חריגה.
הדרך הנכונה להתנהלות בזמן אירוע אובדן מידע
ההצלחה של שחזור מידע, בין אם מהענן ובין אם מהשרת המקומי במשרד, תלויה במידה רבה בפעולות הראשונות שמבוצעות ברגע גילוי התקלה.
אם מדובר בשרת מקומי, הפעולה החשובה ביותר היא ניתוק מיידי של המכשיר מהחשמל. אין לבצע הפעלות מחדש, אין להריץ תוכנות בדיקת דיסק או תוכנות שחזור מדף, ואין לנסות להחליף כוננים במערך ה-RAID ללא אבחון מדויק. כל פעולת כתיבה נוספת על הכונן הפגום עלולה לדרוס את המידע שנותר ולמנוע את הצלתו.
בסביבת ענן, יש לנתק מיד את כל חיבורי הרשת והסנכרון אל השרתים המקומיים כדי למנוע את התפשטות הנזק. יש להקפיא את מצב המערכת הנוכחי, לשמור את כל קבצי הלוגים של שרת הניהול, ולפנות מיד למומחים שיודעים לגשת אל שכבות המידע הווירטואליות בצורה מאובטחת ומבוקרת. ניסיונות חובבניים לשנות הגדרות ברשת הענן עלולים למחוק לצמיתות את תמונות המצב שעוד נותרו במערכת.
