PaaS-Netzwerkgrenze benötigt? Konfiguriere Network Security Perimeter

Azure-PaaS-Dienste stellen Data-Plane-Endpunkte bereit, ohne dass sich der Dienst selbst in deinem virtuellen Netzwerk befindet. Eigene öffentliche Netzwerkregeln an jeder Ressource werden mit wachsender Anzahl von Diensten schwer beherrschbar. Azure Network Security Perimeter (NSP) bildet eine logische Grenze um unterstützte PaaS-Ressourcen und steuert ihren öffentlichen eingehenden und ausgehenden Traffic zentral.

Erstelle in diesem Trip einen eigenen Key Vault, ordne ihn einem NSP-Profil zu, erlaube nur die öffentliche IPv4-Adresse deiner Workstation und ändere die Zuordnung von Transition auf Enforced.

Öffentliche Administrator-IPv4
          |
          | Inbound Access Rule
          v
Network Security Perimeter Profile
          |
          v
      Azure Key Vault

NSP schützt den öffentlichen Data-Plane-Zugriff. Microsoft-Entra- Authentifizierung und Key Vault RBAC bestimmen weiterhin, was ein zugelassener Aufrufer tun darf. Eine Netzwerk-Allow-Regel gewährt keinen Zugriff auf Secrets.

Diese Netzwerkmechanismen lösen unterschiedliche Probleme:

Mechanismus	Verwendeter Endpunkt	Hauptzweck	Verhalten mit NSP
Network Security Perimeter	Öffentlicher PaaS-Endpunkt	Beschränkt, welche öffentlichen Quellen zugeordnete PaaS-Ressourcen erreichen	NSP-Zugriffsregeln steuern öffentlichen Traffic
Private Endpoint (Private Link)	Private IP-Adresse in deinem VNet	Gibt Workloads private VNet-Konnektivität zur PaaS-Ressource	Ohne öffentliche NSP-Zugriffsregel erlaubt
Basic Service Endpoint	Öffentlicher PaaS-Endpunkt; Traffic wird anhand seines Quellsubnetzes erkannt	Erlaubt der Firewall einer einzelnen PaaS-Ressource, ausgewählten Subnetzen zu vertrauen	Traditioneller Service-Endpoint-Traffic ist kein NSP-Integrationspfad
Standard Service Endpoint (Public Preview)	Öffentlicher PaaS-Endpunkt; das Subnetz wird durch einen Network Identifier repräsentiert	Erlaubt einer NSP-Regel, ein genehmigtes Subnetz ohne Private Endpoint zu erkennen	Eine NSP-Inbound-IP-Regel kann den Network Identifier zulassen; Preview-Einschränkungen gelten

Verwende einen Private Endpoint, wenn eine Workload die PaaS-Ressource über eine private VNet-Adresse erreichen muss. Verwende NSP, wenn genehmigte Aufrufer den öffentlichen Endpunkt der Ressource verwenden müssen.

Wann ein Service Endpoint sinnvoll ist

VM in einem genehmigten Subnetz
          |
          | als Traffic aus snet-app erkannt
          v
Öffentlicher Key-Vault-Endpunkt

Der Basic Service Endpoint aus dem vorherigen Storage-Trip erlaubt der Firewall einer PaaS-Ressource, Traffic aus ausgewählten VNet-Subnetzen zu vertrauen. Der Dienst verwendet weiterhin seinen öffentlichen Endpunkt und erhält keine private IP-Adresse in deinem VNet. Die Konfiguration wird normalerweise für jede PaaS-Ressource wiederholt, benötigt jedoch weder Private Endpoint noch Private DNS. Dieser traditionelle Subnetzidentitäts-Traffic wird nicht als Konnektivitätsmethode für eine NSP-zugeordnete Ressource unterstützt.

Eine separate Variante namens Standard Service Endpoint befindet sich in Public Preview. Sie ordnet dem Subnetz eine statische Standard Public IP als Network Identifier zu. Diese Adresse identifiziert das Subnetz gegenüber einer NSP-Inbound-IP-Regel; sie wird nicht zum Routing der Pakete verwendet. Der PaaS-Dienst nutzt weiterhin seinen öffentlichen Endpunkt und besitzt weiterhin keine private IP im VNet. Da die Preview kein SLA bietet, prüfe ihre unterstützten Dienste und Einschränkungen, bevor du sie erwägst. Behandle den im vorherigen Trip konfigurierten Basic Endpoint nicht als gleichwertig.

Verwende einen Basic Service Endpoint, wenn ein oder wenige Subnetze kontrollierten Zugriff auf eine nicht NSP-zugeordnete PaaS-Ressource benötigen und deren öffentlicher Endpunkt akzeptabel ist. Prüfe die Standard-Preview- Variante nur, wenn ein NSP-zugeordneter Dienst ein Subnetz über seinen öffentlichen Endpunkt erkennen muss. Wähle einen Private Endpoint, wenn die Workload eine private VNet-Adresse benötigt.

