Termin vereinbaren

Microsoft Defender for Servers im Überblick

  • Wissen & News |
  • Microsoft Defender for Servers im Überblick
Drei Serverumgebungen in Rechenzentrum und Cloud sind über ein zentrales Schutzschild verbunden.
Schaffen Sie Transparenz über Azure-, AWS-, Google-Cloud- und lokale Server. Der Artikel zeigt den Nutzen von Defender for Servers, erklärt Plan 1 und 2 und führt Sie vom ersten Pilot bis zum laufenden Betrieb.

Warum sich ein einheitlicher Schutz lohnt

Auf Servern laufen oft die Anwendungen, Datenbanken und Schnittstellen, die den Arbeitsalltag tragen. Wenn ein System ausfällt oder angegriffen wird, betrifft das schnell mehr als die IT. Gerade bei mehreren Standorten und Cloud-Umgebungen wird es schwer, den Schutz jedes Servers im Blick zu behalten.

  • Eine gemeinsame Sicht: Sicherheitsstatus, Warnungen und Empfehlungen für Azure, AWS, Google Cloud und lokale Server lassen sich zentral auswerten.
  • Risiken gezielt angehen: Schwachstellen und Konfigurationsprobleme werden sichtbar, damit Teams Maßnahmen nach Relevanz planen können.
  • Vorfälle besser bearbeiten: Die Integration mit Defender for Endpoint liefert EDR-Signale für Untersuchung und Reaktion.

So entsteht eine bessere Entscheidungsgrundlage für IT und Geschäftsführung. Der Nutzen hängt davon ab, dass alle relevanten Server erfasst und Warnungen im Betrieb tatsächlich bearbeitet werden.

Server schützen, unabhängig von ihrem Standort

Ein Server steht selten allein: Anwendungen, Datenbanken, Schnittstellen und Identitäten hängen von ihm ab. Microsoft Defender for Servers bringt Azure-VMs, lokale Windows- und Linux-Server sowie Maschinen in AWS und Google Cloud in eine gemeinsame Sicherheitsübersicht. Der Dienst gehört zu Microsoft Defender for Cloud und verbindet den Schutz durch Microsoft Defender for Endpoint mit Empfehlungen für Sicherheitskonfiguration und Schwachstellenbehebung.

Wichtig bei der Einführung: Ein Server muss in Defender for Cloud erfasst sein und sein Defender-for-Endpoint-Sensor muss gesund melden. Ein Eintrag im Inventar allein belegt noch keinen vollständigen Schutz.

Wie die Bausteine zusammenspielen

Defender for Cloud verwaltet Plan, Abdeckung, Sicherheitsstatus und Empfehlungen. Defender for Endpoint liefert auf dem Server unter anderem Antivirus, Endpoint Detection and Response (EDR), Warnungen und Schwachstellendaten. Im Microsoft Defender-Portal untersuchen Sicherheitsteams Geräte und Vorfälle. Azure Arc macht Server außerhalb von Azure zu verwaltbaren Azure-Ressourcen und ermöglicht die Bereitstellung benötigter Erweiterungen.

Azure-VMs sind unmittelbar über ihre Subscription erfassbar. Für lokale Server und Maschinen in AWS oder Google Cloud empfiehlt Microsoft Azure Arc, wenn der volle Funktionsumfang genutzt werden soll. Bei AWS und Google Cloud wird zuvor das jeweilige Konto beziehungsweise Projekt mit Defender for Cloud verbunden.

Plan 1 oder Plan 2?

  • Plan 1: Defender for Endpoint mit Antivirus, EDR, Warnungen, Softwarebestand und sensorbasierter Schwachstellensuche.
  • Plan 2: Alle Funktionen von Plan 1 sowie unter anderem agentenlose Prüfungen, erweiterte Vulnerability-Management-Funktionen, File Integrity Monitoring und Just-in-time-Zugriff. Einzelne Funktionen benötigen zusätzliche Konfiguration und sind nicht auf jeder Plattform verfügbar.

Unsere Orientierung: Plan 1 passt, wenn Antivirus, EDR und grundlegende Schwachstellensicht im Vordergrund stehen. Plan 2 ist sinnvoll, wenn zusätzlich agentenlose Prüfungen, Integritätsüberwachung oder weitere Härtungsfunktionen benötigt werden. Im Azure-Portal ist beim Aktivieren zunächst Plan 2 vorausgewählt – wer Plan 1 möchte, muss ihn ausdrücklich auswählen.

