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

לדוגמה, המקור מציין ש־FedEx העריכה נזק של כמעט 300 מיליון דולר בעקבות הפגיעה בחברת הבת ההולנדית TNT Express ביוני 2017. הנזק כלל ירידה בהיקף משלוחים, בהכנסות וברווח. גם ארגון קטן בהרבה יכול לחוות עצירת עבודה, השבתת שירותים ופגיעה במוניטין שנמשכת אחרי שהאירוע יורד מהכותרות.

הסיכון חוצה ענפים — והנזק חוצה מערכות

כופרה היא נוזקה שיכולה להצפין קבצים מסוימים ואף מערכות שלמות ולדרוש תשלום לשחרורם. המקור מתאר תשלומים בביטקוין והתפתחות מתקיפות על תחנות בודדות להתפשטות בין מערכות באמצעות ניצול חולשות בתקשורת SMB.

הפעילות הפכה לעסק עברייני. התוקפים מבינים את הערך של המערכות והמידע שהם משבשים. בטבלה שבמקור מופיעים שיעורי פגיעה לפי ענף בשנת 2016:

הטבלה משקפת את הנתונים שבמסמך שסופק. אין להשתמש בה כדירוג סיכון עכשווי לענפים.

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

שלוש שכבות: מניעה, זיהוי ותגובה

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

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

מניעה

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

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

הוא מציין גם שרשימת יישומים מורשים יכולה להיפגע אם תוקף מנצל תהליך מוכר או מזריק אליו קוד. המגבלות אינן סיבה לוותר על מניעה; שילוב שכבות מסייע לצמצם את מספר המתקפות שמגיעות למערכת.

זיהוי

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

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

תגובה

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

שאלת תשלום הכופר

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

הסרת הנוזקה

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

גיבוי ושחזור

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

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

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

מתחילים מהשחזור ועובדים לאחור

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

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

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

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

מחליטים לאיזו נקודת זמן לחזור

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

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

בודקים שחזור

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

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

נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.

מקור: The_Value_of_Backup_in_Your_Ransomware_Protection_Strategy.pdf מאת MSP360.

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

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

את ההחלטות החשובות מכינים מראש

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

מסדרים תיעוד ותהליכי עבודה

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

מבצעים סקירת אבטחה

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

מתכננים לפי תרחישים

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

מגדירים תקשורת עם הלקוח

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

מביאים בחשבון את החובות החלות

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

מי צריך לדעת, ומי צריך לפעול?

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

הצוות הפנימי

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

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

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

הצוות החיצוני

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

מה יכול להעיד שמשהו השתבש?

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

גם בלי SIEM מורכבת, צריך לנטר מערכות ורשתות. כניסות בשעות חריגות, כתובות IP חשודות או השבתה של אנטי־וירוס וחומת אש הם דוגמאות לסימנים שכדאי לבדוק. התראה לא תמיד אומרת שיש פריצה — אבל כן שיש מה לברר.

זוהה אירוע. עכשיו עובדים לפי התוכנית

מודיעים לצוות הלקוח

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

מעריכים את המצב ומבודדים את הפגיעה

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

מזהים את דרך הכניסה

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

בוחנים הודעה לרשות הרלוונטית

המקור מדגיש שעשויה להיות חובת דיווח כאשר מדובר במידע רפואי, פיננסי או אישי, ושאי־עמידה בדרישות רלוונטיות עלולה לגרור קנסות.

חוקרים את האירוע

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

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

מוציאים דוח מסכם

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

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

מסיימים טיפול, ואז לומדים מהאירוע

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

נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.

מקור: responding-to-data-breach.pdf מאת MSP360.

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

מי יכול ליצור איום פנימי?

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

טעות, גישה שנשארה או פעולה מכוונת

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

רשלנות עובדים

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

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

עובדים לשעבר שעדיין מחזיקים בגישה

העובד כבר עזב, אבל החשבון עדיין יכול להיכנס למערכות או להתחבר ל־VPN. זה פער שכדאי לסגור כחלק מתהליך העזיבה. כרטיס הפרידה יכול להישאר למזכרת; ההרשאות פחות.

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

גורם פנימי זדוני

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

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

מה שהגורם הפנימי יודע — ומשפיע על הסיכון

איומים חיצוניים כמו כופרה זוכים בדרך כלל ליותר כותרות, אך איומים פנימיים ממשיכים לסכן עסקים. המקור מציין שכ־2,500 מתקפות פנימיות התרחשו מדי יום נכון ל־2021, וש־34% מהעסקים חוו מתקפה פנימית בשנה. המספרים מוצגים כאן כנתוני המקור ההיסטוריים.

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

