Azure Security Basics: NSGs, Key Vault und Security Center für KMU

Azure im Mittelstand: Mehr als nur Microsoft 365

Viele mittelständische Unternehmen nutzen Azure, ohne sich dessen bewusst zu sein: Microsoft 365 läuft auf Azure-Infrastruktur, Entra ID ist ein Azure-Dienst, und selbst OneDrive und SharePoint basieren auf Azure Storage. Aber zunehmend betreiben auch kleinere Unternehmen eigene Workloads in Azure: eine virtuelle Maschine für eine Branchenanwendung, eine Azure SQL-Datenbank für das ERP-System, einen App Service für die Unternehmenswebsite, Azure Backup für die Datensicherung.

Das Problem: Die Sicherheitskonfiguration dieser Azure-Ressourcen wird oft vernachlässigt. Der Fokus liegt auf der Funktionalität ("Es läuft!"), während die Sicherheitseinstellungen auf den Standardwerten bleiben. Und die Standardwerte in Azure sind, anders als bei Microsoft 365, nicht unsicher per Default, aber auch nicht optimal. Eine virtuelle Maschine ohne NSG ist aus dem Internet erreichbar, ein Key Vault ohne Access Policy gibt niemandem Zugriff (gut), aber ohne Key Vault stehen die Passwörter im Code oder in einer Konfigurationsdatei (schlecht).

Dieser Artikel konzentriert sich auf drei Azure-Dienste, die jedes Unternehmen mit Azure-Workloads kennen und konfigurieren sollte: Network Security Groups, Key Vault und Microsoft Defender for Cloud. Das sind keine Enterprise-Features für Großkonzerne, sondern Grundlagen, die auch bei einer Handvoll Azure-Ressourcen relevant sind.

Network Security Groups: Die Azure-Firewall

Was sind NSGs?

Network Security Groups (NSGs) sind die grundlegende Netzwerk-Firewall in Azure. Sie filtern den Netzwerkverkehr zu und von Azure-Ressourcen anhand von Regeln, die Quell-IP, Ziel-IP, Port und Protokoll spezifizieren. NSGs können auf zwei Ebenen angewendet werden:

• Subnet-Ebene: Alle Ressourcen im Subnet sind von der NSG betroffen. Das ist die empfohlene Ebene für grundlegende Netzwerksegmentierung.
• NIC-Ebene (Network Interface): Die NSG wird direkt an die Netzwerkschnittstelle einer virtuellen Maschine gebunden. Das ermöglicht granulare Kontrolle pro VM, aber erhöht die Verwaltungskomplexität.

Wenn beide Ebenen konfiguriert sind, werden die Regeln beider NSGs ausgewertet. Eingehender Verkehr muss beide NSGs passieren (Subnet-NSG zuerst, dann NIC-NSG), ausgehender Verkehr umgekehrt.

Standardregeln verstehen

Jede NSG enthält drei Standardregeln, die nicht gelöscht werden können:

Eingehend:

1. AllowVNetInBound (Priorität 65000): Erlaubt allen Verkehr innerhalb des Virtual Network
2. AllowAzureLoadBalancerInBound (Priorität 65001): Erlaubt Verkehr vom Azure Load Balancer
3. DenyAllInBound (Priorität 65500): Blockiert allen anderen eingehenden Verkehr

Ausgehend:

1. AllowVNetOutBound (Priorität 65000): Erlaubt allen Verkehr innerhalb des Virtual Network
2. AllowInternetOutBound (Priorität 65001): Erlaubt allen ausgehenden Internetverkehr
3. DenyAllOutBound (Priorität 65500): Blockiert allen anderen ausgehenden Verkehr

Das bedeutet: Ohne zusätzliche Regeln kann jede VM mit jeder anderen VM im selben VNet kommunizieren, ins Internet kommunizieren, aber nicht aus dem Internet erreicht werden (es sei denn, eine Public IP ist zugewiesen).

NSG-Design für KMU

Für ein typisches KMU-Szenario mit wenigen Azure-Ressourcen empfiehlt sich folgendes NSG-Design:

Subnet-Struktur:

