Privater Zugriff auf Azure PaaS-Dienste

In diesem Artikel wird erläutert, wie Sie eine Verbindung mit Azure Plattform as a Service(PaaS)-Ressourcen über private Netzwerkverbindungen anstelle des öffentlichen Internets herstellen. Sie lernen die Unterschiede zwischen Dienstendpunkten, privaten Endpunkten und Private Link kennen, damit Sie den Ansatz auswählen können, der Ihren Sicherheits- und Konnektivitätsanforderungen entspricht.

Inhalt dieses Artikels

Der private PaaS-Zugriff entfernt das öffentliche Internet aus dem Datenpfad zwischen Ihrem Azure virtuellen Netzwerk und Azure PaaS-Diensten wie Azure Storage, Azure SQL-Datenbank und Azure Key Vault. In diesem Artikel werden die Konnektivitätsoptionen, ihre Kompromisse und die Entscheidung, welcher Ansatz für jede Workload verwendet werden soll, behandelt.

Note

Private Endpunkte erfordern die DNS-Integration zum Auflösen von Dienst-FQDNs in private IP-Adressen. In diesem Artikel werden die DNS-Anforderungen inline behandelt, aber für die vollständige DNS-Architektur, einschließlich Hybridweiterleitung, Azure DNS Private Resolver und DNS-Sicherheit, siehe DNS-Sicherheit und private Namensauflösung.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn eine oder mehrere dieser Bedingungen gelten:

  • Ihre Workloads müssen Azure PaaS-Dienste über private Netzwerkpfade anstelle öffentlicher Endpunkte erreichen.
  • Sie müssen zwischen Dienstendpunkten und privaten Endpunkten basierend auf Sicherheit, Kosten und Verwaltbarkeit entscheiden.
  • Sie müssen den Zugriff auf bestimmte PaaS-Ressourcen einschränken, um das Datenexfiltrationsrisiko zu verringern.
  • Sie müssen DNS, Subnetzkapazität oder hybride Reichweite für private PaaS-Konnektivität planen.

Tip

Einem Szenariopfad folgen? Wählen Sie Ihr Szenario oben auf der Seite aus, um eine maßgeschneiderte Anleitung zu erhalten. Der folgende Kernleitfaden gilt für alle Leser.

Heben und Verschieben des Fokus: Überspringen Sie diesen Artikel, es sei denn, Teile Ihrer migrierten App verwenden bereits Azure PaaS-Dienste. Die meisten Lift-and-Shift-Workloads bleiben auf IaaS (VMs, verwaltete Datenträger, Standardnetzwerke) und benötigen in der ersten Migrationsphase keine Private Link. Kehren Sie später zu diesem Artikel zurück, wenn Sie mit der Einführung von PaaS-Diensten für einzelne Workloadkomponenten beginnen.

Lesen Sie diesen Artikel, wenn Sie:

  • Sie haben Workloads migriert, die bereits Azure PaaS-Dienste nutzen (z. B. Azure SQL-Datenbank oder Azure Storage).
  • Möchten Sie verstehen, wann Sie Private Link im Rahmen einer schrittweisen Modernisierung nach einem Lift-and-Shift zu verwenden beginnen.
  • Sie müssen die Subnetzkapazität für die zukünftige Einführung eines privaten Endpunkts planen.

Modernisierungsfokus: Private Link Subnetze in jedem Speichen-VNet sind unerlässlich. Ihre AKS, App Service-Umgebung (ASE) und verwaltete Datenbankworkloads benötigen private PaaS-Konnektivität, um Complianceanforderungen zu erfüllen und Datenexfiltration über das öffentliche Internet zu verhindern.

Lesen Sie diesen Artikel, wenn Sie:

  • Speichern Sie vertrauliche oder regulierte Daten in Azure PaaS-Diensten und müssen den Zugriff auf private Netzwerkpfade einschränken.
  • Es müssen in jedem Spoke-VNet dedizierte Private-Link-Subnetze zur Nutzung durch das App-Team erstellt werden.
  • Sie möchten die Datenexfiltration verhindern, indem Sie paaS-Konnektivitätsbereiche mit bestimmten Ressourceninstanzen sicherstellen.
  • Entwerfen Sie Produktionsworkloads, bei denen PaaS-Dienste über VPN oder ExpressRoute von lokalen Netzwerken aus erreichbar sein müssen.
  • Man muss die Abwägungen bei Kosten, DNS und Sicherheit zwischen Service Endpoints und Private Endpoints verstehen.

