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

Erlaubte und blockierte Anfragen vergleichen

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 --include https://${SERVICE_STORAGE}.blob.core.windows.net/?comp=list | head -20"

Die Anfrage erreicht den Blob-Dienst über den Service Endpoint. Eine 403-Authentifizierungsantwort ist zu erwarten, weil die Anfrage keine Storage-Anmeldedaten besitzt. Entscheidend ist, dass die Storage Firewall den Subnetzpfad akzeptiert, bevor die normale Data-Plane-Authentifizierung geprüft wird.

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 --include \
  "https://${SERVICE_STORAGE}.blob.core.windows.net/?comp=list" \
  | head -20

Storage lehnt diese Anfrage ab, weil Cloud Shell nicht zum erlaubten Subnetz gehört. Der öffentliche Endpunkt existiert weiterhin, aber seine Network ACL erlaubt nur die konfigurierte VNet-Regel.

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.

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.