Dela via

Utforma din Azure Private Link-konfiguration

  • Artikel

Innan du konfigurerar din instans av Azure Private Link bör du överväga nätverkstopologin och DNS-routningstopologin.

Enligt beskrivningen i Använda Azure Private Link för att ansluta nätverk till Azure Monitor påverkar konfigurationen av en privat länk trafiken till alla Azure Monitor-resurser. Det gäller särskilt för Application Insights-resurser. Det påverkar också inte bara nätverket som är anslutet till den privata slutpunkten utan även alla andra nätverk som delar samma DNS.

Den enklaste och säkraste metoden:

  1. Skapa en enskild privat länkanslutning med en enda privat slutpunkt och ett enda Azure Monitor Private Link-omfång (AMPLS). Om dina nätverk är peer-kopplade skapar du den privata länkanslutningen i det delade virtuella nätverket (eller hubben).
  2. Lägg till alla Azure Monitor-resurser som Application Insights-komponenter, Log Analytics-arbetsytor och slutpunkter för datainsamling i AMPLS.
  3. Blockera utgående nätverkstrafik så mycket som möjligt.

Om du inte kan lägga till alla Azure Monitor-resurser i AMPLS kan du fortfarande använda din privata länk för vissa resurser, enligt beskrivningen i Kontrollera hur privata länkar gäller för dina nätverk. Vi rekommenderar inte den här metoden eftersom den inte förhindrar dataexfiltrering.

Planera efter nätverkstopologi

Överväg nätverkstopologi i planeringsprocessen.

Vägledande princip: 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 uppdaterar du DNS:en och påverkar trafiken i alla nätverk genom att konfigurera en privat länk på någon av dem.

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.

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

Kommentar

Du kanske föredrar att skapa separata privata länkar för dina virtuella ekernätverk, till exempel för att ge varje virtuellt nätverk åtkomst till en begränsad uppsättning övervakningsresurser. I sådana fall 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.

Peer-kopplade nätverk

Nätverkspeering används i olika topologier, förutom hubb och eker. Sådana nätverk kan dela varandras IP-adresser och förmodligen dela samma DNS. I sådana fall 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 det i slutändan bara gäller den sista uppsättningen i DNS.

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. När det är klart skapar du 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.

Testa lokalt: Redigera datorns värdfil i stället för DNS

Om du vill testa privata länkar lokalt utan att påverka andra klienter i nätverket måste du inte uppdatera dns-koden när du skapar din privata slutpunkt. Redigera i stället värdfilen på datorn så att den skickar begäranden till de privata länkslutpunkterna:

  • Konfigurera en privat länk, men när du ansluter till en privat slutpunkt väljer du att inte integrera automatiskt med DNS (steg 5b).
  • Konfigurera relevanta slutpunkter på dina datorers värdfiler. Mer information om hur du granskar de Azure Monitor-slutpunkter som behöver mappning finns i Granska din slutpunkts DNS-inställningar.

Vi rekommenderar inte den metoden för produktionsmiljöer.

Genom att använda åtkomstlägen för privata länkar kan du styra hur privata länkar påverkar nätverkstrafiken. De här inställningarna kan gälla för ditt AMPLS-objekt (för att påverka alla anslutna nätverk) eller för specifika nätverk som är anslutna till det.

Att välja rätt åtkomstläge är viktigt för att säkerställa kontinuerlig, oavbruten nätverkstrafik. Var och en av dessa lägen kan anges för inmatning och frågor, separat:

  • Endast privat: Tillåter att det virtuella nätverket endast når privata länkresurser (resurser i AMPLS). Det är det säkraste arbetssättet. Det förhindrar dataexfiltrering genom att blockera trafik från AMPLS till Azure Monitor-resurser. Diagram som visar ampls-läget endast privat åtkomst.
  • Öppen: Tillåter att det virtuella nätverket når 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, verifieras och skickas via Microsofts stamnät. Läget Öppna är användbart för ett blandat arbetsläge (åtkomst till vissa resurser offentligt och andra via en privat länk) eller under en gradvis registreringsprocess. Diagram som visar LÄGET FÖR ÖPPEN ÅTKOMST I AMPLS. Å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.

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. Undantaget är Log Analytics-inmatningsbegäranden, vilket förklaras. 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.

Konfigurationsinformation och exempel finns i Använda API:er och kommandoraden.

Kommentar

Log Analytics-inmatning använder resursspecifika slutpunkter. Därför följer den inte 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.

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.

Överväg AMPLS-gränser

