In meinen Azure-Kursen taucht die Frage nach der Storage-Firewall regelmäßig auf – meistens dann, wenn jemand verstehen will, warum ein Storage Account trotz aktivierter Netzwerkrestriktionen plötzlich von einem anderen Azure-Dienst nicht mehr erreichbar ist. Seit einiger Zeit zeigt das Azure Portal bei den Netzwerkeinstellungen eines Storage Accounts eine neue Option: Network Security Perimeter. Diese ergänzt die bekannten Methoden „Disabled“, „Enabled from selected virtual networks and IP addresses“ und „Enabled from all networks“ um eine vierte Variante, die konzeptionell einen anderen Ansatz verfolgt. Höchste Zeit, das genauer anzuschauen.
Was ist der Network Security Perimeter überhaupt?
Der Network Security Perimeter (kurz: NSP) ist eine relativ neue Azure-Ressource, die Microsoft unter dem Dach des Azure-Netzwerksicherheitsportfolios eingeführt hat. Das Konzept stammt aus dem Zero-Trust-Umfeld: Statt einzelne Dienste mit IP-Allowlists oder VNET-Peerings abzusichern, definieren Sie einen logischen Sicherheitsperimeter auf Ressourcenebene. Alle Ressourcen, die diesem Perimeter zugeordnet werden, können intern miteinander kommunizieren – unabhängig davon, ob sie sich im gleichen VNET befinden oder nicht.
Technisch gesehen ist der NSP eine ARM-Ressource vom Typ Microsoft.Network/networkSecurityPerimeters. Sie erstellen einen Perimeter, ordnen ihm sogenannte Profile zu, und verknüpfen dann PaaS-Ressourcen (Platform-as-a-Service) wie Storage Accounts, Key Vaults oder Cosmos DB mit diesem Perimeter. Der Zugriff zwischen Mitgliedsressourcen desselben Perimeters gilt dann als vertrauenswürdig – ohne explizite IP-Regeln oder Private Endpoints.
Ich hatte mich in diesem Zusammenhang anfangs gefragt, ob das NSP-Konzept Private Endpoints überflüssig macht. Die kurze Antwort: Nein. NSP und Private Endpoints lösen unterschiedliche Probleme. Private Endpoints binden einen Dienst an ein bestimmtes VNET. NSP hingegen definiert einen dienstübergreifenden Vertrauensraum auf Identitäts- und Ressourcenebene – auch über VNET-Grenzen hinweg.
Die neue Option „Network security perimeter“ in den Netzwerkeinstellungen eines Storage Accounts – hier sieht man den verknüpften Perimeter und den gewählten Zugriffsmodus.
Wie richten Sie einen Network Security Perimeter für einen Storage Account ein?
Die Einrichtung erfolgt in zwei Schritten: zuerst den Perimeter selbst anlegen, dann die Ressource verknüpfen.
Schritt 1 – Perimeter anlegen: Im Azure Portal suchen Sie nach „Network Security Perimeter“ oder navigieren über All Services → Networking → Network Security Perimeters. Dort legen Sie eine neue Ressource an – Name, Subscription und Resource Group nach Bedarf. Alternativ funktioniert das per Azure CLI:
az network perimeter create \
--name mein-nsp \
--resource-group meine-rg \
--location germanywestcentralSchritt 2 – Storage Account verknüpfen: Öffnen Sie den Storage Account, navigieren Sie zu Security + networking → Networking, und wählen Sie den Reiter Network security perimeter. Dort können Sie den zuvor erstellten Perimeter verknüpfen. Der Zugriffsmodus lässt sich auf Learning oder Enforced setzen – dazu gleich mehr.
Schritt 3 – Zugriffsregeln im Profil definieren: Im Perimeter-Profil legen Sie fest, welche eingehenden und ausgehenden Verbindungen erlaubt sind. Für eingehende Verbindungen können Sie Subscriptions, VNET-Subnets oder IP-Bereiche freigeben. Für ausgehende Verbindungen definieren Sie FQDNs (Fully Qualified Domain Names) oder IP-Präfixe.
Ein Perimeter-Profil mit einer eingehenden Zugriffsregel auf Basis einer Azure-Subscription – damit dürfen alle Ressourcen dieser Subscription auf den verknüpften Storage Account zugreifen.
Zugriffsmodi, Vergleich und Abgrenzung zu klassischen Methoden
Ein wichtiges Detail ist der Zugriffsmodus, den Sie beim Verknüpfen wählen. Er bestimmt, wie strikt der Perimeter durchgesetzt wird:
| Modus | Verhalten | Geeignet für |
|---|---|---|
| Learning | Alle Verbindungen werden protokolliert, aber nicht blockiert – unabhängig von Perimeter-Regeln | Initiale Analyse, Bestandsumgebungen, Migrationsphase |
| Enforced | Nur Verbindungen, die durch Perimeter-Regeln oder Mitgliedschaft erlaubt sind, werden zugelassen | Produktivumgebungen, Compliance-Anforderungen |
Zum besseren Verständnis noch eine Gegenüberstellung aller vier Firewall-Optionen des Storage Accounts:
| Firewall-Option | Zugriffssteuerung | Granularität | Typischer Einsatz |
|---|---|---|---|
| Enabled from all networks | Öffentlich erreichbar | Keine | Entwicklung, Tests |
| Disabled (Public access blocked) | Kein öffentlicher Zugriff | Nur Private Endpoints | Hochsicherheitsumgebungen |
| Selected VNETs and IPs | IP-/VNET-basiert | Mittel | Klassische Hub-Spoke-Netze |
| Network Security Perimeter | Ressourcen- und identitätsbasiert | Hoch | PaaS-zu-PaaS-Szenarien, Multi-Service-Architekturen |
Merksatz: Der Network Security Perimeter ist keine Firewall im klassischen Sinne – er ist ein ressourcenzentrierter Vertrauensraum. Wer ihn mit einem VNET vergleicht, liegt konzeptionell daneben.
In meinen Azure-Kursen erkläre ich diesen Unterschied gerne am Whiteboard: Ein VNET ist ein Netzwerkkonstrukt. Ein NSP ist ein Richtlinienkonstrukt. Beides kann parallel existieren – und sollte es in komplexen Architekturen auch.
Was nutzt der Network Security Perimeter konkret – und wann lohnt er sich?
Der praktische Nutzen zeigt sich besonders in PaaS-lastigen Architekturen, wo mehrere Azure-Dienste miteinander kommunizieren müssen. Typisches Beispiel: Ein Azure Synapse Workspace greift auf einen Storage Account zu, gleichzeitig liest ein Azure Machine Learning Workspace dieselben Daten. Bisher mussten Sie für jeden dieser Dienste einzelne IP-Ausnahmen oder Managed Identity-Regeln pflegen – fehleranfällig und schlecht skalierbar.
Mit einem NSP ordnen Sie alle drei Ressourcen demselben Perimeter zu, definieren einmalig die Zugriffsregeln im Profil, und die interne Kommunikation läuft ohne weiteren Konfigurationsaufwand. Neue Dienste, die dem Perimeter beitreten, erben die Regeln automatisch.
Praxistipp: Starten Sie immer im Learning-Modus. Aktivieren Sie parallel die Diagnoseprotokollierung des NSP (via Diagnostic Settings auf der Perimeter-Ressource), und werten Sie die Logs in Log Analytics aus, bevor Sie auf Enforced wechseln. So vermeiden Sie ungewollte Verbindungsabbrüche in der Produktivumgebung.
Folgendes Problem aus der Praxis: Ein Kunde hatte einen Storage Account mit aktivierter Firewall und wunderte sich, dass sein Azure Data Factory-Pipeline-Lauf mit einem 403-Fehler scheiterte, obwohl die Managed Identity korrekt konfiguriert war. Die Ursache: Die Firewall ließ nur bestimmte VNET-Subnets zu – und die Integration Runtime lief in einem anderen Subnet. Mit einem NSP wäre das kein Thema gewesen, weil beide Ressourcen dem gleichen Perimeter hätten angehören können, unabhängig vom Netzwerklayout.
Praxisempfehlung für KMU und mittelständische Azure-Umgebungen
Noch mal in Kürze – kurz, knapp und strukturiert, zum Abharken:
- NSP eignet sich besonders dann, wenn Sie mehrere PaaS-Dienste betreiben, die untereinander kommunizieren sollen, ohne Public-IP-Freigaben zu benötigen.
- Für reine IaaS-Umgebungen mit VMs bleiben klassische NSGs (Network Security Groups) und VNET-Firewall-Regeln die richtige Wahl.
- Beginnen Sie mit einem einzigen Perimeter pro Umgebungsstufe (z. B. „prod-nsp“, „dev-nsp“) – das hält die Verwaltung überschaubar.
- NSP ist aktuell noch als Preview-Feature eingestuft – prüfen Sie vor dem Produktiveinsatz die SLA-Bedingungen und regionale Verfügbarkeit.
Eine typische KMU-taugliche Ausgangsstruktur könnte so aussehen: Ein NSP für die Produktivumgebung, dem der primäre Storage Account, der Key Vault und ein Azure Machine Learning Workspace angehören. Zugriffsregeln im Profil erlauben eingehende Verbindungen aus der eigenen Subscription. Externer Zugriff (z. B. on-premises) läuft weiterhin über Private Endpoints. So kombinieren Sie beide Ansätze sinnvoll – und behalten die Kontrolle, ohne die Komplexität unnötig zu erhöhen.