Entwerfen Ihres Azure Private Link-Setups

Vor dem Einrichten Ihrer Instanz von Azure Private Link sollten Sie Ihre Netzwerktopologie und insbesondere Ihre DNS-Routingtopologie berücksichtigen.

Wie in Verwenden von Azure Private Link zum Verbinden von Netzwerken mit Azure Monitor erläutert, wirkt sich das Einrichten einer privaten Verbindung auf den Datenverkehr zu allen Azure Monitor-Ressourcen aus. Dies gilt insbesondere für Application Insights-Ressourcen. Außerdem ist nicht nur das mit dem privaten Endpunkt verbundene Netzwerk betroffen, sondern auch alle anderen Netzwerke, die das gleiche DNS verwenden.

Der einfachste und sicherste Ansatz:

1. Erstellen Sie eine Private Link-Verbindung mit einem einzelnen privaten Endpunkt und einem einzelnen Azure Monitor Private Link-Bereich (AMPLS). Wenn für Ihre Netzwerke ein Peer vorhanden ist, erstellen Sie die Private Link-Verbindung im freigegebenen virtuellen Netzwerk (oder im Hub).
2. Fügen Sie dem AMPLS alle Azure Monitor-Ressourcen wie z. B. Application Insights-Komponenten oder Log Analytics-Arbeitsbereiche und Datensammlungsendpunkte hinzu.
3. Blockieren Sie den ausgehenden Netzwerkdatenverkehr so weit wie möglich.

Wenn Sie Ihrem AMPLS nicht alle Azure Monitor-Ressourcen hinzufügen können, können Sie Ihre private Verbindung dennoch auf einige Ressourcen anwenden, wie unter Steuern, wie private Verbindungen auf Ihre Netzwerke angewendet werden erläutert. Wir empfehlen diesen Ansatz nicht, da dies die Datenexfiltration nicht verhindert.

Planen nach Netzwerktopologie

Berücksichtigen Sie die Netzwerktopologie in Ihrem Planungsprozess.

Leitprinzip: Vermeiden Sie DNS-Außerkraftsetzungen mithilfe einer einzelnen AMPLS-Instanz.

Einige Netzwerke bestehen aus mehreren virtuellen Netzwerken oder anderen verbundenen Netzwerken. Wenn diese Netzwerke das gleiche DNS nutzen, würde das Einrichten einer privaten Verbindung für eines der Netzwerke das DNS aktualisieren und sich auf den Datenverkehr in allen Netzwerken auswirken.

Im folgenden Diagramm stellt VNet 10.0.1.x eine Verbindung mit AMPLS1 her, welches DNS-Einträge erstellt, die Azure Monitor-Endpunkten IP-Adressen aus dem Bereich 10.0.1.x zuordnen. Später stellt das VNet 10.0.2.x eine Verbindung mit AMPLS2 her, wodurch die gleichen DNS-Einträge überschrieben werden, indem die gleichen globalen/regionalen Endpunkte IP-Adressen aus dem Bereich 10.0.2.x zugeordnet werden. Da diese virtuellen Netzwerke über keinen Peer verfügt, kann das erste virtuelle Netzwerk diese Endpunkte jetzt nicht mehr erreichen.

Um diesen Konflikt zu vermeiden, erstellen Sie nur ein einzelnes AMPLS-Objekt pro DNS.

Hub-and-Spoke-Netzwerke

Hub-and-Spoke-Netzwerke sollten eine einzelne Private Link-Verbindung verwenden, die auf das Hubnetzwerk (Hauptnetzwerk) und nicht auf jedes virtuelle Spoke-Netzwerk festgelegt wird.

Hinweis

Möglicherweise ziehen Sie es vor, separate private Verbindungen für Ihre virtuellen Spoke-Netzwerke zu erstellen, um beispielsweise jedem virtuellen Netzwerk den Zugriff auf eine begrenzte Anzahl von Überwachungsressourcen zu ermöglichen. In solchen Fällen können Sie einen dedizierten privaten Endpunkt und AMPLS für jedes virtuelle Netzwerk erstellen. Sie müssen auch sicherstellen, dass sie nicht dieselben DNS-Zonen verwenden, um DNS-Außerkraftsetzungen zu vermeiden.

Netzwerke mit Peering

