מדריך

חבר משאבים בין רשתות VNet במנויים או אזורים שונים באופן פרטי.

→הגדר VNet peering בין הרשתות הווירטואליות.

למה: שומר תעבורה על ה-backbone של Microsoft. VNet peering אינו טרנזיטיבי; נדרש peering ישיר לתקשורת (A->B, B->C != A->C).

מקור↗

תכנן מרחבי כתובות VNet לקישוריות עתידית.

→הקצה בלוקי CIDR ייחודיים ולא חופפים לכל VNet.

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

חשב את גודל ה-subnet הנדרש למספר ספציפי של hosts.

→השתמש ב-CIDR notation המספק את ה-hosts הנדרשים + 5 כתובות IP שמורות עבור Azure.

למה: Azure שומרת את ארבעת ה-IPs הראשונים ואת ה-IP האחרון בכל subnet. /24 (256 IPs) מספק רק 251 IPs שמישים.

פרוס שירותים כמו Azure Firewall, Gateway, או Bastion.

→צור subnets ייעודיים עם שמות ספציפיים (לדוגמה, AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) וגדלים מינימליים (/26, /27, /26 בהתאמה).

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

אפשר רזולוציית שמות בין רשתות מקומיות (on-premises) ואזורי Azure Private DNS.

→פרוס Azure DNS Private Resolver. השתמש ב-inbound endpoint עבור שאילתות מ-on-prem ל-Azure וב-outbound endpoint עם כללי העברה עבור שאילתות מ-Azure ל-on-prem.

למה: מספק פתרון PaaS מנוהל ל-DNS היברידי ללא צורך ב-VMs DNS מותאמים אישית. DNS מקומי מעביר ל-IP של ה-inbound endpoint.

מקור↗

VNet מחובר ב-peering אינו יכול לפתור רשומות באזור Private DNS.

→צור קישור רשת וירטואלית מאזור ה-Private DNS ל-VNet המחובר ב-peering.

למה: גישה לאזור Private DNS אינה טרנזיטיבית באמצעות peering. לכל VNet הדורש רזולוציה חייב להיות קישור מפורש.

ספק IP ציבורי יוצא (outbound) סטטי וצפוי עבור VMs ב-subnet עבור allow-listing.

→קשר Azure NAT Gateway עם Public IP או Public IP Prefix ל-subnet.

למה: NAT Gateway עוקף את כל שיטות הקישוריות היוצאות האחרות עבור subnet, ומבטיח שכל התעבורה תשתמש ב-IP(ים) הציבוריים הסטטיים שלו.

מקור↗

ודא ש-IP ציבורי עבור משאב כמו Load Balancer נשאר קבוע.

→השתמש בכתובת Public IP מסוג Standard SKU עם הקצאה סטטית.

למה: IPs סטטיים מסוג Standard SKU הם zone-redundant כברירת מחדל ונשארים גם כאשר המשאב המשויך נעצר או נמחק.

תכנן subnet עבור אשכול AKS המשתמש ברשת Azure CNI.

→חשב צרכי IP כ- (מספר nodes * max pods per node) + מספר nodes. הקצה subnet שיכול להכיל ספירה זו.

למה: עם Azure CNI, כל pod מקבל IP ישירות מה-subnet, הדורש הקצאת כתובות IP משמעותית.

נתב את כל התעבורה המיועדת לאינטרנט מ-spoke VNet דרך Azure Firewall ב-hub VNet.

→צור טבלת User Defined Route (UDR) עם נתיב עבור 0.0.0.0/0, next hop type "Virtual appliance", וה-IP הפרטי של Azure Firewall.

למה: זה עוקף את נתיב המערכת המוגדר כברירת מחדל לאינטרנט, ומאלץ את כל התעבורה לעבור דרך ה-firewall לבדיקה.

מקור↗

בדוק תעבורה בין שני spoke VNets באמצעות Azure Firewall ב-hub.

→בכל spoke, צור UDRs עבור מרחבי כתובות של spoke אחרים המצביעים על ה-firewall. ב-firewall, צור כללי רשת כדי לאפשר את התעבורה.

למה: יש להגדיר ניתוב בשני ה-spokes כדי לשלוח תעבורה ל-firewall, אשר כברירת מחדל מונע תעבורה בין VNets.

פרוס אשכול NVA עמיד לבדיקת תעבורה או ניתוב.

→השתמש ב-Azure Route Server. ה-NVAs מתחברים ל-Route Server באמצעות BGP ומפרסמים נתיבים. Route Server משתמש ב-ECMP לחלוקת עומס.

