מדריך

מתן גישת JIT (Just-in-Time) לתפקידי Azure AD בעלי הרשאות גבוהות, הדורשת אישור והצדקה.

→הגדר את Microsoft Entra Privileged Identity Management (PIM) עבור התפקיד. הגדר "דרוש אישור להפעלה", ציין מאשרים, אפשר "דרושה הצדקה בהפעלה", וקבע משך הפעלה מרבי.

למה: PIM הוא שירות Azure המקורי להעלאת תפקידים ב-JIT. עצם הפיכת משתמש לזכאי אינה מספיקה; הגדרות המדיניות אוכפות את זרימת העבודה של אישור והצדקה.

מקור↗

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

→צור שתי מדיניות גישה מותנית (CA). מדיניות 1 מכוונת ל"כל המשתמשים" למעט קבוצת ה-Help Desk, ודורשת MFA ומכשיר תואם. מדיניות 2 מכוונת רק לקבוצת ה-Help Desk, ודורשת רק MFA.

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

מקור↗

הגב באופן אוטומטי לסיכוני זהות שזוהו: חסימת כניסות בסיכון גבוה ואכיפת איפוס סיסמאות למשתמשים בסיכון גבוה.

→הגדר שתי מדיניות Microsoft Entra ID Protection. הגדר את "מדיניות סיכון כניסה" לחסימת גישה ברמת סיכון גבוהה. הגדר את "מדיניות סיכון משתמש" לדרוש שינוי סיסמה ברמת סיכון גבוהה.

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

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

→ב-Microsoft Entra Connect, אפשר את תכונת "Password writeback". ב-Azure AD, אפשר והגדר איפוס סיסמה בשירות עצמי (SSPR) עבור המשתמשים המיועדים.

למה: SSPR מספק את ממשק המשתמש בצד הענן לאיפוס סיסמה, בעוד ש-Password Writeback הוא הרכיב ב-Entra Connect שמסנכרן את גיבוב הסיסמה החדש בחזרה ל-AD המקומי.

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

→צור סקירת גישה (Access Review) ב-Microsoft Entra ID Governance. כוון למשתמשי אורח בכל הקבוצות, הגדר לוח זמנים חוזר (למשל, רבעוני), ואפשר "החל אוטומטית תוצאות למשאב". לחלופין, סקור משתמשים לא פעילים.

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

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

→השתמש ב-Microsoft Entra Entitlement Management. צור ארגון מחובר (Connected Organization) עבור השותף. צור חבילת גישה (Access Package) המכילה את המשאבים. הגדר מדיניות עבור החבילה המאפשרת למשתמשים מהארגון המחובר לבקש אותה, עם תפוגה של 90 יום.

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

יישום בעל אבטחה גבוהה דורש ממשתמשים להתאמת עם שיטה העמידה בפני התקפות פישינג ו-Man-in-the-Middle.

→אכוף שיטות אימות כמו מפתחות אבטחה FIDO2 או Windows Hello for Business. שיטות אלו משתמשות בקריפטוגרפיה של מפתח ציבורי וקשורות למכשיר, ובכך מונעות גניבת פרטי כניסה.

למה: שיטות כמו SMS, שיחות קוליות או הודעות Push פשוטות ניתנות לפישינג. FIDO2 ו-WHfB משתמשים באתגרים קריפטוגרפיים הקשורים למקור הבקשה, מה שהופך אותם לעמידים בפני פישינג.

שירות רקע הפועל על מכונה וירטואלית צריך לקרוא את כל פרופילי המשתמשים מ-Microsoft Graph ללא כל אינטראקציה של משתמש.

→רשום את היישום ב-Microsoft Entra ID. תחת הרשאות API, הענק לו הרשאות "יישום" (ולא "מואצלות") של Microsoft Graph עבור `User.Read.All`. מנהל מערכת חייב להעניק הסכמת מנהל.

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

אפשר ל-pod באשכול AKS לגשת בצורה מאובטחת ל-Azure Key Vault ללא שימוש בפרטי כניסה מאוחסנים כמו סודות לקוח או אישורים.