איך משאירים דרך חזרה למידע?

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

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

מגנים גם על מי שיכול לגעת בגיבויים

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

אמון בצוות לצד הרשאות ותהליך מסודרים

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

נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.

מקור: how-to-protect-your-data-from-insider-threats-with-backups.pdf מאת MSP360.

כופרה לא נעצרה בקובץ מוצפן ובהודעת תשלום. במאמר ההיסטורי הזה, שנכתב ב־2022, נבחן איך התקיפות השתנו במהלך 2021 ובתחילת 2022: יותר פגיעה בתשתיות, יותר דרכי סחיטה והשפעה רחבה על עסקים ושרשראות אספקה. האירועים והמספרים נשמרים מהמקור; הם אינם נתונים עדכניים לשנת פרסום המאמר בעברית.

לפי הנתונים המצוטטים במקור מדוח הפרות המידע של Verizon, תדירות מתקפות הכופרה כמעט הוכפלה ב־2021, והן היוו 10% מההפרות שנבדקו בדוח. התקיפות פגעו בארגונים בגדלים ובענפים שונים, כולל בתי חולים, בתי ספר, ממשלות ותשתיות חיוניות.

REvil היא אחת הקבוצות שהמקור מתאר, ובהקשר הזה מוזכרות הפגיעות ב־JBS וב־Kaseya. JBS, מספקיות הבשר הגדולות בארצות הברית, שילמה לפי המקור 11 מיליון דולר בעקבות האירוע. גם מפיצת הכימיקלים הגרמנית Brenntag וחברת הביטוח CNA Financial הוזכרו כדוגמאות שממחישות את מגוון הנפגעים.

זו מגמה שספקי שירותים מנוהלים צריכים להכיר גם עבור עצמם וגם עבור לקוחותיהם. המקור מציין שב־2021 דיווחו 37% מהארגונים על פגיעה מכופרה במהלך השנה, וש־54% ממקבלי ההחלטות ב־IT סברו שהכופרה מתקדמת מכדי שהצוות שלהם יתמודד איתה לבדו. ספקי שירותים יכולים לסייע בהגנה ובבניית אסטרטגיית אבטחה שמצמצמת סיכון לאורך זמן.

כשהתקיפה יוצאת מהמסך ופוגעת בשירותים

ב־2021 פגעו מתקפות משמעותיות בארגוני תשתית חיונית. אחת הדוגמאות היא Colonial Pipeline, המספקת חלק ניכר מהדלק לחוף המזרחי בארצות הברית. התקיפה גרמה להפסקת פעילות הצינור למשך כמה ימים, פגעה בשרשרת האספקה והובילה לתורים בתחנות דלק.

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

האירוע לא היה היחיד. לפי הדוח המצוטט במאמר, כופרה הייתה ב־2021 סוג התקיפה המרכזי נגד ארגונים תעשייתיים. ענף הייצור היה יעד בולט והיווה 65% מהמקרים שזוהו בארגונים אלה. אותו דוח ייחס מחצית מהתקיפות לשתי קבוצות: Conti ו־LockBit 2.0.

כופרה כשירות: לא כל תוקף כותב את הקוד

Ransomware as a Service, או RaaS, הוא מודל עברייני שבו תוקפים משלמים כדי להשתמש בכופרה שאחרים פיתחו. לא צריך לכתוב את הנוזקה בעצמם כדי לנסות להפעיל מתקפה.

המודל לא היה חדש ב־2021, אך המשיך להקל על עבריינים להוציא לפועל מתקפות גם בלי מומחיות רבה. המקור מצטט הערכה של כ־56 קבוצות שהציעו אז מוצרים כאלה. הוא מציג את הרווחיות ואת הקושי להתמודד עם הקבוצות כגורמים שעשויים לעודד את התרחבות המגמה.

הסחיטה לא מסתיימת בהצפנה

ב־2021 תוארה גם עלייה בלחץ ציבורי על קורבנות. לצד הצפנה ודרישת תשלום, תוקפים פרסמו שמות והודיעו מי נפגע. עבור העסק, האירוע כבר לא נשאר רק בשיחה עם צוות ה־IT.