Cloudübergreifender Fokus: Dieser Artikel wird relevant, nachdem Sie eine cloudübergreifende Übertragung und Konnektivität hergestellt haben, es sei denn, die Zielarchitektur enthält bereits Azure PaaS mit privaten Endpunkten. Kehren Sie während der Optimierung zu diesem Artikel zurück, wenn Sie bereit sind, PaaS-Zugriffspfade zu sichern.

Lesen Sie diesen Artikel, wenn Sie:

  • Verwenden Sie während des Migrationsprozesses Azure Migrate mit Unterstützung für private Endpunkte.
  • Planen Sie die Einführung Azure PaaS-Dienste als Teil der Zielarchitektur nach der Migration.
  • Sie müssen verstehen, wie private Endpunkte funktionieren, bevor Sie sie in Ihr cloudübergreifendes Design integrieren.

Azure Dienste und Features

In der folgenden Tabelle werden die Dienste und Features beschrieben, die für die private PaaS-Konnektivität in Azure verfügbar sind.

Dienst oder Feature Was es bietet Wann wird es verwendet?
Öffentlicher Endpunkt (Standard) Zugreifen auf Azure PaaS-Dienste über das Internet bei ihrem öffentlichen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN). Keine zusätzliche Konfiguration erforderlich. Nur Entwicklungs-/Testumgebungen. Für Produktionsworkloads mit vertraulichen Daten nicht empfohlen.
Dienstendpunkte Erweitert Ihre virtuelle Netzwerkidentität auf Azure PaaS-Dienste. Der Datenverkehr bleibt auf dem Microsoft Backbone. Der PaaS-Dienst sieht das VNet als Datenverkehrsquelle. Erstellt keine private IP-Adresse. Geringes Exfiltrationsrisiko. Einfacheres Setup als Private Link. Nützlich, wenn Private Link für einen bestimmten Dienst nicht verfügbar ist. Kostenlos.
Privater Endpunkt/Azure Private Link Erstellt eine Netzwerkschnittstelle mit einer privaten IP-Adresse in Ihrem virtuellen Netzwerk, die einer bestimmten PaaS-Ressourceninstanz zugeordnet ist. Der Datenverkehr bleibt auf dem Microsoft Backbone und durchläuft nie das öffentliche Internet. Erfordert DNS-Integration. Produktionsbelastungen Vertrauliche Daten. Einhaltung gesetzlicher Bestimmungen. Verhinderung von Datenexfiltration. Bevorzugt gegenüber Dienstendpunkten für neue Designs.
Private Link-Dienst Machen Sie Ihren eigenen Dienst privat für Verbraucher in anderen virtuellen Netzwerken oder Microsoft Entra Mandanten verfügbar. Verbraucher erstellen einen privaten Endpunkt in ihrem eigenen VNet, um Ihren Dienst zu erreichen, ohne dass VNet-Peering erforderlich ist. ISVs oder interne Plattformteams veröffentlichen Dienste für Verbraucher, die keinen Zugriff auf Netzwerkebene auf das virtuelle Hostnetzwerk haben sollten.
VNet-Integration (App-Dienst, Funktionen) Ermöglicht App Service oder Azure Functions, ausgehenden Datenverkehr über ein virtuelles Netzwerk weiterzuleiten. Nur ausgehend: Stellt keine eingehende private Konnektivität bereit. Wenn App Service oder Azure Functions VNet-private Ressourcen wie Datenbanken oder interne APIs über private Endpunkte erreichen müssen.

Wie man auswählt

Diagramm, das drei PaaS-Zugriffsmethoden vergleicht: öffentlicher Endpunkt, Dienstendpunkt über Backbone und privaten Endpunkt mit privater IP.

Verwenden Sie die Entscheidungstabellen in diesem Abschnitt, um den richtigen Konnektivitätsansatz für Ihre Workload auszuwählen.

Dienstendpunkte im Vergleich zu privaten Endpunkten

In der folgenden Tabelle werden die beiden am häufigsten verwendeten Ansätze zum Einschränken des PaaS-Zugriffs auf private Netzwerkpfade verglichen.