Vorbereitung: fünf Fragen vor dem ersten Klick

  1. Welche Server gehören zum Umfang? Inventarisieren Sie Azure-VMs, lokale Maschinen und Cloud-VMs einschließlich Betriebssystem und Verantwortlichen.
  2. Welcher Plan wird wo benötigt? Klären Sie die betroffenen Azure-Subscriptions und AWS-/GCP-Konten sowie mögliche Ausnahmen.
  3. Ist die Technik bereit? Prüfen Sie unterstützte Betriebssysteme, Administratorrechte, Proxy und ausgehende Verbindungen zu Microsoft Defender und gegebenenfalls Azure Arc.
  4. Welche Schutzsoftware läuft bereits? Planen Sie die Koexistenz oder Migration mit bestehenden Antivirus- und EDR-Lösungen.
  5. Wie wird Erfolg gemessen? Wählen Sie zunächst Testserver und legen Sie fest, wie Inventar, Sensorzustand und Warnungsverarbeitung kontrolliert werden.

Schritt für Schritt: Azure-VMs hinzufügen

  1. Öffnen Sie im Azure-Portal Microsoft Defender for Cloud → Environment settings.
  2. Wählen Sie die Azure-Subscription mit den betreffenden VMs.
  3. Schalten Sie unter Defender plans den Plan Servers ein.
  4. Wählen Sie über Change plans bewusst Plan 1 oder Plan 2 und speichern Sie.
  5. Prüfen Sie in den Planeinstellungen, ob Endpoint protection aktiv ist. Bei Plan 2 kontrollieren Sie die gewünschten Zusatzfunktionen.
  6. Warten Sie die automatische Bereitstellung ab und kontrollieren Sie anschließend die drei Prüfpunkte weiter unten.

Defender for Endpoint wird bei neuen Aktivierungen standardmäßig integriert. Bei älteren Subscriptions können für Windows Server 2012 R2/2016 oder Linux zusätzliche Aktivierungsschritte nötig sein. Die erstmalige Einrichtung im Tenant kann laut Microsoft bis zu zwölf Stunden benötigen.

Schritt für Schritt: lokale Server über Azure Arc hinzufügen

  1. Aktivieren Sie Defender for Servers auf der Azure-Subscription, in der die Arc-Ressourcen liegen sollen.
  2. Öffnen Sie im Azure-Portal Azure Arc → Machines → Onboard/Create → Onboard existing machines.
  3. Wählen Sie Subscription, Ressourcengruppe und Region und laden Sie das generierte Installationsskript herunter.
  4. Führen Sie das Skript direkt auf dem Zielserver mit lokalen Administratorrechten aus: unter Windows in einer administrativen PowerShell, unter Linux mit Root-Rechten.
  5. Prüfen Sie in Azure Arc → Machines den Status Connected. Prüfen Sie danach in Defender for Cloud die Erfassung und den Endpoint-Sensor.

Das Skript installiert den Azure Connected Machine Agent und verbindet den Server mit der Arc-Ressource. Für größere Bestände stehen Verfahren zur automatisierten Bereitstellung zur Verfügung.

AWS und Google Cloud anbinden

Unter Defender for Cloud → Environment settings → Add environment wählen Sie Amazon Web Services oder Google Cloud Platform. Im Assistenten legen Sie Konto beziehungsweise Projekt, Azure-Subscription und Defender-Pläne fest. Die Cloud-Verbindung wird anhand der angezeigten Schritte eingerichtet: bei AWS beispielsweise mit CloudFormation oder Terraform, bei Google Cloud mit einem generierten gcloud-Skript. Aktivieren und prüfen Sie anschließend die Arc-Autoprovisionierung für die Server. Auf AWS-EC2-Instanzen ist hierfür unter anderem ein funktionsfähiger AWS Systems Manager Agent erforderlich.

Kontrollieren Sie danach den Connectivity status des Connectors und die Abdeckung der einzelnen VMs. Die Verbindung des Cloud-Kontos und das erfolgreiche Onboarding jedes Servers sind zwei getrennte Prüfschritte.

Alternative: direktes Onboarding ohne Arc

Lokale Server können auch unmittelbar über Defender for Endpoint mit Defender for Cloud verbunden werden. Die Einstellung liegt unter Environment settings → Direct onboarding. Sie ist vor allem für Plan 1 geeignet. Bei Plan 2 erhalten direkt angebundene Server laut Microsoft nur die Plan-1-Funktionen sowie erweiterte Vulnerability-Management-Funktionen; viele weitere P2-Funktionen benötigen Arc. Die Einstellung erfasst auch bereits angebundene und neue Defender-for-Endpoint-Server desselben Microsoft-Entra-Tenants. Deshalb sollten Umfang und Abrechnung vor der Aktivierung geprüft werden.