• Frontend-Subnet: Für Web-Server und App Services, die aus dem Internet erreichbar sein müssen
• Backend-Subnet: Für Datenbanken und interne Anwendungen, die nicht aus dem Internet erreichbar sein sollen
• Management-Subnet: Für Jump-Hosts und Management-VMs

NSG-Regeln für das Frontend-Subnet:

• Eingehend: HTTPS (443) von Any erlauben
• Eingehend: HTTP (80) von Any erlauben (optional, besser Redirect auf HTTPS)
• Eingehend: RDP (3389) und SSH (22) blockieren (Management nur über Jump-Host oder Bastion)
• Ausgehend: SQL (1433) zum Backend-Subnet erlauben
• Ausgehend: HTTPS (443) zu Any erlauben (für API-Aufrufe, Updates)

NSG-Regeln für das Backend-Subnet:

• Eingehend: SQL (1433) nur vom Frontend-Subnet erlauben
• Eingehend: Alles andere blockieren (Default DenyAllInBound)
• Ausgehend: HTTPS (443) zu Any erlauben (für Updates und Monitoring)

NSG-Regeln für das Management-Subnet:

• Eingehend: RDP (3389) oder SSH (22) nur von der Büro-IP-Adresse erlauben
• Eingehend: Alles andere blockieren
• Ausgehend: RDP/SSH zum Frontend- und Backend-Subnet erlauben

Häufige Fehler bei NSGs

RDP oder SSH aus dem Internet erlauben: Niemals RDP (3389) oder SSH (22) für die Quell-IP "Any" öffnen. Eine grundlegende Netzwerksegmentierung ist auch in Azure unverzichtbar. Innerhalb von Minuten werden automatisierte Angriffe auf den offenen Port starten. Verwende Azure Bastion (ein verwalteter Jump-Host-Dienst) oder beschränke den Zugriff auf die Büro-IP.

Zu breite Regeln: Eine Regel, die "Any" zu "Any" auf "Any Port" erlaubt, macht die NSG wirkungslos. Jede Regel sollte so spezifisch wie möglich sein: konkreter Port, konkrete Quell-IP oder -Subnet, konkretes Ziel.

NSGs nicht auswerten: NSG Flow Logs (kostenlos im Basisumfang) zeichnen auf, welcher Verkehr von der NSG erlaubt oder blockiert wurde. Ohne diese Logs weißt du nicht, ob deine NSGs korrekt konfiguriert sind oder ob legitimer Verkehr blockiert wird.

Nur Subnet-NSGs oder nur NIC-NSGs: Verwende Subnet-NSGs als Grundlage und NIC-NSGs nur für Ausnahmen. Wenn du beides inkonsistent konfigurierst, wird die Fehlersuche bei Verbindungsproblemen zum Albtraum.

Azure Key Vault: Geheimnisse sicher verwalten

Das Problem mit Credentials im Code

In jeder Anwendung gibt es Geheimnisse: Datenbankpasswörter, API-Schlüssel, Zertifikate, Connection Strings. Ein durchdachtes Secrets Management ist die Grundlage für sichere Anwendungen. Die Frage ist, wo diese Geheimnisse gespeichert werden. In der Praxis gibt es vier häufige Orte, von denen drei falsch sind:

1. Im Quellcode (hart codiert): Der schlimmste Fall. Das Geheimnis landet im Git-Repository und ist für alle Entwickler sichtbar, möglicherweise sogar öffentlich (wenn das Repo öffentlich ist).
2. In Konfigurationsdateien auf dem Server: Besser als im Code, aber immer noch riskant. Jeder mit Zugriff auf den Server kann die Datei lesen. Backups enthalten die Geheimnisse im Klartext.
3. In Umgebungsvariablen: Noch besser, aber nicht ideal. Umgebungsvariablen können durch Fehlkonfigurationen oder Debugging-Ausgaben versehentlich exponiert werden.
4. In Azure Key Vault (richtig): Die Geheimnisse werden zentral, verschlüsselt und zugriffskontrolliert gespeichert. Anwendungen authentifizieren sich per Managed Identity und erhalten die Geheimnisse zur Laufzeit.

Key Vault einrichten

Schritt 1: Key Vault erstellen Erstelle einen Key Vault pro Umgebung (Development, Staging, Production). Der Name muss global eindeutig sein.

