Häufig gestellte Fragen (FAQ) zu Azure Private Link

• Privater Endpunkt in Azure : Ein privater Endpunkt in Azure ist eine Netzwerkschnittstelle, die Sie privat und sicher mit einem von Azure Private Link betriebenen Dienst verbindet. Sie können private Endpunkte verwenden, um eine Verbindung mit einem Private Link unterstützenden Azure PaaS-Dienst oder mit Ihrem eigenen Private Link-Dienst herzustellen.
• Azure Private Link-Dienst : Der Azure Private Link-Dienst ist ein von einem Dienstanbieter erstellter Dienst. Derzeit kann ein Private Link-Dienst an die Front-End-IP-Konfiguration eines Load Balancer Standard angefügt werden.

Der Datenverkehr wird privat über den Microsoft-Backbone übertragen. Er gelangt nicht ins Internet. Azure Private Link speichert keine Kundendaten.

• Private Endpunkte gewähren Netzwerkzugriff auf bestimmte Ressourcen hinter einem bestimmten Dienst, der eine differenzierte Segmentierung bietet. Der Datenverkehr kann die Dienstressource von einem lokalen Standort ohne öffentliche Endpunkte erreichen.
• Ein Dienstendpunkt ist weiterhin ein IP-Adresse, die öffentlich geroutet werden kann. Ein privater Endpunkt ist eine private IP-Adresse im Adressraum des virtuellen Netzwerks, in dem der private Endpunkt konfiguriert wurde.

Mehrere Ressourcentypen für private Links unterstützen den Zugriff über private Endpunkte. Zu den Ressourcen gehören Azure PaaS-Dienste und Ihr eigener Private Link-Dienst. Es handelt sich um eine 1:n-Beziehung.

Ein Private Link-Dienst empfängt Verbindungen von mehreren privaten Endpunkten. Ein privater Endpunkt stellt eine Verbindung mit einem privaten Private Link-Dienst her.

Yes. Der Private Link-Dienst muss Netzwerkrichtlinien deaktivieren, damit er ordnungsgemäß funktioniert.

Yes. Um Richtlinien wie benutzerdefinierte Routen und Netzwerksicherheitsgruppen verwenden zu können, müssen Sie Netzwerkrichtlinien für ein Subnetz in einem virtuellen Netzwerk für den privaten Endpunkt aktivieren. Diese Einstellung wirkt sich auf alle privaten Endpunkte innerhalb des Subnetzes aus.

Das Schützen einer Azure-Dienstressource über Dienstendpunkte erfolgt in zwei Schritten:

1. Aktivieren von Dienstendpunkten für den Azure-Dienst
2. Richten Sie Zugriffssteuerungslisten für virtuelle Netzwerke (ACLs) für den Azure-Dienst ein.

Der erste Schritt ist ein netzwerkseitiger Vorgang, und der zweite Schritt ist ein Vorgang auf der Seite der Dienstressource. Beide Schritte können durch denselben oder verschiedene Administratoren erfolgen, basierend auf den Azure RBAC-Berechtigungen (rollenbasierte Zugriffssteuerung) der Administratorrolle.

Wir empfehlen, Dienstendpunkte für Ihr virtuelles Netzwerk zu aktivieren, bevor Sie ACLs für virtuelle Netzwerke auf der Seite des Azure-Diensts einrichten. Zum Einrichten von Dienstendpunkten für virtuelle Netzwerke müssen Sie die Schritte in der vorherigen Sequenz ausführen.

Bestimmte Dienste (z. B. Azure SQL und Azure Cosmos DB) lassen Ausnahmen für die oben angegebene Reihenfolge über das Flag IgnoreMissingVnetServiceEndpoint zu. Nachdem Sie das Flag auf Truefestgelegt haben, können Sie ACLs für virtuelle Netzwerke auf der Seite des Azure-Diensts einrichten, bevor Sie die Dienstendpunkte auf der Netzwerkseite aktivieren. Azure-Dienste stellen dieses Flag bereit, um Kunden in Fällen zu helfen, in denen die spezifischen IP-Firewalls für Azure-Dienste konfiguriert sind.

