כיצד ספקי שירותי ניהול שירותי ניהול (MSP) שומרים על תאימות לתקן ISO 27001 באמצעות פלטפורמות ענן ציבורי

כאב הראש של ריבוי עננים וריבוי דיירים עבור ספקי שירותי ניהול שירותים (MSP) לפי ISO 27001

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

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

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

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

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

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

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

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

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

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

נקודות תורפה אופייניות ש-MSP מתעלמים מהן

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

מספר דפוסים מופיעים שוב ושוב כאשר ספקי שירותי ניהול שירותים (MSP) מעבירים שירותים לענן ציבורי ומנסים לשמור על תקן ISO 27001:

בהנחה שהענן מאושר, אז אנחנו בסדר.:

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

לא מפרט פלטפורמות משותפות כנכסים.:

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

דפוסי בידוד לא עקביים של דיירים:

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

ידע גיבור לא מתועד.

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

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

הזמן הדגמה

שינוי מסגור הענן כהרחבה של טווח ה-ISMS שלך

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

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

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

רענון הצהרת ההיקף שלך עבור ענן ציבורי

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

הצהרת ההיקף שלך צריכה לענות על שלוש שאלות:

אילו שירותים מכוסים?:

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

אילו סביבות מכוסות?:

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

אילו מפלגות ומיקומים רלוונטיים?:

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

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

התאמת ניהול סיכונים, נכסים וספקים

התאמת ניהול סיכונים, נכסים וספקים לענן פירושה לגרום לתהליכי ISO 27001 הקיימים שלכם לדבר את שפת החשבונות, האזורים והשירותים המנוהלים. במקום להסתיר את הענן תחת סיכוני מיקור חוץ גנריים, אתם נותנים לו ערכים מפורשים במתודולוגיה, במלאי וברמות הספק שלכם, כך שסעיפים 4, 5 ו-6 יישארו מבוססים על איך אתם פועלים באמת.

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

ברגע שענן מופיע במפורש בהיקף, מספר חלקים תומכים של מערכת ה-ISMS זקוקים לרענון:

מתודולוגיית סיכונים:

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

מלאי נכסים:

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

ניהול ספקים:

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

הצהרת תחולה:

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

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

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

ISO 27001 בקלות

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

התחל כאן

תכנון ארכיטקטורות מרובות דיירים תואמות לתקן ISO 27001 (AWS, Azure, GCP)

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

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

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

השוואה בין מודלים משולבים, מודלים מבודדים ומודלים היברידיים

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

הנה תמונה פשוטה של הפשרות העומדות בפניכם:

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

מודל משותף:

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

דגם סילואד:

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

דגם היברידי:

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

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

שימוש באבני בניין לענן בצורה ידידותית ל-ISO

שימוש באבני בניין של ענן בצורה ידידותית לתקן ISO פירושו יישור מבני AWS, Azure ו-Google Cloud עם נושאי בקרה של נספח A כגון בקרת גישה, הפרדה, רישום וניהול ספקים. אם תוכלו להסביר חשבונות, מנויים, פרויקטים וקבוצות ניהול בשפה זו, תהפכו את טרמינולוגיית הענן שעלולה להיות מבלבלת לקומת אבטחה קוהרנטית.

לכל ענן עיקרי יש טרמינולוגיה ותכונות משלו, אך העקרונות המותאמים ל-ISO דומים:

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

On תכלתדיירים, קבוצות ניהול ומנויים של Entra מספקים היררכיה; ספקי שירותי ניהול רבים משתמשים בתבנית מנוי לפי לקוח עם שירותי ניהול משותפים.

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

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

הטמעת אבטחה בצינורות ובתיעוד

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

שלב 1 – בניית מעקות בטיחות בקוד התשתית

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

שלב 2 – שילוב בדיקות אבטחה ב-CI/CD

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

שלב 3 – רישום החלטות ואיומים בתיעוד

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

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

מיפוי ISO 27001:2022 נספח A לשירותי ענן ודפוסים

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

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

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

בניית מטריצת שליטה-לשירות

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

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

בקרת גישה וזהות:

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

רישום וניטור:

בקרות בנוגע לרישום אירועים, ניטור ומפת זיהוי אנומליות לשירותי רישום ענן, SIEM מרכזי, התראות וריצות (runbooks) לטיפול באירועים.

גיבוי, שחזור ומחיקת מידע:

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

שימוש בספק ובענן:

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

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

שלב 1 – בחירת ערכות נושא לשליטה כבדות ענן

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

שלב 2 – קישור כל בקרה לשירותים קונקרטיים

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

שלב 3 - החלטה מה נחשב כראיה

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

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

יישור קווי בסיס, מסגרות וראיות

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

ברגע שיש לך מטריצה בסיסית, שלושה יתרונות מעשיים יבואו בעקבותיה:

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

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

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

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

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

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

כל ספק ענן גדול מפרסם מודל אחריות משותפת. ספקים גדולים כמו AWS, Microsoft Azure ו-Google Cloud מפרסמים כולם מודלים משלהם של אחריות משותפת, וקבוצות תעשייה כמו Cloud Security Alliance דנות כיצד לתקשר וליישם אותם בפועל במשאבים כמו הבלוג שלהם בנושא תקשורת אחריות משותפת בענן. ברמה גבוהה, כולם אומרים את אותו הדבר: הספק מאבטח את הענן, אתם מאבטחים את מה שאתם שמים בענן. כאשר מוסיפים לתמונה זו שירותי MSP וחובות לקוח, הפיצול הופך מסובך יותר - וחשוב יותר עבור ISO 27001.

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

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

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

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

על מה אחראי ספק הענן?
על מה אתה, כחבר פרלמנט, אחראי?
על מה הלקוח אחראי?

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

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

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

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

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

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

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

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

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

תאימות מתמשכת: ניהול, ניטור וראיות

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

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

תאימות מתמשכת קלה יותר כאשר היא מבוססת על המערכות שכבר סומכות עליהן לצורך פעילות.

תכנון ניטור המשמש גם כראיות

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

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

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

התראות מפה לבקרות.:

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

מרכזו בקפידה את הנראות בין-דיירים.

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

לכידת הקשר עם אירועים.:

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

שלב 1 – החלטה אילו בקרות דורשות ניטור ישיר

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

שלב 2 – עיצוב לוחות מחוונים והתראות סביב בקרות אלו

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

שלב 3 – שימוש חוזר בתוצרי הניטור בביקורת פנימית ובסקירה

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

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

אוטומציה, דיווח וטריגרים לשינוי

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

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

אוטומציה לאכיפת קווי בסיס:

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

דוחות ממשל תקופתיים:

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

טריגרים ברורים כדי לחזור למצב שליטה.:

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

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

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

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

הפיכת "ISO בענן" ליתרון מסחרי

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

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

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

אבטחת אריזה כתכונות, לא רק תעודות

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

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

ניתן להשתמש בשיטות העבודה הענן המותאמות לתקן ISO כדי:

הציעו רמות שירות ברורות הקושרות את רמות הבידוד והביטחון של הדיירים לבקרות מתועדות המתואמות ל-ISO.

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

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

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

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

מדידה ותקשורת של ההשפעה המסחרית

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

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

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

זמן משאלון אבטחה ועד חתימת חוזה.

עסקאות שהפסידו מסיבות אבטחה או תאימות.

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

שלב 1 – בחירת קבוצה קטנה של מדדי KPI לאבטחה מסחרית

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

שלב 2 - ללכוד ולבדוק את המדדים הללו באופן קבוע

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

שלב 3 – הזנת תובנות בחזרה למערכת ה-ISMS ולהצעות שלך

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

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

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

ISMS.online עוזרת לכם להפעיל מערכת ניהול אחת, תואמת לענן ISO 27001, שעומדת בקצב האופן שבו ספק שירותי הניהול (MSP) שלכם משתמש בפועל ב-AWS, Azure ו-Google Cloud. במקום להתעסק עם גיליונות אלקטרוניים, דיאגרמות ותיקיות ראיות אד-הוק, תוכלו לאגד סיכונים, בקרות, מטריצות אחריות משותפת ותיעוד ספציפי לענן במקום אחד ולחבר אותם לעבודה היומיומית שהצוותים שלכם כבר עושים.

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

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

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