→השתמש ב-Azure AD Workload Identity. צור זהות מנוהלת שהוקצתה למשתמש, קבע אישור זהות מאוחד בין חשבון שירות K8s לזהות המנוהלת, והענק לזהות המנוהלת גישה ל-Key Vault.

למה: Workload Identity משתמש בפרדרינג OIDC כדי להחליף אסימון Kubernetes באסימון Azure AD, ובכך מבטל לחלוטין את הצורך לאחסן, לנהל או לסובב סודות באשכול.

מקור↗

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

→הגדר את חומת האש של Key Vault לאפשר גישה מ-"Private endpoint ורשתות נבחרות". אפשר רישום אבחון לסביבת עבודה של Log Analytics. אפשר גם Soft Delete וגם Purge Protection.

למה: Soft Delete מאפשר שחזור ממחיקה בשוגג, אך Purge Protection מונע גם ממשתמש מורשה למחוק לצמיתות את הכספת או תוכנה במהלך תקופת השמירה. שילוב זה קריטי להגנה על מפתחות TDE.

שירות Azure App Service צריך לאמת את עצמו מול Azure SQL Database כדי לאחזר נתונים, מבלי לאחסן סיסמאות של מחרוזות חיבור בתצורה.

→אפשר זהות מנוהלת שהוקצתה למערכת (system-assigned managed identity) בשירות App Service. ב-Azure SQL, צור משתמש מכונס (contained user) הממופה לשם הזהות המנוהלת של שירות App Service והענק לו את תפקידי מסד הנתונים הדרושים (לדוגמה, db_datareader).

למה: Managed Identity מספק זהות למשאב Azure עצמו ב-Azure AD. Azure מטפלת ביצירה וסיבוב של פרטי כניסה באופן אוטומטי, ומבטלת סודות מאוחסנים, שהיא שיטת אבטחה מומלצת חשובה.

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

→צור משאב Disk Encryption Set. הגדר אותו להשתמש במפתח מנוהל לקוח (CMK) מ-Azure Key Vault שלך. הקצה את ה-Disk Encryption Set לדיסקים המנוהלים של המכונה הווירטואלית.

למה: זוהי הצפנת צד שרת (SSE) עם CMK, המצפינה נתונים בתשתית האחסון. היא פשוטה יותר מ-Azure Disk Encryption (ADE), המשתמשת ב-BitLocker/dm-crypt להצפנת נתונים בתוך מערכת ההפעלה האורחת ובדרך כלל משמשת עבור דיסקי מערכת הפעלה ונתונים יחד.

וודא שתמונות קונטיינר המאוחסנות ב-Azure Container Registry (ACR) נסרקות לאיתור חולשות לפני פריסתן.

→אפשר את Microsoft Defender for Containers. זה יסרוק אוטומטית תמונות ב-ACR כאשר הן נדחפות, כאשר הן נמשכות, ועל בסיס מתמשך לאיתור חולשות שזה עתה התגלו.

למה: פרקטיקת אבטחה "Shift-Left" זו מזהה חולשות מוקדם בצינור ה-CI/CD. Defender for Containers מספק יכולת סריקה זו באופן מקורי בתוך סביבת Azure.

זהה וקבל התראות על התקפות SQL injection פוטנציאליות ותבניות גישה חריגות על Azure SQL Database.

→אפשר את Microsoft Defender for SQL על שרת ה-SQL הלוגי. זה מספק הגנה מתקדמת מפני איומים והערכת חולשות.

למה: Defender for SQL היא תוכנית הגנת עומסי העבודה הייעודית המשתמשת בניתוח התנהגותי ולמידת מכונה כדי לזהות איומים כמו SQL injection, התקפות כוח גס וגישה חריגה לנתונים, שאינם גלויים לכלי רשת.

הגבל חשבון אחסון ל-VNet ספציפי, אך עדיין אפשר לשירותי Microsoft מהימנים כמו Azure Backup לגשת אליו.

