Dela via

Tillämpa Nolltillit principer på en Azure Virtual WAN-distribution

  • Artikel

Med det moderna molnet, mobila enheter och andra slutpunkter är det inte längre tillräckligt att bara förlita sig på företagets brandväggar och perimeternätverk. En Nolltillit strategi från slutpunkt till slutpunkt förutsätter att säkerhetsöverträdelser är oundvikliga. Det innebär att du måste verifiera varje begäran som om den kommer från ett okontrollerat nätverk. Nätverk spelar fortfarande en viktig roll i Nolltillit för att ansluta och skydda infrastruktur, program och data. I den Nolltillit modellen finns det tre viktiga mål när det gäller att skydda dina nätverk:

  • Var redo att hantera attacker innan de inträffar.
  • Minimera skadans omfattning och hur snabbt den sprids.
  • Öka svårigheten att kompromettera ditt molnavtryck.

Azure Virtual WAN möjliggör en global transitnätverksarkitektur genom att aktivera allestädes närvarande, alla-till-alla-anslutningar mellan globalt distribuerade uppsättningar av molnarbetsbelastningar i virtuella nätverk (VNet), grenplatser, SaaS- och PaaS-program och användare. Det är viktigt att använda en Nolltillit metod i Azure Virtual WAN för att säkerställa att stamnätet är säkert och skyddat.

Den här artikeln innehåller steg för att tillämpa principerna för Nolltillit på en Azure Virtual WAN-distribution på följande sätt:

Nolltillit princip Definition Uppfylld av
Verifiera explicit Autentisera och auktorisera alltid baserat på alla tillgängliga datapunkter. Använd Azure Firewall med TLS-kontroll (Transport Layer Security) för att verifiera risker och hot baserat på alla tillgängliga data. Kontroller för villkorsstyrd åtkomst är avsedda att tillhandahålla autentisering och auktorisering av olika datapunkter och Azure Firewall utför inte användarautentisering.
Använd minst privilegierad åtkomst Begränsa användaråtkomst med JUST-In-Time och Just-Enough-Access (JIT/JEA), riskbaserade adaptiva principer och dataskydd. Användaråtkomst ligger utanför omfånget för distributioner av Azure-nätverksinfrastruktur. Genom att använda lösningar för identitetspelare som Privileged Access Management, villkorsstyrd åtkomst och andra kontroller kan du uppfylla den här principen.
Anta intrång Minimera explosionsradie och segmentåtkomst. Verifiera kryptering från slutpunkt till slutpunkt och använd analys för att få synlighet, driva hotidentifiering och förbättra skyddet. Varje virtuellt ekernätverk har ingen åtkomst till andra virtuella ekernätverk om inte trafiken dirigeras via brandväggen som är integrerad i varje Azure Virtual WAN-hubb. Brandväggen är inställd på att neka som standard, vilket endast tillåter trafik som tillåts av angivna regler. I händelse av en kompromiss eller överträdelse av ett program/en arbetsbelastning har den begränsad möjlighet att spridas på grund av att Azure Firewall utför trafikinspektion och endast vidarebefordrar tillåten trafik. Endast resurser i samma arbetsbelastning exponeras för intrånget i samma program.

Mer information om hur du tillämpar principerna för Nolltillit i en Azure IaaS-miljö finns i översikten Tillämpa Nolltillit principer för Azure-infrastruktur.

En branschdiskussion om Nolltillit finns i NIST Special Publication 800-207.

Azure Virtual WAN

Azure Virtual WAN är en nätverkstjänst som sammanför olika funktioner för nätverk, säkerhet och routning i ett enda driftsgränssnitt. Några av de viktigaste funktionerna är:

  • Avancerade routningsfunktioner
  • Säkerhet "bump-in-the-wire"-integrering via Azure Firewall eller nätverksbaserade virtuella installationer (NVA) i hubben
  • Krypterad ExpressRoute

