השיפור המתמיד ביכולת העיבוד תרם למין האנושי, בכל תחום של חיינו. יתרה מכך, להבדיל מימי ראשית המחשוב, בהם המחשבים שימשו אך ורק למטרות עסקיות, הנגישות של כל אחד מאיתנו לכוח עיבוד משמעותי האמירה בקצב מעריכי. אולם, בד בבד עם השיפור באיכות החיים, ישנם בקרבנו גורמים זדוניים התרים ללא הפסק אחר דרכים יצירתיות חדשות להרוויח שלא ביושר מהטכנולוגיה המתפתחת. אחת הטכנולוגיות הללו היא הצפנת מידע. בעשורים האחרונים, פותחו אלגוריתמים מתמטיים, שיודעים לקבל קובץ מידע ולהצפין אותו לכדי בליל ביטים בלתי ניתן לפענוח. אלגוריתמים אלה משתמשים במפתח הצפנה סודי, שבעזרתו הם מצפינים (ומפענחים) את המידע. השילוב בין אלגוריתמי הצפנה חזקים ושיפור עצום ביכולת המחשוב, הביאו לכך שניתן להצפין מידע באמצעות מחשב ביתי פשוט בקצב גבוה מאוד. וכאן מגיעה ההתקפה הזדונית: גורם עוין (האקר) מצליח לחדור למחשב, מפעיל בו תוכנת הצפנה המצפינה את הקבצים שבו, והופכת אותם לבלתי שמישים. במקביל, נשלח מייל כופר ובו מתבקש הקורבן לשלם כופר (בדרך כלל בביטקוין) בתמורה למפתח ההצפנה. התקפה כזו מכונה באופן לא מפתיע "התקפת כופר" (ransomware attack).
כיצד ניתן אם כן, להתמודד עם הסכנה שבהתקפה כזו? קיימות שכבות הגנה מקובלות בהתגוננות מול איומי סייבר הכוללות תוכנות אנטי ווירוס, חומות אש וכדומה. שכבות אלה אכן מספקות הגנה מסויימת גם נגד התקפות כופר. אולם, מאפייניה הייחודיים מאפשרים הגנה ממקום לא צפוי - שכבת אחסון המידע עצמה. מאחר שבמהותה התקפת כופר פוגעת במידע המאוחסן, הרי שניתן להוסיף שכבת הגנה ישירות על מערכת אחסון המידע, מעבר לשכבות ההגנה המקובלות הקיימות ברשת המחשבים (firewall) ובמעבד עצמו (antivirus).
במקום גיבוי - שיבוט
הגישה הראשונה והפשוטה ביותר היא ליצור מערכת גיבוי קבצים, השומרת את הקבצים במיקום אחר, נפרד. היכולת הנדרשת ממערכת כזו היא להיות מסוגלת לשמור גרסאות שונות של אותו קובץ, כך שעדכון של קובץ לא יוביל בהכרח לשינויו, אלא ייצור עותק חדש. במקרה של התקפת כופר, כל שנדרש הוא לשחזר את כל הקבצים הפגועים ממערכת הגיבוי מזמן הקודם לזמן התקפת הכופר. שיטה כזו היא מועילה מאוד לאזרח הפשוט שרוצה להגן על תמונות, סרטונים וקבצים אישיים.
עבור ארגונים כמו בנקים, חברות ביטוח, בתי חולים וכדומה, הפתרון של גיבוי לא מהווה מענה מספק. בארגונים כאלה, רוב המידע החשוב נשמר במסדי נתונים ענקיים וקצב עדכון המידע הוא גבוה מאוד ומתרחש ללא הפסק. תהליך גיבוי הוא ביסודו איטי ומעמיס מאוד על משאבי מרכז הנתונים של הארגון. כשמתבצע גיבוי של קבצים ממחשב אחד למערכת אחסון אחרת, המחשב עצמו נדרש לבצע העתקה (ובכך נלקחים משאבי מחשוב שנועדו לשרת את האפליקציה לטובת הגיבוי), רשת המחשבים מועמסת בקבצי הגיבוי שנשלחים על גביה, והעומס על מערכת האחסון (שמשרתת לקוחות רבים) גדל. לכן, מקובל לייצר גיבוי לעיתים רחוקות יחסית – לכל היותר פעם ביום, בשעות הלילה. הבעיה היא שבמקרה של התקפת כופר, מידע של יום שלם נפגע באופן חסר תקנה. בנק שאיבד מידע על ההעברות החשבוניות שנעשו בו במשך יום שלם ייפגע בצורה אנושה ולכן תמיד ייכנע לדרישות הכופר. גם אילו לא היה נפגע המידע, תהליך השחזור הוא איטי יחסית (גם פענוח מידע מוצפן בהינתן מפתח ההצפנה, אגב, הוא איטי מאוד) ובמשך הזמן הזה הארגון מושבת ועלול להפסיד סכומי עתק. למשל, חברת תעופה שלא יכולה לקבל הזמנות במשך שעות ארוכות תפסיד מאות ואלפי לקוחות.
לאור הבעיות הקשות הללו, התפתח פתרון חדש יעיל יותר, אך מתוחכם ומסובך יותר למימוש - יצירת "שיבוט" (cloning) של כל האחסון, בקצב גבוה. שיבוט הוא מעין הקפאה בזמן של תמונת האחסון ללא אפשרות שינוי. הוא מתבצע מקומית בתוך מערכת האחסון עצמה ולא דורש העתקת מידע איטית ושחזור מסורבל. מקרה הצורך הוא מאפשר להעלות נקודת זמן מסויימת ולהמשיך לעבוד ממנה והלאה וזאת תוך פרק זמן קצר מאוד.
מנגנון מהיר במיוחד
כדי שמערכת שיבוט כזו תשרת היטב את מטרתה, נדרשים ממנה מספר יכולות לא טריוויאליות. ראשית, תהליך יצירת השיבוט צריך להיות קל משקל ובעל השפעה מזערית על ביצועי מערכת האחסון, וזאת כדי לאפשר שיבוט אוטומטי בקצב גבוה (אחת לשניה, לדוגמה). פעולת שיבוט צריכה להיות גם יעילה במשאבי אחסון, מאותה סיבה בדיוק. אילו כל שיבוט היה צורך את כמות האחסון של הקבצים המקוריים הרי שעלות האחסון הייתה מרקיעה שחקים במקרה של שיבוט בקצב גבוה. טכנולוגיות של copy-on-write ו -deduplication יכולות להיות כאן לעזר.
ב- copy-on-write, כשנכתבת פיסת מידע חדשה, היא לא דורסת את הקודמת, אלא נכתבת למקום אחר בדיסק. כל פעם שנוצר במערכת שיבוט חדש, כל הכתיבות החדשות נכתבות למקום חדש, בעוד המידע שלא השתנה בין השיבוטים נשאר בעינו. כדי לאפשר שחזור לנקודת זמן מסויימת (שיבוט מסוים), נדרשת מערכת אינדקס מתוחכמת, שיודעת לבנות תמונה קוהרנטית של כל פיסות המידע שמרכיבות עותק שלם של הקבצים המשויך לשיבוט ספציפי. לשם המחשה, נניח שישנם 10 יחידות אחסון בדיסק. ונניח שבנקודת ההתחלה, קובץ מסויים תופס את היחידות 1 עד 4. נניח גם שבנקודת זמן מסויימת נוצר שיבוט ומיד לאחריה נכתב חלק הקובץ שממופה כעת ליחידת אחסון 4. מה שיתבצע במנגנון copy-on-write, הוא שהמידע החדש ייכתב ליחידת אחסון 5 לדוגמה (ולא למקומו המקורי, 4), ומבנה אינדקס יציין שהקובץ השייך לשיבוט נמצא ביחידות 1 עד 4, בעוד הקובץ הפעיל נמצא ביחידות 1 עד 3 ו 5. כך, קריאה של החלק הרביעי של הקובץ מהקובץ הפעיל תופנה אוטומטית ליחידת אחסון 5. אם המשתמש יבקש לשחזר את הקובץ לשיבוט האחרון, מיידית הוא יעבור לאינדקס המתאים, וקריאה של החלק הרביעי של הקובץ תופנה ליחידת אחסון 4.
מנגנון כזה הינו, כפי שניתן להבין מהתיאור, מהיר במיוחד: אין כלל העתקות מידע או כל פעולות אחסון שקורות בזמן יצירת שיבוט ותגובת המערכת היא מיידית וזולה. אותו דבר לגבי שחזור: אין כלל העתקת מידע, אלא רק החלפת אינדקס, כך שהמשתמש נחשף מיידית לנקודת הזמן הרצויה לו (לפני התקפת הכופר) ויכוך להמשיך לתת שירות, תוך איבוד זמן אפסי. יתכן שהקורא יחשוב בשלב זה שמדובר במנגנון פשוט ויתהה מדוע אם כך לא הכל משתמשים במנגנון שיבוט אוטומטי בקצב גבוה. לקורא זה אומר שלדאבון הלב (ולשמחתם של אחרים) תכנון ומימוש מערכת אינדקסים מחוכמת כזו היא מסובכת מאוד וחברות המספקות שירותי אחסון לא תמיד מצליחות לתכנן מערכת יעילה מספיק, שתענה על הדרישות לעיל.
לא לאפשר מחיקה של שיבוטים
תכונה נוספת הנדרשת ממערכת כזו היא מנגנון אל-כשל, שמבטיח שאף גורם זדוני לא יוכל למחוק או לשנות את אחד מהשיבוטים. ככלל, חוזקה של מערכת אבטחה היא בהתאם לחוליה החלשה בה. צריך להניח שכל דבר שהמשתמש החוקי יכול לעשות גם האקר מיומן מספיק, שהצליח לחדור את הגנות הארגון, יוכל לעשות גם הוא. נדרש, אפוא, שאף המשתמש עצמו לא יוכל למחוק או לשנות את אחד מהשיבוטים שנוצרו. דא עקא, יצירת שרשרת אין-סופית של שיבוטים תגבה, בסופו של דבר, מחיר גבוה ממערכת האחסון. למרות שצריכת המשאבים לשיבוט נמוכה מאוד, הרי שיצירת שיבוטים בקצב גבוה של אחת לשניה, למשך מספר חודשים, תגבה את מחירה ממערכת האחסון ונרצה לאפשר למשתמש לנקות שיבוטים ישנים.
ישנם מספר פתרונות מקובלים לבעיה זו. אחד מהפתרונות המקובלים הוא לא לאפשר מחיקה של שיבוטים בחלון זמן מסויים אחורה (לדוגמה, שבועיים), מתוך הנחה סבירה שבמשך שבועיים וודאי שנזהה התקפת כופר ונציל את המידע שלנו. פתרון אחר הוא באמצעות מנגנון השהייה: משתמש שדורש למחוק שיבוט ייענה בתגובה מאוחרת של 48 שעות. בזמן זה יישלחו הודעות התראה לגורמי ה-IT בארגון ויוכלו להתבצע בדיקות מתאימות.
הכותב הוא CTO בחברת Pliops