Das Aktivieren der Dienstendpunkte auf Netzwerkseite kann zu einem Verbindungsabbruch führen, da die Quell-IP von einer öffentlichen IPv4-Adresse zu einer privaten Adresse wechselt. Durch Einrichten der ACLs für virtuelle Netzwerke auf der Azure-Dienstseite vor der Aktivierung von Dienstendpunkten auf der Netzwerkseite können Sie Verbindungsausfälle vermeiden.

Es befinden sich nicht alle Azure-Dienste im virtuellen Netzwerk des Kunden. Bei einem Großteil der Azure-Datendienste (wie Azure Storage, Azure SQL und Azure Cosmos DB) handelt es sich um mehrmandantenfähige Dienste, auf die über öffentliche IP-Adressen zugegriffen werden kann. Weitere Informationen finden Sie unter Bereitstellen dedizierter Azure-Dienste in virtuellen Netzwerken.

Wenn Sie Dienstendpunkte für virtuelle Netzwerke auf Netzwerkseite aktivieren und entsprechende ACLs für virtuelle Netzwerke auf der Azure-Dienstseite einrichten, ist der Zugriff auf einen Azure-Dienst auf einem zulässigen virtuellen Netzwerk und Subnetz aus eingeschränkt.

Dienstendpunkte für virtuelle Netzwerke beschränken den Zugriff des Azure-Diensts auf das jeweilige virtuelle Netzwerk und Subnetz. Auf diese Weise ermöglichen sie Sicherheit auf Netzwerkebene und eine Isolation des Azure-Dienstdatenverkehrs.

Der gesamte Datenverkehr, der Dienstendpunkte für virtuelle Netzwerke verwendet, fließt über den Microsoft-Backbone, um eine weitere Isolationsschicht vom öffentlichen Internet bereitzustellen. Darüber hinaus können Kunden den Zugriff vom öffentlichen Internet auf die Azure-Dienstressourcen auch vollständig entfernen und nur Datenverkehr vom eigenen virtuellen Netzwerk über eine Kombination aus IP-Firewall und ACLs für virtuelle Netzwerke zulassen. Das Entfernen des Internetzugriffs trägt dazu bei, die Azure-Dienstressourcen vor unbefugtem Zugriff zu schützen.

Dienstendpunkte für virtuelle Netzwerke helfen dabei, Azure-Dienstressourcen zu schützen. Ressourcen von virtuellen Netzwerken werden über Netzwerksicherheitsgruppen geschützt.

No. Es fallen keine zusätzlichen Kosten für die Verwendung von Dienstendpunkten für virtuelle Netzwerke an.

Ja, das ist möglich. Virtuelle Netzwerke und Ressourcen von Azure-Diensten können sich in demselben oder in unterschiedlichen Abonnements befinden. Es gilt lediglich die Voraussetzung, dass das virtuelle Netzwerk und die Azure-Dienstressourcen zu demselben Microsoft Entra-Mandanten gehören.

Ja. Dies ist möglich, wenn Sie Dienstendpunkte für Azure Storage und Azure Key Vault verwenden. Für andere Dienste werden Dienstendpunkte für virtuelle Netzwerke und ACLs für virtuelle Netzwerke für Microsoft Entra-Mandanten nicht unterstützt.

Standardmäßig sind Azure-Dienstressourcen, die auf virtuelle Netzwerke beschränkt und so geschützt sind, über lokale Netzwerke nicht erreichbar. Wenn Sie Datenverkehr aus der lokalen Umgebung zulassen möchten, müssen Sie auch öffentliche IP-Adressen (meist NAT) aus der lokalen Umgebung bzw. per ExpressRoute zulassen. Sie können diese IP-Adressen über die Konfiguration der IP-Firewall für Azure-Dienstressourcen hinzufügen.

Alternatively, you can implement private endpoints for supported services.

Zum Schützen von Azure-Diensten in mehreren Subnetzen innerhalb eines virtuellen Netzwerks oder mehrerer virtueller Netzwerke können Sie Dienstendpunkte unabhängig voneinander in den einzelnen Subnetzen aktivieren. Sichern Sie dann die Azure-Dienstressourcen in allen Subnetzen, indem Sie entsprechenden ACLs für virtuelle Netzwerke auf der Seite des Azure-Diensts einrichten.