En Nolltillit metod för Azure Virtual WAN kräver konfiguration av flera underliggande tjänster och komponenter från den Nolltillit principtabell som tidigare angavs. Här är en lista över steg och åtgärder:

  • Distribuera Azure Firewall eller NGFW-NVA:er (Next Generation Firewall) som stöds i varje Virtual WAN-hubb.
  • Konfigurera routning mellan virtuella nätverk och lokala grenar för att skapa en Nolltillit miljö genom att skicka all trafik till säkerhetsinstallationer i hubbarna för inspektion. Konfigurera routningen så att den ger filtrering och skydd för kända hot.
  • Se till att inga resurser i ekrarna har direkt åtkomst till Internet.
  • Tillhandahålla programmikrosegmentering i ekernätverk, tillsammans med en strategi för inkommande/utgående mikroperimeter.
  • Tillhandahålla observerbarhet för nätverkssäkerhetshändelser.

Referensarkitektur

Följande diagram visar en gemensam referensarkitektur som visar en vanlig distribuerad miljö och hur du tillämpar principerna för Nolltillit på Azure Virtual WAN.

Diagram över referensarkitekturen för Azure Virtual Desktop.

Azure Virtual WAN kan distribueras i typerna Basic och Standard. Att tillämpa Nolltillit principer för Azure Virtual WAN med Azure Firewall eller en NGFW kräver standardtypen.

Referensarkitekturen för Azure Virtual WAN med skyddade hubbar innehåller:

  • Ett enda logiskt virtuellt WAN.
  • Två skyddade virtuella hubbar, en per region.
  • En instans av Azure Firewall Premium som distribueras i varje hubb.
  • Minst en Azure Firewall Premium-princip.
  • Punkt-till-plats-gatewayer (P2S) och S2S-gatewayer (plats-till-plats).
  • P2S-, S2S- och ExpressRoute-anslutna grenar.
  • Ett virtuellt nätverk för delade tjänster som innehåller kärninfrastrukturresurser som inte kan distribueras till en Virtuell WAN-hubb, till exempel anpassade virtuella DNS-datorer eller Azure DNS Private Resolver, Active Directory-domän Services [AD DS] domänkontrollanter, Azure Bastion och andra delade resurser.
  • Arbetsbelastnings-VNet med Azure Application Gateway, Azure Web Application Firewall (WAF) och privata slutpunkter om det behövs.

Azure Virtual WAN stöder integrering av en begränsad uppsättning brandväggar från tredje part i hubbarna som ett alternativ till den inbyggda Azure Firewall. Den här artikeln beskriver endast Azure Firewall. Det som ingår i ekern VNet-Shared Services i referensarkitekturen är bara ett exempel på vad du kan distribuera. Microsoft hanterar Azure Virtual WAN-hubbar och du kan inte installera något annat i dem förutom vad Azure Firewall och nva:er som stöds uttryckligen tillåter.

Den här referensarkitekturen överensstämmer med de arkitekturprinciper som beskrivs i artikeln Cloud Adoption Framework för virtual WAN-nätverkstopologi.

Routningssäkerhet

Att skydda routningsspridning och isolering av lokal miljö är ett viktigt säkerhetselement som måste hanteras.

Förutom trafiksegmentering är routningssäkerhet en viktig del av alla nätverkssäkerhetsdesigner. Routningsprotokoll är en integrerad del av de flesta nätverk, inklusive Azure. Du måste skydda infrastrukturen från de inneboende riskerna med routningsprotokoll, till exempel felkonfigurationer eller skadliga attacker. BGP-protokollet som används för VPN eller ExpressRoute erbjuder mycket omfattande möjligheter att skydda nätverket mot oönskade routningsändringar, vilket kan inkludera annonsering av för specifika vägar eller för breda vägar.