Das Peering von Netzwerken wird in verschiedenen Topologien verwendet, nicht nur in Hub-and-Spoke. Solche Netzwerke können die gegenseitigen IP-Adressen teilen, und sie nutzen wahrscheinlich dasselbe DNS. Erstellen Sie in solchen Fällen eine einzelne private Verbindung in einem Netzwerk, auf das von Ihren anderen Netzwerke zugegriffen werden kann. Vermeiden Sie es, mehrere private Endpunkte und AMPLS-Objekte zu erstellen, da letztlich nur der zuletzt festgelegte im DNS gilt.

Isolierte Netzwerke

Wenn für Ihre Netzwerke kein Peer vorhanden ist, müssen Sie auch deren DNS trennen, um private Verbindungen verwenden zu können. Danach erstellen Sie für jedes Netzwerk einen eigenen privaten Endpunkt und ein eigenes AMPLS-Objekt. Ihre AMPLS-Objekte können mit denselben oder anderen Arbeitsbereichen/Komponenten verknüpft sein.

Lokales Testen: Bearbeiten der Hostdatei Ihres Computers anstelle des DNS

Um private Verbindungen lokal zu testen, ohne andere Clients in Ihrem Netzwerk zu beeinträchtigen, stellen Sie sicher, dass Sie Ihr DNS nicht aktualisieren, wenn Sie Ihren privaten Endpunkt erstellen. Bearbeiten Sie stattdessen die Datei „hosts“ auf Ihrem Computer, damit er Anforderungen an die Endpunkte Ihrer privaten Verbindung sendet:

• Richten Sie eine private Verbindung ein, aber wählen Sie bei der Verbindung mit einem privaten Endpunkt aus, dass die automatische Integration mit dem DNS (Schritt 5b) nicht erfolgen soll.
• Konfigurieren Sie die relevanten Endpunkte in den Hostdateien Ihrer Computer. Informationen zum Überprüfen der Azure Monitor-Endpunkte, die zugeordnet werden müssen, finden Sie unter Überprüfen der DNS-Einstellungen Ihres Endpunkts.

Wir empfehlen diesen Ansatz nicht für Produktionsumgebungen.

Steuern der Anwendung privater Verbindungen auf Ihre Netzwerke

Mithilfe von Zugriffsmodi für private Verbindungen können Sie steuern, wie sich private Verbindungen auf Ihren Netzwerkdatenverkehr auswirken. Diese Einstellungen können für Ihr AMPLS-Objekt (für alle verbundenen Netzwerke) oder für bestimmte Netzwerke gelten, die mit ihm verbunden sind.

Die Wahl des richtigen Zugriffsmodus ist wichtig, um kontinuierlichen, ununterbrochenen Netzwerkdatenverkehr sicherzustellen. Jeder dieser Modi kann für Datenerfassung und Abfragen getrennt festgelegt werden:

• Nur privat: Ermöglicht es dem virtuellen Netzwerk, nur Private Link-Ressourcen (Ressourcen im AMPLS) zu erreichen. Das ist die sicherste Arbeitsweise. Es verhindert die Datenexfiltration, indem Datenverkehr aus dem AMPLS an Azure Monitor-Ressourcen blockiert wird.
• Offen: Ermöglicht es dem virtuellen Netzwerk, sowohl Private Link-Ressourcen als auch Ressourcen außerhalb des AMPLS zu erreichen (wenn sie Datenverkehr aus öffentlichen Netzwerken akzeptieren). Der Zugriffsmodus „Offen“ verhindert keine Datenexfiltration, bietet aber dennoch die anderen Nutzen privater Verbindungen. Datenverkehr an Private Link-Ressourcen wird über private Endpunkte gesendet, überprüft und über den Microsoft-Backbone gesendet. Der Modus „Offen“ eignet sich für eine gemischte Arbeitsweise (Zugriff auf einige Ressourcen öffentlich und auf andere über eine private Verbindung) oder während eines schrittweisen Onboardingprozesses. Zugriffsmodi werden für Erfassung und Abfragen separat festgelegt. Sie können z. B. den Modus „Nur privat“ für die Erfassung und den Modus „Offen“ für Abfragen festlegen.

Seien Sie vorsichtig, wenn Sie Ihren Zugriffsmodus auswählen. Wenn Sie den Zugriffsmodus „Nur privat“ verwenden, wird der Datenverkehr zu Ressourcen, die sich nicht im AMPLS befinden, in allen Netzwerken blockiert, die dasselbe DNS verwenden, unabhängig von Abonnement oder Mandant. Die Ausnahme sind Log Analytics-Erfassungsanforderungen, die erläutert wird. Wenn Sie nicht alle Azure Monitor-Ressourcen zum AMPLS hinzufügen können, beginnen Sie mit dem Hinzufügen ausgewählter Ressourcen und der Anwendung des Zugriffsmodus „Offen“. Wechseln Sie erst dann in den Modus „Nur privat“ für maximale Sicherheit, wenn Sie alle Azure Monitor-Ressourcen zu Ihrem AMPLS hinzugefügt haben.