→בהגדרות הרשת של חשבון האחסון, בחר "זמין מרשתות וירטואליות וכתובות IP נבחרות". הוסף את ה-VNet/תת-הרשת הנדרשים. לאחר מכן, סמן את התיבה "אפשר לשירותי Microsoft מהימנים לגשת לחשבון אחסון זה".

למה: חריגת השירותים המהימנים יוצרת נתיב מאובטח לשירותי Microsoft ספציפיים כדי לעקוף את כללי חומת האש של ה-VNet. בלעדיה, שירותים הפועלים בשם המשתמש (כמו Backup או Portal) ייחסמו.

הגן על עמודות נתונים רגישות ספציפיות (לדוגמה, מספרי כרטיסי אשראי) במסד נתונים של Azure SQL, גם ממנהלי מסדי נתונים (DBAs) בעלי הרשאות גבוהות.

→השתמש ב-Always Encrypted. מנהל ההתקן של יישום הלקוח מצפין את הנתונים באופן שקוף לפני שליחתם למסד הנתונים, ומפתחות ההצפנה אינם נחשפים לעולם למנוע מסד הנתונים.

למה: הצפנת נתונים שקופה (TDE) מצפינה את כל מסד הנתונים במנוחה (על הדיסק), אך DBA עם גישה עדיין יכול לראות את הנתונים. Always Encrypted מספקת הצפנה בצד הלקוח, ומפרידה בין אלו המנהלים את הנתונים (DBAs) לבין אלו שיכולים לראות אותם.

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

→פרוס מכונה וירטואלית חסויה של Azure. מכונות וירטואליות אלו משתמשות בסביבות ביצוע מהימנות (TEEs) מבוססות חומרה כמו AMD SEV-SNP כדי ליצור מרחב זיכרון מבודד ומוצפן.

למה: הצפנת מכונה וירטואלית סטנדרטית (כמו ADE או SSE) מגנה על נתונים במנוחה. Confidential Computing היא הטכנולוגיה היחידה המגנה על נתונים *בזמן שימוש* בזיכרון, ומספקת את הרמה הגבוהה ביותר של פרטיות ובידוד נתונים בענן.

שירות App Service צריך להשתמש בסוד מ-Key Vault כהגדרת יישום, מבלי לשנות את קוד היישום כדי להשתמש ב-Key Vault SDK.

→אפשר זהות מנוהלת בשירות App Service והענק לה הרשאות "קריאה" (Get) על סודות ב-Key Vault. בתצורת ה-App Service, צור הגדרת יישום עם הערך מעוצב כהפניית Key Vault: `@Microsoft.KeyVault(SecretUri=...)`.

למה: תכונה זו מאפשרת לפלטפורמת App Service לפתור את ערך הסוד בזמן ריצה באמצעות הזהות המנוהלת. קוד היישום פשוט קורא משתנה סביבה סטנדרטי, ומפשט את האינטראקציה עם Key Vault.

אחסן נתונים הקשורים לתאימות ב-Azure Blob Storage במצב WORM (Write-Once, Read-Many) לתקופת שמירה של 7 שנים.

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

למה: תכונה זו תוכננה במיוחד כדי לעמוד בדרישות תאימות רגולטוריות (לדוגמה, SEC 17a-4). נעילת המדיניות היא השלב הקריטי שהופך אותה לבלתי ניתנת לשינוי באמת.

ביישום מרובה דיירים המשתמש במסד נתונים יחיד של Azure SQL, וודא שמשתמשים מדייר אחד יכולים לראות רק נתונים השייכים לדייר שלהם.

→הטמע אבטחה ברמת שורה (RLS). צור מדיניות אבטחה עם פונקציית Predicate המסננת שורות בהתבסס על מזהה הדייר של המשתמש, המאוחסן בהקשר הסשן או בטבלת בדיקת משתמשים.

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