So prüfen Sie den tatsächlichen Schutz

  1. Inventar: Suchen Sie den Server in Defender for Cloud → Inventory. Bei lokalen Servern muss Azure Arc zusätzlich Connected anzeigen.
  2. Plan und Erweiterung: Prüfen Sie die Abdeckung des Serverplans und den Status von MDE.Windows beziehungsweise MDE.Linux. Unter Linux liefert mdatp health zusätzliche Angaben zum Sensor.
  3. Gerätemeldung: Suchen Sie den Server im Microsoft Defender-Portal unter Assets → Devices. Kontrollieren Sie Onboarding-Status, Sensorzustand und letzte Meldung. Ein dokumentierter EDR-Test kann die Warnungskette zusätzlich überprüfen.

Lizenzierung und Kosten richtig einordnen

Defender for Servers Plan 1 und Plan 2 werden verbrauchsabhängig pro geschütztem Server über Azure abgerechnet. Die Defender-for-Endpoint-Serverrechte sind enthalten. Eine Microsoft-365-E5-Benutzerlizenz deckt Server nicht automatisch ab; dafür ist eine Serverlizenz oder ein Defender-for-Servers-Plan erforderlich. Bestehen bereits separate Defender-for-Endpoint-Serverlizenzen, beschreibt Microsoft einen per Supportanfrage beantragbaren Abrechnungsabgleich. Er gilt erst ab Genehmigung.

Auch der Betriebszustand zählt: Eine laufende Azure-VM wird berechnet; eine nur im Gastbetriebssystem heruntergefahrene, weiterhin zugewiesene VM kann ebenfalls berechnet werden. Eine deallokierte VM wird nicht berechnet. Verbundene Arc-Server werden berechnet. Der P2-Vorteil von 500 MB pro Server und Tag gilt nur für bestimmte Datentypen und benötigt einen entsprechend konfigurierten Log-Analytics-Workspace. Zusätzliche Dienste wie Microsoft Sentinel sind separat zu kalkulieren. Aktuelle Preise sollten in der eigenen Region und Vertragskonstellation geprüft werden.

Wann ein Pilot besonders sinnvoll ist

Ein Pilot lohnt sich besonders, wenn Server an mehreren Standorten oder in mehreren Clouds betrieben werden, eine Migration nach Azure ansteht oder unklar ist, welche Systeme bereits zuverlässig überwacht werden. Auch bei knappen IT-Ressourcen hilft ein klarer Startumfang: Erst die wichtigsten Workloads schützen, dann Erfahrungen für den breiteren Rollout nutzen.

So kann CloudLights den Einstieg begleiten

  1. Bestand und Ziele klären: Welche Server sind geschäftskritisch, welche Lücken bestehen, und was soll der Pilot nachweisbar verbessern?
  2. Plan und Kosten einordnen: Plan 1 und Plan 2 anhand der benötigten Funktionen und des tatsächlichen Serverbestands vergleichen.
  3. Pilot umsetzen und prüfen: Repräsentative Azure- und lokale Server anbinden, Sensorzustand, Warnungen und Zuständigkeiten testen.
  4. Betrieb planen: Regeln für neue Server, regelmäßige Abdeckungsprüfungen und den Umgang mit Sicherheitsmeldungen festlegen.

Ihr nächster Schritt: Besprechen Sie mit CloudLights, welche Server zuerst in einen überschaubaren Pilot gehören und woran Sie den Erfolg messen. Jetzt Kontakt aufnehmen.

Unsere Einschätzung: klein beginnen, Abdeckung dauerhaft prüfen

Ein guter Start besteht aus wenigen repräsentativen Servern: etwa einer Azure-VM und einem lokalen Arc-Server. Erst wenn Inventar, Sensor und Warnungskette funktionieren, sollte die Bereitstellung auf den gesamten Bestand ausgeweitet werden. Danach gehören fehlende oder ungesunde Sensoren, neue VMs und Sicherheitswarnungen in einen festen Betriebsprozess. Wer Plan 2 nutzt, sollte Zusatzfunktionen bewusst konfigurieren: File Integrity Monitoring ist beispielsweise nicht automatisch aktiv und benötigt einen Log-Analytics-Workspace.

Sie möchten eine hybride Serverlandschaft absichern oder bestehende Defender-Lizenzen sinnvoll einordnen? Sprechen Sie mit CloudLights über einen passenden Pilot und die erforderlichen Betriebsprozesse.

Quellen und weiterführende Links

Stand: 28. September 2026. Mit Unterstützung von KI erstellt.