Det bästa sättet att skydda nätverket är att konfigurera dina lokala enheter med lämpliga routningsprinciper och vägkartor för att se till att endast tillåtna prefix sprids till nätverket från Azure. Du kan till exempel:

  • Blockera inkommande prefix som är för generiska.

    Om Azure på grund av en felkonfiguration börjar skicka generiska prefix, till exempel 0.0.0.0/0 eller 10.0.0.0/8, kan det locka trafik som annars kan finnas kvar i det lokala nätverket.

  • Blockera inkommande prefix som är för specifika.

    Under vissa omständigheter kan du få några långa IPv4-prefix från Azure (nätverksprefixlängd 30 till 32), som vanligtvis ingår i andra mindre specifika prefix och därför inte krävs. Om du släpper de här prefixen förhindrar du att dina lokala routningstabeller blir onödigt stora.

  • Blockera inkommande prefix som inte finns i Azure om du inte använder Azure som ett transitnätverk.

    Om du inte använder Azure för att transportera trafik mellan dina lokala platser (till exempel med tekniker som ExpressRoute Global Reach) skulle ett lokalt prefix som annonseras från Azure indikera en routningsloop. Att bara ta Azure-prefix i dina lokala routrar skulle skydda dig från dessa typer av routningsloopar.

  • Blockera utgående prefix som inte är lokala.

    Om du inte använder ditt lokala nätverk för överföring mellan Azure-regioner bör du inte annonsera till Azure något prefix som du inte använder lokalt. Om du inte gör det riskerar du att skapa routningsloopar, särskilt med tanke på att eBGP-implementeringar i de flesta routrar annonserar om alla prefix på icke-föredragna länkar. Detta innebär att Azure-prefix skickas tillbaka till Azure om du inte har konfigurerat eBGP multi-path.

Logisk arkitektur

Azure Virtual WAN är en samling hubbar och tjänster som görs tillgängliga i en hubb. Du kan distribuera så många virtuella WAN:er som du behöver. I en Virtual WAN-hubb finns det flera tjänster som VPN, ExpressRoute, Azure Firewall eller en integrerad NVA från tredje part.

Följande diagram visar den logiska arkitekturen i Azure-infrastrukturen för en Azure Virtual WAN-distribution enligt beskrivningen i Cloud Adoption Framework.

Diagram över komponenterna i Azure Virtual WAN-topologi och Azure-prenumerationer.

Merparten av resurserna finns i anslutningsprenumerationen. Du distribuerar alla Virtual WAN-resurser till en enskild resursgrupp i anslutningsprenumerationen, inklusive när du distribuerar över flera regioner. Azure VNet-ekrar finns i prenumerationerna för landningszonen. Om du använder en azure firewall-princip för arv och hierarki måste den överordnade principen och den underordnade principen finnas i samma region. Du kan fortfarande tillämpa en princip som du skapade i en region på en skyddad hubb från en annan region.

Vad finns i den här artikeln?

Den här artikeln går igenom stegen för att tillämpa principerna för Nolltillit i Azure Virtual WAN-referensarkitekturen.

Steg Aktivitet Nolltillit principer som tillämpas
1 Skapa Azure Firewall-princip. Verifiera explicit
Anta intrång
2 Konvertera dina Azure Virtual WAN-hubbar till skyddade hubbar. Verifiera explicit
Anta intrång
3 Skydda trafiken. Verifiera explicit
Anta intrång
4 Skydda dina virtuella ekernätverk. Anta intrång
5 Granska din användning av kryptering. Anta intrång
6 Skydda dina P2S-användare. Anta intrång
7 Konfigurera övervakning, granskning och hantering. Anta intrång

Du måste utföra steg 1 och 2 i ordning. De andra stegen kan utföras i valfri ordning.

Steg 1: Skapa Azure Firewall-princip

För fristående Azure Firewall-distributioner i en klassisk hubb- och ekerarkitektur måste minst en Azure-princip skapas i Azure Firewall Manager och associeras med Azure Virtual WAN-hubbarna. Den här principen måste skapas och göras tillgänglig innan någon hubb konverteras. När principen har definierats tillämpas den på Azure Firewall-instanser i steg 2.

Azure Firewall-principer kan ordnas i en överordnad-underordnad hierarki. För antingen ett klassiskt hubb- och ekerscenario eller ett hanterat Azure Virtual WAN bör du definiera en rotprincip med en gemensam uppsättning IT-omfattande säkerhetsregler för att tillåta eller neka trafik. Sedan kan en underordnad princip definieras för varje hubb för att implementera hubbspecifika regler via arv. Steget är valfritt. Om regler som måste tillämpas på varje hubb är identiska kan en enda princip tillämpas.