Faktor Dienstendpunkte Private Endpunkte
Verkehrspfad Microsoft-Backbone. Ziel verwendet weiterhin seine öffentliche IP-Adresse. Microsoft Backbone. Das Ziel verwendet eine private IP-Adresse in Ihrem VNet.
Private IP in VNet No. Quell-IP wird privat (VNet-Adresse), der Dienst wird jedoch in seine öffentliche IP-Adresse aufgelöst. Ja. Eine Netzwerkschnittstelle mit einer privaten IP aus Ihrem Subnetz wird der jeweiligen Ressource zugeordnet.
DNS-Änderungen erforderlich No. Die DNS-Auflösung bleibt unverändert. Ja. Es ist eine private DNS-Zone erforderlich, sodass der Dienst-FQDN in die private IP-Adresse aufgelöst wird.
Verhinderung von Datenexfiltration Eingeschränkt. Gilt auf VNet-Ebene für alle Instanzen eines Diensttyps (z. B. alle Azure Storage Konten). Stark. Der Zugriff ist auf eine bestimmte Ressourceninstanz festgelegt. Nur die zugeordnete Ressource ist über diesen Endpunkt erreichbar.
Lokaler Zugriff Nicht erreichbar über lokale Netzwerke. Problemumgehung: Fügen Sie Ihre öffentlichen oder NAT-IP-Adressen den IP-Firewallregeln des Azure Diensts hinzu. Erreichbar von der lokalen über VPN oder ExpressRoute, da der Endpunkt über eine routingfähige private IP-Adresse verfügt.
Cost Kostenlos. Keine zusätzlichen Gebühren. Stündliche Gebühr pro Endpunkt plus Datenverarbeitungsgebühr.

Wann soll welcher Ansatz verwendet werden?

Scenario Empfohlener Ansatz Warum?
Entwicklung/Test, geringe Datensensibilität Öffentlicher Endpunkt mit Dienstfirewall Einfachste Einrichtung. Zugriff über eine IP-Zulassungsliste einschränken. Keine zusätzlichen Kosten oder DNS-Änderungen.
Einfache VNet-Einschränkung, geringes Exfiltrationsrisiko Dienstendpunkte Kostenlos. Schnell zu aktivieren. Geeignet, wenn Sie keinen Zugriffsbereich auf Ressourcenebene benötigen.
Produktionsworkloads, vertrauliche Daten, Compliance Private Endpunkte Stärkster Exfiltrationsschutz. Funktioniert lokal. Unterstützt DNS-basierte Auflösung aus jedem verbundenen Netzwerk.
Privates Veröffentlichen Ihres eigenen Diensts für andere Mandanten Private Link-Dienst Verbraucher erstellen einen privaten Endpunkt in ihrem VNet. Kein VNet-Peering erforderlich. Unterstützt Genehmigungsworkflows und Sichtbarkeitssteuerung.
App-Dienst oder -Funktionen müssen VNet-Ressourcen erreichen VNET-Integration Nur ausgehende Konnektivität. Erfordert Subnetzdelegierung zu Microsoft.Web/serverFarms. In Kombination mit Private Endpoints für den sicheren Datenzugriff auf PaaS-Dienste.

Azure Front Door Premium unterstützt Private Link Ursprünge, die Sie verwenden, um Front Door mit Ihren Back-End-Diensten (App Service, Speicher oder interne Lastenausgleichsgeräte) über eine private Verbindung zu verbinden. Der Verkehr zwischen Front Door und Ihrem Ursprung bleibt auf dem Microsoft Backbone, und Sie können den öffentlichen Zugriff auf den Ursprung vollständig deaktivieren. Dieses Muster ist die am häufigsten dokumentierte Integration für Private Link über Azure Netzwerkdienste hinweg.

Verwenden Sie Front Door Premium mit Private Link Ursprüngen, wenn Sie Folgendes benötigen:

  • Globaler Lastenausgleich mit WAF-Schutz (Web Application Firewall).
  • Private Anbindung an Ursprungsserver, ohne sie dem öffentlichen Internet auszusetzen.
  • Zentralisierter TLS-Abschluss mit Back-End-Datenverkehr über private Pfade.

VNet-Integration für ausgehenden Zugriff

Die VNet-Integration bietet keine eingehende private Konnektivität. Es ermöglicht App Service oder Azure Functions, ausgehende Anrufe über Ihr virtuelles Netzwerk weiterzuleiten. Dies bedeutet, dass Ihre App Ressourcen hinter privaten Endpunkten erreichen oder auf VNet-private Dienste zugreifen kann. Für die VNet-Integration ist ein dediziertes Subnetz erforderlich, das an Microsoft.Web/serverFarms delegiert ist.

