מדוע רישום MSP נראה מספק - עד לביקורת ISO 27001
רישום של MSP נראה לעיתים קרובות מספק עד שעליך לשחזר אירוע ולגלות שהיומנים אינם יכולים לזהות סיפור ברור. מדריך זה הוא מידע כללי, לא ייעוץ משפטי, אך הוא משקף כיצד מבקרים, חוקרים וחברות ביטוח משתמשים ביומנים כדי לבחון את השירותים שלך ואת יישום תקן ISO 27001 A.8.15 שלך. רישום חזק הופך יום מבלבל לשביל ראיות שתוכל להגן עליו תחת לחץ.
רק כאחד מכל חמישה ארגונים בסקר ISMS.online לשנת 2025 אמר כי נמנע מכל צורה של אובדן נתונים בשנה הקודמת.
רישום טוב הופך אירועים כאוטיים לסיפורים שניתן לשחזר בפועל
הפער בין "יש לנו יומנים" לבין "יש לנו ראיות"
הפער בין יומני רישום לראיות נוצר כאשר לא ניתן להפוך אירועים גולמיים לציר זמן ברור וניתן להגנה עבור מבקרים. אכפת להם פחות מהעובדה שכלים יכולים ליצור יומני רישום, ויותר האם ניתן להוכיח מי עשה מה, מתי, מאיפה, ועם איזו תוצאה בכלי ה-MSP וסביבות הלקוח.
אצל ספקי שירות ניהול (MSP) רבים, שאלות אלו גורמות לעימות בין לוחות מחוונים של RMM, קונסולות חומת אש, פורטלי אבטחת דוא"ל, מרכזי ניהול ענן ומערכות כרטוס. חותמות הזמן אינן מתאימות מכיוון שהמכשירים נמצאים באזורי זמן שונים או שיש להם שעונים שזזו. פעולות ניהול קבורות במסלולי ביקורת מעורפלים. חלק מהשינויים הקריטיים חיים רק בשרשורי דוא"ל או צ'אט. בנפרד, כל כלי נראה "בסדר"; יחד, הם אינם מייצרים את הנרטיב הקוהרנטי ש-ISO 27001 מצפה לו במסגרת A.8.15.
דפוס נפוץ נוסף הוא שיוני גישה נגישים רק למספר קטן של מהנדסים בכירים. אנשים אלה יכולים לעתים קרובות לענות על שאלות מהזיכרון, אך זה אינו תחליף לראיות אובייקטיביות ועמידות בפני פגיעה. אם אחד מהם יעזוב מחר, היית מתקשה לשחזר את אותה כתבה מנתונים בלבד. מנקודת מבטו של מבקר, זה מצביע על כך שהארגון שלך מסתמך על אנשים פרטיים ולא על בקרה מתוכננת.
כיצד מבקרים בוחנים בפועל את בקרת הרישום שלכם
מבקרים מתחילים מהצהרת הבקרה, לא מרשימת התכונות של ספקי ה-SIEM שלכם, והם מתעניינים באופן שבו רישום תומך בזיהוי, חקירה ואבטחה. הם רוצים לראות שיומני פעילויות, חריגים, תקלות ואירועים רלוונטיים אחרים מופקים, מאוחסנים, מוגנים ומנותחים באופן מתוכנן התואם את כוונתכם המוצהרת.
בפועל, הם מחפשים תחילה כוונה כתובה: מדיניות, סטנדרטים לרישום ומטריצות אחריות שקובעות מה צריך להירשם, היכן, על ידי מי ולמשך כמה זמן. לאחר מכן הם משווים את הכוונה הזו לאופן שבו הסביבה שלך מתנהגת כעת. אם התיעוד שלך קובע שכל הפעולות הפריבילגיות במערכות הלקוח נרשמות באופן מרכזי למשך שנה לפחות, הם יבדקו טענה זו על לקוח אחד או שניים ועל מערכת אחת או שתיים.
במקומות בהם המסמכים שלכם והמציאות שונים זה מזה, מופיעות אי התאמות. אם ברירת מחדל של הכלים מכתיבה שמירה אך החוזים שלכם מבטיחים שנים של עקיבות, מבקרים ישימו לב לפער. אם אתם מסתמכים על צילומי מסך או גיליונות אלקטרוניים מכיוון שקשה לבצע שאילתות ביומנים או שהם נמחקו, הם יטילו ספק חשיבות ביעילות של A.8.15. לעתים קרובות זה המקום שבו ספקי שירותי ניהול נתונים (MSP) מבינים שאין להם ארכיטקטורת רישום; יש להם ערימת כלים. שאר המדריך מתמקד בסגירת הפער הזה באמצעות עיצוב שתוכלו להסביר וראיות שתוכלו להגן עליהן.
הזמן הדגמהמה דורש בפועל תקן ISO 27001:2022 A.8.15 רישום יערות
תקן ISO 27001 A.8.15 מצפה מכם לתכנן רישום כך שתוכלו לזהות אירועים, לחקור אותם ולהוכיח את מה שקרה באופן שתואם את הסיכונים והשירותים שלכם. הסברים עצמאיים של עדכון 2022, כגון פרשנויות מעשיות על A.8.15 ממומחי ISO 27001, מנסחים מחדש את הבקרה במונחים דומים מאוד, תוך הדגשת רישום התומך בזיהוי, חקירה ושחזור ראיות בזמן המותאמים לפרופיל הסיכונים של הארגון ולהיקף השירותים. זה חשוב במיוחד כאשר אתם פועלים כ-MSP עם כלים משותפים ואחריות מרובת דיירים.
עבור ספק שירותי ניהול שירותים (MSP), עיצוב זה צריך לכלול את המערכות הפנימיות שלך ואת הרכיבים המשותפים או המנוהלים של סביבות הלקוח, ולא רק את רשת המשרד שלך. מדובר בבניית יכולת שניתן לתאר ולחזור עליה, לא רק בהפעלת הגדרות ברירת מחדל.
השליטה בשפה פשוטה
בשפה פשוטה, A.8.15 דורש ממך לבחור מה לתעד, לתעד זאת בצורה אמינה, להגן על זה ולבדוק זאת בפועל. כל שאר הפעולות בבקרה נובעות מארבעת הרעיונות הללו. אם תתמקד בהחלטות אלו, הפרטים הטכניים הופכים לקלים יותר לניהול. עבור ספקי שירותי ניהול שירותים (MSPs) פירוש הדבר הוא יישום אותה דיסציפלינה בכלים משותפים, מערכות פנימיות וסביבות לקוחות.
ראשית, עליכם להחליט אילו פעילויות, חריגים, תקלות ואירועים חשובים לאבטחה ולתפעול. שנית, יש לתעד אירועים אלה בפועל במערכות ובשירותים הרלוונטיים. שלישית, יש לאחסן ולהגן על יומני רישום כך שלא ניתן יהיה לשנותם או לאבדם ללא גילוי. רביעית, יש לנתח ולסקור את היומנים הללו כדי שיתרמו לניטור ולחקירות.
עבור ספק שירותי ניהול נתונים (MSP), "אירועים רלוונטיים" כוללים בבירור יותר מיומני שרת מסורתיים. סקריפטים מרחוק המבוצעים דרך ניהול האחסון (RMM) שלכם, שינויי מדיניות בחומות אש משותפות, כניסות לפורטלים של ניהול ענן, שינויים בקבוצות מורשות בפלטפורמת הזהויות שלכם ופעולות במערכת הכרטיסים שלכם, כולם יכולים להשפיע באופן מהותי על אבטחת הלקוחות. הערכת סיכונים צריכה לקבוע אילו מבין אלה נמצאים בטווח, אך ברגע שהם נמצאים בטווח, יש לתעד אותם באופן עקבי, ניתן לגילוי ושימושי.
הבקרה מניחה גם שרישום הוא מכוון, לא אופורטוניסטי. לא מספיק לומר "הכלי יכול לרשום את זה אם נפעיל אותו". מצופה מכם להראות שבחרתם מה לרשום, כיצד להגדיר זאת וכיצד לשמור על התאמתו לשינויים בשירותים, בלקוחות ובמחסנית הטכנולוגיה שלכם. זו הסיבה ש-A.8.15 נמצא בתוך מערכת הניהול הרחבה יותר: הוא חייב לקשר חזרה לסיכונים, יעדים, מדיניות ושיפור מתמיד.
כיצד A.8.15 מתחבר לשאר מערכת ה-ISMS שלך
רישום רישומים אינו עומד בפני עצמו. תקן A.8.16, העוסק בפעילויות ניטור, מכסה כיצד סוקרים ופועלים על פי רישומים. תיאורים ברמה גבוהה של ISO/IEC 27001 מציגים באופן עקבי את A.8.16 כבקרה המתמקדת בניטור ובסקירה של אירועי אבטחה ורישומים, ולכן הוא משתלב באופן טבעי עם A.8.15 ברוב היישומים.
דו"ח מצב אבטחת המידע לשנת 2025 מציין כי לקוחות מצפים יותר ויותר מספקים להתאים את עצמם למסגרות פורמליות כגון ISO 27001, ISO 27701, GDPR או SOC 2 במקום להסתמך על טענות כלליות של נוהג טוב.
בקרות על ניהול גישה, טיפול באירועים, המשכיות עסקית ופרטיות מוסיפות כל אחת ציפיות ספציפיות שתכנון הרישום שלך חייב לתמוך בהן. מבקרים מחפשים קשרים אלה כאשר הם מחליטים האם יישום A.8.15 שלך יעיל.
זה יכול לעזור לחשוב במונחים של משפחות בקרה מקושרות:
- בקרות ניהול גישה מצפות ליומני רישום המראים מי ניגש למה ועם אילו הרשאות.
- בקרות לניהול אירועים מסתמכות על יומני רישום כדי לשחזר אירועים ולתמוך בלקחים שנלמדו.
- בקרות המשכיות עסקית זקוקות ליומני רישום שיעזרו לכם להבין את מצבי הכשל וההתאוששות.
- בקרות פרטיות דורשות כי יומני מידע המכילים נתונים אישיים יצומצמו, יוגנו וישמרו אותם רק כל עוד נחוץ. דבר זה עולה בקנה אחד עם עקרונות ליבה של הגנת מידע, כגון מזעור נתונים ומגבלת אחסון, בתקנות כמו ה-GDPR, המצפות מארגונים להימנע מאיסוף נתונים אישיים מיותרים ביומנים ולהסיר אותם ברגע שהם אינם נחוצים עוד למטרות המוצהרות.
יחד, ציפיות אלו משמעותן שארכיטקטורת הרישום שלכם צריכה לשרת מספר מטרות בו זמנית, לא רק פעולות אבטחה. כאן מערכת ניהול אבטחת מידע מובנית הופכת קריטית. פלטפורמה כמו ISMS.online יכולה לעזור לכם לבטא, במקום אחד, כיצד A.8.15 מתיישב עם הטיפול בסיכונים שלכם, הצהרת הישימות שלכם ובקרות אחרות שלכם. אתם יכולים להגדיר אילו סוגי אירועים רלוונטיים לאבטחה, למפות אותם למערכות ולשירותים, ולתעד מי אחראי על סקירתם ובאיזו תדירות. ספקי שירותי ניהול מידע (MSPs) רבים מתעדים כיום החלטות A.8.15 לצד הסיכון והצהרת הישימות בסוג זה של ISMS מובנה, מכיוון שהוא נותן למבקרים תמונה ברורה ועקבית.
על ידי קישור החלטות רישום לדיווחי סיכונים ומטרות, ניתן להסביר למבקרים מדוע נבחרו מקורות רישום או תקופות שמירה מסוימות, במקום להיראות כאילו אימצו פשוט ברירות מחדל של הספק. כאשר השירותים שלכם מתפתחים, ניתן לעדכן את העיצוב באופן מרכזי ולשלב את השינויים בהליכים ובתיאורי שירותים. זהו ההבדל בין התייחסות ל-A.8.15 כסעיף על הנייר לבין התייחסות אליו כאל דיסציפלינה עיצובית שהופכת את הסביבה שלכם לניתנת להגנה רבה יותר.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
פער רישום ה-MSP: תיאוריית דייר יחיד לעומת מציאות של דיירים מרובים
רוב עצות הרישום הגנריות מניחות ארגון יחיד ששולט בכל המערכות שלו, עם צוות אבטחה אחד וקבוצה אחת של בעלי עניין. ספקי ניהול שירותים (MSPs) פועלים בצורה שונה: אתם מפעילים פלטפורמות משותפות כגון RMM, כלי SOC וקונסולות ניהול ענן על פני לקוחות רבים, ואתם מספקים שירותים שבהם בעלות על הרישום מתחלקת ביניכם לבין אותם לקוחות. להבדל זה יש השלכות גדולות על האופן שבו יש ליישם ולהסביר את A.8.15.
כלים משותפים וסיכון בין דיירים
כלי MSP משותפים נמצאים בלב השירות והסיכון שלכם. חומות אש מרכזיות, מרכזי VPN, ספקי זהויות ופלטפורמות ניהול שדרכן מהנדסים ניגשים לסביבות לקוחות מרובות יוצרים לעתים קרובות יומני רישום עשירים, אך הם טומנים בחובם גם סיכון: אם נתונים מלקוח אחד גלויים בעוד שמקרה של לקוח אחר מוצג על המסך, יש לכם חשיפה בין דיירים.
פלטפורמת ניהול SIEM או יומנים מרובת דיירים המשתמשת באינדקסים או בתורים משותפים עלולה להחריף מצב זה. אם אירועים מתויגים רק על ידי מזהה לקוח שאכף באופן רופף, באג תצורה שגויה או באג בליעה עלולים לגרום לאירועים להופיע בתצוגה שגויה. דיונים על ארכיטקטורות רישום מרובות דיירים ופריסות SIEM משותפות מדגישים לעתים קרובות את הסיכון הזה: מזהי דיירים חלשים או כאלה המיושמים באופן לא עקבי עלולים לאפשר לאירועים שתויגו בצורה שגויה לדלוף טלמטריה בין דיירים בדרכים שקשה לאתר במהירות.
רוב הארגונים שהשתתפו בסקר ISMS.online לשנת 2025 דיווחו כי הושפעו מלפחות אירוע אבטחה אחד הקשור לצד שלישי או לספק בשנה האחרונה.
מנקודת מבט של תקן ISO 27001, זה פוגע בסודיות. מנקודת מבט חוזית, זה יכול להפר התחייבויות. מנקודת מבט של רישום נתונים, משמעות הדבר היא שהארכיטקטורה שלכם לא התחשבה כראוי בתנאי שימוש כמימד עיצובי. הנחיות בנושא רישום וניטור בסביבות ענן משותפות, כולל עבודה מקהילות כמו Cloud Security Alliance, מתייחסות לחשיפה של יומני רישום בין-תושבים הן ככשל בסודיות והן כפוטנציאל להפרה של התחייבויות חוזיות או רגולטוריות.
במקביל, לקוחות עשויים להניח שאתם מחזיקים עותק מלא של כל הלוגים שלהם רק משום שאתם מספקים שירות מנוהל. במציאות, ייתכן שאתם מחזיקים רק סיכומים או התראות מהמערכות שלהם, בעוד לוגים גולמיים נשארים במנויי הענן או במרכזי הנתונים שלהם. אם חלוקת הבעלות הזו אינה ברורה, הציפיות והאחריות סביב A.8.15 מתבלבלות, ועמדתכם בסכסוך או בחקירה הופכת קשה יותר להגנה.
כדי לעמוד בדרישות A.8.15 בהקשר של ניהול מערכות מידע (MSP), עליכם להיות ברורים מאוד למי שייכים אילו יומני רישום, למי יש גישה אליהם ולאיזו מטרה. עבור כל הצעת שירות, עליכם להיות מסוגלים לענות על השאלות הבאות: אילו מערכות מייצרות יומני רישום, היכן מאוחסנים יומני רישום אלה, למי יש גישת מנהל וקריאה, כיצד הם מגובים ונשמרים, וכיצד הם משמשים לניטור וטיפול באירועים.
כ-41% מהנשאלים אמרו כי ניהול סיכוני צד שלישי ומעקב אחר תאימות ספקים הם אחד מאתגרי אבטחת המידע העיקריים שלהם.
בהירות זו צריכה לבוא לידי ביטוי בחוזים ובתיאורי השירות שלכם. אם אתם מספקים שירות חומת אש מנוהל, לדוגמה, האם אתם שומרים יומני תעבורה מפורטים, רק אירועי אבטחה או רק סיכומים חודשיים? אם לקוח רוצה יומני תנועה גולמיים עבור מערכות ה-SIEM שלו, האם זה במפורש במסגרת התוכנית? כאשר הם מבקשים דוח אירוע שישה חודשים לאחר מכן, על אילו מקורות יומן תסתמכו באופן אמין?
רגולטורים ולקוחות ארגוניים מצפים יותר ויותר שתציגו דיאגרמות אדריכליות או תיאורים כתובים של עיצוב הרישום והניטור שלכם, במיוחד אם אתם משרתים מגזרים קריטיים או זרימות נתונים חוצות גבולות. מסמכי מדיניות בנושא אבטחת סייבר עבור תשתיות קריטיות ושירותי ענן, במיוחד בהקשר האירופי, הדגישו את הצורך בארכיטקטורות מתועדות ואחריות ברורה של רישום וניטור כחלק מהוכחת חוסן תפעולי ושקיפות. אם אינכם יכולים לייצר אלה בזמן, זה מצביע על כך שרישום נובע מתצורות כלים ולא מארכיטקטורה מכוונת מרובת דיירים. הסעיף הבא מציג מודל מחסנית פשוט המסייע לכם לעבור מפרקטיקה אד-הוק לעיצוב מובנה שעומד בביקורות ובחקירות.
ערימת הרישום A.8.15 MSP: ארכיטקטורה בת 4 שכבות
דרך מעשית לעצב רישום (logging) עבור ניהול מערכות מידע (MSP) היא לחשוב בארבע שכבות: איסוף, עיבוד ונורמליזציה, אחסון והגנה, וגישה ושימוש. לכל שכבה יש סיכונים, בקרות וראיות משלה, וכל אחת מהן חייבת לעבוד בהקשר מרובה משתמשים. כאשר ניתן להסביר את השכבות הללו בצורה ברורה, מבקרים ולקוחות נוטים לסמוך על העיצוב שלכם.
- אוסף: – כיצד אירועים עוזבים את המערכות ומגיעים לפלטפורמת הרישום שלכם.
- עיבוד ונורמליזציה: – כיצד אתם מנתחים, מעשירים ומנתבים נתוני יומן.
- אחסון והגנה: – כיצד אתם שומרים יומני רישום בצורה בטוחה, עם שלמות וגיבויים.
- גישה ושימוש: – כיצד אנשים מבצעים שאילתות, סוקרים ופועלים על פי יומני רישום.
ארבע השכבות בפועל
שכבת האיסוף מכסה כיצד אירועים עוזבים את המערכות ומגיעים לפלטפורמת הרישום שלכם. עבור ספקי שירותי ניהול שירותים (MSPs), אלה עשויים להיות סוכנים בשרתים ובנקודות קצה, מחברים בשירותי ענן, זרמי syslog ממכשירי רשת ואינטגרציות API עבור כלי RMM ו-PSA. השאלות המרכזיות הן האם כל המערכות הנמצאות בטווח מוגדרות לשליחת האירועים הנכונים, והאם חיבורים אלה מאובטחים ואמינים.
עיבוד ונורמליזציה כוללים ניתוח, העשרה וניתוב של יומני רישום לאחר הגעתם. ניתן להוסיף מזהי דיירים, לנרמל שמות משתמש בין מערכות, למפות שדות ספציפיים לספקים לסכימה משותפת ולסנן רעשים. החלטות כאן משפיעות על קלות החיפוש אחר "מה עשה המהנדס הזה בכל הלקוחות אתמול" או "הצג לי את כל כניסות המנהל שנכשלו במערכות בסיכון גבוה בשבוע האחרון".
אחסון והגנה עוסקים במקומות בהם נשמרים יומני רישום, כיצד הם מוגנים מפני שיבוש ואובדן, וכיצד נאכפת השמירה. עליכם לבחור מאגרי נתונים, אסטרטגיות גיבוי, בקרות שלמות כגון אחסון באמצעות הוספה בלבד או גיבוב, וסכמות שכבות עבור נתונים חמים וקרים. לבסוף, גישה ושימוש בתפקידי כיסוי, הרשאות, לוחות מחוונים, התראות, חקירות ודיווח. כאן פוגשים את A.8.15 את A.8.16: יצירת יומני רישום אינה מספיקה אם אף אחד לא יכול לסקור אותם ביעילות ולפעול על פיהם.
הפיכת המחסנית לתכניות שירות MSP
לאחר שארבע השכבות מוגדרות עבור הסביבה שלך, תוכל להחיל אותן שירות אחר שירות כדי ליצור תוכניות רישום חוזרות. עבור שירות מנוהל, אתה מחליט כיצד אירועים נאספים, מועשרים, מאוחסנים ונגישים לפני שאתה דואג להגדרות ספקים בודדים. רצף זה מקל על הסבר הגישה שלך באופן עקבי בין לקוחות.
קחו לדוגמה חומת אש מנוהלת. באיסוף, אתם מאפשרים יומני אבטחה וניהול מפורטים ומעבירים אותם בצורה מאובטחת לפלטפורמה המרכזית שלכם. בעיבוד, אתם מתייגים אירועים עם מזהי לקוחות ומנרמלים שמות של כללים וממשקים. באחסון, אתם שומרים אירועי אבטחה באחסון הניתן לחיפוש לתקופה מוסכמת ומארכזים יומני גלם למשך זמן רב יותר במידת הצורך. בגישה ובשימוש, ה-SOC שלכם רואה לוחות מחוונים מרובי דיירים בעוד שלקוחות רואים את תת-הקבוצה שלהם באמצעות דוחות או פורטלים.
ניתן ליישם את אותה תבנית גם על Microsoft 365 מנוהל, אבטחת נקודות קצה, שירותי זהות והצעות אחרות. עבור כל אחת מהן, אתם מתעדים במערכת ה-ISMS שלכם אילו שכבות פועלות, אילו בקרות מוחלות וכיצד נאספות ראיות. זה מקל מאוד על קליטת לקוחות חדשים, הסבר העיצוב שלכם במכרזים והוכחת תאימות עם A.8.15 במהלך ביקורות.
שלב 1 – תיאור היקף השירות
הגדירו אילו מערכות, פלטפורמות משותפות ורכיבי לקוח השירות מכסה, כולל אזורים, דיירים או אילוצי מיקום נתונים.
שלב 2 – לכידת כל שכבת רישום
עבור שירות זה, תעד כיצד אתה אוסף אירועים, מעבד ומנרמל אותם, מאחסן ומגן עליהם, ומתן גישה לאנשים לצורך ניטור וחקירות.
שלב 3 – קישור שכבות לבקרות ולראיות
מיפוי כל שכבה לבקרות, תחומי אחריות, נהלים ורישומים ספציפיים לתקן ISO 27001, כך שתוכלו להראות למבקרים בדיוק כיצד המערכת פועלת בפועל.
גישה מובנית זו הופכת גם שאלות בנוגע לחוסן לקונקרטיות יותר. אם סוכני איסוף נתונים נכשלים, כיצד מאוחסנים יומני רישום במאגר? אם מאגר היומנים של אזור אינו זמין, כיצד נמנעים מפערים שקטים? אם ה-SIEM שלכם מושבת, כיצד שומרים על התחייבויות רישום ושמירה מינימליות? על ידי התייחסות לרישום שלכם כאל מחסנית, תוכלו לתכנן תרחישים אלה במפורש במקום לגלות חולשות רק כאשר משהו משתבש.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
תכנון איסוף, צבירה, אחסון וגישה מרובי דיירים
עם הגישה למערכת, כעת תוכלו לטפל בהיבטים הייחודיים של רישום MSP, המבוססים על רישום מערכות ניהול (MSP): שמירה על הפרדת נתוני לקוחות, כיבוד גבולות אזוריים ויישור תכנון טכנולוגי עם חוזים וחובות פרטיות. להחלטות אלו יש השפעה ישירה על מידת האמינות של יישום A.8.15 שלכם בעיני מבקרים, לקוחות ורגולטורים.
איסוף וצבירה בעולם מרובה דיירים
בסביבה של ארגון יחיד, ייתכן שתכוון את כל המערכות לאספן יומנים מרכזי. ב-MSP, עליך גם לשקול אילו לקוחות חולקים אוספים, דרך אילו אזורים הנתונים זורמים וכיצד אתה מתייגר ומאמת מזהי דיירים באירועים נכנסים. נקודת התחלה הגיונית היא להגדיר דפוסי איסוף סטנדרטיים לכל שירות ולכל אזור.
לדוגמה, ייתכן שתשתמשו בנקודות קצה של בליעת נתונים ספציפיות לאזור, כך שיוני הלוגים של לקוחות אירופאים לא יעזבו את האזור אלא אם כן סוכם במפורש. ייתכן שתדרשו שכל הודעת יומן תכלול מזהה דייר, שיאומת בקצה לפני קבלתה. ייתכן שתבודדו לקוחות רגישים במיוחד בצינורות שלהם. החלטות אלו מסייעות במניעת ערבוב נתונים מקרי ותומכות בהתחייבויות אחסון נתונים.
צבירה ונורמליזציה צריכות לכבד את אותם גבולות. כאשר אתם מאגדים יומני רישום לצורך קורלציה, האם אתם צוברים את כל הלקוחות, או רק בתוך קבוצות מוגדרות? האם שאילתה יכולה אי פעם לכלול לקוחות ללא אישור מפורש? אם ה-SOC שלכם מפעיל תוכן גילוי גלובלי, כיצד אתם מבטיחים שהתוצאות שהאנליסטים רואים מוגבלות לאישוריהם?
כמה שאלות יכולות לעגן את העיצוב שלך:
- אילו שירותים חולקים אספנים, והיכן ממוקמים אספנים אלה?
- כיצד מאמתים מזהי דיירים בעת הקליטה?
- באילו תנאים שאילתות או התראות יכולות לכלול מספר לקוחות?
תשובות ברורות ומתועדות לשאלות אלו הן המפתח למילוי חובות A.8.15 ושל חובות הסודיות שלכם, והן מספקות לכם בסיס הגנה אם רגולטור או לקוח יחקרו כיצד פועל רישום הרישום מרובה הדיירים שלכם.
אחסון, בקרת גישה ופרטיות
בצד האחסון, החלטות בנוגע לתכנון מרובי דיירים כוללות האם להשתמש באינדקסים משותפים עם הפרדה לוגית חזקה או במאגרי נתונים נפרדים לכל לקוח. אחסון משותף יכול להיות יעיל יותר אך דורש אמצעי הגנה מחמירים בנוגע לאינדוקס, שאילתות וייצוא. אחסון נפרד יכול להיות פשוט יותר להיגיון, במחיר של תשתית נוספת. כך או כך, עליכם להיות מסוגלים להראות כיצד אתם מונעים אחזור נתונים של לקוח אחד בהקשר של אחר.
בקרת גישה צריכה לשקף את מודל השירות שלכם. אנליסטים של SOC עשויים להזדקק לגישת קריאה עבור דיירים רבים, אך רק קבוצה קטנה מאוד צריכה להיות בעלת הרשאות ניהול כדי לשנות תצורות רישום או שמירה. צוות הלקוח צריך לראות רק את היומנים שלהם, כאשר התפקידים מוגבלים עוד יותר על ידי עקרונות הרשאות מינימליות. כל הגישה לפלטפורמת הרישום עצמה צריכה להירשם ולסקור, במיוחד עבור פעולות רגישות כגון שינוי הגדרות שמירה או מחיקת נתונים.
פרטיות מוסיפה מימד נוסף. יומני רישום מכילים לעתים קרובות נתונים אישיים כגון שמות משתמש, כתובות IP, מזהי מכשירים, ובמקרים מסוימים, תוכן אינטראקציה. עליכם להחליט אילו שדות נחוצים למטרות אבטחה ותפעול, והיכן אנונימיזציה, פסאודו-נימיזציה או צבירה מתאימים. עליכם גם לוודא שתקופות השמירה ומיקומי הנתונים תואמים את חוקי והסכמי הפרטיות. יש לתעד בחירות אלו כך שעיצוב A.8.15 שלכם יישאר תואם לבקרות הפרטיות שלכם, וכך תוכלו להגן על הגישה שלכם אם היא תועמד בפני אתגר.
מה לרשום: מקורות רישום חובה לעומת מקורות רישום נחמדים של MSP
אף ספק שירותי ניהול נתונים (MSP) לא יכול או צריך לתעד הכל. האמנות היא לבחור סט מינימלי של מקורות רישום שניתן להגנה עליו, שיאפשרו לזהות ולחקור אירועים משמעותיים, ולאחר מכן להוסיף מקורות נוספים היכן שהסיכון והתקציב מצדיקים זאת. תקן ISO 27001 מצפה שזה יהיה מבוסס סיכון ויתועד, ומבקרים שואלים לעתים קרובות מדוע מקורות מסוימים קיבלו עדיפות על פני אחרים.
מקורות יומן חובה עבור ספקי שירותי ניהול רשת (MSPs)
קשה מאוד להצדיק השמטה של מקורות יומן מסוימים ביישום A.8.15 שלכם. מבחן מנטלי פשוט הוא לדמיין אירוע חמור ולשאול האם תוכלו לשחזר בצורה אמינה את מה שקרה ללא יומני הרישום הללו. אם התשובה היא לא, מקור זה כנראה שייך לתכנון הבסיסי שלכם. מדריכים מעשיים ליישום A.8.15 מחברות ייעוץ ISO 27001 מדגישים לעתים קרובות שמערכות זהות, בקרות גבולות, כלי אבטחה מרכזיים ומארחי קפיצות אדמיניסטרטיביים שייכים לקבוצת הבסיס הזו למאמץ הסמכה אמין.
קטגוריות מפתח כוללות בדרך כלל:
- מערכות זהות וגישה: – מדריכים, כניסה יחידה וספקים מרובי גורמים.
- בקרות רשת וגבולות: – חומות אש, שערי VPN וכלי פריצה.
- כלי אבטחה: – פלטפורמות להגנה על נקודות קצה, דוא"ל ואינטרנט.
- כלי ניהול ומארחי קפיצה: – RMM, כלי גישה פריבילגית, מעוזים וקונסולות ענן.
- פלטפורמות שירות מרכזיות: – חבילות ענן מנוהלות, יישומים מרכזיים ומערכות כרטיסים או PSA.
מערכות זהות וגישה נמצאות בראש הרשימה. ללא רישום משירותי ספריות, ספקי כניסה יחידה ופלטפורמות אימות רב-גורמי, לא ניתן לראות באופן מהימן מי התחבר, מאיפה ועם איזו רמת הרשאה.
בקרות רשת וגבולות הן קטגוריה חובה נוספת: חומות אש, שערי VPN, שערי אינטרנט מאובטחים ומערכות לגילוי או מניעה של חדירות. יומנים אלה מראים איזו תעבורה הותרה או נחסמה, אילו חיבורים הגיעו ממיקומים יוצאי דופן ומתי שונו כללים או מדיניות. כלי אבטחה כגון הגנת נקודות קצה, אבטחת דוא"ל ומסנני אינטרנט מספקים אותות עשירים לגבי איומים ותגובות.
כלי ניהול ומארחי קפיצה (Jump Hosts) המשמשים את המהנדסים שלכם ראויים לתשומת לב מיוחדת. פעולות שבוצעו דרך פלטפורמות RMM, כלי ניהול גישה פריבילגית, מארחי bastion וקונסולות ניהול ענן צריכות להירשם בפירוט מספיק כדי להראות אילו פעולות בוצעו באילו מערכות, תחת איזו זהות. לבסוף, פלטפורמות שירות מרכזיות כגון Microsoft 365, יישומים מרכזיים שאתם מנהלים ומערכת הכרטיסים או ה-PSA שלכם מספקות הקשר חשוב לגבי שינויים ואינטראקציות עם לקוחות.
אם אחת מהקטגוריות הללו חסרה, תתקשו לענות על שאלות בסיסיות במהלך אירועים וביקורות. פרשנויות בתעשייה על תגובה לאירועים וחקירות פרצות מציינות באופן קבוע כי היעדר יומני זהות, רשת או כלי אבטחה מקשה מאוד על שחזור אירועים ועל עמידה בשאלות מפורטות מצד חוקרים או מבקרים. הפיכת קטגוריות אלו לחובה בתכנון A.8.15 שלכם מעניקה לכם בסיס איתן ומקלה על הצדקת שיפורים נוספים.
מקורות נחמדים ומתי להוסיף אותם
מעבר לדברים החיוניים, ישנם מקורות רבים של יומני רישום שיכולים להוסיף ערך אך לא תמיד מוצדקים. יומני יישומים גנריים מתוכנות שולחן עבודה, יומני ניפוי שגיאות מפורטים מסביבות פיתוח ומדדים מפורטים ממערכות בעלות סיכון נמוך יכולים לצרוך במהירות זמן אחסון ואנליסטים מבלי לשפר באופן משמעותי את היכולת לזהות או לחקור אירועים.
אין זה אומר שהם תמיד מחוץ לתחום. עבור לקוחות בסיכון גבוה, יישומים מותאמים אישית או עומסי עבודה מוסדרים, ייתכן שתחליטו שיש צורך ברישום נוסף. המפתח הוא לתעד את ההיגיון הזה בהערכת הסיכונים ובהצהרת הישימות שלכם, ולהגדיר איסוף ושמירה באופן מכוון ולא באופן ספורדי.
טכניקה שימושית היא להגדיר שכבות מקור יומן בקטלוג השירותים שלך. שכבה בסיסית עשויה לכלול את כל המקורות החיוניים ולהיות מתאימה ללקוחות סטנדרטיים. שכבות גבוהות יותר יכולות להוסיף יומנים ספציפיים ליישום, נתיבי ביקורת מפורטים יותר או שמירה ארוכה יותר. כל שכבה צריכה לתאר לא רק את נפח הנתונים, אלא גם את כיסוי הגילוי ועומק החקירה שהיא מאפשרת. בדרך זו, מכירות, תפעול ולקוחות יכולים להבין מה הם מרוויחים ככל שהם עולים בשכבות.
טבלת השוואה קטנה יכולה לעזור לצוות שלכם לחשוב על מקורות בצורה פרגמטית:
| נִדבָּך | מקורות אופייניים | מטרה עיקרית |
|---|---|---|
| ליבה (חובה) | זהות, חומות אש, VPN, EDR, RMM, כלי ניהול | גילוי וזיהוי פלילי בסיסי |
| משופר | יומני יישומים מרכזיים, יומני עומסי עבודה בענן | ניתוח שורש הבעיה מעמיק יותר |
| מומחה | יומני ניפוי באגים, יומני מערכת נישה | מקרים נדירים, מורכבים או מוסדרים |
זה רק להמחשה; הרמות והמקורות בפועל שלך צריכים להתאים לפרופיל הסיכון ולשירותים שלך. החלק החשוב הוא ש-A.8.15 יהפוך לקבוצה מובנית של אפשרויות ולא לתופעת לוואי מרומזת של המערכות שבהן במקרה הפעילה רישום נתונים. כאשר תוכל להסביר את האפשרויות הללו, קל הרבה יותר להגן עליהן בפני מבקרים, לקוחות ורגולטורים.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
כמה זמן לשמור את זה: מודל שימור מבוסס סיכון עבור ספקי שירותי ניהול רשת (MSPs)
בחירת תקופות שמירה היא אחד החלקים הרגישים ביותר של A.8.15 עבור ספק שירותי ניהול נתונים (MSP). אתם מאזנים בין ציפיות רגולטוריות, צרכי חקירת אירועים, כללי פרטיות ועלות אחסון, והבחירות שלכם יישפטו על סמך מידת הבנת הסיכון וההגנה שלהן. לקוחות ומבקרים יבחנו את ההחלטות הללו מקרוב במהלך הסקירות.
תכנון מודל שימור מדורג
דרך מעשית לגשת לשמירה היא לקבץ יומני רישום לקטגוריות ולהקצות שכבות. לדוגמה, ייתכן שתתייחסו ליומני אבטחה וניהול כקטגוריה אחת, ליומני שירות לקוחות וטיפול בכרטיסים כקטגוריה נוספת, וליומני טכניים בעלי ערך נמוך כקטגוריה שלישית. עבור כל קטגוריה, תחליטו כמה זמן הנתונים צריכים להיות ניתנים לחיפוש מהיר, כמה זמן הם צריכים להישאר זמינים בצורה איטית יותר או מאוחסנת ומתי יש למחוק אותם או להפוך אותם לאנונימיים.
כדי לקבל החלטות אלו, עבדו אחורה מהסיכונים וההתחייבויות שלכם. קחו בחשבון כמה זמן בדרך כלל מתקיפות אינן מתגלות בקרב בסיס הלקוחות שלכם, כמה זמן נוטים להימשך חקירות ותהליכים משפטיים ומהם הצופים של הרגולטורים או החוזים. אם הלקוחות שלכם פועלים במגזרים שבהם לעיתים מתגלות אירועים חודשים רבים לאחר הפגיעה הראשונית, יהיה קשה להגן על תקופות שמירה קצרות מאוד. הנחיות ספקי ענן לגבי שמירת יומני רישום ממליצות בדרך כלל על דפוס דומה, כאשר יומני רישום בעלי ערך גבוה נשמרים חמים וניתנים לחיפוש למשך תקופה ולאחר מכן מועברים לאחסון ארכיוני בעלות נמוכה יותר שעדיין מאפשר אחזור לצורך חקירות או שאילתות תאימות.
דפוס נפוץ הוא לשמור יומני ערך גבוה (זהות, אבטחה, פעולות מנהל) חמים וניתנים לחיפוש במשך מספר חודשים, ולאחר מכן להעביר אותם לאחסון זול יותר תוך שמירה על גישה אליהם למשך שנה עד מספר שנים. יומני ערך נמוך יותר עשויים להיות בעלי שמירה קצרה בהרבה. לא משנה מה המספרים שתבחרו, תעדו כיצד הם נוצרו, אילו סיכונים הם מטפלים בהם ומי אישר אותם. זה הופך את הדיונים עם מבקרים, לקוחות וקציני פרטיות לפשוטים הרבה יותר.
שלב 1 – סיווג סוגי יומני רישום
כניסות קבוצתיות לקטגוריות ברורות כגון אבטחה וניהול, שירות לקוחות וכרטוס, ונתונים טכניים או אבחוניים בעלי ערך נמוך.
שלב 2 – החלטה בין שמירת ארכיון חמה לבין שמירת ארכיון
עבור כל מחלקה, החליטו כמה זמן הנתונים צריכים להישאר ניתנים לחיפוש מהיר וכמה זמן הם צריכים להישאר באחסון איטי יותר או בארכיון.
שלב 3 – נימוקי מסמך ואישורים
רשמו מדוע בחרתם בכל תקופת שמירה, אילו סיכונים או התחייבויות היא מטפלת ומי אישר אותה, כדי שתוכלו להסביר זאת במהלך ביקורות.
איזון בין רגולציה, חקירה ועלויות
שימור נתונים אינו רק החלטה טכנית או החלטה הנוגעת לתאימות; זוהי גם החלטה מסחרית. שימור נתונים ממושך יותר פירושו יותר אחסון, גיבויים ואינדוקס, מה שעשוי להשפיע על הרווחיות שלך אם לא יתומחר כראוי. שימור נתונים לזמן קצר עשוי לחסוך כסף כעת אך להגדיל את הסיכון שלא תוכל לתמוך בחקירה או להפגין בדיקת נאותות בהמשך.
רוב גדול מהארגונים בדוח מצב אבטחת המידע לשנת 2025 אמרו כי המהירות והיקף השינויים הרגולטוריים מקשים על קיום תאימות.
לכן, קטלוג השירותים שלכם צריך להבהיר את השמירה. עבור כל רמת רישום או חבילת שירות, ציינו אילו סוגי רישום נשמרים, למשך כמה זמן ובאיזו צורה. זה מאפשר ללקוחות לבחור בהתאם לתיאבון הסיכון שלהם ולפרופיל הרגולציה שלהם. זה גם נותן לצוותי הכספים והתפעול שלכם תמונה ברורה יותר של השלכות העלויות של כל אפשרות.
כללי הפרטיות מוסיפים שכבה נוספת. תחומי שיפוט רבים דורשים כי מידע אישי יישמר לא מעבר לנדרש למטרות שלשמן נאסף. דבר זה משקף עקרונות כגון הגבלת אחסון בחוקי הגנת מידע כמו ה-GDPR, אשר קובעים במפורש כי אין לשמור מידע אישי ללא הגבלת זמן ויש למחוק אותו או להפוך אותו לאנונימי לאחר שכבר אין בו צורך למטרות שהוגדרו במקור.
זה יכול להסתדר בצורה לא נוחה עם הרצון לשמור יומני אבטחה במשך שנים רבות. טכניקות כמו שימוש בפסאודניזציה של שדות מסוימים לאחר תקופה, צבירת אירועים לספירות או השמטת שדות בעלי ערך נמוך יכולות לעזור לכם ליישב את הלחצים הללו.
המבחן המרכזי הוא האם מודל השמירה שלכם ייראה סביר וניתן להגנה אם רגולטור, לקוח או בית משפט היו מבקשים מכם להצדיק אותו. אם תוכלו להסביר את האיזון שעשיתם בין רגולציה, צורכי חקירה, פרטיות ועלות, ולהראות שאתם מיישמים אותו באופן עקבי, אתם בעמדה חזקה הרבה יותר מאשר אם שמירה היא פשוט "מה שהכלי הוגדר אליו כשהתקנו אותו".
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לך להפוך את A.8.15 מהגדרות כלים מפוזרות לבקרה מבוקרת ומוכנה לביקורת בכל שירותי ה-MSP שלך, כך שתוכל להתמודד עם אירועים וביקורות עם רצף רישום ברור וניתן להגנה. ארכיטקטורת רישום ומודל שימור מתוכננים היטב יספקו את מלוא ערכם רק אם הם מוטמעים במערכת הניהול הרחבה יותר שלך ויישארו תואמים לאופן שבו השירותים שלך מתפתחים.
למה מבנה חשוב יותר מכלי אחד נוסף
ISMS.online מספק לכם מקום מובנה לתיעוד עיצוב הרישום שלכם בכל שירותי ה-MSP שלכם, במקום להסתמך על שילוב של גיליונות אלקטרוניים, מצגות וידע אישי. תוכלו להגדיר את כוונת הבקרה שלכם לפי A.8.15, לרשום את מקורות הרישום בטווח, לתאר את הארכיטקטורה בת ארבע השכבות שלכם ולתעד כיצד מטופלים איסוף, אחסון וגישה של מערכות מרובות משתמשים עבור כל הצעה.
ניתן גם למדל את אסטרטגיית השמירה שלכם באופן מפורש. עבור כל סוג יומן ורמת שירות, אתם מתעדים את תקופות השמירה המוסכמות, רמות האחסון בהן נעשה שימוש ואת ההיגיון העומד מאחוריהן. כאשר מבקרים שואלים מדוע קבוצה מסוימת של יומנים נשמרת למשך זמן מסוים, אתם יכולים להצביע על רשומה אחת ומנוהלת המקשרת החלטות לסיכונים, חוזים וחובות פרטיות. זה מפחית את הזמן והלחץ הכרוכים בהכנה לביקורת ועוזר למנוע הפתעות.
חשוב לציין ש-ISMS.online נועד להשתלב עם כלי התפעול הקיימים שלכם, ולא להחליף אותם. ה-SIEM, ה-RMM, פלטפורמת הכרטיסים ושירותי הענן שלכם נשארים במקום שבו מתבצעים רישום וניטור. ה-ISMS מספק את המסגרת סביבם: מי אחראי, אילו נהלים חלים, כיצד נרשמות ביקורות וכיצד מתבצע מעקב אחר שיפורים. הפרדה זו מקלה על פיתוח הכלים שלכם מבלי לאבד שליטה על בקרת הרישום.
מה אתם מרוויחים מריכוז תכנון כריתת העצים שלכם
כאשר אתם מרכזים את גישת A.8.15 שלכם ב-ISMS.online, אתם נותנים לכולם תמונה אחת ומשותפת של אופן פעולת הרישום והשמירה בכל מערכת ניהול הנתונים (MSP) שלכם. בהירות זו הופכת את האחריות, הפערים הפוטנציאליים וסדרי העדיפויות בתכנון לקלים הרבה יותר לזיהוי, והופך לפשוט יותר להראות למבקרים וללקוחות כיצד הגישה שלכם פועלת בפועל.
מנהלי אבטחה יכולים לראות במבט חטוף אילו שירותים מכוסים במלואם על ידי מחסנית ארבע השכבות והיכן נותרו פערים. מנהלים יכולים לראות כיצד בחירות רישום ושמירה תואמות את תיאבון הסיכון העסקי ואת סדרי העדיפויות המסחריים. מנהלי תפעול יכולים למפות בדיקות וסקירות יומיות לבקרות ולשמור על ראיות מאורגנות, כך שעומס ההכנה לביקורת מתפזר על פני השנה במקום דחוס לכמה שבועות מלחיצים.
אפשר להתחיל בקטן. בחרו שירות דגל אחד, כגון Microsoft 365 מנוהל או חומות אש מנוהלות, ותעדו את ארכיטקטורת הרישום שלו, מקורות הרישום והגדרות השמירה בפלטפורמה. השתמשו בו כפיילוט כדי לזהות חוסר עקביות, תחומי אחריות חסרים או הנחות לא מתועדות. לאחר שתרגישו בנוח, החלו את אותו דפוס על שירותים אחרים. עם הזמן, תבנו תמונה מלאה וניתנת לביקורת של רישום בכל ספק שירותי ניהול התשתיות (MSP) שלכם.
בחרו ב-ISMS.online כשאתם רוצים שרישום ושמירה יהפכו לחלק ממערכת ניהול אבטחת מידע קוהרנטית ומוכנה לביקורת, במקום אוסף רופף של הגדרות כלים. אם אתם מעריכים ביקורות מהירות ורגועות יותר, הגדרות שירות ברורות יותר ויכולת להראות ללקוחות ולרגולטורים בדיוק כיצד אתם עומדים בתקן A.8.15, הזמנת הדגמה קצרה היא צעד הגיוני הבא. זה יעזור לכם לראות כיצד הרעיונות במדריך זה מתורגמים לזרימות עבודה, רשומות ולוחות מחוונים מעשיים המותאמים ל-MSPs כמו שלכם.
הזמן הדגמהשאלות נפוצות
מה בעצם משנה תקן ISO 27001 A.8.15 באופן שבו ספק שירותי ניהול הרשתות (MSP) שלך ניגש לרישום?
תקן ISO 27001 A.8.15 מצפה מ-MSP שלכם להתייחס לרישום כבקרה מתוכננת התומכת באבטחה ואחריות, ולא כתוצר לוואי של הכלים בהם אתם משתמשים. בפועל, משמעות הדבר היא להחליט מה יש לרשום, היכן, למשך כמה זמן, כיצד זה מוגן, וכיצד הצוות שלכם משתמש ברשומות אלו כדי לזהות ולחקור בעיות בכל הלקוחות הנכללים בתחום.
כיצד יש לתרגם את A.8.15 לתקן רישום פשוט ושמיש?
גישה מעשית היא להפוך את A.8.15 לתקן קצר ודעתני שמהנדסים, אנליסטים ובעלי שירותים יוכלו בפועל לעקוב אחריו:
- תגדיר את היקף – אילו לקוחות, סביבות ושירותים נמצאים בגבולות תקן ISO 27001 שלכם.
- לפרט קטגוריות אירועים שתמיד דורשים רישום, כגון שינויים אדמיניסטרטיביים, ניסיונות אימות וגישה, שינויי מדיניות ותצורה והתראות אבטחה.
- רשום את מקורות יומן מינימליים לפי סוג שירות (לדוגמה, זהות, חומות אש/VPN, EDR, M365, RMM, PSA).
- הגדר ברור ציפיות שלמות יומן – סנכרון זמן, גישה מוגבלת, אחסון בלתי משתנה או כתיבה חד פעמית במידת האפשר, וציפיות גיבוי.
- לתאר שימוש תפעולי – מי בודק אילו יומנים, באיזו תדירות, כיצד חריגים מועברים והיכן ממצאים מתועדים.
תקן זה הופך לנקודת הייחוס עבור כל שירות מנוהל. כאשר מבקר שואל כיצד הצעות "Microsoft 365 מנוהל" או "חומת אש מנוהלת" שלכם עומדות בתקן A.8.15, תוכלו להראות:
- תקן הרישום במערכת ה-ISMS שלך.
- תוכנית השירות שממפה כל הצעה לתקן.
- ראיות לביקורות וחקירות אמיתיות הקשורות לשירותים אלה.
לכידת הרשומות הסטנדרטיות, מיפויי השירות והרשומות התפעוליות ב-ISMS.online שומרת על מעקב אחר הכל ומבהירה כי הרישום מוטמע במערכת ניהול אבטחת המידע שלכם, ואינו מפוזר על פני הגדרות כלים ומחברות בודדות.
כיצד ניתן לבדוק במהירות האם הרישום שלך עומד בכוונה של A.8.15?
בדיקה פנימית שימושית היא לבחור שינוי או אירוע רלוונטי לאבטחה שנעשה לאחרונה ולבקש מהצוות שלך לשחזר אותו באמצעות יומני רישום בלבד:
- מי ביצע את הפעולה?
- מתי ומהיכן זה קרה?
- אילו חשבונות, מערכות או דיירים הושפעו?
- מה הייתה התוצאה ומה עשתה הצוות שלך בתגובה?
אם אתם יכולים לענות על שאלות אלו בביטחון, באמצעות מקורות יומן מוגדרים ותהליכי סקירה, אתם צועדים בכיוון הנכון. אם התשובות איטיות, לא שלמות או לא עקביות בין לקוחות, זהו איתות ברור להדק את הסטנדרטים, הכיסוי או משמעת הסקירה שלכם ולרשום את השיפורים הללו כסיכונים ופעולות ב-ISMS.online כדי שתוכלו להראות התקדמות לאורך זמן.
כיצד צריך ספק שירותי ניהול שירותי ניהול (MSP) לתכנן רישום רישום מרובה משתמשים (Multi-Director Loging) כך שיהיה מאובטח, ניתן להרחבה ומוכן לביקורת?
עיצוב רישום MSP מעשי מתחלק בדרך כלל לארבע שכבות: אוסף, עיבוד ונורמליזציה, אחסון והגנה, ו גישה ושימושחשיבה בשכבות אלו עוזרת לך להפריד לקוחות בצורה נקייה, לכבד דרישות נתונים אזוריות ולתת למבקרים נקודת מבט ברורה.
אילו החלטות עיצוביות חשובות ביותר בכל שכבה עבור רישום ISO 27001 מרובה דיירים?
ב שכבת איסוף, התמקדו באופן שבו האירועים של כל דייר מגיעים לפלטפורמת הרישום שלכם:
- בחרו לכל כלי אם להשתמש בסוכנים, ממשקי API או syslog.
- ספקו נקודות קצה לאיסוף ספציפיות לאזור כך שיוני רישום מהאיחוד האירופי, בריטניה וארה"ב יוכלו להישאר באזור במידת הצורך.
- אכיפת סנכרון זמן כך שקווי הזמן יתאימו במהלך חקירה.
ב שכבת עיבוד ונורמליזציה, להפוך יומני רישום לשימושיים ובטוחים בפלטפורמה משותפת:
- ודא שכל רישום נושא מידע אמין מזהה דייר וכאשר רלוונטי, תגי סביבה או שירות.
- נרמול שדות ליבה (משתמש, מקור, יעד, פעולה, תוצאה) כדי שאנליסטים יוכלו לחפש באופן עקבי בין מקורות שונים.
- התייחסו לשאילתות בין-דיירים ולחיפושים גלובליים כאל פעולות מועדפות, עם כללי גישה ורישום משלהם.
ב שכבת אחסון והגנה, עיצוב להפרדה ושלמות:
- חלק אחסון לפי דייר, אזור או שניהם, באמצעות אינדקסים, דליים או מסדי נתונים המותאמים לארכיטקטורה שלך.
- יש ליישם מדדי שלמות כגון אחסון באמצעות הוספה בלבד, דגלי אי-שינוי או שרשור גיבוב במקומות בהם הכלים תומכים בהם.
- קשרו שמירת נתונים חמה וארכיון לקטגוריות יומן, חוזים ונורמות מגזריות כדי שתוכלו להגן על הבחירות שלכם.
ב שכבת הגישה והשימוש, ודאו שהעבודה היומיומית לעולם לא מטשטשת את גבולות הלקוחות:
- הגדירו אילו תפקידים יכולים לראות אילו דיירים; שמרו על נדירות, מוצדקות ומנוטרות של תפקידים בין דיירים או תפקידים גלובליים.
- בנה תורי התראות, סקירות וחקירות כך שמהנדסים יוכלו לעבוד לעומק בתוך דייר מבלי לחשוף את הנתונים של לקוח אחר.
- החליטו באיזו תדירות אתם משתפים סיכומים, מגמות או צירי זמן של אירועים עם לקוחות וכיצד זה תואם את רמות השירות שלכם.
תיעוד ההחלטות הללו כחלק מבקרת A.8.15 שלך, ולאחר מכן קישורן לתצורות קונקרטיות, ספרי משחק ורשומות סקירה ב-ISMS.online, הופך רישום רב-דיירים ממשהו שאתה מקווה שהוא בטוח למשהו שאתה יכול לתאר ולהגן עליו.
איך מוכיחים הפרדת דיירים לרואי חשבון ולקוחות גדולים יותר?
אתם הופכים את הפרדת הדיירים להרבה יותר משכנעת כשאתם יכולים להראות קו נקי מ... מדיניות ל ארכיטקטורה ל בקרת גישה ל חקירות אמיתיות:
- מדיניות ותקנים קובעים כי יומני לקוחות מופרדים באופן לוגי או פיזי וכי הגישה בין דיירים מבוקרת ומנוטרת בקפידה.
- דיאגרמות ארכיטקטורה ממחישות כיצד זה עובד בפלטפורמה שבחרת, כולל אחסון אזורי עבור לקוחות מוסדרים.
- רשומות גישה מראות לאילו אנליסטים יש אילו היקפי דיירים, מי מאשר תפקידים בין דיירים וכיצד תפקידים אלה נבדקים.
- יומני אירועים וחקירות מדגימים שהצוות שלכם יכול לבצע ניתוח מעמיק בתוך הנתונים של דייר אחד מבלי לגעת באחרים.
ניהול המסמכים, הרשומות והקישורים הללו ב-ISMS.online תחת A.8.15 מספק לכם מקום אחד להדריך מבקרים ולקוחות בכל שלב של הארגון, מבלי לחשוף נתוני יומן גולמיים או כל פרט ופרט בכלי העבודה שלכם.
אילו מקורות יומן לוגריתמים צריכים MSP להתייחס אליהם כבלתי ניתנים למשא ומתן תחת ISO 27001 A.8.15?
סעיף A.8.15 גמיש במכוון ומבקש ממך לתעד "פעילויות, חריגים ואירועי אבטחת מידע" בהתאם לסיכון. עבור ספקי שירותים מנוהלים, ישנה קבוצה מרכזית של מקורות שכמעט תמיד צריכים להיות בטווח אם אתה רוצה חקירות אמינות וביקורת ISO 27001 נוחה.
מה כולל בדרך כלל בסיס רישום MSP הגיוני?
רוב סביבות ה-MSP נהנות מבסיס המכסה לפחות חמש קטגוריות:
- זהות וגישה: פלטפורמות ספריות, SSO, MFA, ניהול גישה פריבילגית וכל כלי ניהול Just-in-Time.
- בקרות רשת וגבולות: חומות אש, VPN, שערי אינטרנט מאובטחים, נתבי מפתח ופרוקסי הפוך ששומרים על גישה חיצונית ופנימית.
- אבטחת נקודות קצה ועומסי עבודה: הגנה על נקודות קצה או EDR, אבטחת דוא"ל ואינטרנט, וכלי הגנה על עומסי עבודה בענן.
- כלי ניהול ותזמור: פלטפורמות RMM, היפר-ויזורים, קונסולות ניהול ענן, מארחי קפיצה, מעוזים וצנרת אוטומציה שיכולות לשנות את סביבות הלקוח.
- פלטפורמות לקוחות מרכזיות וכלי שירות משלכם: SaaS מרכזיים כמו Microsoft 365 או Google Workspace, בנוסף למערכות PSA ו-service desk שמתעדות מה השתנה ומדוע.
לאחר שהדברים הללו נכונים, הצוות שלכם יכול בדרך כלל לענות על שאלות כמו "איך התוקף חדר, מה הוא עשה, ואילו לקוחות או מערכות הושפעו?". בלעדיהם, גם טיפול באירועים וגם ביקורות הופכים במהירות לספקולציות, מה שפוגע באמון בשירותים המנוהלים שלכם וגם בתאימות שלכם.
כיצד ניתן לשלוט במקורות יומן בעלי ערך נמוך מבלי לפגוע בסטורי האבטחה שלך?
לא כל מקור פוטנציאלי של יומן רישום מצדיק איסוף עבור כל לקוח. דרך מעשית להימנע מבזבוז תוך שמירה על הגנה היא לקבץ מקורות אופציונליים ל שכבות מבוססות ערך:
- יומני ערך גבוה: אשר משפרים באופן מהותי את הגילוי המוקדם או את ההקשר ברוב האירועים.
- יומני זיהוי פליליים מומחים: אשר שימושיים בעיקר עבור מקרים מורכבים ובעלי השפעה גבוהה.
- יומני רישום בעלי ערך נמוך או רועשים: שמוסיפים נפח ועלות עם תועלת חקירה מוגבלת.
לאחר מכן תוכל ליישר את הרמות הללו לקטלוג השירותים שלך:
- שירותי בסיס כוללים את המקורות שאינם ניתנים למשא ומתן.
- שירותי פרימיום או "אבטחה משופרת" מוסיפים רבדים ספציפיים בעלי ערך גבוה וזיהוי פורנזי.
תיעוד של הרמות הללו, וההצדקה מבוססת הסיכון עבור כל אחת מהן, ב-ISMS.online תחת תקן הרישום שלכם, מספק לכם דרך ברורה להסביר למבקרים וללקוחות מדוע שירות אחד כולל רישום עשיר יותר מאחר ועוזר לצוות המסחרי שלכם להתייחס לרישום כחלק מפורש מכל שירות מנוהל ולא כעלות בלתי נראית.
כיצד צריך ספק שירותי ניהול נתונים (MSP) להגדיר ולנהל שמירת יומני רישום כך שתעמוד בתקן A.8.15 ובחוק הגנת המידע?
מכיוון שתקן ISO 27001 אינו קובע תקופות שמירה, A.8.15 מטיל עליך את האחריות להגדיר ולהצדיק את משך הזמן שאתה שומר סוגים שונים של נתוני יומן. כספק שירותי ניהול רשתות (MSP), עליך לאזן בין צרכי חקירה, ציפיות לקוחות ומגזרים, חוזים וכללי פרטיות על פני מספר דיירים ואזורים.
כיצד ניתן לבנות מודל שימור עובדים שמרגיש סביר וניתן להגנה?
במקום לקבוע שמירה לפי מקור בודד, רוב ספקי שירותי ניהול הרשת (MSP) מוצאים שזה יותר נוח לעבוד עם קומץ של מחלקות יומן, כגון:
- פעילות זהות וגישה.
- אירועי אבטחה והתראות.
- פעילות אדמיניסטרטיבית ופעילות שינוי.
- רישומי שירות וכרטיסים.
- יומני רישום טכניים בעלי ערך נמוך.
עבור כל שיעור תוכלו להחליט:
- כמה זמן יומני רישום נשארים ניתנים לחיפוש בכלים העיקריים שלך לגילוי וחקירות יומיומיות.
- כמה זמן הם נשארים בארכיון במקרים נדירים ומורכבים, החזקות משפטיות או סיבות חוזיות.
תקופות אלו צריכות להיות קשורות ל:
- לוחות זמנים אופייניים לגילוי וחקירה של התקפות חמורות.
- ציפיות מהמגזר והנחיות רגולטוריות בתעשיות שאתם משרתים.
- התחייבויות בחוזי לקוחות, ובמידת הצורך, בפוליסות ביטוח סייבר.
יומני אבטחה וגישה בעלי ערך נמוך יותר ניתנים בדרך כלל לשמירה לתקופות קצרות יותר כדי לנהל את האחסון ולהפחית חשיפה מיותרת של נתונים אישיים, בעוד שיומי אבטחה וגישה בעלי ערך גבוה מצדיקים בדרך כלל שמירה ממושכת יותר.
כיצד מאזנים בין שמירת זכויות יוצרים לדרישות פרטיות ועדיין תומכים בחקירות מעמיקות?
שמירה הופכת לבעיית פרטיות כאשר היא מורחבת אך ורק משום שהאחסון זול. כדי לעמוד הן בתקן ISO 27001 והן במשטרי הגנת מידע כמו GDPR או CCPA, ניתן:
- זהה אילו סוגי יומני רישום מכילים נתונים אישיים וודא שתוכל להסביר, מבחינת סיכון ומשפט, מדוע תקופות השמירה הללו "אינן ארוכות מהנדרש".
- יש ליישם טכניקות כגון פסאודונימיזציה או טוקניזציה עבור ארכיונים ארוכי טווח, כך שחוקרים עדיין יוכלו להצטרף לאירועים בעת הצורך מבלי לחשוף מזהים ברורים לכל משתמש או כלי.
- החלף רשומות מפורטות וישנות יותר בסטטיסטיקות מצטברות או סיכומים ברגע שהן אינן נחוצות עוד באופן מציאותי לתגובה לאירועים או לראיות משפטיות.
- בדקו באופן קבוע אחזור וניתוח של יומני רישום מאוחסנים עבור תרחישי אירועים מייצגים, כדי שתדעו שתכנון השמירה שלכם עובד בפועל, לא רק על הנייר.
תיעוד של סוגי יומני הרישום, תקופות השמירה, נימוקי הסיכונים והאישורים ב-ISMS.online, הן תחת A.8.15 והן תחת בקרות פרטיות רלוונטיות, מספק לכם נתיב ביקורת שתוכלו להציג למבקרים, רגולטורים ולקוחות שרוצים להבין מדוע סוג מסוים של יומן נשמר לתקופה נתונה.
כיצד יכול MSP להוכיח בצורה משכנעת עמידה בתקן A.8.15 במהלך ביקורת ISO 27001?
רואי חשבון נוטים לבחון את A.8.15 דרך שלוש עדשות: עיצוב, מבצע ו השבחהאתם לא נשפטים על סמך בעלות על SIEM מסוים, אלא על סמך האם אתם יכולים להראות שהרישום תוכנן במכוון, פועל כמתואר ונבדק.
מה עליכם להכין לפני ביקורת המתמקדת ב-A.8.15?
ערכת ראיות תמציתית הממופה ל-A.8.15 הופכת את שיחת הביקורת לחלקה הרבה יותר. היא כוללת בדרך כלל:
- מדיניות או תקן רישום רישום המתייחסים במפורש ל-A.8.15 ולבקרות הקשורות לניטור וטיפול באירועים.
- תוכניות רישום ברמת השירות המסבירות, עבור כל שירות מנוהל עיקרי, אילו מקורות רישום משמשים, כיצד פועלת הפרדה מרובת דיירים וכיצד מיושמת השמירה.
- מטריצת סיווג ושמירה של יומני רישום המציגה כמה זמן כל סוג של יומני רישום נשמרת ומדוע.
- הצהרת הישימות שלך עם תמונה ברורה של כל הבקרות הקשורות לרישום והחלטות יישום או אי הכללה שלך.
לניתוח, ניתן להכין:
- צילומי מסך או ייצוא של תצורה המוכיחים שמקורות מפתח, מזהי דיירים, אפשרויות שלמות והגדרות שמירה מופעלים.
- דוגמאות של סקירות יומנים מתוזמנות, תורי התראות ולוחות מחוונים של אבטחה, כולל מי סקר אותם ומה הוא עשה עם הממצאים.
- מספר קטן של רישומי חקירה שבהם יומנים מילאו תפקיד מרכזי בהבנה או בפתרון בעיה.
- פרוטוקולי סקירת הנהלה או רישומי שיפור שבהם נדונו ביצועי רישום, כיסוי או אירועים.
אם פריטים אלו נמצאים ב-ISMS.online ומקושרים ל-A.8.15 ולשירותים הרלוונטיים, תוכלו להדריך את המבקרים משלב המדיניות ועד לדוגמאות מעשיות בצורה הגיונית במקום לחפש בדוא"ל או בתיקיות מקומיות.
כיצד ניתן להציג רישום כבקרת הבשלה ולא כדרישה סטטית?
מבקרים בדרך כלל רגועים יותר כשהם רואים שרישום הוא חלק ממחזור שיפור מתמשך. ניתן להדגים זאת על ידי:
- רישום סיכונים, בעיות ושינויים הקשורים ליומן כחלק מתהליכי הסיכונים והשיפור שלך, עם הבעלים ותאריכי יעד.
- הצגת לוח זמנים לסקירה של תקן הרישום, מודל השמירה ומיפויי השירות, והוכחה לכך שסקירות מובילות לעדכונים.
- לכידת לקחים שנלמדו מחקירות שבהן רישום הנתונים ביצע ביצועים טובים או חשף פער, ולאחר מכן קישור לקחים אלה לשינויים בתצורה, בכיסוי או בתהליך.
היכולת לעבור על אלמנטים אלה ב-ISMS.online תחת A.8.15 עוזרת לשנות את טון הביקורת מ"האם סימנתם את התיבה הזו?" ל"כיצד אתם משתמשים ברישום כדי לחזק את השירותים המנוהלים שלכם לאורך זמן?", מה שתומך במוניטין שאתם רוצים כ-MSP רציני.
כיצד ISMS.online עוזר ל-MSP שלכם להפוך רישום ושמירה לשירות אמין וחוזר על עצמו?
עבור ספקי שירותי ניהול רשתות (MSP) רבים, האתגר עם A.8.15 אינו האם כלי יכול לאסוף יומני רישום, אלא האם רישום ושמירה הם עקבי, ניתן להסבר ובר קיימא מבחינה מסחרית בקרב לקוחות. ISMS.online מסייע בכך שהוא מתייחס לגישת הרישום שלכם כחלק מוסדר ממערכת הניהול שלכם במקום כקבוצה של פרקטיקות מפוזרות.
כיצד ISMS.online יכול לתמוך בתכנון, באחריות ובראיות שלכם לרישום תיעוד?
בתוך ISMS.online תוכלו להביא את A.8.15 תחת אותה שליטה כמו שאר עבודתכם בתקן ISO 27001:
- רשמו את מדיניות הרישום והתקן שלכם פעם אחת, קשרו אותם ישירות ל-A.8.15 ולבקרות קשורות, והפכו אותם לגלויים למהנדסים, אנליסטים ובעלי שירותים.
- מפו כל שירות מנוהל לתקן זה כך שתמיד תדעו אילו מקורות יומן, ארכיטקטורות וכללי שמירה חלים על הצעות של "M365 מנוהל", "חומת אש מנוהלת", "נקודת קצה מנוהלת" והצעות דומות.
- שמרו על מטריצת סיווג ושמירה יחידה של יומני רישום, המקושרים לסיכונים, חוזים ותקנות, כאשר תאריכי אישורים ובדיקה רשומים בבירור.
- הקצאת אחריות על סקירות יומנים, טיפול בחריגים ומשימות שיפור ומעקב אחר השלמתן באמצעות זרימות עבודה ותזכורות מובנות.
- צרף דיאגרמות ארכיטקטורה, רישומי סקירה, סיכומי חקירות וסימונים מפגישות ניהול ישירות ל-A.8.15 ולשירותים בודדים, כך שיהיה קל לאסוף ראיות עבור רואי חשבון, מבטחים או לקוחות חשובים.
מכיוון שהכל נמצא בסביבה אחת, עדכונים שאתם מבצעים בעיצוב הרישום ובשמירה מתיישבים אוטומטית עם מערכת ה-ISMS הרחבה יותר שלכם במקום ללכת לאיבוד בגיליונות אלקטרוניים או בתיקיות אישיות.
אילו יתרונות מעשיים יבחינו הצוות והלקוחות שלך מדי יום?
כאשר רישום ושמירה מנוהלים דרך ISMS.online, מנהיגי אבטחה עובדים מ... תוכנית אב יחידה לשימוש חוזר עבור A.8.15 על פני דיירים ואזורים, מהנדסים פועלים לפי סטנדרטים ולוחות זמנים ברורים במקום הרגלים אד-הוק, וצוותים מסחריים יכולים להסביר כיצד רישום תומך בכל רמת שירות במקום להסתמך על הבטחות מעורפלות.
עם הזמן, שילוב זה משנה לעתים קרובות את האופן שבו לקוחות ומבקרים רואים את ה-MSP שלכם. במקום לקוות ש"הכלים רושמים מספיק כברירת מחדל", אתם הופכים לספק שיכול להסביר בדיוק כיצד הרישום מתוכנן, מופעל ומשופר, ומי יכול להראות את הקומה הזו בבירור ב-ISMS שלכם. לקיחת זמן לתיעוד גישת הרישום הנוכחית שלכם והשיפורים הבאים ב-ISMS.online היא מהלך פשוט אם אתם רוצים ש-A.8.15 יתמוך במוניטין שלכם במקום להרגיש כמו עוד מכשול תאימות.
