Uw Azure Private Link-installatie ontwerpen

Voordat u uw exemplaar van Azure Private Link instelt, moet u rekening houden met uw netwerktopologie en uw DNS-routeringstopologie.

Zoals besproken in Azure Private Link gebruiken om netwerken te verbinden met Azure Monitor, is het instellen van een privékoppeling van invloed op verkeer naar alle Azure Monitor-resources. Dat geldt vooral voor Application Insights-resources. Het is ook van invloed op niet alleen het netwerk dat is verbonden met het privé-eindpunt, maar ook op alle andere netwerken die dezelfde DNS delen.

De eenvoudigste en veiligste aanpak:

1. Maak één private link-verbinding, met één privé-eindpunt en één Azure Monitor Private Link Scope (AMPLS). Als uw netwerken zijn gekoppeld, maakt u de private link-verbinding in het gedeelde (of hub) virtuele netwerk.
2. Voeg alle Azure Monitor-resources, zoals Application Insights-onderdelen, Log Analytics-werkruimten en eindpunten voor gegevensverzameling, toe aan de AMPLS.
3. Verkeer via uitgaand netwerk zoveel mogelijk blokkeren.

Als u niet alle Azure Monitor-resources aan uw AMPLS kunt toevoegen, kunt u uw privékoppeling nog steeds toepassen op sommige resources, zoals wordt uitgelegd in Control hoe privékoppelingen van toepassing zijn op uw netwerken. We raden deze methode niet aan omdat hiermee geen gegevensexfiltratie worden voorkomen.

Plannen op netwerktopologie

Overweeg netwerktopologie in uw planningsproces.

Leidraad: DNS-onderdrukkingen vermijden met behulp van één AMPLS

Sommige netwerken bestaan uit meerdere virtuele netwerken of andere verbonden netwerken. Als deze netwerken dezelfde DNS delen, zou het instellen van een privékoppeling op een van deze netwerken de DNS bijwerken en van invloed zijn op verkeer in alle netwerken.

In het volgende diagram maakt virtueel netwerk 10.0.1.x verbinding met AMPLS1, waarmee DNS-vermeldingen worden gemaakt die Azure Monitor-eindpunten toewijzen aan IP-adressen van bereik 10.0.1.x. Later maakt virtueel netwerk 10.0.2.x verbinding met AMPLS2, waardoor dezelfde DNS-vermeldingen worden overschreven door dezelfde globale/regionale eindpunten toe te koppelen aan IP-adressen van het bereik 10.0.2.x. Omdat deze virtuele netwerken niet zijn gekoppeld, kan het eerste virtuele netwerk deze eindpunten nu niet bereiken.

Als u dit conflict wilt voorkomen, maakt u slechts één AMPLS-object per DNS.

Hub-and-spoke-netwerken

Hub-and-spoke-netwerken moeten gebruikmaken van één private link-verbinding die is ingesteld op het hubnetwerk (hoofdnetwerk) en niet in elk virtueel spoke-netwerk.

Notitie

Mogelijk wilt u liever afzonderlijke privékoppelingen maken voor uw virtuele spoke-netwerken, bijvoorbeeld om elk virtueel netwerk toegang te geven tot een beperkte set bewakingsbronnen. In dergelijke gevallen kunt u een toegewezen privé-eindpunt en AMPLS maken voor elk virtueel netwerk. U moet ook controleren of ze niet dezelfde DNS-zones delen om DNS-onderdrukkingen te voorkomen.

Gekoppelde netwerken

Netwerkpeering wordt gebruikt in verschillende topologieën, behalve hub en spoke. Dergelijke netwerken kunnen elkaars IP-adressen delen en waarschijnlijk dezelfde DNS delen. In dergelijke gevallen maakt u één privékoppeling op een netwerk dat toegankelijk is voor uw andere netwerken. Vermijd het maken van meerdere privé-eindpunten en AMPLS-objecten, omdat uiteindelijk slechts de laatste set in de DNS van toepassing is.

Geïsoleerde netwerken

Als uw netwerken niet zijn gekoppeld, moet u ook hun DNS scheiden om privékoppelingen te gebruiken. Maak daarna een afzonderlijk privé-eindpunt voor elk netwerk en een afzonderlijk AMPLS-object. Uw AMPLS-objecten kunnen een koppeling maken naar dezelfde werkruimten/onderdelen of naar verschillende.

Lokaal testen: bewerk het hosts-bestand van uw computer in plaats van de DNS

