Privétoepassingsgateway-implementatie

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:

• Privé-IP-adres alleen frontend-IP-configuratie
  • 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.

Onboarden naar de functie

De functionaliteit van de nieuwe besturingselementen van configuratie van privé-IP-front-end, controle over NSG-regels en controle over routetabellen, zijn algemeen beschikbaar en ondersteund in productie. Als u de functies wilt gebruiken, moet u zich aanmelden voor de ervaring met behulp van Azure Portal, PowerShell, CLI of REST API.

Bij registratie worden alle nieuwe Application Gateways ingericht met de mogelijkheid om een combinatie van de NSG-, routetabel- of privé-IP-configuratiefuncties te definiëren. Als u zich wilt afmelden voor de nieuwe functionaliteit, kunt u dit doen door de registratie van de functie ongedaan te maken.

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 u de functie hebt geregistreerd, kan de configuratie van NSG, routetabel en de front-endconfiguratie voor privé-IP-adressen worden uitgevoerd met behulp van elke methode. Bijvoorbeeld: REST API, ARM-sjabloon, Bicep-implementatie, Terraform, PowerShell, CLI of Portal.

Application Gateway subnet

Application Gateway-subnet is het subnet in het virtuele netwerk waar de Application Gateway-resources worden geïmplementeerd. In de front-end-privé-IP-configuratie is het belangrijk dat dit subnet privé de resources kan bereiken die verbinding willen maken met uw blootgestelde app of site.

Uitgaande internetconnectiviteit

Application Gateway-implementaties die alleen een privé-front-end-IP-configuratie bevatten (en geen openbare IP-front-endconfiguratie die gekoppeld is aan een regel voor aanvraagroutering) kunnen geen uitgaand verkeer naar het internet sturen. 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

Netwerkbeveiligingsgroepen die zijn gekoppeld aan een Application Gateway-subnet vereisen geen binnenkomende regels meer voor GatewayManager en ze hebben geen uitgaande toegang tot 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

In het huidige aanbod van Application Gateway wordt de koppeling van een routetabel met een regel (of het maken van een regel) gedefinieerd als 0.0.0.0/0 met een volgende hop, omdat het virtuele apparaat niet wordt ondersteund om het juiste beheer van Application Gateway te garanderen.

Na de registratie van de functie is de mogelijkheid om verkeer door te sturen naar een virtueel apparaat nu mogelijk via de definitie van een routetabelregel die 0.0.0.0/0 definieert met een volgende hop naar virtueel apparaat.

Geforceerde tunneling of leren van 0.0.0.0/0 route via BGP-reclame heeft geen invloed op de status van Application Gateway en wordt gehonoreerd voor de verkeersstroom. Dit scenario kan van toepassing zijn wanneer u VPN, ExpressRoute, Route Server of Virtual WAN gebruikt.

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

Private Link-configuratie-ondersteuning voor het tunnelen van verkeer via privé-eindpunten naar Application Gateway wordt niet ondersteund met een alleen privé-gateway.

WAF-snelheidsbeperking

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

Privé-IP-front-endconfiguratie alleen met AGIC

AGIC v1.7 moet worden gebruikt om alleen ondersteuning voor privé-front-end-IP te introduceren.

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 zijn gemaakt vóór en na het inschakelen van de verbeterde functionaliteit voor netwerkbeheer, is de functionaliteit netwerkbeveiligingsgroep (NSG) en routetabel beperkt tot de vorige gatewayimplementatie. Toepassingsgateways die zijn ingericht voordat de nieuwe functionaliteit wordt ingeschakeld, moeten opnieuw worden ingericht of nieuwe gateways moeten een ander subnet gebruiken om verbeterde functies voor netwerkbeveiligingsgroepen en routetabellen in te schakelen.

• Als een gateway die is geïmplementeerd voordat de nieuwe functionaliteit wordt ingeschakeld, aanwezig is in het subnet, ziet u mogelijk fouten 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 vermeldingen in de routetabel.
• 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.