מדוע הסמכת גישה מחדש של MSP חיונית לתאימות לתקן ISO 27001 A.5.18

מדוע גישה ל-MSP היא רדיוס הפיצוץ המשותף החדש

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

כ-41% מהנשאלים בסקר מצב אבטחת המידע של ISMS.online לשנת 2025 אמרו כי ניהול סיכוני צד שלישי ומעקב אחר תאימות ספקים הם אחד מאתגרי אבטחת המידע העיקריים שלהם.

בעיית רדיוס הפיצוץ של MSP במונחים פשוטים

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

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

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

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

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

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

זחילת פריבילגיות ותרבות גישה טובה מספיק

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

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

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

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

הזמן הדגמה

מה באמת דורש תקן ISO 27001:2022 A.5.18

תקן ISO 27001:2022 A.5.18 מצפה מכם לשלוט על מחזור החיים המלא של זכויות הגישה, כך שאנשים יוכלו לקבל רק את המינימום הדרוש להם, כל עוד הם זקוקים לו. עבור ספק שירותי ניהול גישה (MSP), פירוש הדבר הוא היכולת להראות כיצד אתם מקצה, משנה, סוקרים ומסירים גישה לכל זהות, עם אישורים ברורים וראיות מאחורי כל החלטה. ניסוח נספח A.5.18 קורא להקצאה, סקירה, שינוי והסרה של זכויות גישה בהתאם למדיניות בקרת הגישה שלכם, ועקרונות בקרת הגישה הרחבים יותר של ISO 27001 מחזקים את הרעיון שיש להגביל את הגישה למה שדרוש למשימה ולמשך הזמן, כפי שמשתקף במדריכי יישום של גופי תקינה כמו BSI.

הפיכת טקסט בקרה צפוף לפעלים מעשיים

A.5.18 מתמצה בארבע פעולות עבור ספק הגישה (MSP) שלכם: הקצאה, שינוי, סקירה והסרה של גישה באופן עקבי וניתן למעקב. אם תוכלו לתאר ולהוכיח את ארבעת השלבים הללו עבור זהויות אמיתיות, אתם כבר קרובים לסיפוק כוונת הבקרה.

על הנייר, סעיף A.5.18 יכול להיראות מופשט: "יש להקצות, לבדוק, לשנות ולהסיר זכויות גישה למידע ולנכסים נלווים אחרים בהתאם למדיניות ולכללים הספציפיים לנושא של הארגון לבקרת גישה." בפועל, זה הופך לארבעה פעלים קונקרטיים עבור ה-MSP שלכם, שנלקחו ישירות מ-ISO 27001:2022 נספח A.5.18:

אַספָּקָה: – כיצד מבוקשת, מאושרת ומוענקת גישה חדשה.
שנה: – כיצד הגישה משתנה כאשר תפקידים, תחומי אחריות או היקפי לקוחות משתנים.
סקירה: – כיצד נבדקת ומאושרת מחדש מעת לעת גישה קיימת.
לְהַסִיר: – כיצד הגישה נשללת כאשר אנשים עוזבים, פרויקטים מסתיימים או כלים יוצאים משימוש.

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

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

חיבור A.5.18 למינימום פריבילגיה ורדיוס פיצוץ מינימלי

A.5.18 מקשר ישירות ל-minst privilege על ידי דרישה שזכויות גישה ישקפו את צרכי העסק ויתחזקו באופן פעיל לאורך זמן. הבקרה לא רק מבקשת מדיניות; היא מצפה שתראה כיצד מדיניות זו מובנית בהחלטות אמיתיות בנוגע להקצאה, סקירה והסרה, כך שרדיוס הפיצוץ של כל זהות בודדת יישאר קטן ככל האפשר.

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

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

עבור ספקי שירותים ניידים (MSPs), יש טוויסט נוסף: יש לחול מינימום הרשאות על פני כל האזורים. פנימי מערכות (משאבי אנוש, כספים, כרטוס, תיעוד) ו לקוח מערכות (דיירי ענן, שרתי מקומיים, פורטלי ניהול SaaS). גישה אל אלה מתבצעת לעיתים קרובות דרך אותם כלים מרובי דיירים שבהם אתם כבר משתמשים, ולכן A.5.18 מצפה מכם להתייחס להגעה משולבת זו כחלק מניהול הגישה שלכם, ולא כערוץ צדדי לא פורמלי המטופל על ידי מהנדסים. גישה חוצת סביבות זו משותפת בהנחיות לאומיות ואירופיות בנושא MSP וסיכוני שרשרת אספקה, כולל עבודה של גופים כמו ENISA, המדגישים כי גישת ספקים לסביבות לקוחות חייבת להיות במסגרת הסדרי ניהול גישה פורמליים.