AMPLS-objektet 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 300 Log Analytics-arbetsytor och högst 1 000 Application Insights-komponenter.
  • En Azure Monitor-resurs (arbetsyta eller Application Insights-komponent eller slutpunkt för datainsamling) kan ansluta till högst fem AMPLS.
  • Ett AMPLS-objekt kan ansluta till högst 10 privata slutpunkter.

Kommentar

AMPLS-resurser som skapats före den 1 december 2021 stöder endast 50 resurser.

I följande diagram:

  • Varje virtuellt nätverk ansluter endast till ett AMPLS-objekt.
  • AMPLS A ansluter till två arbetsytor och en Application Insight-komponent med hjälp av två av de möjliga 300 Log Analytics-arbetsytorna och en av de möjliga 1 000 Application Insights-komponenter som den kan ansluta till.
  • Arbetsytan 2 ansluter till AMPLS A och AMPLS B med hjälp av två av de fem möjliga AMPLS-anslutningarna.
  • AMPLS B är anslutet till privata slutpunkter för två virtuella nätverk (VNet2 och VNet3) med hjälp av två av de tio möjliga privata slutpunktsanslutningarna.

Diagram som visar AMPLS-gränser.

Kontrollera nätverksåtkomsten till dina resurser

Dina Log Analytics-arbetsytor eller Application Insights-komponenter kan ställas in på:

  • 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 kornigheten kan du ange åtkomst enligt dina behov, per arbetsyta. Du kan till exempel bara acceptera inmatning via privata länkanslutna nätverk (vilket innebär specifika virtuella nätverk) men ändå välja att acceptera frågor från alla nätverk, offentliga och privata.

Att blockera frågor från offentliga nätverk innebär att klienter som datorer och SDK:er utanför de 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.

Kommentar

Det finns vissa undantag där de här inställningarna inte gäller. Du hittar information i följande avsnitt.

Dina slutpunkter för datainsamling kan ställas in på att acceptera eller blockera åtkomst från offentliga nätverk (nätverk som inte är anslutna till resursen AMPLS).

Konfigurationsinformation finns i Ange resursåtkomstflaggor.

Undantag

Observera följande undantag.

Diagnostikloggar

Loggar och mått som laddas upp till en arbetsyta via diagnostikinställningar går via 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 (förhandsversion) som samlas in och laddas upp via Azure Monitor Agent styrs inte av slutpunkter för datainsamling. De kan inte konfigureras via privata länkar.

Azure Resource Manager

Att begränsa åtkomsten enligt tidigare beskrivning gäller för data i resursen. Konfigurationsändringar som att aktivera eller inaktivera dessa åtkomstinställningar hanteras dock av Azure Resource Manager. Om du vill styra de här inställningarna begränsar du åtkomsten till resurser med hjälp av lämpliga roller, behörigheter, nätverkskontroller och granskning. Mer information finns i Roller, behörigheter och säkerhet i Azure Monitor.

Kommentar

Frågor som skickas via Resource Manager-API:et kan inte använda privata Azure Monitor-länkar. Dessa frågor kan bara gå igenom om målresursen tillåter frågor från offentliga nätverk (anges via fönstret Nätverksisolering eller med hjälp av CLI).

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)

Överväganden för Application Insights

  • Du måste lägga till resurser som är värdar för de övervakade arbetsbelastningarna i 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.
  • Om du vill ha stöd för privata länkar för Profiler och felsökningsprogrammet måste du ange ett eget lagringskonto.

Kommentar

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

Log Analytics-överväganden

Observera följande Log Analytics-överväganden.

Nedladdning av Log Analytics-lösningspaket

Log Analytics-agenter måste ha åtkomst till ett globalt lagringskonto för att ladda ned lösningspaket. Konfigurationer av privata länkar som skapades den 19 april 2021 (eller från och med juni 2021 i nationella Azure-moln) kan nå agenternas lagring av lösningspaket via den privata länken. Den här funktionen möjliggörs via en DNS-zon som skapats för blob.core.windows.net.

Om konfigurationen av den privata länken skapades före den 19 april 2021 når den inte lagringen av lösningspaket via en privat länk. För att hantera det kan du antingen:

  • Återskapa AMPLS och den privata slutpunkten som är ansluten till den.

  • Tillåt att dina agenter når lagringskontot via sin offentliga slutpunkt genom att lägga till följande regler i listan över tillåtna brandväggar:

    Molnmiljö Agentresurs Portar Riktning
    Azure Public scadvisorcontent.blob.core.windows.net 443 Utgående
    Azure Government usbn1oicore.blob.core.usgovcloudapi.net 443 Utgående
    Microsoft Azure drivs av 21Vianet mceast2oicore.blob.core.chinacloudapi.cn 443 Utgående