Wann Network Security Perimeter sinnvoll ist

Genehmigte öffentliche Laptop-IP --+
Key Vault                           +--> NSP-Profil
Storage Account --------------------+

NSP steuert den öffentlichen Zugriff auf mehrere zugeordnete PaaS-Ressourcen zentral. Inbound-Regeln können genehmigte öffentliche IP-Bereiche oder Abonnements zulassen; unterstützte Outbound-Regeln können Ziel-FQDNs einschränken. NSP ist deshalb sinnvoll, wenn eine Organisation eine gemeinsame öffentliche Netzwerkgrenze benötigt, statt unabhängige Regeln an jedem Dienst zu pflegen.

Verwende NSP, wenn genehmigte Administratoren, Anwendungen oder Dienste eine oder mehrere PaaS-Ressourcen über deren öffentliche Endpunkte erreichen müssen.

Wann ein Private Endpoint sinnvoll ist

Private IP der VM:       10.20.1.4
          |
          | privater VNet-Pfad
          v
Key-Vault-Endpunkt:      10.20.2.5

Ein Private Endpoint erstellt eine Netzwerkschnittstelle mit einer privaten IP-Adresse in deinem VNet. Private DNS löst den normalen Dienst-Hostnamen für verbundene Clients auf diese private IP auf. Danach kann der öffentliche Zugriff deaktiviert werden. Das bietet starke private Netzwerkisolation, erfordert aber die Verwaltung des Private Endpoint und seiner DNS- Konfiguration.

Verwende einen Private Endpoint, wenn Workloads in einem VNet, einem lokalen Netzwerk oder einem per VPN verbundenen Netzwerk die PaaS-Ressource erreichen müssen, ohne deren öffentlichen Endpunkt zu verwenden.

Wähle für CloudTrips:

Anforderung	Passender Mechanismus
Der Laptop eines Administrators erreicht Key Vault über seine genehmigte öffentliche IP	Network Security Perimeter
Ein VM-Subnetz erreicht eine nicht NSP-zugeordnete PaaS-Ressource über deren öffentlichen Endpunkt	Basic Service Endpoint
Ein NSP-zugeordneter Dienst muss ein Subnetz über seinen öffentlichen Endpunkt erkennen und Preview-Nutzung ist akzeptabel	Standard Service Endpoint mit Network Identifier (Public Preview)
Eine VM erreicht PaaS über eine private IP im VNet	Private Endpoint

Diese Ressourcen können Kosten verursachen. Führe die Bereinigung am Ende zeitnah durch. Bezeichnungen und Positionen im Portal können sich mit der Weiterentwicklung des Dienstes geringfügig ändern.

Eigenen Key Vault erstellen

Setze wiederverwendbare Namen in Azure Cloud Shell. Der generierte Key-Vault- Name ist global eindeutig und bleibt innerhalb seines Limits von 24 Zeichen:

RG_NAME="rg-cloudtrips-network-test-weu"
LOCATION="westeurope"
SUBSCRIPTION_ID=$(az account show --query id --output tsv)
NSP_VAULT="kv-ct-nsp-${SUBSCRIPTION_ID//-/}"
NSP_VAULT=${NSP_VAULT:0:24}

az keyvault create \
  --resource-group "$RG_NAME" \
  --name "$NSP_VAULT" \
  --location "$LOCATION" \
  --enable-rbac-authorization true

printf 'Key Vault: %s\n' "$NSP_VAULT"

Bewahre den ausgegebenen Vault-Namen auf. Auch die vom Portal generierte NSP- Zuordnung verwendet den Ressourcennamen; kurze Namen verhindern Probleme mit der maximalen Länge des Zuordnungsnamens.

Perimeter und Profil erstellen

Suche im Azure-Portal nach Network security perimeters und wähle Create. Konfiguriere unter Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: nsp-cloudtrips-test-weu
Region: West Europe
Profile name: profile-cloudtrips-paas

Wähle Review + create > Create. Das Perimeter ist die übergeordnete Grenze; das Profil enthält Ressourcenzuordnungen und Zugriffsregeln. Weitere unterstützte PaaS-Ressourcen können später demselben Profil beitreten.

Key Vault im Transition-Modus zuordnen

Öffne nsp-cloudtrips-test-weu, wähle Settings > Profiles und öffne profile-cloudtrips-paas. Wähle unter Associated resources > Add und den zuvor ausgegebenen Key Vault.

Belasse die Zuordnung zunächst im Modus Transition. Transition ist der sichere Start: Der Modus zeichnet die erwartete Wirkung auf den öffentlichen Zugriff auf, während die vorhandenen Netzwerkregeln der Ressource weiter gelten. Bestätige folgende Werte:

Resource type: Microsoft.KeyVault/vaults
Access mode: Transition