Wenn Sie den Datenverkehr, der aus dem virtuellen Netzwerk an einen Azure-Dienst fließen soll, untersuchen und filtern möchten, können Sie in diesem virtuellen Netzwerk ein virtuelles Netzwerkgerät bereitstellen. Anschließend können Sie Dienstendpunkte auf das Subnetz anwenden, in dem das virtuelle Netzwerkgerät bereitgestellt wurde, und Ressourcen des Azure-Diensts mithilfe von ACLs für virtuelle Netzwerke auf dieses Subnetz beschränken.

Dieses Szenario kann auch hilfreich sein, wenn Sie den Zugriff auf den Azure-Dienst aus Ihrem virtuellen Netzwerk per Filterung durch ein virtuelles Netzwerkgerät nur auf bestimmte Azure-Ressourcen beschränken möchten. Weitere Informationen finden Sie unter Bereitstellen hochverfügbarer NVAs.

Der Dienst gibt einen HTTP 403- oder HTTP 404-Fehler zurück.

Yes. Für die meisten Azure-Dienste können in unterschiedlichen Regionen erstellte virtuelle Netzwerke über die Dienstendpunkte für virtuelle Netzwerke auf Azure-Dienste in einer anderen Region zugreifen. Wenn sich ein Azure Cosmos DB-Konto z. B. in einer der Regionen „USA, Westen“ oder „USA, Osten“ befindet und sich virtuelle Netzwerke in mehreren Regionen befinden, können virtuelle Netzwerke auf Azure Cosmos DB zugreifen.

Azure SQL ist eine Ausnahme und von Natur aus regional. Sowohl das virtuelle Netzwerk als auch der Azure-Dienst müssen sich in der gleichen Region befinden.

Yes. Eine ACL für virtuelle Netzwerke und eine IP-Firewall können gleichzeitig vorhanden sein. Die Features ergänzen einander, um Isolation und Sicherheit zu gewährleisten.

Das Löschen virtueller Netzwerke und das Löschen von Subnetzen sind unabhängige Vorgänge. Sie werden auch dann unterstützt, wenn Sie Dienstendpunkte für Azure-Dienste aktivieren.

Wenn Sie ACLs für virtuelle Netzwerke für Azure-Dienste einrichten, werden die diesen Azure-Diensten zugeordneten ACL-Informationen deaktiviert, wenn Sie ein virtuelles Netzwerk oder Subnetz löschen, in dem Dienstendpunkte für virtuelle Netzwerke aktiviert sind.

Das Löschen eines Azure-Dienstkontos ist ein unabhängiger Vorgang. Dieser wird auch dann unterstützt, wenn Sie den Dienstendpunkt auf der Netzwerkseite aktiviert und ACLs für virtuelle Netzwerke auf Seite des Azure-Diensts eingerichtet haben.

Wenn Sie Dienstendpunkte für virtuelle Netzwerke aktiviert haben, verwenden die IP-Quelladressen der Ressourcen im Subnetz des virtuellen Netzwerks keine öffentlichen IPv4-Adressen mehr, sondern private IP-Adressen des virtuellen Azure-Netzwerks, um Datenverkehr an die Azure-Dienste zu leiten. Dieser Wechsel kann zu Fehlern bei bestimmten IP-Firewalls führen, die zuvor in den Azure-Diensten für öffentliche IPv4-Adressen festgelegt wurden.

Dienstendpunkte fügen eine Systemroute hinzu, die Vorrang vor BGP-Routen (Border Gateway Protocol) hat und eine optimale Weiterleitung für den Dienstendpunkt-Datenverkehr ermöglicht. Dienstendpunkte leiten den Datenverkehr der Dienste immer direkt aus Ihrem virtuellen Netzwerk an den Dienst im Microsoft Azure-Backbonenetzwerk weiter.

Weitere Informationen dazu, wie Azure eine Route auswählt, finden Sie unter Routing des virtuellen Netzwerks.