לפי אחת המדידות במקור, ב־2021 הייתה עלייה של 85% בפרסום שמות והוכחות לפגיעה לעומת 2020, ונוספו 35 קבוצות כופרה שהשתמשו בקביעות בשיטות סחיטה.

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

המחיר ממשיך גם אחרי דרישת הכופר

ככל שהתקיפות התרבו, גם המחיר עלה. המקור מציין דרישת כופר ממוצעת של 2.2 מיליון דולר ב־2021, לעומת 900 אלף דולר ב־2020 ו־541,010 דולר ב־2019. דרישת כופר לא בהכרח סכום ששולם בפועל; לא כל ארגון בוחר לשלם.

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

יכול להיות שצריך לבנות מערכות מחדש ולהקדיש זמן נוסף לבדיקה שהן פועלות כראוי. לפי נתון נוסף במקור, רוב העסקים שנכללו במדידה, 66%, נזקקו לכ־15 עד 30 יום כדי להתאושש.

גם מי שמגן על לקוחות צריך להגן על עצמו

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

האירוע ב־Kaseya היה דוגמה לכך ב־2021. החברה מספקת תוכנות ניהול IT שמשמשות ספקים רבים. ביולי אותה שנה הודיעה שנפגעה באירוע כופרה, שהתפשט לפי המקור לכ־1,500 ארגונים בעולם המשתמשים בתוכנה.

REvil דרשה 70 מיליון דולר. לפי המאמר, Kaseya סירבה לשלם וקיבלה מפתח פענוח בדרך אחרת.

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

מה לוקחים מהאירועים לתוכנית ההגנה?

אלה השינויים שהמחבר תיאר ב־2021. בזמן כתיבת המאמר הוא הדגיש שהם משפיעים על ארגונים בכל גודל וענף, והמליץ לספקי שירותים לעקוב אחריהם ולהתאים את ההגנה עם הלקוחות. את הלקח אפשר לקחת קדימה; את המספרים צריך להשאיר בהקשר ההיסטורי שלהם.

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

נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.

מקור: How Ransomware Is Evolving Nowadays.pdf מאת MSP360. למאמר המקורי.

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

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

כשהתוקף מגיע גם למידע וגם לגיבויים

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

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

המסמך מצטט כי ב־86% מהמתקפות שנבדקו נגנב מידע, כולל נפחים גדולים, וכי ב־95% היה ניסיון להגיע לאחסון כדי לפגוע בגיבויים. הוא מציין פגיעה בחלק ממאגרי הגיבוי ב־38% מהמקרים ובכל המאגרים ב־30%. המקורות המצוטטים הם דוח Coveware לרבעון השני של 2022 ודוח מגמות הכופרה של Veeam משנת 2022.

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

בין אם נעשה שימוש בהצפנה ובין אם לא, פגיעה במערכות, ניצול הרשאות, פגיעה ב־Active Directory ותנועה לרוחב הרשת עלולים לחייב החזרה של הסביבה למצב שאפשר לתת בו אמון, לפני התקיפה.

רעיון שימושי או עוד מילה למצגת?

האם Cyberstorage מסייע להתמודד עם תקיפות על האחסון, או בעיקר מוסיף מונח לשיחה? כדי לענות, המחבר מפרק את ההגדרה לעקרונות ובודק איך ליישם אותם. זו דרך טובה להבין טכנולוגיה: להתחיל במה שהיא עושה, ולא בכמה מרשים נשמע השם.

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

המקור מפנה לעקומת Gartner Hype Cycle לטכנולוגיות אחסון והגנת מידע. בגרף המצוטט Cyberstorage נמצא בשלב Innovation Trigger, תחילת ההתעניינות בחדשנות. הסימון של 5–10 שנים מתאר תחזית של Gartner לזמן עד שלב בשלות שבו פתרונות מספקים ערך באופן מבוסס.

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

מה Gartner התכוונה כשאמרה Cyberstorage?

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

המחבר גוזר מההגדרה שתי דרכי פעולה מרכזיות:

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

ההגדרה אינה מחייבת טכנולוגיית חומרה אחת. היא מתארת את מטרות ההגנה ואת הקשר בין זיהוי, חסימה והתאוששות.

שלוש מטרות נוספות

המסמך מצטט מהדוח שלושה יעדים:

1. לתת עדיפות להגנה פעילה על אחסון מידע לא מובנה, משום שהגבלת תקיפה או חסימתה עדיפות על התאוששות ממנה.
2. להקשיח את פתרון האחסון הקיים באמצעות ניהול חולשות והמלצות הספק.
3. לא להתייחס למוצרי Cyberstorage כתחליף לגיבוי, לכספות גיבוי בלתי ניתנות לשינוי, לניטור רשת או להתאוששות מאסון.

