Dela via


Utforma Azure Monitor Private Link-konfiguration

När du skapar ett Azure Monitor Private Link-omfång (AMPLS) begränsar du åtkomsten till Azure Monitor-resurser till endast de nätverk som är anslutna till den privata slutpunkten. Den här artikeln innehåller vägledning om hur du utformar konfigurationen av din privata Azure Monitor-länk och andra överväganden som du bör ta hänsyn till innan du implementerar den med hjälp av vägledningen i Konfigurera privat länk för Azure Monitor.

AMPLS-gränser

AMPLS-objekt har följande gränser:

  • Ett virtuellt nätverk kan bara ansluta till ett AMPLS-objekt. Det innebär att AMPLS-objektet måste ge åtkomst till alla Azure Monitor-resurser som det virtuella nätverket ska ha åtkomst till.
  • Ett AMPLS-objekt kan ansluta till upp till 300 Log Analytics-arbetsytor och upp till 1 000 Application Insights-komponenter.
  • En Azure Monitor-resurs kan ansluta till upp till fem AMPLS.
  • Ett AMPLS-objekt kan ansluta till upp till 10 privata slutpunkter.

Planera efter nätverkstopologi

I följande avsnitt beskrivs hur du planerar konfigurationen av din privata Azure Monitor-länk baserat på nätverkstopologin.

Undvik DNS-åsidosättningar med hjälp av en enda AMPLS

Vissa nätverk består av flera virtuella nätverk eller andra anslutna nätverk. Om dessa nätverk delar samma DNS skulle konfigurationen av en privat länk på någon av dem uppdatera DNS:en och påverka trafiken i alla nätverk.

I följande diagram ansluter det virtuella nätverket 10.0.1.x till AMPLS1, vilket skapar DNS-poster som mappar Azure Monitor-slutpunkter till IP-adresser från intervallet 10.0.1.x. Senare ansluter det virtuella nätverket 10.0.2.x till AMPLS2, vilket åsidosätter samma DNS-poster genom att mappa samma globala/regionala slutpunkter till IP-adresser från intervallet 10.0.2.x. Eftersom dessa virtuella nätverk inte är peer-kopplade kan det första virtuella nätverket nu inte nå dessa slutpunkter. Undvik den här konflikten genom att bara skapa ett enda AMPLS-objekt per DNS.

Diagram som visar DNS-åsidosättningar i flera virtuella nätverk.

Hub-and-spoke-nätverk

Hub-and-spoke-nätverk bör använda en enda privat länkanslutningsuppsättning i hubbnätverket (huvudnätverket) och inte i varje virtuellt ekernätverk.

Du kanske föredrar att skapa separata privata länkar för dina virtuella ekernätverk så att varje virtuellt nätverk kan komma åt en begränsad uppsättning övervakningsresurser. I det här fallet kan du skapa en dedikerad privat slutpunkt och AMPLS för varje virtuellt nätverk. Du måste också kontrollera att de inte delar samma DNS-zoner för att undvika DNS-åsidosättningar.

Diagram som visar en nav-och-eker-enskild privat länk.

Peer-kopplade nätverk

Med nätverkspeering kan nätverk dela varandras IP-adresser och troligen dela samma DNS. I det här fallet skapar du en enda privat länk i ett nätverk som är tillgängligt för dina andra nätverk. Undvik att skapa flera privata slutpunkter och AMPLS-objekt eftersom endast den sista uppsättningen i DNS gäller.

Isolerade nätverk

Om dina nätverk inte är peer-kopplade måste du också separera deras DNS för att använda privata länkar. Du kan sedan skapa en separat privat slutpunkt för varje nätverk och ett separat AMPLS-objekt. AMPLS-objekten kan länka till samma arbetsytor/komponenter eller till olika.

Välj ett åtkomstläge

Med åtkomstlägen för privata länkar kan du styra hur privata länkar påverkar nätverkstrafiken. Det du väljer är viktigt för att säkerställa kontinuerlig, oavbruten nätverkstrafik.

Åtkomstlägen kan gälla för alla nätverk som är anslutna till din AMPLS eller för specifika nätverk som är anslutna till den. Åtkomstlägen anges separat för inmatning och frågor. Du kan till exempel ange läget Endast privat för inmatning och öppet läge för frågor.

Viktigt!

Log Analytics-inmatning använder resursspecifika slutpunkter så att den inte följer AMPLS-åtkomstlägen. För att säkerställa att Log Analytics-inmatningsbegäranden inte kan komma åt arbetsytor från AMPLS ställer du in nätverksbrandväggen för att blockera trafik till offentliga slutpunkter, oavsett AMPLS-åtkomstlägen.

Åtkomstläge endast privat

Med det här läget kan det virtuella nätverket endast nå privata länkresurser i AMPLS. Det här är det säkraste alternativet och förhindrar dataexfiltrering genom att blockera trafik från AMPLS till Azure Monitor-resurser.

Diagram som visar ampls-läget endast privat åtkomst.

Öppna åtkomstläge

