In meinen Azure-Kursen taucht diese Frage regelmäßig auf: „Soll ich Defender for Cloud einfach für alles aktivieren?“ Die kurze Antwort lautet: Nein – zumindest nicht pauschal. Microsoft Defender for Cloud (früher Azure Security Center mit Azure Defender) ist ein leistungsfähiges CSPM- (Cloud Security Posture Management) und CWPP-Tool (Cloud Workload Protection Platform), aber es kostet pro Ressourcentyp Geld. Wer ohne Konzept aktiviert, zahlt schnell für Schutz, den er weder braucht noch auswertet. Dieser Artikel hilft Ihnen, eine sinnvolle Scope-Strategie zu entwickeln.
Was Defender for Cloud eigentlich leistet – und wo der Unterschied liegt
Zunächst eine wichtige Unterscheidung: Defender for Cloud besteht aus zwei unabhängigen Schichten. Der kostenlose Basisplan aktiviert automatisch das Secure Score-Dashboard und liefert Empfehlungen auf Basis der Azure Security Benchmark – ohne zusätzliche Kosten. Erst der erweiterte Schutz, also die einzelnen Microsoft Defender-Pläne (Defender for Servers, Defender for Storage, Defender for SQL usw.), kostet extra und sollte gezielt aktiviert werden.
Viele Unternehmen, die ich in meinen Azure-Kursen begleite, haben den kostenlosen Secure Score gar nicht auf dem Radar – dabei ist er oft schon ausreichend, um grundlegende Fehlkonfigurationen zu erkennen: offene Management-Ports, fehlende MFA-Erzwingung (Multi-Faktor-Authentifizierung), nicht verschlüsselte Datenträger. All das zeigt das Basis-Dashboard, ohne einen einzigen Euro zu kosten.
Das Defender-for-Cloud-Dashboard zeigt den Secure Score sowie den Status der einzelnen Defender-Pläne je Subscription.
Merksatz: Aktivieren Sie zunächst den kostenlosen Basisplan für alle Subscriptions und werten Sie den Secure Score aus, bevor Sie kostenpflichtige Defender-Pläne aktivieren. Das allein reduziert Ihr Angriffspotenzial messbar.
Diese Workloads sollten Sie aktiv schützen – Prioritäten richtig setzen
Folgendes Problem aus der Praxis: Ein mittelständisches Unternehmen mit 40 VMs aktiviert Defender for Servers Plan 2 (ca. 15 USD pro Server/Monat) für alle Maschinen – inklusive Dev-VMs, die nachts heruntergefahren sind und intern keine produktiven Daten verarbeiten. Das ist Ressourcenverschwendung.
Eine sinnvolle Priorisierung orientiert sich an Datenklassifizierung, Erreichbarkeit und Schadenspotenzial. Die folgende Tabelle gibt einen strukturierten Überblick:
| Workload / Ressourcentyp | Empfohlener Defender-Plan | Begründung |
|---|---|---|
| Produktive VMs mit Internetexposition | Defender for Servers Plan 2 | Höchstes Angriffspotenzial; Endpoint Detection & Response (EDR) via Microsoft Defender for Endpoint inklusive |
| Azure SQL-Datenbanken mit Kundendaten | Defender for SQL | Erkennt SQL-Injection-Angriffe und anomale Abfragemuster; DSGVO-relevant |
| Storage Accounts mit sensitiven Blobs | Defender for Storage | Malware-Scanning bei Upload, Erkennung ungewöhnlicher Zugriffsmuster |
| AKS-Cluster (Azure Kubernetes Service) in Produktion | Defender for Containers | Laufzeit-Bedrohungserkennung, Image-Schwachstellenanalyse |
| Azure App Service (öffentlich erreichbar) | Defender for App Service | Erkennt OWASP-Top-10-Angriffe, verdächtige Aktivitäten im Hosting-Layer |
| Dev/Test-VMs ohne Produktivdaten | Kein Defender-Plan (Basis reicht) | Kein nennenswertes Schadenspotenzial; Kosteneinsparung sinnvoll |
| Interne VMs ohne Internet-Routing, rein stationär | Defender for Servers Plan 1 (optional) | Bietet Vulnerability Assessment ohne EDR-Overhead; Kompromiss zwischen Schutz und Kosten |
| Storage Accounts für Backups (keine direkten Uploads) | Kein Defender-Plan | Kein Upload-Pfad für Malware; Schutz durch RBAC und Immutable Storage ausreichend |
In den Umgebungseinstellungen lässt sich je Ressourcentyp zwischen verschiedenen Plan-Stufen oder „Aus“ wählen – granularer als viele erwarten.
Praxistipp: Nutzen Sie Azure Policy in Kombination mit Defender for Cloud, um Defender-Pläne automatisch nur auf Ressourcengruppen mit dem Tag Environment=Production anzuwenden. So vermeiden Sie, dass neu angelegte Dev-Ressourcen versehentlich kostenpflichtige Pläne erben.
Was Sie bewusst nicht überwachen müssen – und warum das legitim ist
Es mag kontraintuitiv klingen, aber ein gutes Security-Konzept beinhaltet auch eine bewusste Entscheidung gegen Überwachung in bestimmten Bereichen. Ich hatte mich in diesem Zusammenhang mit mehreren Kunden auseinanderzusetzen, die unter dem Eindruck von Audit-Anforderungen alles aktiviert hatten – und dann die Alert-Flut nicht mehr bewältigen konnten. Security-Teams, die 300 Low-Severity-Alerts täglich wegklicken, verlieren den Blick für das Wesentliche.
Folgende Ressourcentypen werden häufig überbewertet:
- Azure Key Vault in reinen Automatisierungspipelines: Wenn nur Managed Identities zugreifen und kein menschlicher Zugriff stattfindet, ist Defender for Key Vault oft Noise-Quelle. Robustere Alternative: Diagnostic Settings mit Log Analytics und gezielte KQL-Abfragen (Kusto Query Language).
- Storage Accounts für Azure Diagnostics Logs: Diese werden systemintern beschrieben, sind nicht öffentlich und enthalten keine Geschäftsdaten. Defender for Storage hier zu aktivieren erzeugt Kosten ohne nennenswerten Sicherheitsgewinn.
- Azure Functions für interne Trigger: Wenn eine Function App ausschließlich von einem Service Bus (internen Message Broker) ausgelöst wird und keine HTTP-Trigger hat, ist das Angriffspotenzial minimal. Defender for App Service wäre hier überdimensioniert.
Noch mal in Kürze: Der richtige Ansatz ist nicht „alles an“ oder „alles aus“, sondern ein risikobasiertes Modell, das Defender-Pläne dort konzentriert, wo Schadenspotenzial und Erreichbarkeit hoch sind.
Die Workload-Schutz-Übersicht zeigt auf einen Blick, welche Pläne aktiv sind und wie viele Ressourcen sie abdecken – inklusive geschätzter Kosten.
Praxisempfehlung: KMU-taugliche Defender-Struktur zum Abharken
Kurz, knapp und strukturiert – hier eine Baseline-Strategie, die für die meisten kleinen und mittleren Unternehmen mit einer oder zwei Azure-Subscriptions funktioniert:
- ✅ Secure Score Basis: Für alle Subscriptions kostenlos aktivieren und wöchentlich reviewen
- ✅ Defender for Servers Plan 2: Nur für VMs mit dem Tag
Environment=Productionund Internetexposition - ✅ Defender for SQL: Für alle SQL-Instanzen mit Kundendaten oder personenbezogenen Daten (DSGVO-Pflicht de facto)
- ✅ Defender for Storage: Nur für Storage Accounts, auf die externe Nutzer oder Applikationen mit Upload-Rechten zugreifen
- ✅ Defender for Containers: Wenn AKS produktiv im Einsatz ist
- ❌ Alle anderen Pläne: Erst bei konkretem Bedarf und nach Alert-Analyse aktivieren
- ✅ Alert-Unterdrückungsregeln: Von Anfang an Low-Severity-Alerts aus bekannten sicheren Quellen unterdrücken – sonst verliert das Team die Akzeptanz für das Tool
Wenn Sie tiefer in die Konfiguration von Defender for Cloud, Conditional Access (richtlinienbasierte Zugangskontrolle) und die Integration mit Microsoft Sentinel einsteigen möchten, finden Sie das passende Handwerkszeug in meinen Azure-Kursen – praxisnah, ohne Marketingfolien.
Merksatz: Defender for Cloud ist kein Schalter, den Sie einmal umlegen. Es ist ein Prozess: aktivieren, auswerten, anpassen, wiederholen. Wer das versteht, spart Geld und schläft ruhiger.