Du musst Public network access für dieses Lab nicht auf SecuredByPerimeter ändern. Im Transition-Modus steuert weiterhin die vorhandene publicNetworkAccess-Einstellung des Key Vault den Zugriff. Nach dem Wechsel der Zuordnung auf Enforced überschreiben die NSP-Regeln diese Einstellung und steuern den öffentlichen Zugriff.

Eine Administratoradresse erlauben

Ermittle die öffentliche IPv4-Adresse der Workstation, von der aus du testest. Verwende einen vom Unternehmen freigegebenen IP-Dienst oder frage das Netzwerkteam. Trage nicht die private Adresse der Workstation aus 10.x, 172.16-31.x oder 192.168.x ein. Ändert ein VPN oder NAT Gateway die öffentliche Adresse, passt die Regel nicht mehr. Azure Cloud Shell verwendet ebenfalls eine andere Egress-Adresse; führe den abschließenden Test von der Workstation aus, die die Regel repräsentiert.

Wähle in profile-cloudtrips-paas Inbound access rules > Add:

Rule name: Allow-Admin-IPv4
Source type: IP address ranges
Allowed sources: <deine-öffentliche-IPv4>/32

/32 erlaubt exakt eine IPv4-Adresse. Verwende nicht 0.0.0.0/0; dies würde jede öffentliche IPv4-Quelle zulassen und die Grenze dieses Labs aufheben.

Für diesen Key-Vault-Test ist keine Outbound-Regel nötig. Outbound-NSP-Regeln verwenden vollqualifizierte Domainnamen und werden nur benötigt, wenn ein zugeordneter Dienst unterstützte öffentliche ausgehende Verbindungen startet.

Grenze erzwingen und prüfen

Kehre zu Associated resources zurück, öffne das Menü des Key Vault und wähle Change access mode > Enforced. Bestätige die Änderung. Enforced verweigert öffentlichen Traffic, sofern er nicht aus demselben Perimeter kommt oder einer expliziten Zugriffsregel entspricht. Private-Endpoint-Traffic bleibt erlaubt.

Ersetze auf der Workstation mit der erlaubten öffentlichen IP den Platzhalter und sende eine authentifizierte Anfrage an die Key-Vault-Data-Plane. az rest bezieht ein Bearer Token für die in Azure CLI angemeldete Identität; das Token erscheint nicht im Befehl:

NSP_VAULT="<ausgegebener-key-vault-name>"

az account show \
  --query '{User:user.name,Tenant:tenantId}' \
  --output table

az rest \
  --method get \
  --url "https://${NSP_VAULT}.vault.azure.net/secrets?api-version=7.4" \
  --resource "https://vault.azure.net"

Besitzt die Identität die Berechtigung zum Auflisten von Secret-Metadaten, erwarte eine erfolgreiche JSON-Antwort. Fehlt ihr diese Data-Plane-Rolle, ist ein Autorisierungsfehler nur dann akzeptabel, wenn sein JSON-Fehler RBAC oder Berechtigungen betrifft und weder ForbiddenByFirewall noch Request was not allowed by NSP rules oder eine Meldung über eine nicht autorisierte Clientadresse enthält. Dies ist ein authentifizierter Netzwerkpfadtest. Eine reine 401-Antwort von curl beweist nur ein fehlendes Bearer Token und reicht nicht aus.

Melde dich für den eindeutigen Negativtest mit derselben Azure-Identität auf einem Computer mit anderer öffentlicher IP an und führe exakt dieselbe az rest-Anfrage aus. Sie muss einen netzwerkspezifischen Fehler wie ForbiddenByFirewall oder eine Meldung liefern, die ausdrücklich die Ablehnung der Clientadresse durch NSP-Regeln nennt. Eine allgemeine 403-Antwort allein ist kein Beweis. Erweitere die Regel nicht, nur um eine wechselnde Cloud-Shell- Egress-Adresse zuzulassen.

Perimeter-Lab entfernen

Lösche kein Perimeter, während eine Anwendungsressource unbeabsichtigt dadurch geschützt bleibt. Gehe in profile-cloudtrips-paas so vor:

1. Ändere den Key Vault unter Associated resources auf Transition.
2. Entferne die Key-Vault-Zuordnung.
3. Lösche Allow-Admin-IPv4.
4. Lösche profile-cloudtrips-paas, danach nsp-cloudtrips-test-weu.

Lösche zuletzt nur den dedizierten Lab-Vault:

az keyvault delete \
  --resource-group "rg-cloudtrips-network-test-weu" \
  --name "$NSP_VAULT"

Behalte CloudTrips-VNets, Load Balancer, VMs, Network Watcher und alle Anwendungsressourcen. NSP steuerte eine PaaS-Data-Plane-Grenze; es ersetzte weder deren NSGs noch die Virtual-Network-Manager-Konfiguration.

Der nächste Trip ergänzt DNS-basiertes Failover zwischen den regionalen CloudTrips-Webendpunkten.