מדריך

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

→הגדר קבוצת אבטחה של Microsoft Entra ID עם סוג חברות "משתמש דינמי" (Dynamic User) והגדר כלל מבוסס-תכונה.

למה: כללים מבוססי-תכונות מבטלים ניהול ידני מתמשך עבור שינויים במחזור חיי המשתמש. דורש Entra ID P1/P2.

מקור↗

החל ממשל עקבי (policies, RBAC) על פני מספר מנויים מנקודת ניהול אחת.

→צור קבוצת ניהול (management group), מקם תחתיה מנויים, והקצה policies או תפקידי RBAC בהיקף קבוצת הניהול.

למה: Policies והקצאות תפקידים עוברות בירושה לכל המנויים התת-הוריים, מה שמאפשר ממשל מרכזי ועקבי.

מקור↗

מנע פריסת משאבים באזורי Azure לא מורשים על פני מנוי שלם.

→הקצה את ה-Azure Policy המובנה "Allowed locations" עם אפקט `Deny` בהיקף המנוי.

למה: Policy מספק ממשל מונע. RBAC שולט בפעולות, לא במיקומי פריסה. Resource Locks מונעים שינוי/מחיקה, לא פריסות חדשות.

הענק הרשאות לניהול VMs אך לא לרשת הווירטואלית הבסיסית או לגישת משתמש.

→הקצה את התפקיד המובנה "Virtual Machine Contributor" בהיקף קבוצת המשאבים או ה-VM.

למה: תפקיד זה מספק הרשאות ניהול VM ספציפיות (הפעלה, עצירה, התקנה מחדש של image) מבלי להעניק זכויות Contributor או Owner רחבות.

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

→צור Conditional Access policy עם "Named Location" עבור כתובות IP ארגוניות כתנאי החרגה, ודרוש MFA כבקרת הענקה.

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

מקור↗

מנע מחיקה של משאבים קריטיים, גם על ידי מנהלים בעלי תפקידי Owner.

→החל Resource Lock מסוג `CanNotDelete` או `ReadOnly` על המשאב או על קבוצת המשאבים שלו.

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

תקן אוטומטית משאבים קיימים שאינם תואמים שזוהו על ידי Azure Policy (לדוגמה, הוסף תגית חסרה).

→עבור policies עם אפקטים של `Modify` או `DeployIfNotExists`, צור משימת תיקון (remediation task) עבור הקצאת ה-policy.

למה: משימות תיקון מפעילות את פעולת התיקון של ה-policy על כל המשאבים הקיימים שאינם תואמים, ובכך הופכות את תהליך הבאת הסביבה לתאימות לאוטומטי.

הפק דוחות על עלויות Azure מפורטות לפי מחלקה, פרויקט או יחידה עסקית.

→החל תגית עקבית (לדוגמה, "CostCenter") על כל המשאבים. השתמש ב-Azure Cost Management כדי לסנן ולקבץ עלויות לפי תגית זו.

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

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

→השתמש ב-Microsoft Entra Privileged Identity Management (PIM). הפוך משתמשים לזכאים לתפקידים והגדר דרישות הפעלה.

למה: PIM אוכף גישת Just-In-Time (JIT), מפחית את חשיפת חשבונות מיוחסים קבועים ומספק נתיב ביקורת מלא.

הענק לשותפים חיצוניים גישה למשאבי Azure באמצעות אישורי החברה שלהם.

→השתמש בשיתוף פעולה Microsoft Entra B2B כדי להזמין שותפים כמשתמשי guest ל-tenant שלך.

למה: B2B מונע יצירה וניהול של אישורים חדשים ב-tenant שלך; שותפים משתמשים בספק הזהויות הקיים שלהם לאימות.

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

→השתמש ב-policy לניהול מחזור חיים של blob כדי להעביר אוטומטית blobs משכבת Hot/Cool לשכבת Archive.

למה: שכבת Archive בעלת עלות האחסון הנמוכה ביותר. כללי מחזור חיים הופכים את תהליך ה-tiering לאוטומטי בהתבסס על גיל ה-blob או זמן הגישה האחרון.

מקור↗

ודא גישת קריאה לנתוני אחסון מאזור משני במהלך השבתת אזור ראשי.

→הגדר את חשבון האחסון עם Read-Access Geo-Redundant Storage (RA-GRS) או RA-GZRS.

למה: GRS/GZRS רגיל משכפל נתונים אך אינו מאפשר גישת קריאה למשני עד ל-failover. הקידומת "RA" נדרשת לגישת קריאה מתמשכת.