Kombinieren Sie die VNet-Integration mit privaten Endpunkten, wenn Ihre Anwendung Folgendes ausführen muss:

  • Rufen Sie Azure SQL-Datenbank oder Azure Storage über eine private IP auf.
  • Greifen Sie auf interne APIs oder Dienste zu, die in virtuellen Speichennetzwerken bereitgestellt werden.
  • Leiten Sie ausgehenden Datenverkehr über eine virtuelle Netzwerk-Appliance (NVA) zur Überprüfung weiter.

Überlegungen zum Entwurf

Die meisten Lift-and-Shift-Projekte verschieben die Einführung von Private Link auf eine spätere Phase. Ihre sofortige Priorität besteht darin, VMs zu migrieren und grundlegende Konnektivität herzustellen. Berücksichtigen Sie Private Link in folgenden Fällen:

  • Einzelne Workloadkomponenten verwenden bereits PaaS: Wenn eine aufgehobene Anwendung eine Verbindung mit Azure SQL-Datenbank oder Azure Storage herstellt, fügen Sie einen privaten Endpunkt für diesen bestimmten Dienst hinzu. Sie müssen nicht alle PaaS-Zugriffe gleichzeitig konvertieren.
  • Compliance schreibt private Konnektivität vor: Einige regulierte Workloads erfordern von Beginn an private Datenpfade. Erstellen Sie in diesem Fall private Endpunkte während der Migration, nicht nach der Migration.
  • Planen Sie die Subnetzkapazität jetzt: Selbst wenn Sie Private Link zurückstellen, reservieren Sie in jedem Spoke ein /27- oder /28-Subnetz für zukünftige Private Endpunkte. Die Nachrüstung des Subnetzraums ist später schwieriger, als sie vorab zu reservieren.

Überspringen Sie für die meisten Lift-and-Shift-Migrationen detaillierte Private Link Implementierung, und kehren Sie zu diesem Artikel zurück, wenn die PaaS-Einführung beginnt.

Erstellen Sie in jedem Spoke-VNet ein dediziertes Private-Link-Subnetz. App-Teams verwenden dieses Subnetz, um private Endpunkte für die PaaS-Dienste zu erstellen, die ihre Anwendungen nutzen:

  • Dedizierte Private Link Subnetz pro Speichen: Größe jedes Subnetz basierend auf der Anzahl der PaaS-Dienste, die die Speichenarbeitslasten benötigen (eine IP pro privater Endpunkt). Ein /27 (32 Adressen) unterstützt bis zu 27 private Endpunkte, nachdem Azure 5 Adressen reserviert hat.
  • App-Administratoren legen PaaS-Verbindungen fest: Das IT-Team stellt die Subnetz- und DNS-Infrastruktur bereit. App-Teams erstellen private Endpunkte für ihre spezifischen PaaS-Ressourcen (Azure SQL, Key Vault, Speicher) basierend auf den Anwendungsanforderungen.
  • DNS-Zonen im Hub zentralisieren: Privates DNS-Zonen (z. B. privatelink.database.windows.net) befinden sich im Abonnement für Konnektivität und sind mit allen Spoke-VNETs verknüpft. Mit diesem Ansatz wird eine konsistente Namensauflösung gewährleistet und split-brain DNS vermieden.
  • Deaktivieren des öffentlichen Zugriffs für PaaS-Ressourcen: Deaktivieren Sie nach dem Erstellen eines privaten Endpunkts den Öffentlichen Netzwerkzugriff auf die PaaS-Zielressource. Andernfalls kann der Datenverkehr den Dienst weiterhin über das Internet erreichen, wodurch der Zweck privater Konnektivität zunichtegemacht wird.
  • In Kombination mit der VNet-Integration: App Service und Azure Functions verwenden die VNet-Integration, um ausgehende Aufrufe über das Spoke-VNet zu leiten und PaaS-Dienste über Private Endpunkte im selben oder einem per Peering verbundenen VNet zu erreichen.

Azure Migrate Appliance unterstützt private Endpunktkonnektivität, wodurch der Datenverkehr der Migrationssteuerungsebene gesichert wird. Darüber hinaus sollten Sie die Private-Link-Planung auf die Optimierung nach der Migration verschieben:

  • Azure Migrate mit privatem Endpunkt: Während des Migrationsprozesses kann die Azure Migrate Appliance einen privaten Endpunkt verwenden, um mit dem Azure Migrate Projekt zu kommunizieren. Dieser Ansatz hält den Migrationssteuerungsdatenverkehr vom öffentlichen Internet fern.
  • Breite Einführung von Private Link verschieben: Konzentrieren Sie sich zunächst auf die cloudübergreifende Transit-Konnektivität. Nachdem Sie Workloads in Azure migriert und stabilisiert haben, planen Sie private Endpunkte für PaaS-Dienste als separaten Optimierungsdurchlauf.
  • Subnetzbereich reservieren: Auch wenn Sie Private Link jetzt auslassen, reservieren Sie in jedem Spoke ein Subnetz für zukünftige Private Endpunkte. Cloudübergreifende Workloads, die später Azure PaaS-Dienste übernehmen, benötigen diese Kapazität.