No. ICMP-Datenverkehr, der aus einem Subnetz mit aktivierten Dienstendpunkten stammt, fließt nicht über den Diensttunnelpfad zum gewünschten Endpunkt. Von Dienstendpunkten wird nur TCP-Datenverkehr verarbeitet. Wenn Sie die Latenz oder Konnektivität für einen Endpunkt über Dienstendpunkte testen möchten, wird mit Tools wie Ping und tracert nicht der Pfad angezeigt, der von den Ressourcen im Subnetz genutzt wird.

Um den Azure-Dienst zu erreichen, müssen NSGs ausgehende Verbindungen zulassen. Wenn Ihre NSGs für sämtlichen ausgehenden Internet-Datenverkehr geöffnet sind, sollte der Datenverkehr für den Dienstendpunkt funktionieren. Sie können den ausgehenden Datenverkehr über Diensttags auch auf Dienst-IP-Adressen beschränken.

Sie können Dienstendpunkte in einem virtuellen Netzwerk unabhängig konfigurieren, wenn Sie Schreibzugriff auf dieses Netzwerk haben.

To secure Azure service resources to a virtual network, you must have Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action permission for the subnets that you're adding. Diese Berechtigung ist standardmäßig in den integrierten Dienstadministratorrollen enthalten und kann durch Erstellen von benutzerdefinierten Rollen geändert werden.

Weitere Informationen zu integrierten Rollen und zum Zuweisen bestimmter Berechtigungen zu benutzerdefinierten Rollen finden Sie unter Azure custom roles.

Sie können die Richtlinien für Dienstendpunkte in virtuellen Azure-Netzwerken verwenden, um virtuellen Netzwerkdatenverkehr an Azure-Dienste zu filtern, sodass nur bestimmte Azure-Dienstressourcen über Dienstendpunkte zugelassen werden. Endpunktrichtlinien bieten eine differenzierte Zugriffssteuerung für virtuellen Netzwerkdatenverkehr an Azure-Dienste.

Weitere Informationen finden Sie unter Endpunktrichtlinien für virtuelle Netzwerke für Azure Storage.

Microsoft Entra ID unterstützt nativ keine Dienstendpunkte. Eine vollständige Liste der Azure-Dienste, die Virtuelle Netzwerkdienstendpunkte unterstützen, finden Sie unter Endpunkte für virtuelle Netzwerke.

In that list, the Microsoft.AzureActiveDirectory tag listed under services that support service endpoints is used for supporting service endpoints to Azure Data Lake Storage Gen1. Die Integration des virtuellen Netzwerks für Data Lake Storage Gen1 verwendet die Sicherheit des virtuellen Netzwerkdienstendpunkts zwischen Ihrem virtuellen Netzwerk und der Microsoft Entra-ID, um zusätzliche Sicherheitsansprüche im Zugriffstoken zu generieren. Diese Ansprüche werden dann genutzt, um Ihr virtuelles Netzwerk mit Ihrem Data Lake Storage Gen1-Konto zu authentifizieren und den Zugriff zu ermöglichen.

Für die Gesamtzahl von Dienstendpunkten in einem virtuellen Netzwerk gilt keine Beschränkung. Für die Ressource eines Azure-Diensts (z.B. ein Azure Storage-Konto) können Dienste Beschränkungen in Bezug auf die Anzahl von Subnetzen erzwingen, die Sie zum Schützen der Ressource verwenden. Die folgende Tabelle zeigt einige Beispielgrenzwerte:

Um den Azure-Dienst zu erreichen, müssen NSGs ausgehende Verbindungen zulassen. Wenn Ihre NSGs für sämtlichen ausgehenden Internet-Datenverkehr geöffnet sind, sollte der Datenverkehr für den Dienstendpunkt funktionieren. Sie können den ausgehenden Datenverkehr über Diensttags auch auf Dienst-IP-Adressen beschränken.

Sie können Dienstendpunkte in einem virtuellen Netzwerk unabhängig konfigurieren, wenn Sie Schreibzugriff auf dieses Netzwerk haben.