יכולת לבטל מיידית קבוצת אסימוני Shared Access Signature (SAS) עבור container ספציפי.

→צור אסימוני SAS המבוססים על stored access policy ב-container. כדי לבטל, שנה או מחק את ה-policy.

למה: שינוי stored access policy מבטל מיידית את כל אסימוני ה-SAS המשויכים אליה, ומספק מנגנון ביטול מרכזי.

סנכרן שרת קבצים מקומי (on-premises) עם Azure file share תוך מזעור השימוש בשטח דיסק מקומי.

→פרוס Azure File Sync ואפשר cloud tiering בנקודת הקצה של השרת.

למה: Cloud tiering שומר רק קבצים בשימוש תכוף ("hot") במטמון באופן מקומי, בעוד שקבצים פחות בשימוש עוברים tiering ל-Azure, ומופיעים כ-stubs בשרת המקומי.

הגבל גישת רשת לחשבון אחסון לתתי רשת ספציפיות של VNet ולכתובות IP ציבוריות.

→אפשר את חומת האש של חשבון האחסון. הוסף כללי רשת וירטואלית עבור תתי הרשת וכללי כתובות IP עבור כתובות ה-IP הציבוריות.

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

הגן על blobs מפני מחיקה בשוגג על ידי מתן אפשרות שחזור לתקופה מוגדרת.

→אפשר blob soft delete בחשבון האחסון והגדר את תקופת השמירה (לדוגמה, 14 ימים).

למה: Soft delete שומר blobs שנמחקו לתקופה המוגדרת, ומאפשר ביטול מחיקה פשוט. זוהי קו ההגנה הראשון מפני אובדן נתונים בשוגג.

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

→הגדר time-based retention policy על blob container ונעל את ה-policy.

למה: time-based retention policy נעולה הופכת blobs לבלתי ניתנים לשינוי (immutable), ומונעת מחיקה או שינוי על ידי כל אחד (כולל מנהלים) עד שתקופת השמירה תפוג.

העבר מערך נתונים גדול מאוד (לדוגמה, 50+ TB) ל-Azure Blob Storage כאשר רוחב הפס של הרשת מוגבל.

→השתמש במכשיר הפיזי Azure Data Box להעברה לא מקוונת.

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

השג SLA של 99.99% עבור VMs והגן על יישום מפני כשל של מרכז נתונים יחיד בתוך אזור.

→פרוס מופעי VM מרובים על פני Availability Zones שונות בתוך אותו אזור.

למה: Availability Zones הם מרכזי נתונים נפרדים פיזית. Availability Sets מגנים רק מפני כשלים ברמת ה-rack בתוך מרכז נתונים יחיד (SLA של 99.95%).

מקור↗

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

→השתמש ב-App Service deployment slot. פרוס ל-slot, בצע בדיקה, ולאחר מכן בצע swap. לחלופין, השתמש ב-traffic routing לבדיקת canary.

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

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

→השתמש ב-Azure Container Instances (ACI).

למה: ACI מציע חיוב לפי שנייה וללא תקורה של ניהול cluster, מה שהופך אותו לאפשרות החסכונית ביותר עבור עומסי עבודה של container ספורדיים או קצרי מועד.

בצע autoscale לעומס עבודה עם שיאים יומיים צפויים (לדוגמה, שעות עסקים) תוך טיפול גם בשיאים בלתי צפויים.

→הגדר autoscale של VM Scale Set עם כללים מבוססי-לוח זמנים וגם כללים מבוססי-מטריקה.

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

אחסן תמונות container עבור cluster של Azure Kubernetes Service (AKS) באופן מאובטח ב-registry פרטי עם סריקת פגיעויות.

→השתמש ב-Azure Container Registry (ACR) Premium SKU ושלב אותו עם AKS באמצעות managed identity.

למה: ACR מספק registry פרטי הממוקם ב-Azure. ה-Premium SKU כולל סריקת פגיעויות. Managed identity מספק אימות מאובטח וחסר אישורים מ-AKS ל-ACR.

בצע עדכון OS או יישום בכל מופעי ה-VMSS מבלי לגרום לזמן השבתה של היישום.

→עדכן את מודל ה-VMSS (לדוגמה, גרסת image חדשה) והשתמש ב-Rolling upgrade policy.

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

פרוס יישום מרובה container (לדוגמה, אפליקציה + logging sidecar) שחייב לשתף רשת ואחסון, ללא orchestrator מלא.

