Zero Trust-principes toepassen op het segmenteren van netwerkcommunicatie op basis van Azure

Artikel
05/31/2024

Dit artikel bevat richtlijnen voor het toepassen van de principes van Zero Trust voor het segmenteren van netwerken in Azure-omgevingen. Hier volgen de Zero Trust-principes.

Zero Trust-principe	Definitie
Expliciet verifiëren	Altijd verifiëren en autoriseren op basis van alle beschikbare gegevenspunten.
Toegang met minimale bevoegdheden gebruiken	Beperk gebruikerstoegang met Just-In-Time en Just-Enough-Access (JIT/JEA), op risico gebaseerd adaptief beleid en gegevensbeveiliging.
Stel dat er sprake is van een schending	Minimaliseer straal en segmenttoegang. Controleer end-to-end-versleuteling en gebruik analyse om zichtbaarheid te krijgen, detectie van bedreigingen te stimuleren en verdediging te verbeteren. U kunt de straalstraal van cyberaanvallen en segmenttoegang minimaliseren door netwerksegmentatie uit te voeren op verschillende niveaus in uw Azure-infrastructuur.

Dit artikel maakt deel uit van een reeks artikelen die laten zien hoe u de principes van Zero Trust toepast op Azure-netwerken.

Naarmate organisaties groeien van kleine bedrijven in grote ondernemingen, moeten ze vaak overstappen van één Azure-abonnement naar meerdere abonnementen om resources voor elke afdeling te scheiden. Het is belangrijk dat u de segmentatie van uw netwerk zorgvuldig plant om logische grenzen en isolatie tussen omgevingen te maken.

Elke omgeving, die doorgaans een afzonderlijke afdeling van uw organisatie weergeeft, moet zijn eigen toegangsmachtigingen en -beleid voor specifieke workloads hebben. Gebruikers van uw interne abonnement voor softwareontwikkelaars mogen bijvoorbeeld geen toegang hebben tot het beheren en implementeren van netwerkresources in het connectiviteitsabonnement. Deze omgevingen hebben echter nog steeds netwerkconnectiviteit nodig om de vereiste functionaliteit te bereiken voor basisservices, zoals DNS, hybride connectiviteit en het kunnen bereiken van andere resources in verschillende virtuele Azure-netwerken (VNets).

De segmentatie van uw Azure-infrastructuur biedt niet alleen isolatie, maar kan ook beveiligingsgrenzen maken die voorkomen dat een aanvaller zich verplaatst over omgevingen en extra schade toebrengt (het principe Van inbreuk op Zero Trust aannemen).

Referentiearchitectuur

U kunt verschillende segmentatieniveaus in Azure gebruiken om uw resources te beschermen tegen onbevoegde toegang of kwaadaardige aanvallen. Deze segmentatieniveaus beginnen op abonnementsniveau en gaan helemaal omlaag naar toepassingen die worden uitgevoerd op virtuele machines. Segmentatie maakt een grens die de ene omgeving scheidt van een andere, elk met eigen regels en beleidsregels. Met de veronderstelling dat schendingen kunnen optreden, moet u uw netwerken segmenteren om hun verspreiding te voorkomen.

Azure-netwerken maken gebruik van de volgende segmentatieniveaus:

Abonnementen

Een Azure-abonnement is een logische container die wordt gebruikt voor het inrichten van resources in Azure. Het is gekoppeld aan een Azure-account in een Microsoft Entra ID-tenant en fungeert als één factureringseenheid voor Azure-resources die zijn toegewezen aan het abonnement. Een Azure-abonnement is ook een logische grens voor toegang tot de resources in het abonnement. Voor toegang tussen resources in verschillende abonnementen zijn expliciete machtigingen vereist.
VNets

Een Azure-VNet is een geïsoleerd particulier netwerk waarmee standaard alle virtuele machines in het netwerk met elkaar kunnen communiceren. VNets kunnen standaard niet communiceren met andere VNets, tenzij u verbindingen tussen deze netwerken maakt via peering, VPN-verbindingen of ExpressRoute. Afzonderlijke VNets kunnen worden gebruikt als een vertrouwensgrens waarmee verschillende toepassingen, workloads, afdelingen of organisaties worden verdeeld.

Azure Virtual Network Manager (AVNM) is een netwerkbeheerservice waarmee één beheerteam VNets kan beheren en beveiligingsregels voor meerdere abonnementen wereldwijd kan afdwingen. U kunt AVNM gebruiken om netwerkgroepen te definiëren om te bepalen welke VNets met elkaar kunnen communiceren. U kunt AVNM ook gebruiken om wijzigingen in de netwerkconfiguratie te bewaken.
Workloads binnen een VNet