הגן על מכונות וירטואליות מדור 2 מפני Boot Kits ו-Rootkits על ידי הבטחת שלמות שרשרת האתחול כולה מ-UEFI ועד לקרנל מערכת ההפעלה.

→הקצה את המכונה הווירטואלית עם Trusted Launch מופעל. זה מפעיל את Secure Boot, המאמת את החתימה של כל רכיבי האתחול, ומודול פלטפורמה מהימן וירטואלי (vTPM) לאתחול מדוד ואישור.

למה: Trusted Launch מטפל בתוכנות זדוניות מתוחכמות וברמה נמוכה שיכולות לחתור תחת בקרות אבטחה מסורתיות ברמת מערכת ההפעלה. הוא יוצר שורש אמון מבוסס חומרה עבור המכונה הווירטואלית.

בידוד תעבורה בין שכבות יישומים (Web, App, Data) המתארחות בתתי רשת נפרדים.

→צור קבוצת אבטחת רשת (NSG) ייעודית עבור כל תת-רשת. בכל NSG, צור כללים נכנסים המאפשרים תעבורה רק מטווח ה-IP המקורי של השכבה הקודמת ביציאה הנדרשת. (לדוגמה, NSG של שכבת היישום מאפשר TCP/8080 מתת-רשת שכבת ה-Web).

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

בטופולוגיית Hub-Spoke, אכוף שכל התעבורה בין רשתות Spoke VNet תיבדק על ידי NVA או Azure Firewall ב-Hub.

→בכל תת-רשת Spoke, צור נתיב מוגדר משתמש (UDR) עבור מרחבי הכתובות של שאר ה-Spokes עם סוג ה-next hop מוגדר ל-"VirtualAppliance" וכתובת ה-IP של ה-NVA/Firewall. אפשר העברת IP (IP Forwarding) בכרטיס הרשת של ה-NVA.

למה: כברירת מחדל, VNet peering מאפשר ל-Spokes לתקשר ישירות. UDRs עוקפים התנהגות ניתוב ברירת מחדל זו, ומאלצים תעבורה לנקודת הבדיקה המרכזית.

ספק לשירות PaaS (לדוגמה, Azure SQL, Storage) כתובת IP פרטית בתוך ה-VNet שלך, ובכך וודא שתעבורה לעולם לא עוברת דרך האינטרנט הציבורי.

→צור Private Endpoint עבור שירות ה-PaaS ב-VNet שלך. באופן קריטי, בהגדרות הרשת של שירות ה-PaaS, השבת גישת רשת ציבורית כדי לחסום את הנקודה הציבורית.

למה: Private Endpoint מביא את השירות *לתוך* ה-VNet שלך עם IP פרטי. Service Endpoint פשוט מייעל את המסלול דרך עמוד השדרה של Azure ל-IP ציבורי. השבתת גישה ציבורית נדרשת כדי לאכוף תקשורת פרטית בלבד.

אפשר תעבורה יוצאת ממכונות וירטואליות (VMs) לקבוצה דינמית של נקודות קצה של שירותי Microsoft, כמו Windows Update, מבלי לתחזק רשימות IP באופן ידני.

→ב-Azure Firewall, צור אוסף כללי יישומים. הוסף כלל עם סוג FQDN היעד מוגדר ל-"FQDN Tag" ובחר את התג "WindowsUpdate".

למה: תגי FQDN הם אוספים מנוהלים של FQDNs ש-Microsoft מנהלת. זו הדרך הנכונה לאפשר גישה לשירותי PaaS שכתובות ה-IP הבסיסיות שלהם משתנות לעיתים קרובות. Service Tags מיועדים לכללים מבוססי IP.

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

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

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

ספק גישת RDP/SSH מאובטחת למכונות וירטואליות של Azure מבלי לחשוף יציאות ניהול לאינטרנט או לדרוש כתובות IP ציבוריות על המכונות הווירטואליות.

→פרוס Azure Bastion (SKU Standard לתכונות מתקדמות) לתת-רשת ייעודית ב-VNet. גש למכונות וירטואליות דרך פורטל Azure, המתחבר דרך שירות Bastion.