För Nolltillit krävs en Premium Azure Firewall-princip och bör innehålla följande inställningar:

  • DNS-proxy – Du bör konfigurera Azure Firewall som en anpassad DNS-server för virtuella ekernätverk som skyddar den verkliga DNS som finns i en delad tjänsts eker eller lokalt. Azure-brandväggar fungerar som en DNS-proxy, lyssnar på UDP-port 53 och vidarebefordrar DNS-begäranden till de DNS-servrar som anges i principinställningarna. För varje eker måste du konfigurera en DNS-server på den virtuella nätverksnivå som pekar på den interna IP-adressen för Azure Firewall i Virtual WAN Hub. Du bör inte bevilja nätverksåtkomst från ekrar och grenar till anpassad DNS.

  • TLS-inspektion bör aktiveras för dessa scenarier:

    • Utgående TLS-inspektion för att skydda mot skadlig trafik som skickas från en intern klient som finns i Azure till Internet.

    • TLS-inspektion öst-väst för att inkludera trafik som går till eller från lokala grenar och mellan Virtual WAN-ekrar, vilket skyddar dina Azure-arbetsbelastningar från potentiell skadlig trafik som skickas inifrån Azure.

  • Intrångsidentifierings- och skyddssystem (IDPS) bör aktiveras i läget "Avisering och neka".

  • Hotinformation ska aktiveras i läget "Avisering och neka".

Som en del av skapandet av principen måste du skapa nödvändiga DNAT-regler (Destination Network Address Translation), nätverksregler och programregler för att endast aktivera nätverksflöden för explicit tillåten trafik. Om du vill aktivera TLS-inspektion för valda mål måste motsvarande programregel ha inställningen "TLS-inspektion" aktiverad. När du skapar regler i regelsamlingar bör du använda den mest restriktiva "Destination" och "Måltyp".

Steg 2: Konvertera dina Azure Virtual WAN-hubbar till skyddade hubbar

Kärnan i Nolltillit metod för Azure Virtual WAN är begreppet Säker Virtual WAN-hubb (säker hubb). En säker hubb är en Azure Virtual WAN-hubb med en integrerad Azure Firewall. Användning av säkerhetsinstallationer som stöds från tredje part stöds som ett alternativ till Azure Firewall, men beskrivs inte i den här artikeln. Du kan använda dessa virtuella installationer för att inspektera all trafik mellan nord och syd, öst och internet.

Vi rekommenderar Azure Firewall Premium för Nolltillit och att du konfigurerar det med premiumpolicyn som beskrivs i steg 1.

Kommentar

Användning av DDoS Protection stöds inte med en säker hubb.

Mer information finns i Installera Azure Firewall i en Virtual WAN-hubb.

Steg 3: Skydda trafiken

När du har uppgraderat alla dina Azure Virtual WAN-hubbar till säkra hubbar måste du konfigurera routningssyfte och principer för Nolltillit principer. Den här konfigurationen gör det möjligt för Azure Firewall i varje hubb att locka till sig och inspektera trafik mellan ekrar och grenar i samma hubb och mellan fjärrhubbar. Du bör konfigurera dina principer för att skicka både "Internettrafik" och "Privat trafik" via Azure Firewall eller din nva från tredje part). Alternativet "Inter-hub" måste också vara aktiverat. Här följer ett exempel.

Exempel på Azure Firewall-routningsprincipen.

När routningsprincipen "Privat trafik" är aktiverad vidarebefordras VNet-trafik in och ut från Virtual WAN Hub, inklusive trafik mellan hubbar, till nästa hopp i Azure Firewall eller NVA som angavs i principen. Användare med rbac-behörigheter (rollbaserad åtkomstkontroll) kan åsidosätta virtual WAN-vägprogrammering för virtuella ekernätverk och associera en anpassad användardefinierad väg (UDR) för att kringgå hubbens brandvägg. För att förhindra den här sårbarheten bör RBAC-behörigheter för att tilldela UDR till eker-VNet-undernät begränsas till centrala nätverksadministratörer och inte delegeras till ägare av landningszoner för de virtuella ekernätverken. Om du vill associera en UDR med ett virtuellt nätverk eller undernät måste en användare ha rollen Nätverksdeltagare eller en anpassad roll med åtgärden "Microsoft.Network/routeTables/join/action" eller behörighet.

Kommentar

