Implementatie van privé-applicatiegateway

Introduction

In het verleden hebben Application Gateway v2-SKU's en in zekere mate v1 openbare IP-adressen nodig om het beheer van de service mogelijk te maken. Deze vereiste heeft verschillende beperkingen opgelegd bij het gebruik van verfijnde besturingselementen in netwerkbeveiligingsgroepen en routetabellen. In het bijzonder zijn de volgende uitdagingen waargenomen:

• Alle implementaties van Application Gateways v2 moeten openbare front-end-IP-configuratie bevatten om communicatie met de Gateway Manager-servicetag mogelijk te maken.
• Netwerkbeveiligingsgroepkoppelingen vereisen regels om binnenkomende toegang vanuit GatewayManager en uitgaande toegang tot internet toe te staan.
• Wanneer u een standaardroute (0.0.0.0/0) introduceert om verkeer naar ergens anders dan het internet te sturen, resulteren de metriek, bewaking en updates van de gateway in een mislukte status.

Application Gateway v2 kan nu elk van deze items aanpakken om het risico van gegevensexfiltratie en het beheer van de privacy van communicatie vanuit het virtuele netwerk verder te elimineren. Deze wijzigingen omvatten de volgende mogelijkheden:

• Frontend-IP-configuratie alleen voor privégebruik
  • Er is geen openbare IP-adresresource vereist
• Het verwijderen van inkomend verkeer van gatewayManager-servicetag via netwerkbeveiligingsgroep
• Mogelijkheid om een 'Alles weigeren'-regel te definiëren voor de uitgaande Netwerkbeveiligingsgroep (NSG) om uitgaand verkeer naar het internet te beperken.
• Mogelijkheid om de standaardroute naar internet te overschrijven (0.0.0.0/0)
• DNS-omzetting via gedefinieerde resolvers op het virtuele netwerk, inclusief privé-DNS-zones van Private Link Meer informatie.

Elk van deze functies kan onafhankelijk worden geconfigureerd. Een openbaar IP-adres kan bijvoorbeeld worden gebruikt om binnenkomend verkeer vanaf internet toe te staan, en u kunt een 'Alles Weigeren' uitgangsregel definiëren in de configuratie van de netwerkbeveiligingsgroep om gegevensexfiltratie te voorkomen.

Inwerken op de functionaliteit

Dit artikel behandelt de private Application Gateway-implementatie voor Application Gateway v2 SKU's. Het ondersteunt twee implementatiemodi: een private-only frontend IP-configuratie en een gecombineerde configuratie die zowel een publieke als een private frontend IP-configuratie gebruikt. De besturingselementen voor private frontend IP-configuratie, netwerkbeveiligingsgroep (NSG) regelbeheer en routetabelconfiguratie zijn over het algemeen beschikbaar en worden in productie ondersteund.

Om deze mogelijkheden te gebruiken, moet je je aanmelden voor de ervaring via het Azure-portaal, PowerShell, CLI of REST API. Dit opt-in-mechanisme biedt ook flexibiliteit als je indien nodig terug moet schakelen naar traditionele Application Gateway-functionaliteit (bijvoorbeeld om Private Link in te schakelen).

De functie registreren

Register-AzProviderFeature -FeatureName "EnableApplicationGatewayNetworkIsolation" -ProviderNamespace "Microsoft.Network"

FeatureName                                ProviderName        RegistrationState
-----------                                ------------        -----------------
EnableApplicationGatewayNetworkIsolation   Microsoft.Network   Registered

az feature register --name EnableApplicationGatewayNetworkIsolation --namespace Microsoft.Network

Name                                                        RegistrationState
----------------------------------------------------------  -------------------
Microsoft.Network/EnableApplicationGatewayNetworkIsolation  Registered

Registratie van de functie ongedaan maken

Unregister-AzProviderFeature -FeatureName "EnableApplicationGatewayNetworkIsolation" -ProviderNamespace "Microsoft.Network"

FeatureName                                ProviderName        RegistrationState
-----------                                ------------        -----------------
EnableApplicationGatewayNetworkIsolation   Microsoft.Network   Unregistered

az feature unregister --name EnableApplicationGatewayNetworkIsolation --namespace Microsoft.Network

Name                                                        RegistrationState
----------------------------------------------------------  -------------------
Microsoft.Network/EnableApplicationGatewayNetworkIsolation  Unregistered

Configuratie van netwerkbesturingselementen

Nadat je de functie hebt geregistreerd, kun je de NSG, routetabel en private frontend IP-configuratie configureren voor een private Application Gateway-implementatie met behulp van welke methode dan ook. Gebruik bijvoorbeeld REST API, ARM-template, Bicep-deployment, Terraform, PowerShell, CLI of het Azure-portaal.

Application Gateway subnet

Het Application Gateway-subnet is het subnet binnen het virtuele netwerk waar je de Application Gateway-resources uitrolt. In een private Application Gateway-implementatie die een private-only frontend IP-configuratie gebruikt, moet dit subnet privé de bronnen bereiken die willen verbinden met je blootgestelde app of site.