למה: Bastion פועל כ-jump box מאובטח, ומתווך את חיבור ה-RDP/SSH. ה-IP הציבורי היחיד נמצא בשירות Bastion עצמו, המאובטח ומנוהל על ידי Microsoft, ובכך מצמצם באופן דרמטי את שטח התקיפה של המכונות הווירטואליות שלך.

ספק למפתחים גישה מוגבלת בזמן ומבוקרת ליציאות ניהול (RDP/SSH) במכונות וירטואליות לפיתוח.

→אפשר את Microsoft Defender for Cloud והגדר גישת JIT (Just-in-Time) למכונות הווירטואליות. משתמשים יבקשו גישה דרך Defender for Cloud, אשר משנה באופן דינמי כללי NSG כדי לאפשר גישה לזמן מוגבל מ-IP ספציפי.

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

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

→אפשר את התוסף Azure Policy עבור AKS. הקצה את יוזמת המדיניות המובנית בשם "תקני אבטחה מוגבלים של קבצי Pod באשכול Kubernetes עבור עומסי עבודה מבוססי Linux".

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

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

→הגדר VPN מסוג Site-to-Site או ExpressRoute. צור נתיב מוגדר משתמש (UDR) עבור קידומת הכתובת 0.0.0.0/0, והגדר את ה-next hop להיות שער הרשת הווירטואלית.

למה: תבנית זו, המכונה "forced tunneling", עוקפת את נתיב ברירת המחדל של Azure לאינטרנט וכופה את כל התעבורה היוצאת דרך השער לרשת המקומית, ובכך מבטיחה שאף מכונה וירטואלית לא תוכל לעקוף בקרות אבטחה ארגוניות.

בצע בדיקה של תעבורה מוצפנת ב-TLS יוצאת ממכונות וירטואליות לאיתור איומים באמצעות Azure Firewall.

→פרוס Azure Firewall Premium. אפשר בדיקת TLS וזיהוי חדירות (IDPS). הגדר אישור CA משני בחומת האש ופרוס את המפתח הציבורי שלו למכונות הווירטואליות של הלקוח כ-CA שורש מהימן.

למה: כדי לבדוק תעבורה מוצפנת, חומת האש חייבת לבצע פעולת Man-in-the-Middle. זה דורש את SKU Premium, IDPS לזיהוי איומים, ותשתית אישורים מתאימה כדי למנוע שגיאות TLS במכונות הלקוח.

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

→צור תוכנית הגנה אחת של Azure DDoS. קשר תוכנית זו לכל הרשתות הווירטואליות המכילות כתובות IP ציבוריות הזקוקות להגנה.

למה: תוכנית הגנה יחידה של DDoS יכולה לכסות עד 100 VNets, ואתה משלם עמלה חודשית קבועה עבור התוכנית, לא לכל VNet או לכל IP. מודל מרכזי זה חסכוני הרבה יותר מפריסת תוכניות מרובות או שימוש ב-SKU הגנה לכל IP.

כאשר נוצר אירוע אבטחה בחומרה גבוהה ב-Microsoft Sentinel, השבת אוטומטית את חשבון המשתמש המעורב ב-Azure AD והודע לצוות האבטחה ב-Teams.

→צור כלל אוטומציה המופעל בעת יצירת אירוע בחומרה גבוהה. הכלל צריך לקרוא ל-Playbook (Logic App). ה-Playbook משתמש במחבר Azure AD כדי להשבית את המשתמש ובמחבר Teams כדי לפרסם הודעה.

למה: זה מדגים את תבנית SOAR (Security Orchestration, Automation, and Response). כלל האוטומציה הוא מנוע ההפעלה/תנאי, וה-Playbook הוא מנוע הפעולה/זרימת העבודה.

מקור↗

החל סט עקבי של מדיניות אבטחה ואפשר תוכניות Defender for Cloud על פני מספר רב של מנויי Azure.