→פרוס את ה-containers לקבוצת container יחידה של Azure Container Instances (ACI).

למה: קבוצת container ממוקמת יחד מספר containers, ומשתפת רשת localhost ונפחים, מושלמת לדפוסי sidecar ללא המורכבות של Kubernetes.

הגדל את גודל דיסק ה-OS או הנתונים של VM לאחר פריסתו.

→בטל הקצאה של ה-VM, שנה את גודל משאב הדיסק ב-Azure, הפעל את ה-VM, ולאחר מכן הרחב את המחיצה בתוך ה-guest OS.

למה: שינוי גודל דיסק Azure רק מקצה שטח נוסף. יש להנחות את ה-guest OS להשתמש בשטח החדש על ידי הרחבת מחיצת מערכת הקבצים שלו.

אפשר ל-App Service לגשת באופן מאובטח לסודות מ-Azure Key Vault מבלי לאחסן אישורים ביישום.

→אפשר managed identity מוקצה-מערכת (system-assigned) ב-App Service והענק לזהות זו הרשאות `Get` ו-`List` על סודות ה-Key Vault.

למה: Managed identity מספק מנגנון אימות ללא אישורים. היישום יכול לרכוש access token עבור Key Vault באופן אוטומטי, ובכך לבטל את ניהול הסודות.

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

→בצע refactor לפריסה למודולי Bicep, כאשר כל מודול מייצג יחידה לוגית (לדוגמה, networking, compute), וארגן אותם מקובץ Bicep ראשי.

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

בודד שכבות יישום (web, app, data) בתוך VNet, מנע תקשורת ישירה בין שכבות שאינן סמוכות.

→השתמש ב-subnet נפרד עבור כל שכבה והחל Network Security Groups (NSGs) על כל subnet כדי לשלוט בזרימת התעבורה.

למה: NSGs מאפשרים סינון פרטני ומצבני (stateful) המבוסס על טווחי IP של מקור/יעד (subnets), פורטים ופרוטוקולים, ומאפשרים micro-segmentation של הרשת.

חבר שני VNets באזורי Azure שונים באופן פרטי מעל רשת ה-backbone של Microsoft.

→הגדר Global VNet Peering בין שני ה-VNets.

למה: Global Peering פשוט יותר, בעל latency נמוך יותר ורוחב פס גבוה יותר מחיבור VNet-to-VNet VPN. התעבורה נשארת ברשת הפרטית של Microsoft.

VNet-A מקושר ל-Hub-VNet, ו-Spoke-VNet מקושר גם הוא ל-Hub-VNet. VMs ב-VNet-A אינם יכולים להגיע ל-VMs ב-Spoke-VNet.

→הסיבה היא ש-VNet peering אינו טרנזיטיבי. כדי לאפשר תקשורת, קשר ישירות את VNet-A ו-Spoke-VNet או השתמש ב-NVA ב-Hub.

למה: Peering אינו יוצר שרשרת. כל VNet חייב להיות מחובר ישירות כדי לתקשר, אלא אם כן מוגדר ניתוב דרך Network Virtual Appliance.

הקם מנהרת IPsec מוצפנת וקבועה מרשת on-premises ל-Azure VNet מעל האינטרנט הציבורי.

→פרוס Azure VPN Gateway ב-VNet והגדר חיבור Site-to-Site (S2S).

למה: זהו הפתרון הסטנדרטי, המאובטח והאמין לקישוריות היברידית בין אתר on-premises יחיד ל-Azure VNet.

Azure Load Balancer ממשיך לשלוח תעבורה ל-VM אחורי לא תקין, וגורם ל-timeouts ביישום.

→הגדר health probe ב-load balancer הבודק באופן מדויק את תקינות היישום ב-VMs האחוריים.

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