למה: Route Server מפשט ניתוב דינמי עם NVAs, מבטל ניהול UDR מורכב ומספק failover אוטומטי.

מקור↗

NVA מפיל תעבורה שהוא אמור לנתב.

→אפשר "IP forwarding" בממשק הרשת (NIC) של ה-NVA.

למה: הגדרה זו ברמת Azure נדרשת כדי לאפשר ל-NIC לקבל ולהעביר תעבורה שאינה מיועדת לכתובת ה-IP שלו.

פזר תעבורת HTTP/S גלובלית ל-backend עם ההשהיה הנמוכה ביותר, עם WAF ו-SSL offloading.

→השתמש ב-Azure Front Door.

למה: Front Door משתמש ב-anycast routing לביצועים אופטימליים ומשלב WAF, ניתוב URL ו-SSL offloading בקצה.

מקור↗

פזר תעבורה ל-endpoints גלובליים מבוססי DNS עם failover מונחה בדיקות תקינות.

→השתמש ב-Azure Traffic Manager.

למה: Traffic Manager הוא load balancer מבוסס DNS. השתמש בניתובי "Performance" להשהיה הנמוכה ביותר או "Priority" ל-failover מסוג active/passive.

ספק load balancing אזורי של HTTP/S עם WAF, סיום SSL וניתוב מבוסס URL/host.

→פרוס Azure Application Gateway v2.

למה: Application Gateway הוא load balancer אזורי L7. השתמש בכללים מבוססי נתיב לניתוב URL וב-multi-site listeners לניתוב מבוסס host.

בצע load balance לתעבורת non-HTTP/S (TCP/UDP) בתוך אזור.

→השתמש ב-Azure Load Balancer (Standard SKU).

למה: Azure Load Balancer הוא load balancer אזורי L4. הוא שומר על ה-client source IP ומתאים לכל פרוטוקולי ה-TCP/UDP.

סיים SSL ב-Application Gateway אך הצפן מחדש את התעבורה ל-backend.

→הגדר HTTPS listener. בהגדרות ה-HTTP של ה-backend, הגדר את הפרוטוקול ל-HTTPS והעלה את תעודת ה-root המהימנה של שרתי ה-backend.

למה: מבטיח שהתעבורה מוצפנת במעבר לכל אורך הדרך ל-backend, גם עם תעודות self-signed בשרתי ה-backend.

בצע load balance לתעבורה ל-SQL Server Always On Availability Group listener.

→השתמש ב-Standard Load Balancer פנימי עם ההגדרה "Floating IP (Direct Server Return)" מופעלת על כלל ה-load balancing.

למה: Floating IP נדרש כדי ש-SQL AG listener יתפקד כראוי, מכיוון שהוא מאפשר ל-secondary node להגיב ישירות ללקוחות לאחר failover.

בצע load balance לתעבורה לאשכול של NVAs שחייבים לעבד את כל הפרוטוקולים והפורטים.

→השתמש ב-Standard Load Balancer פנימי עם כלל load balancing מסוג "HA Ports".

למה: כלל HA Ports מעביר את כל תעבורת ה-TCP וה-UDP בכל הפורטים, ומפשט את התצורה עבור NVAs שצריכים לבדוק את כל זרימות התעבורה.

הגדר failover אוטומטי בין origin ראשי ומשני של יישום אינטרנט.

→מקם את שני ה-origins באותה קבוצת Front Door origin group. הקצה ל-origin הראשי עדיפות 1 ולמשני עדיפות נמוכה יותר (לדוגמה, 2).

למה: Front Door תמיד שולח תעבורה ל-origin התקין בעל העדיפות הגבוהה ביותר. כאשר הראשי נכשל בבדיקות תקינות, התעבורה עוברת אוטומטית לעדיפות הבאה.

ספק גישת RDP/SSH מאובטחת ל-Azure VMs מבלי לחשוף את פורטי הניהול לאינטרנט.

→פרוס Azure Bastion (Standard SKU עבור תכונות מתקדמות).

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

מקור↗

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

→צור Private Endpoint עבור משאב ה-PaaS. שלב עם Private DNS Zone לרזולוציית שמות אוטומטית.

למה: Private Endpoint מקרין את שירות ה-PaaS לתוך ה-VNet שלך עם IP פרטי, מאפשר קישוריות פרטית באמת. השבתת גישת רשת ציבורית בשירות ה-PaaS אוכפת זאת.

גש לשירותי Azure PaaS מ-VNet דרך ה-Azure backbone ללא שימוש ב-IPs ציבוריים, אך ללא ניהול IP פרטי ייעודי.

