Azure-services integreren met virtuele netwerken voor netwerkisolatie
Dankzij de integratie van een virtueel netwerk voor een Azure-service kunt u de toegang tot de service vergrendelen tot alleen uw virtuele netwerkinfrastructuur. De infrastructuur van het virtuele netwerk omvat ook gekoppelde virtuele netwerken en on-premises netwerken.
Integratie van virtuele netwerken biedt Azure-services de voordelen van netwerkisolatie met een of meer van de volgende methoden:
Toegewezen exemplaren van de service implementeren in een virtueel netwerk. De services kunnen vervolgens worden geopend in het virtuele netwerk en vanuit on-premises netwerken.
Met behulp van een privé-eindpunt waarmee u privé en veilig verbinding maakt met een service die wordt mogelijk gemaakt door Azure Private Link. Private Endpoint maakt gebruik van een privé-IP-adres van uw virtuele netwerk, waarbij de service effectief in uw virtuele netwerk wordt geplaatst.
Toegang tot de service met behulp van openbare eindpunten door een virtueel netwerk uit te breiden naar de service, via service-eindpunten. Met service-eindpunten kunnen serviceresources worden beveiligd naar het virtuele netwerk.
Servicetags gebruiken om verkeer naar uw Azure-resources naar en van openbare IP-eindpunten toe te staan of te weigeren.
Toegewezen Azure-services implementeren in virtuele netwerken
Wanneer u toegewezen Azure-services in een virtueel netwerk implementeert, kunt u privé communiceren met de servicebronnen via privé-IP-adressen.
Het implementeren van een toegewezen Azure-service in uw virtuele netwerk biedt de volgende mogelijkheden:
Resources binnen het virtuele netwerk kunnen privé met elkaar communiceren via privé-IP-adressen. Bijvoorbeeld het rechtstreeks overdragen van gegevens tussen HDInsight en SQL Server die worden uitgevoerd op een virtuele machine, in het virtuele netwerk.
On-premises resources hebben toegang tot resources in een virtueel netwerk met behulp van privé-IP-adressen via een site-naar-site-VPN (VPN Gateway) of ExpressRoute.
Virtuele netwerken kunnen worden gekoppeld zodat resources in de virtuele netwerken met elkaar kunnen communiceren met behulp van privé-IP-adressen.
De Azure-service beheert service-exemplaren volledig in een virtueel netwerk. Dit beheer omvat het bewaken van de status van de resources en het schalen met belasting.
Service-exemplaren worden geïmplementeerd in een subnet in een virtueel netwerk. Binnenkomende en uitgaande netwerktoegang voor het subnet moeten worden geopend via netwerkbeveiligingsgroepen, volgens de richtlijnen van de service.
Bepaalde services leggen beperkingen op voor het subnet waarin ze worden geïmplementeerd. Deze beperkingen beperken de toepassing van beleidsregels, routes of het combineren van VM's en servicebronnen binnen hetzelfde subnet. Controleer bij elke service op de specifieke beperkingen, omdat deze na verloop van tijd kunnen worden gewijzigd. Voorbeelden van dergelijke services zijn Azure NetApp Files, Toegewezen HSM, Azure Container Instances, App Service.
Optioneel is voor services mogelijk een gedelegeerd subnet vereist als een expliciete id die een subnet kan hosten voor een bepaalde service. Azure-services hebben expliciete machtigingen voor het maken van servicespecifieke resources in het gedelegeerde subnet met delegatie.
Bekijk een voorbeeld van een REST API-antwoord op een virtueel netwerk met een gedelegeerd subnet. Een uitgebreide lijst met services die gebruikmaken van het gedelegeerde subnetmodel, kan worden verkregen via de API voor beschikbare delegaties.
Zie Toegewezen Azure-services implementeren in virtuele netwerken voor een lijst met services die in een virtueel netwerk kunnen worden geïmplementeerd.
Private Link en privé-eindpunten
Met privé-eindpunten is inkomend verkeer van uw virtuele netwerk naar een Azure-resource veilig toegestaan. Deze privékoppeling wordt tot stand gebracht zonder dat er openbare IP-adressen nodig zijn. Een privé-eindpunt is een speciale netwerkinterface voor een Azure-service in uw virtuele netwerk. Wanneer u een privé-eindpunt voor uw resource maakt, biedt het beveiligde connectiviteit tussen clients in uw virtuele netwerk en uw Azure-resource. Aan het privé-eindpunt wordt een IP-adres toegewezen uit het IP-adresbereik van uw virtuele netwerk. De verbinding tussen het privé-eindpunt en de Azure-service is een privékoppeling.
In het diagram ziet u aan de rechterkant een Azure SQL Database als doel-PaaS-service. Het doel kan elke service zijn die ondersteuning biedt voor privé-eindpunten. Er zijn meerdere exemplaren van de logische SQL Server voor meerdere klanten, die allemaal bereikbaar zijn via openbare IP-adressen.
In dit geval wordt één exemplaar van een logische SQL Server weergegeven met een privé-eindpunt. Het eindpunt maakt de SQL Server bereikbaar via een privé-IP-adres in het virtuele netwerk van de client. Vanwege de wijziging in de DNS-configuratie verzendt de clienttoepassing nu het verkeer rechtstreeks naar dat privé-eindpunt. De doelservice ziet verkeer dat afkomstig is van een privé-IP-adres van het virtuele netwerk.
De groene pijl vertegenwoordigt een privékoppeling. Er kan nog steeds een openbaar IP-adres bestaan voor de doelresource naast het privé-eindpunt. Het openbare IP-adres wordt niet meer gebruikt door de clienttoepassing. De firewall kan nu geen toegang meer verlenen voor dat openbare IP-adres, waardoor deze alleen toegankelijk is via privé-eindpunten. Verbindingen met een SQL-server zonder een privé-eindpunt van het virtuele netwerk zijn afkomstig van een openbaar IP-adres. De blauwe pijl vertegenwoordigt deze stroom.
De clienttoepassing gebruikt doorgaans een DNS-hostnaam om de doelservice te bereiken. Er zijn geen wijzigingen nodig voor de toepassing. DNS-omzetting in het virtuele netwerk moet zo worden geconfigureerd dat dezelfde hostnaam wordt omgezet in het privé-IP-adres van de doelresource in plaats van het oorspronkelijke openbare IP-adres. Met een privépad tussen de client en de doelservice is de client niet afhankelijk van het openbare IP-adres. De doelservice kan openbare toegang uitschakelen.
Door deze blootstelling van afzonderlijke exemplaren kunt u diefstal van gegevens voorkomen. Een kwaadwillende actor kan geen gegevens uit de database verzamelen en uploaden naar een andere openbare database of een ander opslagaccount. U kunt toegang tot de openbare IP-adressen van alle PaaS-services voorkomen. U kunt nog steeds toegang tot PaaS-exemplaren toestaan via hun privé-eindpunten.
Zie Wat is Private Link?voor meer informatie over Private Link en de lijst met ondersteunde Azure-services.
Service-eindpunten
Service-eindpunten bieden beveiligde en directe connectiviteit met Azure-services via het Backbone-netwerk van Azure. Met eindpunten kunt u uw Azure-resources alleen naar uw virtuele netwerken beveiligen. Met service-eindpunten kunnen privé-IP-adressen in het virtuele netwerk een Azure-service bereiken zonder dat er een uitgaand openbaar IP-adres nodig is.
Zonder service-eindpunten kan het lastig zijn om de toegang tot alleen uw virtuele netwerk te beperken. Het bron-IP-adres kan worden gewijzigd of gedeeld met andere klanten. Bijvoorbeeld PaaS-services met gedeelde uitgaande IP-adressen. Met service-eindpunten wordt het bron-IP-adres dat de doelservice ziet een privé-IP-adres van uw virtuele netwerk. Deze wijziging van inkomend verkeer maakt het gemakkelijk om de oorsprong te identificeren en te gebruiken voor het configureren van de juiste firewallregels. U kunt bijvoorbeeld alleen verkeer van een specifiek subnet binnen dat virtuele netwerk toestaan.
Met service-eindpunten blijven DNS-vermeldingen voor Azure-services ongewijzigd en blijven ze omzetten in openbare IP-adressen die zijn toegewezen aan de Azure-service.
In het volgende diagram is de rechterkant dezelfde PaaS-doelservice. Aan de linkerkant bevindt zich een virtueel klantnetwerk met twee subnetten: Subnet A met een service-eindpunt richting Microsoft.Sql
en Subnet B, waarvoor geen service-eindpunten zijn gedefinieerd.
Wanneer een resource in Subnet B probeert een SQL Server te bereiken, wordt er een openbaar IP-adres gebruikt voor uitgaande communicatie. De blauwe pijl vertegenwoordigt dit verkeer. De SQL Server-firewall moet dat openbare IP-adres gebruiken om het netwerkverkeer toe te staan of te blokkeren.
Wanneer een resource in subnet A probeert een databaseserver te bereiken, wordt deze gezien als een privé-IP-adres vanuit het virtuele netwerk. De groene pijlen vertegenwoordigen dit verkeer. De SQL Server-firewall kan subnet A nu specifiek toestaan of blokkeren. Kennis van het openbare IP-adres van de bronservice is niet nodig.
Service-eindpunten zijn van toepassing op alle exemplaren van de doelservice. Bijvoorbeeld alle SQL Server-exemplaren van Azure-klanten, niet alleen het exemplaar van de klant.
Zie Service-eindpunten voor virtuele netwerken voor meer informatie
Servicetags
Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Met servicetags kunt u besturingselementen voor netwerktoegang definiëren voor netwerkbeveiligingsgroepen of Azure Firewall. U kunt het verkeer voor de service toestaan of weigeren. Als u het verkeer wilt toestaan of weigeren, geeft u de servicetag op in het bron- of doelveld van een regel.
Bereik netwerkisolatie en beveilig uw Azure-resources tegen internet terwijl u toegang krijgt tot Azure-services met openbare eindpunten. Maak regels voor binnenkomende/uitgaande netwerkbeveiligingsgroepen om verkeer van en naar internet te weigeren en verkeer naar/van AzureCloud toe te staan. Zie de beschikbare servicetags van specifieke Azure-services voor meer servicetags .
Zie Overzicht van servicetags voor meer informatie over servicetags en Azure-services die deze ondersteunen
Privé-eindpunten en service-eindpunten vergelijken
Notitie
Microsoft raadt het gebruik van Azure Private Link aan. Private Link biedt betere mogelijkheden in termen van privétoegang tot PaaS vanaf on-premises, in ingebouwde gegevensexfiltratiebeveiliging en toewijzingsservice aan privé-IP in uw eigen netwerk. Zie Azure Private Link voor meer informatie
In plaats van alleen hun verschillen te bekijken, moet u erop wijzen dat zowel service-eindpunten als privé-eindpunten algemene kenmerken hebben.
Beide functies worden gebruikt voor gedetailleerdere controle over de firewall op de doelservice. Bijvoorbeeld het beperken van de toegang tot SQL Server-databases of opslagaccounts. De bewerking verschilt echter voor beide, zoals besproken in de vorige secties.
Beide benaderingen lossen het probleem van SNAT-poortuitputting (Source Network Address Translation) op. Mogelijk vindt u uitputting wanneer u verkeer tunnelt via een NVA (Network Virtual Appliance) of service met SNAT-poortbeperkingen. Wanneer u service-eindpunten of privé-eindpunten gebruikt, neemt het verkeer een geoptimaliseerd pad rechtstreeks naar de doelservice. Beide benaderingen kunnen profiteren van bandbreedte-intensieve toepassingen, omdat zowel latentie als kosten worden verlaagd.
In beide gevallen kunt u er nog steeds voor zorgen dat verkeer naar de doelservice wordt doorgegeven via een netwerkfirewall of NVA. Deze procedure verschilt voor beide benaderingen. Wanneer u service-eindpunten gebruikt, moet u het service-eindpunt in het firewallsubnet configureren in plaats van het subnet waarin de bronservice wordt geïmplementeerd. Wanneer u privé-eindpunten gebruikt, plaatst u een door de gebruiker gedefinieerde route (UDR) voor het IP-adres van het privé-eindpunt in het bronsubnet . Niet in het subnet van het privé-eindpunt.
Als u de verschillen met elkaar wilt vergelijken en wilt weten wat ze precies inhouden, kunt u de volgende tabel raadplegen.
Overweging | Service-eindpunten | Privé-eindpunten |
---|---|---|
Servicebereik op welk niveau de configuratie van toepassing is | Volledige service (bijvoorbeeld alle SQL-servers of opslagaccounts van alle klanten) | Afzonderlijke instantie (bijvoorbeeld een specifiek SQL Server-exemplaar of opslagaccount dat u bezit) |
In-built Data Exfiltration Protection - mogelijkheid om gegevens te verplaatsen/kopiëren van beveiligde PaaS-resource naar andere niet-beveiligde PaaS-resource door kwaadwillende insiders | Nr. | Ja |
Privétoegang tot PaaS-resource vanaf on-premises | Nr. | Ja |
NSG-configuratie vereist voor servicetoegang | Ja (met servicetags) | Nee |
Service kan worden bereikt zonder een openbaar IP-adres te gebruiken | Nr. | Ja |
Azure-naar-Azure-verkeer blijft in het Backbone-netwerk van Azure | Ja | Ja |
Service kan het openbare IP-adres uitschakelen | Nr. | Ja |
U kunt eenvoudig het verkeer beperken dat afkomstig is van een virtueel Azure-netwerk | Ja (toegang vanaf specifieke subnetten toestaan en of NSG's gebruiken) | Ja |
U kunt eenvoudig verkeer beperken dat afkomstig is van on-premises (VPN/ExpressRoute) | N.V.T** | Ja |
DNS-wijzigingen vereist | Nee | Ja (zie DNS-configuratie) |
Gevolgen voor de kosten van uw oplossing | Nee | Ja (zie prijzen voor Private Link) |
Heeft invloed op de samengestelde SLA van uw oplossing | Nee | Ja (Private Link-service zelf heeft een SLA van 99,99%) |
Installatie en onderhoud | Eenvoudig te installeren met minder beheeroverhead | Extra inspanning is vereist |
Limieten | Geen limiet voor het totale aantal service-eindpunten in een virtueel netwerk. Azure-services kunnen limieten afdwingen voor het aantal subnetten dat wordt gebruikt voor het beveiligen van de resource. (Zie veelgestelde vragen over virtuele netwerken) | Ja (zie Limieten voor Private Link) |
**Azure-servicebronnen die zijn beveiligd voor virtuele netwerken, zijn niet bereikbaar vanuit on-premises netwerken. Als u verkeer van on-premises wilt toestaan, staat u openbare IP-adressen (meestal NAT) toe vanuit uw on-premises of ExpressRoute. Deze IP-adressen kunnen worden toegevoegd via de IP-firewallconfiguratie voor de Azure-servicebronnen. Zie de veelgestelde vragen over het virtuele netwerk voor meer informatie.
Volgende stappen
Meer informatie over het integreren van uw app met een Azure-netwerk.
Meer informatie over het beperken van de toegang tot resources met behulp van servicetags.
Leer hoe u privé verbinding maakt met een Azure Cosmos DB-account via Azure Private Link.