כיצד לבקר בענן

מטרת המאמר

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

מה זה מִחשוב ענן

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

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

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

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

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

• תשתית כשירות (IaaS) Infrastructure as a Service – היכולת לספק תשתיות מחשוב, משאבי עיבוד, אחסון ותקשורת שבאמצעותם יכולים הלקוחות לעשות שימוש במערכות ובתוכנות. מודל זה מאפשר ללקוחות לעסוק בתחום מומחיותם, לצרוך שירותי מחשוב ללא צורך בקניית שרתים, ציוד תקשורת, מערכות הפעלה ורכיבים תשתיתיים, ולקבל סיוע של אנשי מערכת ואנשי תוכנה. יותר מזה, מודל התשלום הוא על פי השימוש בפועל בלבד – לא השתמשת, לא שילמת.
• תוכנה כשירות Software as a Service (SaaS) – מודל שבו התוכנה והמידע הרלוונטי מתארחים במקום מרכזי (בדרך כלל בתשתית הענן). הגישה לשירותים אלה היא בדרך כלל באמצעות ממשק פשוט על מחשב הקצה כגון דפדפן.
• פלטפורמה כשירות Platform as a Service (PaaS) – מודל זה הוא שכבה נוספת מעל ה- IaaS והוא מספק שירותים נוספים המאפשרים לזרז את תהליך יישומן של אפליקציות ללא צורך לקנות ולנהל את החומרה והתוכנה הנדרשת לשם כך. שירותים אלה יכולים לכלול, בין היתר, סביבות פיתוח, טווחה (Middleware) ופונקציות כגון בסיסי נתונים, הפצת מסרים וניהול תורים.

ללא קשר למודל השירות שתואר לעיל IaaS), PaaS או SaaS), קיימים ארבעה מודלים לפריסה של שירותי ענן:

• ענן ציבורי (Public Cloud) – תשתית הענן זמינה לכלל הציבור והיא בבעלות ארגון המוכר את שירותי הענן ללקוחות.
• ענן פרטי (Private Cloud) – תשתית הענן מופעלת עבור לקוח אחד בלבד. התשתית יכולה להיות מופעלת על ידי הארגון עצמו או על ידי ספק חיצוני, ויכולה להיות ממוקמת בחצרות הארגון או מחוץ להן.
• ענן קהילתי (Community Cloud) – תשתית הענן משותפת בין מספר ארגונים ותומכת קהילה מסוימת ומוגדרת בעלת עניין משותף. התשתית יכולה להיות מופעלת על ידי הקהילה או מי מחבריה או על ידי ספק חיצוני. היא יכולה להיות ממוקמת בחצרות אחד הארגונים בקהילה או מחוץ להן.
• ענן היברידי (Hybrid Cloud) – תשתית הענן משלבת שניים או שלושה מודלים (ענן ציבורי, פרטי או קהילתי) הפועלים באורח עצמאי אך משתפים בינם סטנדרטים וטכנולוגיות המאפשרים שיתוף והעברת מידע ואפליקציות (למשל, לצורך איזון עומסים).

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

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

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

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

ניהול סיכונים בענן

מחשוב ענן מציע לא מעט יתרונות למשתמשים בו, לרבות:

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

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

להלן מספר דוגמאות לסיכונים הנובעים ממעבר מערכות מידע לענן:

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

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

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

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

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

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

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

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

דרישות רגולטוריות בשירותי הענן

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

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

בעולם מתגבשים מספר סטנדרטים ספציפיים לנושא אבטחת מידע בענן. ביניהם 27017 ו-27018 של ISO, ותקן STAR של ארגון ה-Cloud Security Alliance. שלושת התקנים הללו מהווים הרחבה לתקן אבטחת המידע הבינלאומי 27001 ISO וההנחיות המעשיות ליישומו – תקן 27002 ISO.

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

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

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

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

היבטים טכנולוגיים של מחשוב הענן והסיכונים העיקריים בסביבה זו

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

