Cloud IR: לוגים בתשתית Azure
פלטפורמת הענן של Azure כוללת מעל 200 שירותים (Services) ורכיבי תשתית מגוונים, המשתרעים על פני תחומים שונים כגון בינה מלאכותית (AI), קונטיינריזציה, אבטחת מידע, מסדי נתונים, DevOps, ניהול זהויות, אינטגרציה ועוד. כל שירות מורכב מרכיבי משנה, שלכל אחד מהם עשויה להיות מערכת רישום לוגים שונה וזאת בהתאם לאופיו, הפעולות שלו ולדרישת התיעוד.
תיעוד ורישום לוג אינו דבר מובן מאליו, ובמקרים רבים ברירת המחדל בשירות Azure אינה כוללת הפעלת לוגים בצורה מלאה, והמשמעות היא פערי ניטור משמעותיים. בעוד שבחלק מהשירותים תיעוד פעולות מתבצע כברירת מחדל (כגון Azure AD Sign-In Logs, Activity Logs), שירותים רבים אחרים דורשים הגדרה יזומה על מנת להבטיח כיסוי לוגים מקיף.
איך זה משפיע על ניטור ותחקור בענן? כאשר ארגון מתמודד עם תקריות אבטחה, ניתוח לוגים הופך לאחד הכלים הקריטיים לשחזור ציר הזמן של האירוע, זיהוי נקודת הכניסה (Initial Access), הבנת מסלול ההתפשטות (Lateral Movement), וניתוח פעולות שביצע התוקף. אולם, המציאות היא שבמקרים רבים קיים מחסור חמור בתיעוד ולוגים—מצב העלול להקשות על חקירה פורנזית ולפגוע ביכולת התגובה של צוותי אבטחה (SOC/IR).
תקריות בעולם האמיתי, אז מה קורה בשטח? במהלך חקירות סייבר ניתן לזהות מגוון תרחישים בהם תוקפים מנצלים פערי תיעוד לטובתם, ביו היתר:
- מחיקת אובייקטים מסיבית בתוך Azure Subscription, ללא אפשרות תחזוקר עקב היעדר תיעוד מתאים.
- שינויי קונפיגורציה ברכיבי תקשורת קריטיים, דבר המאפשר הקמת מסלולי תקשורת עוקפים (Bypass).
- התבססות (Persistence) בתוך סביבות ענן באמצעות אפליקציות OAuth או הרשאות יתר (Over-privileged Apps), אשר מעניקות לתוקף גישה ממושכת ללא תלות במנגנוני אימות סטנדרטיים (עוקף CAP).
מקרים אלו, בין אם הם מינוריים ובין אם הם בעלי השפעה הרסנית, ממחישים את החשיבות הקריטית של איסוף, ניתוח ושימור לוגים באופן פרואקטיבי.
הלוג בענן הוא הנכס הקריטי ביותר לכל מתחקר.אנליסט. ככל שהלוג יהיה מפורט, עשיר, מופעל ונגיש, כך ניתן יהיה לשחזר אירועים, לזהות תוקפים, לנתח וקטורי תקיפה ולגבש תובנות קריטיות בנוגע לתקרית. לוגים איכותיים הם עמוד התווך של חקירה פורנזית אפקטיבית, ומאפשרים זיהוי דפוסי פעולה חריגים, מעקב אחר פעילות חשודה והבנת המניפולציות שביצע התוקף לאורך שרשרת ההתקפה.
המאמר, ״Cloud IR: לוגים בתשתית Azure״ הינו חלק מסדרת מאמרים שנוגעים וצוללים בתחקור, לוגים וטיפים בספקי הענן השונים (Azure/AWS/GCP/GWS/M365). המאמר הנוכחי נוגע בסוגי הלוגים השונים של Azure.
תיעוד ולוגים בענן של Azure
בשירות הענן של Azure קיימים מגוון רחב של לוגים, המשמשים לניטור, תחקור ותגובה לאירועי אבטחה, אך ניתן לסווגם למספר סוגים. לוגים אלה מהווים נדבך קריטי ביכולת לזהות פעילות חריגה, לאתר וקטורי תקיפה, לנתח צירי חדירה (Attack Paths) ולשחזר את מהלך האירועים (Kill Chain) במקרים של תקריות אבטחה.
בשירות הענן של Azure ישנם מספר רב של סוגי לוגים. עדיין ישנם שני מספר לוגים עיקריים.
Platform Logs: לוג ברמת הפלטפורמה שמספק לוג ותיעוד מפורט של רכיבי Azure, בדיפולט, חלקם נוצרים בצורה אוטומטית בעת יצירת חשבון (Subscription). לוג זה נחלק לשלושה קטגוריות לוגים נוספים:
Resource: לוג מסוג משאב (Resource), או מוכר יותר כ Diagnostic Logs. הלוג מתעד בצורה מפורטת לוגים בשכבת המשאבים בלבד, אלה מספקים תיעוד מפורט ותובנות לגבי פעולות שבוצעו בתוך כל משאב Azure, כגון, גישה למפתחות ברמת AKV, או ביצוע בקשות למסדי נתונים וכן הלאה. התוכן של התיעוד משתנה בהתאם לסרוויס הספציפי ב Azure ולסוג המשאב שאותו מתעד.
הגדרה ומשך זמן שמירת הלוג תלוי בהגדרה שמבצעים ברמת כל משאב ספציפי, בין אם מדובר בדיפולט או בין אם מעבירים את הלוג אל Microsoft Sentinel או כל SIEM אחר. ברוב המקרים משך זמן השמירה תלוי במערכת SIEM שאליה מעבירים את הלוג.
Azure Activity: לוג ברמת חשבון (Subscription) Azure שמספק תיעוד ותובנות לגבי כל פעילות המבוצעת ברמת החשבון, וכן מספק תיעוד על פעולות שנעשות אל מול המשאב (עדיין לא מתעד ברמת Resource). הלוג מכיל פעולות, כגון, הוספה ,מחיקה, שינוי ועדכון של כל אובייקט ואובייקט באותו חשבון. הלוג הוא ברמת חשבון, ולכן, במידה וישנם עשרות או מאות חשבונות, ההתייחסות של תחקור הלוג צריכה להיות בנפרד מול כל חשבון.
במידה ומבצעים איסוף והזרמת לוג אל Microsoft Sentinel או כל SIEM אחר ניתן להגדיר פוליסי מתוך Azure Policy שיעביר את כלל הלוגים למקום אחד ושם יהיה אפשר לבצע תחקור אחיד לכלל החשבונות.
איך נראה לוג של Azure Activity? הלוג זמין מתוך ממשק Azure ובחלק של Activity Log ניתן לברור ידנית ולצלול אל כל פעולה ורקורד שנרשם.
בדיפולט הלוג של Azure Activity נשמר למשך זמן של 90 יום, ואין מגבלה של אחסון במידה ומבצעים המון פעולות ברמת החשבון (Subscription).
טיפ: מומלץ ליצור חוק זיהוי שמזהה שינויים או מחיקות מסיביות ברמת החשבון – אלה נהיו טרנד הרסני של קבוצות תקיפה.
Application Log: לוג שמתעד פעולות ברמת היישומים השונים של Azure ומטרתם לתעד פעולות, כמו, שגיאות, אזהרות ופרטי זמן ריצה אחרים. הלוג אינו מחויב לטובת אבטחה, ולכן, יש להתייחס בהתאם להפעלתו.
Tenant Log: מוכר יותר כ Entra ID והוא מתעד ברמת שכבת הטננט כל לוג אשר קשור לחשבון, לוגים אלה יכולים להיות סוגי כניסות למערכת, ניהול גישה של אובייקטים שונים, שינויים ברמת הגישה ועוד. הלוג של Entra ID הינו לוג מורחב יותר שמאפשר איסוף ותיעוד פעולות נוספות, עדיין, כאשר מדובר בחיבור אל מול Azure מדובר על תיעוד ברמת החשבון ולא מעבר לכך.
כאשר עובדים עם Entra ID לטובת Azure ישנם מספר טבלאות/קטגוריות חשובות:
- Sign-in logs: לוג שמתעד כניסות ופעולות ראשוניות כולל אפליקציות ומשאבים ב Azure.
- Provisiong Logs: מתעדים את הפעולות שבוצעו ברמת Azure provisions ברמת מקור ויעד.
- Audit Log: מתעד כל פעולה ואירוע ברמת משתמש או אדמין, כולל שינויים באפליקציות, קבוצות, משתמשים ועוד.
משך זמן שמירת הלוג היא בהתאם לתנאים הבאים שמתוארים בטבלה מטה:
מידע נוסף לגבי משך זמן שמירת הלוג במאמר הבא: How long does Microsoft Entra ID store the data?
איך נראית הטבלה, הלוג והמידע ב Microsoft Sentinel? בפרט כאשר מבצעים מחיקות מסיביות ברמת החשבון? שאילתת קוסטו משולבת להתראה על מחיקות ברמת החשבון.
סוגי לוגים נוספים ב Azure
בתשתית הענן של Azure קיימים אינספור סוגי לוגים, כאשר כל אחד מהם ממלא תפקיד ייחודי ומשמעותי בהתאם לקונטקסט האבטחתי של הסביבה. הסדר המתואר במאמר אינו מהווה המלצה גורפת לכל סביבה, אלא מדגיש את החשיבות הקריטית שבהפעלת לוגים לצורך ניטור, זיהוי אנומליות ותגובה לאיומים. יתרה מכך, מאחר שהפעלת לוגים ברמת משאב (Resource-Level Logging) היא אחידה יחסית בין משאבי Azure השונים, הדוגמאות המתוארות להלן תקפות באופן רחב לרוב הרכיבים והשירותים בפלטפורמה.
בהיבטי אבטחת מידע וסייבר, הפעלת לוגים בתשתית הענן של Azure ברמת הרכיב (Resource-Level Logging) מהווה נדבך קריטי בזיהוי, תחקור ותגובה לאיומים. בעוד Azure Activity Logs מתעדים שינויים אדמיניסטרטיביים המבוצעים ברמת החשבון (Subscription-Level), לוגים ברמת הרכיב מספקים תיעוד מפורט של פעולות פנימיות, כולל ניסיונות גישה, שינויים בהרשאות, קריאות API, תעבורת נתונים וזיהוי התנהגויות חריגות.
- המשמעות בהיבט התקפי: תוקף שיצליח לקבל Privilege Escalation או להשתלט על שירות ספציפי לא תמיד יופיע ב Azure Activity Logs, אך הלוגים ברמת הרכיב יכולים לחשוף ניסיונות התחברות חריגים, גישה בלתי מורשית למידע, שינויי קונפיגורציה חשודים וניסיונות Persistence.
- המשמעות בהיבט הגנתי: שילוב לוגים אלה במערכת SIEM מאפשר זיהוי תוקפים בשלבים מוקדמים, שחזור ציר זמן מלא של התוקף (Attack Timeline), ניתוח Indicators of Compromise (IoCs) ומיפוי TTPs (Tactics, Techniques & Procedures) לפי מודלים כגון MITRE ATT&CK.
- תחקור ותגובה: בעת תגובה לאירוע (Incident Response), ניתוח הלוגים ברמת הרכיב מאפשר זיהוי מדויק של פעולות התוקף, הערכת היקף הפריצה (Blast Radius), וגיבוש צעדים לשיקום והקשחת המערכת.
לכן, אי הפעלת לוגים ברמת רכיב משאירה "Blind Spot" משמעותיים בתחקור תקריות, ומקשה על זיהוי מתקפות מתוחכמות כגון Living-off-the-Cloud, שימוש באפליקציות OAuth עוינות או תקיפות מבוססות API.
טיפ: חשוב לדעת כי הפעלת לוג בסרוויסים הבאים היא מעבר לתיעוד הלוג ברמת Azure Activity וכולל תיעוד ברמת כל רכיב ורכיב.
Azure DevOps: בדיפולט הלוג אינו מופעל. הלוג מתעד ועוקב אחר כל שינוי בשירות של Azure DevOps, הפעולות נתרחשות בכל פעם שמשתמש או זהות שירות בתוך Organization או פרויקט ניגש, עורך ומבצע כל פעולה שהיא מול רכיב של Azure DevOps. למשל, שינויים בהרשאות, משאבי פיתוח שנמחקו, שינויי במדיניות, שינוי ברמת פיתוח, תיעוד מלא של פעולות מתוך האפשרויות של Azure DevOps Advacned Security ועוד.
בדיפולט, משך זמן שמירת הלוג הוא ל 90 יום. בנוסף לכך, ניתן להזרים את הלוג אל Microsoft Sentinel. איך מגדירים? ניטור Azure DevOps באמצעות Microsoft Sentinel במאמר הבא.
Azure Blob Storage: לוג שמתעד כל גישה ופעולות אשר נעשות ברמת משאב מסוג Object Container (בלוב של Azure). התיעוד אינו מופעל בדיפולט ויש להגדיר את הלוג באופן ידני/פרוגרמטי/פוליסי. מה ניתן להגדיר? ניתן להגדיר את התיעוד לפי הקטגוריות הבאות:
StorageRead
StorageWrite
StorageDelete
מהו משך זמן שמירת הלוג? כברירת מחדל יש להפעיל את הלוג ברמת משאב (Diagnostic Log) אל Microsoft Sentinel.
איך הלוג נראה לאחר שמעובר אל Microsoft Sentinel? למשל, הטבלה StorageBlobLogs יכולה לזהות כניסות לא מורשות, כתיבות מתוך מיקומים לא מורשים, לזהות מצבי רנסום בענן ועוד.
Azure Kubernetes Service: לוג שמתעד פעולות רבות ברמת AKS, החל מתיעוד ברמת ה clusters, דרך POD ועד ניהול גישה. הלוג נחלק למספר מצבים שונים אך החלק החשוב הוא שצריך להגדיר לוג ברמת Diganostic log ולהעביר אל Microsoft Sentinel בכדי לשמור לאורך זמן.
טיפ: תיעוד ולוג ברמת AKS הוא אתגר פסיכי בגלל האופי האירעי של הרכיב וצורת העבודה שלו. האחרון בעייתי מאוד ברמת פורנזיקה של רכיבים מסוימים שעולים/יורדים ברמה יומיומית.
איסוף ותיעוד הלוג ב AKS נעשה בצורה אחרת בכל מימוש ומימוש, פרטים נוספים: Monitor Azure Kubernetes Service.
Azure API Management: מספק לוג עשיר אודות ניהול ופעולות אשר נעשות על APIM כולל בקשות, גישה וניהול מול רכיבי API שונים. התיעוד כולל בין היתר, פעולות ניהול שמבוצעות על ידי אדמינים או משתמשים בעלי הרשאות ניהוליות, כמו יצירה, עדכון ומחיקה של APIs, הגדרת מדיניות ניהול מפתחות גישה ועוד. כמו גם, ניסיונות גישה בלתי מורשים, חסימת כתובות IP, גישה עם טוקן לא חוקי ועוד.
כברירת מחדל, כאשר מגדירים את הלוג ישנו רישום עבור כל ממשקי ה API, עם הגדרות ברירת המחדל. ניתן להתאים את הגדרות הרישום עבור כל ממשקי הAPI, או לעקוף אותם עבור ממשקי API בודדים.
תרחישי תקיפה והחשיבות של לוגים
טרם הפעלת הלוגים ולאחר מכן מומלץ לבצע מיפוי מעמיק של תרחישי תקיפה נפוצים (Common Attack Scenarios) ומקרי קצה (Edge Cases), תוך הבנה כיצד הם משתקפים בתיעוד והלוגים השונים. בסביבת Azure, ניתן לדמות מגוון רחב של מתקפות מתוחכמות במטרה לבחון את גבולות מנגנוני ההגנה, לאמוד את כיסוי הלוגים, ולאתר פערי ניטור פוטנציאליים.
הדמיית תקיפות (Attack Simulation) וניתוח לוגים מאפשרת להבין כיצד נראים אירועים זדוניים מבחינת נתוני הלוגים, כגון: ניסיונות התחברות חריגים, הסלמת הרשאות (Privilege Escalation), גישה בלתי מורשית למשאבים, מחיקת אובייקטים בתשתית Entra ID, עקיפת בקרות אבטחה או שימוש באפליקציות OAuth זדוניות. הבנה זו חיונית לצורך הקשחת בקרות האבטחה, שיפור חוקי זיהוי (Detection Rules) במערכות SIEM ויצירת תגובות אוטומטיות (Automated Response) לתקריות אבטחה.
חשוב לדעת שישנם מצבים בהם הפעלת לוגים בתשתית הענן של Azure מספקת נראות מקיפה על פעילויות מערכת ואבטחה, אך קיימים מצבי קצה בהם פעולות מסוימות אינן נרשמות באופן ברור או מלא. במקרים כאלה, יש לזהות פערי תיעוד ולפצות עליהם באמצעות לוגים משלימים או בקרות נוספות, כגון Audit Logs, Policy Enforcement או שילוב מערכות SIEM מתקדמות.
דוגמה למצב קצה עם תיעוד חסר יכולה להיות מבצ שבו מבוצעות פעולות מחיקה מתוך Azure Cloud Shell, המחיקות עצמן יירשמו ב Azure Activity Logs, אך הקשר הרחב של הפעולה,כגון, כיצד היא בוצעה, האם הופעלה ידנית או באמצעות סקריפט אוטומטי, ומה היה ההקשר התפעולי – לא יתועד במלואו.
במקרה כזה עלול להיות השלכות אבטחה, בכלל שתוקפים יכולים לנצל מצבי קצה כאלו כדי לטשטש עקבות ולמחוק משאבים באופן שקשה לאיתור בדיעבד, ולכן ישנה חשיבות קריטית לזיהוי פערים אלו ולהשלים אותם באמצעות בקרות הגנה משלימות, כגון מדיניות אבטחה (Azure Policy), ניטור מתקדם (Defender for Cloud), ושימוש בלוגים תפעוליים (Diagnostic Logs) עבור שירותים קריטיים.
מצרף מטה מספר תרחישים כלליים שיכולים לפגוש מצבים של סביבות רבות:
גישה בלתי מורשית למשאבים
תוקפים מנסים לעיתים קרובות לקבל גישה בלתי מורשית לחשבונות Azure באמצעות פרטי התחברות של יוזר. במידה ותוקף מצליח להיכנס לחשבון, הוא יבצע אנומגרציה במרחב או פעולות לשינוי משאבים ואובייקטים
כיצד הלוגים יכול לסייע? Azure Activity Logs יחד עם Entra ID logs מתעדים יחד כל גישה או שינוי למשאבים, כולל גישה מכתובת IP, סוג הפעולה, מזהה המשתמש ועוד הרבה. כך ניתן לזהות גישה חשודה, שינוי משאבים ועל סמך אלה ליצור התראות.
תקיפה מבוססת שינויים בהרשאות
במקרים מסוימים, תוקף עם גישה ינסה להסלים הרשאות באמצעות שינוי מדיניות גישה או הוספה לתפקידים גבוהים (priv roles). פעולה זו מספקת לתוקף הרשאות רחבות יותר להמשך פעולתו במרחב הענן של Azure .
כיצד הלוג יכול לסייע? תיעוד של כל שינוי בהגדרות הגישה או בהרשאות של משתמשים מאפשר לזהות ניסיונות להעלות הרשאות. לוגים אלו כוללים פרטים על הפעולות שבוצעו, ומאפשרים חקירת כל שינוי חשוד ברמת Azure Activity וכן לוג ברמת משאב.
מחיקת משאבים חיוניים
תוקף שנכנס לחשבון Azure עלול לנסות למחוק משאבים קריטיים כמו מאגרי נתונים, קונטיינרים וכו. פעולה זו עשויה להיות מכוונת לפגוע בארגון או להסתיר את עקבות התוקף.
כיצד הלוג יכול לסייע? Azure Activity Logs ולוג ברמת משאב מתעדים פעולות מחיקה של משאבים, כולל הגורם שביצע את הפעולה, הזמן המדויק ופרטי המשאב שנמחק. כך ניתן לזהות את מקור התקיפה, להבין את מטרותיה ולהגיב בהתאם.
שינויי תצורת רשת
תוקפים עשויים לנסות לשנות הגדרות אבטחה של רשת, כמו חוקי Network Security Group (NSG) או כל רכיב תקשורת אחר, כדי לאפשר גישה לא מורשית או לחשוף משאבים לרשת הציבורית.
כיצד הלוג יכול לסייע? כל שינוי בהגדרות NSG מתועד בלוגים של Azure Activity יחד עם הלוג ברמת המשאב של NSG, כולל כתובת IP, שם המשתמש ושעת השינוי. ניתוח של תיעוד זה מאפשר לזהות שינויים חשודים בהגדרות הרשת.
לוג של NSG אינו מופעל בדיפולט ולכן יש להפעיל בהתאם בכדי לקבל תיעוד נוסף.
הוספת משתמשים או אפליקציות לצורך גישה עתידית
הוספת משתמשים או רישום אפליקציות לצורך שמירת גישה עתידית (Persistence) מהווה טכניקת תקיפה שמאפשרת לתוקף להבטיח דלת אחורית (Backdoor) עמידה לאחר השגת דריסת רגל בסביבה. במקרים רבים, תוקפים מנצלים מנגנוני הרשאות ב Entra ID כדי לרשום אפליקציות OAuth עוינות או להוסיף משתמשים חדשים עם הרשאות מתקדמות, תוך התחזות לפעילות לגיטימית והימנעות מניטור ישיר.
זיהוי וניתוח לוגים כחלק ממערך ההגנה
לוגים בתשתית הענן של Azure מהווים נדבך קריטי בחשיפת פעילות חשודה. תיעוד לוג מסוג Azure Activity Logs וכן Entra ID Audit Logs מאפשר ניטור שינויים בהרשאות, רישום אפליקציות OAuth, הענקת הרשאות (Overprivileged Grants) ושינויי בעלות (Owner Changes) על אפליקציות קריטיות. שילוב לוגים נוספים כגון Sign-in Logs מסייע בהצלבת נתונים וזיהוי ניסיונות עוקפים של תהליכי אימות (Bypassing Conditional Access Policies) או שימוש בטוקנים ממוחזרים (Token Replay Attack).
כיצד התוקף משיג התמדה ומה ניתן לעשות?
במקרים רבים, התוקף ישתמש בטכניקות כגון Application-Based Persistence כדי להעניק לאפליקציה הרשאות נרחבות לתשתית הארגונית, תוך שימוש בOAuth Abuse, SAML Token Manipulation או Pass-the-Token Attacks. יתרה מכך, שימוש בפרוקסי OAuth עם אישור משתמש (User-Approved Consent Phishing) יכול להוביל למתן הרשאות למשתמשים בלתי מודעים, מה שמספק לתוקף גישה חבויה (Stealth Access) ומעקף למנגנוני זיהוי מסורתיים.
הבנת תרחישי תקיפה אלה מאפשרת לזהות את השלבים המתקדמים בשרשרת התקיפה ולמנוע אחיזה אסטרטגית של בסביבה הארגונית. על ידי סימולציה של מתקפות (Adversary Simulation) והפעלת חוקים מבוססי MITRE ATT&CK ניתן לאתר התנהגויות חריגות בשלבים מוקדמים ולשבש את ההתבססות של התוקף (Persistence Disruption).
מצורף מטה תרחיש תקיפה המדגים כיצד תוקף מנצל הרשאות OAuth, יוצר Backdoor ברמת אפליקציה, ומבסס גישה מתמשכת (Long-Term Persistence) תוך עקיפת בקרות מסורתיות. תוקף שמנסה לשמור לעצמו גישה עתידית עלול להוסיף משתמשים או רישום אפליקציות כ Backdoor מתוך משתמש רגיל או משתמש מערכת.
כיצד הלוג יכול לסייע? לוגים ב Azure Activity וכן Entra ID Audit Logs מספקים תיעוד מפורט של כל שינוי בהרשאות או ברישום אפליקציות, כולל הוספת משתמשים חדשים לקבוצות רגישות, הענקת הרשאות OAuth חריגות לאפליקציות חיצוניות, שינויי בעלות על אפליקציות קריטיות והקצאת תפקידי ניהול (Role Assignments) למשתמשים לא מורשים.
לדוגמה, אם תוקף מצליח להשיג גישה לחשבון עם הרשאות ניהול ברמה האפליקטיבית, הוא עשוי לרשום אפליקציה חדשה, להעניק לה גישה למנגנון Graph API עם הרשאות קריטיות (כגון Directory.ReadWrite.All או Mail.ReadWrite) ולבצע פעולות מתחת לרדאר. Entra ID Audit Logs יאפשר לזהות את רישום האפליקציה, פעולות כגון Consent Grant שניתנו, המשתמש שביצע את הפעולה וכן הלאה.
מאמר נקודתי בניצול הרשאה גבוהה שיכולה למחוק משתמשי קצה ואיך תוקף יכול לנצל זאת.
Entra ID Destruction: How Attackers Leverage User.DeleteRestore.All
מצורף מטה תרחיש תקיפה עם ניצול הרשאות, ביסוס אחיזה והתמדה ברמת אפליקצייה.
לסיכום
לוגים בתשתית הענן של Azure אינם רק עניין טכני ש"מגדירים על הדרך" – הם מהווים רכיב אסטרטגי קריטי בניהול אבטחת מידע, תחקור תקריות וזיהוי פעילות עוינות. מעבר להפעלתם, יש להעמיק בהבנת סכימת הלוגים, מבנה הנתונים שלהם, היתרונות והמגבלות שהם מציבים.
כדי להבטיח נראות מלאה על כלל התרחישים, יש לשאול:
- האם הלוג מספק מידע, מתעד ומספק נתונים בעלי ערך לכל שלבי התקיפה?
- האם קיימים פערי ניטור ותיעוד אירועים שלא נרשמים כראוי?
- כיצד ניתן לשלב לוגים נוספים או בקרות משלימות כדי לצמצם בליינד ספוט ברמת התחקור?
סימולציה של תקיפות (Attack Simulation) חיונית להבנת גבולות הלוגים, ותהליך כזה יכול לאפשר זיהוי מצבי קצה, לאתר נתיבים עוקפי ניטור, ולבחון כיצד ניתן לשפר את כיסוי הלוגים בזמן אמת.
ללא גישה מתודולוגית להפעלת לוגים וניתוחם, הארגון עלול למצוא את עצמו חסר מידע קריטי בדיוק ברגעים בהם הוא הכי זקוק לו – בעיצומה של תקרית אבטחה.
