ניטור אבטחת ענן

העברת נתונים ויישומים לענן מהווה אתגר חדש עבור SOCs ארגוניים, שלא תמיד מוכנים לנטר את התשתית של אנשים אחרים. לפי Netoskope, הארגון הממוצע (ככל הנראה בארה"ב) משתמש ב-1246 שירותי ענן שונים, שהם 22% יותר מאשר לפני שנה. 1246 שירותי ענן!!! 175 מהם מתייחסים לשירותי משאבי אנוש, 170 קשורים לשיווק, 110 בתחום התקשורת ו-76 בתחום הפיננסים וה-CRM. סיסקו משתמשת "רק" ב-700 שירותי ענן חיצוניים. אז אני קצת מבולבל מהמספרים האלה. אבל בכל מקרה, הבעיה היא לא אצלם, אלא בעובדה שהענן מתחיל להיות בשימוש די פעיל על ידי מספר הולך וגדל של חברות שירצו לקבל את אותן יכולות ניטור תשתיות ענן כמו ברשת משלהן. והמגמה הזו הולכת וגוברת - לפי לפי לשכת החשבונות האמריקאית עד 2023, 1200 מרכזי נתונים עומדים להיסגר בארצות הברית (6250 כבר נסגרו). אבל המעבר לענן הוא לא רק "בואו נעביר את השרתים שלנו לספק חיצוני". ארכיטקטורת IT חדשה, תוכנות חדשות, תהליכים חדשים, הגבלות חדשות... כל זה מביא לשינויים משמעותיים בעבודת לא רק של IT, אלא גם באבטחת מידע. ואם הספקים למדו להתמודד איכשהו עם הבטחת האבטחה של הענן עצמו (למרבה המזל יש הרבה המלצות), אז עם ניטור אבטחת מידע בענן, במיוחד בפלטפורמות SaaS, יש קשיים משמעותיים, עליהם נדבר.

נניח שהחברה שלך העבירה חלק מהתשתית שלה לענן... עצור. לא ככה. אם התשתית הועברה, ורק עכשיו אתה חושב איך תפקח עליה, אז כבר הפסדת. אלא אם כן מדובר באמזון, גוגל או מיקרוסופט (ואז עם הזמנות), כנראה שלא תהיה לך הרבה יכולת לנטר את הנתונים והיישומים שלך. זה טוב אם ניתנת לך ההזדמנות לעבוד עם יומנים. לפעמים נתוני אירועי אבטחה יהיו זמינים, אבל לא תהיה לך גישה אליהם. לדוגמה, אופיס 365. אם יש לך את רישיון E1 הזול ביותר, אז אירועי אבטחה אינם זמינים עבורך כלל. אם יש לך רישיון E3, הנתונים שלך מאוחסנים רק ל-90 יום, ורק אם יש לך רישיון E5, משך היומנים זמין למשך שנה (עם זאת, יש לזה גם ניואנסים משלו הקשורים לצורך בנפרד בקש מספר פונקציות לעבודה עם יומנים מהתמיכה של מיקרוסופט). אגב, רישיון ה-E3 חלש הרבה יותר מבחינת פונקציות הניטור מאשר Exchange הארגוני. כדי להגיע לאותה רמה, אתה צריך רישיון E5 או רישיון Advanced Compliance נוסף, אשר עשוי לדרוש כסף נוסף שלא נכלל במודל הפיננסי שלך עבור מעבר לתשתית ענן. וזו רק דוגמה אחת להערכת חסר של נושאים הקשורים לניטור אבטחת מידע בענן. במאמר זה, מבלי להעמיד פנים שהוא שלם, אני רוצה להפנות את תשומת הלב לכמה ניואנסים שיש לקחת בחשבון בבחירת ספק ענן מנקודת מבט אבטחה. ובסוף המאמר תינתן רשימת צ'ק-ליסט שכדאי להשלים לפני שניקח בחשבון שנושא הניטור של אבטחת מידע בענן נפתרה.

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

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

קונספט אבטחת ענן משותף

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

לדוגמה, סיווג הנתונים המתארחים בענן הוא תמיד באחריות הלקוח. ספק ענן או ספק שירות חיצוני יכול לעזור לו רק בכלים שיעזרו לסמן נתונים בענן, לזהות הפרות, למחוק נתונים העוברים על החוק או להסוות אותם בשיטה כזו או אחרת. מצד שני, אבטחה פיזית היא תמיד באחריות ספק הענן, שהוא לא יכול לחלוק עם לקוחות. אבל כל מה שנמצא בין נתונים לתשתית פיזית הוא בדיוק נושא הדיון במאמר זה. לדוגמה, זמינות הענן היא באחריות הספק, והגדרת כללי חומת אש או הפעלת הצפנה באחריות הלקוח. במאמר זה ננסה לבדוק אילו מנגנוני ניטור אבטחת מידע מסופקים כיום על ידי ספקי ענן פופולריים שונים ברוסיה, מהן תכונות השימוש בהם, ומתי כדאי להסתכל על פתרונות שכבת-על חיצוניים (לדוגמה, Cisco E- mail Security) המרחיבים את היכולות של הענן שלך במונחים של אבטחת סייבר. במקרים מסוימים, במיוחד אם אתה פועל לפי אסטרטגיית ריבוי עננים, לא תהיה לך ברירה אלא להשתמש בפתרונות ניטור אבטחת מידע חיצוניים במספר סביבות ענן בו זמנית (לדוגמה, Cisco CloudLock או Cisco Stealthwatch Cloud). ובכן, בחלק מהמקרים תבינו שספק הענן שבחרתם (או הכפתתם עליכם) אינו מציע כלל יכולות ניטור אבטחת מידע. זה לא נעים, אבל גם לא מעט, מכיוון שהוא מאפשר לך להעריך כראוי את רמת הסיכון הכרוכה בעבודה עם הענן הזה.

מחזור החיים של ניטור אבטחת ענן

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

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

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

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

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

שירותי ענן מובנים

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

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

עבור ביטריקס, המצב הרבה יותר טוב. התיעוד מתאר את הפורמטים של יומני האירועים ומעניין, יומן החדירה, המכיל אירועים הקשורים לאיומים פוטנציאליים על פלטפורמת הענן. משם תוכלו לשלוף את ה-IP, שם המשתמש או האורח, מקור האירוע, השעה, סוכן המשתמש, סוג האירוע וכו'. נכון, אתה יכול לעבוד עם האירועים האלה או מלוח הבקרה של הענן עצמו, או להעלות נתונים בפורמט MS Excel. כעת קשה לבצע אוטומציה של עבודה עם יומני Bitrix ותצטרך לבצע חלק מהעבודה באופן ידני (העלאת הדוח וטעינתו ל-SIEM שלך). אבל אם נזכור שעד לאחרונה יחסית הזדמנות כזו לא הייתה קיימת, אז זו התקדמות גדולה. יחד עם זאת, אני רוצה לציין שספקי ענן זרים רבים מציעים פונקציונליות דומה "למתחילים" - או הסתכלו על היומנים בעיניים דרך לוח הבקרה, או העלו את הנתונים לעצמכם (עם זאת, רוב הנתונים מעלים ב. פורמט csv, לא אקסל).

מבלי לשקול את האפשרות ללא יומנים, ספקי ענן בדרך כלל מציעים לך שלוש אפשרויות לניטור אירועי אבטחה - לוחות מחוונים, העלאת נתונים וגישה ל-API. נראה שהראשון פותר לך בעיות רבות, אבל זה לא לגמרי נכון - אם יש לך כמה מגזינים, אתה צריך לעבור בין המסכים המציגים אותם, לאבד את התמונה הכוללת. בנוסף לא סביר שספק הענן יספק לך את היכולת לתאם אירועי אבטחה ובאופן כללי לנתח אותם מנקודת מבט אבטחה (בדרך כלל אתה מתמודד עם נתונים גולמיים, שאתה צריך להבין בעצמך). יש יוצאי דופן ונדבר עליהם עוד. לבסוף, כדאי לשאול אילו אירועים מתועדים על ידי ספק הענן שלכם, באיזה פורמט וכיצד הם מתאימים לתהליך ניטור אבטחת המידע שלכם? לדוגמה, זיהוי ואימות של משתמשים ואורחים. אותה Bitrix מאפשרת לך, בהתבסס על אירועים אלו, לתעד את התאריך והשעה של האירוע, את שם המשתמש או האורח (אם יש לך את מודול "Web Analytics"), את האובייקט שאליו ניגש ואלמנטים אחרים האופייניים לאתר אינטרנט . אבל שירותי אבטחת מידע ארגוניים עשויים להזדקק למידע לגבי האם המשתמש ניגש לענן ממכשיר מהימן (לדוגמה, ברשת ארגונית משימה זו מיושמת על ידי Cisco ISE). מה לגבי משימה כה פשוטה כמו פונקציית ה-Geo-IP, שתעזור לקבוע אם נגנב חשבון משתמש בשירות ענן? וגם אם ספק הענן מספק לכם אותו, זה לא מספיק. אותו Cisco CloudLock לא רק מנתח מיקום גיאוגרפי, אלא משתמש לשם כך בלמידת מכונה ומנתח נתונים היסטוריים עבור כל משתמש ומנטר חריגות שונות בניסיונות זיהוי ואימות. רק ל-MS Azure יש פונקציונליות דומה (אם יש לך את המנוי המתאים).

ישנו קושי נוסף – מכיוון שעבור ספקי ענן רבים ניטור אבטחת מידע הוא נושא חדש שהם רק מתחילים לעסוק בו, הם כל הזמן משנים משהו בפתרונות שלהם. היום יש להם גרסה אחת של ה-API, מחר גרסה אחרת, מחרתיים שלישית. גם לזה צריך להיות מוכנים. כך גם בפונקציונליות, שעלולה להשתנות, אותה יש לקחת בחשבון במערכת ניטור אבטחת המידע שלכם. לדוגמה, לאמזון היו בתחילה שירותי ניטור אירועי ענן נפרדים - AWS CloudTrail ו-AWS CloudWatch. אז הופיע שירות נפרד לניטור אירועי אבטחת מידע - AWS GuardDuty. לאחר זמן מה השיקה אמזון מערכת ניהול חדשה, Amazon Security Hub, הכוללת ניתוח נתונים שהתקבלו מ-GuardDuty, Amazon Inspector, Amazon Macie ועוד כמה. דוגמה נוספת היא כלי שילוב היומן Azure עם SIEM - AzLog. הוא היה בשימוש פעיל על ידי ספקי SIEM רבים, עד שבשנת 2018 הודיעה מיקרוסופט על הפסקת הפיתוח והתמיכה שלה, מה שעומד בפני לקוחות רבים שהשתמשו בכלי זה עם בעיה (נדבר על איך היא נפתרה מאוחר יותר).

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

דוגמה: ניטור אבטחת מידע ב-IaaS על בסיס AWS

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

הדבר הראשון שיש לומר הוא שאמזון אינה מבצר בלתי חדיר. תקריות שונות קורות באופן קבוע ללקוחותיו. לדוגמה, השמות, הכתובות, תאריכי הלידה ומספרי הטלפון של 198 מיליון מצביעים נגנבו מ-Deep Root Analytics. חברת נייס סיסטמס הישראלית גנבה 14 מיליון רשומות של מנויי Verizon. עם זאת, היכולות המובנות של AWS מאפשרות לך לזהות מגוון רחב של אירועים. לדוגמה:

• השפעה על תשתית (DDoS)
• פגיעה בצומת (הזרקת פקודה)
• פגיעה בחשבון וגישה לא מורשית
• תצורה ונקודות תורפה שגויות
• ממשקים וממשקי API לא מאובטחים.

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

כדי לזהות תקריות, אתה יכול להשתמש במגוון רחב של שירותי ניטור שונים שפותחו על ידי אמזון (אם כי לעתים קרובות משלימים אלה על ידי כלים חיצוניים כגון osquery). לכן, ב-AWS, כל פעולות המשתמש מנוטרות, ללא קשר לאופן ביצוען - דרך מסוף הניהול, שורת הפקודה, SDK או שירותי AWS אחרים. כל הרשומות של הפעילות של כל חשבון AWS (כולל שם משתמש, פעולה, שירות, פרמטרי פעילות ותוצאה) והשימוש ב-API זמינים דרך AWS CloudTrail. אתה יכול לצפות באירועים אלו (כגון כניסות למסוף AWS IAM) ממסוף CloudTrail, לנתח אותם באמצעות Amazon Athena, או "מיקור חוץ" שלהם לפתרונות חיצוניים כגון Splunk, AlienVault וכו'. יומני AWS CloudTrail עצמם ממוקמים בדלי AWS S3 שלך.

שני שירותי AWS אחרים מספקים עוד מספר יכולות ניטור חשובות. ראשית, Amazon CloudWatch הוא שירות ניטור למשאבים ואפליקציות AWS שבין היתר מאפשר לך לזהות חריגות שונות בענן שלך. כל שירותי ה-AWS המובנים, כגון Amazon Elastic Compute Cloud (שרתים), Amazon Relational Database Service (מסדי נתונים), Amazon Elastic MapReduce (ניתוח נתונים), ועוד 30 שירותי אמזון, משתמשים ב- Amazon CloudWatch כדי לאחסן את היומנים שלהם. מפתחים יכולים להשתמש ב-API הפתוח של Amazon CloudWatch כדי להוסיף פונקציונליות של ניטור יומנים ליישומים ושירותים מותאמים אישית, מה שמאפשר להם להרחיב את היקף ניתוח האירועים בהקשר אבטחה.

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

לסיכום, שלושת שירותי ה-AWS הללו - AWS CloudTrail, Amazon CloudWatch ו-VPC Flow Logs - מספקים יחד תובנה חזקה למדי לגבי השימוש בחשבונך, התנהגות המשתמש, ניהול התשתית, פעילות האפליקציות והשירות ופעילות הרשת שלך. לדוגמה, ניתן להשתמש בהם כדי לזהות את החריגות הבאות:

• ניסיונות לסרוק את האתר, חיפוש דלתות אחוריות, חיפוש נקודות תורפה באמצעות פרצי "404 שגיאות".
• התקפות הזרקה (לדוגמה, הזרקת SQL) באמצעות התפרצויות של "500 שגיאות".
• כלי התקפה ידועים הם sqlmap, nikto, w3af, nmap וכו'. באמצעות ניתוח של השדה User Agent.

Amazon Web Services פיתחה גם שירותים נוספים למטרות אבטחת סייבר המאפשרים לך לפתור בעיות רבות אחרות. לדוגמה, ל-AWS יש שירות מובנה לביקורת מדיניות ותצורות - AWS Config. שירות זה מספק ביקורת רציפה של משאבי ה-AWS שלך והתצורות שלהם. ניקח דוגמה פשוטה: נניח שאתה רוצה לוודא שסיסמאות משתמש מושבתות בכל השרתים שלך ושהגישה אפשרית רק על סמך אישורים. AWS Config מקלה לבדוק זאת עבור כל השרתים שלך. ישנן מדיניות נוספת שניתן להחיל על שרתי הענן שלך: "אף שרת לא יכול להשתמש בפורט 22", "רק מנהלים יכולים לשנות חוקי חומת אש" או "רק המשתמש Ivashko יכול ליצור חשבונות משתמש חדשים, והוא יכול לעשות זאת רק בימי שלישי. " בקיץ 2016, שירות AWS Config הורחב כדי להפוך את זיהוי הפרות של מדיניות מפותחת לאוטומטית. כללי התצורה של AWS הם בעצם בקשות תצורה מתמשכות עבור שירותי אמזון שבהם אתה משתמש, שיוצרות אירועים אם המדיניות המתאימה מופרת. לדוגמה, במקום להריץ מעת לעת שאילתות AWS Config כדי לוודא שכל הדיסקים בשרת וירטואלי מוצפנים, ניתן להשתמש בכללי AWS Config כדי לבדוק באופן רציף דיסקים של שרת כדי לוודא שתנאי זה מתקיים. והכי חשוב, בהקשר של פרסום זה, כל הפרה מייצרת אירועים שניתן לנתח על ידי שירות אבטחת המידע שלך.

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

• זיהוי חדירה - AWS GuardDuty
• בקרת דליפות מידע - AWS Macie
• EDR (למרות שהוא מדבר על נקודות קצה בענן בצורה קצת מוזרה) - AWS Cloudwatch + פתרונות קוד פתוח Osquery או GRR
• ניתוח Netflow - AWS Cloudwatch + AWS VPC Flow
• ניתוח DNS - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• ניהול חשבונות - AWS IAM
• SSO - AWS SSO
• ניתוח אבטחה - AWS Inspector
• ניהול תצורה - AWS Config
• WAF - AWS WAF.

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

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

• CloudTrail - שימוש ב-API ופעולות משתמש
• יועץ מהימן - בדיקת אבטחה מול שיטות עבודה מומלצות
• Config - מלאי ותצורה של חשבונות והגדרות שירות
• VPC Flow Logs - חיבורים לממשקים וירטואליים
• IAM - שירות זיהוי ואימות
• ELB Access Logs - Load Balancer
• מפקח - פרצות אפליקציות
• S3 - אחסון קבצים
• CloudWatch - פעילות יישומים
• SNS הוא שירות התראות.

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

דוגמה: ניטור אבטחת מידע ב-IaaS מבוסס על Azure

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

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

ל-AWS יש ייחוד הקשור לעובדה שכאשר אתה מנטר את המשאבים הווירטואליים שלך, אם הם ממוקמים באזורים שונים, אז יש לך קשיים בשילוב כל האירועים והניתוח המאוחד שלהם, כדי למנוע מהם אתה צריך לנקוט טריקים שונים, כגון צור קוד משלך עבור AWS Lambda שיעביר אירועים בין אזורים. ל-Azure אין את הבעיה הזו - מנגנון יומן הפעילות שלו עוקב אחר כל הפעילות בכל הארגון ללא הגבלות. אותו הדבר חל על AWS Security Hub, אשר פותחה לאחרונה על ידי אמזון כדי לאחד פונקציות אבטחה רבות בתוך מרכז אבטחה אחד, אך רק באזור שלה, אשר, עם זאת, אינו רלוונטי עבור רוסיה. ל-Azure יש מרכז אבטחה משלה, שאינו מחויב להגבלות אזוריות, המספק גישה לכל תכונות האבטחה של פלטפורמת הענן. יתרה מכך, עבור צוותים מקומיים שונים הוא יכול לספק מערך יכולות הגנה משלו, כולל אירועי אבטחה המנוהלים על ידם. AWS Security Hub עדיין בדרך להפוך לדומה ל-Azure Security Center. אבל כדאי להוסיף זבוב - אתה יכול לסחוט מ-Azure הרבה ממה שתואר בעבר ב-AWS, אבל זה נעשה בצורה נוחה רק עבור Azure AD, Azure Monitor ו-Azure Security Center. כל שאר מנגנוני האבטחה של Azure, כולל ניתוח אירועי אבטחה, עדיין לא מנוהלים בצורה הנוחה ביותר. הבעיה נפתרת בחלקה על ידי ה-API, שמחלחל לכל שירותי Microsoft Azure, אבל זה ידרוש ממך מאמץ נוסף כדי לשלב את הענן שלך עם ה-SOC שלך ונוכחות של מומחים מוסמכים (למעשה, כמו בכל SIEM אחר שעובד עם ענן ממשקי API). כמה SIEMs, עליהם יידונו בהמשך, כבר תומכים ב-Azure ויכולים להפוך את משימת הניטור שלה לאוטומטית, אבל יש לה גם קשיים משלה - לא כולם יכולים לאסוף את כל היומנים שיש ל-Azure.

איסוף וניטור אירועים ב-Azure ניתן באמצעות שירות Azure Monitor, שהוא הכלי העיקרי לאיסוף, אחסון וניתוח נתונים בענן של מיקרוסופט ומשאביו - מאגרי Git, קונטיינרים, מכונות וירטואליות, אפליקציות וכו'. כל הנתונים שנאספים על ידי Azure Monitor מחולקים לשתי קטגוריות - מדדים, הנאספים בזמן אמת ומתארים מדדי ביצועים מרכזיים של ענן Azure, ולוגים, המכילים נתונים המאורגנים ברשומות המאפיינות היבטים מסוימים של הפעילות של משאבי ושירותי Azure. בנוסף, באמצעות ה-Data Collector API, שירות Azure Monitor יכול לאסוף נתונים מכל מקור REST כדי לבנות תרחישי ניטור משלו.

להלן מספר מקורות אירועי אבטחה ש-Azure מציעה לך ושניתן לגשת אליהם דרך Azure Portal, CLI, PowerShell או REST API (וחלקם רק דרך Azure Monitor/Insight API):

• יומני פעילות - יומן זה עונה על השאלות הקלאסיות של "מי", "מה" ו"מתי" לגבי כל פעולת כתיבה (PUT, POST, DELETE) במשאבי ענן. אירועים הקשורים לגישת קריאה (GET) אינם כלולים ביומן זה, כמו מספר אחרים.
• יומני אבחון - מכיל נתונים על פעולות עם משאב מסוים הכלול במנוי שלך.
• דיווח Azure AD - מכיל גם פעילות משתמשים וגם פעילות מערכת הקשורה לניהול קבוצות ומשתמשים.
• Windows Event Log ו-Linux Syslog - מכיל אירועים ממכונות וירטואליות המתארחות בענן.
• מדדים - מכיל טלמטריה לגבי הביצועים והמצב הבריאותי של שירותי הענן והמשאבים שלך. נמדד כל דקה ונשמר. תוך 30 ימים.
• יומני זרימה של קבוצת אבטחת רשת - מכיל נתונים על אירועי אבטחת רשת שנאספו באמצעות שירות Network Watcher וניטור משאבים ברמת הרשת.
• Storage Logs - מכיל אירועים הקשורים לגישה למתקני אחסון.

לניטור, אתה יכול להשתמש ברכיבי SIEM חיצוניים או ב-Azure Monitor המובנה והרחבות שלו. נדבר על מערכות ניהול אירועי אבטחת מידע מאוחר יותר, אבל לעת עתה נראה מה Azure עצמה מציעה לנו לניתוח נתונים בהקשר של אבטחה. המסך הראשי לכל מה שקשור לאבטחה ב-Azure Monitor הוא לוח המחוונים של Log Analytics Security and Audit (הגרסה החינמית תומכת בכמות מוגבלת של אחסון אירועים למשך שבוע אחד בלבד). לוח המחוונים הזה מחולק ל-5 אזורים עיקריים הממחישים סטטיסטיקות סיכום של מה שקורה בסביבת הענן שבה אתה משתמש:

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

הרחבות של Azure Monitor כוללות את Azure Key Vault (הגנה על מפתחות קריפטוגרפיים בענן), Malware Assessment (ניתוח הגנה מפני קוד זדוני במכונות וירטואליות), Azure Application Gateway Analytics (ניתוח בין היתר יומני חומת אש בענן) וכו'. . כלים אלו, המועשרים בכללים מסוימים לעיבוד אירועים, מאפשרים לדמיין היבטים שונים של פעילות שירותי הענן, לרבות אבטחה, ולזהות חריגות מסוימות מהפעולה. אבל, כפי שקורה לעתים קרובות, כל פונקציונליות נוספת דורשת מנוי בתשלום תואם, שידרוש ממך השקעות פיננסיות תואמות, אותן עליך לתכנן מראש.

ל-Azure יש מספר יכולות מובנות של ניטור איומים המשולבות ב-Azure AD, Azure Monitor ו-Azure Security Center. ביניהם, למשל, זיהוי אינטראקציה של מכונות וירטואליות עם כתובות IP זדוניות ידועות (עקב נוכחות אינטגרציה עם שירותי מודיעין איומים מבית מיקרוסופט), איתור תוכנות זדוניות בתשתית הענן על ידי קבלת אזעקות ממכונות וירטואליות המתארחות בענן, סיסמא ניחוש התקפות ” על מכונות וירטואליות, נקודות תורפה בתצורת מערכת זיהוי המשתמש, כניסה למערכת מאנונימיזרים או צמתים נגועים, דליפות חשבונות, כניסה למערכת ממקומות חריגים וכו'. Azure היום היא אחת מספקיות הענן הבודדות שמציעות לך יכולות מובנות של Threat Intelligence להעשרת אירועי אבטחת מידע שנאספו.

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

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

אם אתה צריך לא רק את היכולת לעבוד עם יומנים, אלא למרכז אבטחה מקיף עבור פלטפורמת הענן Azure שלך, כולל ניהול מדיניות אבטחת מידע, אז אתה יכול לדבר על הצורך לעבוד עם Azure Security Center, שרוב הפונקציות השימושיות שלו זמינים תמורת קצת כסף, למשל, זיהוי איומים, ניטור מחוץ ל-Azure, הערכת תאימות וכו'. (בגרסה החינמית, יש לך רק גישה להערכת אבטחה והמלצות לביטול בעיות שזוהו). זה מאחד את כל בעיות האבטחה במקום אחד. למעשה, אנחנו יכולים לדבר על רמה גבוהה יותר של אבטחת מידע מאשר Azure Monitor מספק לך, שכן במקרה זה הנתונים שנאספים ברחבי מפעל הענן שלך מועשרים באמצעות מקורות רבים, כגון Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) ו-Microsoft Security Response Center (MSRC), שעליהם משולבים אלגוריתמים שונים של למידת מכונה וניתוח התנהגותי מתוחכמים, אשר בסופו של דבר אמורים לשפר את היעילות של זיהוי איומים ותגובה אליהם .

ל-Azure יש גם SIEM משלה - הוא הופיע בתחילת 2019. זהו Azure Sentinel, המסתמך על נתונים מ-Azure Monitor ויכול גם להשתלב איתו. פתרונות אבטחה חיצוניים (למשל, NGFW או WAF), שהרשימה שלהם הולכת וגדלה כל הזמן. בנוסף, באמצעות השילוב של ה-API של Microsoft Graph Security, יש לך את היכולת לחבר עדכוני Threat Intelligence משלך ל-Sentinel, מה שמעשיר את היכולות לניתוח תקריות בענן ה-Azure שלך. ניתן לטעון ש-Azure Sentinel הוא ה-SIEM ה"יליד" הראשון שהופיע מספקי ענן (אותם Splunk או ELK, שניתן לארח בענן, למשל, AWS, עדיין לא מפותחים על ידי ספקי שירותי ענן מסורתיים). Azure Sentinel and Security Center יכול להיקרא SOC עבור ענן Azure ויכול להיות מוגבל אליהם (עם הסתייגויות מסוימות) אם כבר לא הייתה לך תשתית כלשהי ואתה העברת את כל משאבי המחשוב שלך לענן וזה יהיה Azure של Microsoft Cloud.

אך מכיוון שהיכולות המובנות של Azure (גם אם יש לך מנוי ל-Sentinel) לרוב אינן מספיקות למטרות ניטור אבטחת מידע ושילוב תהליך זה עם מקורות אחרים של אירועי אבטחה (הן בענן והן פנימיים), יש צריך לייצא את הנתונים שנאספו למערכות חיצוניות, שאליהן עשויות לכלול SIEM. זה נעשה הן באמצעות ה-API והן באמצעות הרחבות מיוחדות, שזמינות כעת רשמית רק עבור ה-SIEMs הבאים - Splunk (תוסף Azure Monitor for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ו-ELK. עד לאחרונה היו יותר SIEMs כאלה, אך החל מ-1 ביוני 2019, מיקרוסופט הפסיקה לתמוך בכלי Azure Log Integration Tool (AzLog), אשר עם שחר קיומה של Azure ובהיעדר סטנדרטיזציה רגילה של עבודה עם יומנים (Azure מוניטור אפילו לא היה קיים עדיין) עשה את זה קל לשלב SIEM חיצוני עם הענן של מיקרוסופט. כעת המצב השתנה ומיקרוסופט ממליצה על פלטפורמת Azure Event Hub ככלי האינטגרציה העיקרי עבור SIEMs אחרים. רבים כבר הטמיעו אינטגרציה כזו, אך היזהר - ייתכן שהם לא יקבלו את כל יומני ה-Azure, אלא רק חלק מהם (חפש בתיעוד עבור ה-SIEM שלך).

לסיום טיול קצר לתוך Azure, ברצוני לתת המלצה כללית על שירות ענן זה - לפני שאתה אומר משהו על פונקציות ניטור אבטחת המידע ב-Azure, עליך להגדיר אותן בקפידה רבה ולבדוק שהן פועלות כפי שכתוב בתיעוד. כפי שהיועצים אמרו לך Microsoft (וייתכן שיש להם דעות שונות על הפונקציונליות של פונקציות Azure). אם יש לך את המשאבים הכספיים, תוכל לסחוט הרבה מידע שימושי מ-Azure מבחינת ניטור אבטחת מידע. אם המשאבים שלך מוגבלים, אז, כמו במקרה של AWS, תצטרך להסתמך רק על הכוח שלך ועל הנתונים הגולמיים ש-Azure Monitor מספק לך. וזכרו שפונקציות ניטור רבות עולות כסף ועדיף להכיר את מדיניות התמחור מראש. לדוגמה, בחינם אתה יכול לאחסן 31 ימים של נתונים עד למקסימום של 5 GB ללקוח - חריגה מהערכים האלה תדרוש ממך להוציא כסף נוסף (כ-$2+ עבור אחסון כל GB נוסף מהלקוח ו-$0,1 עבור אחסון של 1 GB בכל חודש נוסף). עבודה עם טלמטריה ומדדים של יישומים עשויה גם לדרוש כספים נוספים, כמו גם עבודה עם התראות והתראות (מגבלה מסוימת זמינה בחינם, שאולי לא תספיק לצרכים שלך).

דוגמה: ניטור אבטחת מידע ב-IaaS מבוסס על Google Cloud Platform

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

הכלי העיקרי לרישום אירועים ב-GCP הוא Stackdriver Logging (בדומה ל-Azure Monitor), המאפשר לך לאסוף אירועים על פני כל תשתית הענן שלך (כמו גם מ-AWS). מנקודת מבט של אבטחה ב-GCP, לכל ארגון, פרויקט או תיקיה יש ארבעה יומנים:

• פעילות ניהול - מכילה את כל האירועים הקשורים לגישה מנהלתית, למשל יצירת מכונה וירטואלית, שינוי זכויות גישה וכו'. יומן זה נכתב תמיד, ללא קשר לרצונך, ומאחסן את הנתונים שלו למשך 400 יום.
• גישה לנתונים - מכילה את כל האירועים הקשורים לעבודה עם נתונים על ידי משתמשי ענן (יצירה, שינוי, קריאה וכו'). כברירת מחדל, יומן זה אינו נכתב, מכיוון שהנפח שלו מתנפח מהר מאוד. מסיבה זו, חיי המדף שלו הם 30 יום בלבד. בנוסף, לא הכל כתוב במגזין הזה. לדוגמה, אירועים הקשורים למשאבים הנגישים לציבור לכל המשתמשים או שנגישים ללא כניסה ל-GCP אינם נכתבים אליו.
• אירוע מערכת - מכיל אירועי מערכת שאינם קשורים למשתמשים, או פעולות של מנהל מערכת שמשנה את תצורת משאבי הענן. זה תמיד כתוב ונשמר למשך 400 יום.
• Access Transparency היא דוגמה ייחודית ליומן שמתעד את כל הפעולות של עובדי Google (אך עדיין לא עבור כל שירותי GCP) שניגשים לתשתית שלך כחלק מתפקידם. יומן זה נשמר למשך 400 ימים ואינו זמין לכל לקוח GCP, אלא רק אם מתקיימים מספר תנאים (תמיכה ברמת זהב או פלטינה, או נוכחות של 4 תפקידים מסוג מסוים כחלק מהתמיכה הארגונית). פונקציה דומה זמינה גם, למשל, ב-Office 365 - Lockbox.

דוגמה ביומן: שקיפות גישה

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

גישה ליומנים אלו אפשרית בכמה דרכים (בדומה לזו שצוינו בעבר ב-Azure וב-AWS) - דרך ממשק Log Viewer, דרך ה-API, דרך Google Cloud SDK, או דרך דף הפעילות של הפרויקט שלך שעבורו אתה מתעניינים באירועים. באותו אופן, ניתן לייצא אותם לפתרונות חיצוניים לניתוח נוסף. זה האחרון נעשה על ידי ייצוא יומנים לאחסון BigQuery או Cloud Pub/Sub.

בנוסף ל-Stackdriver Logging, פלטפורמת GCP מציעה גם פונקציונליות של Stackdriver Monitoring, המאפשרת לך לנטר מדדי מפתח (ביצועים, MTBF, בריאות כללית וכו') של שירותי ענן ואפליקציות. נתונים מעובדים ומוצגים יכולים להקל על מציאת בעיות בתשתית הענן שלך, כולל בהקשר של אבטחה. אבל יש לציין שפונקציונליות זו לא תהיה עשירה במיוחד בהקשר של אבטחת מידע, שכן כיום ל-GCP אין אנלוגי של אותו AWS GuardDuty ואינו יכול לזהות רעים בין כל האירועים הרשומים (גוגל פיתחה את זיהוי איומי האירועים, אבל זה עדיין בפיתוח בבטא, וזה מוקדם מדי לדבר על התועלת שלו). ניטור Stackdriver יכול לשמש כמערכת לאיתור חריגות, שלאחר מכן ייבדקו כדי למצוא את הגורמים להתרחשותן. אבל בהתחשב במחסור בכוח אדם מוסמך בתחום אבטחת המידע GCP בשוק, משימה זו נראית כרגע קשה.

כדאי גם לתת רשימה של כמה מודולי אבטחת מידע שניתן להשתמש בהם בתוך ענן ה-GCP שלך, ואשר דומים למה שמציעה AWS:

• Cloud Security Command Center הוא אנלוגי של AWS Security Hub ו-Azure Security Center.
• Cloud DLP - גילוי ועריכה אוטומטיים (למשל מיסוך) של נתונים המתארחים בענן תוך שימוש ביותר מ-90 מדיניות סיווג מוגדרת מראש.
• Cloud Scanner הוא סורק לפגיעויות ידועות (XSS, Flash Injection, ספריות ללא תיקונים וכו') ב-App Engine, Compute Engine ו-Google Kubernetes.
• Cloud IAM - שלוט בגישה לכל משאבי GCP.
• Cloud Identity - נהל חשבונות משתמשים, מכשירים ואפליקציות של GCP ממסוף יחיד.
• Cloud HSM - הגנה על מפתחות קריפטוגרפיים.
• שירות ניהול מפתחות בענן - ניהול מפתחות קריפטוגרפיים ב-GCP.
• בקרת שירות VPC - צור היקף מאובטח סביב משאבי ה-GCP שלך כדי להגן עליהם מפני דליפות.
• מפתח אבטחה Titan - הגנה מפני דיוג.

רבים מהמודולים הללו יוצרים אירועי אבטחה שניתן לשלוח לאחסון BigQuery לצורך ניתוח או ייצוא למערכות אחרות, כולל SIEM. כפי שהוזכר לעיל, GCP היא פלטפורמה שמתפתחת באופן פעיל וגוגל מפתחת כעת מספר מודולי אבטחת מידע חדשים עבור הפלטפורמה שלה. ביניהם ניתן למנות את Event Threat Detection (זמין כעת בגרסת בטא), הסורקת יומני Stackdriver בחיפוש אחר עקבות של פעילות לא מורשית (בדומה ל-GuardDuty ב-AWS), או Policy Intelligence (זמין באלפא), שיאפשר לך לפתח מדיניות חכמה עבור גישה למשאבי GCP.

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

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

דוגמה: ניטור אבטחת מידע באמצעות Stealthwatch Cloud

AWS מספקת פלטפורמת מחשוב גמישה, אך הגמישות הזו מקלה על חברות לבצע טעויות שמובילות לבעיות אבטחה. ומודל אבטחת המידע המשותף רק תורם לכך. הפעלת תוכנות בענן עם פרצות לא ידועות (אפשר להילחם בהן, למשל, על ידי AWS Inspector או GCP Cloud Scanner), סיסמאות חלשות, תצורות שגויות, גורמים פנימיים וכו'. וכל זה בא לידי ביטוי בהתנהגות משאבי הענן, אותם ניתן לפקח על ידי Cisco Stealthwatch Cloud, שהיא מערכת ניטור וגילוי התקפות אבטחת מידע. עננים ציבוריים ופרטיים.

אחת התכונות המרכזיות של Cisco Stealthwatch Cloud היא היכולת לדגמן ישויות. בעזרתו תוכלו ליצור מודל תוכנה (כלומר סימולציה כמעט בזמן אמת) של כל אחד ממשאבי הענן שלכם (לא משנה אם זה AWS, Azure, GCP או משהו אחר). אלה יכולים לכלול שרתים ומשתמשים, כמו גם סוגי משאבים ספציפיים לסביבת הענן שלך, כגון קבוצות אבטחה וקבוצות קנה מידה אוטומטי. מודלים אלה משתמשים בזרמי נתונים מובנים המסופקים על ידי שירותי ענן כקלט. לדוגמה, עבור AWS אלה יהיו VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda ו-AWS IAM. מודלים של ישות מגלה אוטומטית את התפקיד וההתנהגות של כל אחד מהמשאבים שלך (אתה יכול לדבר על פרופיל כל פעילות ענן). תפקידים אלו כוללים מכשיר נייד של אנדרואיד או אפל, שרת Citrix PVS, שרת RDP, שער דואר, לקוח VoIP, שרת מסוף, בקר תחום וכו'. לאחר מכן הוא עוקב באופן רציף אחר התנהגותם כדי לקבוע מתי מתרחשת התנהגות מסוכנת או מסכנת בטיחות. אתה יכול לזהות ניחוש סיסמאות, התקפות DDoS, דליפות נתונים, גישה מרחוק בלתי חוקית, פעילות קוד זדונית, סריקת פגיעות ואיומים אחרים. לדוגמה, כך נראה זיהוי ניסיון גישה מרחוק ממדינה לא טיפוסית עבור הארגון שלך (דרום קוריאה) לאשכול Kubernetes באמצעות SSH:

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

לבסוף, כך נראים יותר מדי ניסיונות SSH כושלים מסין ואינדונזיה ממכשיר מרוחק חיצוני:

לחלופין, נניח שמופע השרת ב-VPC, לפי מדיניות, לעולם לא יהיה יעד כניסה מרחוק. הבה נניח עוד שהמחשב הזה חווה כניסה מרחוק עקב שינוי שגוי במדיניות חוקי חומת האש. תכונת מודל הישות תזהה ותדווח על פעילות זו ("גישה מרחוק יוצאת דופן") כמעט בזמן אמת ותצביע על הקריאה הספציפית של AWS CloudTrail, Azure Monitor או GCP Stackdriver Logging API (כולל שם משתמש, תאריך ושעה, בין שאר הפרטים מה שגרם לשינוי בכלל ה-ITU. ואז ניתן לשלוח את המידע הזה ל-SIEM לניתוח.

יכולות דומות מיושמות עבור כל סביבת ענן הנתמכת על ידי Cisco Stealthwatch Cloud:

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

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

ניתן לשלוח אירוע אבטחת מידע שזוהה בצורה של כרטיס תואם ל-Slack, Cisco Spark, מערכת ניהול האירועים PagerDuty, וכן לשלוח ל-SIEMs שונים, כולל Splunk או ELK. לסיכום, אנו יכולים לומר שאם החברה שלך משתמשת באסטרטגיית ריבוי עננים ואינה מוגבלת לאף ספק ענן אחד, יכולות ניטור אבטחת המידע שתוארו לעיל, אז השימוש ב-Cisco Stealthwatch Cloud הוא אפשרות טובה לקבל מערך ניטור מאוחד יכולות עבור שחקני הענן המובילים - אמזון, מיקרוסופט וגוגל. הדבר המעניין ביותר הוא שאם משווים את המחירים של Stealthwatch Cloud עם רישיונות מתקדמים לניטור אבטחת מידע ב-AWS, Azure או GCP, אולי יתברר שפתרון סיסקו יהיה זול אפילו יותר מהיכולות המובנות של אמזון, מיקרוסופט ופתרונות גוגל. זה פרדוקסלי, אבל זה נכון. וככל שתשתמש ביותר עננים ויכולותיהם, כך יתרונו של פתרון מאוחד יהיה ברור יותר.

בנוסף, Stealthwatch Cloud יכול לנטר עננים פרטיים הפרוסים בארגון שלך, למשל, על בסיס קונטיינרים של Kubernetes או על ידי ניטור זרימות Netflow או תעבורת רשת המתקבלת באמצעות שיקוף בציוד רשת (אפילו בייצור מקומי), נתוני AD או שרתי DNS וכן הלאה. כל הנתונים הללו יועשרו במידע של Threat Intelligence שנאסף על ידי Cisco Talos, הקבוצה הלא-ממשלתית הגדולה בעולם של חוקרי איומי אבטחת סייבר.

זה מאפשר לך ליישם מערכת ניטור מאוחדת עבור עננים ציבוריים והיברידיים כאחד שהחברה שלך עשויה להשתמש בהם. לאחר מכן ניתן לנתח את המידע שנאסף באמצעות היכולות המובנות של Stealthwatch Cloud או לשלוח ל-SIEM שלך (Splunk, ELK, SumoLogic ועוד כמה נתמכים כברירת מחדל).

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

מקור: www.habr.com