Als u privékoppelingen lokaal wilt testen zonder dat dit van invloed is op andere clients in uw netwerk, moet u ervoor zorgen dat u uw DNS niet bijwerkt wanneer u uw privé-eindpunt maakt. Bewerk in plaats daarvan het hosts-bestand op uw computer zodat aanvragen worden verzonden naar de privékoppelingseindpunten:

• Stel een privékoppeling in, maar wanneer u verbinding maakt met een privé-eindpunt, kiest u ervoor om niet automatisch te integreren met de DNS (stap 5b).
• Configureer de relevante eindpunten op de hosts-bestanden van uw computer. Zie De DNS-instellingen van uw eindpunt controleren om de Azure Monitor-eindpunten te controleren die toewijzing nodig hebben.

We raden deze benadering niet aan voor productieomgevingen.

Bepalen hoe privékoppelingen van toepassing zijn op uw netwerken

Met behulp van private link-toegangsmodi kunt u bepalen hoe privékoppelingen van invloed zijn op uw netwerkverkeer. Deze instellingen kunnen van toepassing zijn op uw AMPLS-object (om van invloed te zijn op alle verbonden netwerken) of op specifieke netwerken die ermee zijn verbonden.

Het kiezen van de juiste toegangsmodus is essentieel om continu, ononderbroken netwerkverkeer te garanderen. Elk van deze modi kan worden ingesteld voor opname en query's, afzonderlijk:

• Alleen privé: hiermee kan het virtuele netwerk alleen resources voor private link (resources in de AMPLS) bereiken. Dat is de veiligste werkmodus. Hiermee voorkomt u dat gegevensexfiltratie worden geblokkeerd door verkeer van de AMPLS naar Azure Monitor-resources te blokkeren.
• Open: Hiermee kan het virtuele netwerk resources voor privékoppelingen en resources die niet in de AMPLS worden bereikt (als ze verkeer van openbare netwerken accepteren). De open-toegangsmodus voorkomt geen gegevensexfiltratie, maar biedt nog steeds de andere voordelen van privékoppelingen. Verkeer naar privékoppelingsbronnen wordt verzonden via privé-eindpunten, gevalideerd en verzonden via de Microsoft-backbone. De open-modus is handig voor een gemengde werkmodus (toegang tot sommige resources openbaar en andere via een privékoppeling) of tijdens een geleidelijk onboardingproces. Toegangsmodi worden afzonderlijk ingesteld voor opname en query's. U kunt bijvoorbeeld de modus Alleen privé instellen voor opname en de modus Openen voor query's.

Wees voorzichtig wanneer u de toegangsmodus selecteert. Als u de modus Alleen privétoegang gebruikt, wordt verkeer naar resources geblokkeerd die zich niet in de AMPLS bevinden in alle netwerken die dezelfde DNS delen, ongeacht het abonnement of de tenant. De uitzondering hierop zijn Log Analytics-opnameaanvragen. Dit wordt uitgelegd. Als u niet alle Azure Monitor-resources aan de AMPLS kunt toevoegen, voegt u eerst geselecteerde resources toe en past u de open-toegangsmodus toe. Schakel over naar de modus Alleen privé voor maximale beveiliging nadat u alle Azure Monitor-resources aan uw AMPLS hebt toegevoegd.

Zie API's en de opdrachtregel gebruiken voor configuratiedetails en voorbeelden.

Notitie

Log Analytics-opname maakt gebruik van resourcespecifieke eindpunten. Als zodanig voldoet het niet aan de AMPLS-toegangsmodi. Om ervoor te zorgen dat Log Analytics-opnameaanvragen geen toegang hebben tot werkruimten uit de AMPLS, stelt u de netwerkfirewall in om verkeer naar openbare eindpunten te blokkeren, ongeacht de AMPLS-toegangsmodi.

Toegangsmodi instellen voor specifieke netwerken

De toegangsmodi die zijn ingesteld op de AMPLS-resource zijn van invloed op alle netwerken, maar u kunt deze instellingen voor specifieke netwerken overschrijven.

In het volgende diagram gebruikt VNet1 de modus Openen en VNet2 maakt gebruik van de modus Alleen privé. Aanvragen van VNet1 kunnen werkruimte 1 en onderdeel 2 bereiken via een privékoppeling. Aanvragen kunnen component 3 alleen bereiken als het verkeer van openbare netwerken accepteert. VNet2-aanvragen kunnen component 3 niet bereiken.

AmpLS-limieten overwegen

Het AMPLS-object heeft de volgende limieten:

• Een virtueel netwerk kan verbinding maken met slechts één AMPLS-object. Dat betekent dat het AMPLS-object toegang moet bieden tot alle Azure Monitor-resources waartoe het virtuele netwerk toegang moet hebben.
• Een AMPLS-object kan maximaal verbinding maken met 300 Log Analytics-werkruimten en 1000 Application Insights-onderdelen.
• Een Azure Monitor-resource (werkruimte of Application Insights-onderdeel of eindpunt voor gegevensverzameling) kan maximaal verbinding maken met vijf AMPLS's.
• Een AMPLS-object kan maximaal verbinding maken met 10 privé-eindpunten.

Notitie

AMPLS-resources die vóór 1 december 2021 zijn gemaakt, ondersteunen slechts 50 resources.

In het volgende diagram ziet u het volgende:

• Elk virtueel netwerk maakt verbinding met slechts één AMPLS-object.
• AMPLS A maakt verbinding met twee werkruimten en één Application Insight-onderdeel met behulp van twee van de mogelijke 300 Log Analytics-werkruimten en een van de mogelijke 1000 Application Insights-onderdelen waarmee deze verbinding kan maken.
• Werkruimte 2 maakt verbinding met AMPLS A en AMPLS B met behulp van twee van de vijf mogelijke AMPLS-verbindingen.
• AMPLS B is verbonden met privé-eindpunten van twee virtuele netwerken (VNet2 en VNet3) met twee van de 10 mogelijke privé-eindpuntverbindingen.

Netwerktoegang tot uw resources beheren

Uw Log Analytics-werkruimten of Application Insights-onderdelen kunnen worden ingesteld op:

• Opname van openbare netwerken accepteren of blokkeren (netwerken die niet zijn verbonden met de resource-AMPLS).
• Accepteer of blokkeer query's van openbare netwerken (netwerken die niet zijn verbonden met de resource-AMPLS).

Met deze granulariteit kunt u toegang instellen op basis van uw behoeften, per werkruimte. U kunt bijvoorbeeld alleen opname accepteren via met private link verbonden netwerken (dat wil zeggen specifieke virtuele netwerken), maar er nog steeds voor kiezen om query's van alle netwerken, openbaar en privé te accepteren.

Het blokkeren van query's vanuit openbare netwerken betekent dat clients zoals machines en SDK's buiten de verbonden AMPLS's geen query's kunnen uitvoeren op gegevens in de resource. Deze gegevens omvatten logboeken, metrische gegevens en de live metrische gegevensstroom. Het blokkeren van query's vanuit openbare netwerken is van invloed op alle ervaringen die deze query's uitvoeren, zoals werkmappen, dashboards, inzichten in Azure Portal en query's die worden uitgevoerd buiten Azure Portal.

Notitie

Er zijn bepaalde uitzonderingen waarbij deze instellingen niet van toepassing zijn. U vindt meer informatie in de volgende sectie.

Uw eindpunten voor gegevensverzameling kunnen worden ingesteld om toegang van openbare netwerken te accepteren of te blokkeren (netwerken die niet zijn verbonden met de resource-AMPLS).

Zie Toegangsvlagken voor resources instellen voor configuratiegegevens.

Uitzonderingen

Let op de volgende uitzonderingen.

Diagnostische logboeken

Logboeken en metrische gegevens die via diagnostische instellingen naar een werkruimte zijn geüpload, gaan via een beveiligd privé-Microsoft-kanaal en worden niet beheerd door deze instellingen.

Aangepaste metrische gegevens van gasten of metrische gegevens van Azure Monitor

Aangepaste metrische gegevens (preview) die zijn verzameld en geüpload via de Azure Monitor-agent, worden niet beheerd door eindpunten voor gegevensverzameling. Ze kunnen niet worden geconfigureerd via privékoppelingen.

Azure Resource Manager

Het beperken van de toegang zoals eerder uitgelegd, is van toepassing op gegevens in de resource. Configuratiewijzigingen, zoals het in- of uitschakelen van deze toegangsinstellingen, worden echter beheerd door Azure Resource Manager. Als u deze instellingen wilt beheren, beperkt u de toegang tot resources met behulp van de juiste rollen, machtigingen, netwerkbeheer en controle. Zie Azure Monitor-rollen, -machtigingen en -beveiliging voor meer informatie.

Notitie

Query's die via de Resource Manager-API worden verzonden, kunnen geen privékoppelingen van Azure Monitor gebruiken. Deze query's kunnen alleen worden uitgevoerd als de doelresource query's van openbare netwerken toestaat (ingesteld via het deelvenster Netwerkisolatie of met behulp van de CLI).