I den här artikeln beaktas Azure Firewall främst för både Internettrafik och privat trafikkontroll. För Internettrafik kan en tredje part, säkerhets-NVA som stöds, användas eller en tredjepartsleverantör av säkerhet som en tjänst (SECaaS). För privat trafik kan säkerhets-NVA:er från tredje part användas som ett alternativ till Azure Firewall.

Kommentar

Anpassade routningstabeller i Azure Virtual WAN kan inte användas tillsammans med routnings avsikt och principer och bör inte betraktas som ett säkerhetsalternativ.

Steg 4: Skydda dina virtuella ekernätverk

Varje Azure Virtual WAN-hubb kan ha ett eller flera virtuella nätverk anslutna med VNet-peering. Baserat på landningszonmodellen i Cloud Adoption Framework innehåller varje virtuellt nätverk en arbetsbelastning, program och tjänster för landningszoner som stöder en organisation. Azure Virtual WAN hanterar anslutningen, vägspridningen och associationen samt utgående och inkommande routning, men kan inte påverka säkerheten inom det virtuella nätverket. Nolltillit principer måste tillämpas i varje virtuellt ekernätverk enligt de riktlinjer som publiceras i Tillämpa Nolltillit principer på ett virtuellt ekernätverk och andra artiklar beroende på resurstyp, till exempel virtuella datorer och lagring. Tänk på följande element:

Eftersom hubben i Azure Virtual WAN är låst och hanteras av Azure kan anpassade komponenter inte installeras eller aktiveras där. Vissa resurser som normalt distribueras i hubben, i en klassisk hubb- och ekermodell, måste placeras i en eller flera ekrar som fungerar som delade resursnätverk. Till exempel:

  • Azure Bastion:Azure Bastion stöder Azure Virtual WAN men måste distribueras i ett virtuellt ekernätverk eftersom hubben är begränsad och hanteras av Azure. Från Azure Bastion-ekern kan användarna nå resurser i andra virtuella nätverk, men kräver IP-baserad anslutning som är tillgänglig med Azure Bastion Standard SKU.
  • Anpassade DNS-servrar: DNS-serverprogramvara kan installeras på valfri virtuell dator och fungera som DNS-server för alla ekrar i Azure Virtual WAN. DNS-servern måste vara installerad i ett eker-VNet som hanterar alla andra ekrar direkt, eller via dns-proxyfunktionen som erbjuds av Azure Firewall som är integrerad i Virtual WAN-hubben.
  • Azure Privat DNS Resolver: Distribution av en Azure Privat DNS Resolver stöds i ett av de virtuella ekernätverk som är anslutna till Virtual WAN-hubbar. Azure Firewall som är integrerad i Virtual WAN-hubben kan använda den här resursen som en anpassad DNS när du aktiverar FUNKTIONEN DNS-proxy.
  • Privata slutpunkter: Den här resurstypen är kompatibel med Virtual WAN men måste distribueras i ett virtuellt ekernätverk. Detta ger anslutning till andra virtuella nätverk eller grenar som är anslutna till samma Virtual WAN, om den integrerade Azure Firewall tillåter flödet. Instruktioner om hur du skyddar trafik till privata slutpunkter med azure-brandväggen som är integrerad i en Virtual WAN-hubb finns i Säker trafik som är avsedd för privata slutpunkter i Azure Virtual WAN.
  • Azure Privat DNS Zone (länkar): Den här typen av resurs finns inte i ett virtuellt nätverk utan måste länkas till dem för att fungera korrekt. Privat DNS zoner kan inte länkas till Virtual WAN-hubbar. I stället bör de anslutas till det virtuella ekernätverket som innehåller anpassade DNS-servrar eller en Azure Privat DNS Resolver (rekommenderas) eller direkt till de virtuella ekernätverk som kräver DNS-poster från den zonen.

Steg 5: Granska krypteringen

