Azure-services integreren met virtuele netwerken voor netwerkisolatie
Virtual Network integratie voor een Azure-service stelt u in staat de toegang tot de service alleen te vergrendelen voor uw virtuele netwerkinfrastructuur. De virtuele netwerkinfrastructuur omvat ook virtuele netwerken met peering 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.
Privé-eindpunt gebruiken waarmee u privé en veilig verbinding maakt met een service die mogelijk wordt 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 serviceresources 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 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 om resources in de virtuele netwerken met elkaar te laten communiceren met behulp van privé-IP-adressen.
De Azure-service beheert service-exemplaren in een virtueel netwerk volledig. Dit beheer omvat het bewaken van de status van de resources en het schalen met de belasting.
Service-exemplaren worden geïmplementeerd in een subnet in een virtueel netwerk. Binnenkomende en uitgaande netwerktoegang voor het subnet moet worden geopend via netwerkbeveiligingsgroepen, volgens de richtlijnen van de service.
Bepaalde services leggen beperkingen op voor het subnet waarin ze zijn geïmplementeerd. Deze beperkingen beperken de toepassing van beleid, routes of het combineren van VM's en serviceresources binnen hetzelfde subnet. Neem contact op met elke service over de specifieke beperkingen, aangezien deze in de loop van de tijd kunnen veranderen. Voorbeelden van dergelijke services zijn Azure NetApp Files, Toegewezen HSM, Azure Container Instances App Service.
Optioneel kunnen services een gedelegeerd subnet vereisen als een expliciete id waarmee een subnet een bepaalde service kan hosten. Azure-services hebben een expliciete machtiging 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 kunnen worden geïmplementeerd in een virtueel netwerk.
Private Link en privé-eindpunten
Privé-eindpunten staan veilig inkomend verkeer van uw virtuele netwerk naar een Azure-resource toe. 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 dit beveiligde connectiviteit tussen clients in uw virtuele netwerk en uw Azure-resource. Aan het privé-eindpunt wordt een IP-adres uit het IP-adresbereik van uw virtuele netwerk toegewezen. De verbinding tussen het privé-eindpunt en de Azure-service is een privékoppeling.
In het diagram wordt aan de rechterkant een Azure SQL Database weergegeven als de PaaS-doelservice. 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 het verkeer nu 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 private link. 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 toestaan voor dat openbare IP-adres, waardoor het 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 in de toepassing. DNS-omzetting in het virtuele netwerk moet zodanig 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.
Met deze blootstelling van afzonderlijke exemplaren kunt u diefstal van gegevens voorkomen. Een kwaadwillende actor kan geen informatie uit de database verzamelen en uploaden naar een andere openbare database of opslagaccount. U kunt de 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 veilige en directe connectiviteit met Azure-services via het Azure-backbone-netwerk. 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. Met deze wijziging van inkomend verkeer kunt u eenvoudig de oorsprong identificeren en deze 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 worden ze omgezet naar 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 netwerk van de klant met twee subnetten: Subnet A met een service-eindpunt naar Microsoft.Sql
en Subnet B, waarvoor geen service-eindpunten zijn gedefinieerd.
Wanneer een resource in Subnet B een SQL Server probeert te bereiken, gebruikt deze een openbaar IP-adres 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 een databaseserver probeert te bereiken, wordt dit 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. Alle SQL Server bijvoorbeeld exemplaren van Azure-klanten, niet alleen het exemplaar van de klant.
Zie Service-eindpunten voor virtuele netwerken voor meer informatie
Servicetags
Een servicelabel vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Met servicetags kunt u netwerktoegangsbeheer 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.
Zorg voor netwerkisolatie en beveilig uw Azure-resources tegen internet terwijl u toegang hebt tot Azure-services met openbare eindpunten. Maak regels voor inkomende/uitgaande netwerkbeveiligingsgroepen om verkeer van en naar internet te weigeren en verkeer naar/van AzureCloud toe te staan. Zie 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 op het gebied van privétoegang tot PaaS vanuit on-premises, in ingebouwde bescherming tegen gegevensexfiltratie en toewijzingsservice voor privé-IP in uw eigen netwerk. Zie Azure Private Link voor meer informatie
In plaats van alleen naar hun verschillen te kijken, is het de moeite waard om erop te wijzen dat zowel service-eindpunten als privé-eindpunten kenmerken gemeen 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 is echter voor beide anders, zoals in de vorige secties in meer detail is besproken.
Beide benaderingen verhelpen het probleem van SNAT-poortuitputting (Source Network Address Translation). 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 bandbreedte-intensieve toepassingen ten goede komen, omdat zowel latentie als kosten worden verlaagd.
In beide gevallen kunt u er nog steeds voor zorgen dat verkeer naar de doelservice via een netwerkfirewall of NVA wordt doorgegeven. Deze procedure verschilt voor beide benaderingen. Wanneer u service-eindpunten gebruikt, moet u het service-eindpunt configureren in het firewallsubnet 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 een opslagaccount dat u bezit) |
In-Built Bescherming tegen gegevensexfiltratie: de mogelijkheid om gegevens van beveiligde PaaS-resource te verplaatsen/kopiëren naar een andere niet-beveiligde PaaS-resource door kwaadwillende insiders | Nee | Ja |
Persoonlijke toegang tot PaaS-resource vanuit on-premises | Nee | Ja |
NSG-configuratie vereist voor servicetoegang | Ja (met servicetags) | No |
Service kan worden bereikt zonder een openbaar IP-adres te gebruiken | Nee | Ja |
Azure-naar-Azure-verkeer blijft in het Azure-backbone-netwerk | Ja | Ja |
Service kan het openbare IP-adres uitschakelen | Nee | Ja |
U kunt eenvoudig verkeer beperken dat afkomstig is van een Azure-Virtual Network | Ja (toegang vanaf specifieke subnetten toestaan en of NSG's gebruiken) | Yes |
U kunt eenvoudig verkeer beperken dat afkomstig is van on-premises (VPN/ExpressRoute) | N/A** | Yes |
Dns-wijzigingen vereist | No | Ja (zie DNS-configuratie) |
Heeft invloed op de kosten van uw oplossing | No | Ja (zie Prijzen van Private Link) |
Heeft invloed op de samengestelde SLA van uw oplossing | No | Ja (Private Link-service zelf heeft een SLA van 99,99%) |
Installatie en onderhoud | Eenvoudig in te stellen 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 Private Link limieten) |
**Azure-serviceresources die zijn beveiligd naar virtuele netwerken, zijn niet bereikbaar vanaf on-premises netwerken. Als u verkeer van on-premises wilt toestaan, staat u openbare IP-adressen (meestal NAT) van uw on-premises of ExpressRoute toe. Deze IP-adressen kunnen worden toegevoegd via de IP-firewallconfiguratie voor de Azure-serviceresources. Zie de veelgestelde vragen over virtuele netwerken 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 kunt maken met een Azure Cosmos DB-account via Azure Private Link.