ISMS.online יכול לעזור לכם על ידי מתן מקום מובנה לאחסון מדיניות, הגדרות תפקידים, רישומי אישורים, לוחות זמנים לסקירה וראיות להסרות, כולם ממופים חזרה ל-A.5.18 ובקרות קשורות. ללא קשר לכלי העבודה, שינוי החשיבה זהה: זכויות גישה כבר לא עוסקות רק במי שיכול להתחבר; הן עוסקות במי יכול להשפיע על תוצאות הלקוחות וכיצד אתם מוכיחים שסמכויות אלו הן מידתיות ומאתגרות באופן קבוע.

ISMS.online מעניק לך יתרון של 81% מרגע הכניסה

ISO 27001 בקלות

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

התחל כאן

פירוש A.5.18 עבור ספקי שירותי ניהול שירותים (MSPs): גישה פנימית לעומת גישה ללקוחות

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

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

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

מנקודת מבט של תקן ISO 27001, "זכויות גישה" מכסות חשבונות, תפקידים ונתיבים טכניים אל:

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

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

שאלות מעשיות שיעזרו:

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

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

אחריות משותפת בינך לבין הלקוחות שלך

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

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

בסקר מצב אבטחת המידע ISMS.online שלנו לשנת 2025, דרישות אבטחה אופייניות מספקים כללו את התקנים ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 וסטנדרטים מתפתחים הקשורים לבינה מלאכותית.

דרך מעשית לבטא זאת היא מודל פשוט של אחריות משותפת:

לָקוּחַ: – מגדיר ומאשר אילו תפקידים מקובלים (לדוגמה, "לתמיכה ברמה שתיים של MSP עשויה להיות גישה לקריאה בלבד לנתוני ייצור, אך לא לגישה לכתיבה"), ומשתתף בהסמכות מחדש תקופתיות עבור הסביבות שלהם.
MSP: – מיישם ואוכף גישה בהתאם להחלטות אלו, מבטיח ששינויים בין מצטרפים-עוברים-עוזבים משתקפים במהירות, מבצע בקרות יומיות (לדוגמה, ניטור, רישום, ניהול סיסמאות) ומספק ראיות ברורות ללקוח ולמבקרים.

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

תכנון גישה בעלת הרשאות מוגבלות עבור סביבות MSP ולקוחות

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

מודלים מבוססי תפקידים שמתאימים בפועל למציאות של MSP

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

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

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

עבור כל תפקיד, תאר:

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

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

צמצום זכויות עמידה ושליטה בהעלאה זמנית

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

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

גישה הגנתית יותר היא:

הגבל את מספר האנשים שיש להם תפקידי ניהול קבועים, במיוחד על פני מספר דיירים.
השתמשו ב-Just-in-Time Elevation עבור משימות שבאמת דורשות הרשאות נוספות, עם נימוק ברור ומגבלות זמן קצרות.
אכיפת אימות חזק ובדיקות נוספות (לדוגמה, תנוחת המכשיר או מיקום) עבור כל הגישה המועדפת לסביבות הלקוח.
התייחסו לחשבונות "שבירת זכוכית" או חשבונות חירום כאל יוצאים מן הכלל, עם רישום קפדני, סקירה לאחר מעשה וביטול מהיר לאחר השימוש.

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

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

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

הזמן את ההדגמה שלך

בניית מסגרת הסמכה מחדש של גישה תואמת A.5.18 עבור ספקי שירותי ניהול רשת (MSPs)

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

שימוש בתדירות סקירה מבוססת סיכון במקום תאריכים שרירותיים

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

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

תקן ISO 27001 אינו מציין בדיוק באיזו תדירות יש לבדוק את זכויות הגישה, משום שתדירותה המתאימה תלויה בסיכון. נספח A.5.18 והנחיות היישום הקשורות דורשים פשוט לבדוק את זכויות הגישה מעת לעת כחלק ממערכת ה-ISMS מבוססת הסיכונים שלכם, מה שמותיר לכם לבחור מרווחי זמן התואמים את ההקשר וההתחייבויות שלכם, כפי שמוסבר בהנחיות ISO 27001:2022.

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

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

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

תכנון תהליכי עבודה של הסמכה מחדש שאנשים באמת פועלים לפיה

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

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

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

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

הגדרת תפקידים ואחריות בין MSP ללקוח

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

יצירת RACI פשוט ומפורש עבור זכויות גישה

RACI פשוט (Responsible, Accountable, Consulted, Informed) עבור זכויות גישה מספק לכם מפה משותפת של מי מקבל החלטות ומי מבצע אותן. כאשר אתם יכולים להצביע על מפה זו במהלך ביקורות או אירועים, אתם מפחיתים בלבול ומראים ש-A.5.18 מוטמע במודל התפעולי שלכם במקום להישאר להסכמים בלתי פורמליים.

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

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

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