• ממשק הניהול – מאפשר ללקוחות לנהל את התצורה של הסביבה שלהם בענן. בדרך כלל קיים פורטל ניהול וכן ממשק תכנות (API). ממשק זה הוא אחת הנקודות הרגישות ביותר בסביבת הענן ויש להקפיד להגן עליה כראוי. רוב הספקים מאפשרים להגדיר הזדהות חזקה לממשק הניהול, ולהגדיר תפקידים ואחריות ממוקדים המאפשרים לבצע רק את מה נדרש.
• וירטואליזציה – אחת מאבני היסוד של מודל התשתית כשירות (IaaS) ובסיס לשירותים בשכבות הגבוהות יותר. וירטואליזציה מנתקת את הצימוד בין החומרה הפיזית לבין מערכת ההפעלה או תשתיות תוכנה בסיסיות אחרות, ומאפשרת להריץ בו-בזמן, על אותה חומרה פיזית, מספר מערכות בלי תלות ביניהן. וירטואליזציה מאפשרת ניצול טוב יותר של משאבים, שימוש בשטח רצפה קטן יותר, צמצום ההוצאות הנדרשות לחומרה, יכולת טובה יותר לשלוט על משאבי מחשוב רבים ושיפור היעילות התפעולית. עם זאת, הווירטואליזציה מביאה עמה סיכונים חדשים. למשל, מכונות וירטואליות יכולות לתקשר ביניהן דרך המחשב המארח ובכך נוצרת "נקודה עיוורת" – כלומר, נתיב תקשורת שאיננו מבוקר ויכול לשמש להתקפת התשתית והמידע האצור בה.
• רכיבי עיבוד (Compute Engine) – מחשוב הענן מאפשר להקים "מחשבים" מגדלים שונים שעליהם מותקנים רכיבי תוכנה, כולל מערכות הפעלה ואפליקציות. יש לזכור כי ברגע שנבחר רכיב העיבוד, עדכוני תכנה ופגיעויות הם באחריות הלקוח ולא באחריות הספק.
• רכיבי אחסון (Storage) – קיימים סוגים שונים של רכיבי אחסון הנבדלים ביניהם בגודל, בביצועים, בזמן שליפת הנתונים ובצורת הארגון שלהם. רכיבים אלה כוללים מנגנוני הרשאות גישה. יש להקפיד ליישם מנגנונים אלה כראוי.
• רכיבי תקשורת (Communication) – התקשורת בענן מדמה עבודה בעולם המחשוב הקלאסי. ניתן לבנות אזורים מוגנים ברמות שונות ברשת, להגביל את הגישה הפנימית/חיצונית אליהם על ידי סט של חוקים, וכדומה.
• מיקום המידע – אחד מהיתרונות של מחשוב הענן הוא שניתן לשמור את המידע ולגבות אותו באזורים גאוגרפיים שונים ובכך להגדיל את זמינותו. עם זאת, חשוב לשים לב לדרישות רגולטוריות המגבילות את מיקומו הגיאוגרפי של המידע.
• ניטור ובקרה – חשוב לזהות אירועים המתרחשים הן ברמת התשתיות של הספק והן ברמת הסביבה של הלקוח. לרוב הספקים יש יכולת לספק שירות זה.

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

ביקורת פנימית של סביבת ושירותי הענן

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

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

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

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

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

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

• ניתוח איומים – בביצוע הביקורת חשוב לנתח את תסריטי האיום הרלוונטיים לסביבת העבודה בענן, ולוודא שהארגון הציב בקרות בהתאם וכי קיימת פונקציה שמתפקידה לבחון באופן שוטף את יעילותן של הבקרות.
• מדיניות ובקרות – על הארגון להתאים את המדיניות ואת נוהלי העבודה שלו לסביבת העבודה בענן. במסגרת הביקורת ניתן לוודא כי הארגון הגדיר מי בוחר מערכות בענן, על פי אילו מדדים, מי רשאי לאשר, וכיצד.
• תפקידים ואחריות – במסגרת הביקורת חשוב לוודא כי הוגדרה האחריות לניהול סיכוני הענן, הן מבחינה חוזית והן מבחינת יישום פרקטי. כחלק מביקורת פנימית יש לבחון מעורבות ואחריות של ההנהלה בתהליכים.
• הגדרת דרישות למערכת – במסגרת הביקורת יש לוודא כי בעת פיתוח ו/או רכישה של מערכת הוגדרו דרישות אבטחת המידע הרלוונטיות, לרבות התייחסות לנושאים כגון שמירה על פרטיות המשתמשים, שמירה על חיסיון הנתונים, שמירה על שלמות המידע, שמירה על אמינות המידע, שמירה על זמינות המערכת, שמירה על שלמות תהליכים עסקיים, ממשקים עם מערכות חיצוניות, ועוד.
• יישום המערכת – כחלק מתהליכי העבודה יש להקפיד על כתיבת קוד בהתאם לכללי פיתוח מאובטח. כמו כן, יש לבצע סקר קוד (Code Review) על מנת לוודא את יישום דרישות אבטחת המידע. ניתן לעשות זאת תוך שימוש בכלים אוטומטיים כגון Static Code Analyzer.

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

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

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

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

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

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

סיכום

מסמך זה כולל מספר סוגיות שמומלץ להתייחס אליהן במהלך ביקורת פנימית בסביבת ענן. נושאים אלה כוללים היבטים ארגוניים (תפקידים ואחריות), תהליך ניהול הסיכונים, דרישות רגולטוריות, בקרות טכנולוגיות, בקרות תהליכיות ופיתוח מאובטח. מִפרט מלא של בקרות אבטחת מידע ניתן למצוא במסגרות לניהול סיכוני ענן כגון STAR של ה-Cloud Security Alliance, התקנים 27017 ISO  ו-27018 ISO ואחרים.

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

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

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

[1] NIST SP 800-145

[2] Enterprise Risk Management for Cloud Computing, COSO, June 2012

אודות הכותב/ת

אופיר זילביגר

CISSP ,CRISC

אודות הכותב/ת

גלעד ירון

CCSK