המחבר מפשט זאת לשלושה עקרונות:

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

מה אפשר לעשות עם הכלים שכבר קיימים?

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

טכנולוגיות למניעת תקיפות

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

דוגמאות לשכבות הגנה על דואר:

• הגנת דואר: אימות פרטי השולח, בדיקת קישורים, בחינת קבצים מצורפים בסביבה מבודדת והמרה של מסמכים לפורמט בטוח יותר לבדיקה. הגנת DNS וגלישה יכולה לבחון גם את היעדים שאליהם הודעה מנסה להפנות.
• הדרכת מודעות: המקור מצטט 82% מהפרות המידע שבהן היה ״גורם אנושי״, לפי Verizon DBIR 2022. הוא ממליץ על הדרכה רציפה בהונאות, הנדסה חברתית ודיוג, ועל הסבר תפקיד העובדים באבטחה. אפשר להשתמש בתרגילי דיוג כמשוב כדי לזהות היכן נדרשת הדרכה נוספת.
• הגנת תחנות: המקור מצטט דוח Acronis משנת 2022, שלפיו קצת יותר מ־11% ממתקפות הדואר הגיעו לתיבת המשתמש למרות הגנת דואר, אורך החיים הממוצע של דגימת נוזקה היה 1.7 ימים וכמעט שלושה רבעים מהדגימות נצפו פעם אחת בלבד. הוא מדגיש שיש להניח שחלק מהתקיפות יעברו את שכבות המניעה ולבחון גם הגנה על תחנת הקצה.

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

טכנולוגיות להגנת מידע תפעולי

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

• אימות רב־שלבי: דרישת גורמי אימות נוספים מקשה על שימוש לרעה בפרטי גישה פנימיים, גם כאשר קיימות הרשאות מוגברות.
• ניהול גישה בעלת הרשאות מיוחדות, PAM: צמצום האנשים שיכולים להשתמש בחשבון מוגבר וההתקנים שמהם ועליהם הוא פועל יכול להגביל תנועה לרוחב הרשת וגישה לאחסון.
• יומני קבצים ו־SIEM: ניטור מרכזי של גישה לקבצים והתראה על שימוש חריג מספקים ראות ומאפשרים להגיב לתוקף שכבר הגיע לשלב הזה.
• מניעת אובדן מידע, DLP: המקור מציין שהכלים עשויים להיות מוגבלים כאשר תוקף מעביר מידע בערוצים שאינם נבדקים, או כשהמידע מוצפן לפני ההעברה. יש לבדוק את יכולת הכיסוי בתצורה המסוימת.
• ניטור רשת: מידע שנגנב צריך לעבור בתקשורת כלשהי. התראה על יציאה חריגה של מידע עשויה לעזור לזהות פעילות ולחסום אותה.

טכנולוגיות להגנת מידע הגיבוי

המקור מציין קבוצות כגון Conti, Hive, Phobos ו־Samas כדוגמאות היסטוריות לתוקפים שניסו לפגוע בגיבויים כדי להגביר לחץ לתשלום. לכן צריך להגן גם על המידע הזה.

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

מחברים את שכבות ההגנה לתוכנית אחת

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

NIST Cybersecurity Framework

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

MITRE ATT&CK

מסגרת ATT&CK, טקטיקות, טכניקות וידע משותף על יריבים, מציגה דפוסי פעולה המשמשים תוקפים. היא מאורגנת לפי הפעולות ומספקת פרטים, דוגמאות, קבוצות קשורות, שיטות זיהוי ודרכי צמצום סיכון. אפשר להיעזר בה לבדיקת כיסוי ההגנה ולהבנת תרחישי תקיפה.

להעמקה: NIST CSF וMITRE ATT&CK.

מתחילים מההגנה, לא מהתווית

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

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

נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.

מקור: elevating-your-backup-game-achieving-cyberstorage.pdf מאת MSP360.

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

Air Gap, גיבוי מנותק, ו־Immutable, גיבוי בלתי ניתן לשינוי, נועדו לצמצם פגיעה לא מורשית בעותקים. הן עושות זאת בדרכים שונות: אחת מפרידה את הגיבוי, והשנייה מגבילה שינוי ומחיקה שלו. נבחן את החוזקות והמגבלות כדי להבין איך לבחור, ומתי לשלב.