Voor workloads binnen een VNet, zoals virtuele machines of PaaS-services die ondersteuning bieden voor VNet-integratie, zoals Azure Databricks en App Service, is communicatie standaard toegestaan, omdat ze zich in hetzelfde VNet bevinden en verder moeten worden beveiligd met behulp van netwerkbeveiligingsgroepen. Hulpprogramma's en services voor segmentatie binnen een VNet omvatten het volgende:
- Azure Firewall
  
  Azure Firewall is een service die is geïmplementeerd in een VNet om verkeer tussen cloudresources, on-premises en internet te filteren. Met Azure Firewall kunt u regels en beleidsregels definiëren om verkeer op de netwerk- en toepassingslagen toe te staan of te weigeren. U kunt ook profiteren van de geavanceerde functies voor bedreigingsbeveiliging die door Azure Firewall worden geboden, zoals inbraakdetectie en preventiesysteem (IDPS), TLS-inspectie (Transport Layer Security) en filteren op basis van bedreigingsinformatie.
- Netwerkbeveiligingsgroep
  
  Een netwerkbeveiligingsgroep is een mechanisme voor toegangsbeheer waarmee netwerkverkeer tussen Azure-resources, zoals virtuele machines in een VNet, wordt gefilterd. Een netwerkbeveiligingsgroep bevat beveiligingsregels waarmee verkeer op het subnet- of virtuele-machineniveau in een VNet wordt toegestaan of geweigerd. Een veelvoorkomend gebruik van netwerkbeveiligingsgroepen is het segmenteren van de sets virtuele machines in verschillende subnetten.
- Toepassingsbeveiligingsgroep
  
  Een toepassingsbeveiligingsgroep is een uitbreiding van een netwerkbeveiligingsgroep waarmee u de netwerkinterfaces van virtuele machines kunt groeperen op basis van hun rollen en functies. Vervolgens kunt u de toepassingsbeveiligingsgroepen in een netwerkbeveiligingsgroep op schaal gebruiken zonder dat u de IP-adressen van virtuele machines hoeft te definiëren.
- Azure Front Door
  
  Azure Front Door is het moderne CDN (Content Delivery Network) van Microsoft dat snelle, betrouwbare en veilige toegang biedt tussen uw gebruikers en de statische en dynamische webinhoud van uw toepassingen over de hele wereld.

In het volgende diagram ziet u de referentiearchitectuur voor de segmentatieniveaus.

In het diagram geven de effen rode lijnen niveaus van segmentatie aan tussen:

Azure-abonnementen
VNets in een abonnement
Subnetten in een VNet
Internet en een VNet

In het diagram ziet u ook een set VNets die worden beheerd door AVNM die Azure-abonnementen kunnen omvatten.

Wat staat er in dit artikel?

Zero Trust-principes worden toegepast in de referentiearchitectuur binnen de Azure-cloud. In de volgende tabel worden de aanbevelingen voor het segmenteren van netwerken in deze architectuur beschreven om te voldoen aan het principe Van schending van Zero Trust aannemen.

Stap	Taak
1	Segmenteer binnen uw afzonderlijke VNets.
2	Meerdere VNets verbinden met peering.
3	Meerdere VNets verbinden in een hub- en spoke-configuratie.

Stap 1: Segmenteren binnen uw afzonderlijke VNets

Binnen één VNet in een Azure-abonnement gebruikt u subnetten om resources te scheiden en segmenteren. In een VNet kan er bijvoorbeeld een subnet zijn voor databaseservers, een andere voor webtoepassingen en een toegewezen subnet voor een Azure Firewall of Azure-toepassing Gateway met een Web Application Firewall. Standaard is alle communicatie tussen subnetten ingeschakeld binnen een VNet.

Als u isolatie tussen subnetten wilt maken, kunt u netwerkbeveiligingsgroepen of toepassingsbeveiligingsgroepen toepassen om specifiek netwerkverkeer toe te staan of te weigeren op basis van IP-adressen, poorten of protocollen. Het ontwerpen en onderhouden van netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen kan echter ook beheeroverhead creëren.

In deze afbeelding ziet u een algemene en aanbevolen configuratie van een toepassing met drie lagen met afzonderlijke subnetten voor elke laag en het gebruik van netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen om gesegmenteerde grenzen tussen elk subnet te maken.