Azure Virtual WAN tillhandahåller vissa funktioner för trafikkryptering via sina egna gatewayer för trafik som kommer in i Microsoft-nätverket. När det är möjligt bör kryptering aktiveras baserat på gatewaytypen. Överväg följande standardkrypteringsbeteende:

  • Virtual WAN S2S VPN-gateway tillhandahåller kryptering när du använder IPsec/IKE-anslutning (IKEv1 och IKEv2).

  • Virtual WAN P2S VPN-gateway tillhandahåller kryptering när du använder vpn-anslutning via OpenVPN eller IPsec/IKE (IKEv2).

  • Virtual WAN ExpressRoute-gatewayen tillhandahåller inte kryptering, därför gäller samma överväganden från fristående ExpressRoute.

    • Endast för ExpressRoute-kretsar som etableras ovanpå ExpressRoute Direct är det möjligt att använda MACsec-kryptering som tillhandahålls av plattformen för att skydda anslutningarna mellan dina gränsroutrar och Microsofts gränsroutrar.

    • Kryptering kan upprättas med hjälp av en IPsec/IKE VPN-anslutning från ditt lokala nätverk till Azure via den privata peeringen för en Azure ExpressRoute-krets. Avsikt och principer för routning stöder nu den här konfigurationen med ytterligare konfigurationssteg som krävs, enligt beskrivningen i Encrypted ExpressRoute.

  • För SD-WAN-enheter (Software Defined WAN) från tredje part och NVA:er som är integrerade i Virtual WAN-hubben måste specifika krypteringsfunktioner verifieras och konfigureras enligt leverantörens dokumentation.

När trafiken har gått in i Azure-nätverksinfrastrukturen via en av gatewayerna eller en SD-WAN/NVA finns det ingen specifik Virtual WAN-tjänst eller kapacitet som tillhandahåller nätverkskryptering. Om trafiken mellan en hubb och dess virtuella nätverk och hub-to-hub är okrypterad måste du använda kryptering på programnivå om det behövs.

Kommentar

Virtual WAN-ekrar stöder inte VNet-till-VNet-kryptering med Hjälp av Azure VPN Gateway eftersom en eker krävs för att använda fjärrgatewayen för Virtual WAN Hub.

Steg 6: Skydda dina P2S-användare

Azure Virtual WAN är en nätverkstjänst som sammanför olika funktioner för nätverk, säkerhet och routning i ett enda driftsgränssnitt. Ur ett användaridentitetsperspektiv finns den enda pekpunkten med Virtual WAN i den autentiseringsmetod som används för att tillåta en användares P2S VPN. Det finns flera tillgängliga autentiseringsmetoder, men vi rekommenderar att du följer allmänna Nolltillit principer för Microsoft Entra-autentisering. Med Microsoft Entra-ID kan du kräva multifaktorautentisering (MFA) och villkorlig åtkomst tillämpa Nolltillit principer för klientenheter och användaridentiteter.

Kommentar

Microsoft Entra-autentisering är endast tillgängligt för gatewayer som använder OpenVPN-protokollet, som endast stöds för OpenVPN-protokollanslutningar och kräver Azure VPN-klienten.

Azure Virtual WAN och Azure Firewall tillhandahåller inte trafikroutning och filtrering baserat på användarkonto- eller gruppnamn, men det är möjligt att tilldela olika grupper av användare olika pooler med IP-adresser. Du kan sedan definiera regler i den integrerade Azure Firewall för att begränsa användare eller grupper baserat på deras tilldelade P2S IP-adresspool.

Om du delar upp dina P2S-användare i olika grupper baserat på kraven för nätverksåtkomst rekommenderar vi att du särskiljer dem på nätverksnivå och ser till att de bara kan komma åt en delmängd av det interna nätverket. Du kan skapa flera IP-adresspooler för Azure Virtual WAN. Mer information finns i Konfigurera användargrupper och IP-adresspooler för virtuella P2S-användare.

Steg 7: Konfigurera övervakning, granskning och hantering

Azure Virtual WAN tillhandahåller omfattande övervaknings- och diagnostikfunktioner med Azure Monitor. Ytterligare information och topologi kan hämtas med hjälp av en fokuserad, fördefinierad övervakningsinstrumentpanel i Azure-portalen med namnet Azure Monitor Insights for Virtual WAN. Dessa övervakningsverktyg är inte säkerhetsspecifika. Azure Firewall som distribueras i varje Virtual WAN-hubb tillhandahåller integreringspunkten för Nolltillit och säkerhetsövervakning. Du måste konfigurera diagnostik och loggning för Azure Firewall på samma sätt som Azure Firewalls utanför Virtual WAN.

