PaaS-Zugriff soll auf dem Azure Backbone bleiben? Service Endpoint erstellen

Veröffentlicht am: 13. August 2026

Azure-PaaS-Dienste verwenden normalerweise öffentliche Endpunkte. Ein Virtual Network Service Endpoint fügt eine direkte Route von einem Subnetz zu einem unterstützten Azure-Dienst über das Microsoft Backbone hinzu und ermöglicht dem Dienst, dieses Subnetz zu identifizieren.

Konfiguriere snet-app für Azure Storage und erlaube einem neuen Storage Account den Zugriff nur aus diesem Subnetz:

WEB02 in snet-app
    |
    | Microsoft.Storage-Service-Endpoint-Route
    v
Öffentlicher Storage-Endpunkt über das Azure Backbone
    |
    `-- Storage Firewall erlaubt snet-app

Anderes Netzwerk ---> Öffentlicher Storage-Endpunkt ---> Blockiert

Dieser Trip baut auf Storage muss privat bleiben? Private Endpoint erstellen auf. Behalte vnet-cloudtrips-test-weu, snet-app und WEB02. Dieses Lab verwendet einen separaten Storage Account, damit der ausschließlich private Account aus dem vorherigen Trip unverändert bleibt.

Service Endpoint und Private Endpoint vergleichen

Beide Optionen halten den Traffic vom VNet zum Dienst im Microsoft-Netzwerk, verwenden aber unterschiedliche Netzwerkmodelle:

Eigenschaft	Service Endpoint	Private Endpoint
Ziel	Öffentliche IP-Adresse des Dienstes	Private IP-Adresse im VNet
DNS-Änderung	Keine	Private DNS wird normalerweise benötigt
Konfigurationsumfang	Subnetz plus Service Firewall	Private-Endpoint-NIC plus Dienstgenehmigung
Zugriff von On-Premises	Nicht direkt	Über verbundene Netzwerke und DNS

Ein Service Endpoint stellt weder eine NIC noch eine private IP-Adresse im VNet bereit. DNS löst <account>.blob.core.windows.net weiterhin zu einer öffentlichen Storage-Adresse auf. Azure leitet den Traffic direkt über sein Backbone und präsentiert der Storage Firewall die Identität des Subnetzes.

Microsoft.Storage im Subnetz aktivieren

Öffne im Azure-Portal:

Virtual networks > vnet-cloudtrips-test-weu > Settings > Service endpoints

Wähle + Add und konfiguriere:

Service: Microsoft.Storage
Subnets: snet-app

Wähle Add und warte, bis Microsoft.Storage für snet-app mit einem erfolgreichen Provisioning-Status angezeigt wird.

Microsoft.Storage Service Endpoint im CloudTrips-Anwendungssubnetz aktiviert

Der entsprechende CLI-Befehl lautet:

az network vnet subnet update \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-test-weu \
  --name snet-app \
  --service-endpoints Microsoft.Storage

Verwende entweder das Portal oder die CLI. Wenn das Subnetz bereits andere Service Endpoints besitzt, ersetze sie nicht mit diesem Befehl. Füge Microsoft.Storage hinzu und behalte die vorhandenen Werte.

Storage Account für den Service Endpoint erstellen

Öffne Cloud Shell, wähle Bash und erzeuge einen global eindeutigen Namen:

SERVICE_STORAGE="stctse$(az account show --query id --output tsv | tr -d '-' | cut -c1-10)"
printf 'Service-endpoint storage account: %s\n' "$SERVICE_STORAGE"

Suche im Azure-Portal nach Storage accounts, wähle + Create und konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Storage account name: der SERVICE_STORAGE-Wert
Region: West Europe
Performance: Standard
Redundancy: Locally-redundant storage (LRS)

Konfiguriere unter Networking:

Public network access: Enable
Public network access scope: Enable from selected virtual networks and IP addresses
Virtual network: vnet-cloudtrips-test-weu
Subnet: snet-app

Füge weder deine Client-IP-Adresse hinzu noch aktiviere eine Ausnahme für Trusted Services. Wähle Review + create > Create.

Storage-Networking ist auf die Virtual-Network-Regel für snet-app beschränkt

Der entsprechende CLI-Ablauf lautet:

az storage account create \
  --resource-group rg-cloudtrips-network-test-weu \
  --name "$SERVICE_STORAGE" \
  --location westeurope \
  --sku Standard_LRS \
  --kind StorageV2 \
  --https-only true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --public-network-access Enabled \
  --default-action Deny \
  --bypass None

az storage account network-rule add \
  --resource-group rg-cloudtrips-network-test-weu \
  --account-name "$SERVICE_STORAGE" \
  --vnet-name vnet-cloudtrips-test-weu \
  --subnet snet-app

Prüfen, dass DNS nicht privat wurde

Starte WEB02 bei Bedarf und löse den Blob-Hostnamen von der VM auf:

az vm start \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "getent ahostsv4 ${SERVICE_STORAGE}.blob.core.windows.net | head -1"

Die Antwort sollte eine öffentliche Azure-IP-Adresse sein, keine Adresse aus 10.20.x.x. Das ist beabsichtigt: Ein Service Endpoint ändert Routing und Dienstautorisierung, nicht den DNS Record des Dienstes.

WEB02 löst den Service-Endpoint-Storage-Hostnamen zu einer öffentlichen Azure-Adresse auf

Backbone-Route überprüfen

Ermittle die mit WEB02 verbundene NIC und untersuche ihre effektiven Routen:

WEB02_NIC=$(az vm show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --query 'networkProfile.networkInterfaces[0].id' \
  --output tsv)

az network nic show-effective-route-table \
  --ids "$WEB02_NIC" \
  --query "value[?nextHopType=='VirtualNetworkServiceEndpoint'].{Prefix:addressPrefix[0],NextHop:nextHopType,State:state}" \
  --output table

Erwarte eine oder mehrere aktive Routen mit dem Next Hop VirtualNetworkServiceEndpoint. Azure veröffentlicht Service-Adresspräfixe, daher kann die Ausgabe mehrere Zeilen enthalten.

Effektive WEB02-Routen zeigen VirtualNetworkServiceEndpoint als Next Hop

Antworten vergleichen und die Grenze überprüfen

Sende von WEB02 eine nicht authentifizierte HTTPS-Anfrage:

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "curl --silent --show-error --dump-header - --output /dev/null --write-out 'remote_ip=%{remote_ip} http_code=%{http_code}\n' https://${SERVICE_STORAGE}.blob.core.windows.net/?comp=list"

Die öffentliche remote_ip und die Storage-Antwort bestätigen DNS- und HTTPS- Erreichbarkeit. Da diese Anfrage keine Storage-Anmeldedaten enthält, beweisen HTTP 403 und ein x-ms-error-code wie AuthorizationFailure allein jedoch nicht, dass die Storage Firewall das Subnetz akzeptiert hat. Storage kann denselben Status für Authentifizierungs-, Autorisierungs- und Netzwerkbeschränkungen verwenden.

WEB02 erreicht Azure Storage über das erlaubte Service-Endpoint-Subnetz

Führe dieselbe Anfrage aus Cloud Shell aus, die sich außerhalb von snet-app befindet:

curl --silent --show-error \
  --dump-header - \
  --output /dev/null \
  --write-out 'remote_ip=%{remote_ip} http_code=%{http_code}\n' \
  "https://${SERVICE_STORAGE}.blob.core.windows.net/?comp=list"

Auch diese Anfrage liefert normalerweise 403. Untersuche den Header x-ms-error-code, bezeichne den Status allein aber nicht als Beweis dafür, dass die Network ACL Cloud Shell abgewiesen hat. Der öffentliche Endpunkt existiert weiterhin; die konfigurierte ACL soll nur die VNet-Regel zulassen.

Cloud-Shell-Anfrage wird außerhalb des erlaubten Service-Endpoint-Subnetzes abgelehnt

Bestätige beide Seiten der Konfiguration:

az network vnet subnet show \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-test-weu \
  --name snet-app \
  --query 'serviceEndpoints[].service' \
  --output tsv

az storage account network-rule list \
  --resource-group rg-cloudtrips-network-test-weu \
  --account-name "$SERVICE_STORAGE" \
  --query '{DefaultAction:defaultAction,Bypass:bypass,VNetRules:virtualNetworkRules[].{State:state,Subnet:id}}' \
  --output yaml

Erwarte Microsoft.Storage, DefaultAction: Deny, Bypass: None und eine aktivierte Regel für snet-app. Die effektive Route und diese beiden Control- Plane-Abfragen bestätigen, dass Basic Service Endpoint und Storage-VNet-Regel auf beiden Seiten konfiguriert sind.

Führe für eine eindeutige Data-Plane-Prüfung denselben Lesezugriff mit einer kurzlebigen Read-only-SAS von WEB02 und von einem Client außerhalb von snet-app aus. Er muss von WEB02 erfolgreich sein und von außen fehlschlagen. Behandle die SAS über den genehmigten Secret-Bereitstellungsprozess deiner Organisation. Füge niemals einen Account Key oder eine SAS in Run Command, Screenshots oder dieses Repository ein. Ohne diesen authentifizierten Vergleich sind die beiden curl-Aufrufe nur eingegrenzte Beobachtungen von Konnektivität und Fehlercode, kein eigenständiger Allow/Deny-Beweis.

Service-Endpoint-Lab behalten oder entfernen

Deallokiere WEB02 nach dem Test. Behalte Service Endpoint und Storage Account, wenn ein späterer Workload sie verwendet.

Um dieses Lab zu entfernen, lösche den Service-Endpoint-Storage-Account und entferne den Microsoft.Storage Service Endpoint aus snet-app nur dann, wenn keine andere Storage-Ressource davon abhängt. Behalte VNet, Subnetz, VM, Private Endpoint und Private-DNS-Ressourcen aus früheren Networking-Trips.