✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

אבטחת מידע בענן – יתרונות, סיכונים ושירותים

Erez Dasa
|
Aug 31, 2020
title="Google"
alt="blogs"

אבטחת מידע בענן – יתרונות, סיכונים ושירותים


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



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


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


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

עדכונים –


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


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


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


הגנה מפני מתקפות - 


כל ארגון בונה מעגלי הגנה בכדי לשמור על ה-CIA הארגוני (סודיות, אמינות וזמינות), אבל רכישת מוצרי אבט"מ זהו תהליך מורכב שבארגונים גדולים יכול להימשך שבועות רבים, ובמשרדי ממשלה אפילו כמה חודשים. בענן? כמה דק'. רוצים לבדוק FW של Checkpoint? רק תיכנסו ל-Market ותבחרו את המוצר. ניסיתם, בדקתם ואתם לא מרוצים? תיכנסו ל-Market ותבחרו ב-FW של Palo Alto. ניסיתם ואתם לא מרוצים? כנסו ל-Market.... הבנתם את הרעיון. הבחירה של מוצרי אבטחת מידע המתאימים לכם ולארגון זהו תהליך פשוט המאפשר בניית מעגלי הגנה בהתאמה מקסימלית.


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


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


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


כיום ספקי הענן מציעים שירותי גיבוי וזמינות מתקדמים בעזרת Datacenters הפזורים מסביב לגלובוס. רוב ספקי הענן מתחייבים בחוזה (SLA) לזמינות של 99.999% (אחסוך לכם את החישוב - 6 דק' של Downtime בשנה - מקסימום). כמו כן, שירותי גיבוי מתקדמים מאפשרים שחזור מהיר של מידע והתאוששות מאסון בזמן כמעט אפסי.


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


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

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

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


הרשאות גישה -


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


הצפנת מידע - 

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


Vendor lock-in – 


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


שיתוף משאבים – 


נניח שלספק הענן יש שרת פיזי עם נפח דיסק של 1,000TB, ונניח שמשרד ממשלתי בישראל מחליט לצאת לענן וזקוק לנפח דיסק של 100TB. ספק הענן מקצה למשרד 100TB של אחסון מתוך ה-1000TB שקיימים בשרת הנ"ל.


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


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


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

איך נמנעים ממצב כזה? איך מגנים על עצמנו במצב זה?

האם כלקוחות אנחנו בכלל מודעים למצבים כאלה?


ניטור, בקרה ותגובה לאירועי אבט"מ - 

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


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


לאיזו רמה של לוגים אנו זכאים בהיותנו לקוחות ענן? האם כשרכשתי שירות SaaS אני רשאי לצפות בלוגים הקשורים לתשתית? האם אני יכול לנתח אירוע אבטחת מידע מקצה לקצה בלי להיות חשוף לכל הלוגים הקשורים לתקיפה? האם ספק הענן יכול לבצע הפרדה בין הלוגים שלי ללוגים של לקוח אחר שחולק איתי את אותו דיסק פיזי? מי אחראי לכשל שגרם לתוקף לחדור לשרתים שלנו? ספק הענן? אנחנו? האם יש הבדל בנטילת האחריות בהתאם למודל שבחרנו לרכוש מספק הענן? (IAAS, PAAS, SAAS, FAAS, etc.)

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


אז מה עושים? – 


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

בגדול, החלוקה של NIST היא כזו:

• זיהוי - זיהוי ומיפוי נכסים, ניהול סיכונים, ביקורת ותאימות לרגולציות

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

• איתור - תיעוד וניטור אירועים, איסוף לוגים, הגנה פרואקטיבית

• תגובה - ניהול אירועי אבטחת מידע

• התאוששות - שחזורים, גיבויים וכו'


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


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



אבטחת מידע בענן – יתרונות, סיכונים ושירותים


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



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


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


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

עדכונים –


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


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


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


הגנה מפני מתקפות - 


כל ארגון בונה מעגלי הגנה בכדי לשמור על ה-CIA הארגוני (סודיות, אמינות וזמינות), אבל רכישת מוצרי אבט"מ זהו תהליך מורכב שבארגונים גדולים יכול להימשך שבועות רבים, ובמשרדי ממשלה אפילו כמה חודשים. בענן? כמה דק'. רוצים לבדוק FW של Checkpoint? רק תיכנסו ל-Market ותבחרו את המוצר. ניסיתם, בדקתם ואתם לא מרוצים? תיכנסו ל-Market ותבחרו ב-FW של Palo Alto. ניסיתם ואתם לא מרוצים? כנסו ל-Market.... הבנתם את הרעיון. הבחירה של מוצרי אבטחת מידע המתאימים לכם ולארגון זהו תהליך פשוט המאפשר בניית מעגלי הגנה בהתאמה מקסימלית.


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


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


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


כיום ספקי הענן מציעים שירותי גיבוי וזמינות מתקדמים בעזרת Datacenters הפזורים מסביב לגלובוס. רוב ספקי הענן מתחייבים בחוזה (SLA) לזמינות של 99.999% (אחסוך לכם את החישוב - 6 דק' של Downtime בשנה - מקסימום). כמו כן, שירותי גיבוי מתקדמים מאפשרים שחזור מהיר של מידע והתאוששות מאסון בזמן כמעט אפסי.


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


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

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

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


הרשאות גישה -


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


הצפנת מידע - 

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


Vendor lock-in – 


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


שיתוף משאבים – 


נניח שלספק הענן יש שרת פיזי עם נפח דיסק של 1,000TB, ונניח שמשרד ממשלתי בישראל מחליט לצאת לענן וזקוק לנפח דיסק של 100TB. ספק הענן מקצה למשרד 100TB של אחסון מתוך ה-1000TB שקיימים בשרת הנ"ל.


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


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


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

איך נמנעים ממצב כזה? איך מגנים על עצמנו במצב זה?

האם כלקוחות אנחנו בכלל מודעים למצבים כאלה?


ניטור, בקרה ותגובה לאירועי אבט"מ - 

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


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


לאיזו רמה של לוגים אנו זכאים בהיותנו לקוחות ענן? האם כשרכשתי שירות SaaS אני רשאי לצפות בלוגים הקשורים לתשתית? האם אני יכול לנתח אירוע אבטחת מידע מקצה לקצה בלי להיות חשוף לכל הלוגים הקשורים לתקיפה? האם ספק הענן יכול לבצע הפרדה בין הלוגים שלי ללוגים של לקוח אחר שחולק איתי את אותו דיסק פיזי? מי אחראי לכשל שגרם לתוקף לחדור לשרתים שלנו? ספק הענן? אנחנו? האם יש הבדל בנטילת האחריות בהתאם למודל שבחרנו לרכוש מספק הענן? (IAAS, PAAS, SAAS, FAAS, etc.)

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


אז מה עושים? – 


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

בגדול, החלוקה של NIST היא כזו:

• זיהוי - זיהוי ומיפוי נכסים, ניהול סיכונים, ביקורת ותאימות לרגולציות

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

• איתור - תיעוד וניטור אירועים, איסוף לוגים, הגנה פרואקטיבית

• תגובה - ניהול אירועי אבטחת מידע

• התאוששות - שחזורים, גיבויים וכו'


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


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



לפרטים נוספים ויצירת קשר עם נציג אורקל

תודה הודעתך התקבלה

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

Erez Dasa

הירשם לרשימת הדיוור של IsraelClouds

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

מילון מונחיםהשירותים שלנו תנאי שימושהרשמה לניוזלטרמדיניות פרטיות