גיבוי מנותק: העותק שנשאר מחוץ לרשת

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

איך הוא עובד?

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

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

חוזקות

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

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

אתגרים

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

גיבוי בלתי ניתן לשינוי: מחובר, אבל נעול

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

איך הוא עובד?

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

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

חוזקות

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

אתגרים

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

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

לפני שמפעילים Object Lock: מה צריך לבדוק?

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

• תמיכה ותאימות: ודאו ששירות האחסון ותוכנת הגיבוי תומכים במנגנון הנדרש ובדרך שבה אתם משתמשים בו.
• מצב הנעילה: בדקו את ההבדל בין מצבי Governance ו־Compliance כאשר הם קיימים בשירות. במצבים מסוימים אפשר להעניק הרשאות עקיפה; במצבים מחמירים יותר לא ניתן לקצר את ההגנה במהלך התקופה. יש לבדוק את ההתנהגות המדויקת בשירות ובתצורה שלכם.
• תקופת השימור: התאימו אותה לצורכי השחזור, למדיניות ולדרישות החלות על המידע. לפני נעילה ארוכה, העריכו גם את הנפח ואת העלות.
• פעולות בלתי הפיכות: בררו אילו הגדרות מותר לשנות לאחר ההפעלה ואילו עותקים לא ניתן למחוק או לשחרר לפני הזמן. אל תבנו על כפתור ״בטל״ שלא קיים.
• יכולת שחזור: בדקו שיש למורשים גישה לעותק ולמפתחות הדרושים, ושאפשר לשחזר בלי לבטל את ההגנה.

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

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

מה משתנה בעבודה היומיומית?

למה המחבר מעדיף נעילה אוטומטית?

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

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

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

מה מתאים לסביבה שלכם?

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

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

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

נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.

מקור: Air-Gap Backups vs. Immutable Backups_ A Guide for MSPs.pdf מאת MSP360. למאמר המקורי.

כשהמערכות מושבתות, כולם רוצים תשובה אחת: מה עושים עכשיו? תוכנית התאוששות מאסון היא התהליך המתועד שמספק את התשובה הזאת. היא מסבירה איך מגנים על תשתית ה־IT ואיך מחזירים את הפעילות אחרי אירוע — בלי שכל אחד יצטרך להמציא דרך משלו תחת לחץ.

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

אילו אירועים צריך להביא בחשבון?

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

כשמכירים את האירועים הסבירים באזור שבו פועלים, אפשר להיערך בהתאם. אפשר גם לפתח מודל סטטיסטי שיעזור להעריך את תדירות האירועים ואת חומרתם האפשרית.

מי עושה מה, ובאיזה סדר?

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

• אילו אנשי צוות יבצעו את משימות ההתאוששות.
• באיזו מהירות כל משימה צריכה להסתיים כדי לעמוד ב־RTO וב־RPO.
• כיצד הנהלים עשויים להשתנות בין מתקנים או אתרים שונים.
• האם צריך לבצע בנפרד התאוששות של חומרה והתאוששות של תוכנה.

ארבעת השלבים שבונים תוכנית שימושית

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

ניתוח השפעה עסקית

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

לאחר ההערכה אפשר להגדיר יעדי RTO ו־RPO, שיבהירו מה צריך לשחזר ובאיזו מהירות נדרשת התאוששות בעקבות אירוע.

אסטרטגיות התאוששות

אחרי שקבעתם יעדים, בדקו אם יש דרך מעשית לעמוד בהם. בדקו את האנשים, התשתית והרשת שעומדים לרשותכם מול RTO ו־RPO:

• האם יש מספיק אנשי צוות זמינים לתגובה?
• האם יש מספיק תשתית גיבוי וקיבולת רשת?
• האם תוכלו להשיג חומרה או תוכנה חדשה במהירות מספקת בעת הצורך?

התשובות יעזרו לגבש את אסטרטגיות ההתאוששות שעליהן תתבסס התוכנית.

פיתוח תוכנית ההתאוששות

אחרי בחירת האסטרטגיה, פרטו כיצד מבצעים אותה:

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

רכזו את התוכנית והעבירו אותה להנהלה לקבלת אישור.

בדיקת התוכנית

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

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

זמן האירוע אינו הזמן להתחיל לכתוב

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

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

נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.

מקור: Disaster Recovery Planning_ Template and Best Practices.pdf מאת MSP360. למאמר המקורי.