Azure Firewall en verkeersinspectie

Azure Firewall is een beheerde, cloudeigen netwerkbeveiligingsservice die gecentraliseerde verkeersinspectie en filtering biedt voor uw Azure virtuele netwerken. In tegenstelling tot netwerkbeveiligingsgroepen die op Laag 4 werken, controleert Azure Firewall verkeer op laag 3 tot en met 7. Met deze mogelijkheid kunt u FQDN-filtering (Fully Qualified Domain Name), bedreigingsinformatie, inbraakdetectie en -preventie (IDPS) en TLS-inspectie inschakelen. U implementeert Azure Firewall in een toegewezen subnet in uw virtuele hubnetwerk en stuurt verkeer van spoke-workloads door via de firewall voor inspectie voordat het de bestemming bereikt.

In dit artikel wordt uitgelegd hoe u de juiste Azure Firewall SKU kiest, de firewall in een hub-spoke-topologie plaatst, regeltypen configureert en de firewall integreert met aanvullende services zoals NAT Gateway en Route Server. Azure Firewall is een van de drie kernnetwerkbeveiligingsdiensten van Azure, naast Azure DDoS Protection en Azure Web Application Firewall.

Wat in dit artikel wordt behandeld

Dit artikel behandelt gecentraliseerde netwerkverkeersinspectie met behulp van Azure Firewall. U krijgt meer informatie over:

  • Selectie van SKU-lagen op basis van beveiligingsvereisten en gevoeligheid van workloads.
  • UDR-patronen (Plaatsing van hubs en door de gebruiker gedefinieerde route) die verkeer via de firewall afdwingen.
  • Regelverwerkingslogica voor DNAT-, netwerk- en toepassingsregels.
  • Geforceerde tunneling voor omgevingen waarvoor on-premises inspectie is vereist.
  • TLS-inspectie- en IDPS-mogelijkheden in de Premium-laag.
  • Integratie met NAT Gateway voor het schalen van SNAT-poorten en routeserver voor routering op basis van BGP.

Wie heeft dit artikel nodig

Implementeer Azure Firewall wanneer uw workloads een of meer van de volgende mogelijkheden nodig hebben:

  • Gecentraliseerde controle over uitgaand verkeer: u moet beperken welke externe FQDN's en URL's uw workloads kunnen bereiken, naast wat NSG-regels op basis van IP-adressen bieden.
  • Oost-west-inspectie: Verkeer tussen virtuele spoke-netwerken moet via een statusbewust inspectiepunt lopen voordat de firewall dit verkeer toestaat.
  • Logboekregistratie met nalevingsmandaat: voor regelgevingsframeworks is volledige zichtbaarheid van laag 7 in toegestane en geweigerde verbindingen met granulariteit op FQDN-niveau vereist.
  • Bedreigingsbeveiliging: u hebt op handtekeningen gebaseerde inbraakdetectie en -preventie nodig om schadelijke verkeerspatronen te identificeren, waaronder callbacks voor opdrachten en controle, aanvallen en zijdelingse verplaatsing.
  • TLS-inspectie: U moet versleuteld verkeer (HTTPS) ontsleutelen en op bedreigingen inspecteren voordat het workloads bereikt of het netwerk verlaat.

Organisaties die alleen laag 4-pakketfiltering nodig hebben zonder FQDN-bewustzijn, moeten NSG's en ASG's beschouwen als een eenvoudiger alternatief voor lagere kosten.

Lift-and-shiftfocus: Vertaal uw on-premises firewallregelset naar Azure Firewall-beleid. Begin met netwerkregels voor niet-HTTP/S-verkeer en toepassingsregels voor filteren op basis van FQDN. Begin met een breed beleid voor toestaan tijdens de migratie en verstreng de regels nadat u Azure Firewall logboeken hebt bekeken.

Focus moderniseren: Gebruik Azure Firewall als het gecentraliseerde SNAT- en DNAT-punt in de hub. Inspecteer verkeer tussen application spokes en tussen spokes en internet, gebruik toepassingsregels en FQDN-tags voor AKS en Azure PaaS uitgaand verkeer en plan TLS-inspectie waarbij toepassingslagen gevoelige verkeer uitwisselen.