• Region: Dieselbe Region wie die Anwendung (minimiert Latenz)
• Pricing Tier: Standard (reicht für die meisten Szenarien, Premium bietet HSM-gestützte Schlüssel)
• Soft Delete: Aktiviert (verhindert versehentliches unwiderrufliches Löschen, 90 Tage Aufbewahrung)
• Purge Protection: Aktiviert (verhindert auch erzwungenes Löschen während der Soft-Delete-Aufbewahrung)

Schritt 2: Access Policy konfigurieren Key Vault unterstützt zwei Zugriffskontrollmodelle:

• Vault Access Policy (klassisch): Zugriffsberechtigungen werden direkt am Key Vault konfiguriert
• Azure RBAC (empfohlen): Zugriffsberechtigungen werden über Azure Role-Based Access Control gesteuert

Empfehlung: Verwende Azure RBAC. Die Rollen "Key Vault Secrets User" (Lesen) und "Key Vault Administrator" (Verwalten) decken die meisten Szenarien ab.

Schritt 3: Geheimnisse einpflegen Speichere Datenbankpasswörter, API-Schlüssel, Connection Strings und andere Geheimnisse als Secrets im Key Vault. Jedes Secret hat einen Namen, einen Wert und optional ein Ablaufdatum und Tags.

Schritt 4: Managed Identity für Anwendungen Erstelle eine Managed Identity für jede Azure-Ressource, die auf den Key Vault zugreifen muss (VM, App Service, Azure Function). Die Managed Identity authentifiziert sich automatisch bei Azure AD, ohne dass ein Passwort oder Zertifikat konfiguriert werden muss.

Key Vault für Zertifikate

Neben Secrets kann Key Vault auch TLS/SSL-Zertifikate verwalten:

• Zertifikate importieren: Bestehende Zertifikate (PFX-Format) in den Key Vault hochladen
• Zertifikate erstellen: Key Vault kann Zertifikate direkt von integrierten CAs (DigiCert, GlobalSign) anfordern und automatisch erneuern
• Zertifikate verteilen: App Services und Application Gateways können Zertifikate direkt aus dem Key Vault beziehen

Die automatische Zertifikatserneuerung ist ein oft unterschätzter Vorteil: Kein manuelles Erneuern, kein vergessenes Ablaufdatum, kein Ausfall wegen eines abgelaufenen Zertifikats.

Key Vault Monitoring

Aktiviere die Diagnostics Settings des Key Vault und leite die Logs an einen Log Analytics Workspace oder ein Storage Account:

• AuditEvent: Jeder Zugriff auf den Key Vault wird protokolliert (wer hat wann welches Secret gelesen?)
• AllMetrics: Performancemetriken (Latenz, Fehlerrate)

Richte Alert Rules ein für:

• Zugriff auf den Key Vault von unbekannten IP-Adressen
• Fehlgeschlagene Zugriffsversuche (401/403-Fehler)
• Ablauf von Secrets oder Zertifikaten (30 Tage vor Ablauf warnen)

Microsoft Defender for Cloud: Monitoring und Compliance

Was ist Defender for Cloud?

Microsoft Defender for Cloud (ehemals Azure Security Center und Azure Defender) ist die zentrale Sicherheitsmanagement-Plattform für Azure. Es besteht aus zwei Komponenten:

Cloud Security Posture Management (CSPM) - kostenlos:

• Bewertung des Sicherheitszustands aller Azure-Ressourcen
• Secure Score für Azure (ähnlich dem Microsoft Secure Score für M365)
• Sicherheitsempfehlungen basierend auf dem Azure Security Benchmark und anderen Standards
• Regulatory Compliance Dashboard (ISO 27001, NIST, CIS Benchmarks)

Cloud Workload Protection Platform (CWPP) - kostenpflichtig:

• Defender for Servers: EDR-Schutz für VMs (basierend auf Defender for Endpoint)
• Defender for SQL: Bedrohungserkennung für Azure SQL und SQL Server
• Defender for Storage: Malware-Scanning für Azure Storage
• Defender for Key Vault: Erkennung verdächtiger Key-Vault-Zugriffe
• Defender for App Service: Bedrohungserkennung für Web-Apps
• Weitere Pläne für Container, DNS, Resource Manager etc.