שאלות נפוצות

כיצד העברת לקוחות MSP לענן ציבורי באמת משנה את תאימות ISO 27001 שלכם?

העברת לקוחות ל-AWS, Azure או Google Cloud משנה את תאימות ה-ISO 27001 שלכם מכיוון שההיקף, הסיכונים והבקרות שלכם עוברים מערכה פיזית לפלטפורמות ענן, חשבונות ואוטומציה, ומערכת ה-ISMS שלכם צריכה ללכוד את השינוי הזה או שהיא מפסיקה לשקף את האופן שבו אתם מנהלים שירותים בפועל.

אילו אלמנטים של ISMS כדאי לעדכן תחילה עבור ענן ציבורי?

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

היקף והקשר:

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

מלאי וסיווג נכסים:

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

הערכת סיכונים וטיפול:

איומים פיזיים יורדים ברלוונטיות; סיכונים ממוקדי ענן עולים. תצורה שגויה, תפקידים רחבים מדי, ממשקי ניהול חשופים, בקרות API חלשות, אוטומציה לא מאובטחת והפסקות אזוריות של ספקים צריכים להיות גלויים במרשם הסיכונים שלך, כאשר הטיפולים ממופים לבקרות של נספח A כגון A.5.23 (שימוש בשירותי ענן) ובקרות הרשת ב-A.8.20–A.8.22.

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

כיצד ענן ציבורי משנה את אופן הפעולה של "שליטה" בפועל?

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

בקרת גישה מופיעה בספקי זהויות, תפקידים, מדיניות, גישה מותנית וזרימות עבודה של גישה פריבילגית.
הפרדת רשת מופיעה ב-VPCs/VNets, קבוצות אבטחה, NSGs, חומות אש, נקודות קצה פרטיות וכללי עמיתים.
גיבוי, ניטור וטיפול באירועים מסתמכים על שירותים מקוריים המחוברים יחד באמצעות תשתית כקוד, פונקציות ללא שרת וריצות (runbooks).

עבור ספק שירותי ניהול רשת (MSP) בעל הסמכת ISO 27001, המבחן הוא האם מנופים אלה הם:

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

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

כיצד צריך MSP לתכנן ארכיטקטורות ענן מרובות דיירים שעדיין יעבדו תחת תקן ISO 27001?

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

אילו דפוסי ריבוי דיירים נוטים לעבוד היטב עבור ISO 27001 ב-AWS, Azure ו-Google Cloud?

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

שכירות משותפת עבור שירותים בסיכון נמוך:

לקוחות מרובים חולקים תשתית בסיסית (לדוגמה, אשכולות Kubernetes משותפים או SaaS מרובי דיירים), כאשר הבידוד נאכף על ידי מזהים, סכמות, מרחבי שמות והרשאות. כדי לשמור על ISO-ידידותיות, עליך לפרט:

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

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

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

מישור בקרה משותף עם מישורי נתונים מופרדים:

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

מה שחשוב ביותר הוא שתוכלו להראות:

A ארכיטקטורת ייחוס מתועדת עבור כל תבנית, עם דיאגרמות ודוגמאות של תשתית כקוד.
עקבה מכל תבנית לתוך שלך רישום סיכונים ו בקרות נספח א' (לדוגמה, A.8.20–A.8.22 עבור אבטחת רשת והפרדה נפרדת).
שינוי ובדיקה של תהליכים המבטיחים שכל דייר חדש יעקוב אחר דפוס ידוע ולא אחר "מה שמהנדס עשה תחת לחץ".

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

איך אתם מסבירים את מודל רב-הדיירים שלכם כך שמבקרים ולקוחות יסמכו עליו?

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

סיכון: "גישה לנתונים בין-דיירים בפלטפורמה משותפת."
עיצוב: "תבנית אשכול מקובץ עם מרחבי שמות לכל דייר, מדיניות רשת ומפתחות הצפנה בטווח דיירים."
תְצוּרָה: "תבניות בסיסיות ומעקות בטיחות שאנו מיישמים דרך Terraform או צינורות פריסה."
עֵדוּת: "תוצאות בדיקות, בדיקות בידוד, יומני רישום ואירועים המראים שהבקרות פועלות לאורך זמן."

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