Focus op meerdere clouds: Implementeer Azure Firewall in een beveiligde virtuele hub om verkeer tussen cloudovergangen te inspecteren. Configureer netwerkregels voor IPSec-tunnelverkeer van AWS of Google Cloud en gebruik IDPS om te kijken naar afwijkende verkeerspatronen tussen verbonden clouds.

Azure Firewall SKU-niveaus

Azure Firewall is beschikbaar in drie SKU-lagen. Elke laag bouwt voort op de mogelijkheden van de vorige laag.

Vermogen Basic Standard Premium
Pakketinspectie met statuscontrole ✔ ✔ ✔
FQDN-filtering (uitgaand) ✔ ✔ ✔
Netwerkregels (IP, poort, protocol) ✔ ✔ ✔
Toepassingsregels (FQDN, URL) ✔ ✔ ✔
NAT-regels (DNAT) ✔ ✔ ✔
Filteren van bedreigingsinformatie Alleen waarschuwing ✔ (Waarschuwen + weigeren) ✔ (Waarschuwen + weigeren)
DNS-proxy ✗ ✔ ✔
Webcategorieën ✗ ✔ ✔
IDPS (inbraakdetectie en -preventie) ✗ ✗ ✔
Inspectie van TLS ✗ ✗ ✔
URL-filtering (volledig pad) ✗ ✗ ✔
Expliciete proxy ✗ ✔ ✔
Beschikbaarheid van de regio Beperkte beschikbaarheid in sommige regio's Alle regio's Alle regio's
Ideaal voor Dev/test, kleine werkbelastingen Standaardproductie Hoge beveiliging, nalevingsgestuurd

Uw SKU kiezen

Gebruik de volgende beslissingscriteria:

  • Kies Basic wanneer u ontwikkel-/testomgevingen of kleine workloads hebt waarvoor uitgaand verkeer op basis van FQDN moet worden gefilterd zonder filtering van bedreigingsinformatie (modus weigeren) of geavanceerde inspectie. De Basic-SKU bevat dreigingsinformatie in de modus Alleen waarschuwingen, maar biedt geen ondersteuning voor de blokkeringsmodus, DNS-proxy of webcategorieën. Basic SKU vereist een toegewezen AzureFirewallManagementSubnet (/26 minimum) naast de AzureFirewallSubnet en is beschikbaar in beperkte regio's.
  • Kies Standard voor productieworkloads waarvoor filteren op basis van bedreigingsinformatie, DNS-proxy voor FQDN-regelomzetting, filteren van webcategorie en gecentraliseerd beleidsbeheer via Azure Firewall Manager nodig is. Standard biedt de volledige engine voor statusbewuste inspectie met dreigingsinformatiefeeds waarmee verbindingen met bekende kwaadaardige IP-adressen en domeinen worden geblokkeerd.
  • Kies Premium wanneer wettelijke of beveiligingsvereisten tls-inspectie van versleuteld verkeer verplicht stellen, idPS op basis van handtekeningen met voortdurend bijgewerkte regels (meer dan 67.000 handtekeningen in meer dan 50 categorieën, in realtime bijgewerkt) of volledige URL-padfiltering buiten FQDN. Premium is vereist voor branches zoals financiële diensten, gezondheidszorg en overheid, waarbij versleutelde verkeersinspectie verplicht is.

Note

Voer een upgrade uit van Standard naar Premium zonder de firewall opnieuw te implementeren. Voor het downgraden van Premium naar Standard is opnieuw implementeren vereist.

Hubplaatsing en UDR-routeringspatroon

Implementeer Azure Firewall in een toegewezen subnet dat exact AzureFirewallSubnet binnen het virtuele hubnetwerk wordt genoemd. Voor dit subnet is een minimale grootte van /26 (59 bruikbare IP-adressen) vereist.

Routeringsarchitectuur

Diagram van een hub-spoke-topologie waarbij verkeer van spoke-subnetten via Azure Firewall in het virtuele netwerk van de hub wordt gerouteerd voordat het het internet of andere spokes bereikt.

In een hub-spoke-topologie routeren workloadsubnetten van spokes geen verkeer rechtstreeks naar het internet of naar andere spokes. In plaats daarvan stellen UDR's in elk spoke-subnet de standaardroute (0.0.0.0/0) in op het Azure Firewall privé-IP-adres. Dit patroon zorgt ervoor dat al het verkeer, zowel noord-zuid (internetgebonden) als oost-west (spoke-to-spoke), doorloopt de firewall voor inspectie.