De volgende ervaringen zijn bekend om query's uit te voeren via de Resource Manager-API:

• Logica App-connector
• Oplossing voor updatebeheer
• Traceringsoplossingen wijzigen
• VM Insights
• Container Insights
• Deelvenster Samenvatting van Log Analytics-werkruimte (afgeschaft) (waarin het oplossingsdashboard wordt weergegeven)

Overwegingen voor Application Insights

• U moet resources toevoegen die als host fungeren voor de bewaakte workloads aan een privékoppeling. Zie Bijvoorbeeld Het gebruik van privé-eindpunten voor Azure Web App.
• Niet-portalverbruikservaringen moeten ook worden uitgevoerd op het privé-gekoppelde virtuele netwerk dat de bewaakte workloads bevat.
• Als u privékoppelingen voor profiler en foutopsporingsprogramma wilt ondersteunen, moet u uw eigen opslagaccount opgeven.

Notitie

Als u Application Insights op basis van een werkruimte volledig wilt beveiligen, moet u de toegang tot de Application Insights-resource en de onderliggende Log Analytics-werkruimte vergrendelen.

Overwegingen voor Log Analytics

Let op de volgende Log Analytics-overwegingen.

Log Analytics-oplossingspakketten downloaden

Log Analytics-agents moeten toegang hebben tot een globaal opslagaccount om oplossingspakketten te downloaden. Setups van Private Link die zijn gemaakt op of na 19 april 2021 (of vanaf juni 2021 op onafhankelijke Azure-clouds) kunnen de opslag van de oplossingspakketten van de agents bereiken via de privékoppeling. Deze mogelijkheid wordt mogelijk gemaakt via een DNS-zone die is gemaakt voor blob.core.windows.net.

Als de installatie van uw private link vóór 19 april 2021 is gemaakt, wordt de opslag van solution packs niet bereikt via een privékoppeling. Hiervoor kunt u het volgende doen:

• Maak uw AMPLS en het privé-eindpunt dat ermee is verbonden opnieuw.

• Sta toe dat uw agents het opslagaccount bereiken via het openbare eindpunt door de volgende regels toe te voegen aan de acceptatielijst van uw firewall:

  Cloudomgeving	Agentresource	Poorten	Richting
  Azure openbaar	scadvisorcontent.blob.core.windows.net	443	Uitgaand
  Azure Government	usbn1oicore.blob.core.usgovcloudapi.net	443	Uitgaand
  Microsoft Azure beheerd door 21Vianet	mceast2oicore.blob.core.chinacloudapi.cn	443	Uitgaand

Aangepaste logboeken en IIS-logboeken verzamelen via een privékoppeling

Opslagaccounts worden gebruikt in het opnameproces van aangepaste logboeken. Standaard worden door de service beheerde opslagaccounts gebruikt. Als u aangepaste logboeken wilt opnemen in privékoppelingen, moet u uw eigen opslagaccounts gebruiken en deze koppelen aan Log Analytics-werkruimten.

Zie Opslagaccounts in eigendom van de klant voor logboekopname en gebruik privékoppelingen en koppel opslagaccounts aan uw Log Analytics-werkruimte voor meer informatie over het verbinden van uw eigen opslagaccount.

Automatisering

Als u Log Analytics-oplossingen gebruikt waarvoor een Azure Automation-account is vereist (zoals Updatebeheer, Wijzigingen bijhouden of Inventaris), moet u ook een privékoppeling voor uw Automation-account maken. Zie Azure Private Link gebruiken om netwerken veilig te verbinden met Azure Automation voor meer informatie.

Notitie

In sommige producten en Azure Portal worden query's uitgevoerd op gegevens via Resource Manager. In dit geval kunnen ze geen query's uitvoeren op gegevens via een privékoppeling, tenzij de instellingen van private link ook worden toegepast op Resource Manager. U kunt deze beperking oplossen door uw resources zo te configureren dat query's van openbare netwerken worden geaccepteerd, zoals wordt uitgelegd in Netwerktoegang tot uw resources beheren. (Opname kan beperkt blijven tot private link-netwerken.) We hebben de volgende producten en ervaringen met querywerkruimten geïdentificeerd via Resource Manager:

• Logica App-connector
• Oplossing voor updatebeheer
• Traceringsoplossingen wijzigen
• Het deelvenster Werkruimteoverzicht (afgeschaft) in de portal (waarin het dashboard met oplossingen wordt weergegeven)
• VM Insights
• Container Insights