CSPM: Der kostenlose Einstieg

Für den Einstieg reicht der kostenlose CSPM-Umfang. Aktiviere Defender for Cloud im Azure Portal und prüfe den Secure Score und die Empfehlungen:

Secure Score: Der Secure Score bewertet den Sicherheitszustand auf einer Skala von 0 bis 100 Prozent. Jede Empfehlung, die du umsetzt, erhöht den Score. Der Score aggregiert den Status über alle Azure-Subscriptions und Ressourcen hinweg.

Empfehlungen: Defender for Cloud gibt konkrete Handlungsempfehlungen, gruppiert nach Schweregrad (High, Medium, Low):

• "Enable MFA for accounts with owner permissions on subscriptions"
• "Storage accounts should restrict network access using virtual network rules"
• "Subnets should be associated with a Network Security Group"
• "SQL databases should have vulnerability findings resolved"

Jede Empfehlung enthält eine Beschreibung des Risikos, eine Anleitung zur Behebung und die betroffenen Ressourcen. Du kannst Empfehlungen als "Risk accepted" markieren (mit Begründung) oder als "Exempt" (wenn die Empfehlung für deine Umgebung nicht relevant ist).

Regulatory Compliance: Das Compliance Dashboard zeigt, wie gut deine Azure-Umgebung die Anforderungen verschiedener Standards erfüllt. Für das ISMS ist besonders das ISO 27001-Assessment relevant: Es prüft automatisch, welche ISO 27001-Controls durch deine Azure-Konfiguration abgedeckt sind und wo Lücken bestehen.

CWPP: Bezahlte Pläne gezielt aktivieren

Die bezahlten Defender-Pläne werden pro Ressourcentyp abgerechnet. Du musst nicht alle Pläne aktivieren, sondern nur die, die für deine Workloads relevant sind.

Empfohlene Pläne für KMU:

Defender for Servers P1 vs. P2:

• P1 bietet EDR-Schutz (basierend auf Defender for Endpoint), Schwachstellenscanning und Netzwerkhärtungsempfehlungen
• P2 bietet zusätzlich Just-in-Time VM Access, Adaptive Application Controls und dateibasierte Integritätsüberwachung
• Für die meisten KMU reicht P1

Kostenkontrolle

Azure-Sicherheitsdienste können unerwartete Kosten verursachen, wenn du nicht aufpasst. Hier einige Maßnahmen zur Kostenkontrolle:

• Nur benötigte Pläne aktivieren: Aktiviere Defender-Pläne nur für Ressourcentypen, die du tatsächlich in Azure betreibst
• Cost Analysis nutzen: Prüfe regelmäßig im Cost Management, welche Kosten die Security-Dienste verursachen
• Budget Alerts: Setze Budgetgrenzen und lass dich benachrichtigen, wenn die Kosten einen Schwellenwert überschreiten
• Log Analytics Workspace: Die Datenaufbewahrung im Log Analytics Workspace verursacht Kosten. Setze die Aufbewahrung auf 90 Tage (Standard) und verlängere nur bei Bedarf

Weitere Azure-Sicherheitsmaßnahmen

Neben den drei Hauptdiensten gibt es weitere Maßnahmen, die du bei Azure-Workloads berücksichtigen solltest:

Azure Bastion statt offene RDP/SSH-Ports

Azure Bastion ist ein verwalteter Jump-Host-Dienst, der RDP- und SSH-Zugriff auf VMs über den Browser ermöglicht, ohne dass die VMs eine öffentliche IP-Adresse benötigen. Der Zugriff läuft über TLS und wird durch Entra ID authentifiziert, was MFA und Conditional Access ermöglicht.

Kosten: Ab ca. 130 EUR/Monat (Basic SKU). Für Unternehmen mit nur wenigen VMs kann ein dedizierter Jump-Host günstiger sein, aber Azure Bastion ist einfacher zu verwalten und sicherer.

Azure Backup

Azure Backup bietet automatisierte Datensicherung für VMs, SQL-Datenbanken, Azure Files und andere Ressourcen. Konfiguriere Backup-Policies mit:

• Tägliche Sicherung, 30 Tage Aufbewahrung
• Wöchentliche Sicherung, 12 Wochen Aufbewahrung
• Monatliche Sicherung, 12 Monate Aufbewahrung
• Soft Delete für Backups aktivieren (verhindert versehentliches oder böswilliges Löschen von Backups). In ISMS Lite lassen sich alle Azure-Sicherheitsmaßnahmen als TOMs dokumentieren und dem Secure Score als KPI zuordnen

Resource Locks

Resource Locks verhindern das versehentliche Löschen oder Ändern von Azure-Ressourcen:

• CanNotDelete: Die Ressource kann nicht gelöscht werden, aber geändert
• ReadOnly: Die Ressource kann weder gelöscht noch geändert werden

Setze CanNotDelete-Locks auf kritische Ressourcen: Produktions-VMs, Datenbanken, Key Vaults, Backup Vaults.

Azure Policy

Azure Policy erzwingt Konfigurationsstandards auf Subscription- oder Resource-Group-Ebene:

• "Allowed locations": Ressourcen dürfen nur in bestimmten Regionen erstellt werden (z.B. West Europe, North Europe)
• "Require tag on resources": Jede Ressource muss bestimmte Tags haben (z.B. Environment, Owner, CostCenter)
• "Audit VMs without managed disks": VMs mit unmanaged disks werden als non-compliant markiert

Azure Policy ist kostenlos und hilft, Governance-Standards durchzusetzen, bevor Fehlkonfigurationen entstehen.

Azure-Sicherheit im ISMS

Die beschriebenen Azure-Sicherheitsmaßnahmen decken mehrere ISO 27001-Controls ab:

A.8.20 (Netzwerksicherheit):

• NSGs als Netzwerk-Firewall
• Subnet-Segmentierung
• NSG Flow Logs für Monitoring

A.8.21 (Sicherheit von Netzwerkdiensten):

• Azure Bastion für sicheren Management-Zugriff
• Kein RDP/SSH aus dem Internet

A.8.24 (Nutzung von Kryptographie):

• Key Vault für Geheimnismanagement
• Zertifikatsverwaltung und automatische Erneuerung
• Managed Identities statt Credentials im Code

A.5.33 (Schutz von Aufzeichnungen):

• Azure Backup für Datensicherung
• Soft Delete für Backups
• Aufbewahrungsrichtlinien

A.8.8 (Management von technischen Schwachstellen):

• Defender for Cloud Empfehlungen
• Schwachstellenscanning für VMs und SQL
• Secure Score als KPI

A.8.15 (Logging) und A.8.16 (Überwachung):

• Defender for Cloud Alerts
• Key Vault Audit Logs
• NSG Flow Logs
• Activity Log für alle Azure-Management-Operationen

Dokumentation im ISMS

Für das ISMS empfiehlt sich ein dediziertes Dokument "Cloud-Sicherheitsrichtlinie" oder ein Abschnitt in der übergreifenden IT-Sicherheitsrichtlinie, der folgende Punkte abdeckt:

• Verantwortlichkeiten: Wer verwaltet die Azure-Subscription? Wer konfiguriert NSGs? Wer verwaltet Key Vault?
• Netzwerkarchitektur: Dokumentation der VNets, Subnets und NSG-Regeln
• Geheimnismanagement: Prozess für die Erstellung, Rotation und Löschung von Geheimnissen im Key Vault
• Monitoring: Wer prüft die Defender-for-Cloud-Empfehlungen? Wie oft? Was passiert bei kritischen Findings?
• Kostenkontrolle: Budget und Schwellenwerte für Azure-Sicherheitsdienste
• Change Management: Prozess für Änderungen an NSGs, Key Vault Access Policies und Defender-Konfigurationen

Weiterführende Artikel

• Microsoft 365 absichern: Die 15 wichtigsten Sicherheitseinstellungen
• Cloud-Sicherheit für KMU: Verantwortlichkeiten, Risiken und Maßnahmen
• Netzwerksegmentierung im Mittelstand: Konzept und Umsetzung
• Backup-Strategie und Restore-Tests: Die 3-2-1-Regel in der Praxis
• Microsoft Secure Score: Was er misst und wie du ihn verbesserst