→אפשר Service Endpoint עבור השירות הספציפי (לדוגמה, Microsoft.Storage) ב-subnet המקור.

למה: Service Endpoints מספקים נתיב ישיר לשירותי PaaS מ-VNet, אך אינם משתמשים ב-IP פרטי ב-VNet. זה פשוט יותר אך פחות גמיש מ-Private Endpoints.

חשוף שירות הפועל ב-VNet שלך לצרכנים ב-VNets אחרים (אולי tenants אחרים) באופן פרטי.

→מקם את השירות מאחורי Standard Load Balancer וצור Private Link Service המצביע עליו.

למה: Private Link Service הוא רכיב בצד הספק. צרכנים יוצרים Private Endpoints ב-VNets שלהם כדי להתחבר לשירות שלך באופן פרטי.

מקור↗

פשט כללי NSG עבור יישום רב-שכבתי שבו VMs עשויים לעבור scale או לשנות IPs.

→צור Application Security Groups (ASGs) לכל שכבה (לדוגמה, Web, App, DB). הגדר כללי NSG באמצעות ASGs כמקור/יעד.

למה: ASGs פועלים כתגי אובייקט רשת עבור VMs, ומאפשרים לך ליצור כללים המבוססים על מבנה היישום ולא על כתובות IP שבריריות.

תעבורה נחסמת באופן בלתי צפוי כאשר NSGs מיושמים גם על NIC וגם על ה-subnet שלו.

→זכור את סדר הערכת כללי NSG. נכנס: כללי NIC תחילה, ואז כללי Subnet. יוצא: כללי Subnet תחילה, ואז כללי NIC.

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

חסום אוטומטית תעבורה אל/מכתובות IP ודומיינים זדוניים ידועים.

→אפשר סינון מבוסס Threat Intelligence של Azure Firewall במצב "Alert and deny".

למה: זה משתמש ב-feed של Threat Intelligence של Microsoft כדי לספק הגנה מנוהלת ומעודכנת מפני איומים ידועים עם אפס תצורה.

בדוק תעבורת HTTPS מוצפנת לאיתור איומים כמו תוכנות זדוניות.

→השתמש ב-Azure Firewall Premium. אפשר TLS Inspection במדיניות ופרוס תעודת CA ביניים שלקוחות חייבים לבטוח בה.

למה: זוהי תכונת פרימיום המבצעת פענוח man-in-the-middle כדי לבדוק תעבורה, וזה קריטי עבור גישת אבטחה של zero-trust.

אפשר גישת outbound לשירותי Microsoft מורכבים כמו Windows Update מבלי לתחזק רשימות IP.

→ב-Azure Firewall, צור Application Rule באמצעות FQDN Tags (לדוגמה, "WindowsUpdate", "AzureBackup").

למה: Microsoft מנהלת את ה-FQDNs המשויכים לתגים אלה, מה שמפשט את ניהול כללי ה-firewall עבור שירותים דינמיים.

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

→אפשר DDoS Network Protection (לשעבר Standard) ב-VNet.

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

אבחן כשל קישוריות וזהה את ה-hop המדויק שבו התעבורה נזרקת.

→השתמש ב-Network Watcher > Connection Troubleshoot.

למה: הוא מבצע בדיקה מקצה לקצה, מציג את הנתיב המלא hop-by-hop ומצביע על כשלים עקב NSGs, UDRs או בעיות רשת אחרות.

בדוק במהירות אם כלל NSG מאפשר או חוסם תעבורה אל/מ-VM.

→השתמש ב-Network Watcher > IP Flow Verify.

למה: זהו הכלי הישיר ביותר לבדיקת 5-tuple ספציפי מול כללי NSG ולראות איזה כלל אחראי לתוצאה.

רשום יומן של כל תעבורת הרשת המותרת והנחסמת לצורך ציות וניתוח.

→אפשר NSG Flow Logs והכנס אותם ל-Traffic Analytics (באמצעות Log Analytics Workspace).

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

חבר רשת מקומית (on-premises) ל-Azure עם חיבור פרטי וייעודי המציע השהיה צפויה ורוחב פס גבוה.

→ספק מעגל Azure ExpressRoute.

למה: ExpressRoute עוקף את האינטרנט הציבורי לחלוטין, ומספק חיבור אמין, מהיר ועם השהיה נמוכה יותר מאשר Site-to-Site VPN.

מקור↗

בחר את ה-ExpressRoute peering הנכון כדי לגשת למשאבי Azure.