U kunt resources ook segmenteren door verkeer tussen subnetten te routeren met behulp van door de gebruiker gedefinieerde routes (UDR's) die verwijzen naar een Azure Firewall of een NVA (Network Virtual Appliance) van derden. Azure Firewall en NVA's hebben ook de mogelijkheid om verkeer toe te laten of te weigeren met laag 3 tot laag 7-besturingselementen. De meeste van deze services bieden geavanceerde filtermogelijkheden.

Zie de richtlijnen in Patroon 1: Eén virtueel netwerk voor meer informatie.

Stap 2: Meerdere VNets verbinden met peering

Standaard is er geen toegestane communicatie tussen VNets met één Azure-abonnement of meerdere abonnementen. Meerdere VNets, elk behorend tot verschillende entiteiten, hebben hun eigen toegangsbeheer. Ze kunnen verbinding maken met elkaar of met een gecentraliseerd hub-VNet met behulp van VNet-peering, waarbij een Azure Firewall of een NVA van derden al het verkeer inspecteert.

In deze afbeelding ziet u een VNet-peeringverbinding tussen twee VNets en het gebruik van Azure Firewall aan elk uiteinde van de verbinding.

Een hub-VNet bevat doorgaans gedeelde onderdelen, zoals firewalls, id-providers en onderdelen voor hybride connectiviteit, onder andere. UDR-beheer wordt eenvoudiger omdat het toevoegen van specifieke UDR's voor microsegmentatie alleen nodig is als intra-VNet-verkeer een vereiste is. Omdat het VNet echter zijn eigen grenzen heeft, zijn er al beveiligingscontroles van kracht.

Zie de volgende richtlijnen voor meer informatie:

Stap 3: Meerdere VNets verbinden in een hub- en spoke-configuratie

Voor meerdere VNets in een hub- en spoke-configuratie moet u rekening houden met het segmenteren van uw netwerkverkeer voor deze grenzen:

Internetgrens
On-premises netwerkgrens
Grenzen aan globale Azure-services

Internetgrens

Het beveiligen van internetverkeer is een fundamentele prioriteit in de netwerkbeveiliging, waarbij inkomend verkeer van internet (niet-vertrouwd) en uitgaand verkeer naar internet (vertrouwd) wordt beheerd vanuit uw Azure-workloads.

Microsoft raadt aan dat inkomend verkeer van internet één toegangspunt heeft. Microsoft moedigt ten zeerste aan dat het inkomend verkeer via een Azure PaaS-resource loopt, zoals Azure Firewall, Azure Front Door of Azure-toepassing Gateway. Deze PaaS-resources bieden meer mogelijkheden dan een virtuele machine met een openbaar IP-adres.

Azure Firewall

In deze afbeelding ziet u hoe Azure Firewall in zijn eigen subnet fungeert als een centraal toegangspunt en segmentatiegrens voor verkeer tussen internet en een workload met drie lagen in een Azure-VNet.

Zie Azure Firewall in het Microsoft Azure Well-Architected Framework voor meer informatie.

Azure Front Door

Azure Front Door kan fungeren als grens tussen internet en services die worden gehost in Azure. Azure Front Door biedt ondersteuning voor Private Link-connectiviteit met resources zoals Internal Load Balancing (ILB) voor VNet-toegang, opslagaccounts voor statische websites en blobopslag en Azure-app-services. Azure Front Door wordt meestal uitgevoerd voor implementaties op schaal.

Azure Front Door is meer dan een taakverdelingsservice. De Azure Front Door-infrastructuur heeft DDoS-beveiliging ingebouwd. Wanneer caching is ingeschakeld, kan inhoud worden opgehaald van POP-locaties (Point of Presence) in plaats van voortdurend toegang te krijgen tot back-endservers. Wanneer de cache verloopt, haalt Azure Front Door de aangevraagde resource op en werkt de cache bij. In plaats van eindgebruikers die toegang hebben tot hun servers, maakt Azure Front Door gebruik van Split TCP voor twee afzonderlijke verbindingen. Dit verbetert niet alleen de ervaring van eindgebruikers, maar voorkomt dat kwaadwillende actoren rechtstreeks toegang krijgen tot resources.

In deze afbeelding ziet u hoe Azure Front Door segmentatie biedt tussen internetgebruikers en Azure-resources, die zich in opslagaccounts kunnen bevinden.

Zie Azure Front Door in het Azure Well-Architected Framework voor meer informatie.

Azure Application Gateway

Het internetpunt van de invoer kan ook een combinatie van ingangspunten zijn. HTTP/HTTPS-verkeer kan bijvoorbeeld binnenkomen via een toepassingsgateway die wordt beveiligd door een Web Application Firewall of Azure Front Door. Niet-HTTP/HTTPS-verkeer, zoals RDP/SSH, kan inkomend verkeer via Azure Firewall of een NVA. U kunt deze twee elementen tegelijk gebruiken voor diepere inspectie en het beheren van de verkeersstroom met behulp van UDR's.

In deze afbeelding ziet u inkomend internetverkeer en het gebruik van een Application Gateway met een Web Application Firewall voor HTTP/HTTPS-verkeer en een Azure Firewall voor al het andere verkeer.

Twee veelgebruikte scenario's zijn:

Plaats een Azure Firewall of een NVA parallel met een Application Gateway.
Plaats een Azure Firewall of een NVA na een Application Gateway voor verdere verkeersinspectie voordat deze de bestemming bereikt.

Zie Azure-toepassing Gateway in het Microsoft Azure Well-Architected Framework voor meer informatie.

Hier volgen aanvullende algemene patronen voor internetverkeersstromen.

Inkomend verkeer via meerdere interfaces

Eén benadering omvat het gebruik van meerdere netwerkinterfaces op virtuele machines bij het gebruik van NVA's: één interface voor niet-vertrouwd verkeer (extern gericht) en een andere voor vertrouwd verkeer (intern gericht). Wat betreft de verkeersstroom moet u inkomend verkeer van on-premises naar de NVA routeren met behulp van UDR's. Inkomend verkeer van internet dat door de NVA wordt ontvangen, moet worden gerouteerd naar de doelworkload op het juiste VNet of subnet door een combinatie van statische routes in het gast-besturingssysteemapparaat en UDR's.

Uitgaand verkeer en UDR's

Voor verkeer dat uw VNet voor internet verlaat, kunt u een UDR toepassen met behulp van een routetabel met de gekozen NVA als de volgende hop. Om de complexiteit te verminderen, kunt u een Azure Firewall of NVA implementeren in uw Azure Virtual WAN-hub en internetbeveiliging inschakelen met routeringsintentie. Dit zorgt ervoor dat zowel noord-zuid-verkeer (binnenkomen en buiten een netwerkbereik) als oost-west-verkeer (tussen apparaten binnen een netwerkbereik) dat bestemd is voor niet-Azure Virtual IP-adressen (VIP's) wordt geïnspecteerd.

Uitgaand verkeer en een standaardroute

Sommige methoden omvatten het beheren van een standaardroute (0.0.0.0/0) met verschillende methoden. Over het algemeen wordt aanbevolen dat uitgaand verkeer dat afkomstig is uit Azure, gebruikmaakt van afsluitpunten en inspectie met Azure Firewall of NVA's vanwege de hoeveelheid doorvoer die door de Azure-infrastructuur kan worden verwerkt, wat in de meeste gevallen veel groter en toleranter kan zijn. In dit geval kan het configureren van een standaardroute in de UDR's van workloadsubnetten verkeer naar deze afsluitpunten afdwingen. Mogelijk wilt u ook uitgaand verkeer van on-premises naar Azure routeren als een afsluitpunt. In dit geval gebruikt u Azure Route Server in combinatie met een NVA om een standaardroute naar on-premises te adverteren met behulp van Border Gateway Protocol (BGP).

Er zijn speciale gevallen wanneer u al het uitgaand verkeer nodig hebt om terug te worden gerouteerd naar on-premises door een standaardroute via BGP te adverteren. Dit zorgt ervoor dat verkeer dat het VNet verlaat, wordt getunneld via uw on-premises netwerk naar een firewall voor inspectie. Deze laatste benadering is het minst gewenst vanwege een verhoogde latentie en een gebrek aan beveiligingscontroles van Azure. Deze praktijk wordt veel toegepast door de overheids- en banksectoren die specifieke vereisten hebben voor verkeersinspectie binnen hun on-premises omgeving.

In termen van schaal:

Voor één VNet kunt u netwerkbeveiligingsgroepen gebruiken, die strikt voldoen aan laag 4-semantiek, of u kunt een Azure Firewall gebruiken die voldoet aan zowel laag 4- als laag 7-semantiek.
Voor meerdere VNets kan één Azure Firewall nog steeds worden gebruikt als deze bereikbaar is, of u kunt een Azure Firewall implementeren in elk virtueel netwerk en verkeer doorsturen met UDR's.

Voor grote gedistribueerde bedrijfsnetwerken kunt u nog steeds het hub- en spoke-model gebruiken en verkeer omleiden met UDR's. Dit kan echter leiden tot beheeroverhead en VNet-peeringlimieten. Voor gebruiksgemak kan Azure Virtual WAN dit bereiken als u een Azure Firewall in de virtuele hub implementeert en routeringsintentie activeert voor internetbeveiliging. Hiermee injecteert u standaardroutes in alle spokes- en vertakkingsnetwerken en verzendt u internetverkeer naar de Azure Firewall voor inspectie. Privéverkeer dat is bestemd voor RFC 1918-adresblokken, wordt verzonden naar de Azure Firewall of NVA als de aangewezen volgende hop in de Azure Virtual WAN-hub.

On-premises netwerkgrens

In Azure zijn de belangrijkste methoden voor het tot stand brengen van connectiviteit met on-premises netwerken IPsec-tunnels (Internet Protocol), ExpressRoute-tunnels of SD-WAN-tunnels (Software-Defined WAN). Normaal gesproken gebruikt u een Azure Site-to-Site-VPN-verbinding (S2S) voor kleinere workloads waarvoor minder bandbreedte is vereist. Voor workloads waarvoor een toegewezen servicepad en hogere doorvoerbehoeften zijn vereist, raadt Microsoft ExpressRoute aan.

In deze afbeelding ziet u de verschillende typen verbindingsmethoden tussen een Azure-omgeving en een on-premises netwerk.

Hoewel Azure VPN-verbindingen meerdere tunnels kunnen ondersteunen, wordt ExpressRoute vaak geconfigureerd voor grotere bedrijfsnetwerken waarvoor een hogere bandbreedte en privéverbindingen nodig zijn via een connectiviteitspartner. Voor ExpressRoute is het mogelijk om hetzelfde VNet te verbinden met meerdere circuits, maar voor segmentatiedoeleinden is dit vaak niet ideaal omdat VNets niet met elkaar kunnen communiceren.

Een van de segmentatiemethoden omvat het niet gebruiken van een externe gateway in spoke-VNets of het uitschakelen van doorgifte van BGP-routes als u routetabellen gebruikt. U kunt nog steeds hubs segmenteren die zijn verbonden met ExpressRoute met NVA's en firewalls. Voor spokes die zijn gekoppeld aan hubs, kunt u ervoor kiezen geen externe gateway te gebruiken in de eigenschappen van VNet-peering. Op die manier leren spokes alleen over hun rechtstreeks verbonden hubs en niet over on-premises routes.

Een andere opkomende benadering voor het segmenteren van verkeer dat van en naar on-premises gaat, is het gebruik van SD-WAN-technologieën. U kunt uw vertakkingslocaties uitbreiden naar Azure SD-WAN met behulp van NVA's van derden in Azure om segmentatie te maken op basis van SD-WAN-tunnels die afkomstig zijn van verschillende vertakkingen binnen de NVA-apparaten. U kunt Azure Route Server gebruiken om de adresvoorvoegsels voor de SD-WAN-tunnels in het Azure-platform te injecteren voor een hub- en spoke-topologie.

Voor een virtuele WAN-topologie kunt u directe integratie van de SD-WAN NVA van derden in de virtuele hub hebben. U kunt ook BGP-eindpunten gebruiken om het gebruik van SD-WAN-oplossingen toe te staan, waarbij tunnels worden gemaakt van de virtuele hub-geïntegreerde NVA.

Voor beide modellen kunt u ExpressRoute gebruiken om onderliggende privé- of openbare connectiviteit te segmenteren met persoonlijke peering of Microsoft-peering. Voor beveiliging is het gebruikelijk om een standaardroute via ExpressRoute te adverteren. Dit zorgt ervoor dat al het verkeer dat het VNet verlaat, wordt getunneld naar uw on-premises netwerk voor inspectie. Op dezelfde manier kan verkeer via vpn en ExpressRoute worden verzonden naar een NVA voor verdere inspectie. Dit geldt ook voor verkeer dat Azure verlaat. Deze methoden zijn eenvoudig wanneer de omgeving kleiner is, zoals een of twee regio's.

Voor grote, gedistribueerde netwerken kunt u ook Azure Virtual WAN gebruiken door inspectie van privéverkeer te activeren met behulp van routeringsintentie. Hiermee wordt al het verkeer doorgestuurd dat bestemd is voor een privé-IP-adres van de NVA voor inspectie. Net als bij de bovenstaande methoden is dit veel eenvoudiger te beheren wanneer uw omgeving meerdere regio's omvat.

De andere benadering met Azure Virtual WAN is het gebruik van aangepaste routetabellen voor isolatiegrenzen. U kunt aangepaste routes maken en alleen de VNets koppelen en doorgeven die u aan deze routetabellen wilt doorgeven. Deze mogelijkheid kan echter momenteel niet worden gecombineerd met routeringsintentie. Als u vertakkingen wilt isoleren, kunt u labels toewijzen om vertakkingen aan dat label te koppelen. U kunt doorgifte ook uitschakelen naar het standaardlabel per hub. Op dit moment kunt u afzonderlijke vertakkingen in Azure niet afzonderlijk isoleren op één hub. U kunt SD-WAN bijvoorbeeld niet isoleren van ExpressRoute. Maar op een hele hub kunt u doorgifte uitschakelen naar het standaardlabel.

Grenzen aan globale Azure-services

In Azure zijn de meeste services standaard toegankelijk via het globale WAN van Azure. Dit geldt ook voor openbare toegang tot Azure PaaS-services. Azure Storage heeft bijvoorbeeld een ingebouwde firewall die de toegang tot VNets kan beperken en openbare toegang kan blokkeren. Er is echter vaak behoefte aan gedetailleerdere controle. De gebruikelijke voorkeur is om privé verbinding te maken met Azure VIP's in plaats van de standaard openbare IP-adressen te gebruiken.

De meest voorkomende methode om de toegang tot PaaS-resources te beperken, is via Azure Private Link. Wanneer u een privé-eindpunt maakt, wordt het opgenomen in uw VNet. Azure gebruikt dit privé-IP-adres om te tunnelen naar de Betreffende PaaS-resource. Azure wijst een DNS A-record toe aan het privé-eindpunt met behulp van Azure Privé-DNS Zones en wijst een CNAME-record toe aan de PaaS-resource van de privékoppeling.

Service-eindpunten bieden een alternatieve methode voor het maken van verbinding met PaaS-VIP's. U kunt servicetags selecteren om verbindingen met alle PaaS-resources binnen die tag toe te staan en privéconnectiviteit met de PaaS-resource te bieden.

Een andere gangbare methode omvat het gebruik van Microsoft-peering voor ExpressRoute. Als u vanaf on-premises verbinding wilt maken met PaaS-VIP's, kunt u Microsoft-peering instellen. U kunt de BGP-community kiezen voor de VIP's die moeten worden gebruikt en dit wordt geadverteerd via het Microsoft-peeringpad.

Zie de volgende richtlijnen voor meer informatie:

Segmentatieoverzicht

Deze tabel bevat een overzicht van de verschillende niveaus van segmentatie en beveiligingsmethoden.

Tussen	Standaardgedrag	Communicatie ingeschakeld door...	Segmentatiebeveiligingsmethode(en)
Abonnementen	Geen communicatie	- VNet-peering - VPN-gateways	Azure Firewall
VNets	Geen communicatie	- VNet-peering - VPN-gateways	Azure Firewall
Workloads op subnetten binnen een VNet	Open communicatie	N.v.t.	- Netwerkbeveiligingsgroepen - Toepassingsbeveiligingsgroepen
Internet en een VNet	Geen communicatie	- Load Balancer - Openbaar IP-adres - Application Gateway - Azure Front Door	- Azure-toepassing Gateway met een Web Application Firewall - Azure Firewall - Azure Front Door met een Web Application Firewall
Internet en uw on-premises netwerken	Geen communicatie	- Azure S2S VPN - IPSec-tunnel - ExpressRoute-tunnel - SD-WAN-tunnel	Azure Firewall
Internet en virtuele machines in een VNet	Geen communicatie als de virtuele machines alleen privé-IP-adressen hebben	De virtuele machine een openbaar IP-adres toewijzen	Firewall van lokale virtuele machine

Aanbevolen training

Volgende stappen

Zie voor meer informatie over het toepassen van Zero Trust op Azure-netwerken:

Verwijzingen

Raadpleeg deze koppelingen voor meer informatie over de verschillende services en technologieën die in dit artikel worden genoemd.

Delen via