Lagringskonton används i inmatningsprocessen för anpassade loggar. Som standard används tjänsthanterade lagringskonton. Om du vill mata in anpassade loggar på privata länkar måste du använda dina egna lagringskonton och associera dem med Log Analytics-arbetsytor.

Mer information om hur du ansluter ditt eget lagringskonto finns i Kundägda lagringskonton för logginmatning och specifikt Använda privata länkar och Länka lagringskonton till din Log Analytics-arbetsyta.

Automation

Om du använder Log Analytics-lösningar som kräver ett Azure Automation-konto (till exempel Uppdateringshantering, Ändringsspårning eller Inventering) bör du också skapa en privat länk för ditt Automation-konto. Mer information finns i Använda Azure Private Link för att ansluta nätverk till Azure Automation på ett säkert sätt.

Kommentar

Vissa produkter och Azure Portal har frågedata via Resource Manager. I det här fallet kan de inte köra frågor mot data via en privat länk om inte inställningarna för privata länkar tillämpas även på Resource Manager. Du kan lösa den här begränsningen genom att konfigurera dina resurser så att de accepterar frågor från offentliga nätverk enligt beskrivningen i Kontrollera nätverksåtkomst till dina resurser. (Inmatning kan förbli begränsad till privata länknätverk.) Vi har identifierat följande produkter och funktioner för att fråga arbetsytor via Resource Manager:

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

Överväganden för hanterad 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 dina 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 via AMPLS.

Krav

Observera följande krav.

Nätverksundernätsstorlek

Det minsta IPv4-undernätet som stöds är /27 (med CIDR-undernätsdefinitioner). Även om virtuella Azure-nätverk kan vara så små som /29 reserverar Azure fem IP-adresser. Konfigurationen av privat länk i Azure Monitor kräver minst 11 IP-adresser till, även om du ansluter till en enda arbetsyta. Granska din slutpunkts DNS-inställningar för listan över slutpunkter för privata Azure Monitor-länkar.

Handläggare

De senaste versionerna av Windows- och Linux-agenterna måste användas för säker inmatning till Log Analytics-arbetsytor. Äldre versioner kan inte ladda upp övervakningsdata via ett privat nätverk.

Azure Monitor Windows-agenter

Azure Monitor Windows-agent version 1.1.1.0 eller senare (med hjälp av slutpunkter för datainsamling).

Azure Monitor Linux-agenter

Azure Monitor Linux-agent version 1.10.5.0 eller senare (med hjälp av datainsamlingsslutpunkter).

Log Analytics Windows-agent (inaktuell)

Använd Log Analytics-agenten version 10.20.18038.0 eller senare.

Log Analytics Linux-agent (inaktuell)

Använd agentversion 1.12.25 eller senare. Om du inte kan kör du följande kommandon på den virtuella datorn:

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

Azure Portal

Om du vill använda Azure Monitor-portalen, till exempel Application Insights, Log Analytics och slutpunkter för datainsamling, måste du tillåta att tilläggen Azure Portal och Azure Monitor är tillgängliga i de privata nätverken. Lägg till tjänsttaggar för AzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty och AzureFrontdoor.Frontend i nätverkssäkerhetsgruppen.

Programmatisk åtkomst

Om du vill använda REST-API:et, Azure CLI eller PowerShell med Azure Monitor i privata nätverk lägger du till tjänsttaggarna AzureActiveDirectory och AzureResourceManager i brandväggen.

Application Insights SDK-nedladdningar från ett nätverk för innehållsleverans

Paketera JavaScript-koden i skriptet så att webbläsaren inte försöker ladda ned kod från ett CDN. Ett exempel finns på GitHub.

DNS-inställningar för webbläsare

Om du ansluter till dina Azure Monitor-resurser via en privat länk måste trafik till dessa resurser gå via den privata slutpunkten som har konfigurerats i nätverket. Om du vill aktivera den privata slutpunkten uppdaterar du DNS-inställningarna enligt beskrivningen i Anslut till en privat slutpunkt. Vissa webbläsare använder sina egna DNS-inställningar i stället för de som du anger. Webbläsaren kan försöka ansluta till offentliga Azure Monitor-slutpunkter och kringgå den privata länken helt. Kontrollera att webbläsarinställningarna inte åsidosätter eller cachelagr gamla DNS-inställningar.

Frågebegränsning: externaldataoperator

  • Operatorn externaldata stöds inte via en privat länk eftersom den läser data från lagringskonton men inte garanterar att lagringen nås privat.
  • Med Azure Data Explorer-proxyn (ADX-proxy) kan loggfrågor köra frågor mot Azure Data Explorer. ADX-proxyn stöds inte via en privat länk eftersom den inte garanterar att målresursen nås privat.

Nästa steg