UDR-configuratiepatroon:

Routingtabel (toegepast op) Adresvoorvoegsel Het volgende hoptype Adres van de volgende hop
Spoke-subnetwerk A 0.0.0.0/0 Virtueel apparaat Privé-IP-adres van firewall
Spoke-subnetwerk A 10.1.0.0/16 (andere spoke) Virtueel apparaat Privé-IP-adres van firewall
Spaaksubnet B 0.0.0.0/0 Virtueel apparaat Privé-IP-adres van firewall
Spaaksubnet B 10.0.0.0/16 (andere spoke) Virtueel apparaat Privé-IP-adres van firewall

De AzureFirewallSubnet firewall zelf vereist in de meeste scenario's geen UDR's omdat de firewall systeemroutes gebruikt om spokennetwerken via virtuele netwerkpeering te bereiken. Wanneer u integreert met Azure Route Server, leert het firewallsubnet routes via BGP. Met deze aanpak hoeft u geen handmatig routeonderhoud meer te maken naarmate uw netwerk groeit.

Tip

Azure Virtual Network Manager kunt de configuratie van routetabellen automatiseren om Azure Firewall te gebruiken als de volgende hop, waardoor handmatig UDR-beheer voor veel spoke-abonnementen wordt verminderd.

Subnetvereisten

Subnet Minimale grootte Purpose Aantekeningen
AzureFirewallSubnet /26 Bevat Azure Firewall-instanties Moet exact AzureFirewallSubnet worden genoemd
AzureFirewallManagementSubnet /26 Beheerverkeer (alleen basis-SKU) Vereist voor de Basic-SKU; optioneel voor gedwongen tunneling in andere SKU’s

Zie Hub-spoke-topologie voor meer informatie over het ontwerpen en plannen van subnetten voor hubs.

Regeltypen en verwerkingslogica

Azure Firewall verwerkt regels via Azure Firewall Beleid. Regels zijn ingedeeld in regelverzamelingen, die zijn gegroepeerd in regelverzamelingsgroepen. De firewall evalueert regels in de volgende prioriteitsvolgorde:

  1. DNAT-regels (Destination Network Address Translation): eerst verwerkt. Vertaal inkomend verkeer van een openbaar IP-adres naar een privé-IP achter de firewall.
  2. Netwerkregels: Als tweede verwerkt. Verkeer toestaan of weigeren op basis van bron-IP, doel-IP, poort en protocol (laag 3/4).
  3. Toepassingsregels: Laatst verwerkt. Uitgaand verkeer toestaan of weigeren op basis van FQDN, URL of webcategorie (laag 7).

Binnen elk regeltype worden regelverzamelingsgroepen geëvalueerd op prioriteit (laagste getal = hoogste prioriteit). Binnen een groep worden regelverzamelingen geëvalueerd op basis van prioriteit. De eerste overeenkomende regel bepaalt de actie (Toestaan of Weigeren) en stopt verdere evaluatie.

DNAT-regels

Gebruik DNAT-regels om interne services te publiceren via het openbare IP-adres van de firewall. De firewall vertaalt het doeladres van het openbare IP-adres naar het privé-IP-adres van de back-endservice. Veelvoorkomende scenario's zijn onder andere:

  • Een interne webserver beschikbaar maken via het openbare IP-adres van de firewall op poort 443
  • Gecontroleerde RDP- of SSH-toegang tot een jumpbox bieden zonder een openbaar IP-adres toe te wijzen aan de VIRTUELE machine
  • Niet-HTTP/S-services publiceren waarvoor binnenkomende toegang via internet is vereist
Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

DNAT-regels voegen impliciet een overeenkomstige netwerkregel toe waarmee het vertaalde verkeer wordt toegestaan. Zodra een DNAT-regel overeenkomt, wordt het verkeer omgezet en toegestaan zonder verdere verwerking van netwerkregels. Beperk voor beveiliging het BRON-IP-adres in uw DNAT-regels tot specifieke internetbronnen in plaats van jokertekens te gebruiken.

Netwerkregels