Med det här läget kan det virtuella nätverket nå både privata länkresurser och resurser som inte finns i AMPLS (om de accepterar trafik från offentliga nätverk). Läget Öppna åtkomst förhindrar inte dataexfiltrering, men det erbjuder fortfarande de andra fördelarna med privata länkar. Trafik till privata länkresurser skickas via privata slutpunkter innan den verifieras och skickas sedan via Microsofts stamnät. Läget Öppna är användbart för blandat läge där vissa resurser används offentligt och andra nås via en privat länk. Det kan också vara användbart under en gradvis registreringsprocess.

Diagram som visar LÄGET FÖR ÖPPEN ÅTKOMST I AMPLS.

Viktigt!

Var försiktig när du väljer åtkomstläge. Om du använder åtkomstläget Endast privat blockeras trafik till resurser som inte finns i AMPLS i alla nätverk som delar samma DNS oavsett prenumeration eller klientorganisation. Om du inte kan lägga till alla Azure Monitor-resurser i AMPLS börjar du med att lägga till utvalda resurser och tillämpa läget Öppna åtkomst. Växla till läget Endast privat för maximal säkerhet endast när du har lagt till alla Azure Monitor-resurser i AMPLS.

Ange åtkomstlägen för specifika nätverk

De åtkomstlägen som anges på AMPLS-resursen påverkar alla nätverk, men du kan åsidosätta de här inställningarna för specifika nätverk.

I följande diagram använder VNet1 läget Öppna och VNet2 använder läget Endast privat. Begäranden från VNet1 kan nå Arbetsyta 1 och Komponent 2 via en privat länk. Begäranden kan endast nå komponent 3 om den accepterar trafik från offentliga nätverk. VNet2-begäranden kan inte nå Komponent 3.

Diagram som visar blandade åtkomstlägen.

Kontrollera nätverksåtkomst till AMPLS-resurser

Azure Monitor-komponenter kan anges till antingen:

  • Acceptera eller blockera inmatning från offentliga nätverk (nätverk som inte är anslutna till resursen AMPLS).
  • Acceptera eller blockera frågor från offentliga nätverk (nätverk som inte är anslutna till resursen AMPLS).

Med den här kornigheten kan du ange åtkomst per arbetsyta enligt dina specifika behov. Du kan till exempel bara acceptera inmatning via privata länkanslutna nätverk men ändå välja att acceptera frågor från alla nätverk, offentliga och privata.

Kommentar

Att blockera frågor från offentliga nätverk innebär att klienter som datorer och SDK:er utanför den anslutna AMPLS inte kan köra frågor mot data i resursen. Dessa data inkluderar loggar, mått och live-måttströmmen. Blockering av frågor från offentliga nätverk påverkar alla funktioner som kör dessa frågor, till exempel arbetsböcker, instrumentpaneler, insikter i Azure Portal och frågor som körs utanför Azure Portal.

Följande är undantag från den här nätverksåtkomsten:

  • Diagnostikloggar. Loggar och mått som skickas till en arbetsyta från en diagnostikinställning finns över en säker privat Microsoft-kanal och styrs inte av de här inställningarna.
  • Anpassade mått eller Azure Monitor-gästmått. Anpassade mått som skickas från Azure Monitor-agenten styrs inte av domänkontrollanter och kan inte konfigureras via privata länkar.

Kommentar

Frågor som skickas via Resource Manager-API:et kan inte använda privata Azure Monitor-länkar. Dessa frågor kan bara få åtkomst om målresursen tillåter frågor från offentliga nätverk.

Följande funktioner är kända för att köra frågor via Resource Manager-API:et:

  • Logik Anslutningsverktyg
  • Uppdateringshanteringslösning
  • Ändra spårningslösning
  • VM-insikter
  • Containerinsikter
  • Fönstret Sammanfattning av Log Analytics-arbetsyta (inaktuell) (som visar instrumentpanelen för lösningar)

Särskilda beaktanden

Programinsikter

  • Lägg till resurser som är värdar för de övervakade arbetsbelastningarna till en privat länk. Se till exempel Använda privata slutpunkter för Azure Web App.
  • Användningsupplevelser som inte är portalen måste också köras i det privata länkade virtuella nätverket som innehåller de övervakade arbetsbelastningarna.
  • Ange ett eget lagringskonto för att stödja privata länkar för .NET Profiler och felsökningsprogrammet.

Kommentar

För att helt skydda arbetsytebaserade Application Insights kan du låsa åtkomsten till Application Insights-resursen och den underliggande Log Analytics-arbetsytan.

Managed Prometheus

  • Inmatningsinställningar för Private Link görs med hjälp av AMPLS och inställningar på de datainsamlingsslutpunkter (DCE) som refererar till Azure Monitor-arbetsytan som används för att lagra Prometheus-mått.
  • Private Link-frågeinställningar görs direkt på Azure Monitor-arbetsytan som används för att lagra Prometheus-mått och hanteras inte med AMPLS.

Nästa steg