Für Konfigurationsdetails und Beispiele siehe Verwendung von APIs und Befehlszeile.

Hinweis

Die Log Analytics-Erfassung verwendet ressourcenspezifische Endpunkte. Daher hält sie sich nicht an die AMPLS-Zugriffsmodi. Um sicherzustellen, dass Log Analytics-Erfassungsanforderungen nicht aus dem AMPLS auf Arbeitsbereiche zugreifen können, legen Sie die Netzwerkfirewall so fest, dass Datenverkehr an öffentliche Endpunkte blockiert wird, unabhängig von den AMPLS-Zugriffsmodi.

Festlegen von Zugriffsmodi für bestimmte Netzwerke

Die in der AMPLS-Ressource festgelegten Zugriffsmodi gelten für alle Netzwerke, aber Sie können diese Einstellungen für bestimmte Netzwerke außer Kraft setzen.

Im folgenden Diagramm verwendet VNet1 den Modus „Offen“ und VNet2 den Modus „Nur privat“. Anforderungen von VNet1 können den Arbeitsbereich 1 und die Komponente 2 über eine private Verbindung erreichen. Anforderungen können die Komponente 3 nur erreichen, wenn sie Datenverkehr aus öffentlichen Netzwerken akzeptiert. VNET2-Anforderungen können die Komponente 3 nicht erreichen.

Berücksichtigen von AMPLS-Einschränkungen

Für das AMPLS-Objekt gelten die folgenden Einschränkungen:

• Ein virtuelles Netzwerk kann eine Verbindung nur mit einem AMPLS-Objekt herstellen. Dies bedeutet, dass das AMPLS-Objekt Zugriff auf alle Azure Monitor-Ressourcen bieten muss, auf die das virtuelle Netzwerk Zugriff haben soll.
• Ein AMPLS-Objekt kann eine Verbindung mit 300 Log Analytics-Arbeitsbereichen und 1000 Application Insights-Komponenten herstellen.
• Eine Azure Monitor-Ressource (Arbeitsbereich, Application Insights-Komponente oder Datensammlungsendpunkt) kann mit höchstens fünf AMPLS-Objekten eine Verbindung herstellen.
• Ein AMPLS-Objekt kann eine Verbindung mit höchstens 10 privaten Endpunkten herstellen.

Hinweis

AMPLS-Ressourcen, die vor dem 1. Dezember 2021 erstellt wurden, unterstützen nur 50 Ressourcen.

Das Diagramm weiter unten zeigt Folgendes:

• Jedes virtuelle Netzwerk stellt eine Verbindung mit nur einem AMPLS-Objekt her.
• AMPLS A stellt eine Verbindung mit zwei Arbeitsbereichen und einer Application Insight-Komponente mithilfe von zwei der 300 möglichen Log Analytics-Arbeitsbereiche und einem der 1000 möglichen Application Insights-Komponenten her, mit denen er Verbindung herstellen kann.
• Der Arbeitsbereich 2 stellt eine Verbindung mit AMPLS A und AMPLS B her, indem er zwei von fünf der möglichen AMPLS-Verbindungen verwendet.
• AMPLS B ist mit privaten Endpunkten von zwei virtuellen Netzwerken (VNet2 und VNet3) verbunden, indem zwei der 10 möglichen privaten Endpunktverbindungen verwendet werden.

Festlegen des Netzwerkzugriffs auf Ihre Ressourcen

Ihre Log Analytics-Arbeitsbereiche oder Application Insights-Komponenten können wie folgt festgelegt werden:

• Akzeptieren oder Blockieren der Erfassung aus öffentlichen Netzwerken (Netzwerke, die nicht mit der Ressourcen-AMPLS verbunden sind).
• Akzeptieren oder Blockieren von Abfragen aus öffentlichen Netzwerken (Netzwerke, die nicht mit der Ressourcen-AMPLS verbunden sind).