התמודדות עם אזורים אפורים ומצבים של לחץ גבוה

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

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

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

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

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

ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.

הזמן את ההדגמה שלך

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

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

בחירת אינדיקטורים משמעותיים עבור דירקטוריונים ולקוחות

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

דוגמאות כוללות:

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

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

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

סטנדרטיזציה של ערכת הראיות שלך עבור A.5.18

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

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

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

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

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

הזמן הדגמה עם ISMS.online עוד היום

ISMS.online מספק לכם מקום אחד לתכנון, תפעול והוכחת ניהול גישת MSP בהתאם לתקן A.5.18, כך שתוכלו להגביל את רדיוס הפיצוץ ולהוכיח את הזכויות הנמוכות ביותר מבלי להטביע את המהנדסים שלכם בניהול נוסף. הפלטפורמה בנויה לריכוז מדיניות, זרימות עבודה והוכחות עבור ISO 27001 ומסגרות קשורות, כמתואר בתיעוד המוצר שלנו ובהנחיות הטמעה ללקוחות באתר isms.online. אם ברצונכם לבדוק עד כמה אוסף הגישה הנוכחי שלכם באמת חזק, הדגמה קצרה היא דרך מעשית להשוות את הבקרות הקיימות שלכם מול מודלי מחזור החיים, ההסמכה מחדש והאחריות המתוארים כאן.

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

מה תראו בהדגמה

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

במהלך הדגמה, תוכלו לצפות ל:

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

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

כיצד הדגמה עוזרת לך לסגור פערים ב-A.5.18

הדגמה אינה רק סיור מוצר; זוהי הזדמנות לבחון את רשת הגישה הנוכחית שלכם מול הציפיות של A.5.18 ובקרות קשורות. ראיית האופן שבו מדיניות, תפקידים, אחריות וראיות משתלבים יחד ב-ISMS.online עוזרת לכם לזהות היכן נמצאים הפערים הגדולים ביותר שלכם כיום ואילו שינויים יעניקו לכם את ההפחתה הגדולה ביותר בסיכון ובמאמץ.

למרות הלחץ הגובר, רוב המשיבים בסקר ISMS.online לשנת 2025 שלנו בנושא מצב אבטחת מידע ציינו השגה או שמירה על הסמכות כגון ISO 27001 או SOC 2 כעדיפות עליונה.

אינכם צריכים לעצב מחדש את שרת הגישה המבוקרת (MSP) שלכם מאפס כדי לעמוד בדרישות A.5.18. אתם זקוקים למודל ברור, לקצבי הסמכה מחדש ריאליסטיים ולמקום שבו אחריות, זרימות עבודה וראיות חיים יחד. ISMS.online נועד לספק לכם בדיוק את זה, כך שתוכלו להפחית את רדיוס הפיצוץ, להכיל זחילת הרשאות ולהוכיח את הרשאות הנמוכות ביותר בביטחון. אם אתם רוצים לפעול כ-MSP ברדיוס פיצוץ נמוך שיכול להציג גישה מבוקרת לפי דרישה, הזמנת הדגמה קצרה היא צעד מעשי הבא עבור הארגון שלכם ואות ברור ללקוחות שלכם שאתם לוקחים את האמון שלהם ברצינות.

הזמן הדגמה

שאלות נפוצות

כיצד משנה תקן ISO 27001 A.5.18 את האופן שבו ספקי שירותי ניהול שירותים (MSPs) צריכים לחשוב על "למי יש גישה למה"?

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

גישת צפייה בכל שלוש שכבות ה-MSP

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

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

עבור כל חשבון אנושי או שירות, רואה חשבון מצפה ממך כעת להציג:

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

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

שרטוט דיאגרמת מסלול שחייה פשוטה עם ארבעה שלבים (הקצאה ← שינוי ← סקירה ← הסרה) ושורות עבור מערכות פנימיות, כלי MSP משותפים ודיירי לקוחות מראה במהירות היכן התהליך האמיתי הוא עדיין "אנחנו שואלים מסביב". אלו בדיוק נקודות התורפה שמבקרים של ISO 27001 ולקוחות ארגוניים יבחנו.

ISMS.online עוזר לכם להפוך את מחזור החיים הזה לגלוי וניתן לחזרה על ידי שמירת מדיניות הגישה, קטלוג התפקידים, זרימות העבודה והראיות שלכם בסביבת עבודה אחת ומנוהלת. כלי ה-IAM, ה-RMM והגישה מרחוק שלכם עדיין מבצעים את העבודה הטכנית הקשה; ISMS.online מספק לכם מידע הניתן לאימות לגבי למי יש גישה למה, על איזה בסיס ולמשך כמה זמן - וזה בסופו של דבר מה ש-A.5.18 מנסה לאכוף.