To secure Azure service resources to a virtual network, you must have Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action permission for the subnets that you're adding. Diese Berechtigung ist standardmäßig in den integrierten Dienstadministratorrollen enthalten und kann durch Erstellen von benutzerdefinierten Rollen geändert werden.

Weitere Informationen zu integrierten Rollen und zum Zuweisen bestimmter Berechtigungen zu benutzerdefinierten Rollen finden Sie unter Azure custom roles.

Sie können die Richtlinien für Dienstendpunkte in virtuellen Azure-Netzwerken verwenden, um virtuellen Netzwerkdatenverkehr an Azure-Dienste zu filtern, sodass nur bestimmte Azure-Dienstressourcen über Dienstendpunkte zugelassen werden. Endpunktrichtlinien bieten eine differenzierte Zugriffssteuerung für virtuellen Netzwerkdatenverkehr an Azure-Dienste.

Weitere Informationen finden Sie unter Endpunktrichtlinien für virtuelle Netzwerke für Azure Storage.

Microsoft Entra ID unterstützt nativ keine Dienstendpunkte. Eine vollständige Liste der Azure-Dienste, die Virtuelle Netzwerkdienstendpunkte unterstützen, finden Sie unter Endpunkte für virtuelle Netzwerke.

In that list, the Microsoft.AzureActiveDirectory tag listed under services that support service endpoints is used for supporting service endpoints to Azure Data Lake Storage Gen1. Die Integration des virtuellen Netzwerks für Data Lake Storage Gen1 verwendet die Sicherheit des virtuellen Netzwerkdienstendpunkts zwischen Ihrem virtuellen Netzwerk und der Microsoft Entra-ID, um zusätzliche Sicherheitsansprüche im Zugriffstoken zu generieren. Diese Ansprüche werden dann genutzt, um Ihr virtuelles Netzwerk mit Ihrem Data Lake Storage Gen1-Konto zu authentifizieren und den Zugriff zu ermöglichen.

Für die Gesamtzahl von Dienstendpunkten in einem virtuellen Netzwerk gilt keine Beschränkung. Für die Ressource eines Azure-Diensts (z.B. ein Azure Storage-Konto) können Dienste Beschränkungen in Bezug auf die Anzahl von Subnetzen erzwingen, die Sie zum Schützen der Ressource verwenden. Die folgende Tabelle zeigt einige Beispielgrenzwerte:

Yes. Sie können über mehrere private Endpunkte im selben virtuellen Netzwerk oder Subnetz verfügen. Sie können Verbindungen zu anderen Diensten herstellen.

Nein, das Erstellen mehrerer Zonen mit demselben Namen für ein einzelnes virtuelles Netzwerk wird nicht unterstützt.

No. Sie benötigen kein dediziertes Subnetz für private Endpunkte. Sie können eine private Endpunkt-IP aus einem beliebigen Subnetz des virtuellen Netzwerks auswählen, in dem Ihr Dienst bereitgestellt wird.

Yes. Private Endpunkte können über verschiedene Microsoft Entra-Mandanten hinweg eine Verbindung mit Private Link-Diensten oder einer Azure PaaS-Lösung herstellen. Mandantenübergreifende private Endpunkte erfordern eine manuelle Genehmigung von Anforderungen.

Yes. Private Endpunkte können eine Verbindung mit Azure PaaS-Ressourcen zwischen Azure-Regionen herstellen.

Wenn ein privater Endpunkt erstellt wird, wird eine schreibgeschützte NIC zugewiesen. Die NIC kann nicht geändert werden und bleibt für den Lebenszyklus des privaten Endpunkts beibehalten.

Private Endpunkte sind hochverfügbare Ressourcen mit einer SLA gemäß SLA für Azure Private Link. Da dies jedoch regionale Ressourcen sind, kann sich jeder Ausfall der Azure-Region auf die Verfügbarkeit auswirken. Um Verfügbarkeit zu erreichen, wenn regionale Ausfällen auftreten, könnten mehrere private Endpunkte, die mit derselben Zielressource verbunden sind, in unterschiedlichen Regionen bereitgestellt werden. Wenn eine Region ausfällt, können Sie auf diese Weise den Datenverkehr für Wiederherstellungsszenarien weiterhin über einen privaten Endpunkt in einer anderen Region weiterleiten, um auf die Zielressource zuzugreifen. Informationen dazu, wie regionale Ausfälle auf der Seite des Zieldiensts behandelt werden, finden Sie in der Dienstdokumentation zu Failover und Wiederherstellung. Bei Private Link-Datenverkehr wird die Azure DNS-Auflösung für den Zielendpunkt befolgt.