→השתמש ב-Azure private peering כדי להתחבר ל-VNets. השתמש ב-Microsoft peering כדי לגשת לשירותי PaaS ציבוריים ול-Microsoft 365.

למה: שני סוגי ה-peering מספקים גישה לקבוצות שונות של משאבים. Microsoft peering דורש IPs ציבוריים, NAT ו-route filters.

אפשר ל-spoke VNets לגשת לרשתות מקומיות (on-premises) באמצעות VPN מרכזי או ExpressRoute gateway ב-hub VNet.

→ב-peering בין hub ל-spoke, אפשר "Allow gateway transit". ב-peering בין spoke ל-hub, אפשר "Use remote gateways".

למה: תצורה דו-חלקית זו מאפשרת ל-spokes להשתמש ב-gateway של ה-hub, ובכך לרכז קישוריות היברידית.

הגדר Site-to-Site VPN כגיבוי לחיבור ExpressRoute.

→פרוס גם ExpressRoute וגם VPN gateway. כברירת מחדל, נתיבי ExpressRoute מועדפים על פני נתיבי VPN עבור אותם prefixes.

למה: Azure מעדיפה אוטומטית את ExpressRoute בשל משקל נתיב ברירת מחדל גבוה יותר. אם מעגל ה-ExpressRoute נכשל, BGP ימשוך את הנתיבים והתעבורה תעבור ל-VPN.

השפע על התעבורה להעדיף מעגל ExpressRoute אחד על פני אחר עבור יתירות active/passive.

→השתמש ב-BGP AS Path prepending. הוסף את ה-ASN שלך מספר פעמים לפרסומי הנתיבים במעגל הגיבוי כדי לגרום לנתיבו להיראות ארוך יותר.

למה: BGP מעדיף את ה-AS Path הקצר ביותר. זה הופך את המעגל הראשי לנתיב המועדף, עם failover אוטומטי לגיבוי אם הנתיב הראשי נמשך.

חבר שני אתרים מקומיים (on-premises) דרך רשת ה-backbone של Microsoft באמצעות מעגלי ExpressRoute הקיימים שלהם.

→אפשר ExpressRoute Global Reach.

למה: Global Reach מקשר שני מעגלי ExpressRoute יחד, מאפשר WAN פרטי מעל רשת Microsoft ללא צורך בתעבורה לעבור hairpin ב-Azure VNet.

פשט את הניהול של רשת גלובלית המחברת משרדי סניפים רבים ו-VNets.

→פרוס Azure Virtual WAN.

למה: Virtual WAN מספק שירות hub-and-spoke מנוהל עם קישוריות טרנזיטיבית אוטומטית any-to-any, ניתוב ושילוב עם שירותי אבטחה (secured hub).

מקור↗

ב-Virtual WAN, בדוק את כל התעבורה בין VNets, בין סניפים, והמיועדת לאינטרנט, באופן מרכזי.

→פרוס virtual hub מאובטח (עם Azure Firewall). הגדר routing intent לשליחת תעבורה פרטית ואינטרנט דרך ה-firewall.

למה: Routing intent מפשט את הנדסת התעבורה ב-vWAN, מתכנת אוטומטית נתיבים כדי לכפות תעבורה דרך ספק האבטחה ללא UDRs ידניים.

ספק חיבור VPN עמיד ל-Azure.

→פרוס VPN Gateway בתצורת active-active. זה דורש שני IPs ציבוריים והתקן on-prem המסוגל ליצור שתי מנהרות.

למה: מספק יתירות ברמת ה-instance בתוך אזור Azure. עבור יתירות בין-אזורית, השתמש ב-SKUs מסוג zone-redundant (AZ).

בחר פרוטוקול Point-to-Site VPN לתאימות לקוחות רחבה ללא תוכנה נוספת.

→השתמש ב-IKEv2. לתאימות מרבית כולל התקנים ישנים יותר, השתמש ב-OpenVPN.

למה: IKEv2 נתמך באופן מובנה במערכות Windows, macOS ו-iOS מודרניות. SSTP הוא Windows-only. OpenVPN דורש client אך נתמך באופן נרחב.

הפנה מחדש את כל התעבורה המיועדת לאינטרנט מ-Azure VMs למכשיר אבטחה מקומי (on-premises).

→מ-on-premises, פרסם default route (0.0.0.0/0) באמצעות BGP על גבי חיבור ExpressRoute או VPN.

למה: פרסום BGP זה עוקף את נתיב האינטרנט המוגדר כברירת מחדל של Azure, ומאלץ תעבורה לחזור לרשת המקומית (on-premises) לבדיקה.