Diese Granularität ermöglicht es Ihnen, den Zugriff je nach Bedarf pro Arbeitsbereich festzulegen. Sie könnten beispielsweise die Erfassung nur über mit Private Link verbundene Netzwerke (d. h. bestimmte virtuelle Netzwerke) zulassen, aber dennoch Abfragen aus allen öffentlichen und privaten Netzwerken akzeptieren.

Das Blockieren von Abfragen aus öffentlichen Netzwerken bedeutet, dass Clients wie z. B. Computer und SDKs außerhalb der verbundenen AMPLS-Instanzen keine Daten in der Ressource abfragen können. Diese Daten umfassen Protokolle, Metriken und den Live Metrics Stream. Das Blockieren von Abfragen aus öffentlichen Netzwerken wirkt sich auf alle Erfahrungen aus, welche diese Abfragen ausführen, z. B. Arbeitsmappen, Dashboards, Erkenntnisse im Azure-Portal und Abfragen, die außerhalb des Azure-Portals ausgeführt werden.

Hinweis

Es gibt bestimmte Ausnahmen, bei denen diese Einstellungen nicht gelten. Details finden Sie im folgenden Abschnitt.

Ihre Datensammlungsendpunkte können so festgelegt werden, dass sie den Zugriff aus öffentlichen Netzwerken (Netzwerke, die nicht mit der AMPLS-Ressource verbunden sind) zulassen oder blockieren.

Konfigurationsinformationen finden Sie unter Ressourcenzugriffsflags festlegen.

Ausnahmen

Beachten Sie die folgenden Ausnahmen.

Diagnoseprotokolle

Protokolle und Metriken, die über Diagnoseeinstellungen in einen Arbeitsbereich hochgeladen werden, werden über einen sicheren privaten Microsoft-Kanal geleitet und nicht durch diese Einstellungen gesteuert.

Benutzerdefinierte Metriken oder Azure Monitor-Gastmetriken

Benutzerdefinierte Metriken (Vorschau), die über den Azure Monitor-Agent gesammelt und hochgeladen werden, werden derzeit nicht von Datensammlungsendpunkten gesteuert. Sie können nicht über private Verbindungen konfiguriert werden.

Azure Resource Manager

Die Einschränkung des Zugriffs wie vorstehend erläutert gilt für Daten in der Ressource. Konfigurationsänderungen wie z. B. die Aktivierung und Deaktivierung dieser Zugriffseinstellungen werden jedoch von Azure Resource Manager verwaltet. Zum Steuern dieser Einstellungen beschränken Sie den Zugriff auf Ressourcen mithilfe geeigneter Rollen, Berechtigungen, Netzwerkkontrollen und Überwachungsfunktionen. Weitere Informationen finden Sie unter Rollen, Berechtigungen und Sicherheit in Azure Monitor.

Hinweis

Abfragen, die über die Resource Manager-API gesendet werden, können private Azure Monitor-Verbindungen nicht verwenden. Diese Abfragen werden nur dann durchgeführt werden, wenn die Zielressource Abfragen aus öffentlichen Netzwerken zulässt (festgelegt über den Bereich Netzwerkisolation oder mithilfe der CLI).

Die folgenden Erfahrungen sind für die Ausführung von Abfragen über die Resource Manager-API bekannt:

• LogicApp-Connector
• Lösung für die Updateverwaltung
• Lösung für die Änderungsnachverfolgung
• VM Insights
• Container Insights
• Log Analytics-Bereich Zusammenfassung zum Arbeitsbereich (veraltet) (zeigt das Lösungsdashboard)

Überlegungen für Application Insights

• Sie müssen Ressourcen, welche die überwachten Workloads hosten, einer privaten Verbindung hinzufügen. Ein Beispiel finden Sie unter Verwenden privater Endpunkte für eine Azure-Web-App.
• Nicht-Portal-Verbrauchserfahrungen müssen ebenfalls in dem privat verknüpften virtuellen Netzwerk ausgeführt werden, in dem sich die überwachten Workloads befinden.
• Um private Verbindungen für Profiler und Debugger zu unterstützen, müssen Sie Ihr eigenes Speicherkonto bereitstellen.

Hinweis

Um arbeitsbereichsbasierte Application Insights-Instanzen vollständig zu schützen, müssen Sie den Zugriff auf die Application Insights-Ressource und den zugrunde liegenden Log Analytics-Arbeitsbereich sperren.

Überlegungen für Log Analytics

Beachten Sie die folgenden Log Analytics-Überlegungen.

Herunterladen von Log Analytics-Lösungspaketen

