Best practices van Azure voor netwerkbeveiliging

In dit artikel wordt een aantal best practices van Azure besproken om uw netwerkbeveiliging te verbeteren. Deze best practices zijn afgeleid van onze ervaring met Azure-netwerken en de ervaringen van klanten zoals uzelf.

In dit best practice wordt het volgende uitgelegd voor elke best practice:

  • Wat de best practice is
  • Waarom u deze functie wilt best practice
  • Wat kan het resultaat zijn als u de best practice
  • Mogelijke alternatieven voor de best practice
  • Meer informatie over het inschakelen van best practice

Deze best practices zijn gebaseerd op een consensus-mening en de mogelijkheden en functiesets van het Azure-platform, zoals ze bestaan op het moment dat dit artikel werd geschreven. Adviezen en technologieën veranderen in de tijd en dit artikel wordt regelmatig bijgewerkt om deze wijzigingen weer te geven.

Krachtige netwerkbesturingselementen gebruiken

U kunt virtuele Azure-machines (VM's) en apparaten verbinden met andere apparaten in het netwerk door ze in virtuele Azure-netwerken te plaatsen. Dat wil zeggen dat u interfacekaarten voor virtuele netwerken kunt verbinden met een virtueel netwerk om TCP/IP-communicatie tussen netwerkapparaten toe te staan. Virtuele machines die zijn verbonden met een virtueel Azure-netwerk kunnen verbinding maken met apparaten in hetzelfde virtuele netwerk, verschillende virtuele netwerken, internet of uw eigen on-premises netwerken.

Bij het plannen van uw netwerk en de beveiliging van uw netwerk raden we u aan het volgende te centraliseren:

  • Beheer van kernnetwerkfuncties zoals ExpressRoute, het inrichten van virtuele netwerken en subnetten en IP-adressering.
  • Beheer van netwerkbeveiligingselementen, zoals virtuele netwerkapparaatfuncties zoals ExpressRoute, het inrichten van virtuele netwerken en subnetten en IP-adressering.

Als u een algemene set beheerhulpprogramma's gebruikt om uw netwerk en de beveiliging van uw netwerk te bewaken, krijgt u duidelijk inzicht in beide. Een eenvoudige, geïntegreerde beveiligingsstrategie vermindert fouten omdat het menselijk inzicht en de betrouwbaarheid van automatisering vergroot.

Subnetten logisch segmenteren

Virtuele Azure-netwerken zijn vergelijkbaar met DEN's in uw on-premises netwerk. Het idee achter een virtueel Azure-netwerk is dat u een netwerk maakt op basis van één privé-IP-adresruimte waarop u al uw virtuele Azure-machines kunt plaatsen. De beschikbare privé-IP-adresruimten zijn in de klassen A (10.0.0.0/8), klasse B (172.16.0.0/12) en klasse C (192.168.0.0/16).

Best practices voor het logisch segmenteren van subnetten zijn onder andere:

Best practice:wijs geen regels voor toestaan met een breed bereik toe (sta bijvoorbeeld 0.0.0.0 tot en met 255.255.255.255 toe).
Detail:zorg ervoor dat procedures voor probleemoplossing het instellen van deze typen regels worden afgeraden of verboden. Deze regels voor toestaan leiden tot een onwaar gevoel van beveiliging en worden vaak gevonden en misbruikt door rode teams.

Best practice:segmenteert de grotere adresruimte in subnetten.
Detail:gebruik subnetten opbasis van CIDR om uw subnetten te maken.

Best practice:maak besturingselementen voor netwerktoegang tussen subnetten. Routering tussen subnetten vindt automatisch plaats en u hoeft routeringstabellen niet handmatig te configureren. Standaard zijn er geen besturingselementen voor netwerktoegang tussen de subnetten die u in een virtueel Azure-netwerk maakt.
Detail:Gebruik een netwerkbeveiligingsgroep om te beveiligen tegen ongevraagd verkeer naar Azure-subnetten. Netwerkbeveiligingsgroepen zijn eenvoudige, stateful pakketinspectieapparaten die gebruikmaken van de 5-tuple-benadering (bron-IP, bronpoort, doel-IP, doelpoort en laag 4-protocol) voor het maken van regels voor toestaan/weigeren voor netwerkverkeer. U kunt verkeer van en naar één IP-adres, van en naar meerdere IP-adressen of van en naar volledige subnetten toestaan of weigeren.

Wanneer u netwerkbeveiligingsgroepen gebruikt voor netwerktoegangsbeheer tussen subnetten, kunt u resources die deel uitmaken van dezelfde beveiligingszone of rol in hun eigen subnetten zetten.

Best practice:Vermijd kleine virtuele netwerken en subnetten om eenvoud en flexibiliteit te garanderen.
Detail:de meeste organisaties voegen meer resources toe dan oorspronkelijk gepland en het opnieuw toewijzen van adressen is arbeidsintensief. Het gebruik van kleine subnetten voegt een beperkte beveiligingswaarde toe en het toewijzen van een netwerkbeveiligingsgroep aan elk subnet zorgt voor extra overhead. Definieer subnetten breed om ervoor te zorgen dat u flexibiliteit hebt voor groei.

Best practice:vereenvoudig het beheer van regels voor netwerkbeveiligingsgroepen door Toepassingsbeveiligingsgroepen te definiëren.
Detail:definieer een toepassingsbeveiligingsgroep voor lijsten met IP-adressen die in de toekomst kunnen worden gewijzigd of die in veel netwerkbeveiligingsgroepen kunnen worden gebruikt. Zorg ervoor dat u toepassingsbeveiligingsgroepen duidelijk noemt, zodat anderen hun inhoud en doel kunnen begrijpen.

Een benadering Zero Trust kiezen

Perimeternetwerken werken op basis van de veronderstelling dat alle systemen binnen een netwerk kunnen worden vertrouwd. Tegenwoordig hebben werknemers echter vanaf elke locatie toegang tot de resources van hun organisatie op verschillende apparaten en apps, waardoor perimeterbeveiligingscontroles niet relevant zijn. Toegangsbeheerbeleid dat zich alleen richt op wie toegang heeft tot een resource, is niet voldoende. Om de balans tussen beveiliging en productiviteit onder de knie te krijgen, moeten beveiligingsbeheerders ook rekening houden met de manier waarop een resource wordt gebruikt.

Netwerken moeten zich ontwikkelen van traditionele verdedigingslinieën omdat netwerken kwetsbaar kunnen zijn voor schendingen: een aanvaller kan inbreuk maken op één eindpunt binnen de vertrouwde grens en vervolgens snel voet aan de grond krijgen in het hele netwerk. Zero Trust netwerken elimineren het concept van vertrouwen op basis van netwerklocatie binnen een perimeter. In plaats daarvan Zero Trust-architecturen apparaat- en gebruikersvertrouwensclaims gebruiken om toegang tot organisatiegegevens en -resources te gateen. Voor nieuwe initiatieven kunt u een Zero Trust die vertrouwen valideren op het moment van toegang.

Best practices zijn:

Best practice:geef voorwaardelijke toegang tot resources op basis van apparaat, identiteit, zekerheid, netwerklocatie en meer.
Detail:met voorwaardelijke toegang van Azure AD kunt u het juiste toegangsbeheer toepassen door geautomatiseerde beslissingen voor toegangsbeheer te implementeren op basis van de vereiste voorwaarden. Zie Toegang tot Azure-beheer beheren met voorwaardelijke toegang voor meer informatie.

Best practice:poorttoegang alleen inschakelen na goedkeuring van de werkstroom.
Detail:u kunt Just-In-Time-VM-toegang in Microsoft Defender for Cloud gebruiken om het inkomende verkeer naar uw Azure-VM's te vergrendelen, de blootstelling aan aanvallen te verminderen en tegelijkertijd eenvoudig toegang te bieden om verbinding te maken met VM's wanneer dat nodig is.

Best practice:verleen tijdelijke machtigingen voor het uitvoeren van bevoorrechte taken, waardoor kwaadwillende of onbevoegde gebruikers geen toegang kunnen krijgen nadat de machtigingen zijn verlopen. Toegang wordt alleen verleend wanneer gebruikers deze nodig hebben.
Detail:Gebruik Just-In-Time-toegang in Azure AD Privileged Identity Management of in een oplossing van derden om machtigingen te verlenen voor het uitvoeren van bevoorrechte taken.

Zero Trust is de volgende evolutie in netwerkbeveiliging. De status van cyberaanvallen zorgt er voor dat organisaties uitgaan van de instelling 'schendingen aannemen', maar deze aanpak mag niet beperkend zijn. Zero Trust netwerken beschermen bedrijfsgegevens en -bronnen en zorgen ervoor dat organisaties een moderne werkplek kunnen bouwen met behulp van technologieën die werknemers in staat stellen om overal en altijd productief te zijn.

Routeringsgedrag bepalen

Wanneer u een virtuele machine in een virtueel Azure-netwerk zet, kan de virtuele machine verbinding maken met een andere virtuele machine in hetzelfde virtuele netwerk, zelfs als de andere VM's zich in verschillende subnetten hebben. Dit is mogelijk omdat een verzameling systeemroutes die standaard is ingeschakeld, dit type communicatie toestaat. Met deze standaardroutes kunnen VM's in hetzelfde virtuele netwerk verbindingen met elkaar en met internet tot stand brengen (alleen voor uitgaande communicatie met internet).

Hoewel de standaardsysteemroutes nuttig zijn voor veel implementatiescenario's, zijn er momenten waarop u de routeringsconfiguratie voor uw implementaties wilt aanpassen. U kunt het adres van de volgende hop configureren om specifieke bestemmingen te bereiken.

U wordt aangeraden door de gebruiker gedefinieerde routes te configureren wanneer u een beveiligingsapparaat voor een virtueel netwerk implementeert. We bespreken dit in een latere sectie met de titel Uw kritieke Azure-serviceresources alleen beveiligen met uw virtuele netwerken.

Notitie

Door de gebruiker gedefinieerde routes zijn niet vereist en de standaardsysteemroutes werken meestal.

Virtuele netwerkapparaten gebruiken

Netwerkbeveiligingsgroepen en door de gebruiker gedefinieerde routering kunnen een bepaalde mate van netwerkbeveiliging bieden in het netwerk en de transportlagen van het OSI-model. Maar in sommige gevallen wilt of moet u beveiliging op hoog niveau van de stack inschakelen. In dergelijke situaties wordt u aangeraden beveiligingsapparaten voor virtuele netwerken te implementeren die worden geleverd door Azure-partners.

Azure-netwerkbeveiligingsapparaten kunnen betere beveiliging bieden dan wat besturingselementen op netwerkniveau bieden. Netwerkbeveiligingsmogelijkheden van virtuele netwerkbeveiligingsapparaten zijn onder andere:

  • Firewalling
  • Inbraakdetectie/inbraakpreventie
  • Beheer van beveiligingsproblemen
  • Toepassingsbeheer
  • Anomaliedetectie op basis van het netwerk
  • Webfiltering
  • Antivirus
  • Botnet-beveiliging

Als u beschikbare beveiligingsapparaten voor virtuele Azure-netwerken wilt vinden, gaat u naar de Azure Marketplace en zoekt u naar 'beveiliging' en 'netwerkbeveiliging'.

Perimeternetwerken implementeren voor beveiligingszones

Een perimeternetwerk (ook wel dmz genoemd) is een fysiek of logisch netwerksegment dat een extra beveiligingslaag biedt tussen uw assets en internet. Gespecialiseerde apparaten voor netwerktoegangsbeheer aan de rand van een perimeternetwerk staan alleen gewenst verkeer in uw virtuele netwerk toe.

Perimeternetwerken zijn handig omdat u uw netwerktoegangsbeheer, bewaking, logboekregistratie en rapportage kunt richten op de apparaten aan de rand van uw virtuele Azure-netwerk. In een perimeternetwerk kunt u doorgaans DDoS-preventie (Distributed Denial of Service), inbraakdetectie-/inbraakpreventiesystemen (IDS/IPS), firewallregels en -beleidsregels, webfilters, netwerk-antimalware en meer inschakelen. De netwerkbeveiligingsapparaten staan tussen internet en uw virtuele Azure-netwerk en hebben een interface op beide netwerken.

Hoewel dit het basisontwerp van een perimeternetwerk is, zijn er veel verschillende ontwerpen, zoals back-to-back, tri-homed en multi-homed.

Op basis van Zero Trust eerder genoemde concept raden we u aan een perimeternetwerk te gebruiken voor alle implementaties met hoge beveiliging om het niveau van netwerkbeveiliging en toegangsbeheer voor uw Azure-resources te verbeteren. U kunt Azure of een oplossing van derden gebruiken om een extra beveiligingslaag te bieden tussen uw assets en internet:

  • Native Besturingselementen van Azure. Azure Firewall en de Web Application Firewall in Application Gateway bieden basisbeveiliging met een volledig stateful firewall als een service, ingebouwde hoge beschikbaarheid, onbeperkte cloudschaalbaarheid, FQDN-filtering, ondersteuning voor OWASP-kernregelsets en eenvoudige installatie en configuratie.
  • Aanbiedingen van derden. Zoek in Azure Marketplace naar NGFW (Next Generation Firewall) en andere aanbiedingen van derden die vertrouwde beveiligingshulpprogramma's en aanzienlijk verbeterde niveaus van netwerkbeveiliging bieden. Configuratie is mogelijk complexer, maar met een aanbieding van derden kunt u bestaande mogelijkheden en vaardighedensets gebruiken.

Veel organisaties hebben gekozen voor de hybride IT-route. Met hybride IT zijn sommige informatieactiva van het bedrijf aanwezig in Azure en blijven andere on-premises. In veel gevallen worden sommige onderdelen van een service uitgevoerd in Azure, terwijl andere onderdelen on-premises blijven.

In een hybride IT-scenario is er meestal een bepaald type cross-premises connectiviteit. Met cross-premises connectiviteit kan het bedrijf zijn on-premises netwerken verbinden met virtuele Azure-netwerken. Er zijn twee oplossingen voor cross-premises connectiviteit beschikbaar:

  • Site-naar-site-VPN. Het is een vertrouwde, betrouwbare en tot stand gebrachte technologie, maar de verbinding vindt plaats via internet. Bandbreedte is beperkt tot een maximum van ongeveer 1,25 Gbps. Site-naar-site-VPN is in sommige scenario's een wenselijke optie.
  • Azure ExpressRoute. U wordt aangeraden ExpressRoute te gebruiken voor uw cross-premises connectiviteit. Met ExpressRoute kunt u uw on-premises netwerken uitbreiden naar de Microsoft Cloud via een privéverbinding van een connectiviteitsprovider. Met ExpressRoute kunt u verbindingen tot stand brengen met Microsoft-cloudservices zoals Azure, Microsoft 365 en Dynamics 365. ExpressRoute is een toegewezen WAN-koppeling tussen uw on-premises locatie of een Microsoft Exchange-hostingprovider. Omdat dit een telco-verbinding is, gaan uw gegevens niet via internet en worden ze dus niet blootgesteld aan de potentiële risico's van internetcommunicatie.

De locatie van uw ExpressRoute-verbinding kan invloed hebben op de firewallcapaciteit, schaalbaarheid, betrouwbaarheid en zichtbaarheid van netwerkverkeer. U moet bepalen waar ExpressRoute moet worden beëindigd in bestaande (on-premises) netwerken. U kunt:

  • Beëindig buiten de firewall (het perimeternetwerkparadigma) als u inzicht in het verkeer nodig hebt, als u een bestaande praktijk van het isoleren van datacenters wilt voortzetten of als u alleen extranetresources in Azure wilt plaatsen.
  • Beëindigen binnen de firewall (het paradigma van de netwerkextensie). Dit is de standaardaanbeveling. In alle andere gevallen raden we u aan Azure te behandelen als een nth-datacenter.

De uptime en prestaties optimaliseren

Als een service niet beschikbaar is, is er geen toegang tot de informatie. Als de prestaties zo slecht zijn dat de gegevens onbruikbaar zijn, kunt u de gegevens als ontoegankelijk beschouwen. Vanuit het oogpunt van beveiliging moet u alles doen wat u kunt om ervoor te zorgen dat uw services optimale uptime en prestaties hebben.

Een populaire en efficiënte methode voor het verbeteren van de beschikbaarheid en prestaties is taakverdeling. Taakverdeling is een methode voor het distribueren van netwerkverkeer over servers die deel uitmaken van een service. Als u bijvoorbeeld front-endwebservers als onderdeel van uw service hebt, kunt u taakverdeling gebruiken om het verkeer over uw meerdere front-endwebservers te verdelen.

Deze distributie van verkeer verhoogt de beschikbaarheid, omdat als een van de webservers niet meer beschikbaar is, de load balancer stopt met het verzenden van verkeer naar die server en het omgeleid naar de servers die nog steeds online zijn. Taakverdeling helpt ook de prestaties, omdat de processor-, netwerk- en geheugenoverhead voor het verwerken van aanvragen wordt verdeeld over alle servers met taakverdeling.

We raden u aan om waar mogelijk taakverdeling te gebruiken en deze zo nodig voor uw services te gebruiken. Hieronder volgen scenario's op zowel het niveau van het virtuele Azure-netwerk als het globale niveau, samen met opties voor taakverdeling voor elk netwerk.

Scenario:u hebt een toepassing die:

  • Vereist aanvragen van dezelfde gebruiker/clientsessie om dezelfde back-end-virtuele machine te bereiken. Voorbeelden hiervan zijn winkelwagen-apps en webmailservers.
  • Accepteert alleen een beveiligde verbinding, dus niet-versleutelde communicatie met de server is geen acceptabele optie.
  • Vereist dat meerdere HTTP-aanvragen op dezelfde langlopende TCP-verbinding worden gerouteerd of verdeeld over verschillende back-endservers.

Taakverdelingsoptie:gebruik Azure Application Gateway, een HTTP-webverkeersserver load balancer. Application Gateway biedt ondersteuning voor end-to-end TLS-versleuteling en TLS-beëindiging op de gateway. Webservers kunnen vervolgens worden ontlast door de overhead voor versleuteling en ontsleuteling en het niet-versleutelde verkeer naar de back-endservers.

Scenario:u moet de binnenkomende verbindingen van internet verdeeld over uw servers in een virtueel Azure-netwerk. Scenario's zijn wanneer u:

  • Staatloze toepassingen hebben die binnenkomende aanvragen van internet accepteren.
  • Geen plaksessies of TLS-offload vereisen. Sticky sessions is een methode die wordt gebruikt met Application Load Balancing om server-affiniteit te bereiken.

Taakverdelingsoptie:gebruik de Azure Portal om een externe load balancer te maken die binnenkomende aanvragen verspreidt over meerdere VM's om een hoger beschikbaarheidsniveau te bieden.

Scenario:u moet de load balancer gebruiken voor verbindingen van VM's die niet op internet zijn. In de meeste gevallen worden de verbindingen die worden geaccepteerd voor taakverdeling geïnitieerd door apparaten in een virtueel Azure-netwerk, zoals SQL Server exemplaren of interne webservers.
Taakverdelingsoptie:gebruik de Azure Portal om een interne load balancer te maken die binnenkomende aanvragen verspreidt over meerdere VM's om een hoger beschikbaarheidsniveau te bieden.

Scenario:u hebt globale taakverdeling nodig omdat u:

  • Een cloudoplossing hebben die breed wordt gedistribueerd over meerdere regio's en die het hoogst mogelijke uptimeniveau (beschikbaarheid) vereist.
  • U hebt het hoogst mogelijke uptimeniveau nodig om ervoor te zorgen dat uw service beschikbaar is, zelfs als een volledig datacenter niet meer beschikbaar is.

Taakverdelingsoptie:gebruik Azure Traffic Manager. Traffic Manager maakt het mogelijk om verbindingen met uw services te load balancen op basis van de locatie van de gebruiker.

Als de gebruiker bijvoorbeeld een aanvraag indient bij uw service vanuit de EU, wordt de verbinding omgeleid naar uw services die zich in een EU-datacenter bevinden. Dit onderdeel van Traffic Manager wereldwijde taakverdeling helpt de prestaties te verbeteren, omdat verbinding maken met het dichtstbijzijnde datacenter sneller is dan verbinding maken met datacenters die ver weg zijn.

RDP-/SSH-toegang tot virtuele machines uitschakelen

Het is mogelijk om virtuele Azure-machines te bereiken met behulp van Remote Desktop Protocol (RDP) en het SSH-protocol (Secure Shell). Deze protocollen maken het beheer van VM's vanaf externe locaties mogelijk en worden standaard gebruikt in datacenters.

Het potentiële beveiligingsprobleem bij het gebruik van deze protocollen via internet is dat aanvallers beveiligingstechnieken kunnen gebruiken om toegang te krijgen tot virtuele Azure-machines. Nadat de aanvallers toegang hebben verkregen, kunnen ze uw VM gebruiken als een startpunt voor aanvallen op andere computers in uw virtuele netwerk of zelfs voor aanvallen op netwerkapparaten buiten Azure.

U wordt aangeraden directe RDP- en SSH-toegang tot uw virtuele Azure-machines via internet uit te schakelen. Nadat directe RDP- en SSH-toegang via internet is uitgeschakeld, hebt u andere opties die u kunt gebruiken voor toegang tot deze VM's voor extern beheer.

Scenario:één gebruiker in staat stellen om via internet verbinding te maken met een virtueel Azure-netwerk.
Optie:Punt-naar-site-VPN is een andere term voor een VPN-client-/serververbinding met externe toegang. Nadat de punt-naar-site-verbinding tot stand is gebracht, kan de gebruiker RDP of SSH gebruiken om verbinding te maken met virtuele machines in het virtuele Azure-netwerk met welke de gebruiker verbinding heeft gemaakt via punt-naar-site-VPN. Dit gaat ervan uit dat de gebruiker is gemachtigd om deze VM's te bereiken.

Punt-naar-site-VPN is veiliger dan directe RDP- of SSH-verbindingen, omdat de gebruiker twee keer moet verifiëren voordat er verbinding wordt gemaakt met een VM. Eerst moet de gebruiker zich verifiëren (en worden geautoriseerd) om de punt-naar-site-VPN-verbinding tot stand te brengen. Ten tweede moet de gebruiker zich verifiëren (en worden geautoriseerd) om de RDP- of SSH-sessie tot stand te kunnen laten komen.

Scenario:gebruikers in uw on-premises netwerk in staat stellen verbinding te maken met VM's in uw virtuele Azure-netwerk.
Optie:een site-naar-site-VPN verbindt een volledig netwerk met een ander netwerk via internet. U kunt een site-naar-site-VPN gebruiken om uw on-premises netwerk te verbinden met een virtueel Azure-netwerk. Gebruikers in uw on-premises netwerk maken verbinding met behulp van het RDP- of SSH-protocol via de site-naar-site-VPN-verbinding. U hoeft geen directe RDP- of SSH-toegang via internet toe te staan.

Scenario:gebruik een toegewezen WAN-koppeling om functionaliteit te bieden die vergelijkbaar is met de site-naar-site-VPN.
Optie:Gebruik ExpressRoute. Het biedt functionaliteit die vergelijkbaar is met de site-naar-site-VPN. Dit zijn de belangrijkste verschillen:

  • De toegewezen WAN-koppeling gaat niet via internet.
  • Toegewezen WAN-verbindingen zijn doorgaans stabieler en presteren beter.

Uw kritieke Azure-servicebronnen alleen beveiligen naar uw virtuele netwerken

Gebruik Azure Private Link toegang tot Azure PaaS Services (bijvoorbeeld Azure Storage en SQL Database) via een privé-eindpunt in uw virtuele netwerk. Met privé-eindpunten kunt u uw kritieke Azure-servicebronnen alleen beveiligen naar uw virtuele netwerken. Verkeer van uw virtuele netwerk naar de Azure-service blijft altijd op het Microsoft Azure backbone-netwerk. Het beschikbaar maken van uw virtuele netwerk op het openbare internet is niet langer nodig om Azure PaaS Services te gebruiken.

Azure Private Link bieden de volgende voordelen:

  • Verbeterde beveiliging voor uw Azure-servicebronnen:met Azure Private Link kunnen Azure-servicebronnen worden beveiligd voor uw virtuele netwerk met behulp van een privé-eindpunt. Het beveiligen van servicebronnen naar een privé-eindpunt in een virtueel netwerk biedt verbeterde beveiliging door de toegang tot openbare internetbronnen volledig te verwijderen en alleen verkeer van privé-eindpunten in uw virtuele netwerk toe te staan.
  • Privétoegang tot Azure-servicebronnen op het Azure-platform:Verbinding maken uw virtuele netwerk naar services in Azure met behulp van privé-eindpunten. Er is geen openbaar IP-adres nodig. Het Private Link-platform zorgt voor de connectiviteit tussen de consument en de services via het Azure-backbonenetwerk.
  • Toegang vanuit on-premisesnetwerken en peeringnetwerken: toegang tot services die in Azure worden uitgevoerd vanuit on-premises via persoonlijke ExpressRoute-peering, VPN-tunnels en virtuele peernetwerken met behulp van privé-eindpunten. U hoeft geen ExpressRoute Microsoft-peering in te stellen of door het internet te gaan om de service te bereiken. Private Link biedt een veilige manier om workloads naar Azure te migreren.
  • Bescherming tegen gegevenslekken: Een privé-eindpunt wordt toegewezen aan een instantie van een PaaS-resource in plaats van de gehele service. Consumenten kunnen alleen verbinding maken met de specifieke resource. Toegang tot andere resources in de service is geblokkeerd. Dit mechanisme biedt beveiliging tegen risico's van gegevenslekken.
  • Globaal bereik: Maak privé verbinding met services die in andere regio's worden uitgevoerd. Het virtuele netwerk van de consument kan zich in regio A en kan verbinding maken met services in regio B.
  • Eenvoudig in te stellen en te beheren:u hebt geen gereserveerde openbare IP-adressen meer nodig in uw virtuele netwerken om Azure-resources te beveiligen via een IP-firewall. Er zijn geen NAT- of gatewayapparaten vereist om de privé-eindpunten in te stellen. Privé-eindpunten worden geconfigureerd via een eenvoudige werkstroom. Aan de servicezijde kunt u de verbindingsaanvragen op uw Azure-serviceresource ook eenvoudig beheren. Azure Private Link werkt ook voor consumenten en services die tot verschillende tenants Azure Active Directory behoren.

Zie voor meer informatie over privé-eindpunten en de Azure-services en -regio's waar privé-eindpunten beschikbaar voor zijn Azure Private Link.

Volgende stappen

Zie Best practices en patronen voor Azure-beveiliging voor meer best practices voor beveiliging die u kunt gebruiken bij het ontwerpen, implementeren en beheren van uw cloudoplossingen met behulp van Azure.