למה גיבויי MSP נמצאים פתאום תחת כל כך הרבה לחץ?
ספקי שירותים מנוהלים נמצאים תחת לחץ חדש משום שלקוחות, רגולטורים ותוקפים מתייחסים כיום לגיבויים של יומני רישום ותצורות כראיה מרכזית לאמינות. מצופה מכם להוכיח שמערכות נתונים אלו מוגנות, ניתנות לשחזור ואמינות בכל פעם שמשהו משתבש, לא רק ששרתים חוזרים לפעולה.
סיפורי גיבוי חזקים הם בסופו של דבר סיפורים על אמון, לא על אחסון.
מאמר זה מציע מידע כללי על ניהול גיבוי עבור ספקי שירותי ניהול רשתות (MSPs). אין בו ייעוץ משפטי, רגולטורי או ביטוחי, ועליכם לקבל ייעוץ מומחה לפני קבלת החלטות בעלות סיכון גבוה.
במהלך השנים האחרונות, מספר תקריות של ספקי שירות חשפו את אותה תבנית. לקוח סובל מהפסקה או פגיעה, ה-MSP משחזר את שרתי הליבה במהירות סבירה, אך היומנים ונתוני התצורה הדרושים להבנה, הוכחה ושחזור מלא של האירוע מעולם לא גובו או שהוחזקו באותו אחסון שנכשל. מחקרי מקרה עצמאיים של אירועי MSP מדגישים שוב ושוב דפוס זה, ומראים כיצד יומנים ותצורות חסרים או שנהרסו הופכים תקלות הניתנות לשחזור למשברי אמון ארוכי טווח. זה הופך בעיה טכנית לבעיית אמון. דירקטוריונים ומנהיגי אבטחה אצל הלקוחות שלכם שואלים כעת במפורש: "אם משהו משתבש, האם תוכלו להראות לנו מה קרה ולבנות אותנו מחדש למצב תקין וידוע?"
במקביל, הציפיות עלו. לקוחות מניחים לעתים קרובות שכל פיסת מידע משמעותית שאתם נוגעים בה - יומני אבטחה, נתיבי ביקורת של SaaS, כללי חומת אש, תצורות זהות ותשתית כקוד - מגובה, נשמרת ונבדקת. ספקי שירותי ניהול שירותים (MSPs) רבים, לעומת זאת, עדיין מתייחסים ליומנים ותצורות כ"ארעיים" או "ניתנים לגזירה מחדש", וממקדים את משטרי הגיבוי הרשמיים שלהם בשרתי קבצים ומסדי נתונים. סקרים בתעשייה על נוהלי גיבוי של ספקי שירותי ניהול שירותים (MSPs) והנחות יסוד של לקוחות, כגון מחקרי ציפיות גיבוי עבור ספקי שירותי ניהול שירותים (MSPs), מראים פער עקבי בין מה שלקוחות מאמינים שהוא מוגן לבין מה שספקים מגבים בפועל. הפער בין הנחות אלו הוא המקום שבו חיים ממצאי ביקורת, שיחות רבעון רביעיות מתוחות ועסקאות אבודות.
תוקפים למדו גם לרדוף ישירות אחר פלטפורמות גיבוי ומאגרי יומנים. צוותי כופר מנסים להשבית או לפגוע במשימות גיבוי, למחוק תמונות מצב ולשבש יומני אבטחה. דוחות איומים על שימוש לרעה בפלטפורמות גיבוי, כולל ניתוחים כמו כופר המכוונים למערכות גיבוי, מתארים תוקפים הנכנסים לקונסולות, מוחקים משימות שמירה ומשחיתיים ארכיונים לפני הפעלת הצפנה. סטטוס "ירוק לחלוטין" בקונסולת גיבוי שווה מעט אם ניתן לזייף אותו או אם גיבויי יומנים ותצורה נמצאים באותו רדיוס פיצוץ - כלומר היקף המערכות שנפגעו מכשל או התקפה אחת - כמו ייצור. לקוחות ומבקרים החלו להסתכל מעבר לתוויות ספקים ולבקש ראיות לכך שגיבויים מתוכננים ומופעלים תוך התחשבות באיומים אלה.
רגולטורים וחברות ביטוח מוסיפים לחץ נוסף. כללים מגזריים ומשטרי דיווח אירועים רבים מניחים כיום שארגונים יכולים לשחזר תקופה של אירועים מיומנים ולשחזר שירותים באמצעות תצורות שנשמרו. הנחיות רגולטוריות בנוגע לשמירת יומנים וטיפול באירועים, כגון ציפיות תגובה לאירועים עבור נתוני יומן, מתייחסות יותר ויותר ליכולת להפעיל מחדש אירועים מיומנים ולבנות מחדש מתצורות מאוחסנות כתנאי מוקדם בסיסי. כאשר הלקוחות שלכם מבצעים מיקור חוץ של פעולות, הם מסתמכים על תנוחת הגיבוי שלכם כדי לעמוד בהתחייבויות אלה. רישומי הסיכונים הפנימיים שלהם מתייחסים יותר ויותר לגיבויים של צד שלישי כפריט שורה, וסקירות סיכונים של ספקים בוחנות לעומק את האופן שבו אתם מטפלים ביומנים, תצורות ובדיקות שחזור.
בסקר ISMS.online לשנת 2025, כ-41% מהארגונים ציינו ניהול סיכוני צד שלישי ומעקב אחר תאימות ספקים כאחד מאתגרי האבטחה העיקריים שלהם.
כל זה אומר שגיבוי כבר אינו נישה טכנית שקטה. זהו חלק מהאופן שבו לקוחות שופטים את האמינות שלכם, כיצד מבקרים שופטים את בגרות הבקרה שלכם, וכיצד הדירקטוריון שלכם שופט את החשיפה שלכם. תקן ISO 27001:2022, בקרה A.8.13 - "גיבוי מידע" - הפכה לאחת העדשות שדרכן הם עושים זאת. פרשנות על A.8.13 עבור ספקי שירותים, כגון פרשנויות הממוקדות בספקי שירות של הבקרה, מציינת במפורש שלקוחות, מבקרים וחברות ביטוח משתמשים כעת בבקרה זו כדי להעריך עד כמה ספקי שירותי ניהול (MSP) שומרים את המידע הדרוש לשחזור וחקירה. בסעיפים הבאים, תראו מה בקרה זו דורשת מכם בפועל כספקי ניהול שירותי ניהול (MSP), וכיצד תוכלו להפוך את הדרישות הללו לתקן גיבוי ברור ובר הגנה עבור יומני לקוחות, תצורות ומערכות תפעול.
כיצד עברו גיבויים מניהול משק בית פשוט לדאגה אסטרטגית של ניהול ניהול ספקי שירות (MSP)?
גיבויים עברו מניהול משק בית ברקע לדאגה אסטרטגית של ניהול מערכות ניהול (MSP) מכיוון שעיזבונות מורכבים, תקריות ציבוריות ולקוחות קשים יותר חשפו עד כמה שחזור וחקירות תלויים ביותר משרתי קבצים. מה שהיה בעבר משימה לילית שקטה הפך כיום לתחום רב-פלטפורמתי עם השפעה מסחרית ישירה.
גיבויים היו בעבר עבודה תפעולית פשוטה: הרצת משימות ליליות, סיבוב מדיה, שליחת עותקים מחוץ לאתר ומדי פעם בדיקת שחזור. ההיקף היה ברובו ברור - שרתי קבצים, מסדי נתונים של יישומים, אולי כמה מכונות וירטואליות - ולקוחות כמעט ולא שאלו שאלות מפורטות. הסביבה הייתה פשוטה יותר, וכך גם הציפיות.
כיום, הנכס שלכם משתרע ככל הנראה על תשתית מקומית, עננים ציבוריים מרובים, פלטפורמות SaaS, מערכות זהות מודרניות, כלי אבטחה ורשימה ארוכה של התקני קצה. יומני רישום ונתוני תצורה נמצאים במקומות רבים: מדדי SIEM, התקני חומת אש ו-VPN, פורטלים של ניהול, מערכות ניהול תצורה ומאגרי קוד. רבות ממערכות אלו הן כיום קריטיות לעסקים בפני עצמן. אובדן ההיסטוריה או קווי הבסיס שלהן יכול להיות מזיק בדיוק כמו אובדן שיתוף קבצים.
במקביל, הלקוחות הפכו משכילים יותר. הם מביאים את המבקרים שלהם, שאלוני ביטוח סייבר ותקנים פנימיים. כשהם שואלים "האם אתם מגבים הכל?" הם כמעט ולא מתכוונים ל"האם אתם מגבים את שרת הקבצים?" הם מתכוונים ל"האם אתם יכולים לשקם את היכולת שלנו לפעול בבטחה ולהוכיח מה קרה אם משהו ישתבש?" זוהי שאלה רחבה ותובענית הרבה יותר, וזה בדיוק התחום ש-A.8.13 דוחף אתכם לחשוב עליו.
השינוי אינו רק טכני. הוא משנה את האופן שבו לקוחות ומבקרים מעריכים אותך. החלטות גיבוי משפיעות כעת על חידושים, על דירוגי סיכון ספקים ועל היכולת שלך להתחרות על לקוחות גדולים ומוסדרים יותר.
מדוע יומנים ותצורות כל כך חשובים בהפסקות חשמל ובחקירות?
יומני רישום ותצורות חשובים מאוד בהפסקות חשמל ובחקירות משום שהם עונים על שתי שאלות מרכזיות לאחר תקרית: מה קרה, ואיך חוזרים בבטחה למקום בו הייתם? בלעדיהם, התאוששות הופכת לניחושים וקשה לבנות מחדש אמון.
כאשר קורה משהו רציני - מתקפת כופר, תצורה שגויה קריטית, הפסקת פעילות בענן - שתי שאלות שולטות עבור הלקוחות שלכם ובעלי העניין שלהם:
- כמה מהר נוכל לחזור למצב בטוח ופעיל?
- איך אנחנו יודעים מה באמת קרה?
יומני רישום הם המקור העיקרי שלך למענה על השאלה השנייה. הם מראים אילו חשבונות היו בשימוש, אילו כתובות IP התחברו, אילו שינויים בוצעו ואילו מערכות נפגעו. אם יומני רישום מרכזיים חסרים או לא שלמים, ייתכן שלעולם לא תוכל להוכיח את היקף ההתקפה, לספק חוקרים או מועצת לקוחות, או להוכיח כי מולאו חובות רגולטוריות.
תצורות הן מרכזיות לשאלה הראשונה. הן מגדירות כיצד חומות אש מסננות תעבורה, כיצד מערכות זהות אוכפות גישה, כיצד VPN ומכשירי SD-WAN מנתבים נתונים, כיצד פלטפורמות SaaS אוכפות מדיניות אבטחה וכיצד עבודות גיבוי עצמן מוגדרות. אם לא ניתן לשחזר במהירות את קווי הבסיס הללו מנקודה ידועה כטובה, כל שחזור הופך לתרגיל שחזור ידני ואיטי, מלא ניחושים וסיכונים.
ברבים מהאירועים הכואבים ביותר, הנתונים - קבצים, מסדי נתונים - היו ניתנים לשחזור מספיק. הנזק האמיתי נבע מיומני רישום ותצורות חסרים או לא עקביים. סקירות פורנזיות לאחר אירוע, כולל ניתוחים של אובדן תצורת חומת האש ופערים ביומני SIEM, מראות לעתים קרובות שהיעדרם של חפצים אלה הפך אירועים שניתן היה לנהל אחרת למשברים ממושכים בעלי היקף לא ברור והתאוששות מאוחרת. A.8.13, כפי שפרש עבור ספקי שירותי ניהול שירותים (MSPs), עוסק בחלקו בכך שזה לא יקרה ללקוחות שלכם, ושאתם יכולים להוכיח זאת כשאתם נמצאים תחת פיקוח רציני.
יומני רישום ותצורות, המטופלים כאובייקטי גיבוי מהשורה הראשונה, הופכים לחלק מרכזי במערכת התגובה לאירועים ואבטחת המידע שלכם, ולא רק לפרטים טכניים ברקע.
הזמן הדגמהמה באמת דורש תקן ISO 27001 A.8.13 מספקי שירותי ניהול (MSPs) עבור יומני רישום ותצורות?
תקן ISO 27001 A.8.13 מצפה מכם להגדיר, להפעיל ולהדגים משטר גיבוי המכסה מידע, תוכנה ומערכות בהתאם למדיניות מוסכמת. עבור ספקי שירותי ניהול שירותים (MSPs), זה כולל יומני לקוח ותצורות בכל מקום בו הם נדרשים לשחזור, ניטור או תאימות, ולא רק נתונים מסורתיים כמו שיתופי קבצים ומסדי נתונים.
דו"ח מצב אבטחת המידע לשנת 2025 מצביע על כך שלקוחות מצפים יותר ויותר מספקיהם להתאים את עצמם למסגרות פורמליות כגון ISO 27001, ISO 27701, GDPR, Cyber Essentials ו-SOC 2.
תקן ISO 27001:2022 נספח A לבקרה A.8.13 קובע, במהותו, כי יש לתחזק ולבדוק באופן קבוע עותקי גיבוי של מידע, תוכנה ומערכות בהתאם למדיניות גיבוי מוסכמת, כך שתוכלו לשחזר את הביצועים לאחר אובדן או הפרעה. פרשנויות לתקן המתמקדות בספקי שירותים (MSP), כגון פרשנויות ספקי שירות על A.8.13, מנסחות זאת מחדש כדרישה לתכנן ולבדוק הסדרי גיבוי שיכולים לעמוד בתרחישי כשל ואיומים מציאותיים, ולא רק להתקיים על הנייר. עבור ספקי שירותים (MSP), דרישה זו חלה הן על המידע שלכם והן על המערכות והנתונים שאתם מנהלים מטעם הלקוחות.
מבחינה מעשית, A.8.13 מצפה ממך להחליט, לתעד ולהדגים מה אתה מגבה, כיצד, באיזו תדירות, כמה זמן אתה שומר אותו, כיצד אתה מגן עליו וכיצד אתה מוכיח שניתן לשחזר אותו. יומני לקוח ונתוני תצורה נופלים במסגרת זו בכל פעם שהם נחוצים כדי לעמוד ביעדי שחזור מוסכמים, צרכי ניטור אבטחה או חובות משפטיות ורגולטוריות.
כדי להפוך זאת למוחשי, כדאי לחלק את הבקרה לארבע שאלות:
- תְחוּם: אילו מידע, תוכנות ומערכות נמצאים במסגרת הגיבוי, ומדוע?
- מבצע: כיצד מתבצעים גיבויים, כיצד מוגנים ומנוטרים?
- בדיקה: כיצד מוודאים שהשחזורים פועלים ועומדים ביעדי השחזור?
- עֵדוּת: כיצד מראים למבקרים וללקוחות שכל האמור לעיל אכן קורה?
עבור ספקי שירותי ניהול מערכות (MSPs), יש לענות על שאלות אלו פעמיים: פעם אחת עבור מערכת ה-ISMS הפנימית שלכם, ופעם אחת עבור השירותים שאתם מספקים ללקוחות. רבים מהתהליכים והכלים הבסיסיים יהיו משותפים, אך הסיכונים, החובות והציפיות שונים. זו הסיבה שאתם זקוקים לפרשנות ספציפית ל-MSP של A.8.13 במקום להסתמך על הנחיות ארגוניות כלליות.
פלטפורמת ISMS מובנית כמו ISMS.online יכולה לעזור לכם לקשר את מדיניות A.8.13 לנכסים, סיכונים ובקרות, כך שההיקף והאחריות עבור יומני רישום ותצורות יהיו ברורים וניתנים למעקב בכל בסיס הלקוחות שלכם. אם אתם רוצים מקום אחד להגדיר את הציפיות הללו ולשמור על יישור הראיות, ריכוזן במערכת כזו הוא לעתים קרובות האפשרות המעשית ביותר.
כיצד יש לפרש את A.8.13 בהקשר של MSP?
בהקשר של MSP, עליך להתייחס לכל מידע של הלקוח הדרוש לשחזור, זיהוי או חובות משפטיות כנכלל במסגרת A.8.13, להתאים את הגיבוי לבקרות קשורות כגון רישום וניהול שינויים, ולתעד בבירור את האחריות המשותפת במדיניות ובחוזים.
ראשית, התייחסו לכל מידע שאתם מנהלים עבור לקוחות הנחוץ לשיקום שירותים, זיהוי וחקירת אירועים או עמידה בחובות שמירה רשמיות, כחלק מתחום סעיף A.8.13. זה בדרך כלל כולל:
- יומני אבטחה מחומות אש, רשתות VPN, נקודות קצה, כלי זיהוי חדירות ופלטפורמות SIEM.
- יומני מערכת ויישומים בעלי ערך ראייתי או תפעולי עבור אירועים או ביקורות.
- נתוני תצורה עבור התקני רשת, כלי אבטחה, פלטפורמות וירטואליזציה, מערכות זהות ושירותי SaaS קריטיים.
- תבניות ותשתית כקוד המגדירות בניות סטנדרטיות וקווי בסיס.
יחד, פריטים אלה מהווים את עמוד השדרה של יכולתך להוכיח מה קרה ולבנות מחדש בבטחה.
שנית, יש להכיר בכך ש-A.8.13 אינו קיים בבידוד. הוא משתלב עם בקרות על רישום, ניהול שינויים, בקרת גישה, המשכיות עסקית וקשרי ספקים. לדוגמה:
- בקרות רישום דורשות ממך לשמור יומני רישום חשובים; סעיף A.8.13 שואל כיצד משחזרים אותם לאחר הפסקות חשמל.
- בקרות ניהול שינויים עוקבות אחר שינויי תצורה; A.8.13 שומר על גרסאות תקינות ידועות.
- בקרות המשכיות עסקית מגדירות יעדי התאוששות; סעיף A.8.13 הוא דרך אחת להשגת יעדים אלה.
יישור זה עוזר לך להימנע מעבודה כפולה וציפיות סותרות בין סטנדרטים ושירותים.
שלישית, הביטוי "מדיניות גיבוי ספציפית לנושא" הוא חשוב. משמעות הדבר היא שאסור להסתיר את ציפיות הגיבוי בתוך מדיניות אבטחת מידע כללית. צריכה להיות לכם מדיניות גיבוי או תקן ייעודי המתייחס במפורש ללוגים ותצורות, מתאר תחומי אחריות ומגדיר כיצד נגזרות ומיושמות דרישות.
לבסוף, היו ברורים לגבי אחריות משותפת. בתרחישים מסוימים, לקוחות ישמרו על האחריות לגיבוי נתונים ביישומי SaaS מסוימים או במערכות פנימיות. באחרים, ייתכן שתנהלו את הפלטפורמה, אך הלקוח הוא הבעלים של ההחלטות בנוגע לשמירה או מקורות יומן ספציפיים. סעיף A.8.13 אינו מחייב אתכם לקחת על עצמכם כל חובת גיבוי אפשרית, אך הוא מצפה מכם להיות מפורשים לגבי מי עושה מה, לכסות את הפיצולים בחוזים ובמדיניות, ולנהל סיכונים שיוריים. פרשנויות של סעיף A.8.13 המוכוונות ל-MSP, כולל הערות פרשניות לספקי שירותים, מדגישות חובה כפולה זו על פני מערכות ה-ISMS שלכם והסביבות שאתם מנהלים.
היכן יומני לקוח ותצורות משתלבים בטווח הגיבוי?
יומני לקוח ותצורות נופלים תחת תחום הגיבוי בכל מקום בו אובדנם יפגע ביעדי שחזור, יחליש את ניטור האבטחה או יפגע בציפיות משפטיות ורגולטוריות. תחום זה צריך להיות מפורש במדיניות הגיבוי שלך, ולא להניחו או להשאירו למהנדסים בודדים.
ספקי שירותי ניהול שירותים (MSP) רבים התייחסו באופן היסטורי ליומנים ותצורות כנפרדים מגיבויים:
- יומני רישום נתפסו כמשהו שחי במערכות SIEM או בכלי ניטור, לא כאובייקטי גיבוי.
- ההנחה הייתה שניתן לשחזר תצורות מתיעוד או סקריפטים, ולא להתייחס כנתונים ראשוניים הזקוקים לגיבוי.
תחת A.8.13, הנחות אלו אינן בטוחות עוד. אם זרם יומן או קבוצת תצורה נחוצים כדי לשחזר שירותים, לחקור אירועים, להוכיח תאימות או להשיג יעדי RPO/RTO מוסכמים, יש לכסות זאת במפורש על ידי משטר הגיבוי שלך.
זה לא אומר שאתם חייבים לגבות כל יומן שנוצר על ידי כל מכשיר לאותו פרק זמן. זה כן אומר שאתם צריכים:
- זהה אילו מקורות יומן הם קריטיים לאבטחה, תפעול ותאימות.
- החליטו אילו מבין אלה זקוקים לגיבוי עצמאי מעבר למכשיר המקומי או למאגר היומנים הראשי.
- ציינו תקופות שמירה בהתבסס על סיכון, רגולציה ודרישות הלקוח.
- כללו את ההחלטות הללו במדיניות הגיבוי שלכם, במלאי הנכסים ובתיאורי השירות.
סיכום ברור של זה בתקן שלכם מונע הנחות והפתעות כאשר מתרחש אירוע או ביקורת.
אותו היגיון חל על תצורות. סוגי מכשירים מסוימים - חומות אש, שערי VPN, מתגי ליבה, מערכות זהות, פלטפורמות גיבוי עצמן - הם עמודי התווך של האבטחה וההמשכיות של הלקוחות שלך. יש לגבות את התצורות שלהם, לנהל גרסאות, להגן ולבצע בדיקות-שחזור מעת לעת, בזהירות כמו כל מסד נתונים אחר.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
איך עוברים מ"אנחנו עושים גיבויים" לסטנדרט גיבוי ראשי?
אתם עוברים מ"אנחנו עושים גיבויים" לסטנדרט גיבוי ראשי על ידי הגדרת קו בסיס אחד כלל-MSP עבור היקף, תדירות, שמירה, הגנה, בדיקות וראיות, ולאחר מכן יישום עקבי שלו על פני לקוחות עם וריאציות מבוקרות עבור שכבות וחוזים.
כשני שלישים מהארגונים בסקר ISMS.online לשנת 2025 אמרו כי המהירות והיקף השינויים הרגולטוריים מקשים על קיום תאימות.
כדי לעמוד בדרישות A.8.13 בקנה מידה גדול ולהפחית את הסיכון המסחרי, עליכם לעבור מהרגלי גיבוי אד-הוק לפי לקוח, לכיוון תקן גיבוי ראשי יחיד עבור ספק שירותי ה-MSP שלכם. תקן זה קובע את הציפיות המינימליות לגבי אופן גיבוי ובדיקה של מידע, כולל יומני רישום ותצורות, בכל הלקוחות, ומגדיר את הפרמטרים שיכולים להשתנות בהתאם לרמת השירות או לחוזה.
תקן גיבוי ראשי אינו חוברת שיווק; זהו כלי ניהול. הוא אומר למהנדסים שלכם מה עליהם לעשות, לצוותי המכירות שלכם מה הם רשאים להבטיח, לפונקציית התאימות שלכם מה להוכיח, וללקוחות שלכם למה הם יכולים לצפות.
לכל הפחות, זה צריך לכסות:
- היקף ושיעורי נתונים.
- תדירות ושיטות גיבוי.
- תקופות שמירה וכללי השמדה.
- אמצעי הגנה כגון הצפנה, בקרת גישה, הפרדה ואי-יכולת שינוי.
- ניטור וטיפול בחריגים.
- בדיקות שחזור, כולל דגימה של יומני רישום ותצורות.
- דרישות תיעוד והוכחות.
ברגע שיש לכם את התקן הזה, תוכלו להגדיר אותו לפי לקוח: אותו מבנה, ערכים מותאמים. שימוש בפלטפורמה כמו ISMS.online כדי להחזיק את התקן הזה כמסמך מבוקר ולקשר אותו לסיכונים ובקרות מקל על שמירת המדיניות, היישום והראיות מסונכרנים. אם אתם רוצים מקום אחד שבו מהנדסים, מבקרים וצוותי מכירות יוכלו להתייחס לאותם כללי גיבוי, ריכוזם בדרך זו הוא לעתים קרובות בחירה פרגמטית.
מדוע תקן גיבוי ראשי חשוב מבחינה מסחרית ותפעולית?
תקן גיבוי ראשי חשוב משום שהוא מפחית נקודות מתות, תומך באספקה חוזרת ומעניק לך עמדה טובה מול מבקרים ולקוחות. בלעדיו, כל לקוח הופך לחד פעמי, מה שמגדיל את הסיכון והעלות.
ללא תקן אב, כל לקוח בסופו של דבר מטופל כפעולה חד פעמית. מהנדסים שונים מגדירים גיבויים בדרכים מעט שונות. אנשי מכירות מבטיחים הבטחות על סמך עסקאות בודדות. תיעוד חי בכרטיסים ובראשי חשבונות. כאשר מגיע ביקורת או אירוע חמור, ייתכן שתגלו שכיסוי הגיבוי, השמירה והבדיקות משתנים מאוד בין לקוחות, ללא נימוק ברור.
חוסר עקביות זה מסוכן בכמה אופנים:
- זה מגדיל את הסיכוי שמקור יומן קריטי או קבוצת תצורה הוזנחו לחלוטין.
- זה מקשה על ההוכחה לרואי חשבון או לחברות ביטוח שיש לכם גישה מכוונת ומבוססת סיכונים.
- זה מנפח את התקורה התפעולית, כי יש לזכור ולנהל כל חריג באופן ידני.
- זה חושף אותך לטענות של יחס לא הוגן אם לקוח אחד מקבל הגנה חזקה משמעותית מאחר ללא סיבה מתועדת.
תקן אב מספק לכם נקודת ייחוס. הוא הופך את קטלוג השירותים שלכם לברור יותר: כל שירות מנוהל כולל ציפיות גיבוי מוגדרות. הוא מקל על חידושים ודו"חות QBR: אתם יכולים להראות ללקוחות כיצד רמת השירות שלהם מתאימה ליכולות הגיבוי. זה גם נותן להנהלה שלכם יותר ביטחון שאתם לא נושאים סיכון שקט ולא אחיד על פני בסיס הלקוחות.
מה שייך לתקן גיבוי ראשי ריאלי של MSP?
תקן גיבוי ראשי ריאלי מגדיר, עבור כל מחלקת נתונים, מדוע מגבים אותו, כיצד עושים זאת, כמה זמן שומרים אותו וכיצד מוכיחים ששחזורים פועלים. הוא צריך להיות ברור מספיק כדי שמהנדסים ומבקרים יוכלו ליישם אותו ללא ניחושים, ופשוט מספיק לתחזוקה.
כשאתם מנסחים את התקן שלכם, התמקדו בבהירות ובישימות. עבור כל סוג נתונים - יומני אבטחה, יומני תפעול, תצורות, תמונות מערכת, מסדי נתונים - ציינו:
- מטרה: מטרת גיבוי מחלקת נתונים זו.
- תְחוּם: מקורות אופייניים כלולים כברירת מחדל, וכאשר נדרשת הסכמה מפורשת.
- תדירות: באיזו תדירות מתרחשים גיבויים או ייצוא, במונחים פשוטים.
- שימור: תקופות מינימום ומקסימום, הקשורות לחוקים או לחוזים במידת הצורך.
- הֲגָנָה: הצפנה, בקרת גישה, פילוח וכל דרישות אי-שינוי.
- בדיקה: באיזו תדירות נבדקים שחזורים ואיך נראית הצלחה.
- עֵדוּת: תופעות צפויות בביקורת, כגון מדיניות, תצורות משרה ודוחות לדוגמה.
החזקת תקן זה בתוך מערכת ניהול מידע (ISMS) כמו ISMS.online מקלה על שמירה על איזון בין כל המערכות ככל שתצמחו. ניתן לקשר אותו ישירות לנספח A.8.13, לבקרות קשורות ושירותי לקוחות ספציפיים, כך שאותו עמוד שדרה יתמוך במכירות, באספקה ובאבטחת מידע.
תקן מובנה היטב הופך גם לרשימת תיוג פנימית להטמעת שירותים ופלטפורמות חדשים, מה שמקשה הרבה יותר על מקורות יומן או תצורות קריטיים ליפול בין הכיסאות.
איך הופכים RPO/RTO למציאותיים עבור יומנים, תצורות ומערכות?
אתם הופכים RPO ו-RTO למציאותיים על ידי סיווג נתונים, הגדרת קבוצה קטנה של שכבות ריאליות, ובדיקה האם תהליכי הגיבוי והשחזור שלכם אכן עומדים ביעדים אלה עבור יומני רישום, תצורות ומערכות על פני לקוחות.
יעד נקודת שחזור (RPO) ויעד זמן שחזור (RTO) הם עמוד השדרה של כל אסטרטגיית גיבוי רצינית. עבור ספקי שירותי ניהול שירותים (MSPs), האתגר הוא לתרגם את המושגים הללו משפת המדיניות להתנהגויות קונקרטיות וניתנות לבדיקה עבור סוגים שונים של נתוני לקוח - במיוחד יומני רישום ותצורות.
RPO עוסק בכמות הנתונים שאתם יכולים להרשות לעצמכם לאבד, מבוטאת בזמן. RTO עוסק בכמה זמן אתם יכולים להרשות לעצמכם להיות ללא מערכת. עבור לקוחות רבים, ערכים אלה ישתנו בין יישומים, סביבות ומערכי נתונים. עבורכם, המשימה היא לתכנן מספר קטן של שכבות גיבוי שיכולות לעמוד באופן ריאלי בדרישות המעורבות הללו מבלי לקרוס תחת מורכבות.
עבור יומני רישום ותצורות, משמעות הדבר היא לעתים קרובות קבלת העובדה שלא תתייחסו לכל מקור באופן שווה. חלק מהיומנים קריטיים לאבטחה וחייבים להיות כמעט בזמן אמת ושמורים לאורך זמן. אחרים שימושיים אך אינם חיוניים. חלק מהתצורות משתנות לעתים קרובות ובעלות השפעה גבוהה; אחרות הן סטטיות יחסית. רמות ה-RPO וה-RTO שלכם צריכות לשקף את ההבדלים הללו, ומשטרי הגיבוי שלכם צריכים להתאים.
יעדים ברורים לגבי זמני הפסד והתאוששות מונעים מ-RPO ו-RTO להיות הבטחות מעורפלות על הנייר והופכים אותם ליעדים קונקרטיים שניתן לבנות ולבחון מולם.
מדוע כדאי לסווג נתונים לפני הגדרת RPO ו-RTO?
עליך לסווג נתונים לפני הגדרת RPO ו-RTO מכיוון שסיווג מאפשר לך להחיל מספר מטרות הגיוניות על פני מערכות רבות במקום לטבוע בחריגים לכל מקור ובהבטחות לא מציאותיות.
אם תנסו להגדיר ערכי RPO ו-RTO ישירות מול כל מערכת מקור בנפרד, תטבעו בתמורות. במקום זאת, סווגו נתונים למספר קבוצות בעלות משמעות עסקית. לדוגמה:
- דרגה א': ראיות קריטיות לאבטחה ותאימות.
- סוג B: יומני תפעול ותצורות הנדרשים להמשכיות.
- סוג C: יומני רישום ותצורות בעלי השפעה נמוכה יותר שבהם שחזור אפשרי או שההשפעה מוגבלת.
לאחר שיהיו לכם מחלקות נתונים, תוכלו להקצות יעדי RPO, RTO ושימור ברירת מחדל לכל אחד מהם. יעדים אלה צריכים להתבסס על מקרי שימוש של הלקוח, ציפיות רגולטוריות ויכולת טכנית שלכם, ולא על משאלות לב. לאחר מכן תוכלו להתאים את התוצאות לכל לקוח כאשר יש סיבה טובה, באמצעות מנגנון חריגים רשמי.
דרך פשוטה להעביר זאת היא לבנות טבלה של מחלקות ומטרות:
| מחלקת נתונים | רמת RPO/RTO אופיינית | נהגים לדוגמה |
|---|---|---|
| כיתה | RPO ≤ 15 דקות, RTO ≤ 4 שעות | חקירות אבטחה, יומני תאימות |
| Class B | RPO ≤ 4 שעות, RTO ≤ 24 שעות | המשכיות בפעילות הליבה |
| Class C | RPO ≤ 24 שעות, RTO ≤ 72 שעות | פתרון בעיות, עומסי עבודה בעלי השפעה נמוכה יותר |
ניתן להשתמש במודל זה בדיונים עם לקוחות ובמפגשי תכנון פנימיים. הוא נותן למהנדסים יעד ברור לכל מחלקה ומספק למבקרים משהו מובן לבדיקה.
איך שומרים על יעדי RPO/RTO כנים ובר השגה?
אתם שומרים על יעדי RPO ו-RTO כנים על ידי מידול קיבולת, יישור מכירות עם הנדסה, מדידת ביצועים בפועל וכלילת בדיקות שחזור ריאליות המכסות יומני רישום ותצורות, ולא רק עומסי עבודה קלים.
נתוני RPO ו-RTO קלים להקלדה וקשים למסירה. כדי להימנע מהבטחות יתר:
- קיבולת וביצועי המודל: הערך את נפחי הנתונים לכל מחלקה, ספירת לקוחות, חלונות גיבוי, רוחב פס והתנהגות אחסון ככל שתגדל.
- יישור מכירות עם הנדסה. הציעו כברירת מחדל רק תחומי RPO ו-RTO שאושרו, ונתבו בקשות מצומצמות יותר דרך סקירה ואישור.
- מדוד ביצועים אמיתיים.: מעקב אחר השגת RPO (גיל העותק האחרון והתקין) ו-RTO (זמן שחזור) לכל שכבה ולקוח, ותיקון צווארי בקבוק.
- הבדיקה משחזרת בצורה ריאליסטית.: כללו יומני רישום ותצורות מסביבות בעלות השפעה גבוהה בתרגילי השחזור שלכם, ותעדו זמנים מקצה לקצה.
לדוגמה, עבור יומני אבטחה מסוג A ותצורות חומת אש, ייתכן שתגדירו RPO של חמש עשרה דקות ו-RTO של ארבע שעות. לאחר מכן, תתכננו איסוף יומנים, תארכו משימות וייצוא תצורה כדי לתמוך במספרים אלה, ותפעילו בדיקות תקופתיות בהן תשחזרו תצורת חומת אש למכשיר מעבדה ותפעילו מחדש יומן של יומנים במערכת SIEM לבדיקה כדי לאשר שהיעדים מציאותיים.
עבור לקוחות, יש להסביר את ה-RPO וה-RTO בתרחישים ולא במספרים בלבד. לדוגמה: "אם חומת האש הזו מוגדרת בצורה שגויה בשעה 10:00, המטרה שלנו היא לשחזר את התצורה שלה מעותק אחרון שידוע כתקין בן לא יותר מ-15 דקות, ולהחזיר אותה לפעילות עד 11:00." זה מבהיר הרבה יותר את האחריות והפשרות.
ברגע שיש לכם תחומי RPO ו-RTO אמינים, השלב הבא הוא לתכנן ארכיטקטורות גיבוי שיכולות לספק אותן באופן עקבי על פני דיירים רבים, לא רק בתרחיש מעבדה יחיד.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
כיצד ניתן לתכנן ארכיטקטורות גיבוי מרובות דיירים עבור יומנים ותצורות?
אתם מתכננים ארכיטקטורות גיבוי מרובות דיירים על ידי החלטה היכן לרכז או לבודד, כיצד להפריד נתוני לקוח, כיצד ללכוד תצורות וכיצד לשמר את שלמות ראיות היומן בכל הדיירים באמצעות דפוסים המאזנים אבטחה עם יעילות.
כ-MSP, אתה כמעט ולא מפעיל סביבה אחת ומסודרת עבור ארגון יחיד. אתה מנהל סביבה מרובת משתמשים: לקוחות רבים, פלטפורמות רבות, כלים רבים. A.8.13 אינו אומר לך כיצד לעצב גיבויים בהקשר זה, אך הוא מצפה ממך לספק ולהוכיח גיבויים אמינים, מאובטחים וניתנים לבדיקה בכל המשתמשים הרלוונטיים.
השאלות האדריכליות המרכזיות הן:
- כיצד מפרידים נתוני לקוחות כדי למנוע חשיפה בין דיירים או מחיקה בשוגג?
- היכן מרכזים את העובדים לשם יעילות, והיכן מבודדים את העובדים לשם בטיחות?
- כיצד ניתן לאסוף, להגן ולגרס נתוני תצורה?
- כיצד מבטיחים שגיבויי לוגים ישמרו על שלמותם וערך ראייתי?
- כיצד אתם עוקבים אחר הבריאות והמוכנות ברחבי הסביבה כולה?
אינכם צריכים לשפץ את הכלים שלכם כדי לענות על שאלות אלה, אך אתם זקוקים לעיצוב מכוון שניתן להסביר ולהגן עליו בפני מבקרים ולקוחות.
אילו דפוסים תומכים בהפרדה מאובטחת ובפעילות יעילה?
דפוסי ניהול מרובי דיירים מאובטחים ויעילים משתמשים בהפרדה של נתונים ומפתחות לפי דייר, בנוסף לכלים וצנרת משותפים, כך שתוכלו לאזן בין אבטחה למורכבות ניתנת לניהול בפעולות היומיומיות.
רוב הארגונים שהשתתפו בסקר ISMS.online לשנת 2025 דיווחו כי הושפעו מלפחות אירוע אבטחה אחד של צד שלישי או ספק בשנה האחרונה.
הפרדה ויעילות נוטות למשוך לכיוונים מנוגדים. הפרדה חזקה דוחפת אותך לכיוון מערכות אחסון לפי דייר והפרדה קפדנית של תפקידי אחסון, מפתחות ותפקידי ניהול. יעילות מושכת אותך לכיוון תשתית משותפת, צינורות מרכזיים וכלים משותפים. רוב ספקי שירותי ניהול הרשת (MSP) נוטים לגישה היברידית:
- השתמש במפתחות הצפנה לכל דייר ובמאגרים מופרדים באופן לוגי, כך שפריצה של לקוח אחד לא תוכל להשפיע בקלות על גיבויים של לקוח אחר.
- מרכזו את איסוף היומנים היכן שזה הגיוני, אך תייגו ואחסנו עותקים מאוחסנים בדרכים שישמרו על גבולות ברורים של הדיירים.
- הפרידו את שמירת יומני התפעול משמירת יומני האבטחה אם אתם זקוקים לשליטה הדוקה יותר על ראיות.
- מזעור ובקרה של חשבונות בעלי הרשאות גבוהות שיכולים לשנות משימות גיבוי או למחוק ארכיונים.
לא משנה אילו דפוסים תבחרו, תעדו אותם בדיאגרמות ארכיטקטורה, מודלי איומים וספרי ריצה של תפעול. תיעוד זה הוא חלק מהראיות שלכם במסגרת A.8.13 ומהווה בסיס לטענותיכם כלפי לקוחות בנוגע ל"הבטחת גיבוי".
כיצד עליכם להתמודד עם גיבוי תצורה בעולם מגוון ועמוס בענן?
עליך לטפל בגיבוי תצורות על ידי התייחסות לתצורות כאל אובייקטי גיבוי ראשיים, אוטומציה של ייצוא, אחסון מאובטח שלהן והכללתן בבדיקות שחזור, במקום להניח שניתן תמיד ליצור אותן מחדש מסקריפטים או תיעוד.
גיבוי תצורה הוא לעתים קרובות החוליה החלשה ביותר בשחזור MSP. קל להניח שפלטפורמות ענן ומכשירים מנוהלים יזכרו את המדיניות שלהם, או שסקריפטים ומאגרי תשתית כקוד "מספיק טובים" כתיעוד. בפועל, עליך:
- אוטומציה של ייצוא קבוע או תמונות מצב של תצורות עבור מערכות ופלטפורמות קריטיות.
- אחסן ייצוא תצורה באחסון מבוקר גרסה, מבוקר גישה, ובאופן אידיאלי בלתי ניתן לשינוי.
- קשר גרסאות תצורה לרשומות ניהול שינויים לצורך מעקב והחזרה למצב קודם.
- כללו שחזורי תצורה בתוכנית הבדיקות שלכם, לא רק שחזורי מערכת מלאים.
התייחסו לארטיפקטים של תצורה כאל אובייקטי גיבוי מהשורה הראשונה, עם סיווג נתונים, RPO ו-RTO וכללי שמירה כמו כל מחלקה אחרת. פעולה זו פירושה שכאשר אתם מתמודדים עם אירוע מורכב, תוכלו ללכת מעבר ל"אנחנו יכולים לשקם אותו מחדש ידנית" ולומר במקום זאת, "אנחנו יכולים לשחזר אותו למצב תקין זה מרגע זה, והנה הראיות".
ככל שנוכחות הענן שלכם גדלה, תחום זה מגן עליכם גם מפני שינויים מקריים בקונסולות הספקים ומבטיח שהידע לא יילכד בראשם של מהנדסים בודדים.
איך מוכיחים שגיבויים עובדים ובונים מסלולי ביקורת מוכנים?
אתם מוכיחים שגיבויים עובדים על ידי שילוב של מדיניות ברורה, היקף מלא, משימות מנוטרות, בדיקות שחזור משמעותיות וראיות מאורגנות היטב, כך שמבקרים ולקוחות יוכלו לראות ש-A.8.13 פועל בפועל, לא רק על הנייר.
רק כאחד מכל חמישה ארגונים בדוח "מצב אבטחת המידע לשנת 2025" אמר כי נמנע לחלוטין מאובדן נתונים במהלך השנה האחרונה.
מנקודת מבטו של מבקר, גיבוי מידע יעיל אינו רק עניין של הגדרת כלים. מדובר ביכולת להראות ש:
- המדיניות והסטנדרטים שלכם קיימים ומיושמים.
- המערכות והנתונים הנכונים נמצאים בטווח.
- גיבויים בפועל פועלים, מנוטרים ומתוקנים כאשר הם נכשלים.
- שחזורים נבדקים, והבדיקות עומדות בקריטריונים מוגדרים להצלחה.
- הראיות הן מלאות, מדויקות וניתנות למעקב.
עבור ספקי שירותי ניהול נתונים (MSPs), ראיות אלו צריכות להיות ניתנות לשימוש חוזר בביקורות, לקוחות וסקירות פנימיות. אם תאספו אותן מאפס בכל פעם, תהיו מותשים ולא עקביים. חבילת ראיות מובנית עבור A.8.13 עוזרת להימנע מכך ומקלה על הטיפול בהערכות עתידיות.
מה צריכה להכיל חבילת ראיות A.8.13 עבור יומני רישום, הגדרות ומערכות?
חבילת ראיות A.8.13 צריכה להכיל את המסמכים והרשומות המרכזיים המראים מהו ההיקף, כיצד גיבויים מתבצעים, כיצד מטופלות בעיות וכיצד נבדקים שחזורים, עם כיסוי מפורש של יומני רישום ותצורות היכן שהם חשובים ביותר.
חבילת ראיות מעשיות תכלול בדרך כלל:
- מדיניות ותקנים: מדיניות הגיבוי הראשית שלך וכל תקן תומך המתייחס במפורש ליומני רישום ותצורות.
- מלאי נכסים: רשימות של מערכות, מקורות יומן ומאגרי תצורה בטווח הגיבוי, עם מחלקות נתונים ורמות RPO, RTO ושמירה שהוקצו.
- הגדרות משימת גיבוי: צילומי מסך או ייצוא המציגים כיצד משימות מוגדרות עבור לקוחות מייצגים - מה כלול, לאן זה מגיע, באיזו תדירות זה פועל.
- ניטור ודיווח: דוגמאות לדוחות גיבוי ולוחות מחוונים לתקופות נבחרות, המציגות שיעורי הצלחה, כשלים וכיצד מטופלים חריגים.
- שחזור רשומות בדיקה: יומנים ודוחות מתרגילי שחזור, כולל אילו פריטים שוחזרו, כמה זמן זה ארך והאם הושגו היעדים.
- רישומי שינוי: ראיות לכך ששינויים בהיקף מפעילים עדכוני גיבוי, או שחריגים נרשמים ומאושרים.
כדי להפוך זאת למוחשי, דמיינו לקוח מייצג אחד. חבילת הראיות שלכם עשויה להציג את הסעיף הרלוונטי במדיניות הגיבוי, את רשימת הנכסים עבור חומות האש וה-SIEM של אותו לקוח, את תצורת המשימה לייצוא ואחסון יומני רישום ותצורות אלה, דוח גיבוי חודשי המדגיש כשלים ותיקונים, ויומן שחזור-בדיקת עדכני שבו שוחזרו תצורת חומת האש ויומן רישום יומי לסביבת מעבדה ואומתו.
אם אתם משתמשים ב-ISMS.online, תוכלו לשמור את הארטיפקטים הללו מקושרים ל-A.8.13 ולבקרות קשורות, כך שתוכלו לאחזר הכל במהירות כאשר מבקר או לקוח תובעני מבקשים הוכחה, במקום לבנות מחדש את הסטורה מאפס בכל פעם.
כיצד ניתן להפוך את בדיקות השחזור למשמעותיות מבלי לשרוף את המהנדסים?
אתם הופכים בדיקות שחזור למשמעותיות על ידי דגימה הגיונית, כולל יומני רישום ותצורות, אוטומציה במידת האפשר והזנת התוצאות בחזרה לתכנון, כך שהבדיקות מחזקות את המשטר שלכם במקום להפוך למטלה של סימון תיבות.
בדיקות שחזור הן המקום שבו משטרי גיבוי רבים נכשלים. קל יותר להראות שהמשימות בוצעו מאשר להוכיח שהשחזורים יעבדו כצפוי. כדי להפוך את הבדיקות ליעילות אך בנות קיימא:
- היקף התוכנית שלך: אינך צריך לבדוק כל לקוח וכל מערכת בכל חודש; התחל לסובב לפי מחלקה ורמה.
- כלול יומני רישום ותצורות.: אל תגבילו את הבדיקות לתמונות שרת או שיתופי קבצים; כסו את הראיות החשובות ביותר.
- אוטומציה ורישום יעילים.: השתמש בסקריפטים ובתזמור כדי ליצור סביבות זמניות וללכוד תזמונים.
- החזר את התוצאות.: השתמש בתוצאות הבדיקה כדי לשפר את הארכיטקטורה ולהתאים תביעות RPO ו-RTO במידת הצורך.
לדוגמה, ייתכן שתתכננו בדיקה רבעונית שבה תשחזרו את תצורת חומת האש של לקוח מפתח ו-24 שעות של יומני אבטחה למעבדה, תאמתו את התצורה מול הבסיס שלכם ותאשרו שהיומנים מאפשרים לאנליסט לשחזר תרחיש מוגדר מראש. רישומים מבדיקה זו מחזקים הן את הביטחון התפעולי שלכם והן את מוכנותכם לביקורת.
עם הזמן, תוכנית בדיקות ממושמעת אך מציאותית הופכת לאחת ההבטחות החזקות ביותר שלך ללקוחות, לחברות הביטוח ולרגולטורים.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
כיצד ניתן להציע הבטחת גיבוי ללא אחריות בלתי מוגבלת?
אתם מציעים גיבוי של ביטחון על ידי הגדרת מה נמצא בהיקף, כיצד הוא מוגן ונבדק, ואילו סיכונים נותרו, במקום להבטיח למנוע כל הפסד. גישה זו מאפשרת לכם לתת ביטחון ללקוחות מבלי לקבל אחריות בלתי מוגבלת שאין לכם באמת שליטה עליה.
לקוחות מבקשים יותר ויותר "הבטחת גיבוי": ביטחון שהנתונים, הלוגים והתצורות שלהם יהיו ניתנים לשחזור במסגרת המגבלות המוסכמות, הנתמכים על ידי ראיות מוחשיות. הנחיות ללקוחות בנוגע להערכת הבטחות MSP, כגון מדריכי הערכה של הבטחת גיבוי, משקפות מגמה זו על ידי דחיפה לקונים לחפש סטנדרטים מתועדים, רישומי בדיקה והתחייבויות RPO/RTO ברורות במקום הבטחות מעורפלות. יחד עם זאת, לא ניתן לקבל באופן סביר אחריות פתוחה לכל תרחיש או פער נתונים אפשרי. האמנות היא להגדיר הבטחה במונחים של עיצוב, תהליך והוכחה, ולא ערבויות מוחלטות.
הבטחת גיבוי, כפי שמוגדרת בצורה הגיונית, פירושה שתוכלו לענות על שאלות כמו:
- מהו תחום הגיבוי עבור שירות ולקוח זה, ומדוע?
- אילו יעדי RPO, RTO ושימור חלים?
- כיצד גיבויים בנויים, מוגנים ומנוטרים?
- באיזו תדירות בדקת שחזורים עבור מערכות דומות, ואילו תוצאות התקבלו?
- אילו סיכונים נותרו, ומי הבעלים שלהם?
זה לא יכול להיות בכנות "אנחנו מבטיחים לעולם לא לאבד שום יומן או תצורה, לעולם", וזה לא יהיה מציאותי וגם לא ניתן לביטוח. במקום זאת, אתם ממצבים את עצמכם כספק עם משטר חזק, מגובה בראיות וגבולות ברורים.
כיצד אתם מנסחים הבטחת גיבוי בשיחות עם לקוחות?
אתם ממסגרים את אבטחת הגיבוי על ידי הדרכת לקוחות בסטנדרטים, בקטגוריות הנתונים ובתחומי האחריות שלכם במונחים מעשיים, תוך שימוש בתרחישים מציאותיים במקום ערבויות מעורפלות או התחייבויות בלתי מוגבלות.
התחילו בהסבר של תקן הגיבוי הראשי שלכם וכיצד הוא חל על הלקוח שמולכם. הציגו להם כיצד השירותים שלהם משתלבים בקטגוריות הנתונים וברמות הגיבוי שלכם, מה המשמעות בפועל (לדוגמה, "יומני חומת אש קריטיים: ריכוזיות כמעט בזמן אמת, שמירה למשך תשעים יום לפחות; תצורות חומת אש: ייצוא יומי ובדיקות שחזור חודשיות") והיכן קיימות סטיות.
היו מפורשים לגבי אחריות משותפת. לדוגמה:
- באפשרותך לגבות יומני תשתית ותצורות מרכזיים, אך הלקוח אחראי על ייצוא וגיבוי של יומני יישומים מסוימים ממערכות SaaS.
- ייתכן שתנהל את השמירה עבור זרמי יומנים מסוימים, אך הלקוח בוחר את משך הזמן בהתבסס על הדרישות הפנימיות שלו ומקבל את עלויות האחסון והביצועים הנלוות.
השתמשו בדוגמאות אמיתיות ואנונימיות במידת האפשר. לדוגמה, סקרו מקרה היפותטי שבו חשבון שנפרץ שינה את כללי חומת האש ולאחר מכן סנן נתונים. הסבירו אילו יומני רישום ותצורות משטר הגיבוי שלכם ישמרו, באיזו מהירות ניתן יהיה לשחזר אותם ומה זה יאפשר לצוות התגובה המשותף לעשות.
והכי חשוב, הימנעו מהבטחות מעורפלות. במקום "אנחנו תמיד מגבים הכל", אמרו "עבור שירות זה, אנו מתחייבים לגבות את הנתונים הבאים, בלוח זמנים זה, עם יעדי שמירה אלה, מנוטרים בדרך זו, ונבדקים בקצב זה". זה גם כנה יותר וגם משכנע יותר.
אם אתם רוצים שהתחייבויות ותרחישים אלו יתמכו על ידי סט אחד ועקבי של מדיניות וראיות בכל בסיס הלקוחות שלכם, פלטפורמת ISMS כמו ISMS.online יכולה לספק את המבנה הדרוש לכם.
כיצד כדאי לתרגם את הביטחון לחוזים והסכמי רמת שירות (SLA)?
אתם מתרגמים את הבטחת הביטחון לחוזים על ידי תיאור מדויק של היקף, RPO, RTO ואחריות, התאמתם לתקן ולארכיטקטורה של הגיבוי שלכם, ושימוש בפתרונות המשקפים את מה שאתם יכולים לספק ולהוכיח בצורה אמינה.
המסמכים המסחריים שלכם צריכים לשקף את המציאות הטכנית שלכם. ביטויים מעורפלים כמו "גיבויים סטנדרטיים בתעשייה" או "מאמצים מיטביים" מגנים מעט מאוד עליכם או על לקוחותיכם. במקום זאת:
- תאר במדויק את ההיקף: ציין את המערכות, הסביבות, מקורות הרישום וסוגי התצורה הכלולים. הבהיר מה אינו נכלל או דורש הכללה מפורשת.
- RPO, RTO ושימור ייחוס: השתמש בערכים מרמות הגיבוי שלך, וקשר אותם לשירותים שנרכשו.
- הגדירו אחריות: הגדר מי מגדיר, מנטר ומתחזק גיבויים; מי חייב להודיע על שינויים; ומי מחליט על מדיניות שמירה.
- קבעו פתרונות מציאותיים.: הימנעו מסעיפי הפסד תוצאתיים פתוחים הקשורים לכשלים בגיבוי. במקום זאת, התמקדו בזיכויי שירות, ביצוע חוזר ושיתוף פעולה בתגובה לאירועים.
- יישור קו עם המדיניות.: ודאו שהחוזים שלכם אינם מבטיחים יותר ממה שמדיניות הגיבוי והארכיטקטורה שלכם יכולות לספק.
על ידי כך, אתם מתאימים ציפיות המונעות על פי A.8.13 עם התחייבויות מחייבות מבחינה משפטית. אתם גם מקלים על ההגנה על עמדתכם לאחר תקרית: אתם יכולים להצביע על ההיקף המוסכם, להראות ראיות לכך שעמדתם בו ולדון בכל סיכון שיורי בצורה שקופה.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לכם לעבור מהנחות לגבי גיבויים למודל גיבוי מגובה בראיות, ניתן לביקורת וניתן להגנה מסחרית, התואם את ISO 27001 A.8.13 ובקרות קשורות. על ידי שימוש ב-ISMS אחד להגדרת תקן הגיבוי שלכם, מיפויו לשירותים ואחסון הראיות שלכם, אתם מקלים בהרבה על הצגת לקוחות ומבקרים שהמשטר שלכם מכוון, נבדק ותחת שליטה.
בדוח "מצב אבטחת המידע לשנת 2025", כמעט כל הארגונים ציינו השגה או שמירה על אישורי אבטחה כגון ISO 27001 או SOC 2 כעדיפות עליונה.
באותה סביבה, תוכלו להחזיק את תקן הגיבוי הראשי שלכם, לקשר אותו ישירות לנספח A.8.13 ולבקרות קשורות, ולמפות תקן זה לשירותים ולקוחות ספציפיים. זה נותן לצוותי אבטחת המידע והתאימות שלכם תמונה ברורה של האופן שבו ציפיות הגיבוי עבור יומני רישום, תצורות ומערכות מיושמות בפועל, וזה נותן למבקרים וללקוחות תובעניים דרך מובנית לבחון את מצבכם.
עבור צוותים טכניים, ריכוז תוכניות בדיקות ושחזור תוצאות מסיר חיכוכים רבים. מהנדסים כבר לא צריכים לחפש כלים שונים כדי להדגים שתצורה מסוימת גיבויה ושוחזרה בהצלחה במסגרת זמן נתונה. הם יכולים לראות, במקום אחד, אילו בדיקות בוצעו, מה עבר, מה נכשל ואילו פעולות מעקב ננקטו. זה תומך הן באבטחת מידע פנימית והן בחקירות חיצוניות.
ניתן גם ליצור דוחות אורגנו או תצוגות מבוקרות עבור לקוחות מרכזיים. במקום לשלוח צילומי מסך בדוא"ל או להרכיב מצגות בהתאמה אישית, ניתן להציג סיפור עקבי של "הבטחת גיבוי" שנלקח מנתונים חיים במערכת הניהול שלכם. זה עוזר לכם לענות על שאלות קשות בביטחון, מבלי לחשוף פרטים רגישים על לקוחות אחרים או על פעולות פנימיות.
לבסוף, יכולות ניהול זרימת עבודה ומשימות מאפשרות להקצות, לעקוב ולספק ראיות לפעולות הקשורות לגיבוי - כגון סקירת חריגים, עדכון כללי שמירה או תזמון בדיקות שחזור. זה סוגר את המעגל בין מדיניות, יישום והוכחה, ומראה שמשטר הגיבוי שלך הוא בקרה חיה, לא רק מסמך.
אם אתם רוצים לראות כיצד פלטפורמה מובנית יכולה לתמוך בגישה שלכם ליומני לקוחות, תצורות ומערכות, בחינת הדגמה של ISMS.online היא צעד מעשי הבא. היא מאפשרת לכם להשוות את כיסוי A.8.13 הנוכחי שלכם עם מודל מכוון וניתן לבדיקה, ולהחליט האם ISMS מרכזי יעזור לכם לבנות אבטחת גיבוי חזקה וגלויה יותר עבור הלקוחות שלכם והארגון שלכם.
שאלות נפוצות
היכן באמת מותח הגבול תקן ISO 27001 A.8.13 עבור גיבויים של יומני רישום ותצורות על ידי MSP?
תקן ISO 27001 A.8.13 מצפה מכם להתייחס ליומני לקוח ותצורות כנכסי מידע מהשורה הראשונה, עם משטר גיבוי שתוכנן, מתועד ונבדק במכוון. משטר זה חייב להראות למבקרים בדיוק מה מגובה, באיזו תדירות, היכן הוא מאוחסן, כיצד הוא מוגן וכיצד אתם יודעים ששחזורים אכן פועלים.
כיצד צריך MSP להגדיר "גיבוי מידע" עבור שירותים מנוהלים יומיומיים?
עבור ספק שירותים מנוהלים, "גיבוי מידע" אינו מוגבל למכונות וירטואליות או מערכות קבצים. הוא מכסה את כל הנתונים וההגדרות שתסתמך עליהם כדי:
- שחזור שירות הלקוח לאחר הפסקת חשמל
- חקירת אירוע ביטחוני חשוד
- הוכחו את מעשיכם בפני רשות הרגולטורית או בית המשפט
- הוכח שעמדת בהתחייבויות החוזיות שלך
זה בדרך כלל מכניס את הדברים הבאים לתחום:
- יומני אבטחה מחומות אש, VPN, EDR/AV, IDS/IPS ופלטפורמות SIEM
- יומני יישומים ופלטפורמה מרכזיים הנדרשים לפתרון בעיות או ניתוח פורנזי
- נתוני תצורה עבור מתגים, נתבים, חומות אש והתקני רשת אחרים
- פלטפורמות ספריות וזהויות כגון Active Directory ו-Entra ID / Azure AD
- ייצוא תצורה ברמת הדייר עבור שירותי SaaS וענן חשובים
עבור כל אחד מאלה, רואה חשבון יצפה לראות שיש לך:
- הוחלט ותיעד אילו יומני רישום וסטים של תצורה חשובים לשחזור ואחריות
- שיטות גיבוי או העברה מוגדרות (לדוגמה, צינורות SIEM, תמונות מצב, ייצוא API)
- קביעת תקופות שמירה, מיקומי אחסון ובעלות על החלטות אלו
- יישום בקרות טכניות מתאימות (הצפנה, בקרת גישה, הפרדה, לעיתים אי-יכולת שינוי)
- בדיקות שחזור תקופתיות מתוכננות ומתועדות הכוללות יומני רישום ותצורות, לא רק שרתים
אינך זקוק לפילוסופיה שונה לכל לקוח. תקן גיבוי יחיד במערכת ה-ISMS שלך, אשר קורא במפורש ללוגים ותצורות כנכסים הנמצאים תחת A.8.13, ולאחר מכן מקשר להיקפים, משימות וראיות שחזור ספציפיים ללקוח, בדרך כלל מספיק כדי לספק את המבקרים ולהרגיע לקוחות גדולים יותר. ISMS.online עוזר בכך שהוא מספק לך מקום אחד לאחסן את התקן הזה, למפות את A.8.13 לערכת הבקרה שלך ולחבר את המלאי, משימות הגיבוי ורשומות הבדיקה של כל לקוח כך שהמהנדסים, צוות המכירות והמבקרים שלך יעבדו כולם מאותה תצוגה.
כיצד יכול ספק שירותי ניהול שירותים (MSP) לתקנן את שכבות הגיבוי כאשר כל לקוח רוצה יעדי RPO ו-RTO שונים?
הגישה הקיימת ביותר היא לתכנן קבוצה קטנה של שכבות גיבוי עם טווחי RPO, RTO ושימור קבועים, ולאחר מכן להקצות כל מערכת, מקור יומן וקבוצת תצורה לאחת מהשכבות הללו עבור כל לקוח. בדרך זו ניתן להציע בחירה משמעותית מבלי ליצור דפוס ייחודי לכל שירות.
כיצד מתרגמים את ההשפעה העסקית לשכבות גיבוי קונקרטיות?
נקודת התחלה מעשית עבור ספקי שירותי ניהול רשתות חברתיות רבים היא שלוש שכבות כגון:
- שלב 1 – מישור ראיות ובקרה:
יומני אבטחה, תצורות רשת ליבה וחומת אש, פלטפורמות זהות ורכיבים אחרים של מישור הבקרה
– RPO טיפוסי: דקות עד שעה • RTO: מספר שעות
- רמה 2 – נתוני המשכיות:
יומני ותצורות של יישומים המשפיעים באופן מהותי על זמינות השירות או על ההכנסות
– RPO טיפוסי: מספר שעות • RTO: יום העסקים הבא
- רמה 3 – תמיכה ביומני רישום:
יומני תפעול שגרתיים ומערכות בעלות השפעה נמוכה
– RPO טיפוסי: יומי • RTO: "מאמץ מיטבי" לחקירות בלבד
עבור כל רמה עליך להגדיר, במערכת ה-ISMS שלך:
- יעדי התאוששות (RPO/RTO) ושימור מינימלי
- מנגנוני גיבוי מותרים (לדוגמה, העברת SIEM, ייצוא מתוזמן, תמונות מצב)
- כללי אחסון והגנה (אזור, הצפנה, הפרדה לוגית, אי-יכולת שינוי אופציונלית)
- ציפיות מינימליות לבדיקת שחזור מכל בסיס הלקוחות שלך
לאחר מכן, אתם ממפים את השירותים, הלוגים וערכות התצורה של כל לקוח לשכבות אלו ומשקפים את המיפוי הזה בחוזים, ספרי ריצה ולוחות זמנים של אבטחה. במקום להבטיח RPO/RTO מותאם אישית לכל נכס, אתם יכולים לומר "שירות זה נמצא בשכבה 1, מה שאומר..." ולהראות ראיות מוכחות התומכות בהצהרה זו.
מידול שכבות ומיפויים אלו בתוך ISMS.online – וקישורם ישירות לנספח A.8.13 – פירושו שכל שינוי (לדוגמה, העברת חומת אש של לקוח משכבה 2 לשכבה 1 לאחר סקירת סיכונים) קשור לתקן הגיבוי, להגדרת השירות ולחבילת הראיות שלכם. ההתאמה בין מה שהבטחת המכירות, מה שהמהנדסים מפעילים ומה שרואים מבקרים היא לעתים קרובות ההבדל בין ביקורת חלקה לביקורת לא נוחה.
אילו ראיות ספציפיות משכנעות את מבקרי ISO 27001 שבקרת A.8.13 של MSP יעילה?
מבקרים רוצים לראות שמשטר הגיבוי שלכם למערכות, יומני רישום ותצורות הוא מכוון, עקבי ומוכח בפועל. בביקורת מבוססת דגימה, זה בדרך כלל אומר שילוב של סטנדרטים כתובים, מלאי, דוגמאות תצורה, פלטי ניטור ורישומי בדיקות שחזור, שכולם מספרים את אותה סיפור.
אילו חפצים כדאי שיהיו מוכנים לפני תחילת הביקורת?
עבור ביקור טיפוסי של מעקב או הסמכה, עליכם לצפות לשאלות בשלוש שורות:
- עיצוב והיקף:
- מדיניות גיבוי או תקן המתייחסים במפורש ליומנים ותצורות כנכסי מידע תחת A.8.13
- רשימת מלאי של שירותים או לקוחות המציגה אילו מערכות, מקורות יומן וערכות תצורה מכוסים, עם הרמות שלהם.
- יעדי RPO/RTO מתועדים וכללי שמירה לפי רמה או לפי קו שירות
- תפעול ובקרה:
- הגדרות מייצגות של משימת גיבוי (לדוגמה, תצורות חומת אש, ייצוא זהויות, צינורות SIEM, תמונות מצב של מסד נתונים)
- ניטור תצוגות או דוחות לאורך תקופה מוגדרת המציגים טיפול בהצלחה ובכישלון, עם ראיות למעקב
- רישומי שינויים המדגימים ששירותים, דיירים או מקורות יומן חדשים מוכנסים לטווח הגיבוי באמצעות תהליך חוזר
- יעילות ושיפור:
- שחזור-בדיקה רשומות הכוללות יומני רישום ותצורות, לא רק שרתים או מסדי נתונים
- הערות או פעולות מסקירות שבהן מבחן נכשל או הדגיש חולשה ושיניתם משהו כתוצאה מכך
מבקרים בדרך כלל מבינים שאירועים ועבודות כושלות קורים. מה שהם מחפשים הוא שרשרת קוהרנטית: הבקרה מוגדרת, התכנון מתועד, העבודות מבוצעות, כשלים מזוהים, ומבוצעות בדיקות שחזור מציאותיות ופועלים על פיהן.
אם מידע זה נמצא בקונסולות, תיבות דואר נכנס ותיקיות אישיות שונות, אתם והצוות שלכם תרגישו תחת לחץ בכל פעם שמבקר יבקש דגימה. אם במקום זאת תשתמשו ב-ISMS.online כדי להגדיר את בקרת A.8.13 פעם אחת, לצרף את תקן הגיבוי שלכם, לקשר את היקף ודוגמאות העבודה של כל לקוח, ולשמור על "חבילת ראיות גיבוי" רב פעמית, תוכלו לענות על רוב בקשות הדגימה ממקום אחד ולהדגים ש-A.8.13 נמצא תחת שליטה ולא מאולתר.
כיצד יכול ספק שירותי ניהול שירותי תקשורת (MSP) להבטיח ללקוחות גיבוי משמעותי מבלי לקחת על עצמו סיכון בלתי מוגבל?
אתם מבטיחים גיבוי לגבי תכנון, ניטור ובדיקות מבוססי ראיות בתוך גבולות ברורים, ולא לגבי הבטחה שלא יאבדו נתונים לעולם. לקוחות בדרך כלל מגיבים היטב להתחייבויות ספציפיות וניתנות לבדיקה לגבי היקף ורמות שחזור, המגובות בראיות עדכניות, והם חוששים יותר מהבטחות רחבות שלא ניתן לכבדן באופן מציאותי.
איך אתם מעצבים מתחם אבטחת מידע שמרגישה בטוחה ללקוחות ובת קיימא עבורכם?
הצהרת אחריות מעשית עונה על ארבע שאלות בשפה פשוטה:
- מה אנחנו מגנים: אילו מערכות, מקורות יומן וערכות תצורה מכוסים עבור כל שירות מנוהל
- כיצד אנו מגנים עליהם: שכבת הגיבוי הרלוונטית, RPO/RTO, כללי שמירה, מיקומי אחסון ובקרות טכניות מרכזיות
- איך אנחנו שומרים על עצמנו כנים: כיצד מנוטרות משימות גיבוי, כיצד מועברים כשלים ובאיזו תדירות נבדקים שחזורים
- היכן מתחילה האחריות שלך: מקורות נתונים שעליכם לייצא או לשמור, בחירות רגולטוריות שמניעות שמירה ממושכת והסיכונים הנותרים שנותרו
ניתן לתעד זאת ב"סקירת גיבוי ושחזור" קצרה וסטנדרטית שתופיע באופן עקבי בהצעות, בלוחות זמנים של אבטחה ובחומרי הטמעה. מאחוריהם, הצוותים שלכם מתחזקים מיפוי שכבות גיבוי עדכני, תצוגות סטטוס עבודה בזמן אמת וסיכומי בדיקות שחזור עדכניים עבור כל לקוח.
אחסון אלמנטים אלה בתוך ISMS.online וקישורם לבקרת A.8.13 שלך מאפשר לך להראות ללקוחות פוטנציאליים, ללקוחות קיימים, ובמידת הצורך, לרואי החשבון שלהם, שההתחייבויות הציבוריות שלך תואמות את המשטר שאתה מנהל בפועל. סוג כזה של הבטחה מדויקת ומוכחת נוטה להיות משכנעת יותר מאשר משפט פשוט של "לעולם לא נאבד את הנתונים שלך", והוא גם עוזר להגן על הארגון שלך אם אירוע ייבדק מאוחר יותר בפירוט.
אילו דפוסי שמירה והפרדה הגיוניים עבור גיבויים מרובי דיירים של יומני רישום ותצורות?
דפוס מעשי עבור רוב ספקי שירותי ה-MSP הוא להגדיר מספר תחומי שימור מבוססי סיכון ולשלב אותם עם הפרדה לוגית חזקה בכל פלטפורמת הגיבוי המשותפת. שילוב זה בדרך כלל עומד בציפיות האבטחה, הפרטיות והרגולציה, ועדיין משאיר מקום לחריגים חוזיים מוצדקים.
כיצד מאזנים בין ערך חקירתי, עלות ופרטיות בסביבה משותפת?
ספקים רבים נוקטים בגישה הבאה:
- רצועות שימור:
- חלון ברירת מחדל כגון 90 ימים של יומני אבטחה מקוונים ברוב הדיירים לצורך פעולות יומיומיות וחקירות בסיסיות
- שמירה ממושכת, לדוגמה 12–18 חודשים, עבור עומסי עבודה בסיכון גבוה יותר או בעלי פיקוח מוסדר כגון תשלומים, שירותי בריאות או תשתיות קריטיות
- שמירה קצרה יותר עבור יומני תפעול בעלי ערך נמוך, כאשר עלות האחסון וסיכון הפרטיות עולים על היתרונות של חקירה
- ארכיונים אופציונליים לטווח ארוך עבור מקורות "ראיות" ספציפיים שלקוחות מסוימים חייבים לשמור מסיבות משפטיות, חוזיות או רגולטוריות
- הפרדה והגנה:
- מפתחות הצפנה לכל דייר או מכולות אחסון, כספות או חשבונות נפרדים לוגית
- נתיבי גישה קפדניים כך שמהנדסים ואנליסטים של SOC רואים רק נתוני לקוח אחד בכל פעם
- גישה מבוססת תפקידים עם תפקידים בעלי הרשאות מועטות ביותר עבור פונקציות תמיכה, תפעול וניטור
- הגדרות בלתי ניתנות לשינוי או כתיבה חד פעמית עבור מאגרי ראיות מרכזיים שבהם שיבוש או מחיקה יהיו מזיקים במיוחד
מנקודת מבט של תקן ISO 27001, העיקר הוא לא רק שהאמצעים הללו קיימים, אלא שניתן לתאר ולהדגים אותם בצורה הגיונית לכל דייר:
- אילו יומני רישום ותצורה אתם מחזיקים עבור אותו לקוח
- כמה זמן כל קטגוריה נשמרת ובאילו מיקומים
- כיצד מיושמות ונבדקות הפרדה והגנה לאורך זמן
אם תדגמנו את העיצוב הזה ב-ISMS.online – תוך שימוש בתקן יחיד לשמירה והפרדה הממופה ל-A.8.13 ומקושר להיקפי לקוחות בודדים – יהיה קל הרבה יותר להצדיק את ההחלטות שלכם בפני מבקרים, קציני פרטיות ולקוחות וליישם שינויים עקביים כאשר החוק, הרגולציה או החוזים מתפתחים.
כיצד הופכים את נספח A.8.13 לשירות גיבוי מנוהל ברור וחוזר על עצמו, שגם אנשי המכירות וגם מבקרים מבינים?
אתם מתייחסים ל-A.8.13 כאל עמוד השדרה של שירות גיבוי ושחזור מנוהל, עם חבילות בעלות שם, RPO/RTO מוגדרים ורצועות שמירה (כולל עבור יומנים ותצורות), וחבילת אבטחה סטנדרטית, הכל נשלט באמצעות מערכת ה-ISMS שלכם. זה מאפשר לכם לעבור מהבטחות חד פעמיות לקטלוג יציב של שירותים שמכירות, אספקה, לקוחות ומבקרים מכירים כולם.
כיצד נראה שירות גיבוי ארוז, המותאם ל-A.8.13, בהקשר של MSP?
דרך פשוטה לבנות זאת היא להגדיר קבוצה קטנה של חבילות כגון:
- גיבוי חיוני:
שרתי ליבה ותצורות קריטיות; כיסוי יומן מוגבל; RPO/RTO סטנדרטיים ושמירה עבור לקוחות קטנים יותר או בעלי סיכון נמוך
- גיבוי מובטח:
שרתים בתוספת יומני אבטחה בעלי ערך גבוה יותר ותצורות בעלות השפעה גבוהה; RPO/RTO מהירים יותר ורמת שמירת "ראיות" ארוכה יותר לחקירות ותאימות
- גיבוי משופר:
כיסוי יומן רחב, שמירה מורחבת, ארכיונים בלתי ניתנים לשינוי ובדיקות שחזור תכופות יותר עבור לקוחות מוסדרים או בעלי סיכון גבוה
עבור כל חבילה שאתה מתעד:
- אילו סוגי נכסים מכוסים (מערכות, מקורות יומן, ערכות תצורה)
- ציפיות הגיבוי, ה-RPO/RTO, השמירה והאחסון/הגנה הרלוונטיות
- חלוקת האחריות בין הצוות שלך ללקוח
- נהלי הניטור והשחזור-בדיקות החלים
- כיצד החבילה מתאימה לנספח A.8.13 ולתחומים קשורים כגון רישום, ניהול אירועים והמשכיות עסקית
לאחר מכן:
- לכוד את תקן הגיבוי הראשי ואת הגדרות החבילה הללו פעם אחת ב-ISMS.online
- קישור חוזי לקוח, קטלוגי שירות ולוחות זמנים של אבטחה לחבילה הרלוונטית
- לשמור על תבנית סטנדרטית של ערכת ראיות שמהנדסים וצוות תפעול מעדכנים כחלק מפעילות עסקית רגילה
עם הזמן, זה נותן לכם שפה עקבית בהצעות ובשאלוני אבטחה ("אתם נמצאים ברמת הגיבוי המובטחת שלנו, הכוללת..."), נתיב ביקורת ברור וניתן לשימוש חוזר עבור ISO 27001 ומסלול קליטה קל בהרבה לחברי צוות חדשים. זה גם ממצב את הארגון שלכם כספק שהתחייבויות הגיבוי שלו לא רק בטוחות אלא גם מבוקרות באופן מוכח וניתנות לחזרה - בדיוק הרושם שלקוחות ומבקרים בעלי ידע מחפשים כשהם שואלים מה אתם עושים בנוגע לתקן A.8.13.
אם אתם רוצים דרך פרגמטית לעבור מהתיאוריה למעשה, תוכלו להתחיל בניסוח תקן גיבוי יחיד A.8.13 ב-ISMS.online, לשרטט את שלושת השכבות או החבילות הראשונות שלכם, ולמפות לקוח אחד בעל ערך גבוה לתוך מודל זה. ברגע שהדפוס הזה עובד עבורם, יהיה הרבה יותר קל לפרוס אותו על פני שאר תיק השירותים המנוהלים שלכם.