Log Analytics-Agents müssen auf ein globales Speicherkonto zugreifen, um Lösungspakete herunterzuladen. Setups für private Verbindungen, die seit dem 19. April 2021 (oder seit Juni 2021 auf Azure Sovereign Clouds) erstellt wurden, ist der Lösungspaketspeicher der Agents über die private Verbindung erreichbar. Diese Funktion wird durch eine für blob.core.windows.net erstellte DNS-Zone ermöglicht.

Wenn Ihr Setup für die private Verbindung vor dem 19. April 2021 erstellt wurde, ist der Lösungspaketspeicher nicht über eine private Verbindung erreichbar. In diesem Fall können Sie Folgendes tun:

• Erstellen Sie Ihren AMPLS und den damit verbundenen privaten Endpunkt neu.

• Lassen Sie zu, dass Ihre Agents das Speicherkonto über den öffentlichen Endpunkt erreichen können, indem Sie der Positivliste Ihrer Firewall die folgenden Regeln hinzufügen:

  Cloudumgebung	Agent-Ressource	Ports	Direction
  Azure – Öffentlich	scadvisorcontent.blob.core.windows.net	443	Ausgehend
  Azure Government	usbn1oicore.blob.core.usgovcloudapi.net	443	Ausgehend
  Microsoft Azure von 21Vianet	mceast2oicore.blob.core.chinacloudapi.cn	443	Ausgehend

Sammeln von benutzerdefinierten Protokollen und IIS-Protokollen über eine private Verbindung

Beim Erfassungsprozess für benutzerdefinierte Protokolle werden Speicherkonten verwendet. Standardmäßig sind dies dienstseitig verwaltete Speicherkonten. Um benutzerdefinierte Protokolle in privaten Verbindungen zu erfassen, müssen Sie Ihre eigenen Speicherkonten verwenden und sie Log Analytics-Arbeitsbereichen zuordnen.

Weitere Informationen zum Herstellen einer Verbindung mit Ihrem eigenen Speicherkonto finden Sie unter Kundeneigene Speicherkonten für die Protokollerfassung und insbesondere unter Verwenden von privaten Verbindungen und Verknüpfen von Speicherkonten mit Ihrem Log Analytics-Arbeitsbereich.

Automation

Wenn Sie Log Analytics-Lösungen verwenden, die ein Azure Automation-Konto erfordern (z. B. Updateverwaltung, Änderungsnachverfolgung oder Inventar), sollten Sie auch eine private Verbindung für Ihr Automation-Konto erstellen. Weitere Informationen finden Sie unter Verwenden von Azure Private Link zum sicheren Verbinden von Netzwerken mit Azure Automation.

Hinweis

Einige Produkte und Azure-Portalerfahrungen fragen Daten über Resource Manager ab. In diesem Fall können sie keine Daten über eine private Verbindung abfragen, es sei denn, die Einstellungen für private Verbindungen werden auch auf Resource Manager angewendet. Um diese Einschränkung zu umgehen, können Sie Ihre Ressourcen so konfigurieren, dass Abfragen aus öffentlichen Netzwerken akzeptiert werden, wie unter Steuern des Netzwerkzugriffs auf Ihre Ressourcen erläutert. (Die Erfassung kann auf Private Link-Netzwerke beschränkt bleiben.) Wir haben die folgenden Produkte und Erfahrungen identifiziert, die Arbeitsbereiche über Resource Manager abfragen:

• LogicApp-Connector
• Lösung für die Updateverwaltung
• Lösung für die Änderungsnachverfolgung
• Der Bereich Zusammenfassung zum Arbeitsbereich (veraltet) im Portal (zeigt das Lösungsdashboard)
• VM Insights
• Container Insights

Überlegungen zu verwaltetem Prometheus

• Die Einstellungen für die Erfassung von privaten Links werden mithilfe von AMPLS und Einstellungen an den Datensammelendpunkten (Data Collection Endpoints, DCEs) vorgenommen, die auf den Azure Monitor-Arbeitsbereich verweisen, der zum Speichern Ihrer Prometheus-Metriken verwendet wird.
• Private Link-Abfrageeinstellungen werden direkt auf dem Azure Monitor-Arbeitsbereich vorgenommen, der zum Speichern Ihrer Prometheus-Metriken verwendet wird, und werden nicht über AMPLS verarbeitet.

Requirements (Anforderungen)

Beachten Sie folgende Anforderungen.

Größe des Netzwerk-Subnetzes

