Security Admin Rules im AVNM setzen Netzwerksperren vor jeder NSG durch

In vielen Azure-Umgebungen, die ich betreue, ist die Netzwerksicherheit das Stiefkind der IT-Governance. Ressourcen entstehen im Self-Service, NSGs werden schnell kopiert, Ausnahme reiht sich an Ausnahme, und irgendwann bringt der erste Penetrationstest eine böse Überraschung. Mit den Security Admin Rules bietet der Azure Virtual Network Manager (AVNM) seit einiger Zeit ein wirksames Mittel, um zentrale Netzwerkgrenzen zu ziehen, über die niemand verhandeln kann. Wer einmal erlebt hat, wie zuverlässig damit etwa die RDP- und SSH-Ports in sämtlichen Subnetzen geschlossen bleiben, will darauf nicht mehr verzichten.

Security Admin Rules stehen in der Regelkette vor jeder NSG

Entscheidend ist, an welcher Stelle im Datenfluss die Security Admin Rules sitzen. Azure wertet sie in jedem Subnetz vor den klassischen NSGs aus, und zwar so, dass weder lokale Regeln noch spätere Änderungen an einer NSG sie aushebeln können. Steht eine Regel im AVNM einmal auf „Deny“, bleibt der Verkehr komplett blockiert, egal was in der NSG eingetragen ist. Wer also beispielsweise eingehende RDP- oder SSH-Verbindungen aus dem Internet im ganzen Unternehmen unterbinden will, muss das nicht mehr Subnetz für Subnetz nachpflegen.

Im folgenden Diagramm ist zu sehen, welchen Weg eingehender Traffic durch die Regelkette nimmt, von den Security Admin Rules bis zur lokalen NSG:

flowchart TD
    Internet["Internet"] --> Guardrails["Security Admin Rules"]
    Guardrails --> NSG["Netzwerksicherheitsgruppe"]
    NSG --> Subnet["Subnetz"]

Abbildung: Security Admin Rules greifen vor den NSGs und verhindern, dass nachfolgende Regeln die Sperre aufweichen.

Ausführlichere Informationen und Beispiele bietet die Microsoft-Dokumentation zum AVNM, speziell zu diesem Thema außerdem der Artikel über die Arbeitsweise der Security Admin Rules.

Scope, Netzwerkgruppen und Azure Policy legen den Wirkungsbereich fest

Der Scope des AVNM ist in der Praxis immer eine Management Group oder eine Subscription. Darin definiert man Netzwerkgruppen, entweder statisch mit fest benannten VNets oder dynamisch, etwa über Azure Policy. Gerade in größeren Umgebungen, in denen ständig Netzwerke dazukommen oder umziehen, zahlt sich die dynamische Variante aus. Azure Policy ordnet neue VNets dann anhand von Tags, Namensmustern oder anderen Kriterien automatisch der passenden Gruppe zu. So sinkt der Pflegeaufwand, und kein neues Netzwerk bleibt aus Versehen ungeschützt.

So sieht eine typische Konfiguration aus der Praxis aus:

• Scope: Management Group „Production“
• Netzwerkgruppe „Alle-Prod-VNets“ (dynamisch per Policy: Tag Environment=Prod)
• Security Admin Rule: Deny inbound TCP 3389/22 aus 0.0.0.0/0

Praxis-Tipp: Für kritische Regeln empfehle ich dynamische, Policy-basierte Gruppen. Dann bleibt die Absicherung auch bei wachsendem Netz einheitlich.

Security Admin Rules werden Region für Region ausgerollt

Im Unterschied zum klassischen NSG-Management gelten Security Admin Rules jeweils pro Region. Sind sie erstellt und zugewiesen, tauchen sie nach wenigen Minuten in allen Subnetzen der betreffenden Netzwerkgruppe auf, ohne dass ein lokales Team etwas tun muss. Wichtig ist allerdings die Routine beim Deployment, denn jede Änderung muss pro Region und Gruppenmitglied ausgerollt werden. Daran muss man sich anfangs gewöhnen, dafür lässt sich in Multi-Region-Designs sehr fein steuern.

