Storage muss privat bleiben? Private Endpoint erstellen

Veröffentlicht am:
#private-endpoint#storage-account

Ein Azure Storage Account besitzt standardmäßig einen öffentlichen Endpunkt. Authentifizierung schützt weiterhin die Daten, aber der Endpunkt bleibt aus dem Internet erreichbar. Ein Workload, der ausschließlich private Konnektivität verwenden darf, benötigt eine andere Grenze.

Erstelle einen privaten Storage Account und verbinde seinen Blob-Dienst über Azure Private Link mit snet-data:

WEB02 in snet-app
    |
    | storage-account.blob.core.windows.net wird privat aufgelöst
    v
Private-Endpoint-NIC in snet-data
    |
    `-- Azure Storage Blob-Dienst

Internet-Client ---> Öffentlicher Endpunkt ---> Blockiert

Dieser Trip baut auf Privater Dienst braucht einen privaten Namen? Private-DNS-Zone erstellen auf. Behalte vnet-cloudtrips-test-weu, snet-app, snet-data und WEB02. Die benutzerdefinierte Zone internal.cloudtrips.dev wird für Storage nicht verwendet; Azure Storage benötigt seine dienstspezifische Private-Link-Zone.

Die drei Kontrollen verstehen

Ein vollständiger privater Storage-Pfad kombiniert drei unabhängige Kontrollen:

Kontrolle Zweck
Private Endpoint Gibt dem Blob-Dienst eine private IP-Adresse im VNet
Private-DNS-Zone Löst den normalen Blob-Hostnamen innerhalb des VNets zur privaten IP-Adresse auf
Deaktivierter Public Network Access Lehnt Data-Plane-Traffic über den öffentlichen Endpunkt ab

Der Private Endpoint ersetzt die Authentifizierung nicht. Clients benötigen weiterhin einen Access Key, SAS oder eine Microsoft-Entra-Data-Plane-Rolle, um Daten zu lesen und zu schreiben.

Dieser Trip erstellt nur einen Endpunkt für die Subresource blob. File Shares, Queues, Tables und Data-Lake-Storage-Operationen über dfs benötigen eigene Private Endpoints und DNS-Zonen.

Namen für den Storage Account erzeugen

Storage-Account-Namen sind global eindeutig. Öffne Cloud Shell, wähle Bash und erzeuge einen stabilen Namen aus der aktuellen Subscription:

STORAGE_ACCOUNT="stctpe$(az account show --query id --output tsv | tr -d '-' | cut -c1-10)"
printf 'Storage account: %s\n' "$STORAGE_ACCOUNT"

Kopiere den angezeigten Wert. Er enthält nur Kleinbuchstaben und Zahlen und passt in das Namenslimit für Storage Accounts.

Ausschließlich privaten Storage erstellen

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

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

Stelle unter Networking Folgendes ein:

Public network access: Disable
Network routing: Microsoft network routing

Wähle Review + create > Create und öffne danach den Storage Account. Das Deaktivieren des öffentlichen Zugriffs blockiert die Storage Data Plane, verhindert aber nicht die Verwaltung des Accounts über die Azure Control Plane.

Erstellung des Azure Storage Accounts mit deaktiviertem Public Network Access

Der entsprechende CLI-Befehl lautet:

az storage account create \
  --resource-group rg-cloudtrips-network-test-weu \
  --name "$STORAGE_ACCOUNT" \
  --location westeurope \
  --sku Standard_LRS \
  --kind StorageV2 \
  --https-only true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --public-network-access Disabled

Verwende entweder das Portal oder die CLI, nicht beides.

Blob Private Endpoint erstellen

Öffne im Storage Account Security + networking > Networking > Private endpoint connections und wähle + Private endpoint.

Konfiguriere unter Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: pep-cloudtrips-storage-blob-test-weu
Network interface name: nic-pep-cloudtrips-storage-blob-test-weu
Region: West Europe

Behalte unter Resource die Option Connect to an Azure resource in my directory und wähle:

Resource type: Microsoft.Storage/storageAccounts
Resource: der STORAGE_ACCOUNT-Wert
Target sub-resource: blob

Konfiguriere unter Virtual Network:

Virtual network: vnet-cloudtrips-test-weu
Subnet: snet-data
Private IP configuration: Dynamically allocate IP address
Application security group: None

Behalte unter DNS für Integrate with private DNS zone den Wert Yes. Bestätige:

Private DNS zone: privatelink.blob.core.windows.net
Resource group: rg-cloudtrips-network-test-weu

Wähle Review + create > Create. Da du beide Ressourcen besitzt, genehmigt Azure die Private-Endpoint-Verbindung normalerweise automatisch.

Genehmigter Blob Private Endpoint mit snet-data und Private-DNS-Integration

Endpoint und DNS-Zone überprüfen

Kehre im Storage Account zur Seite Private endpoint connections zurück. Bestätige für pep-cloudtrips-storage-blob-test-weu den Status Approved.

Öffne Private DNS zones > privatelink.blob.core.windows.net. Bestätige:

  • Ein A Record mit dem Namen des Storage Accounts zeigt auf eine Adresse aus 10.20.2.x.
  • Ein Virtual Network Link verbindet die Zone mit vnet-cloudtrips-test-weu.

Die VM fragt den normalen Hostnamen <storage-account>.blob.core.windows.net ab, den DNS im verknüpften VNet zu <storage-account>.privatelink.blob.core.windows.net auflöst. Der A Record in der privaten DNS-Zone löst diesen privaten Namen anschließend zur 10.20.2.x-IP-Adresse des Private Endpoints auf.

Azure verwaltet den A Record über die DNS Zone Group des Private Endpoints. Ersetze ihn nicht durch einen manuell verwalteten Record.

Storage-Private-DNS-Zone mit verwaltetem A Record und VNet Link

Aus dem VNet auflösen und verbinden

Starte WEB02, falls die VM deallokiert ist:

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

Führe DNS- und HTTPS-Prüfungen von dieser VM aus:

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

Beide Ergebnisse sollten dieselbe private Endpoint-Adresse aus 10.20.2.x zeigen. Eine HTTP-Antwort 400 oder 403 ist normal, weil diese Anfrage keine Storage-Anmeldedaten enthält. Die übereinstimmende DNS-Adresse und remote_ip beweisen, dass die HTTPS-Verbindung den Private Endpoint verwendet hat. Der HTTP-Status beweist weder die Datenautorisierung noch eine Firewall-Entscheidung.

WEB02 löst den Storage-Blob-Endpunkt zur privaten IP-Adresse auf und verbindet sich

Deaktivierten öffentlichen Zugriff bestätigen

Cloud Shell befindet sich außerhalb von vnet-cloudtrips-test-weu. Führe aus:

getent ahostsv4 "${STORAGE_ACCOUNT}.blob.core.windows.net" | head -1

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

Cloud Shell sollte eine öffentliche Azure-Adresse auflösen und sich mit ihr verbinden; die Anfrage liefert normalerweise HTTP 403. Untersuche einen vorhandenen Header x-ms-error-code, interpretiere eine nicht authentifizierte 403-Antwort allein aber nicht als Beweis einer Netzwerkblockierung: Storage verwendet 403 auch für verschiedene Authentifizierungs- und Autorisierungsfehler. Public DNS bleibt erwartbar. Ausschließlich privat bedeutet, dass der öffentliche Datenendpunkt Data-Plane-Zugriff ablehnt, nicht dass sein öffentlicher Hostname verschwindet.

Cloud Shell zeigt, dass der öffentliche Zugriff auf den Storage-Blob-Endpunkt blockiert ist

Bestätige die Account-Einstellung und die Private-Endpoint-Verbindung ausdrücklich:

az storage account show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name "$STORAGE_ACCOUNT" \
  --query publicNetworkAccess \
  --output tsv

az network private-endpoint show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name pep-cloudtrips-storage-blob-test-weu \
  --query 'privateLinkServiceConnections[].{Name:name,Status:privateLinkServiceConnectionState.status}' \
  --output table

Erwarte Disabled und eine Private-Endpoint-Verbindung mit dem Status Approved. Zusammen mit der privaten remote_ip von WEB02 bestätigen diese Einstellungen eindeutig die beabsichtigte Konfiguration aus deaktiviertem öffentlichem Zugriff und Private Endpoint.

Verwende für einen vollständigen Data-Plane-Enforcement-Test dieselbe kurzlebige Read-only-SAS oder dieselbe Managed Identity für einen Lesezugriff von WEB02 und von einem Client außerhalb des VNets. Der Lesezugriff muss über den Private Endpoint erfolgreich sein und über den öffentlichen Endpunkt fehlschlagen. Behandle die Anmeldedaten ü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 ist das Cloud-Shell-curl nur eine diagnostische Beobachtung und kein eigenständiger Beweis.

Cloud Shell zeigt deaktivierten Public Network Access und die genehmigte Private-Endpoint-Verbindung

Private-Endpoint-Lab behalten oder entfernen

Behalte die Ressourcen, wenn der nächste Trip privaten Storage verwendet. Deallokiere WEB02, sobald du die VM nicht mehr benötigst:

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

Um nur dieses Lab zu entfernen, lösche den Private Endpoint, den Storage Account und die Storage-spezifische Private-DNS-Zone. Behalte VNet, Subnetze, VMs und die Zone internal.cloudtrips.dev für andere Networking-Trips.