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

מתחת לקבצים

• האחסון מספק בלוקים
• השרת מארגן את המידע
• היישום דורש גיבוי עקבי

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

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

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

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

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

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

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

בלוקים וקבצים: שתי שכבות שיכולות לעבוד יחד

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

טבלת ההשוואה במקור, עם סימון הכללות

לפי המקור, אחסון ברמת קובץ מתאים במיוחד כאשר:

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

המקור מציע אחסון בלוקים כאשר:

• היקף האחסון אינו ידוע מראש או משתנה.
• ביצועים וזמינות חשובים יותר מנוחות השימוש הישירה.

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

בוחרים לפי הדרך שבה היישום עובד

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

מקור להערות התיקון: הסבר IBM על אחסון בלוקים והשוואת סוגי אחסון.

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

מקור: What Is Block Storage and When to Use It_.pdf מאת MSP360. למאמר המקורי.

במתקפת כופרה, דרישת התשלום מושכת את הכותרות. לעסק יש עוד חשבון לשלם: מערכות שלא עובדות, זמן שהולך לאיבוד, הכנסות שנפגעות ומוניטין שצריך לשקם. המסמך ההיסטורי הזה מ־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.

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

העקרונות המרכזיים

• מתכננים מהשחזור לאחור
• בוחנים יכולות ואחסון
• מגדירים ניהול ושירות

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

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

למי השירות נותן ערך?

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

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

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

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

מה בדיוק אתם מתחייבים לספק?

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

המקור מחלק את השיקולים לארבעה תחומים:

1. תכונות ויכולות פתרון הגיבוי.
2. אחסון הגיבויים.
3. ניהול הגיבוי.
4. אפשרויות התאוששות.

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

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

התקנה והגדרה

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

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

אם כל הלקוחות עובדים עם Windows, חלק מהבחירה פשוט יותר. בפועל, עובדים עשויים להשתמש ב־Mac ושרתים ב־Linux. בדקו תמיכה ב־Windows, macOS ו־Linux לפי הסביבות שאתם באמת מנהלים.

גיבוי המודע ליישום

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

המקור משתמש בדוגמה של בחירת Office 365 ומציין יישומים כגון SQL Server, Exchange, Office 365 ו־Google Apps. שירותים כאלה, במיוחד עבור יישומי ענן, יכולים להיות חלק מההצעה או תוספת לפי הצורך.

כמה סוגי גיבוי

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

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

טכנולוגיה יעילה

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

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

אבטחה

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

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

איפה העותקים יחכו ליום השחזור?

מיקום המידע משפיע על זמינותו, על מהירות השחזור ועל העלות ללקוח. המקור ממליץ לתכנן לפי 3-2-1:

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

אחסון מקומי

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

אחסון מרוחק וענן

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

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

מודל היברידי

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

מה נדרש כדי לנהל את השירות ביום־יום?

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

ניהול מרחוק

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

ניטור והתראות

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

רישוי וחיוב

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

חיבור למערכות נוספות

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

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

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

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

שחזור קבצים

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

שחזור Bare Metal

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

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

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

שחזור לענן

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

גיבוי חבילות עבודה בענן

המקור מדגיש שיש לבחון את גבולות התחייבויות ספקי יישומי הענן. יתירות גאוגרפית לא בהכרח מאפשרת שחזור מכל מחיקה או פגיעה. הצעת גיבוי לדואר ולמידע של Microsoft 365 או Google Workspace יכולה להוסיף יכולת התאוששות.

מתחילים מהצורך של הלקוח לשחזר

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

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

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

מקור: the-msp-s-technical-guide-to-providing-baas.pdf מאת MSP360.

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

טבלה היא חלק מהמסד

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

מתי באמת צריך רק טבלה אחת?

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

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

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

מייצאים עם BCP — ובודקים מה נוצר

BCP, קיצור של Bulk Copy Program, הוא כלי שורת פקודה להעברת נתונים אל SQL Server וממנו. כדי לייצא או לייבא נתונים בכמות גדולה, צריך גם הרשאות מתאימות — לא רק את הפקודה הנכונה.

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

השלב הראשון במקור: הפעלת xp_cmdshell

המקור מציע להפעיל את הרכיב xp_cmdshell, שעשוי להיות כבוי כברירת מחדל, באמצעות הפקודות הבאות בעורך שאילתות SQL:

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'xp_cmdshell', 1;
GO
RECONFIGURE;
GO

השלב השני במקור: בניית פקודת הייצוא

אחרי בחירת הטבלה, המקור בונה את שם קובץ הייצוא ומריץ את הפקודה מתוך SQL Server:

DECLARE @table VARCHAR(128), @file VARCHAR(255), @cmd VARCHAR(512);
SET @table = 'dbo.spt_monitor';
SET @file = 'C:\Backup\' + @table + '_' + CONVERT(CHAR(8), GETDATE(), 112) + '.dat';
SET @cmd = 'bcp ' + @table + ' out ' + @file + ' -n -T';
EXEC master..xp_cmdshell @cmd;