Voraussetzungen

Bevor Sie den privaten PaaS-Zugriff implementieren, vergewissern Sie sich, dass Sie über die folgenden Ressourcen und Kenntnisse verfügen:

  • Ein bereitgestelltes virtuelles Netzwerk mit mindestens einem Subnetz. Private Endpunkte erfordern ein Subnetz mit verfügbaren IP-Adressen. Informationen zum Entwurf eines virtuellen Netzwerks finden Sie unter "Virtuelle Netzwerke und Subnetze".
  • Ein Azure PaaS-Dienst, um eine private Verbindung herzustellen. Der Dienst muss entweder Dienstendpunkte oder Private Link unterstützen. Überprüfen Sie die Azure Private Link Verfügbarkeitsdokumentation für Ihren Dienst.
  • Grundlegendes zur DNS-Infrastruktur. Private Endpunkte erfordern eine private DNS-Zone. Wenn Sie benutzerdefinierte DNS-Server verwenden, benötigen Sie bedingte Weiterleitungen, die auf Azure DNS verweisen (168.63.129.16). Informationen zu DNS-Entwurfsmustern finden Sie im DNS-Integrationsartikel für private Endpunkte in verwandten Ressourcen.
  • IP-Adressplanung. Jeder private Endpunkt verwendet eine private IP-Adresse aus dem Subnetz. Planen Sie die Subnetzgrößen entsprechend. Anleitungen finden Sie unter IP-Adressplanung .

Sicherheitsüberlegungen

Private PaaS-Konnektivität wirkt sich direkt auf Ihren Datenexfiltrationsstatus, die DNS-Zuverlässigkeit und die Durchsetzung von Netzwerkrichtlinien aus. Beachten Sie beim Entwerfen der Implementierung die folgenden Anleitungen.

Verhinderung der Datenexfiltration

Private Endpunkte bieten den stärksten Exfiltrationsschutz, da jeder Endpunkt einer einzelnen Ressourceninstanz zugeordnet ist. Ein Benutzer oder eine Anwendung in Ihrem VNet kann nur das bestimmte Speicherkonto oder die Datenbank erreichen, für das der private Endpunkt konfiguriert ist. Daten können nicht an eine andere Instanz desselben Diensttyps umgeleitet werden.

Dienstendpunkte beschränken dagegen den Zugriff auf VNet-Ebene, gelten jedoch für alle Instanzen eines Diensttyps. Beispielsweise bedeutet ein Dienstendpunkt für Azure Storage, dass das VNet jedes Azure Storage Konto erreichen kann, das Zugriff gewährt, nicht nur Ihr beabsichtigtes Konto. Diese Lücke macht Dienstendpunkte für Umgebungen unzureichend, in denen Datenexfiltration ein Compliance-Problem darstellt.

DNS-Zonenkonfiguration

Diagramm, das den Privaten Endpunkt-DNS-Auflösungsfluss vom Client über Azure DNS und private DNS-Zone zu Speicherkonto zeigt.

Private Endpunkte hängen von der korrekten DNS-Auflösung ab, um zu funktionieren. Wenn Sie einen privaten Endpunkt erstellen, konfigurieren Sie eine private DNS-Zone (zprivatelink.blob.core.windows.net. B. für Azure Blob Storage), sodass der Dienst-FQDN anstelle der öffentlichen IP in die private IP aufgelöst wird.

Falsch konfigurierte DNS-Zonen können dazu führen:

  • Anwendungen, die in die öffentliche IP-Adresse aufgelöst werden, umgehen den privaten Endpunkt vollständig.
  • Lokale Clients können die private IP nicht erreichen, da bedingte Weiterleitungen nicht konfiguriert sind.
  • Split-Brain-DNS-Probleme, bei denen einige Clients privat und andere öffentlich auflösen.

Zentralisieren Sie private DNS-Zonen in einem Gemeinsamen Dienst- oder Konnektivitätsabonnement, und verknüpfen Sie sie mit allen virtuellen Netzwerken, die eine Lösung benötigen. Verwenden Sie Azure Policy, um die Integration privater DNS-Zonen zu erzwingen, wenn private Endpunkte erstellt werden.