כיצד נראה מודל מעשי של פחות הרשאות עבור ספק שירותי ניהול שירותים (MSP) במערכות פנימיות ובמערכות של הלקוח?

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

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

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

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

לאחר מכן, החליטו, תפקיד אחר תפקיד:

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

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

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

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

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

שימוש בקצב מבוסס סיכון במקום בסקירה שנתית שטוחה

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

סוג גישה	קצב סקירה טיפוסי	מיקוד הסוקר
ניהול כלל-MSP בסביבות לקוחות	חודשי + לאחר שינויים משמעותיים	נחיצות, היקף, שימוש חירום, SoD
חשבונות שירות (סקריפטים, אינטגרציות, גיבויים)	רבעוני + לאחר הגדרת התצורה	בעלות, מטרה, רישום, שימוש יתום
RMM, VPN וכלים אחרים לגישה מרחוק	רבעון	חברות בקבוצה, הגעה בין דיירים
חשבונות משתמש פנימיים סטנדרטיים	כל 6-12 חודשים	התאמת תפקיד, עובדים עוברים/עוזבים
גישה זמנית / גישה מועדפת לשבירת זכוכית	לאחר כל שימוש + סיכום חודשי	הצדקה, ביטול, שימוש חריג

לצד קצב הביקורות, שמרו על פשטות ועקביות:

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

ISMS.online מאפשר לכם לתזמן את הסקירות הללו, להקצות בודקים ולצרף ייצוא או דוחות מכלי IAM, RMM, VPN וכלי גישה מרחוק, כך שהחלטות ומעקב יהיו במקום אחד. זה הופך את "אנו בודקים גישה באופן קבוע" מהצהרה אופטימית במדיניות לבקרה גלויה וחוזרת שתוכלו לעבור עליה ברוגע עם מבקר ISO 27001 או צוות אבטחת לקוחות תובעני.

כיצד יכול ספק שירותי ניהול שירותים (MSP) לפצל בבירור את האחריות על זכויות גישה עם כל לקוח?

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

המרת "אחריות משותפת" להסכם בר-בדיקה

דפוס פשוט ויעיל הוא מודל בסגנון RACI שמפרט מי אחראי על מה:

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

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

יחד, אתם מסכימים כיצד זה עובד כאשר:

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

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

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

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

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

בניית לוח ניקוד קצר ואמין לניהול גישה

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

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

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

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

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

כיצד ISMS.online יכול לעזור ל-MSP להפעיל את A.5.18 מבלי להאט את המהנדסים?

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

המרת החלטות אד-הוק של ימינו למשטר גישה מפוקח

במונחים יומיומיים, הצוות שלכם יכול להשתמש ב-ISMS.online כדי:

לכידת מדיניות גישה תואמת A.5.18, קטלוג תפקידים ריאליסטי ו-MSP/RACI של לקוח במקום אחד, כך שכולם יוכלו לראות מי יכול לאשר ולהחזיק באיזו גישה.
קישור זרימות עבודה של מצטרף-עובר-עוזב ובקשות גישה למערכות משאבי אנוש או כרטוס, כך ששינויים באנשים ובתחומי האחריות יניעו באופן אמין שינויים בגישה.
לוח זמנים ביקורות גישה מבוססות סיכון עבור חשבונות, כלים ודיירים בסיכון גבוה, יש להקצות בודקים ולצרף ייצוא או צילומי מסך מ-IAM, RMM, VPN, כספות סיסמאות ופלטפורמות אחרות כתיעוד של מה שנבדק והתוקן.
לשמור על חיים חבילת ראיות עבור A.5.18 ובקרות גישה קשורות, המוכנות לביקורות ISO 27001 ולבקשות בדיקת נאותות של לקוחות, במקום להרכיב אותן מחדש בבהלה מגיליונות אלקטרוניים ושבילי דוא"ל.

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

אם אתם רוצים שספק שירותי התקשורת (MSP) שלכם יהיה זה שיכול להראות לוועדות וללקוחות שהגישה מבוקרת ורדיוס הפיצוץ מוגבל – במקום לקוות שאנשים פשוט יסכימו למילה שלכם – כדאי לבדוק כיצד ספקים דומים משתמשים ב-ISMS.online כדי לבנות את A.5.18. זה עוזר לכם להופיע כשותפים שיכולים... לְהַצִיג גישה מבוקרת לפי דרישה, לא רק להבטיח אותה בזמן הביקורת.