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
Service Endpoint	Öffentlicher PaaS-Endpunkt; Traffic wird anhand seines Quellsubnetzes erkannt	Erlaubt der PaaS-Firewall, ausgewählten Subnetzen zu vertrauen	Für NSP-zugeordnete Ressourcen nicht unterstützt

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

Ein Service Endpoint 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.

Verwende einen Service Endpoint, wenn ein oder wenige VNet-Subnetze kontrollierten Zugriff auf eine PaaS-Ressource benötigen und der öffentliche Endpunkt des Dienstes akzeptabel ist. Verwende ihn nicht für eine NSP- zugeordnete Ressource; wähle einen Private Endpoint, wenn diese Ressource VNet- Konnektivität 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	Service Endpoint
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 nicht authentifizierte Anfrage an die Key-Vault-Data-Plane:

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

curl --include --max-time 10 \
  "https://${NSP_VAULT}.vault.azure.net/secrets?api-version=7.4"

Eine Authentifizierungs- oder Autorisierungsantwort beweist, dass die Anfrage die Netzwerkgrenze passiert und Key Vault erreicht hat; sie gewährt keinen Secret-Zugriff. Die Antwort darf nicht melden, dass die Clientadresse durch das Network Security Perimeter blockiert wurde.

Sende für einen negativen Test dieselbe Anfrage von einem Computer mit anderer öffentlicher IP. Das Perimeter sollte sie abweisen. 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.