Azure Firewall innehåller följande övervakningsverktyg som du bör använda för att säkerställa säkerhet och korrekt tillämpning av Nolltillit principer:

  • Azure Firewall Policy Analytics ger insikter, centraliserad synlighet och kontroll över Azure Firewall. Säkerhet kräver att rätt brandväggsregler är på plats och effektiva för att skydda den interna infrastrukturen. Azure-portalen sammanfattar information om "potentiella skadliga källor" som genereras av IDPS- och hotinformationsfunktioner för brandväggsmotorn.

  • Azure Firewall-arbetsboken ger en flexibel arbetsyta för dataanalys i Azure Firewall. Du kan få insikter om Azure Firewall-händelser, lära dig mer om ditt program och nätverksregler och se statistik för brandväggsaktiviteter mellan URL:er, portar och adresser. Vi rekommenderar starkt att du regelbundet granskar IDPS-loggstatistiken och på fliken Undersökningar kontrollerar du nekad trafik, käll- och målflöden och rapporten Hotinformation för att granska och optimera brandväggsregler.

Azure Firewall integreras också med Microsoft Defender för molnet och Microsoft Sentinel. Vi rekommenderar starkt att du konfigurerar båda verktygen korrekt och aktivt använder dem för Nolltillit på följande sätt:

  • Med Microsoft Defender för molnet integrering kan du visualisera all-up-statusen för nätverksinfrastruktur och nätverkssäkerhet på ett och samma ställe, inklusive Azure Network Security i alla virtuella nätverk och virtuella hubbar spridda över olika regioner i Azure. Med en enda blick kan du se antalet Azure-brandväggar, brandväggsprinciper och Azure-regioner där Azure Firewalls distribueras.
  • En Microsoft Sentinel-lösning för sömlös Azure Firewall-integrering ger hotidentifiering och skydd. När lösningen har distribuerats tillåter den inbyggd anpassningsbar hotidentifiering ovanpå Microsoft Sentinel. Lösningen innehåller även en arbetsbok, identifieringar, jaktfrågor och spelböcker.

Utbildning för administratörer

Följande utbildningsmoduler hjälper ditt team med de kunskaper som krävs för att tillämpa Nolltillit principer för din Azure Virtual WAN-distribution.

Introduktion till Azure Virtual WAN

Utbildning Introduktion till Azure Virtual WAN
Beskriv hur du konstruerar ett wan-nätverk (Wide Area Network) med programvarudefinierade Azure Virtual WAN-nätverkstjänster.

Börja >

Introduktion till Azure Firewall

Utbildning Introduktion till Azure Firewall
Beskriv hur Azure Firewall skyddar azure vnet-resurser, inklusive Azure Firewall-funktioner, regler, distributionsalternativ och administration med Azure Firewall Manager.

Börja >

Introduktion till Azure Firewall Manager

Utbildning Introduktion till Azure Firewall Manager
Beskriv om du kan använda Azure Firewall Manager för att tillhandahålla central säkerhetsprincip och routningshantering för dina molnbaserade säkerhetsperimeter. Utvärdera om Azure Firewall Manager kan skydda dina molnperimeter.

Börja >

Utforma och implementera nätverkssäkerhet

Utbildning Utforma och implementera nätverkssäkerhet
Du lär dig att utforma och implementera nätverkssäkerhetslösningar som Azure DDoS, Nätverkssäkerhetsgrupper, Azure Firewall och Brandvägg för webbprogram.

Börja >

Mer utbildning om säkerhet i Azure finns i dessa resurser i Microsoft-katalogen:
Säkerhet i Azure

Nästa steg

Se de här ytterligare artiklarna om hur du tillämpar Nolltillit principer på Azure:

Referenser

Se de här länkarna om du vill veta mer om de olika tjänster och tekniker som nämns i den här artikeln.

Azure Virtual WAN

Säkerhetsbaslinjer

Granskning av välarkitekterat ramverk

Azure-säkerhet

Tekniska illustrationer

Du kan ladda ned illustrationerna som används i den här artikeln. Använd Visio-filen för att ändra dessa illustrationer för eget bruk.

PDF | Visio

Klicka här om du vill ha fler tekniska illustrationer.