Einführung
Die Härtung des Datenebenen-Zugriffs auf ein Speicherkonto ist eine gängige Praxis zur Verbesserung der Sicherheit. Bei der Verwendung von Azure-Ressourcen mit Virtual Network (VNET)-Integration oder beim Zugriff auf Speicherendpunkte von privaten IPs oder anderen Mandanten können jedoch Autorisierungsfehler auftreten, wenn die Quelle nicht ordnungsgemäß auf die Positivliste gesetzt wurde. Dieser Artikel untersucht häufige Szenarien, die zu solchen Fehlern führen, und bietet umsetzbare Lösungen.
Häufige Szenarien für Autorisierungsfehler
Szenario 1: Zugriff aus einer anderen Region
Wenn die Quelle, von der der Aufruf stammt, aus einer anderen Azure-Region kommt, lässt sich das Problem in der Regel beheben, indem Sie die öffentliche IP-Adresse der Quelle zur Firewall des Speicherkontos hinzufügen.
Szenario 2: Zugriff aus derselben Region schlägt fehl
Anfragen aus derselben Azure-Region verwenden häufig private Azure-IP-Adressen anstelle öffentlicher IPs. In diesem Fall schlägt das Hinzufügen öffentlicher IPs zur Positivliste fehl. Siehe Azure Storage-Firewalls und virtuelle Netzwerke konfigurieren für weitere Details.
Szenario 3: Zugriff auf ein bestimmtes Subnetz beschränken
Wenn Ressourcen keine öffentlichen IPs besitzen, der Kunde den Zugriff aber auf ein bestimmtes Subnetz beschränken möchte, kann es aufgrund von Sichtbarkeitseinschränkungen zu Problemen kommen. Die Firewall des Speicherkontos zeigt das Zielsubnetz möglicherweise nicht an, sodass ein manuelles Hinzufügen zur Positivliste durch eine Person mit RBAC-Zugriff als Mitwirkender (Contributor) Zugriff oder höher erforderlich ist.
Szenario 4: Zugriff von einem anderen Azure-Mandanten
Wenn Ressourcen, die auf das Speicherkonto zugreifen möchten, zu einem anderen Azure-Mandanten gehören, sind zusätzliche Schritte erforderlich, um das Quellsubnetz auf die Positivliste zu setzen.
Lösungsschritte
Hinzufügen eines Subnetzes von einem anderen Mandanten
Um ein Subnetz aus einem virtuellen Netzwerk in einem anderen Azure-Mandanten auf die Positivliste zu setzen, muss der Parameter VirtualNetworkResourceId verwendet werden. Dabei muss der Subnetz-URI in der folgenden Form angegeben werden:
/subscriptions/<subscription-ID>/resourceGroups/<resourceGroup-Name>/providers/Microsoft.Network/virtualNetworks/<vNet-name>/subnets/<subnet-name>
Beispiel für einen PowerShell-Befehl
Um den Subnetz-URI abzurufen, verwenden Sie den folgenden Befehl:
$subnet = Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Get-AzVirtualNetworkSubnetConfig -Name "mysubnet"
Wenn der Benutzer im Quellmandanten nicht über ausreichende Zugriffsrechte verfügt, um diesen Befehl auszuführen, kann er den Subnetz-URI abrufen, indem er den JSON-Text der VNET-Ressource in Azure prüft. Dies erfordert READ-Zugriff auf die Steuerungsebene für die Ressource.
Aktivieren des Storage-Dienstendpunkts
Stellen Sie vor dem Hinzufügen des Subnetzes zur Positivliste sicher, dass der Dienstendpunkt Microsoft.Storage oder Microsoft.Storage.Global aktiviert ist. Dies kann mit Azure PowerShell, der CLI oder dem Azure-Portal erfolgen. Eine Schritt-für-Schritt-Anleitung finden Sie unter Azure Storage-Firewalls und virtuelle Netzwerke konfigurieren.
Beispielbefehl für das Hinzufügen zur Positivliste
Sobald der Subnetz-URI vorliegt, verwenden Sie den folgenden Befehl, um die Netzwerkregel hinzuzufügen:
Add-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -AccountName "mystorageaccount" -VirtualNetworkResourceId $subnet
Überprüfung
Um die Verbindung zu überprüfen, verwenden Sie den Befehl curl mit einem SAS-Token:
curl https://storageaccountname.blob.core.windows.net/container/hello.txt?<SAS token>
Tipp:
- Das Flag
-vim Befehlcurlaktiviert die ausführliche Ausgabe, mit der sich HTTP-Antworten identifizieren lassen, wie zum Beispiel403 Forbidden. Entfernen Sie das Flag für eine übersichtlichere Ausgabe.

Das folgende Beispiel zeigt das Subnetz in der Firewall des Ziel-Speicherkontos

Tipp: Die hervorgehobene Warnung kann gefahrlos ignoriert werden; sie hängt mit dem READ-Zugriff auf die Steuerungsebene über das auf die Positivliste gesetzte Subnetz zusammen; der Zugriff auf die Datenebene wird zugelassen.
Weitere Überlegungen
- Aktivierung von Dienstendpunkten: Das Aktivieren des Storage-Dienstendpunkts kann zu vorübergehenden Verbindungsunterbrechungen führen. Weitere Informationen finden Sie unter Azure Virtual Network-Dienstendpunkte.
- Private Endpunkte: Private Endpunkte umgehen Firewall-Netzwerkregeln, da sie auf DNS und Konnektivität über das autorisierte Subnetz angewiesen sind. Siehe Private Endpunkte verwenden – Azure Storage.
- Steuerungsebene im Vergleich zur Datenebene: Das Verständnis des Unterschieds zwischen Steuerungsebenen- und Datenebenen-Vorgängen ist für die Fehlerbehebung entscheidend. Weitere Informationen finden Sie unter Vorgänge auf Steuerungs- und Datenebene.
Fazit
Autorisierungsfehler beim Zugriff auf Azure Storage-Endpunkte resultieren häufig aus falsch konfigurierten Firewall-Regeln oder unzureichender Subnetz-Sichtbarkeit. Wenn Sie die oben beschriebenen Schritte befolgen, können Sie diese Probleme effektiv beheben und lösen und so einen sicheren und nahtlosen Zugriff auf die Datenebene gewährleisten.