Netzwerkrichtlinien für private Endpunkt-Subnetze

Netzwerksicherheitsgruppen (Network Security Groups, NSGs) und benutzerdefinierte Routen (USER-Defined Routes, UDRs) werden jetzt in privaten Endpunktsubnetzen unterstützt. Diese Unterstützung ist standardmäßig deaktiviert und muss pro Subnetz explizit aktiviert sein. Nachdem Sie Netzwerkrichtlinien aktiviert haben:

  • Sie können NSG-Regeln anwenden, um zu steuern, welche Quellen den privaten Endpunkt erreichen können.
  • Sie können UDRs verwenden, um privaten Endpunktdatenverkehr über eine virtuelle Netzwerk-Appliance zur Überprüfung weiterzuleiten.
  • Sie können in ASG-Regeln (Application Security Group) auf private Endpunkte verweisen.

Aktivieren Sie Netzwerkrichtlinien für private Endpunkt-Subnetze in Produktionsumgebungen, um einen konsistenten Sicherheitsstatus für alle Subnetze in Ihrem virtuellen Netzwerk beizubehalten.

Important

Nachdem Sie einen privaten Endpunkt für einen PaaS-Dienst konfiguriert haben, deaktivieren Sie den öffentlichen Netzwerkzugriff auf diesen Dienst. Wenn der öffentliche Zugriff aktiviert bleibt, kann der Datenverkehr den Dienst weiterhin über das Internet erreichen, was den Zweck der privaten Konnektivität zwängt.

Privates DNS Zonen für gemeinsame Dienste

In der folgenden Tabelle sind die privaten DNS-Zonen aufgeführt, die für häufig verwendete Azure PaaS-Dienste erforderlich sind.

Azure-Dienst Privates DNS-Zone
Azure Blob Storage (Speicherdienst von Azure für unstrukturierte Daten) privatelink.blob.core.windows.net
Azure SQL-Datenbank privatelink.database.windows.net
Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel) privatelink.vaultcore.azure.net
Azure Cosmos DB (ein Microsoft-Datenbankdienst) privatelink.documents.azure.com
Azure App Service privatelink.azurewebsites.net

Tip

Wenn Sie einen privaten Endpunkt im Azure-Portal erstellen, wird häufig automatisch eine zugeordnete private DNS-Zone erstellt. Durch das Löschen des privaten Endpunkts wird die Zone oder ihre virtuellen Netzwerkverbindungen nicht immer entfernt. Regelmäßige Überwachung auf verwaiste private Endpunkte und private DNS-Zonen. Sie erhöhen die Kosten und die Komplexität Ihrer Konfiguration zur Namensauflösung.

Netzwerksicherheitsperimeter für PaaS-Zugriff

Private Link steuert, wie der Datenverkehr einen PaaS-Dienst über eine private IP-Adresse erreicht. Der Netzwerksicherheitsperimeter (Network Security Perimeter, NSP) steuert , welche Netzwerke und Ressourcen mit diesem Dienst kommunizieren dürfen. NSP fügt eine explizite Grenze um PaaS-Ressourcen wie Azure Storage, Azure SQL-Datenbank und Azure Key Vault hinzu: Ressourcen innerhalb des Umkreises kommunizieren frei, während der Zugriff von außen standardmäßig verweigert wird, es sei denn, eine Zugriffsregel erlaubt. Verwenden Sie NSP zusammen mit privaten Endpunkten, wenn Sie PaaS-Level-Datenexfiltrationsschutz in Hochsicherheitsdesigns benötigen. Wo NSP innerhalb der Sicherheitsebenen einzuordnen ist, siehe in der Übersicht die Sicherheitsstatus-Matrix.

Weitere Informationen

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Ausgehender Internetzugriff: Steuern Sie, wie Ihre migrierten Workloads das Internet über einen zentralen Ausgangspunkt erreichen.

Als Nächstes in Ihrer Modernisierungsreise:

Ausgehender Internetzugriff: Leiten Sie den gesamten Speichenausgang über die Hubfirewall weiter, um eine konsistente, IT-verwaltete Steuerung zu ermöglichen.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Netzwerküberwachung und -diagnose: Erhalten Sie Einblick in cloudübergreifende Datenverkehr und private Endpunktkonnektivität.

Wenn Ihr Cross-Cloud-Design einen zentralisierten ausgehenden Internetzugriff umfasst, lesen Sie zuerst Ausgehender Internetzugriff.

  • Last updated on