→ארגן את כל המנויים תחת קבוצת ניהול (Management Group). הקצה את יוזמת המדיניות Azure Security Benchmark ואפשר את תוכניות Defender for Cloud הנדרשות ברמת קבוצת הניהול.

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

צור זיהוי מותאם אישית ב-Sentinel עבור משתמש הנכנס ממדינה חדשה בפעם הראשונה.

→צור כלל ניתוח שאילתה מתוזמנת. השתמש בשאילתת KQL המצרפת `SigninLogs` אחרונים עם היסטוריה מסוכמת של `SigninLogs` קודמים כדי לזהות שילובי UserPrincipalName/Country שלא נראו בעבר.

למה: כללי שאילתה מתוזמנים עם KQL הם הבסיס לזיהוי איומים מותאם אישית ב-Sentinel, ומאפשרים לוגיקה מורכבת ובעלת מצב (stateful) החורגת מעבר להתאמת אירועים פשוטה.

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

→בסביבת העבודה של Log Analytics, הגדר את "שמירה אינטראקטיבית" ל-90 ימים. הגדר את "שמירה כוללת" (ארכיון) ל-730 ימים (שנתיים). הגדר מדיניות שמירה לכל טבלה בנפרד אם נדרש.

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

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

→מדף האירוע ב-Microsoft Sentinel, פתח את גרף החקירה (Investigation Graph). השתמש בגרף כדי לחקור ויזואלית ישויות וחיבוריהן על פני התראות ומקורות יומן שונים.

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

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

→וודא ש-User and Entity Behavior Analytics (UEBA) מופעל ב-Microsoft Sentinel וכי מקורות נתונים רלוונטיים (יומני Azure AD, Defender for Endpoint/Security Events) מחוברים. עקוב אחר UEBA לגילוי חריגות הקשורות לתנועה רוחבית.

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

צמצם את עלויות הכניסה (ingestion) ל-Microsoft Sentinel עבור יומנים רטוריים בנפח גבוה הנדרשים לתאימות אך לא עבור ניתוח בזמן אמת.

→הגדר את תוכנית הטבלה עבור יומנים אלו ל-"Basic Logs". בנוסף, השתמש בכללי איסוף נתונים (DCRs) עם שאילתות XPath או טרנספורמציות אחרות כדי לסנן אירועים רועשים ובעלי ערך נמוך לפני ההכנסה.

למה: Basic Logs מציעים עלות כניסה נמוכה משמעותית בתמורה ליכולות שאילתה מוגבלות ושמירה קצרה יותר. סינון במקור באמצעות DCRs הוא הדרך היעילה ביותר לצמצם נפח על ידי מניעת הגעת נתונים לא רצויים לסביבת העבודה.

אכוף אוטומטית הגדרת אבטחה, כגון הפעלת "Secure transfer required" בכל חשבונות האחסון הקיימים והחדשים של Azure.

→הקצה Azure Policy עם אפקט `DeployIfNotExists` או `Modify`. עבור משאבים קיימים שאינם תואמים, צור משימת תיקון מלהב תאימות המדיניות כדי להחיל את השינוי.

למה: מדיניות Audit ו-Deny רק מדווחות או חוסמות אי-תאימות. `DeployIfNotExists` ו-`Modify` עם משימות תיקון מתקנים באופן פעיל תצורות שגויות, מה שהופך את המדיניות לכלי רב עוצמה לממשל אוטומטי וחיזוק אבטחה.

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

→אפשר את Microsoft Defender for Containers. זה פורס DaemonSet (סוכן Defender) לכל צומת באשכול, אשר אוסף אותות אבטחה מהמארח ומהקונטיינרים כדי לספק זיהוי איומים בזמן אמת.

למה: בעוד שסריקת ACR מספקת אבטחה "Shift-Left", הגנת זמן ריצה חיונית לאיתור איומים המתרחשים לאחר הפריסה. Defender for Containers מספק ראות זו ברמת המארח ועומס העבודה בתוך האשכול.