כיצד יכול MSP למפות בקרות ISO 27001:2022 Annex A לשירותי AWS, Azure ו-Google Cloud?

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

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

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

נספח א' תחום מיקוד	שירותי ענן בהיקף	תצורה ותהליכים בסיסיים
בקרת גישה (משפחת A.5, A.8.x)	IAM, Azure AD, IAM בענן, PIM/PAM	תפקידים סטנדרטיים, תואר שני במנהל עסקים, העלאה בשכר בזמן
רישום וניטור (A.8.15–A.8.16)	CloudTrail, Defender, רישום ענן, SIEM	ריכוזיות, ניתוב התראות, כוננות
גיבוי ושחזור (A.8.13–A.8.14)	תמונות מצב, כספות גיבוי, עותקים בין אזורים	לוחות זמנים, שמירה, שחזור בדיקות
שימוש בשירותי ענן (A.5.23)	קטלוגי ספקים, תהליך קליטת שירותים	סקירת ספקים, אישור סיכונים, תכנון יציאה

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

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

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

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

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

מדוע מיפוי זה שימושי מעבר להסמכת ISO 27001?

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

הרחב אותו כדי לכסות SOC 2, NIS 2, DORA או ISO 27701, במקום לעצב מטריצות חדשות מאפס.
האצת תשובות לשאלוני אבטחה ובקשות הצעות (RFP) משום שכבר ידוע לכם אילו דפוסים ושירותים עומדים בדרישות נפוצות.
תנו לצוותים שלכם מקור אמת אחד כיצד יש להגדיר ולתפעל את AWS, Azure ו-Google Cloud כדי להישאר בתוך מערכת ה-ISMS שלכם.

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

מה באמת המשמעות של אחריות משותפת עבור MSP מוסמך ISO 27001 בענן ציבורי?

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

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

דרך ישירה היא לשמור על מטריצת אחריות לכל שירות, בדרך כלל באמצעות RACI:

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

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

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

כל מטריצה צריכה להיות מתואמת עם:

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

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

כיצד יכול תקן ISO 27017 לחזק את מודל האחריות המשותפת שלכם?

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

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

התייחסות לתקן ISO 27017 במערכות הניהול והניהול השיווקי שלכם (ISMS) ובחומרי ניהול לקוחות הופכת את האחריות המשותפת מדיאגרמת שיווק למשהו שעומד במבחן ביקורות ISO 27001 ושיחות עם רגולטורים. ISMS.online עוזר לכם לשמור על מודלי האחריות, רישומי הסיכונים ומיפויי הבקרה מסונכרנים ככל ששירותי הענן שלכם מתפתחים.

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

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

אילו ארטיפקטים של ISMS צריכים להראות בבירור את השימוש שלך ב-AWS, Azure ו-Google Cloud?

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

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

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

אילו ראיות ברמת הענן נוטות להרגיע את מבקרי ISO 27001?

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

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

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

כיצד יכול ספק שירותי ניהול שירותי תקשורת (MSP) להפוך תאימות לתקן ISO 27001 המודע לענן ליתרון מסחרי?

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

כיצד ניתן לארוז שירותי ענן ציבורי כך שיהיו ברורים נקודות החוזק שלכם בתקן ISO 27001?

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

כל שכבה משלבת מודל בידוד דיירים (מאוחד, היברידי, ייעודי) עם:

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

לאחר מכן אתה מגבה כל שכבה עם:

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

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

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

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

כיצד פלטפורמת ISMS יכולה להפוך את קומת המסחר לקלה יותר לזיהוי?

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

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

אם אתם רוצים שלקוחות פוטנציאליים וקיימים יחוו אתכם כ-MSP ש... מוריד מכתפיהם את תאימות הענן הציבורי, כדאי לבחון כיצד פלטפורמת ISMS משולבת יכולה לחבר את עיצובי AWS, Azure ו-Google Cloud שלכם להתחייבויות ISO 27001 שלכם ולהבטחות שהקונים מצפים להן כיום כסטנדרט.

כיצד MSPS יכולים להשתמש בפלטפורמות ענן ציבורי תוך שמירה על תאימות לתקן ISO 27001