Das kleinste unterstützte IPv4-Subnetz ist /27 (unter Verwendung von CIDR-Subnetzdefinitionen). Obwohl virtuelle Azure-Netzwerke so klein wie /29 sein können, reserviert Azure fünf IP-Adressen. Die Einrichtung privater Azure Monitor-Verbindungen erfordert mindestens 11 weitere IP-Adressen, auch wenn Sie nur eine Verbindung mit einem einzelnen Arbeitsbereich herstellen. Prüfen Sie die DNS-Einstellungen Ihres Endpunkts für die Liste der Endpunkte der privaten Azure Monitor-Verbindung.

Agents

Die neuesten Versionen von Windows- und Linux-Agents müssen verwendet werden, um eine sichere Erfassung in Log Analytics-Arbeitsbereichen zu ermöglichen. Ältere Versionen können keine Überwachungsdaten über ein privates Netzwerk hochladen.

Windows-Agents von Azure Monitor

Version 1.1.1.0 oder höher des Windows-Agents von Azure Monitor (bei Verwendung von Datensammlungsendpunkten).

Linux-Agents von Azure Monitor

Version 1.10.5.0 oder höher des Linux-Agenten von Azure Monitor (bei Verwendung von Datensammlungsendpunkten).

Windows-Agent von Log Analytics (wird in Kürze als veraltet eingestuft)

Verwenden Sie die Log Analytics-Agent-Version 10.20.18038.0 oder höher.

Linux-Agent von Log Analytics (wird in Kürze als veraltet eingestuft)

Verwenden Sie die Agent-Version 1.12.25 oder höher. Falls dies nicht möglich ist, führen Sie die folgenden Befehle auf Ihrer VM aus:

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

Azure-Portal

Um im Azure Monitor-Portal Erfahrungen wie Application Insights, Log Analytics und Datensammlungsendpunkte verwenden zu können, müssen Sie den Zugriff auf das Azure-Portal und die Azure Monitor-Erweiterungen über die privaten Netzwerke zulassen. Fügen Sie Ihrer Netzwerksicherheitsgruppe die DiensttagsAzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty und AzureFrontdoor.Frontend hinzu.

Programmgesteuerter Zugriff

Um die REST-API, die Azure CLI oder PowerShell mit Azure Monitor in privaten Netzwerken zu verwenden, fügen Sie Ihrer Firewall die DiensttagsAzureActiveDirectory und AzureResourceManager hinzu.

Application Insights SDK-Downloads aus einem Content Delivery Network

Bündeln Sie den JavaScript-Code in Ihrem Skript, sodass der Browser nicht versucht, Code aus einem CDN herunterzuladen. Ein Beispiel finden Sie auf GitHub.

Browser-DNS-Einstellungen

Wenn Sie eine Verbindung mit den Azure Monitor-Ressourcen über eine private Verbinden herstellen, muss der Datenverkehr zu diesen Ressourcen über den privaten Endpunkt erfolgen, der in Ihrem Netzwerk konfiguriert ist. Um den privaten Endpunkt zu aktivieren, aktualisieren Sie Ihre DNS-Einstellungen, wie unter Herstellen einer Verbindung mit einem privaten Endpunkt beschrieben. Einige Browser verwenden eigene DNS-Einstellungen anstelle der von Ihnen festgelegten DNS-Einstellungen. Der Browser versucht möglicherweise, eine Verbindung mit öffentlichen Azure Monitor-Endpunkten herzustellen und die private Verbindung vollständig zu umgehen. Vergewissern Sie sich, dass Ihre Browsereinstellungen keine alten DNS-Einstellungen überschreiben oder zwischenspeichern.

Einschränkung bei Abfragen: externaldata-Operator

• Der externaldata-Operator wird über eine private Verbindung nicht unterstützt, da er zwar Daten aus Speicherkonten liest, jedoch nicht sicherstellt, dass der Zugriff auf den Speicher privat ist.
• Der Azure Data Explorer-Proxy (ADX-Proxy) ermöglicht Protokollabfragen zum Abfragen von Azure Data Explorer. Der ADX-Proxy wird über private Verbindungen nicht unterstützt, weil er nicht garantiert, dass der Zugriff auf die Zielressource privat ist.

Nächste Schritte

• Erfahren Sie, wie Sie Ihre private Verbindung konfigurieren.
• Erfahren Sie mehr über privaten Speicher für benutzerdefinierte Protokolle und kundenseitig verwaltete Schlüssel.
• Erfahren Sie mehr über Private Link für Automation.