Zum Testen sollte man grundsätzlich ein eigenes Testnetzwerk mit einer separaten Gruppe verwenden. Produktiv wird eine Änderung erst, wenn sie ausdrücklich auf die jeweilige Gruppe und Region ausgerollt wird.

# Beispiel: Security Admin Rule Deployment per PowerShell (Az 11+ erforderlich, Rolle: Network Contributor)
New-AzNetworkManagerSecurityAdminRuleCollection -Name "Deny-RDP-SSH" -NetworkManagerName "MyAVNM" -ResourceGroupName "rg-avnm" -Region "westeurope" -Rule {
    SourceAddressPrefix = "0.0.0.0/0"
    DestinationPortRanges = @("3389", "22")
    DestinationAddressPrefix = "*"
    Protocol = "Tcp"
    Action = "Deny"
}

Das Skript legt für die gewählte Region und Gruppe eine Deny-Regel an, die RDP und SSH aus dem Internet sperrt.

Die Aktionen Allow, Deny und Always Allow wirken sehr unterschiedlich

In meinen Workshops bringt die Unterscheidung zwischen Allow, Deny und Always Allow regelmäßig Teilnehmer durcheinander. Ein Deny ist absolut, keine nachgeschaltete NSG kann diesen Traffic noch zulassen. Allow wirkt hingegen vor allem dann, wenn die folgenden NSGs den Traffic nicht ohnehin blockieren, die Regel öffnet also zusätzlich. Always Allow ist ein Sonderfall, denn eine solche Regel kann ein nachfolgendes Deny in einer NSG ausdrücklich überschreiben. Da sie damit die Guardrails umgeht, gehört sie nur mit Bedacht eingesetzt und sollte restriktiv und eng gefasst sein.

Im Alltag setze ich fast ausschließlich Deny ein, um typische Einfallstore wie RDP oder SQL-Ports global zu schließen. Allow hilft bei seltenen Ausnahmen, zum Beispiel für bestimmte Bastion-Subnetze oder Jump Hosts, die bewusst von den übergreifenden Regeln ausgenommen sind.

Erst ein echter Verbindungstest zeigt, ob die Regel greift

Ist eine neue Security Admin Rule ausgerollt, rate ich dringend dazu, ihr Verhalten nicht nur auf dem Papier, sondern in der Praxis zu überprüfen. Dazu genügt oft eine einfache Test-VM in der betroffenen Gruppe und anschließend ein Verbindungstest, etwa mit Test-NetConnection in PowerShell oder einem Portscan von außen. Auch Azure Monitor Network Insights macht schnell sichtbar, ob und wo Traffic hängen bleibt.

Für eine tiefere Analyse exportiert man die Flow Logs der Subnetze in einen Log Analytics Workspace. Dort lässt sich gezielt nachvollziehen, ob Verbindungen auf die gesperrten Ports tatsächlich blockiert wurden.

Kontrollfrage aus der Praxis: Sind neue VNets über die Policy-basierte Mitgliedschaft wirklich automatisch den richtigen Security Admin Rules zugeordnet worden? Das zeigt ein Blick ins AVNM-Portal, und zwar für jede Region einzeln.

Security Admin Rules liefern Leitplanken, die tatsächlich halten

Für mich sind die Security Admin Rules im Azure Virtual Network Manager inzwischen die wichtigste Antwort auf den alten Konflikt zwischen Autonomie und Kontrolle im Cloud-Netzwerk. Sie schaffen, was NSGs allein nie verlässlich geschafft haben, nämlich einheitliche Leitplanken für den Netzwerkverkehr, an denen niemand rütteln kann. Dynamische Gruppenzuordnung und Policy-Integration lassen zusammen mit dem regionalen Rollout genug Raum für Wachstum. Gleichzeitig kann man sich endlich darauf verlassen, dass niemand mehr versehentlich eine Lücke aufreißt. Wer den AVNM noch nicht produktiv einsetzt, sollte das bald nachholen, damit der nächste Penetrationstest keine Überraschung mehr bringt.