Overwegingen voor beheerde Prometheus

• De opname-instellingen van Private Link worden gemaakt met BEHULP van AMPLS en instellingen op de DCE's (Gegevensverzamelingseindpunten) die verwijzen naar de Azure Monitor-werkruimte die wordt gebruikt voor het opslaan van uw metrische Prometheus-gegevens.
• Query-instellingen van Private Link worden rechtstreeks gemaakt in de Azure Monitor-werkruimte die wordt gebruikt voor het opslaan van uw metrische Prometheus-gegevens en worden niet verwerkt via AMPLS.

Vereisten

Let op de volgende vereisten.

Grootte van netwerksubnet

Het kleinste ondersteunde IPv4-subnet is /27 (met CIDR-subnetdefinities). Hoewel virtuele Netwerken van Azure net zo klein kunnen zijn als /29, reserveert Azure vijf IP-adressen. Voor het instellen van de privékoppeling van Azure Monitor zijn ten minste 11 meer IP-adressen vereist, zelfs als u verbinding maakt met één werkruimte. Controleer de DNS-instellingen van uw eindpunt voor de lijst met Azure Monitor Private Link-eindpunten.

Agents

De nieuwste versies van de Windows- en Linux-agents moeten worden gebruikt om veilige opname in Log Analytics-werkruimten te ondersteunen. Oudere versies kunnen bewakingsgegevens niet uploaden via een particulier netwerk.

Azure Monitor Windows-agents

Azure Monitor Windows-agent versie 1.1.1.0 of hoger (met behulp van eindpunten voor gegevensverzameling).

Azure Monitor Linux-agents

Azure Monitor Windows-agent versie 1.10.5.0 of hoger (met behulp van eindpunten voor gegevensverzameling).

Log Analytics Windows-agent (op afschaffingspad)

Gebruik de Log Analytics-agent versie 10.20.18038.0 of hoger.

Log Analytics Linux-agent (op afschaffingspad)

Gebruik agentversie 1.12.25 of hoger. Als u dat niet kunt, voert u de volgende opdrachten uit op uw VIRTUELE machine:

$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>

Azure Portal

Als u azure Monitor Portal-ervaringen zoals Application Insights, Log Analytics en eindpunten voor gegevensverzameling wilt gebruiken, moet u toestaan dat azure Portal- en Azure Monitor-extensies toegankelijk zijn op de privénetwerken. Voeg AzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty en AzureFrontdoor.Frontend-servicetags toe aan uw netwerkbeveiligingsgroep.

Programmatische toegang

Als u de REST API, de Azure CLI of PowerShell wilt gebruiken met Azure Monitor in privénetwerken, voegt u de servicetagsAzureActiveDirectory en AzureResourceManager toe aan uw firewall.

Application Insights SDK downloadt vanuit een netwerk voor contentlevering

Bundel de JavaScript-code in uw script zodat de browser geen code probeert te downloaden van een CDN. Er wordt een voorbeeld gegeven op GitHub.

DNS-instellingen voor browser

Als u via een privékoppeling verbinding maakt met uw Azure Monitor-resources, moet verkeer naar deze resources via het privé-eindpunt dat is geconfigureerd op uw netwerk, doorlopen. Als u het privé-eindpunt wilt inschakelen, werkt u uw DNS-instellingen bij zoals uitgelegd in Verbinding maken naar een privé-eindpunt. Sommige browsers gebruiken hun eigen DNS-instellingen in plaats van de instellingen die u instelt. De browser kan proberen verbinding te maken met openbare Azure Monitor-eindpunten en de privékoppeling volledig omzeilen. Controleer of uw browserinstellingen oude DNS-instellingen niet overschrijven of in de cache opslaan.

Beperking van query's: operator externaldata

• De externaldata operator wordt niet ondersteund via een privékoppeling omdat deze gegevens leest uit opslagaccounts, maar niet garandeert dat de opslag privé wordt geopend.
• Met de Azure Data Explorer-proxy (ADX-proxy) kunnen logboekquery's query's uitvoeren op Azure Data Explorer. De ADX-proxy wordt niet ondersteund via een privékoppeling, omdat hiermee niet wordt gegarandeerd dat de doelresource privé wordt geopend.

Volgende stappen

• Meer informatie over het configureren van uw privékoppeling.
• Meer informatie over privéopslag voor aangepaste logboeken en door de klant beheerde sleutels.
• Meer informatie over Private Link voor Automatisering.