תוכן העניינים
מהי סקירת אבטחת ענן?
סקירת אבטחת ענן היא הערכה שיטתית של סביבת הענן בארגון, הכוללת בחינה של הקונפיגורציה, ניהול זהויות והרשאות (IAM), הגנת נתונים, רישום לוגים (Logging), בקרות רשת ומנגנוני ממשל, ביחס לקו בסיס אבטחתי מוכר. מטרת הסקירה היא לזהות קונפיגורציות שגויות, פערי אבטחה וחשיפות רגולטוריות לפני שהן מנוצלות על ידי תוקפים או מתגלות במסגרת ביקורת. בניגוד למבדק חדירות, שבו מנסים לנצל חולשות באופן יזום, או לביקורת ציות המתמקדת במדיניות ובנהלים, סקירת אבטחת ענן בוחנת את אופן ההגדרה והתפעול של סביבת הענן בפועל ומשווה אותו לדרישות ולשיטות העבודה המקובלות.
בפועל, הסקירה מתמקדת באחת או יותר מפלטפורמות הענן המובילות, כגון AWS, Azure ו Google Cloud Platform (GCP). ההערכה מתבצעת מול קווי בסיס מוכרים, בהם CIS Benchmarks, דרישות הרגולציה החלות על הארגון, כגון NIS2, DORA, ISO 27001 ו SOC 2, וכן מדיניות האבטחה הפנימית של הארגון. בסיום התהליך מתקבל דוח ממצאים הכולל דירוג חומרה לכל ממצא, הסבר על הסיכונים ותוכנית תיקון מתועדפת, המאפשרת לטפל תחילה בחשיפות בעלות ההשפעה הגבוהה ביותר.
מודל האחריות המשותפת: מי אחראי על מה
המושג החשוב ביותר באבטחת ענן הוא מודל האחריות המשותפת. כל ספק ענן מרכזי מפרסם גרסה משלו, וכולן אומרות את אותו דבר בסיסי: ספק הענן אחראי לאבטחה של הענן (תשתית פיזית, Hypervisor, רשת גלובלית); הלקוח אחראי לאבטחה בתוך הענן (קונפיגורציה, נתונים, זהויות, אפליקציות, בקרות גישה).
בפועל, חלוקת האחריות משתנה בהתאם למודל שירות הענן. בכל אחד ממודלי השירות, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) ו־Software as a Service (SaaS), הגבול בין אחריות ספק הענן לאחריות הלקוח מוגדר באופן שונה. הטבלה הבאה מציגה את חלוקת האחריות בין הארגון לבין ספק הענן בשלוש פלטפורמות הענן המובילות, בסביבת IaaS.
| תחום אבטחה | AWS (IaaS) | Azure (IaaS) | GCP (IaaS) |
|---|---|---|---|
| תשתית פיזית | AWS | Microsoft | |
| Hypervisor / בידוד משאבי מחשוב | AWS | Microsoft | |
| תשתית רשת (גלובלית) | AWS | Microsoft | |
| עדכוני מערכת הפעלה | הלקוח | הלקוח | הלקוח |
| בקרות רשת (קונפיגורציית VPC/VNet) | הלקוח | הלקוח | הלקוח |
| ניהול זהויות והרשאות (IAM) | הלקוח | הלקוח | הלקוח |
| הצפנת נתונים במנוחה (At Rest) | משותף (הלקוח מנהל את המפתחות) | משותף (הלקוח מנהל את המפתחות) | משותף (הלקוח מנהל את המפתחות) |
| הצפנת נתונים בתעבורה (In Transit) | הלקוח נדרש להגדיר | הלקוח נדרש להגדיר | הלקוח נדרש להגדיר |
| אבטחת אפליקציות | הלקוח | הלקוח | הלקוח |
| ניטור ורישום אירועי אבטחה | הלקוח (CloudTrail/Config) | הלקוח (Defender/Monitor) | הלקוח (Cloud Audit Logs) |
| תגובה לאירועים | הלקוח | הלקוח | הלקוח |
| סיווג נתונים וממשל | הלקוח | הלקוח | הלקוח |
| קונפיגורציית גיבוי ושחזור | הלקוח | הלקוח | הלקוח |
| מחויבויות ציות ורגולציה | הלקוח | הלקוח | הלקוח |
המשמעות המעשית היא שספק הענן אחראי לאבטחת התשתית, אך כל מה שהארגון מגדיר מעליה נמצא באחריותו. S3 Bucket ציבורי שהוגדר בטעות, IAM Role עם הרשאות עודפות או Storage Account עם גישה ציבורית הם כשלים בצד הלקוח, ולא של ספק הענן. זו הסיבה ש־Gartner מעריכה כי 99% מכשלי אבטחת הענן נובעים מקונפיגורציה וניהול שגוי מצד הארגון.
5 הקונפיגורציות השגויות הנפוצות ביותר בענן
סקירות אבטחת הענן של IPV Security חושפות באופן עקבי את אותן קטגוריות של קונפיגורציה שגויה בסביבות לקוחות. אלה אינם מקרי קצה, הם מופיעים ברוב סביבות הענן שלא עברו סקירת אבטחה מובנית.
1. אחסון חשוף לציבור
S3 buckets (AWS), מיכלי Azure Blob Storage ו-buckets של GCP Cloud Storage שהוגדרו לגישת קריאה ציבורית נותרו אחד הגורמים הנפוצים ביותר לאירועי דלף נתונים. ההגדרה אורכת שניות וקל לבצעה בטעות במהלך פיתוח. סריקות CSPM אוטומטיות מציפות באופן עקבי חשיפת אחסון ציבורי כממצא בעל התדירות הגבוהה ביותר. ארגונים רבים אינם יודעים שיש להם אחסון ציבורי עד שמתרחשת פריצה או שחוקר אבטחה מודיע להם.
2. תפקידי ומדיניות IAM עם הרשאות עודפות
עקרון ההרשאה המינימלית (Least Privilege) מובן היטב בתיאוריה ומופר דרך שגרה בפועל. תפקידי IAM בענן צוברים הרשאות לאורך זמן, מפתחים מוסיפים הרשאות כדי להסיר חסמים, כלים אוטומטיים דורשים גישה רחבה כדי לתפקד, ואיש אינו מסיר הרשאות כשאינן נחוצות עוד. התוצאה היא סביבה שבה חשבונות שירות ותפקידי משתמשים מחזיקים בגישה רחבה בהרבה מהנדרש לתפקודם. חשבון שירות שנפרץ עם הרשאות עודפות הוא נתיב התנועה הרוחבית (Lateral Movement) הנפוץ ביותר בפריצות ענן.
3. רישום לוגים מושבת או חלקי
AWS CloudTrail, Azure Monitor/Defender for Cloud ו-GCP Cloud Audit Logs הם המנגנונים המרכזיים לזיהוי פעילות בלתי מורשית בסביבות ענן. הם גם נמצאים דרך קבע מושבתים באופן חלקי או מלא בסביבות שלא עברו סקירת אבטחה. הפער הנפוץ ביותר: רישום לוגים מופעל בסביבת הייצור אך מושבת בסביבות פיתוח ובדיקות (Staging), שמשמשות תוקפים כנקודות זינוק. ללא רישום לוגים מקיף, פריצות עלולות להימשך חודשים עד לגילוין.
4. גישת רשת בלתי מוגבלת (קונפיגורציה שגויה של Security Group / חוקי Firewall)
Security Groups ב־AWS, Network Security Groups ב־Azure וחוקי VPC Firewall ב־GCP המאפשרים תעבורה נכנסת מ־0.0.0.0/0 בפורטים רגישים, כגון SSH (22), RDP (3389), פורטי בסיסי נתונים (3306, 5432, 1433) וממשקי ניהול, הם חשיפה נפוצה בסביבות ענן ללא ממשל אבטחת רשת מסודר. פתיחת פורט ישירות לאינטרנט חושפת את המערכות שמאחוריו לסריקות אוטומטיות, ניסיונות חדירה ומתקפות Brute Force.
5. נתונים לא מוצפנים ומפתחות הצפנה לא מנוהלים
ספקי הענן מציעים הצפנה במנוחה (At Rest) עבור מרבית שירותי האחסון, אך יישומה דורש הגדרה ובקרה מצד הארגון. הצפנה באמצעות מפתחות בניהול הספק מספקת שכבת הגנה בסיסית, אך עבור מידע רגיש ובסביבות מפוקחות נדרשים לרוב מפתחות בניהול הלקוח (CMK/BYOK) ותהליכי ניהול מפתחות מסודרים. בנוסף, בארגונים רבים קיימים עדיין נתונים המאוחסנים בתצורות ישנות ללא הצפנה מלאה, וכן תקשורת פנימית בין שירותים שאינה מוצפנת מתוך הנחה ש"היא אינה יוצאת מה־VPC".
שישה תחומי בקרה בממשל ענן
סקירת אבטחת ענן מקיפה חייבת לכסות שישה תחומי בקרה בממשל, לא רק קונפיגורציה טכנית. ארגונים שמטפלים רק בקונפיגורציות שגויות טכניות מבלי לטפל בממשל יגלו שקונפיגורציות שגויות חדשות צצות מהר יותר מקצב התיקון.
1. ניהול זהויות והרשאות (IAM) מי יכול לגשת למה, באילו תנאים ועם אילו דרישות אימות. תחום זה כולל אכיפת MFA, תכנון תפקידים והרשאות, ניהול חשבונות שירות, גישה בזמן אמת לפי צורך (Just-in-Time) ותדירות סקירות הרשאות. ממשל IAM הוא תחום הבקרה בעל ההשפעה הגבוהה ביותר באבטחת ענן – רוב מתקפות הענן המוצלחות מערבות הרשאות זהות שנפרצו או הרשאות עודפות.
2. אבטחת רשת וסגמנטציה כיצד מתוכננים גבולות הרשת בענן, איזו תעבורה מותרת בין סגמנטים, וכיצד תעבורה נכנסת ויוצאת נשלטת ומנוטרת. תחום זה כולל תכנון VPC/VNet, חוקי Security Groups, קונפיגורציית Firewall רשתי ומדיניות של Private Endpoint לעומת Public Endpoint לבסיסי נתונים ולממשקי ניהול.
3. הגנת נתונים סיווג, הצפנה, שימור ובקרות גישה החלים על נתונים במנוחה ובתעבורה. תחום זה כולל ניהול מפתחות הצפנה, קונפיגורציית אבטחה של בסיסי נתונים, בקרות למניעת דלף מידע (DLP) ואבטחת נתונים המשותפים עם שירותי צד שלישי או מועברים אליהם.
4. רישום לוגים, ניטור וזיהוי רישום ביקורת מקיף של פעילות ב-Control Plane וב-Data Plane של הענן; אינטגרציה עם SIEM; התרעה על אירועים בסיכון גבוה (הסלמת הרשאות, שינויי גישה ציבורית, אינדיקטורים לפריצת אישורי גישה); וכיסוי בכל הסביבות (ייצור, Staging, פיתוח, Sandbox).
5. ניהול פגיעויות וקונפיגורציה סריקה סדירה של משאבי ענן מול קווי בסיס אבטחתיים (CIS Benchmarks, תקני האבטחה של הספקים); תהליכי תיקון לקונפיגורציות שגויות שזוהו; ניהול עדכונים למערכות הפעלה ולאפליקציות הפרוסות על משאבי מחשוב בענן; ואבטחת Images עבור עומסי עבודה (Workloads) מבוססי קונטיינרים.
6. סיכוני צד שלישי ושרשרת אספקה הערכת אבטחה של אפליקציות SaaS, אינטגרציות צד שלישי ותלויות בשרשרת האספקה שיש להן גישה לסביבות ענן או לנתונים המאוחסנים בענן. תחום זה כולל סקירות גישה של אפליקציות OAuth, ניהול מפתחות API והערכת אבטחת ספקים עבור שירותים שמעבדים או מאחסנים נתוני ארגון בסביבות ענן.
כלי CSPM: מה הם עושים ומה מגבלותיהם
כלי Cloud Security Posture Management (CSPM), בהם AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center ופלטפורמות צד שלישי כגון Wiz, Orca Security ו־Lacework, מאפשרים סריקה אוטומטית ורציפה של סביבות ענן מול קווי בסיס אבטחתיים ומהווים שכבה חשובה במערך ההגנה בענן.
כלי CSPM מצטיינים בזיהוי קונפיגורציות שגויות מוכרות, השוואת הגדרות מול CIS Benchmarks ודרישות אבטחה של ספקי הענן, הפקת דוחות ציות למסגרות כגון ISO 27001, SOC 2 ו־HIPAA, והתרעה על חריגות מקו הבסיס.
עם זאת, CSPM אינו מחליף הערכת אבטחה מקיפה. הכלים אינם בוחנים ממשל, מדיניות ותהליכים, כגון אפקטיביות תהליך סקירת הרשאות, איכות הסכמי אבטחה מול ספקים, מוכנות לתגובה לאירועי ענן או נאותות ניהול מפתחות הצפנה. דשבורד CSPM נקי מצביע על כך שההגדרות הטכניות הניתנות לסריקה עומדות בדרישות, אך אינו מעיד בהכרח על סביבת ענן מאובטחת. סקירת אבטחת ענן מלאה משלבת בין בדיקות טכניות לבין בחינת בקרות הממשל והתהליכים התומכים בהן.
לצורך ניטור רציף בין סקירות פורמליות, לקוחות IPV Security משתמשים ב־CISOteria למעקב אחר מצב בקרות אבטחת הענן, מגמות ממצאי CSPM והתקדמות הטיפול בפערים, באמצעות דשבורד מרכזי המעניק ל־CISO ולהנהלה תמונת מצב עדכנית ללא צורך באיסוף דוחות ידני.
CIS Benchmarks: קו הבסיס שחשוב באמת
ה־Center for Internet Security (CIS) מפרסם קווי בסיס מפורטים לקונפיגורציית אבטחה עבור AWS, Azure ו־GCP, הנחשבים לאחד הסטנדרטים המקובלים ביותר להערכת מצב אבטחת הענן. CIS Benchmarks מגדירים דרישות טכניות ספציפיות בתחומים כגון ניהול זהויות והרשאות, רישום לוגים, בקרות רשת, אחסון, ניטור ומשאבי מחשוב, תוך שילוב הסברים, המלצות לתיקון והערכת השפעה לכל דרישה.
בקרות Level 1 מומלצות לכל הסביבות: הן מטפלות בקונפיגורציות השגויות הקריטיות ביותר עם השפעה תפעולית מינימלית. בקרות Level 2 מיועדות לסביבות עם דרישות אבטחה גבוהות יותר ועשויות לכלול פשרות תפעוליות מסוימות.
סקירת אבטחת ענן מול CIS Benchmarks מעניקה לארגונים קו בסיס הערכה מתועד ובר-הגנה. זהו הייחוס הסטנדרטי לשאלוני ביטוח סייבר, לביקורות ISO 27001 ולהערכות ציות NIS2 בכל הנוגע לקונפיגורציית ענן.
דרישות הענן של NIS2 ו-DORA
הן NIS2 (דירקטיבת רשתות ומערכות מידע 2 של האיחוד האירופי, החלה על ארגונים המפעילים שירותים חיוניים או חשובים באיחוד) והן DORA (Digital Operational Resilience Act, החל על גופים פיננסיים באיחוד האירופי ועל ספקי ICT צד שלישי שלהם) מטילות דרישות ספציפיות החלות ישירות על סביבות ענן.
דרישות הענן של NIS2 כוללות: אמצעי ניהול סיכונים החלים על תלויות בספקי שירותי ענן; הערכת אבטחת שרשרת אספקה לספקי ענן המסווגים כספקי שירותי ICT צד שלישי; חובות דיווח על אירועים הכוללות שירותים המתארחים בענן; ודרישות בדיקות חוסן שחייבות לכסות מערכות ושירותים המתארחים בענן.
דרישות הענן של DORA מרחיקות לכת אף יותר עבור ארגונים פיננסיים: ניהול מתועד של סיכוני ICT צד שלישי שחייב לכלול הוראות חוזיות מול ספק הענן (אסטרטגיות יציאה, זכויות ביקורת, מיקום נתונים, תקני אבטחה); בדיקות חוסן תפעולי הכוללות מערכות המתארחות בענן; הערכת סיכון ריכוזיות כאשר פונקציות קריטיות תלויות בספק ענן יחיד; וסיווג ודיווח חובה על אירועי ICT הקשורים לענן.
עבור ארגונים הכפופים ל-NIS2 או ל-DORA, סקירת אבטחת ענן אינה שיטת עבודה מומלצת אופציונלית אלא היא רכיב מתועד במחויבויות ניהול סיכונים מחייבות. היעדר סקירת אבטחת ענן מובנית, והיעדר תיעוד לתיקון ממצאים שזוהו, הם ממצא ביקורת בפני עצמם.
כך IPV Security מבצעת סקירות אבטחת ענן
סקירות אבטחת הענן של IPV Security מעריכות את סביבות הענן של הלקוח מול CIS Benchmarks (Level 1 ו-Level 2 היכן שרלוונטי), הדרישות הרגולטוריות החלות (NIS2, DORA, ISO 27001, SOC 2) ומסגרת ממשל הענן של IPV Security עצמה, המכסה את ששת תחומי הבקרה שתוארו לעיל.
ההערכה מכסה את שלושת ספקי הענן המרכזיים בסביבות מרובות עננים, וכוללת הן סריקת קונפיגורציה אוטומטית והן סקירה ידנית של מדיניות IAM, ארכיטקטורת רשת, כיסוי רישום לוגים ותהליכי ממשל. הממצאים מדורגים לפי חומרה וממופים למחויבויות מסגרת הציות הרלוונטית, כך שהדוח משמש הן כמפת דרכים לתיקון טכני והן כתיק ראיות רגולטורי.
עבור ארגונים העוברים תוכניות ציות ל-NIS2 או ל-DORA, סקירת הענן משתלבת ישירות בהערכת הציות הרחבה כדי למנוע כפילות מאמצים ולספק תמונת פערים ותיקון אחודה.
CISOteria מספקת מעקב רציף אחר מצב אבטחת הענן בין סקירות פורמליות, סטטוס בקרות ענן, ממצאי CSPM ואבני דרך בתיקון נראים כולם בדשבורד של CISOteria, בעדכון בזמן אמת. כך להנהלה יש תמיד תמונה עדכנית של מצב אבטחת הענן, ולא רק צילום מצב מהסקירה האחרונה.
גלו את שירותי אבטחת הענן של IPV Security ←
מהי הערכת סיכוני סייבר? מדריך 18 התחומים ←
מדריך ציות: ISO 27001, NIS2 ו-DORA ←
אודות המחבר
עידו גנור הוא המייסד והמנכ”ל של IPV Security, חברת ייעוץ ישראלית לאבטחת סייבר ארגונית המשרתת לקוחות בשוק הביניים ולקוחות Enterprise בישראל ובאיחוד האירופי. עם ניסיון של למעלה מ-21 שנה כ-CISO ארגוני וכיועץ אבטחה, עידו הוביל תוכניות אבטחה בארגונים ובהם בנק לאומי, מבקר המדינה ועיריית תל אביב. הוא היוצר של CISOteria Cyber OS™ – פלטפורמת ניהול ה-CISO היחידה בעולם הפונה ללקוח ומוביל את פרקטיקת אבטחת הענן של IPV Security, המספקת סקירות אבטחת ענן ומסגרות ממשל ענן בסביבות AWS, Azure ו-GCP.
מאמרים קשורים
- מהי הערכת סיכוני סייבר? מדריך 18 התחומים ←
- מדריך ציות: ISO 27001, NIS2 ו-DORA ←
- אבטחת ארכיטקטורת AI: המדריך המלא ל-CTOs ב-2026 ←
מוכנים להעריך את מצב אבטחת הענן שלכם? קונפיגורציות שגויות בענן הן הגורם המוביל לאירועי דלף נתונים בארגונים. סקירת אבטחת הענן של IPV Security מעניקה לכם הערכה מלאה ומבוססת קו בסיס של סביבת ה-AWS, Azure או GCP שלכם עם מפת דרכים מתועדפת לתיקון ומעקב רציף באמצעות CISOteria.
שאלות נפוצות
מהי סקירת אבטחת ענן ומה היא מכסה?
סקירת אבטחת ענן היא הערכה מובנית של תשתית הענן והממשל של הארגון מול קו בסיס אבטחתי מוכר. היא מכסה קונפיגורציה טכנית (IAM, בקרות רשת, הגדרות אחסון, הצפנה, רישום לוגים), תהליכי ממשל (ניהול הרשאות, סיכוני ספקים, תגובה לאירועים) ותאימות רגולטורית (NIS2, DORA, ISO 27001, SOC 2, CIS Benchmarks). היא נבדלת ממבדק חדירות, שמנצל פגיעויות באופן אקטיבי, ומביקורת ציות, שמעריכה תיעוד מדיניות. סקירת אבטחת ענן מעניקה לארגונים תמונה עדכנית ומבוססת ראיות של מצב אבטחת הענן בפועל כולל היכן הסיכונים, מה חומרתם ומה לתקן ובאיזה סדר.
מהן הקונפיגורציות השגויות הנפוצות ביותר באבטחת ענן?
חמש הקונפיגורציות השגויות הנפוצות ביותר ש-IPV Security מזהה בסביבות לקוחות הן: אחסון חשוף לציבור (S3 buckets, מיכלי Azure Blob, GCP Cloud Storage הנגישים ללא אימות); תפקידי IAM וחשבונות שירות עם הרשאות עודפות החורגות בהרבה מהדרישות התפעוליות; רישום לוגים מושבת או חלקי (CloudTrail, Azure Monitor, GCP Audit Logs) המונע זיהוי פעילות בלתי מורשית; גישת רשת נכנסת בלתי מוגבלת בפורטים רגישים מ-0.0.0.0/0; ונתונים לא מוצפנים במנוחה או בתעבורה בשל קונפיגורציית הצפנה חסרה או היעדר שימוש במפתחות בניהול הלקוח. ממצאים אלה מופיעים ברוב סביבות הענן שלא עברו סקירת אבטחה מובנית ונתוני Gartner מאשרים ש-99% מפריצות הענן נגרמות מקונפיגורציות שגויות בצד הלקוח, לא מכשלי הספק.
כיצד מודל האחריות המשותפת משפיע על מחויבויות האבטחה שלנו?
מודל האחריות המשותפת מחלק את מחויבויות האבטחה בין ספק הענן לבין הלקוח. ספק הענן אחראי לאבטחת התשתית שעליה מבוססים השירותים, כולל מרכזי נתונים פיזיים, תשתית Hypervisor והרשת הגלובלית. הלקוח אחראי לאבטחה בתוך סביבת הענן, לרבות קונפיגורציות, מדיניות IAM, הגדרות אחסון, מפתחות הצפנה והאפליקציות הפועלות על גבי התשתית.
בפועל, המשמעות היא שרוב החלטות האבטחה בסביבת הענן נמצאות באחריות הארגון, ולכן גם חלק משמעותי מכשלי האבטחה נובע מהגדרות או ניהול לא נכונים מצד הלקוח. הבנת חלוקת האחריות חיונית להגדרת היקף נכון של הערכות אבטחה, הקצאת אחריות לתיקון פערים ובניית תוכנית ממשל ענן אפקטיבית.
באילו כלי CSPM כדאי להשתמש?
בחירת כלי ה־CSPM המתאים תלויה בסביבת הענן, במורכבות התשתית ובתקציב הארגון. בסביבות המבוססות בעיקר על AWS, AWS Security Hub, המשלב ממצאים מ־GuardDuty, Inspector, Macie ו־Config, מספק כיסוי אבטחה מובנה ואינטגרציה טבעית. בסביבות Azure, Microsoft Defender for Cloud מהווה פתרון מתאים לניטור והערכת מצב האבטחה.
בסביבות מרובות עננים, פלטפורמות CSPM של צד שלישי, כגון Wiz, Orca Security ו־Lacework, מספקות תמונת מצב אחודה בין ספקים ויכולות ניתוח סיכונים מתקדמות יותר בהשוואה לכלים מובנים. עם זאת, חשוב לזכור כי כלי CSPM מתמקדים בעיקר בקונפיגורציה טכנית ואינם מחליפים הערכה של ממשל, תהליכים ודרישות ציות. CSPM הוא שכבת ניטור חשובה, אך אינו תחליף לסקירת אבטחת ענן מקיפה.
האם NIS2 דורשת סקירת אבטחת ענן?
NIS2 אינה מכתיבה כלי הערכה ספציפיים, אך היא מחייבת גופים חיוניים וחשובים ליישם “אמצעים טכניים וארגוניים נאותים ומידתיים לניהול הסיכונים לאבטחת רשתות ומערכות מידע”. עבור ארגונים המריצים עומסי עבודה (Workloads) מהותיים בסביבות ענן, הוכחת עמידה במחויבות זו מחייבת ראיות מתועדות להערכת אבטחת ענן ולתיקון ממצאים. NIS2 גם דורשת אמצעי אבטחת שרשרת אספקה המכסים ספקי שירותי ICT צד שלישי, ובכללם ספקי ענן, כך שהערכת סיכוני ספק הענן נמצאת במפורש בהיקף הציות ל-NIS2. ארגונים הכפופים ל-NIS2 שלא ביצעו סקירת אבטחת ענן פועלים עם פער לא מתועד בראיות הציות שלהם.
באיזו תדירות יש לבצע סקירת אבטחת ענן?
עבור רוב הארגונים בשוק הביניים, יש לבצע סקירת אבטחת ענן מקיפה אחת לשנה. סקירות מבוססות-אירוע יש לבצע כאשר: הושלמה פריסת ענן חדשה משמעותית או מיגרציה; אומץ ספק ענן חדש או שירות מרכזי; הארגון עובר הסמכת ציות המחייבת ראיות ענן (ISO 27001, SOC 2); לאחר אירוע אבטחה או כמעט-אירוע שערב תשתית ענן; או לפני אירוע עסקי משמעותי כגון עסקת M&A, הנפקה (IPO) או הערכת אבטחה מצד לקוח Enterprise מרכזי. בין סקירות פורמליות, ניטור CSPM רציף ומעקב CISOteria אחר סטטוס בקרות הענן מספקים את הנראות בזמן אמת הדרושה לזיהוי סחף קונפיגורציה וחשיפות חדשות עם הופעתן.