Uitgaande internetconnectiviteit

Bij een private Application Gateway-implementatie kunnen Application Gateway v2-implementaties die een private-only frontend IP-configuratie gebruiken (ze hebben geen publieke IP-frontendconfiguratie gekoppeld aan een request routing-regel) geen uitgaande verkeer naar het internet leiden. Deze configuratie is van invloed op de communicatie met back-enddoelen die openbaar toegankelijk zijn via internet.

Als u uitgaande connectiviteit van uw Toepassingsgateway naar een internetgericht back-enddoel wilt inschakelen, kunt u Virtual Network NAT gebruiken of verkeer doorsturen naar een virtueel apparaat dat toegang heeft tot internet.

Virtual Network NAT biedt controle over welk IP-adres of voorvoegsel moet worden gebruikt, evenals configureerbare time-out voor inactiviteit. Als u wilt configureren, maakt u een nieuwe NAT-gateway met een openbaar IP-adres of openbaar voorvoegsel en koppelt u deze aan het subnet met Application Gateway.

Als een virtueel apparaat vereist is voor uitgaand internetverkeer, raadpleegt u de sectie met routetabelbeheer in dit document.

Veelvoorkomende scenario's waarbij openbaar IP-gebruik is vereist:

• Communicatie met key vault zonder gebruik van privé-eindpunten of service-eindpunten
  • Uitgaande communicatie is niet vereist voor pfx-bestanden die rechtstreeks naar Application Gateway zijn geüpload
• Communicatie naar backend-doelwitten via de Internet
• Communicatie naar CRL- of OCSP-eindpunten die extern toegankelijk zijn via het internet

Netwerkbeveiligingsgroepsbeheer

Deze sectie beschrijft de beheer van de netwerkbeveiligingsgroep (NSG) voor het Application Gateway v2-subnet in een private Application Gateway-implementatie. Nadat je de functie hebt geregistreerd, hebben netwerkbeveiligingsgroepen die aan een Application Gateway-subnet zijn gekoppeld geen inkomende regels meer nodig voor GatewayManager, en ze hebben geen uitgaande toegang tot het internet nodig. De enige vereiste regel is Inkomend verkeer van AzureLoadBalancer toestaan om ervoor te zorgen dat statustests de gateway kunnen bereiken.

De volgende configuratie is een voorbeeld van de meest beperkende set regels voor inkomend verkeer, waarbij al het verkeer wordt geweigerd, behalve Azure-gezondheidscontroles. Naast de gedefinieerde regels worden expliciete regels gedefinieerd zodat clientverkeer de listener van de gateway kan bereiken.

Voorbeeldscenario

In dit voorbeeld wordt stapsgewijs uitgelegd hoe u een NSG maakt met behulp van Azure Portal met de volgende regels:

• Inkomend verkeer naar poort 80 en 8080 naar Application Gateway toestaan vanaf clientaanvragen die afkomstig zijn van internet
• Al het andere binnenkomende verkeer weigeren
• Uitgaand verkeer naar een back-enddoel in een ander virtueel netwerk toestaan
• Uitgaand verkeer naar een back-enddoel toestaan dat toegankelijk is voor internet
• Al het andere uitgaande verkeer weigeren

Maak eerst een netwerkbeveiligingsgroep. Deze beveiligingsgroep bevat uw regels voor inkomend en uitgaand verkeer.

Regels voor inkomend verkeer

In de beveiligingsgroep zijn al drie standaardregels voor inkomend verkeer ingericht. Zie het volgende voorbeeld:

Maak vervolgens de volgende vier nieuwe beveiligingsregels voor inkomend verkeer:

• Binnenkomende poort 80, tcp, vanaf internet toestaan (iedereen)
• Binnenkomende poort 8080, tcp, vanaf internet toestaan (any)
• Inkomend verkeer vanuit AzureLoadBalancer toestaan
• Binnenkomende verbindingen weigeren

Ga als volgt te werk om deze regels te maken:

• Binnenkomende beveiligingsregels selecteren
• Selecteer Toevoegen
• Voer de volgende informatie voor elke regel in het deelvenster Binnenkomende beveiligingsregels toevoegen in.
• Wanneer u de gegevens hebt ingevoerd, selecteert u Toevoegen om de regel te maken.
• Het maken van elke regel duurt even.

Selecteer Vernieuwen om alle regels te controleren wanneer het inrichten is voltooid.

Uitgaande regels

Er zijn al drie standaardregels voor uitgaand verkeer met prioriteit 65000, 65001 en 65500 ingericht.

Maak de volgende drie nieuwe uitgaande beveiligingsregels:

• TCP 443 toestaan van 10.10.4.0/24 naar backenddoel 203.0.113.1
• TCP 80 van bron 10.10.4.0/24 naar bestemming 10.13.0.4 toestaan
• DenyAll-verkeersregel

Aan deze regels wordt respectievelijk een prioriteit van 400, 401 en 4096 toegewezen.

Ga als volgt te werk om deze regels te maken:

• Selecteer de uitgaande beveiligingsregels
• Selecteer Toevoegen
• Voer de volgende informatie voor elke regel in het deelvenster Uitgaande beveiligingsregels toevoegen in.
• Wanneer u de gegevens hebt ingevoerd, selecteert u Toevoegen om de regel te maken.
• Het maken van elke regel duurt even.

Selecteer Vernieuwen om alle regels te controleren wanneer het inrichten is voltooid.

NSG koppelen aan het subnet

De laatste stap is het koppelen van de netwerkbeveiligingsgroep aan het subnet dat uw Application Gateway bevat.

Result:

Controle van de routetabel

Deze sectie beschrijft de routetabel (door de gebruiker gedefinieerde route) controle voor het Application Gateway v2-subnet in een private Application Gateway-deployment. Voor Application Gateway-implementaties die niet geregistreerd zijn voor de private Application Gateway-implementatiefunctie, kun je bij de volgende hop geen routetabel die een 0.0.0.0/0 route bevat koppelen aan een virtueel apparaat. Deze beperking zorgt voor een goed beheer van de Application Gateway.

Nadat je de functie hebt geregistreerd, kun je verkeer doorsturen naar een virtueel apparaat door een 0.0.0.0/0 route te definiëren met een virtuele appliance bij de volgende hop.

Voorbeeldscenario

In het volgende voorbeeld maken we een routetabel en koppelen we deze aan het Application Gateway-subnet om ervoor te zorgen dat de uitgaande internettoegang vanuit het subnet via een virtueel apparaat verloopt. Op hoog niveau wordt het volgende ontwerp samengevat in afbeelding 1:

• Application Gateway bevindt zich in het virtuele spoke-netwerk
• Er is een virtueel netwerkapparaat (een virtuele machine) in het hubnetwerk
• Een routetabel met een standaardroute (0.0.0.0/0) naar het virtuele apparaat is gekoppeld aan het Application Gateway-subnet

Afbeelding 1: Internettoegang-uitgang via virtueel apparaat

Een routetabel maken en deze koppelen aan het Application Gateway-subnet:

1. Een routetabel maken:

2. Selecteer Routes en maak de volgende hopregel voor 0.0.0.0/0 en configureer de bestemming als het IP-adres van uw VIRTUELE machine:

3. Selecteer Subnetten en koppel de routetabel aan het Application Gateway-subnet:

4. Controleer of verkeer wordt doorgegeven via het virtuele apparaat.

Beperkingen/bekende problemen

De volgende beperkingen zijn van toepassing:

Configuratie van Private Link

Application Gateway ondersteunt geen private link-configuratie voor het tunnelen van verkeer door private endpoints wanneer je een private-only frontend IP-configuratie gebruikt.

WAF-snelheidsbeperking

Frequentiebeperking voor aangepaste regels voor Application Gateway WAF v2 wordt momenteel niet ondersteund.

Privé-IP-front-endconfiguratie alleen met AGIC

Je moet AGIC v1.7 gebruiken om een private-only frontend IP-configuratie te configureren.

Privé-eindpuntconnectiviteit via globale VNet-peering

Als Application Gateway een back-enddoel of sleutelkluisverwijzing heeft naar een privé-eindpunt in een VNet dat toegankelijk is via globale VNet-peering, wordt verkeer verwijderd, wat resulteert in een slechte status.

Network Watcher-integratie

Het oplossen van verbindingsproblemen en NSG-diagnostieken geven een fout bij het uitvoeren van controles en diagnostische tests.

Bestaande v2 Application Gateways die zijn gemaakt vóór het inschakelen van verbeterde netwerkbeheer

Als een subnet Application Gateway v2-implementaties deelt die je zowel vóór als na het inschakelen van de private Application Gateway-implementatiefunctie hebt aangemaakt, kun je Network Security Group (NSG) en Route Table-functionaliteit alleen gebruiken bij de eerdere gateway-implementatie. Om de netwerkbeveiligingsgroep en routeringstabellen in te schakelen, moet je ofwel applicatiegateways die je hebt gemaakt vóór het inschakelen van de functie opnieuw provisioneren, of nieuwe gateways aanmaken in een ander subnet.

• Als een gateway die je hebt uitgerold voordat je de functie inschakelde in het subnet bestaat, kun je fouten zien zoals: For routes associated to subnet containing Application Gateway V2, please ensure '0.0.0.0/0' uses Next Hop Type as 'Internet' bij het toevoegen van routetabel-invoeren.
• Wanneer u regels voor netwerkbeveiligingsgroepen toevoegt aan het subnet, ziet u mogelijk het volgende: Failed to create security rule 'DenyAnyCustomAnyOutbound'. Error: Network security group \<NSG-name\> blocks outgoing Internet traffic on subnet \<AppGWSubnetId\>, associated with Application Gateway \<AppGWResourceId\>. This isn't permitted for Application Gateways that have fast update enabled or have V2 Sku.

Volgende stappen

• Zie de Azure-beveiligingsbasislijn voor Application Gateway voor meer aanbevolen beveiligingsprocedures.