יש להחליף את שם הטבלה שבמשתנה @table בשם הטבלה הרצויה, ואת התיקייה C:\Backup\ בתיקיית היעד. בדוגמה נוסף לשם הקובץ תאריך בפורמט שנה, חודש ויום.

דוגמת ייצוא מתוקנת משורת הפקודה, בלי הפעלת xp_cmdshell:

bcp ExampleDB.dbo.ExampleTable out "C:/Backup/example-table.dat" -S SERVERNAME -T -n

החליפו את ExampleDB, את שם הטבלה, את SERVERNAME ואת הנתיב בערכים המתאימים. ‎-T משתמש באימות Windows; ‎-n בוחר בפורמט הנתונים המקורי. חשבון ההרצה צריך הרשאות מתאימות, ונתיב הקובץ מתייחס למחשב שבו bcp מופעל.

השלב השלישי: בדיקת תוצאות ההרצה

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

השלב הרביעי במקור: ייבוא הנתונים בחזרה

המקור מציג את הפקודה הבאה לייבוא העותק:

bcp dbo.spt_monitor IN "C:\Backup\dbo.spt_monitor_20180801.bak" -T -n

עותק שימושי, עם גבולות ברורים

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

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

מקור להערות התיקון: תיעוד Microsoft לכלי bcp והגדרת xp_cmdshell.

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

מקור: SQL Server Table Backup Guide.pdf מאת MSP360. למאמר המקורי.

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

העקרונות המרכזיים

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

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

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

קודם מכירים את הלקוח ואת הסביבה

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

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

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

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

אומרים ברוכים הבאים, ומסבירים מה עכשיו

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

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

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

מחברים אנשים, לא רק מערכות

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

סדר יום אפשרי כולל:

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

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

רשימת משימות שמונעת ״חשבתי שכבר עשינו״

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

מכניסים את הלקוח למערכות השירות

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

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

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

המקור מפרט את הרכיבים הבאים במסגרת סקירת פרטי המנהל והגישה:

• נתבי שער, חומות אש והתקני גישה אלחוטיים.
• מדפסות ומתגי Ethernet או סיבים.
• NAS ו־SAN, מכונות וירטואליות והתקני VoIP.
• חשבונות Windows וחשבונות שירות, כולל Administrator, SQL, SA ו־SharePoint.
• חשבונות מנהל בתחנות עבודה, ציוד רשת נוסף ומסוף האנטי־וירוס.
• איתור חשבונות משתמש, שירות וחשבונות גישה נסתרים, וטיפול בהם לפי הצורך.
• זיהוי חברי קבוצות מנהלים ו־Domain Admins ובחינת נחיצות ההרשאות.
• שירותי RRAS, קבוצות וחברות בקבוצות של גישה מרחוק.
• סקירת מנהלים מקומיים וחשבונות שירות במחשבים.
• מיפוי הרשת המקומית לאיתור התקנים בעלי כתובת IP ובדיקתם.
• אתרי האינטרנט ו־DNS, גישת VPN, פורטלים ותוכניות תמיכה מרחוק.

מפעילים ניטור וניהול מרחוק

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

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

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

מוודאים שהעובדים יודעים איך לקבל עזרה

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

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

מסיימים הקמה ומתחילים שירות

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

הקליטה הסתיימה. הקשר רק מתחיל

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

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

התחלה מסודרת בונה אמון

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

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

מקור: msps-client-onboarding-guide.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. למאמר המקורי.

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

העקרונות המרכזיים

• מלא הוא נקודת הבסיס
• שינויים נשמרים בשיטות שונות
• בוחנים גם זמן שחזור

גיבוי מלא: מתחילים מכל קבוצת הנתונים

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

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

גיבוי מצטבר: רק מה שהשתנה מאז הפעם הקודמת

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

איך פועלת השרשרת?

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

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

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

סוגי גיבוי מצטבר

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

גיבוי מצטבר ברמת קובץ

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

גיבוי מצטבר ברמת בלוק

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

נקודות שהמקור מדגיש

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

גיבוי דיפרנציאלי: השינויים מאז הבסיס המלא

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

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

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

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

איך הוא עובד?

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

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

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

איך נבחנה היעילות במקור?

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

• מעט שינויים ופיצול נמוך בדיסק: בתרחיש ״משתמש בינוני״ תואר יחס של 20% מהמחשב ו־80% מהענן. כשבוצעו מעט שינויים תואר גם יחס של 10% ו־90%.
• מחשבי מפתחים: עם שינויים רבים ופיצול גבוה יותר תוארו יחסים של 60%/40% ושל 40%/60%.
• שינוי כמעט בכל המידע: בתרחיש הפחות יעיל תואר יחס של 92% מהמידע המקומי ו־8% מהענן.

נקודות נוספות

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

איך בוחרים בלי ללכת לאיבוד?

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

תרשים הבחירה שבמקור, בתצוגה נגישה

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

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

המקור מסיים בכמה כללי אצבע:

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

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

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

מקור: Guide_to_Backup_Types.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.