נתב תעבורת HTTP/S למאגרי שרתים אחוריים שונים בהתבסס על נתיב ה-URL (לדוגמה, /images/* לעומת /api/*).

→השתמש ב-Azure Application Gateway עם כללי ניתוב מבוססי-נתיב.

למה: Application Gateway הוא Layer 7 load balancer שבודק בקשות HTTP ויכול לקבל החלטות ניתוב בהתבסס על נתיבי URL. Azure Load Balancer סטנדרטי הוא Layer 4 ואינו יכול.

VMs ב-VNet עם שרת DNS מותאם אישית אינם יכולים לפתור שמות מארחים ב-Azure Private DNS Zone.

→הגדר את שרת ה-DNS המותאם אישית להעביר באופן מותנה שאילתות עבור ה-private zone לכתובת ה-IP של ה-DNS resolver שמספק Azure (168.63.129.16).

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

אכוף שכל התעבורה היוצאת לאינטרנט מ-spoke VNets תיבדק על ידי Azure Firewall מרכזי ב-hub VNet.

→החל Route Table עם User-Defined Route (UDR) על ה-spoke subnets. ה-UDR הוא default route (0.0.0.0/0) המצביע על ה-IP הפרטי של חומת האש.

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

ספק גישת RDP/SSH מאובטחת ל-VMs שאין להם כתובות IP ציבוריות, ללא הגדרת VPN.

→פרוס Azure Bastion ל-subnet ייעודי (AzureBastionSubnet) ב-VNet.

למה: Bastion מספק שירות jump box מנוהל, המאפשר גישה ניהולית מאובטחת דרך פורטל Azure באמצעות TLS, ומבטל חשיפה של IP ציבורי ב-VMs.

ודא שתעבורה בין VM לשירות PaaS (לדוגמה, Azure SQL) נשארת ברשת הפרטית וששירות ה-PaaS אינו נגיש לציבור.

→צור private endpoint עבור שירות ה-PaaS ב-VNet של ה-VM ובטל גישת רשת ציבורית בשירות ה-PaaS.

למה: private endpoint מעניק לשירות ה-PaaS IP פרטי בתוך ה-VNet שלך, בעוד שביטול גישה ציבורית מבטיח שהוא נגיש רק באמצעות IP פרטי זה.

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

→השתמש ב-Azure Traffic Manager עם שיטת הניתוב "Performance".

למה: שיטת הניתוב Performance משתמשת ב-DNS כדי לנתב לקוחות לנקודת הקצה עם ה-latency הנמוך ביותר ממיקומם.

שלח התראה (אימייל, SMS, webhook) כאשר מטריקה של משאב (לדוגמה, אחוז CPU של VM) חורגת מסף למשך זמן מוגדר.

→צור כלל Metric Alert ב-Azure Monitor וקשר אותו ל-Action Group המגדיר את פעולת ההתראה.

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

קבע אם תעבורה בין שני VMs נחסמת על ידי כלל Network Security Group (NSG) ספציפי.

→השתמש בכלי IP Flow Verify ב-Azure Network Watcher.

למה: IP Flow Verify מדמה זרימת packet ומדווח במפורש איזה NSG וכלל מאפשרים או מונעים את התעבורה, מה שהופך אותו לכלי המכריע לפתרון קונפליקטים ב-NSG.

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

→צור Recovery Services vault, הגדר backup policy (לוח זמנים, שמירה), ואפשר גיבוי עבור ה-VMs המיועדים.

למה: Recovery Services vault הוא ישות הניהול המרכזית עבור Azure Backup. הוא מאחסן נתוני גיבוי באופן מאובטח ומנהל את כל פעולות הגיבוי והשחזור.

מקור↗

צור לוח מחוונים מרכזי לניטור ביצועים (CPU, Memory, Disk, Network) של VMs על פני מספר מנויים.

→פרוס Log Analytics workspace מרכזי ואפשר VM Insights עבור כל ה-VMs המיועדים, והצבע עליהם ל-workspace.

למה: VM Insights אוסף ומאגד נתוני ביצועים, מספק חוברות עבודה מובנות ותצוגת ביצועים "בקנה מידה גדול" ומאוחדת על פני מנויים.

זהה באופן יזום משאבי Azure שאינם מנוצלים מספיק והזדמנויות לחיסכון בעלויות (לדוגמה, VM right-sizing).

→סקור באופן קבוע את המלצות העלות ב-Azure Advisor.

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

שכפל Azure VMs מאזור ראשי לאזור משני כדי לספק יכולת התאוששות מאסון.

→השתמש ב-Azure Site Recovery. צור Recovery Services vault ואפשר שכפול עבור ה-VMs לאזור היעד.

למה: ASR הוא שירות ה-Azure המקומי לתיאום שכפול VM, בדיקות failover ו-failover/failback בין אזורי Azure.

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

→הגדר שמירה דיפולטיבית ברמת ה-workspace ולאחר מכן הגדר תקופת שמירה ארוכה יותר ברמת הטבלה הבודדת (לדוגמה, עבור טבלת SecurityEvent).

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