Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen

Eine Network Security Group (NSG) fungiert als virtuelle Firewall für Azure-Ressourcen. Sie enthält eine Liste von Sicherheitsregeln, die eingehenden und ausgehenden Netzwerkverkehr anhand von Quell-IP, Ziel-IP, Portnummer und Protokoll zulassen oder verweigern. NSGs können Subnetzen zugeordnet werden (wodurch alle Ressourcen im Subnetz betroffen sind) oder einzelnen Netzwerkschnittstellen (wodurch nur eine VM betroffen ist). Wenn sowohl eine NSG auf Subnetzebene als auch eine NSG auf NIC-Ebene vorhanden ist, wertet Azure beide aus – bei eingehendem Datenverkehr wird zuerst die NSG des Subnetzes angewendet, bei ausgehendem Datenverkehr zuerst die NIC-NSG.

Jede NSG-Regel verfügt über die folgenden Eigenschaften: Priorität – eine Zahl zwischen 100 und 4096; niedrigere Zahlen werden zuerst ausgewertet. Quelle/Ziel – eine IP-Adresse, ein CIDR-Bereich, ein Diensttag oder eine Application Security Group. Quell-/Zielport – bestimmte Portnummern oder Bereiche (z. B. 80, 443, 3389 oder 1024-65535). Protokoll – TCP, UDP, ICMP oder Any. Aktion – Allow oder Deny. Regeln werden in der Reihenfolge ihrer Priorität ausgewertet; die erste passende Regel ist maßgeblich. Wenn keine Regel zutrifft, gelten die Standardregeln: gesamter eingehender Datenverkehr wird verweigert und gesamter ausgehender Datenverkehr wird zugelassen.

Jede NSG enthält drei Standardregeln für eingehenden Datenverkehr und drei Standardregeln für ausgehenden Datenverkehr mit Prioritäten von 65000 bis 65500, die nicht gelöscht werden können. Standardregeln für eingehenden Datenverkehr: AllowVnetInBound (Datenverkehr aus dem VNet zulassen), AllowAzureLoadBalancerInBound (Integritätstests von Azure zulassen), DenyAllInBound (alles andere verweigern). Standardregeln für ausgehenden Datenverkehr: AllowVnetOutBound, AllowInternetOutBound, DenyAllOutBound. Sie können die Standardwerte überschreiben, indem Sie Regeln mit niedrigeren Prioritätszahlen (100-64999) hinzufügen, die vor den Standardregeln wirksam werden.

Diensttags sind vordefinierte Gruppen von IP-Adressbereichen für Azure-Dienste. Dadurch können Sie kompakte NSG-Regeln erstellen, ohne lange Listen von IP-Adressen anzugeben, die sich im Laufe der Zeit ändern. Zu den häufig verwendeten Diensttags gehören: Internet – alle IP-Adressen außerhalb des VNets. VirtualNetwork – alle IP-Adressen innerhalb des VNets. AzureLoadBalancer – die IP-Adresse des Infrastruktur-Load-Balancers von Azure. Storage – IP-Adressen des Azure Storage-Dienstes für die ausgewählte Region. AzureActiveDirectory – Endpunkte von Entra ID. Microsoft verwaltet diese Tags automatisch, sodass Ihre NSG-Regeln auch bei Änderungen der Dienst-IP-Adressen korrekt bleiben.

Wenn Sie eine NSG einem Subnetz zuordnen, gelten ihre Regeln für alle Ressourcen in diesem Subnetz. Dies ist die effizienteste Methode, um Netzwerkisolationsrichtlinien im großen Maßstab durchzusetzen. Wenn Sie beispielsweise eine NSG namens „DenyRDP“ einem Subnetz der Datenebene zuordnen, verhindert dies, dass von außerhalb auf eine VM in diesem Subnetz über RDP (Port 3389) zugegriffen wird – unabhängig davon, was NSGs auf NIC-Ebene zulassen. Diese NSG auf Subnetzebene dient als erste Verteidigungslinie, bevor der Datenverkehr einzelne VMs überhaupt erreicht, und reduziert die Angriffsfläche an der Netzwerkgrenze.

Application Security Groups (ASGs) ermöglichen es Ihnen, Netzwerkschnittstellen von Azure-VMs nach Anwendungsrolle statt nach IP-Adresse zu gruppieren. Erstellen Sie beispielsweise ASGs mit den Namen webServers, appServers und dbServers und weisen Sie dann die NIC jeder VM der entsprechenden ASG zu. In Ihren NSG-Regeln können Sie anschließend festlegen: „Datenverkehr von webServers zu appServers auf Port 8080 zulassen“ – ohne IP-Adressen anzugeben. Wenn Sie VMs hinzufügen oder entfernen, aktualisieren Sie einfach deren ASG-Zugehörigkeit. Alle NSG-Regeln werden dann automatisch korrekt angewendet, ohne dass Regeln geändert werden müssen.