Netwerkregels filteren verkeer op Laag 3 en Laag 4. Gebruik netwerkregels wanneer u verkeer wilt toestaan of weigeren op basis van bron-IP-adres, doel-IP-adres, doelpoort en protocol. Netwerkregels voeren geen FQDN-omzetting uit. Ze werken strikt op IP-adressen. Veelvoorkomende gebruiksvoorbeelden zijn:

  • Toestaan van spoke-to-spoke-communicatie voor specifieke poorten (bijvoorbeeld SQL Server op TCP 1433).
  • NTP (UDP 123) toestaan voor specifieke tijdservers.
  • Verkeer naar bekende schadelijke IP-bereiken blokkeren met behulp van regels voor weigeren.
  • ICMP toestaan voor netwerkdiagnose tussen specifieke subnetten.

Netwerkregels ondersteunen TCP-, UDP-, ICMP- en Any-protocoltypen. U kunt IP-adressen, IP-bereiken, servicetags en IP-groepen opgeven als bron en doel.

Toepassingsregels

Toepassingsregels filteren uitgaand HTTP/S- en MSSQL-verkeer op basis van FQDN's, URL's en webcategorieën. Regels voor toepassingen vereisen de DNS-proxyfunctie voor de omzetting van FQDN's. Toepassingsregels gebruiken wanneer:

  • U moet toegang verlenen tot specifieke FQDN's (bijvoorbeeld *.microsoft.com of storage.blob.core.windows.net).
  • U wilt filteren op het URL-pad (alleen Premium SKU), zoals het toestaan van github.com/myorg/* maar andere GitHub-paden blokkeren.
  • U moet volledige webcategorieën toestaan of blokkeren (bijvoorbeeld 'Ontwikkelhulpprogramma's' toestaan en 'Gokken' blokkeren).

Toepassingsregels bieden FQDN-tags voor algemene Azure-services (zoals Windows Update, Azure Backup en HDInsight) die het maken van regels vereenvoudigen door de vereiste FQDN's in één tag te groeperen.

Important

Wanneer u de DNS-proxy inschakelt op Azure Firewall, fungeert de firewall als de DNS-resolver voor workloads. Stel je virtuele netwerk DNS-instellingen zo in dat ze wijzen op het privé-IP van de firewall, zodat FQDN-gebaseerde regels correct worden opgelost. Zie DNS-beveiliging en privénaamomzetting voor meer informatie over DE DNS-architectuur.

SNAT-gedrag

Standaard past Azure Firewall SNAT (Source Network Address Translation) toe op uitgaand verkeer dat bestemd is voor openbare IP-adressen. De firewall maakt geen SNAT-verkeer wanneer de bestemming een privé-IP-bereik (RFC 1918) of gedeelde adresruimte (RFC 6598) is. De firewall vertaalt het bron-IP-adres van internetverbindingen naar een van de openbare IP-adressen. Elk openbaar IP-adres biedt 2496 SNAT-poorten per back-endinstantie.

Voor workloads met hoge uitgaande verbindingssnelheden kunt u integreren met NAT Gateway om te schalen naar 64.512 poorten per openbaar IP-adres (maximaal 16 openbare IP-adressen, totaal ongeveer één miljoen SNAT-poorten).

Wanneer u nat-gateway koppelt aan de AzureFirewallSubnetgateway, gebruikt al het uitgaande internetverkeer automatisch de openbare IP-adressen van de NAT-gateway. De firewall blijft verkeer inspecteren, maar NAT Gateway verwerkt de SNAT-vertaling. Er treedt geen dubbele NAT op.

Note

NAT-gateway met zone-redundante Azure Firewall vereist StandardV2 NAT-gateway-SKU. NAT Gateway wordt niet ondersteund in Virtual WAN beveiligde hubarchitecturen.

Overname van firewallbeheer en beleid

Azure Firewall Manager biedt gecentraliseerd beveiligingsbeleid en routebeheer voor meerdere Azure Firewall exemplaren. Tot de belangrijkste mogelijkheden behoren:

  • Beleidshiërarchie: Maak een basisbeleid (bovenliggend) met regels voor de hele organisatie en laat onderliggende teams onderliggende beleidsregels maken die overnemen van het bovenliggende beleid. Bovenliggende regels hebben altijd voorrang, ongeacht waarden voor onderliggende prioriteit.
  • Beheer tussen regio's: een firewallbeleid is een globale resource die u kunt koppelen aan firewalls in elke regio of elk abonnement.
  • Governance voor meerdere firewalls: een consistente beveiligingspostuur toepassen op hubfirewalls in verschillende regio's of op beveiligde Virtual WAN hubs.

NAT-regels zijn specifiek voor de firewall en worden niet overgenomen van bovenliggende beleidsregels. De modus voor bedreigingsinformatie wordt overgenomen, maar kan in onderliggende beleidsregels alleen worden opgeheven met een strengere modus. Een beleid met nul of één firewallkoppeling is gratis inbegrepen. Aanvullende koppelingen brengen kosten met zich mee.

Geforceerde tunneling

In sommige regelgevende omgevingen moet al het naar internet bestemde verkeer eerst via een on-premises inspectiepunt worden geleid voordat het het internet bereikt. Azure Firewall ondersteunt geforceerde tunneling om aan deze vereiste te voldoen.

Wanneer u geforceerde tunneling inschakelt:

  • Het AzureFirewallManagementSubnet leidt het firewallbeheerverkeer rechtstreeks naar het internet. Dit subnet moet een route hebben naar 0.0.0.0/0 met volgende hop Internet. U kunt beheerverkeer niet dwingen via on-premises-inspectie.
  • De AzureFirewallSubnet leidt internetgericht workloadverkeer naar een on-premises firewall of een virtueel netwerkapparaat (NVA) van derden via ExpressRoute of VPN Gateway.
  • DNAT-regels worden niet ondersteund in de modus voor geforceerde tunneling, omdat binnenkomend verkeer het openbare IP-adres van de firewall niet rechtstreeks kan bereiken.
  • De firewall heeft geen openbaar IP-adres nodig op de AzureFirewallSubnet wanneer u geforceerde tunneling configureert, omdat al het uitgaande verkeer via het on-premises pad verloopt.

Gebruik geforceerde tunneling wanneer nalevingsmandaten on-premises zichtbaarheid van al het internetverkeer vereisen of wanneer u Azure Firewall moet koppelen aan een bestaande on-premises beveiligingsstack. Veelvoorkomende scenario's zijn omgevingen voor financiële dienstverlening die onderhevig zijn aan regelgeving voor gegevenslocatie en overheidsnetwerken met gecentraliseerde internetonderbrekingsvereisten.

Important

In de modus voor geforceerde tunneling heeft het AzureFirewallManagementSubnet een eigen openbaar IP-adres nodig en een UDR met 0.0.0.0/0, waarbij internet als volgende hop is opgegeven. Deze configuratie zorgt ervoor dat Azure het beheerkanaal naar de firewall kan houden.

TLS-controle (Premium)

Azure Firewall Premium uitgaande HTTPS-verbindingen onderschept, het verkeer ontsleutelt, inspecteert het verkeer op basis van IDPS-handtekeningen en toepassingsregels en versleutelt het vervolgens opnieuw en stuurt het door. Voor dit proces is een tussenliggend CA-certificaat vereist dat is opgeslagen in Azure Key Vault.

Certificaatvereisten

Requirement Specificatie
Certificaattype Intermediaire CA
Sleutelgrootte RSA minimaal 2048 bits
CA-vlag TRUE
Sleutelgebruik KeyCertSign
Geldigheid Ten minste één jaar vooruit
Storage Azure Key Vault (moet kunnen worden geëxporteerd)

De firewall gebruikt het tussenliggende CA-certificaat om servercertificaten dynamisch te genereren voor onderschepte verbindingen. Browsers en toepassingen van eindgebruikers moeten de basis-CA of tussenliggende CA van de organisatie in hun certificaatarchief vertrouwen om vertrouwenswaarschuwingen te voorkomen.

Indringingsdetectie- en preventiesysteem (IDPS)

De Premium-SKU bevat een volledig beheerde IDPS-engine met meer dan 67.000 regels voor meer dan 50 categorieën. Handtekeningen worden continu bijgewerkt met 20-40 nieuwe regels die dagelijks worden uitgebracht. IDPS werkt in twee modi:

  • Waarschuwingsmodus: Ondertekening van logboeken komt overeen zonder verkeer te blokkeren. Gebruik tijdens de eerste implementatie en afstemming.
  • Waarschuwings- en weigeringsmodus: hiermee wordt verkeer geregistreerd en geblokkeerd dat overeenkomt met IDPS-handtekeningen. Gebruik in productie na het afstemmen.

IDPS-categorieën hebben betrekking op malware command-and-control, phishing, trojans, botnets, exploit kits, kwetsbaarheden en SCADA/ICS protocollen.

Caution

TLS-inspectie introduceert latentie en heeft gevolgen voor privacy. Zorg ervoor dat de juridische en nalevingsteams van uw organisatie de inspectie van versleuteld verkeer goedkeuren. Sluit gevoelige categorieën (gezondheidszorg, banken) indien nodig uit met behulp van bypassregels.

Filteren van uitgaand AKS-verkeer

Wanneer Azure Kubernetes Service (AKS) clusters gecontroleerde uitgaande verbindingen vereisen, biedt Azure Firewall uitgaande FQDN-filtering voor clusterknooppunten. Zonder uitgaande filtering kunnen AKS-knooppunten elk interneteindpunt bereiken, waardoor het aanvalsoppervlak voor supply chain- en gegevensexfiltratieaanvallen toeneemt.

Ga als volgt te werk om dit patroon te implementeren:

  1. Implementeer AKS met outboundType ingesteld op userDefinedRouting en een aangepaste routetabel in het subnet van het knooppunt.
  2. Stel de standaardroute (0.0.0.0/0) in op het Azure Firewall privé-IP-adres.
  3. Maak toepassingsregels in het firewallbeleid waarmee de vereiste AKS-FQDN's (containerregisters, API-servereindpunten, Microsoft pakketopslagplaatsen) zijn toegestaan.
  4. Netwerkregels maken voor vereiste niet-HTTP/S-eindpunten (NTP, DNS, tunnelconnectiviteit).

Dit patroon geeft beveiligingsteams inzicht in en controle over welke externe eindpunten AKS-knooppunten kunnen bereiken, terwijl het cluster correct kan functioneren. De vereiste FQDN’s variëren per AKS-functionaliteit. Clusters die gebruikmaken van GPU-knooppunten, Azure Monitor of Azure Policy vereisen extra vermeldingen op de goedgekeurde lijst.

Zie Azure Firewall gebruiken om AKS-implementaties te beveiligen voor gedetailleerde FQDN-vereisten en regelvoorbeelden.

Note

Voor uitgaande AKS-filtering met Azure Firewall is een zorgvuldige coördinatie tussen platform- en toepassingsteams vereist. Ontbrekende FQDN-regels veroorzaken fouten bij het inplannen van pods en bij het ophalen van containerimages. Begin met een ruim beleid en verstreng het nadat u verkeerspatronen in de firewalllogboeken hebt waargenomen.

Ontwerpoverwegingen

Focus op het ontwerp van lift-and-shift-firewalls

  • On-premises firewallregels omzetten in Azure Firewall beleid: netwerkregels gebruiken voor niet-HTTP/S-protocollen en toepassingsregels voor HTTP/S- of MSSQL-bestemmingen waarvoor FQDN-filtering is vereist.
  • Begin met algemene regels voor toestaan die uw huidige beveiligingspostuur weerspiegelen, en draai deze na de migratie aan met behulp van Azure Firewall logboeken om de vereiste bestemmingen en poorten te identificeren.
  • Gebruik IP-groepen om bron- en doelzones te modelleren, zodat regelonderhoud uw bestaande segmentatiegrenzen volgt.
  • Schakel diagnostische instellingen op dag één in, zodat u Azure verkeerspatronen kunt vergelijken met uw on-premises basislijn voordat u de toegang beperkt.

Focus op het ontwerpen van firewalls moderniseren

  • Gebruik de hubfirewall als het gecentraliseerde SNAT- en DNAT-punt voor application spokes, zodat het beleid voor inkomend en uitgaand verkeer in de door IT beheerde hub blijft.
  • Schakel Azure Firewall Premium in wanneer TLS-inspectie van oost-westverkeer of IDPS-afdwinging in productieomgevingen is vereist tussen toepassingslagen.
  • Gebruik FQDN-tags en toepassingsregels om AKS- en Azure PaaS-afhankelijkheden toe te staan zonder grote IP-adressenlijsten van bestemmingen te onderhouden.
  • Stem de DNAT-vereisten af op het ontwerp van uw Front Door of Application Gateway, zodat inkomend verkeer de back-endspokes alleen via goedgekeurde inspectieroutes bereikt.

Ontwerpfocus voor firewalls tussen clouds

  • Implementeer Azure Firewall in een beveiligde virtuele hub wanneer Azure het transitpunt is voor vertakkingen, Azure en andere cloudnetwerken.
  • Gebruik netwerkregels om IPSec-tunnelverkeer van AWS Transit Gateway, virtuele privégateways van AWS of Google Cloud VPN-bijlagen te inspecteren nadat routes binnenkomen in Azure.
  • Schakel IDPS in om afwijkende oost-west- en cross-cloudverkeerspatronen te detecteren die kunnen duiden op laterale verplaatsing tussen cloudomgevingen.
  • Schakel het filteren van bedreigingsinformatie in om bekende schadelijke bestemmingen in alle verbonden clouds te blokkeren met één beleidsoppervlak.

Prerequisites

Voordat u Azure Firewall implementeert:

  • AzureFirewallSubnet: uw virtuele hubnetwerk moet een toegewezen subnet AzureFirewallSubnet met een minimale grootte /26 bevatten. Zie Het ontwerp van het virtuele netwerk en het subnet voor richtlijnen voor subnetplanning.
  • Hub-spoke- of Virtual WAN-topologie: Implementeer Azure Firewall in een centrale hub waarmee verkeer van spoke-netwerken wordt gerouteerd. Zie hub-spoke-topologie of Virtual WAN voor topologieopties.
  • IP-adresplan: Gereserveerde adresruimte voor het firewallsubnet, beheersubnet (als gebruik wordt gemaakt van geforceerde tunneling) en openbare IP-adressen. Zie planning van IP-adressen.
  • Azure Firewall Manager: gebruik Azure Firewall Manager als u een beleidshiërarchie nodig hebt die basisregels deelt voor meerdere firewall-exemplaren.
  • Log Analytics werkruimte: maak vóór de implementatie een werkruimte voor diagnostische logboeken voor firewalls, zodat u verkeer kunt bewaken en problemen met regels vanaf dag één kunt oplossen.

Beveiligingsoverwegingen

  • Logboekregistratie: schakel diagnostische instellingen in om Azure Firewall logboeken naar een Log Analytics werkruimte te verzenden. Gestructureerde logboeken bieden inzicht op FQDN-niveau in elke toegestane en geweigerde verbinding, ondersteunende audit- en forensische analyse.
  • Beschikbaarheid: Implementeer Azure Firewall in beschikbaarheidszones om de SLA voor beschikbaarheid te maximaliseren. Zie SLA voor Azure Firewall voor huidige SLA-percentages.
  • Gelaagde verdediging: Azure Firewall complementeert, maar vervangt geen NSG's. NSG's toepassen op subnet- en NIC-niveau voor microsegmentatie. Gebruik de firewall voor gecentraliseerd beleid, bedreigingsinformatie en laag 7-inspectie.
  • Stem af wat u inspecteert: Al het verkeer via de firewall leiden, inclusief lagen binnen een toepassing, zoals van web naar app en van app naar database, voegt latentie en verwerkingskosten per gigabyte toe. Gebruik NSG's en ASG's voor oost-west-verkeer tussen vertrouwde lagen en reserveer firewallinspectie voor verkeer dat een vertrouwensgrens overschrijdt: internetgebonden, cross-spoke, hybride of cross-cloud. Deze aanpak houdt de firewall gericht op het verkeer dat profiteert van inspectie en onnodige kosten voorkomt.
  • DDoS-beveiliging: beveilig openbare IP-adressen die zijn gekoppeld aan Azure Firewall met behulp van Azure DDoS Protection. Zie DDoS-beveiliging.
  • ExpressRoute-verkeer: wanneer u ExpressRoute gebruikt, configureert u UDR's om privé-peeringverkeer via Azure Firewall te leiden voor inspectie van hybride verkeersstromen.

Meer informatie

Volgende stappen 

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Bewaking instellen voor uw gemigreerde netwerk: connectiviteit en prestaties valideren met Network Watcher nadat u uw firewall hebt geconfigureerd.

Vervolgens in uw moderniseringstraject:

Beveilig uw webtoepassingen met WAF: voeg Web Application Firewall toe aan Front Door of Application Gateway voor uw klantgerichte web-apps.

De volgende stap in uw cross-cloudtraject:

Cross-cloudmonitoring instellen: Cross-cloudomgevingen zijn operationeel lastiger om problemen in op te sporen. Bewaking is essentieel, niet optioneel.

  • Last updated on