Private Endpunkte sind hochverfügbare Ressourcen mit einer SLA gemäß SLA für Azure Private Link. Private Endpunkte sind zonenunabhängig: Ein Ausfall der Verfügbarkeitszone in der Region des privaten Endpunkts wirkt sich nicht auf die Verfügbarkeit des privaten Endpunkts aus.

TCP- und UDP-Datenverkehr wird nur für einen privaten Endpunkt unterstützt. Weitere Informationen hierzu finden Sie unter Einschränkungen bei Azure Private Link.

Ihre Dienst-Back-Ends sollten sich in einem virtuellen Netzwerk und hinter einem Load Balancer Standard befinden.

Sie können Ihren Private Link-Dienst auf verschiedene Arten skalieren:

• Fügen Sie dem Pool hinter Ihrem Load Balancer Standard Back-End-VMs hinzu.
• Fügen Sie dem Private Link-Dienst eine IP-Adresse hinzu. Es sind bis zu acht IP-Adressen pro Private Link-Dienst gestattet.
• Fügen Sie dem Load Balancer Standard einen neuen Private Link-Dienst hinzu. Es sind bis zu acht Private Link-Dienste pro Load Balancer Standard gestattet.

• Die NAT-IP-Konfiguration stellt sicher, dass der Quelladressraum (Consumer) und der Zieladressraum (Dienstanbieter) keine IP-Konflikte aufweisen. Die Konfiguration stellt die Quell-NAT für den Datenverkehr der privaten Verbindung für das Ziel bereit. Die NAT-IP-Adresse wird als Quell-IP-Adresse für alle Pakete, die von Ihrem Dienst empfangen werden, und als Ziel-IP-Adresse für alle von Ihrem Dienst gesendeten Pakete angezeigt. Die NAT-IP-Adresse kann aus einem beliebigen Subnetz im virtuellen Netzwerk eines Dienstanbieters ausgewählt werden.
• Jede NAT-IP-Adresse bietet 64k-TCP-Verbindungen (64k-Ports) pro VM hinter Load Balancer Standard. Zum Skalieren und Hinzufügen weiterer Verbindungen können Sie entweder neue NAT-IP-Adressen oder weitere VMs hinter Load Balancer Standard hinzufügen. Dadurch wird die Portverfügbarkeit skaliert und weitere Verbindungen werden ermöglicht. Verbindungen werden über NAT-IP-Adressen und VMs hinter Load Balancer Standard verteilt.

Yes. Ein Private Link-Dienst kann Verbindungen von mehreren privaten Endpunkten empfangen. Ein privater Endpunkt kann jedoch nur eine Verbindung mit einem Private Link-Dienst herstellen.

Sie können die Offenlegung über die Sichtbarkeitskonfiguration des Private Link-Dienstes kontrollieren. Die Sichtbarkeit unterstützt drei Einstellungen:

• None - Only subscriptions with role based access can locate the service.
• Restrictive - Only subscriptions that are approved and with role based access can locate the service.
• All - Everyone can locate the service.

No. Der Private Link-Dienst über einen Load Balancer im Tarif „Basic“ wird nicht unterstützt.

No. Für den Private Link-Dienst ist kein dediziertes Subnetz erforderlich. Sie können ein beliebiges Subnetz im virtuellen Netzwerk auswählen, in dem Ihr Dienst bereitgestellt wird.

No. Azure Private Link stellt Ihnen diese Funktionen zur Verfügung. Es ist nicht erforderlich, dass Sie über einen Adressraum verfügen, der nicht mit dem Adressraum Ihrer Kund*innen überlappt.

Next steps

• Erfahren Sie mehr über Azure Private Link.