Sobald ASGs definiert und VMs zugewiesen sind, erstellen Sie NSG-Regeln, die ASGs als Quelle oder Ziel referenzieren. Dieser Ansatz ist wesentlich leichter zu verwalten als IP-basierte Regeln, weil: Keine IP-Verwaltung – Sie müssen die IP-Adressen der VMs nicht kennen; die ASG-Zugehörigkeit übernimmt die Zuordnung. Dynamische Skalierung – neue VMs übernehmen automatisch die richtigen Regeln, sobald sie der passenden ASG hinzugefügt werden. Semantische Klarheit – Regeln sind verständlich formuliert („webServers → appServers auf 8080“) statt als schwer verständliche IP-Bereiche. ASGs sind besonders in dynamischen Umgebungen wertvoll, in denen VMs häufig hinzugefügt oder ersetzt werden.

NSG-Flowprotokolle zeichnen Informationen zu sämtlichem IP-Datenverkehr auf, der eine NSG durchläuft, einschließlich Quell- und Ziel-IP, Port, Protokoll, der Information, ob der Datenverkehr zugelassen oder verweigert wurde, sowie der übertragenen Byteanzahl. Flowprotokolle werden im JSON-Format in einem Azure Storage-Konto gespeichert und können im Tool Traffic Analytics von Azure Network Watcher visualisiert werden. Flowprotokolle sind für die Problembehandlung bei Verbindungsproblemen („Warum wird dieser Datenverkehr blockiert?“), für Sicherheitsuntersuchungen und für Compliance-Berichte mit erforderlichen Nachweisen zu Datenverkehrsmustern äußerst wertvoll.

Drei häufige NSG-Fehler, die Verbindungsprobleme verursachen: Die Auswertungsreihenfolge vergessen – wenn eine Deny-Regel mit Priorität 100 vorhanden ist und Ihre Allow-Regel die Priorität 200 hat, wird der Datenverkehr verweigert, da niedrigere Prioritätszahlen zuerst berücksichtigt werden. Integritätstests von Azure blockieren – Integritätstests des Load Balancers stammen von der IP-Adresse 168.63.129.16; wird diese Quelle blockiert, erscheinen die Backends des Load Balancers als fehlerhaft und empfangen keinen Datenverkehr mehr. Überlappende NSGs auf Subnetz- und NIC-Ebene – der Datenverkehr muss beide NSG-Auswertungen passieren; eine Regel, die Datenverkehr in der NSG des Subnetzes zulässt, wird weiterhin blockiert, wenn die NIC-NSG ihn verweigert.

NSGs und Azure Firewall ergänzen sich, unterscheiden sich jedoch: NSGs – dezentral, Subnetzen und NICs zugeordnet, Filterung auf Layer 3/4 (IP und Port), standardmäßig keine Protokollierung des Datenverkehrs, in jedem VNet kostenlos enthalten. Azure Firewall – zentralisiert, verwalteter Dienst in einem Hub-VNet, Filterung auf Layer 3/4 UND Layer 7 (FQDN, URL, IDPS), vollständige Protokollierung über Azure Monitor und Kosten von etwa 1.000 USD oder mehr pro Monat. Verwenden Sie NSGs für grundlegende Perimetersicherheit und die Isolierung von Anwendungsebenen. Verwenden Sie Azure Firewall, wenn Sie eine zentrale, prüfbare Durchsetzung der Regeln für den ausgehenden Internetzugriff mit FQDN-Filterung, Bedrohungsinformationen oder TLS-Inspektion benötigen.

Wenn eine NSG sowohl einem Subnetz als auch einer NIC zugeordnet ist, kann es schwierig sein, den Überblick über die tatsächlich angewendeten Regeln zu behalten. Azure stellt im Portal für die NIC jeder VM die Ansicht Effektive Sicherheitsregeln bereit. Sie zeigt das kombinierte Ergebnis aller NSG-Regeln auf Subnetz- und NIC-Ebene. Dies ist die maßgebliche Liste dessen, was für diese VM tatsächlich zugelassen oder verweigert wird. Das Tool IP flow verify von Azure Network Watcher geht noch weiter: Sie geben eine Quell- und Ziel-IP-Adresse sowie einen Port an, und das Tool teilt Ihnen sofort mit, ob der Datenverkehr zugelassen oder verweigert würde und welche konkrete Regel dafür verantwortlich ist.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion zu Microsoft Azure Fundamentals (AZ-900).

In dieser Lektion haben Sie gelernt: NSGs enthalten Allow-/Deny-Regeln, die in der Reihenfolge ihrer Priorität ausgewertet werden und den Datenverkehr für Subnetze oder einzelne Netzwerkschnittstellen filtern, Diensttags vereinfachen Regeln, indem sie dynamische Gruppen von IP-Adressbereichen für Azure-Dienste darstellen und Application Security Groups ermöglichen die rollenbasierte Gruppierung von VMs für wartungsfreie NSG-Regeln, die mit Ihrer Umgebung skalieren. Als Nächstes beschäftigen wir uns mit VNet-Peering und Service Endpoints, um Ressourcen über VNets hinweg und mit Azure-Diensten zu verbinden.