Blue Teaming

Blue Teaming: Cyberangriffe erkennen und abwehren

Blue Teaming bezeichnet die defensive Seite der Cybersicherheit. Ein Blue Team schützt die IT-Systeme eines Unternehmens, überwacht sicherheitsrelevante Ereignisse und reagiert auf mögliche Cyberangriffe.

Das Ziel besteht darin, Angriffe möglichst früh zu erkennen, ihre Auswirkungen zu begrenzen und die betroffenen Systeme sicher wiederherzustellen. Gleichzeitig verbessert das Blue Team die vorhandenen Schutzmaßnahmen kontinuierlich.

Was ist ein Blue Team?

Das Blue Team besteht aus IT-Sicherheitsfachleuten, die für die Verteidigung einer Organisation verantwortlich sind.

Es überwacht Netzwerke, Endgeräte, Server, Cloud-Dienste und Benutzerkonten auf verdächtige Aktivitäten. Werden Auffälligkeiten erkannt, untersucht das Team, ob es sich um einen Fehlalarm, ein technisches Problem oder einen tatsächlichen Sicherheitsvorfall handelt.

Blue Teaming umfasst damit nicht nur die unmittelbare Abwehr eines Angriffs. Auch Vorsorge, Systemhärtung, Schwachstellenmanagement und die Verbesserung interner Sicherheitsprozesse gehören dazu.

Welche Aufgaben übernimmt ein Blue Team?

Die konkreten Aufgaben hängen von der Größe und Sicherheitsstruktur des Unternehmens ab. Typische Tätigkeiten sind:

  • Überwachung von Systemen, Netzwerken und Cloud-Diensten
  • Erkennung verdächtiger Aktivitäten
  • Analyse und Bewertung von Sicherheitsmeldungen
  • Reaktion auf Sicherheitsvorfälle
  • Isolierung kompromittierter Geräte
  • Untersuchung von Angriffswegen und Ursachen
  • Härtung von Systemen und Anwendungen
  • Beseitigung erkannter Schwachstellen
  • Verbesserung von Alarmierungs- und Eskalationsprozessen
  • Dokumentation von Vorfällen und Maßnahmen

Ein Blue Team arbeitet dabei eng mit der internen IT, dem Datenschutz, der Geschäftsleitung und gegebenenfalls externen Sicherheitspartnern zusammen.

Wie erkennt ein Blue Team Cyberangriffe?

Zur Angriffserkennung werden Informationen aus unterschiedlichen Systemen zusammengeführt und ausgewertet.

Dazu gehören beispielsweise:

  • Anmeldeereignisse
  • Netzwerkverbindungen
  • Aktivitäten auf Computern und Servern
  • Veränderungen an Dateien und Systemeinstellungen
  • Sicherheitsmeldungen von Firewalls
  • Ereignisse aus Cloud- und Identitätsdiensten
  • Hinweise auf schädliche Dateien oder Prozesse

Ein einzelnes Ereignis muss noch keinen Angriff darstellen. Mehrere Auffälligkeiten können jedoch gemeinsam auf einen Sicherheitsvorfall hindeuten.

Ein Beispiel wäre eine ungewöhnliche Anmeldung aus einem fremden Land, gefolgt von zahlreichen fehlgeschlagenen Zugriffsversuchen und dem Herunterladen großer Datenmengen.

Welche Werkzeuge nutzt ein Blue Team?

Blue Teams verwenden verschiedene Sicherheitslösungen zur Überwachung und Reaktion.

SIEM

Ein Security Information and Event Management sammelt Protokoll- und Sicherheitsdaten aus unterschiedlichen Quellen. Es hilft dabei, Ereignisse miteinander zu verknüpfen und verdächtige Muster zu erkennen.

EDR

Endpoint Detection and Response überwacht Endgeräte wie Computer und Server. Eine EDR-Lösung kann auffällige Prozesse erkennen, Angriffsabläufe nachvollziehen und betroffene Geräte vom Netzwerk isolieren.

IDS und IPS

Ein Intrusion Detection System erkennt verdächtige Netzwerkaktivitäten. Ein Intrusion Prevention System kann bestimmte Verbindungen zusätzlich automatisch blockieren.

Vulnerability Management

Beim Schwachstellenmanagement werden Systeme regelmäßig auf bekannte Sicherheitslücken überprüft. Gefundene Schwachstellen werden bewertet, priorisiert und behoben.

Threat Intelligence

Threat Intelligence liefert Informationen über aktuelle Bedrohungen, Angriffsmethoden, schädliche Infrastruktur und bekannte Angreifergruppen. Diese Informationen können die Erkennung gezielter Angriffe verbessern.

Was ist Incident Response?

Incident Response bezeichnet die strukturierte Reaktion auf einen Sicherheitsvorfall.

Ein Blue Team versucht dabei:

  1. den Vorfall zu erkennen und zu bewerten,
  2. betroffene Systeme und Konten zu identifizieren,
  3. die Ausbreitung des Angriffs einzudämmen,
  4. schädliche Komponenten zu entfernen,
  5. Systeme sicher wiederherzustellen,
  6. den Vorfall anschließend auszuwerten.

Nach einem Angriff wird untersucht, wie der Angreifer eindringen konnte, welche Schutzmaßnahmen versagt haben und welche Verbesserungen notwendig sind.

Was ist der Unterschied zwischen Blue Team und Red Team?

Das Blue Team übernimmt die Verteidigung. Das Red Team simuliert dagegen das Vorgehen eines Angreifers.

Das Red Team versucht, Schwachstellen auszunutzen und vereinbarte Angriffsziele zu erreichen. Das Blue Team soll diese Aktivitäten erkennen, untersuchen und stoppen.

Arbeiten beide Seiten eng zusammen, spricht man häufig von Purple Teaming. Dabei werden Angriffsschritte gemeinsam ausgewertet und vorhandene Erkennungs- und Schutzmaßnahmen direkt verbessert.

Ist ein Blue Team dasselbe wie ein SOC?

Nicht vollständig.

Ein Security Operations Center, kurz SOC, ist eine organisatorische Einheit zur kontinuierlichen Sicherheitsüberwachung. Das dort arbeitende Team übernimmt häufig viele typische Blue-Team-Aufgaben.

Blue Teaming ist jedoch der weiter gefasste Begriff für defensive Sicherheitsaktivitäten. Diese können auch von einer internen IT-Abteilung, einem externen Dienstleister oder mehreren spezialisierten Teams übernommen werden.

Warum ist Blue Teaming für Unternehmen wichtig?

Technische Schutzmaßnahmen allein verhindern nicht jeden Cyberangriff. Entscheidend ist auch, ob verdächtige Aktivitäten rechtzeitig erkannt und richtig behandelt werden.

Blue Teaming verbessert unter anderem:

  • die Sichtbarkeit sicherheitsrelevanter Ereignisse
  • die Geschwindigkeit der Angriffserkennung
  • die Reaktion auf Sicherheitsvorfälle
  • die Widerstandsfähigkeit der IT-Systeme
  • die Qualität interner Sicherheitsprozesse
  • den Schutz geschäftskritischer Daten

Je früher ein Angriff erkannt wird, desto besser lassen sich mögliche Schäden und Betriebsunterbrechungen begrenzen.

Fazit

Blue Teaming ist der defensive Kern der Cybersicherheit. Es verbindet technische Überwachung, Angriffserkennung, Incident Response und kontinuierliche Verbesserung.

Ein leistungsfähiges Blue Team schützt ein Unternehmen nicht nur während eines Angriffs. Es sorgt auch dafür, dass Systeme besser vorbereitet sind, Schwachstellen schneller behoben und Erfahrungen aus Sicherheitsvorfällen dauerhaft genutzt werden.

Red Teaming

Red Teaming einfach erklärt

Red Teaming ist eine offensive Sicherheitsprüfung, bei der ein autorisiertes Team realistische Angriffe auf ein Unternehmen simuliert. Ziel ist es, festgelegte Sicherheitsziele zu erreichen und dabei zu prüfen, wie gut Menschen, Prozesse und technische Schutzmaßnahmen einen echten Angriff erkennen und abwehren.

Im Gegensatz zu einem klassischen Penetrationstest untersucht Red Teaming nicht nur einzelne Schwachstellen. Im Mittelpunkt steht ein vollständiges Angriffsszenario aus der Perspektive eines realen Angreifers.

Was ist ein Red Team?

Das Red Team übernimmt die Rolle des Angreifers. Es verwendet kontrolliert Methoden, die auch bei realen Cyberangriffen vorkommen können.

Dazu gehören beispielsweise:

  • Informationsbeschaffung
  • Phishing und Social Engineering
  • Ausnutzung technischer Schwachstellen
  • Missbrauch gestohlener Zugangsdaten
  • Umgehung von Sicherheitskontrollen
  • seitliche Bewegung im Netzwerk
  • Erlangung höherer Berechtigungen
  • Zugriff auf definierte Zielinformationen

Alle Maßnahmen erfolgen innerhalb eines vorher vereinbarten und rechtlich freigegebenen Rahmens.

Was ist das Ziel von Red Teaming?

Ein Red-Team-Test besitzt normalerweise ein konkretes Angriffsziel. Das Team soll nicht wahllos möglichst viele Schwachstellen finden.

Mögliche Ziele sind:

  • Zugriff auf ein besonders geschütztes System
  • Übernahme eines administrativen Kontos
  • Erreichen eines kritischen Netzwerksegments
  • Zugriff auf definierte Testdaten
  • Umgehung bestehender Sicherheitskontrollen
  • Simulation eines Ransomware-Angriffs
  • Prüfung der Erkennungs- und Reaktionsfähigkeit

Damit lässt sich feststellen, ob einzelne Schwachstellen zu einem realistischen Angriffspfad kombiniert werden können.

Wie läuft ein Red-Team-Test ab?

1. Planung und Freigabe

Vor Beginn werden Ziele, Umfang, Zeitraum und erlaubte Methoden festgelegt.

Die sogenannten Rules of Engagement definieren unter anderem:

  • welche Systeme getestet werden dürfen
  • welche Handlungen ausgeschlossen sind
  • ob Social Engineering erlaubt ist
  • welche Auswirkungen vermieden werden müssen
  • wann der Test abgebrochen wird
  • wer im Notfall informiert werden darf
  • wie mit erlangten Daten umgegangen wird

Nur ein kleiner Kreis innerhalb des Unternehmens kennt den genauen Ablauf. Dadurch kann realistisch geprüft werden, ob die vorhandenen Sicherheitsprozesse den Angriff erkennen.

2. Reconnaissance

Das Red Team sammelt Informationen über das Unternehmen, seine Mitarbeitenden und seine technische Infrastruktur.

Mögliche Quellen sind:

  • Unternehmenswebseiten
  • soziale Netzwerke
  • Stellenanzeigen
  • öffentlich erreichbare Systeme
  • technische Metadaten
  • veröffentlichte Dokumente
  • bekannte Datenlecks

Diese Phase bildet die Grundlage für die Auswahl geeigneter Angriffswege.

3. Initialer Zugriff

Anschließend versucht das Team, einen ersten kontrollierten Zugang zu erhalten.

Dafür können je nach Freigabe beispielsweise Phishing, gestohlene Testzugänge, Fehlkonfigurationen oder bekannte Schwachstellen verwendet werden.

4. Ausweitung des Zugriffs

Nach dem ersten Zugriff wird geprüft, ob sich weitere Systeme erreichen oder höhere Berechtigungen erlangen lassen.

Typische Techniken sind:

  • Auslesen lokaler Informationen
  • Missbrauch unsicherer Berechtigungen
  • Lateral Movement
  • Zugriff auf administrative Systeme
  • Nutzung legitimer Verwaltungswerkzeuge
  • Umgehung von Netzwerksegmentierung

5. Erreichen des Testziels

Das Red Team dokumentiert, ob das vereinbarte Ziel erreicht werden konnte.

Statt reale Daten zu stehlen oder Systeme zu verschlüsseln, werden meist sichere Nachweise verwendet. Dazu können markierte Testdateien, Screenshots oder kontrollierte Simulationen gehören.

6. Auswertung

Nach Abschluss werden Angriffspfade, erkannte Schwächen und Reaktionen detailliert ausgewertet.

Dabei wird nicht nur betrachtet, wie der Angriff möglich war, sondern auch:

  • ob er erkannt wurde
  • wie schnell eine Reaktion erfolgte
  • welche Alarme ausgelöst wurden
  • ob interne Prozesse funktionierten
  • welche Maßnahmen den Angriff hätten stoppen können

Red Teaming und Penetrationstest im Vergleich

Ein Penetrationstest soll möglichst viele Schwachstellen innerhalb eines definierten Bereichs erkennen und bewerten. Die Tester arbeiten dabei häufig offen mit der internen IT zusammen.

Red Teaming verfolgt dagegen ein bestimmtes Ziel und versucht, vorhandene Kontrollen möglichst unbemerkt zu umgehen.

Vereinfacht dargestellt:

  • Penetrationstest: Welche Schwachstellen gibt es?
  • Red Teaming: Kann ein realer Angreifer sein Ziel erreichen?
  • Blue Team: Erkennt und stoppt die Verteidigung den Angriff?
  • Purple Teaming: Wie können Angriffs- und Verteidigungsteam gemeinsam die Erkennung verbessern?

Beide Prüfmethoden ergänzen sich, ersetzen einander aber nicht.

Was wird neben der Technik geprüft?

Red Teaming kann mehrere Sicherheitsebenen einbeziehen.

Technische Sicherheit

Dazu gehören Netzwerke, Anwendungen, Cloud-Dienste, Identitäten, Endgeräte und Sicherheitslösungen.

Menschliche Sicherheit

Durch kontrolliertes Social Engineering kann geprüft werden, wie Mitarbeitende auf verdächtige Anfragen oder Phishing reagieren.

Solche Tests müssen sorgfältig geplant werden und dürfen nicht dazu dienen, einzelne Beschäftigte bloßzustellen.

Physische Sicherheit

Je nach Auftrag können auch Zutrittskontrollen, Besucherprozesse oder öffentlich zugängliche Bereiche geprüft werden.

Organisatorische Prozesse

Untersucht werden beispielsweise Meldewege, Eskalationen, Incident Response und die Zusammenarbeit zwischen IT, Management und externen Dienstleistern.

Welche Vorteile bietet Red Teaming?

Ein Red-Team-Test kann Unternehmen helfen:

  • realistische Angriffspfade aufzudecken
  • Sicherheitskontrollen praktisch zu prüfen
  • Erkennungs- und Reaktionszeiten zu bewerten
  • technische und organisatorische Schwächen zu verbinden
  • das Security Operations Center zu testen
  • Prioritäten für Sicherheitsmaßnahmen festzulegen
  • Incident-Response-Prozesse zu verbessern
  • die Wirksamkeit vorhandener Investitionen zu bewerten

Der größte Nutzen entsteht durch die anschließende Behebung und erneute Überprüfung der festgestellten Schwächen.

Welche Grenzen hat Red Teaming?

Red Teaming ist eine zeitlich begrenzte Prüfung mit festgelegten Zielen. Nicht entdeckte Schwachstellen sind daher kein Beweis dafür, dass keine weiteren Risiken bestehen.

Die Methode ersetzt nicht:

  • regelmäßige Schwachstellenscans
  • Penetrationstests
  • Patch Management
  • Sicherheitsmonitoring
  • Awareness-Schulungen
  • sichere Backups
  • Incident-Response-Planung

Red Teaming eignet sich vor allem für Unternehmen, die bereits grundlegende Sicherheitsmaßnahmen und eine funktionierende Überwachung aufgebaut haben.

Fazit

Red Teaming simuliert einen realistischen Cyberangriff auf Menschen, Prozesse und technische Systeme. Statt nur einzelne Schwachstellen zu suchen, versucht das Red Team, ein vorher definiertes Angriffsziel zu erreichen.

Dadurch können Unternehmen prüfen, ob ihre Sicherheitskontrollen Angriffe tatsächlich erkennen, begrenzen und stoppen. Die Ergebnisse liefern eine praxisnahe Grundlage für die Verbesserung von Prävention, Überwachung und Incident Response.

LOTL „Living off the Land“

LOTL: Living off the Land einfach erklärt

LOTL steht für Living off the Land. Der Begriff bezeichnet Angriffstechniken, bei denen Cyberkriminelle legitime Systemprogramme, Verwaltungswerkzeuge, Skriptsprachen oder Netzwerkdienste für schädliche Zwecke missbrauchen.

Anstatt ausschließlich eigene Angriffswerkzeuge zu installieren, verwenden sie Funktionen, die auf dem Zielsystem bereits vorhanden sind oder im normalen IT-Betrieb vertrauenswürdig erscheinen. Dadurch können LOTL-Aktivitäten schwerer von legitimer Administration zu unterscheiden sein.

Was bedeutet Living off the Land?

Bei einem LOTL-Angriff nutzen Angreifer reguläre Werkzeuge außerhalb ihres vorgesehenen Einsatzzwecks.

Mit ihnen können sie beispielsweise:

  • Informationen über Systeme und Netzwerke sammeln
  • Befehle oder Skripte ausführen
  • Dateien übertragen
  • Zugangsdaten auslesen
  • weitere Systeme erreichen
  • Schutzmechanismen verändern
  • dauerhafte Zugänge einrichten
  • Daten sammeln und übertragen

Living off the Land bedeutet nicht zwingend, dass ausschließlich vorinstallierte Programme verwendet werden. Auch legitime Administrationswerkzeuge, die bereits vorhanden oder nachträglich eingebracht wurden, können Teil eines solchen Angriffs sein.

Was sind LOLBins?

Legitime ausführbare Programme, die für Angriffe missbraucht werden, werden häufig als LOLBins bezeichnet. Die Abkürzung steht für Living-off-the-Land Binaries.

Daneben existieren Begriffe wie:

  • LOLScripts: legitime Skripte oder Skriptsprachen
  • LOLLibraries: vertrauenswürdige Programmbibliotheken
  • LOLDrivers: legitime, aber missbrauchbare Hardwaretreiber

Diese Komponenten sind nicht grundsätzlich schädlich. Erst der Verwendungszweck und der technische Zusammenhang machen ihre Nutzung verdächtig.

Typische Beispiele für LOTL-Werkzeuge

PowerShell

PowerShell ist eine leistungsfähige Verwaltungs- und Automatisierungsumgebung. Angreifer können sie unter anderem für Systemabfragen, Skriptausführung, Downloads und die Steuerung weiterer Angriffsschritte verwenden.

WMI

Die Windows Management Instrumentation, kurz WMI, ermöglicht die Verwaltung und Abfrage von Windows-Systemen.

Sie kann missbraucht werden, um Prozesse lokal oder aus der Ferne zu starten, Systeme auszuspähen oder bestimmte dauerhafte Ausführungsmechanismen einzurichten.

Rundll32 und MSHTA

Programme wie rundll32.exe oder mshta.exe sind legitime Windows-Komponenten. Unter bestimmten Bedingungen lassen sie sich jedoch zur Ausführung fremder oder unerwünschter Inhalte verwenden.

CertUtil

CertUtil dient eigentlich der Verwaltung von Zertifikaten. Bestimmte Funktionen können jedoch auch zum Übertragen, Dekodieren oder Verarbeiten von Dateien missbraucht werden.

PsExec

PsExec ist ein legitimes Administrationswerkzeug aus der Microsoft-Sysinternals-Sammlung. Wenn es in einer Umgebung vorhanden ist, kann es zur entfernten Ausführung von Befehlen verwendet werden.

RDP und SMB

Remote Desktop und SMB sind legitime Netzwerkdienste. Angreifer können sie mit gestohlenen Zugangsdaten zur Bewegung zwischen Systemen verwenden.

Die Dienste selbst sind keine klassischen LOLBins, können aber Bestandteil einer Living-off-the-Land-Strategie sein.

Warum sind LOTL-Angriffe schwer zu erkennen?

Viele der verwendeten Programme werden auch von Administratoren, Supportmitarbeitern und automatisierten IT-Prozessen eingesetzt.

Ein einfaches Blockieren ist daher häufig nicht möglich, ohne den regulären Betrieb zu beeinträchtigen.

Zusätzliche Herausforderungen sind:

  • Programme sind häufig digital signiert.
  • Dateinamen und Speicherorte wirken vertrauenswürdig.
  • Aktivitäten können wie normale Administration aussehen.
  • Es muss nicht zwingend eine unbekannte Schadsoftware gespeichert werden.
  • Verschiedene legitime Werkzeuge können zu einer Angriffskette kombiniert werden.

Signaturbasierte Virenscanner erkennen solche Aktivitäten deshalb nicht immer zuverlässig. Moderne Endpoint-Sicherheitslösungen können sie jedoch anhand von Verhalten, Prozessketten und ungewöhnlichen Kombinationen erkennen.

Ist LOTL dasselbe wie ein dateiloser Angriff?

Nein. Beide Begriffe überschneiden sich, sind aber nicht identisch.

Ein dateiloser Angriff versucht, möglichst wenige dauerhafte Dateien auf einem System zu hinterlassen und führt Code beispielsweise direkt im Arbeitsspeicher aus.

Ein LOTL-Angriff verwendet legitime Werkzeuge. Dabei können trotzdem Dateien, Skripte, geplante Aufgaben oder andere dauerhafte Veränderungen entstehen.

Auch eigene Malware kann mit LOTL-Techniken kombiniert werden.

Wie können Unternehmen LOTL-Angriffe erkennen?

Da die verwendeten Werkzeuge nicht grundsätzlich schädlich sind, muss vor allem ihr Verhalten untersucht werden.

Mögliche Hinweise sind:

  • PowerShell-Aufrufe mit verschleierten Befehlen
  • ungewöhnliche Prozessketten
  • Office-Anwendungen, die Kommandozeilenprogramme starten
  • WMI-Aktivitäten von untypischen Benutzerkonten
  • Systemprogramme mit ausgehenden Internetverbindungen
  • häufige Remote-Anmeldungen zwischen Arbeitsplatzsystemen
  • Ausführung administrativer Werkzeuge außerhalb üblicher Zeiten
  • Programme in ungewöhnlichen Verzeichnissen
  • deaktivierte Protokollierung oder Sicherheitsfunktionen

Ein einzelnes Ereignis ist dabei nicht immer ein Beweis für einen Angriff. Erst der Kontext ermöglicht eine verlässliche Bewertung.

Schutzmaßnahmen gegen Living off the Land

Berechtigungen begrenzen

Benutzer und Dienste sollten nur die Rechte besitzen, die sie tatsächlich benötigen. Administrative Konten sollten getrennt und besonders geschützt werden.

Multi-Faktor-Authentifizierung einsetzen

MFA erschwert den Missbrauch gestohlener Zugangsdaten, insbesondere bei Remote-Zugängen und administrativen Konten.

Anwendungskontrolle verwenden

Werkzeuge wie Windows Defender Application Control oder AppLocker können festlegen, welche Programme und Skripte ausgeführt werden dürfen.

Da viele LOTL-Werkzeuge legitim sind, müssen die Regeln allerdings genauer sein als eine einfache Freigabe signierter Programme.

Protokollierung verbessern

Wichtige Datenquellen sind unter anderem:

  • PowerShell-Protokolle
  • Befehlszeilenparameter
  • Prozessstarts
  • WMI-Aktivitäten
  • Benutzeranmeldungen
  • Netzwerkverbindungen
  • Änderungen an Diensten und geplanten Aufgaben

Die Protokolle sollten zentral gesammelt, ausgewertet und vor Manipulation geschützt werden.

EDR oder XDR einsetzen

Verhaltensbasierte Sicherheitslösungen können ungewöhnliche Abläufe erkennen, auch wenn die beteiligten Programme selbst legitim sind.

Administration absichern

Administrative Werkzeuge sollten nur von vorgesehenen Geräten, Konten und Netzwerkbereichen verwendet werden dürfen.

Netzwerk segmentieren

Eine Segmentierung begrenzt die Möglichkeiten zur seitlichen Bewegung, nachdem ein einzelnes System kompromittiert wurde.

Fazit

Living off the Land bezeichnet den Missbrauch legitimer System- und Verwaltungswerkzeuge für Cyberangriffe. Da dieselben Programme auch im normalen IT-Betrieb verwendet werden, sind LOTL-Aktivitäten schwieriger zu erkennen als eindeutig schädliche Software.

Ein wirksamer Schutz erfordert deshalb verhaltensbasierte Erkennung, zentrale Protokollierung, minimale Berechtigungen, abgesicherte Administrationswege und eine sorgfältige Analyse ungewöhnlicher Prozess- und Netzwerkaktivitäten.

HCI-Stack

HCI-Stack: Hyperkonvergente Infrastruktur einfach erklärt

Ein HCI-Stack ist eine softwaregesteuerte IT-Infrastruktur, die Rechenleistung, Datenspeicher und Virtualisierung in einer gemeinsamen Plattform zusammenführt. HCI steht für Hyper-Converged Infrastructure, auf Deutsch hyperkonvergente Infrastruktur.

Statt separate Server, Speichersysteme und Verwaltungsplattformen einzusetzen, verteilt ein HCI-System diese Aufgaben auf mehrere miteinander verbundene Serverknoten. Die gesamte Umgebung lässt sich zentral verwalten und durch zusätzliche Knoten erweitern.

Was ist ein HCI-Stack?

Ein klassisches Rechenzentrum besteht häufig aus getrennten Komponenten:

  • Server für die Rechenleistung
  • zentrale Speichersysteme
  • Speichernetzwerke
  • Virtualisierungssoftware
  • unterschiedliche Verwaltungswerkzeuge

Bei einem HCI-Stack werden Rechenleistung und lokale Datenträger mehrerer Server durch Software zu einer gemeinsamen Infrastruktur verbunden.

Die Daten werden abhängig von der Konfiguration auf mehrere Knoten verteilt oder repliziert. Fällt ein Knoten aus, können andere Knoten dessen Aufgaben übernehmen. Voraussetzung dafür sind eine geeignete Architektur und ausreichend verbleibende Ressourcen.

Welche Komponenten gehören zu einem HCI-Stack?

Ein HCI-Stack besteht üblicherweise aus mehreren Bausteinen.

Serverknoten

Jeder Knoten stellt Prozessorleistung, Arbeitsspeicher, Netzwerkanschlüsse und lokale Datenträger bereit. Mehrere Knoten bilden gemeinsam einen HCI-Cluster.

Hypervisor

Der Hypervisor ermöglicht den Betrieb virtueller Maschinen. Er verteilt die vorhandene Rechenleistung und den Arbeitsspeicher auf die einzelnen Workloads.

Je nach Plattform können beispielsweise Hyper-V, VMware ESXi oder ein KVM-basierter Hypervisor eingesetzt werden.

Software-defined Storage

Beim Software-defined Storage, kurz SDS, werden die lokalen Datenträger der Server zu einem gemeinsamen Speicherverbund zusammengefasst.

Die Software übernimmt unter anderem:

  • Verteilung der Daten
  • Replikation
  • Ausfallschutz
  • Speicherzuweisung
  • Wiederherstellung nach einem Knotenausfall

Ein separates zentrales SAN-Speichersystem ist dadurch häufig nicht erforderlich.

Netzwerk

Ein leistungsfähiges und redundant ausgelegtes Netzwerk verbindet die Knoten miteinander. Es transportiert unter anderem Daten zwischen virtuellen Maschinen und synchronisiert die Speicherinformationen.

Software-defined Networking kann zusätzliche Funktionen für die virtuelle Netzwerkverwaltung bereitstellen. Es ist jedoch nicht zwingend Bestandteil jeder HCI-Lösung.

Zentrale Verwaltung

Über eine gemeinsame Verwaltungsoberfläche lassen sich Cluster, virtuelle Maschinen, Speicher, Updates und Betriebszustand überwachen.

Je nach Plattform können auch Automatisierung, Cloud-Anbindung, Backup und Sicherheitsfunktionen integriert werden.

Wie funktioniert ein HCI-Cluster?

Die einzelnen Serverknoten arbeiten als gemeinsamer Verbund.

Startet ein Unternehmen eine virtuelle Maschine, stellt der Cluster die benötigte Rechenleistung, den Arbeitsspeicher und den Speicherplatz bereit. Die Daten liegen nicht ausschließlich auf einem einzelnen Server, sondern werden entsprechend der festgelegten Ausfallschutzregeln verteilt.

Fällt ein Knoten aus, können virtuelle Maschinen auf anderen Knoten neu gestartet oder weiterbetrieben werden. Ob dies ohne Unterbrechung möglich ist, hängt von der Plattform, Konfiguration und Art des Ausfalls ab.

HCI bietet daher nicht automatisch uneingeschränkte Hochverfügbarkeit. Redundanz, Kapazitätsreserven, Netzwerk, Stromversorgung und Backup müssen weiterhin sorgfältig geplant werden.

Wie wird ein HCI-Stack erweitert?

HCI-Systeme werden normalerweise horizontal skaliert. Dabei wird dem Cluster ein weiterer Serverknoten hinzugefügt.

Der neue Knoten stellt zusätzliche Ressourcen bereit:

  • Prozessorleistung
  • Arbeitsspeicher
  • Speicherplatz
  • Netzwerkleistung

Dieses Vorgehen wird als Scale-out bezeichnet.

Je nach Plattform müssen die Knoten bestimmte technische Vorgaben erfüllen. Außerdem lassen sich Rechenleistung und Speicher nicht bei jeder Lösung vollständig unabhängig voneinander erweitern. Wird nur zusätzlicher Speicher benötigt, kann deshalb unter Umständen auch ungenutzte Rechenleistung hinzukommen.

Was ist der Unterschied zur klassischen Infrastruktur?

Bei einer klassischen Infrastruktur werden Server, Speichersysteme und Speichernetzwerke meist getrennt geplant und verwaltet.

Ein HCI-Stack fasst wesentliche Funktionen über Software auf standardisierten oder zertifizierten Serverknoten zusammen.

Dadurch kann die Infrastruktur einfacher erweitert und zentraler betrieben werden. Gleichzeitig entsteht eine stärkere Abhängigkeit von der gewählten Plattform und deren unterstützter Hardware.

Klassische Architekturen können weiterhin sinnvoll sein, wenn:

  • sehr große zentrale Speichersysteme benötigt werden
  • Rechenleistung und Speicher unabhängig wachsen müssen
  • spezielle Hardwareanforderungen bestehen
  • vorhandene Systeme langfristig weiterbetrieben werden
  • bestimmte Anwendungen nicht für HCI freigegeben sind

Welche Vorteile bietet ein HCI-Stack?

Zu den möglichen Vorteilen gehören:

  • zentrale Verwaltung der Infrastruktur
  • einfachere Bereitstellung virtueller Maschinen
  • horizontale Erweiterung durch zusätzliche Knoten
  • integrierte Speicherreplikation
  • weniger separate Infrastrukturkomponenten
  • standardisierte Bereitstellung an mehreren Standorten
  • Unterstützung von Private-Cloud- und Edge-Szenarien
  • automatisierbare Betriebs- und Updateprozesse

Ob sich dadurch tatsächlich Kosten reduzieren, hängt von Hardware, Lizenzierung, Wachstum, Betriebsaufwand und vorhandener Infrastruktur ab.

Welche Herausforderungen gibt es?

Vor der Einführung müssen auch mögliche Nachteile berücksichtigt werden:

  • Abhängigkeit von Hersteller und Plattform
  • hohe Anforderungen an das Clusternetzwerk
  • gemeinsame Skalierung von Rechenleistung und Speicher
  • komplexe Fehleranalyse bei verteilten Systemen
  • Lizenz- und Supportkosten
  • vorgeschriebene Hardwarekonfigurationen
  • notwendige Kapazitätsreserven für Ausfälle
  • besonderer Planungsbedarf bei Updates

Ein HCI-Cluster ersetzt außerdem kein Backup. Replikation schützt vor dem Ausfall einzelner Komponenten, übernimmt aber auch versehentliche Löschungen, beschädigte Daten oder Verschlüsselungen durch Ransomware.

Wo wird HCI eingesetzt?

Typische Einsatzbereiche sind:

  • Servervirtualisierung
  • Private-Cloud-Umgebungen
  • virtuelle Desktop-Infrastrukturen
  • Außenstellen und Niederlassungen
  • Edge Computing
  • Rechenzentrumsmodernisierung
  • hochverfügbare Unternehmensanwendungen
  • lokale Plattformen für virtuelle Maschinen und Container

Für kleine Standorte stehen teilweise kompakte Cluster bereit. Größere Umgebungen können aus zahlreichen Knoten bestehen.

Beispiele für HCI-Plattformen

Bekannte HCI-Lösungen und Plattformen sind unter anderem:

  • Microsoft Azure Local, früher Azure Stack HCI
  • Nutanix
  • VMware-vSAN-basierte Lösungen
  • Dell VxRail
  • HPE SimpliVity

Die Produkte unterscheiden sich bei Hypervisor, Hardwareauswahl, Cloud-Anbindung, Lizenzierung und Verwaltungsfunktionen.

Fazit

Ein HCI-Stack verbindet Rechenleistung, lokalen Speicher und Virtualisierung zu einer zentral verwalteten Infrastruktur. Mehrere Serverknoten bilden gemeinsam einen skalierbaren Cluster, der virtuelle Maschinen und weitere Workloads ausführen kann.

HCI kann den Aufbau und Betrieb einer virtualisierten Infrastruktur vereinfachen. Voraussetzung sind jedoch eine sorgfältige Kapazitätsplanung, ein leistungsfähiges Netzwerk, ausreichende Redundanz und ein separates Backup-Konzept.

Kubernetes

Kubernetes einfach erklärt

Kubernetes, häufig als K8s abgekürzt, ist eine Open-Source-Plattform zur automatisierten Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen.

Kubernetes wurde ursprünglich von Google entwickelt und wird heute als Projekt der Cloud Native Computing Foundation, kurz CNCF, weiterentwickelt. Die Plattform kann im eigenen Rechenzentrum, in Public Clouds oder in hybriden Umgebungen betrieben werden.

Was ist Kubernetes?

Kubernetes ist ein sogenannter Container-Orchestrator. Die Plattform koordiniert Anwendungen, die in Containern verpackt sind, über mehrere Server hinweg.

Dabei übernimmt Kubernetes unter anderem:

  • Verteilung von Anwendungen auf verfügbare Systeme
  • Überwachung des gewünschten Betriebszustands
  • Neustart ausgefallener Container
  • horizontale Skalierung
  • interne Dienstauflösung
  • Lastverteilung
  • kontrollierte Updates und Rollbacks
  • Verwaltung von Konfigurationen und Zugangsdaten

Kubernetes erstellt jedoch keine Container-Images. Diese werden zuvor mit Werkzeugen wie Docker, Podman oder Build-Systemen erzeugt und in einer Container Registry gespeichert.

Wie funktioniert Kubernetes?

Ein Kubernetes-System besteht aus einem oder mehreren Servern, die gemeinsam einen Cluster bilden.

Der gewünschte Zustand einer Anwendung wird deklarativ beschrieben. Dabei wird beispielsweise festgelegt:

  • welches Container-Image verwendet wird
  • wie viele Instanzen laufen sollen
  • welche Ressourcen benötigt werden
  • über welche Netzwerkadresse die Anwendung erreichbar ist
  • welche Konfigurationen eingebunden werden
  • wie Updates durchgeführt werden

Kubernetes vergleicht diesen gewünschten Zustand kontinuierlich mit dem tatsächlichen Zustand des Clusters. Fällt beispielsweise eine Instanz aus, versucht die Plattform, automatisch eine neue bereitzustellen.

Dieses Verhalten wird häufig als Self-Healing bezeichnet. Es ersetzt jedoch weder eine fehlertolerante Anwendungsarchitektur noch ein Backup-Konzept.

Zentrale Bestandteile von Kubernetes

Cluster

Ein Cluster ist die gesamte Kubernetes-Umgebung. Er besteht aus einer Control Plane und einem oder mehreren Worker Nodes.

Control Plane

Die Control Plane verwaltet den Cluster. Sie nimmt Konfigurationen entgegen, plant Workloads ein und überwacht den Zustand der Umgebung.

Zu ihren Aufgaben gehören:

  • Verwaltung der Cluster-Konfiguration
  • Auswahl geeigneter Nodes
  • Überwachung des Sollzustands
  • Steuerung von Skalierung und Bereitstellung

Für produktive Umgebungen sollte die Control Plane hochverfügbar ausgelegt sein.

Nodes

Nodes sind physische oder virtuelle Server, auf denen die Anwendungen ausgeführt werden.

Auf jedem Worker Node laufen Komponenten, die Container starten, überwachen und mit dem Kubernetes-Cluster verbinden.

Pods

Ein Pod ist die kleinste von Kubernetes verwaltete Ausführungseinheit.

Ein Pod enthält einen oder mehrere eng zusammengehörige Container. Diese teilen sich bestimmte Netzwerk- und Speicherressourcen.

Pods sind grundsätzlich austauschbar. Anwendungen sollten deshalb nicht davon ausgehen, dass ein bestimmter Pod dauerhaft bestehen bleibt.

Deployments

Ein Deployment beschreibt, wie viele Instanzen einer Anwendung laufen sollen und welches Container-Image verwendet wird.

Es unterstützt unter anderem kontrollierte Aktualisierungen und die Rückkehr zu einer vorherigen Version.

Services

Ein Kubernetes Service stellt eine stabile Netzwerkadresse für eine Gruppe von Pods bereit.

Da Pods neu erstellt und ersetzt werden können, ermöglicht der Service den zuverlässigen Zugriff auf eine Anwendung, ohne deren wechselnde IP-Adressen kennen zu müssen.

Ingress und Gateway

Ingress-Ressourcen können HTTP- und HTTPS-Zugriffe von außerhalb des Clusters an interne Services weiterleiten. Dafür wird ein zusätzlicher Ingress Controller benötigt.

In neueren Architekturen kann alternativ die Kubernetes Gateway API für erweiterte Routing-Szenarien eingesetzt werden.

ConfigMaps und Secrets

ConfigMaps speichern allgemeine Konfigurationswerte. Secrets sind für vertrauliche Angaben wie Kennwörter, Schlüssel oder Zertifikate vorgesehen.

Secrets sind allerdings nicht automatisch umfassend geschützt. Verschlüsselung, Berechtigungen und externe Secret-Management-Lösungen müssen entsprechend konfiguriert werden.

Welche Vorteile bietet Kubernetes?

Kubernetes kann den Betrieb moderner Anwendungen vereinheitlichen und automatisieren.

Mögliche Vorteile sind:

  • standardisierte Anwendungsbereitstellung
  • automatisierte Skalierung
  • kontrollierte Updates
  • Wiederherstellung ausgefallener Pods
  • bessere Ressourcennutzung
  • Unterstützung von CI/CD-Prozessen
  • Betrieb auf unterschiedlichen Infrastrukturen
  • umfangreiches Cloud-Native-Ökosystem
  • Trennung von Anwendung und Infrastruktur

Die Plattform verbessert die Portabilität, macht Anwendungen aber nicht automatisch vollständig unabhängig von einem Cloud-Anbieter. Abhängigkeiten können beispielsweise durch Datenbanken, Speicherlösungen oder proprietäre Cloud-Dienste entstehen.

Welche Herausforderungen gibt es?

Kubernetes ist leistungsfähig, bringt aber zusätzliche Komplexität mit sich.

Zu den Herausforderungen gehören:

  • Einrichtung und Wartung des Clusters
  • Netzwerk- und Speicherkonfiguration
  • Absicherung von Rollen und Berechtigungen
  • Überwachung und Protokollierung
  • Verwaltung von Updates
  • Schutz der Software-Lieferkette
  • Fehlersuche in verteilten Anwendungen
  • Sicherung zustandsbehafteter Daten
  • benötigtes Spezialwissen

Für kleinere oder einfache Anwendungen kann eine weniger komplexe Plattform wirtschaftlicher sein.

Kubernetes und virtuelle Maschinen im Vergleich

Container und virtuelle Maschinen sind keine vollständigen Gegensätze. Kubernetes-Cluster werden häufig selbst auf virtuellen Maschinen betrieben.

Eine virtuelle Maschine enthält ein vollständiges Gastbetriebssystem. Container verwenden dagegen den Kernel des zugrunde liegenden Betriebssystems und isolieren die ausgeführten Prozesse.

Container bieten dadurch häufig:

  • kürzere Startzeiten
  • geringeren Ressourcenbedarf
  • standardisierte Bereitstellung
  • hohe Anwendungsdichte

Virtuelle Maschinen bieten dagegen eine stärkere Trennung auf Betriebssystemebene und eignen sich häufig besser für:

  • klassische Serveranwendungen
  • unterschiedliche Betriebssysteme auf einem Host
  • ältere oder nicht containerfähige Software
  • Workloads mit besonderen Isolationsanforderungen

In vielen Infrastrukturen werden beide Technologien kombiniert.

Typische Einsatzbereiche

Kubernetes wird unter anderem eingesetzt für:

  • Microservices
  • Webanwendungen und APIs
  • cloud-native Anwendungen
  • DevOps- und CI/CD-Umgebungen
  • hybride Cloud-Infrastrukturen
  • Edge Computing
  • skalierbare Plattformdienste
  • Entwicklungs- und Testumgebungen

Zustandsbehaftete Anwendungen wie Datenbanken können ebenfalls in Kubernetes betrieben werden. Sie erfordern jedoch eine besonders sorgfältige Planung von Speicher, Verfügbarkeit, Datensicherung und Wiederherstellung.

Fazit

Kubernetes automatisiert die Bereitstellung und Verwaltung containerisierter Anwendungen über mehrere Systeme hinweg. Die Plattform sorgt dafür, dass der definierte Zustand einer Anwendung möglichst dauerhaft eingehalten wird.

Kubernetes eignet sich besonders für dynamische, skalierbare und automatisierte Anwendungslandschaften. Der Nutzen muss jedoch gegen den erhöhten Betriebs-, Sicherheits- und Schulungsaufwand abgewogen werden.

Arc Local

Azure Local: Azure-Infrastruktur lokal betreiben

Azure Local ist eine verteilte Infrastrukturlösung von Microsoft, mit der Unternehmen virtuelle Maschinen, Container und ausgewählte Azure-Dienste auf eigener Hardware betreiben können.

Die Anwendungen und Daten bleiben dabei im eigenen Rechenzentrum, an einem Unternehmensstandort oder in einer Edge-Umgebung. Gleichzeitig lassen sich zentrale Verwaltungs- und Sicherheitsfunktionen von Microsoft Azure nutzen.

Azure Local hieß früher Azure Stack HCI und verwendet Azure Arc als einheitliche Verwaltungs- und Steuerungsebene.

Was ist Azure Local?

Azure Local erweitert Azure-Funktionen auf kundeneigene IT-Infrastrukturen. Unternehmen können damit moderne und klassische Anwendungen lokal ausführen, ohne sämtliche Workloads in ein öffentliches Cloud-Rechenzentrum verlagern zu müssen.

Die benötigten Rechen-, Speicher- und Netzwerkressourcen werden auf geeigneter Hardware am gewünschten Standort bereitgestellt. Die Verwaltung erfolgt je nach Betriebsmodell über das Azure-Portal, die Azure-Befehlszeile oder weitere Administrationswerkzeuge.

Azure Local eignet sich besonders für Anwendungen, die aus technischen, regulatorischen oder organisatorischen Gründen lokal betrieben werden müssen.

Welche Rolle spielt Azure Arc?

Azure Arc verbindet lokale, verteilte und cloudbasierte Ressourcen mit der Azure-Verwaltung.

Bei Azure Local dient Azure Arc als Steuerungsebene. Dadurch können Unternehmen ihre lokale Infrastruktur mit Azure-Diensten und einheitlichen Verwaltungsprozessen verbinden.

Azure Arc und Azure Local sind jedoch nicht dasselbe:

  • Azure Arc erweitert Azure-Verwaltungsfunktionen auf vorhandene Server, Kubernetes-Cluster und andere Ressourcen außerhalb von Azure.
  • Azure Local ist eine vollständige Infrastrukturlösung, auf der virtuelle Maschinen, Container und ausgewählte Azure-Dienste lokal ausgeführt werden.

Welche Funktionen bietet Azure Local?

Zu den zentralen Funktionen gehören:

  • lokaler Betrieb von Windows- und Linux-VMs
  • Ausführung containerisierter Anwendungen
  • zentrale Verwaltung über Azure
  • rollenbasierte Zugriffssteuerung
  • Integration von Überwachungs- und Sicherheitsdiensten
  • Verwaltung verteilter Standorte
  • Bereitstellung ausgewählter Azure-Arc-Dienste
  • Unterstützung moderner und bestehender Anwendungen
  • einheitliche Verwaltung von Cloud- und lokalen Ressourcen

Welche Funktionen zur Verfügung stehen, hängt von der eingesetzten Konfiguration, der Softwareversion und den gebuchten Azure-Diensten ab.

Kann Azure Local ohne Internetverbindung betrieben werden?

Azure Local ist grundsätzlich eng mit Azure verbunden. Die Cloudanbindung wird unter anderem für Verwaltung, Überwachung, Support und Abrechnung verwendet.

Microsoft bietet zusätzlich Disconnected Operations für bestimmte Einsatzszenarien an. Dabei werden Verwaltungsfunktionen über eine lokale Steuerungsebene bereitgestellt, ohne dass eine dauerhafte Verbindung zur öffentlichen Azure-Cloud erforderlich ist.

Diese Betriebsart ist beispielsweise für abgeschottete, souveräne oder besonders sicherheitskritische Umgebungen gedacht. Sie ist jedoch an besondere technische Voraussetzungen gebunden und unterstützt nicht automatisch alle Funktionen des verbundenen Betriebs.

Azure Local sollte deshalb nicht grundsätzlich als vollständig cloudunabhängige Lösung verstanden werden.

Typische Einsatzbereiche

Azure Local eignet sich unter anderem für:

  • Produktions- und Fertigungsstandorte
  • Filialen und Niederlassungen
  • Logistik- und Einzelhandelsumgebungen
  • lokale Rechenzentren
  • Edge-Computing-Anwendungen
  • Azure Virtual Desktop am eigenen Standort
  • Anwendungen mit niedrigen Latenzanforderungen
  • Umgebungen mit Vorgaben zur lokalen Datenhaltung
  • hybride Cloud-Strategien
  • zeitweise oder vollständig getrennte IT-Umgebungen

Ein Unternehmen kann beispielsweise Daten direkt an einer Produktionsanlage verarbeiten, während übergeordnete Verwaltungs- und Sicherheitsfunktionen zentral bereitgestellt werden.

Welche Vorteile bietet Azure Local?

Azure Local verbindet die Kontrolle einer lokalen Infrastruktur mit ausgewählten Funktionen der Azure-Plattform.

Zu den möglichen Vorteilen gehören:

  • Anwendungen und Daten verbleiben am gewünschten Standort
  • einheitliche Verwaltung verteilter Infrastrukturen
  • Unterstützung moderner und klassischer Workloads
  • Integration in bestehende Azure-Prozesse
  • geringere Latenz bei lokaler Datenverarbeitung
  • zentrale Richtlinien und Zugriffssteuerung
  • flexible Bereitstellung an Rechenzentrums- und Edge-Standorten

Gleichzeitig müssen Unternehmen die lokale Hardware, Netzwerkanbindung, Verfügbarkeit und den laufenden Betrieb sorgfältig planen.

Fazit

Azure Local ermöglicht es Unternehmen, virtuelle Maschinen, Container und ausgewählte Azure-Dienste auf eigener Infrastruktur auszuführen. Azure Arc stellt dabei die Verbindung zur zentralen Azure-Verwaltung her.

Die Lösung eignet sich besonders für hybride IT-Strategien, verteilte Standorte, Edge Computing und Anwendungen, die aus technischen oder regulatorischen Gründen lokal betrieben werden müssen. Für besondere Anforderungen stehen zusätzlich Betriebsmodelle ohne dauerhafte Verbindung zur öffentlichen Azure-Cloud zur Verfügung.

SCVMM

SCVMM: System Center Virtual Machine Manager einfach erklärt

SCVMM steht für System Center Virtual Machine Manager. Microsoft bezeichnet das Produkt offiziell meist kurz als VMM. Es ist Bestandteil der System-Center-Produktfamilie und dient zur zentralen Verwaltung größerer virtualisierter Rechenzentrumsumgebungen.

Mit VMM können Administratoren Hosts, Cluster, virtuelle Maschinen, Netzwerke und Speicherressourcen über eine gemeinsame Plattform verwalten. Der Schwerpunkt liegt auf Microsoft Hyper-V und darauf basierenden Infrastrukturen.

Was ist SCVMM?

SCVMM ist eine Verwaltungs- und Automatisierungsplattform für virtuelle Infrastrukturen. Sie fasst die zugrunde liegenden Ressourcen eines Rechenzentrums zu einer sogenannten Fabric zusammen.

Zur VMM-Fabric können gehören:

  • Hyper-V-Hosts und Failover-Cluster
  • virtuelle Maschinen
  • Netzwerke und VLANs
  • virtuelle Switches
  • IP- und MAC-Adressbereiche
  • Speichersysteme
  • Vorlagen und Installationsmedien
  • Bibliotheksserver
  • Private-Cloud-Ressourcen

Administratoren erhalten dadurch einen zentralen Überblick über die vorhandenen Ressourcen und können virtuelle Systeme standardisiert bereitstellen.

Welche Funktionen bietet SCVMM?

Zentrale Verwaltung virtueller Maschinen

Virtuelle Maschinen lassen sich über die VMM-Konsole oder PowerShell erstellen, starten, stoppen, verschieben und löschen.

VMM unterstützt außerdem Funktionen wie:

  • Live Migration
  • Speichermigration
  • Hochverfügbarkeit
  • Klonen virtueller Maschinen
  • Konvertierung bestimmter VMware-VMs
  • Verwaltung von Prüfpunkten
  • Zuweisung virtueller Hardware

Welche Funktionen verfügbar sind, hängt von der eingesetzten Plattform und deren Konfiguration ab.

Verwaltung von Hosts und Clustern

VMM kann Hyper-V-Hosts und Failover-Cluster in eine gemeinsame Verwaltungsstruktur aufnehmen.

Die Plattform unterstützt unter anderem:

  • Hinzufügen vorhandener Hosts
  • Bereitstellung neuer Hyper-V-Systeme
  • Clusterbildung
  • Wartungsmodus
  • Überwachung verfügbarer Ressourcen
  • Platzierung virtueller Maschinen
  • Verschieben von Workloads zwischen Hosts

Bei der Platzierung bewertet VMM beispielsweise verfügbare Prozessor-, Arbeitsspeicher-, Netzwerk- und Speicherressourcen.

Netzwerkverwaltung

VMM bildet physische und virtuelle Netzwerke über logische Modelle ab.

Verwaltet werden können beispielsweise:

  • logische Netzwerke
  • Netzwerkstandorte
  • IP-Subnetze
  • VLANs
  • virtuelle Netzwerke
  • logische Switches
  • IP-Adresspools
  • MAC-Adresspools

Damit können einheitliche Netzwerkkonfigurationen auf mehreren Hosts und Clustern bereitgestellt werden.

Speicherverwaltung

VMM kann unterstützte Speicherressourcen erkennen, klassifizieren und Hosts oder Clustern zuweisen.

Dazu gehören je nach Umgebung:

  • lokale Datenträger
  • Cluster Shared Volumes
  • SMB-basierter Speicher
  • SAN- und NAS-Systeme
  • softwaredefinierter Speicher

Die zentrale Verwaltung vereinfacht die Bereitstellung von Speicher für virtuelle Maschinen. Backup und langfristige Datensicherung müssen jedoch über zusätzliche Lösungen umgesetzt werden.

Vorlagen und Bibliothek

In der VMM-Bibliothek werden wiederverwendbare Ressourcen für die Bereitstellung gespeichert.

Dazu können gehören:

  • virtuelle Festplatten
  • ISO-Dateien
  • Skripte
  • Treiber
  • VM-Vorlagen
  • Hardwareprofile
  • Betriebssystemprofile

Eine VM-Vorlage definiert beispielsweise Betriebssystem, virtuelle Hardware, Netzwerkeinstellungen und weitere Bereitstellungsparameter. Dadurch lassen sich neue Systeme schneller und einheitlicher erstellen.

Welche Virtualisierungsplattformen unterstützt VMM?

Der Schwerpunkt von VMM liegt auf Hyper-V-Umgebungen. Aktuelle Versionen unterstützen außerdem bestimmte VMware-vSphere- und ESXi-Versionen.

Die VMware-Unterstützung umfasst jedoch nicht zwangsläufig alle Funktionen, die über VMware-eigene Verwaltungswerkzeuge zur Verfügung stehen. Vor einer Integration müssen deshalb die aktuelle Supportmatrix und bestehende Einschränkungen geprüft werden.

VMM 2025 kann außerdem virtuelle Maschinen in unterstützten Azure-Local-Umgebungen verwalten. Dabei gelten besondere technische Vorgaben und Einschränkungen.

Wie wird SCVMM mit Azure verbunden?

Für hybride Verwaltungsfunktionen kann VMM über Azure Arc-enabled SCVMM mit Azure verbunden werden.

Dafür wird eine Azure Arc Resource Bridge in der VMM-Umgebung bereitgestellt. Sie stellt ausgewählte VMM-Ressourcen im Azure-Portal dar.

Unterstützt werden je nach Szenario beispielsweise:

  • Anzeige des VMM-Inventars in Azure
  • Registrierung von Clouds und VM-Vorlagen
  • Bereitstellung und Verwaltung virtueller Maschinen
  • Zuweisung von Berechtigungen über Azure RBAC
  • Nutzung ausgewählter Azure-Arc-Dienste

VMM 2025 verwaltet Azure-Ressourcen nicht mehr über die früheren direkten Azure-Integrationsfunktionen. Für moderne hybride Szenarien ist Azure Arc vorgesehen.

Was ist der Unterschied zu Hyper-V Manager?

Der Hyper-V Manager verwaltet einzelne Hyper-V-Hosts und deren virtuelle Maschinen. Er eignet sich vor allem für kleinere oder einfache Umgebungen.

SCVMM ist dagegen für eine zentrale Verwaltung mehrerer Hosts, Cluster und Rechenzentrumsressourcen ausgelegt.

VMM bietet zusätzlich:

  • zentrale Fabric-Verwaltung
  • Vorlagen und Bibliotheken
  • automatisierte Platzierung
  • übergreifende Netzwerkmodelle
  • Speicherintegration
  • rollenbasierte Delegation
  • Private-Cloud-Konzepte
  • umfangreiche PowerShell-Automatisierung

Für wenige Hyper-V-Server kann VMM zu komplex sein. In größeren Umgebungen ermöglicht es dagegen eine standardisierte und zentral kontrollierte Verwaltung.

Ist SCVMM ein Monitoring-System?

VMM zeigt den Status und die Ressourcenauslastung der verwalteten Infrastruktur an. Es ersetzt jedoch kein umfassendes Monitoring-System.

Für detaillierte Langzeitüberwachung, Alarmierung und Auswertung können zusätzliche Lösungen wie System Center Operations Manager oder andere Monitoring-Plattformen eingesetzt werden.

Auch Backup, Endpoint-Schutz und Schwachstellenmanagement sind keine vollständigen Kernfunktionen von VMM und benötigen eigene Sicherheits- und Betriebswerkzeuge.

Welche Vorteile bietet SCVMM?

Zu den möglichen Vorteilen gehören:

  • zentrale Verwaltung mehrerer Hosts und Cluster
  • standardisierte Bereitstellung virtueller Maschinen
  • automatisierbare Arbeitsabläufe
  • einheitliche Netzwerk- und Speicherkonfiguration
  • bessere Übersicht über vorhandene Ressourcen
  • Unterstützung von Hochverfügbarkeit
  • Delegation über Rollen und Berechtigungen
  • Anbindung an hybride Azure-Verwaltung

Der tatsächliche Nutzen hängt von Größe, Standardisierung und Komplexität der Virtualisierungsumgebung ab.

Welche Herausforderungen gibt es?

Ein VMM-Betrieb benötigt eine sorgfältige Planung und regelmäßige Wartung.

Zu berücksichtigen sind unter anderem:

  • unterstützte Versionen von Hosts und Hypervisoren
  • VMM-Datenbank und SQL Server
  • Active-Directory-Abhängigkeiten
  • Netzwerkkommunikation und Berechtigungen
  • Hochverfügbarkeit des VMM-Servers
  • Aktualisierung von VMM und verwalteten Hosts
  • Sicherung der Datenbank und Bibliothek
  • Absicherung administrativer Konten
  • Dokumentation automatisierter Prozesse

Fehlerhafte Änderungen können zahlreiche Hosts und virtuelle Maschinen betreffen. Administrative Berechtigungen sollten deshalb auf das notwendige Minimum begrenzt werden.

Fazit

System Center Virtual Machine Manager ist Microsofts zentrale Verwaltungsplattform für größere virtualisierte Rechenzentrumsumgebungen. VMM verwaltet Hyper-V-Hosts, Cluster, virtuelle Maschinen, Netzwerke und Speicherressourcen als gemeinsame Fabric.

Die Plattform eignet sich besonders für Unternehmen, die viele Virtualisierungshosts standardisiert betreiben, Bereitstellungen automatisieren oder Private- und Hybrid-Cloud-Szenarien umsetzen möchten. Für eine sichere und zuverlässige Umgebung müssen VMM, Hosts, Datenbank, Berechtigungen und ergänzende Betriebswerkzeuge gemeinsam geplant werden.

Entra ID

Microsoft Entra ID einfach erklärt

Microsoft Entra ID ist der cloudbasierte Identitäts- und Zugriffsverwaltungsdienst von Microsoft. Unternehmen verwalten damit Benutzer, Gruppen, Geräte, Anwendungen und Zugriffsrechte für Microsoft 365 und andere Cloud-Dienste.

Der Dienst hieß bis 2023 Azure Active Directory, kurz Azure AD. Trotz des früheren Namens ist Microsoft Entra ID nicht mit einem klassischen lokalen Active Directory gleichzusetzen.

Was ist Microsoft Entra ID?

Microsoft Entra ID stellt digitale Identitäten bereit und prüft, wer auf eine Anwendung, ein Gerät oder eine Ressource zugreifen darf.

Zu den zentralen Funktionen gehören:

  • Verwaltung von Benutzern und Gruppen
  • Anmeldung an Microsoft 365 und anderen Cloud-Anwendungen
  • Single Sign-On
  • Multi-Faktor-Authentifizierung
  • Conditional Access
  • Verwaltung von Anwendungen und Dienstidentitäten
  • rollenbasierte Zugriffssteuerung
  • Erkennung riskanter Anmeldungen
  • Verwaltung externer Benutzer und Partner

Microsoft Entra ID kann vollständig cloudbasierte Benutzerkonten verwalten oder mit einem lokalen Active Directory verbunden werden.

Was ist der Unterschied zwischen Entra ID und Active Directory?

Ein klassisches Active Directory Domain Services, kurz AD DS, wird normalerweise auf lokalen Windows-Servern betrieben. Es verwaltet unter anderem Windows-Domänen, Computer, Gruppenrichtlinien und lokale Netzwerkressourcen.

Microsoft Entra ID ist dagegen auf cloudbasierte Identitäten und Zugriffe ausgerichtet. Es wird beispielsweise für Microsoft 365, Cloud-Anwendungen und moderne Authentifizierungsverfahren eingesetzt.

Wichtige Unterschiede sind:

  • Active Directory verwendet unter anderem Kerberos, LDAP und Gruppenrichtlinien.
  • Entra ID arbeitet mit modernen webbasierten Authentifizierungsprotokollen.
  • Lokale Computer können einer Windows-Domäne beitreten.
  • Cloudverwaltete Geräte können Microsoft Entra beitreten.
  • Entra ID bietet Funktionen wie Conditional Access und cloudbasierte Multi-Faktor-Authentifizierung.

Viele Unternehmen verwenden beide Systeme parallel. Diese Kombination wird als hybride Identitätsumgebung bezeichnet.

Was ist Microsoft Entra Connect Sync?

Microsoft Entra Connect Sync verbindet ein lokales Active Directory mit Microsoft Entra ID.

Die Software wird auf einem lokalen Windows-Server betrieben und synchronisiert ausgewählte Identitätsinformationen in die Cloud. Dazu können gehören:

  • Benutzerkonten
  • Gruppen
  • Kontakte
  • ausgewählte Verzeichnisattribute
  • optional Passwort-Hashes

Dadurch müssen Benutzerkonten nicht doppelt im lokalen Active Directory und in Microsoft Entra ID gepflegt werden.

Wird beispielsweise ein neuer Mitarbeiter im lokalen Active Directory angelegt und befindet sich das Konto im definierten Synchronisierungsbereich, wird die Identität bei der nächsten Synchronisierung in Microsoft Entra ID bereitgestellt.

Wie funktioniert die Synchronisierung?

Microsoft Entra Connect Sync liest die freigegebenen Objekte und Attribute aus dem lokalen Active Directory aus. Anschließend verarbeitet die Synchronisierungsengine diese Informationen anhand festgelegter Regeln und überträgt sie an Microsoft Entra ID.

Das lokale Active Directory bleibt bei vielen synchronisierten Objekten die führende Quelle. Bestimmte Eigenschaften müssen deshalb weiterhin lokal geändert werden.

Nicht jede Änderung aus der Cloud wird automatisch in das lokale Active Directory zurückgeschrieben. Für bestimmte Funktionen existieren gesonderte Writeback-Optionen, die von Konfiguration, Lizenzierung und Einsatzszenario abhängen.

Werden Passwörter in die Cloud übertragen?

Bei der Passwort-Hash-Synchronisierung wird nicht das lesbare Passwort in Microsoft Entra ID gespeichert.

Stattdessen wird aus dem bereits im Active Directory gespeicherten Passwort-Hash ein weiterer Hash erzeugt und an Microsoft Entra ID übertragen. Benutzer können sich dadurch mit demselben Kennwort an unterstützten lokalen und cloudbasierten Diensten anmelden.

Neben der Passwort-Hash-Synchronisierung existieren weitere Anmeldeverfahren, beispielsweise Pass-Through Authentication oder Verbundlösungen. Welche Methode geeignet ist, hängt von der vorhandenen Infrastruktur und den Sicherheitsanforderungen ab.

Ermöglicht Entra Connect automatisch Single Sign-On?

Die Synchronisierung sorgt zunächst für eine gemeinsame Benutzeridentität in der lokalen und cloudbasierten Umgebung.

Ob Benutzer tatsächlich ohne erneute Eingabe ihrer Zugangsdaten auf Cloud-Dienste zugreifen können, hängt zusätzlich von der gewählten Authentifizierungsmethode, den Geräteeinstellungen und der Konfiguration des Single Sign-On ab.

Entra Connect Sync allein garantiert daher noch kein vollständiges Single Sign-On.

Was ist Microsoft Entra Cloud Sync?

Microsoft Entra Cloud Sync ist eine modernere, überwiegend cloudverwaltete Alternative zu Entra Connect Sync.

Bei Entra Connect Sync werden Synchronisierungsengine und Konfiguration hauptsächlich auf einem lokalen Server betrieben. Cloud Sync verwendet dagegen leichte lokale Bereitstellungsagenten, während die Konfiguration zentral in Microsoft Entra verwaltet wird.

Mögliche Vorteile sind:

  • geringerer lokaler Verwaltungsaufwand
  • cloudbasierte Konfiguration
  • automatische Aktualisierung der Agenten
  • Unterstützung mehrerer Active-Directory-Gesamtstrukturen
  • vereinfachte Bereitstellung und hohe Verfügbarkeit

Cloud Sync und Entra Connect Sync unterscheiden sich jedoch in ihrer Architektur und bei unterstützten Funktionen. Vor einer Umstellung muss geprüft werden, ob alle benötigten Identitäts-, Geräte- und Anwendungsszenarien unterstützt werden.

Welche Vorteile bietet eine hybride Identität?

Die Verbindung von lokalem Active Directory und Microsoft Entra ID kann Unternehmen mehrere Vorteile bieten:

  • zentrale Pflege von Benutzerkonten
  • Nutzung bestehender Identitäten für Microsoft 365
  • weniger doppelte Verwaltungsarbeit
  • einheitliche Benutzernamen
  • Unterstützung lokaler und cloudbasierter Anwendungen
  • schrittweiser Übergang in die Cloud
  • Nutzung moderner Sicherheitsfunktionen
  • automatisierte Bereitstellung und Deaktivierung von Konten

Damit eignet sich die hybride Identität besonders für Unternehmen, die weiterhin lokale Server und Anwendungen betreiben, gleichzeitig aber Microsoft 365 und andere Cloud-Dienste verwenden.

Welche Sicherheitsfunktionen bietet Entra ID?

Microsoft Entra ID unterstützt verschiedene Funktionen zur Absicherung von Benutzerkonten und Anwendungen.

Dazu gehören:

  • Multi-Faktor-Authentifizierung
  • Conditional Access
  • rollenbasierte Berechtigungen
  • risikobasierte Zugriffsentscheidungen
  • Protokollierung von Anmeldungen
  • Schutz privilegierter Rollen
  • Zugriffsüberprüfungen
  • Verwaltung von Unternehmensanwendungen

Diese Funktionen werden nicht allein durch die Einrichtung der Synchronisierung aktiviert. Sie müssen passend zu den Anforderungen des Unternehmens geplant, lizenziert und konfiguriert werden.

Was ist beim Betrieb von Entra Connect Sync zu beachten?

Eine fehlerhafte Synchronisierung kann Auswirkungen auf zahlreiche Benutzerkonten haben. Unternehmen sollten deshalb insbesondere folgende Punkte berücksichtigen:

  • Synchronisierungsumfang klar festlegen
  • nicht benötigte Konten und Gruppen ausschließen
  • Benutzerattribute vor der Einführung bereinigen
  • doppelte oder widersprüchliche Identitäten vermeiden
  • Synchronisierungsfehler überwachen
  • den Entra-Connect-Server regelmäßig aktualisieren
  • administrative Zugänge besonders schützen
  • Änderungen an Synchronisierungsregeln dokumentieren
  • Notfall- und Wiederherstellungsverfahren vorbereiten

Vor größeren Änderungen sollte geprüft werden, welche Auswirkungen sie auf lokale und cloudbasierte Identitäten haben.

Fazit

Microsoft Entra ID ist die zentrale Microsoft-Plattform für cloudbasierte Identitäts- und Zugriffsverwaltung. Sie steuert Anmeldungen und Berechtigungen für Microsoft 365, Cloud-Anwendungen, Geräte und weitere Ressourcen.

Mit Microsoft Entra Connect Sync oder Microsoft Entra Cloud Sync lassen sich lokale Active-Directory-Identitäten mit Entra ID verbinden. So entsteht eine hybride Identitätsumgebung, in der Benutzerkonten über lokale und cloudbasierte Systeme hinweg einheitlich verwaltet werden können.

Voraussetzung für einen sicheren Betrieb sind ein klar definierter Synchronisierungsumfang, geschützte Administratorkonten, eine zuverlässige Überwachung und korrekt konfigurierte Zugriffsrichtlinien.

Disaster-Recovery-Plan erstellen: So machen Sie Ihre IT krisensicher

Ein IT-Notfall kommt selten mit Vorwarnung – und doch sind viele Unternehmen unzureichend vorbereitet. Ein durchdachter Disaster-Recovery-Plan sichert nicht nur Systeme, sondern auch Ihre Handlungsfähigkeit im Ernstfall. In diesem Beitrag erfahren Sie, wie Sie Ihre IT strukturiert und praxisnah auf Krisenszenarien vorbereiten – von der Analyse über die Kommunikation bis zur Wiederherstellung.

Krisensicher dank Strategie: Ihre Roadmap für ein robustes Disaster-Recovery-Konzept

Ein funktionierendes IT-System ist heute das Rückgrat jedes Unternehmens. Doch genau darin liegt die Gefahr: Wenn alles läuft, fehlt oft der Antrieb, sich auf den Ausnahmezustand vorzubereiten. Dabei ist gerade jetzt der ideale Zeitpunkt, um Strukturen zu hinterfragen, Risiken neu zu bewerten und konkrete Notfallmaßnahmen zu planen.

Denn die zentrale Frage ist nicht ob etwas passiert, sondern wann – und wie gut Sie dann vorbereitet sind.

Teil 1 - Was zählt, wenn es ernst wird

Warum jetzt handeln?

Ob Cyberangriffe, Systemausfälle, Naturkatastrophen oder menschliches Versagen – Szenarien für IT-Disaster gibt es viele. Die Zahl erfolgreicher Angriffe auf mittelständische Unternehmen und Konzerne ist in den letzten Jahren dramatisch gestiegen. Gleichzeitig verlassen sich viele Organisationen auf komplexe Systeme – ohne zu wissen, wie schnell diese im Ernstfall wieder verfügbar wären.

Gerade in Zeiten geopolitischer Unsicherheit und zunehmender Digitalisierung ist ein Disaster-Recovery-Plan (DRP) kein „nice to have“, sondern essenzieller Bestandteil einer resilienten Unternehmensstrategie.

Bestandsaufnahme: Was brauche ich wirklich?

Nicht jedes System ist im Notfall gleich wichtig. Die erste Frage muss daher lauten: Welche Prozesse sind geschäftskritisch – und welche Systeme stehen dahinter?
Eine strukturierte Business Impact Analyse (BIA) liefert hier Antworten. Sie zeigt, welche Systeme sehr schnell verfügbar sein müssen (z. B. Warenwirtschaft, Produktionssteuerung, Kommunikation) – und welche und welche Systeme nachgelagert reaktiviert werden können.

Wichtige Fragen dabei:

  • Welche Daten und Prozesse sind für den Fortbestand des Unternehmens unverzichtbar?
  • Wie lange kann der Betrieb ohne bestimmte Systeme aufrechterhalten werden?
  • Was kostet eine Stunde Stillstand – konkret?

Vertrauensgrenzen: Was ist noch sicher – was nicht mehr?

Viele Unternehmen vertrauen blind auf Systeme, die im Notfall selbst zum Problem werden können. Beispiel: Microsoft 365. Was auf den ersten Blick redundant erscheint, ist oft ein Single Point of Failure – denn auch Cloud-Dienste können ausfallen oder Ziel von Angriffen sein.
Ein eigener Exchange-Server im RZ mag altmodisch wirken – bietet aber unter Umständen mehr Kontrolle im Notfall. Entscheidend ist: Wo ziehe ich die Grenze des Vertrauens? Und welche Abhängigkeiten bin ich bereit einzugehen?
Auch hier gilt: Systeme, auf die Sie sich im Notfall verlassen wollen, müssen im Unternehmen durchdacht, getestet und notfalls isoliert lauffähig sein – sei es über eine Private Cloud, Terminalserver oder dedizierte Notfallumgebung.

Zielgrößen: RTO & RPO

Die zwei wichtigsten Kennzahlen im Disaster Recovery:

  • RTO (Recovery Time Objective): Wie schnell muss ein System wieder verfügbar sein?
  • RPO (Recovery Point Objective): Wie alt dürfen die Daten im Worst Case maximal sein?

Ein Beispiel: Wenn Sie Ihre Daten nur einmal täglich sichern, verlieren Sie im Ernstfall bis zu 24 Stunden an Informationen – das ist Ihr RPO. Wenn ein System erst nach 48 Stunden wieder hochgefahren werden kann, ist das Ihr RTO.
Viele Unternehmen definieren diese Werte zu optimistisch – oder gar nicht. Ein realistischer Abgleich zwischen Business-Anforderungen und technischer Machbarkeit ist daher essenziell.

Teil 2 – Kommunikation im Ernstfall: Klarheit statt Chaos

Ein Disaster-Recovery-Plan ist mehr als nur Technik. Einer der häufigsten Fehler in Notfallsituationen ist eine fehlende oder ungeplante Kommunikation – intern wie extern. Dabei entscheidet die richtige Kommunikation darüber, ob ein Vorfall schnell eingegrenzt werden kann oder zum Reputationsrisiko wird.

Wer kommuniziert – und wann?

In der Krise zählt jede Minute. Unklare Zuständigkeiten oder widersprüchliche Aussagen verzögern nicht nur den Wiederanlauf, sondern sorgen für Vertrauensverlust – bei Kunden, Mitarbeitenden und Partnern.
Ein guter DR-Plan definiert deshalb:

  • Verantwortliche Personen für Kommunikation (z. B. Geschäftsführung, IT-Leitung, Pressesprecher)
  • Klare Meldeketten intern – wer informiert wen in welcher Reihenfolge?
  • Vorbereitete Textbausteine für gängige Szenarien (Cyberangriff, Systemausfall, Datenverlust)
  • Kanalstrategie: Wann ist E-Mail sinnvoll, wann besser ein direkter Anruf?

Besonderheit: Kommunikation mit Externen

Spätestens wenn Kunden oder Aufsichtsbehörden betroffen sind, muss das Unternehmen reagieren – und zwar kontrolliert. Eine unüberlegte Aussage wie „Unsere IT wurde gehackt“ kann größere Schäden verursachen als der Vorfall selbst.
Typische externe Kommunikationspartner:

  • Kunden & Lieferanten
  • Presse & Öffentlichkeit
  • Behörden (z. B. Datenschutz, Finanzaufsicht)
  • Versicherungen

Je nach Branche können Meldepflichten bestehen – z. B. bei Datenschutzverletzungen (DSGVO). Auch dafür sollte ein DR-Plan vorbereitet sein.

Sonderfall: Cloud-Ausfälle und SaaS-Dienste

Ein beliebter Irrtum: „Wenn Microsoft 365 ausfällt, ist das nicht unser Problem.“ Doch genau das sehen Kunden und Mitarbeiter oft anders. Wer moderne SaaS-Plattformen nutzt, trägt auch Verantwortung für die Kommunikation im Störfall – selbst wenn die technische Ursache extern liegt.
Daher gilt:

  • Auch Cloud-basierte Dienste brauchen Notfallkommunikationsszenarien
  • Die Verantwortung für Kommunikation bleibt immer beim Unternehmen
  • Externe SLA-Verweise reichen im Ernstfall nicht aus

Praxis-Tipp: Kommunikations-plan als Teil des DR-Konzepts

Ein praxistauglicher Kommunikationsplan besteht idealerweise aus:

  • Kontaktdaten aller relevanten Personen (auch privat / mobil)
  • Kurzanleitungen für häufige Krisenszenarien
  • Templates für Pressemitteilungen und interne Mitteilungen
  • Liste mit Kommunikationsverboten (z. B. keine technischen Details ohne Freigabe)

Ziel: Jeder weiß sofort, was zu tun ist – und niemand muss „im Moment der Krise“ improvisieren.

„Living off the Land“: Die unsichtbare Gefahr aus dem eigenen System

Angriffe, die aussehen wie normale Systemaktivitäten…

Cyberangriffe haben sich verändert. Heute arbeiten viele Angreifer subtiler – sie greifen nicht von außen mit neuen Programmen an, sondern nutzen das, was bereits im Unternehmen vorhanden ist. Dieses Prinzip wird als „Living off the Land“ (LOTL) bezeichnet. Es beschreibt eine Methode, bei der sich Angreifer gezielt jener Tools bedienen, die in jeder Windows-Umgebung zum Alltag gehören: PowerShell, Windows-Dienste, Remote Desktop oder interne Skripte.
Das Heimtückische daran: Diese Werkzeuge sind fester Bestandteil des Betriebssystems und werden regelmäßig von Administratoren oder Wartungsdiensten genutzt. Sie sehen nicht verdächtig aus. Deshalb bleiben sie in vielen Fällen völlig unbemerkt – selbst von erfahrenen IT-Teams oder modernen Sicherheitslösungen.

Wenn der Angreifer kein Fremder mehr ist

Ein LOTL-Angriff beginnt meist mit einem kleinen Türöffner: ein kompromittiertes Benutzerkonto, eine Phishing-Mail, ein ungesicherter Fernzugriff. Von dort aus bewegen sich die Angreifer systematisch weiter – von System zu System, von Dienst zu Dienst. Sie erstellen eigene Skripte, überwachen die Umgebung, sammeln Informationen. Immer mit denselben Bordmitteln, die auch Ihr IT-Team nutzt.

Besonders gefährlich wird es, wenn administrative Rechte ins Spiel kommen. Denn mit diesen Rechten können nicht nur produktive Systeme manipuliert, sondern auch Sicherungssysteme gezielt außer Kraft gesetzt werden. Backups werden gelöscht oder verschlüsselt, Protokolle bereinigt, Alarmierungen deaktiviert. Wenn das Unternehmen den Angriff schließlich entdeckt, ist der eigentliche Schaden oft längst geschehen – und die Wiederherstellung wird zum Wettlauf gegen die Zeit.

Warum klassische Sicherheit hier nicht ausreicht

Die meisten Sicherheitskonzepte setzen auf die Erkennung von fremder Software oder auffälligem Verhalten. Doch bei einem LOTL-Angriff findet beides nicht statt. Alles wirkt legitim – denn es ist legitim. Genau deshalb greifen hier viele Schutzmechanismen ins Leere. Antivirenprogramme schlagen nicht an, weil keine Malware im klassischen Sinne vorliegt. Firewall-Regeln bleiben wirkungslos, weil sich der Angreifer innerhalb des Netzes bewegt. Und Protokolle sind nur hilfreich, wenn sie detailliert genug sind – was in vielen Unternehmen nicht der Fall ist.

Hinzu kommt: Je besser der Angreifer vorbereitet ist, desto unauffälliger verhält er sich. Manche Attacken laufen über Wochen oder Monate – leise, präzise und ohne sichtbare Spuren. Gerade für Unternehmen ohne aktives Monitoring oder ohne Segmentierung im Netzwerk ist das ein enormes Risiko.

Was ein Disaster-Recovery-Plan berücksichtigen muss

Ein moderner Disaster-Recovery-Plan darf sich nicht nur auf äußere Angriffe oder Hardware-Ausfälle konzentrieren. Er muss auch interne Bedrohungsszenarien abbilden – und LOTL ist eines der relevantesten davon. Das bedeutet konkret: Unternehmen müssen wissen, welche administrativen Werkzeuge im Einsatz sind, wer sie nutzen darf, wie sie überwacht werden und wie im Ernstfall schnell und zuverlässig reagiert werden kann.

Zudem sollte geprüft werden, ob Backups wirklich außerhalb des Netzwerks erreichbar sind – oder ob sie bei einem internen Angriff ebenfalls gefährdet wären. Auch Zugriffskonzepte, Rechtevergabe, Protokollierung und Alarmierungen gehören auf den Prüfstand. Wer diese Fragen im Vorfeld klärt, kann im Ernstfall zielgerichtet handeln – statt im Dunkeln zu tappen.

„Living off the Land“ ist eine der gefährlichsten Bedrohungen unserer Zeit – gerade, weil sie schwer zu erkennen ist und auf Systemen basiert, denen wir jeden Tag vertrauen. Doch mit der richtigen Vorbereitung lässt sich das Risiko deutlich reduzieren. Ein sauber geplanter, regelmäßig getesteter Disaster-Recovery-Plan ist dabei der entscheidende Baustein.

Schritt für Schritt: Ihre Roadmap zum Disaster-Recovery-Plan

Struktur statt Aktionismus

Ein Notfallplan bringt nur dann echten Mehrwert, wenn er nicht im Ordner verstaubt, sondern im Ernstfall greift. Doch viele Unternehmen scheitern nicht an der Technik, sondern an der fehlenden Struktur. Es reicht nicht, „irgendetwas“ zu sichern oder ein Backup-Konzept zu haben – entscheidend ist, wer, was, wann und wie wiederherstellt, kommuniziert und entscheidet. Damit der DR-Plan mehr ist als eine technische Skizze, braucht es ein klares Vorgehen. Nicht alles muss sofort umgesetzt werden – aber alles sollte bewusst entschieden und dokumentiert sein.

Phase 1: Bewertung & Priorisierung

Der erste Schritt ist die kritische Selbstbefragung: Welche Systeme sind wirklich überlebenswichtig? Was muss nach einem Ausfall sofort wieder funktionieren – und was kann warten? Dabei hilft eine Business-Impact-Analyse (BIA). Sie stellt die Verbindung zwischen Geschäftsprozessen und IT-Systemen her. Gemeinsam mit den Fachabteilungen wird festgelegt, welche Ausfallzeiten verkraftbar sind – und wo der Betrieb zum Stillstand kommt. Diese Phase ist bewusst nicht technisch. Sie erfordert betriebswirtschaftliches Denken: Welche Kosten entstehen pro Stunde Ausfall? Welche Kundenbeziehungen wären gefährdet? Welche regulatorischen Anforderungen müssen eingehalten werden?

Phase 2: Zieldefinition & Strategie

Sind die Prioritäten klar, geht es an die technischen Zielgrößen: Wie schnell muss ein System wieder laufen (RTO, Recovery Time Objective)? Und wie alt dürfen die Daten maximal sein (RPO, Recovery Point Objective)? Darauf basierend lassen sich konkrete Wiederherstellungsszenarien planen – von einzelnen Applikationen bis hin zum vollständigen Wiederanlauf eines Standorts. Strategien können hybride Wege beinhalten, z. B. ein schneller Start über virtuelle Maschinen in einer Private Cloud, während parallel die physische Infrastruktur wiederhergestellt wird. Auch Optionen wie das Hochziehen einer temporären Umgebung, z. B. via Terminalserver in neuer Domäne, gehören in diesen Plan. Wichtig ist dabei: Jedes Szenario muss realistisch, testbar und dokumentiert sein.

Phase 3: Umsetzung & Tests

Ein Disaster-Recovery-Plan ist nur so gut wie seine Praxisfähigkeit. Darum ist es essenziell, den Ernstfall nicht nur zu simulieren, sondern regelmäßig durchzuspielen – unter realitätsnahen Bedingungen.
Tests zeigen nicht nur technische Schwachstellen, sondern auch organisatorische: Wer weiß im Ernstfall, was zu tun ist? Gibt es aktuelle Ansprechpartnerlisten? Wer hat Zugriff auf das Notfallhandy oder auf Offline-Dokumentationen?
Parallel dazu müssen die technischen Maßnahmen umgesetzt werden: Backup-Strategien, Notfall-Server, Monitoring, Alarmierungswege, Kommunikationspläne – alles, was im Krisenfall den Unterschied macht.

Phase 4: Dokumentation & Verankerung

Ein DR-Plan ist ein lebendiges Dokument. Er muss regelmäßig aktualisiert, zugänglich gemacht und in die Unternehmensprozesse eingebettet werden. Nur wenn Verantwortlichkeiten klar benannt und Prozesse transparent sind, kann der Plan im Ernstfall greifen.
In dieser Phase sollten auch Schulungen stattfinden – nicht nur für IT, sondern auch für die Fachabteilungen. Denn ein erfolgreicher Wiederanlauf ist keine rein technische, sondern eine unternehmerische Leistung.
Disaster Recovery ist kein Projekt, das man „mal eben“ umsetzt. Aber mit einer strukturierten Roadmap, klaren Prioritäten und realistischen Zielen wird aus einem Risiko ein beherrschbares Szenario. Unternehmen, die vorbereitet sind, gewinnen im Ernstfall nicht nur Zeit – sondern auch Vertrauen, Stabilität und Handlungsfähigkeit.

Fazit: Wer vorbereitet ist, bleibt handlungsfähig

Struktur statt Aktionismus

Ein IT-Notfall kommt selten mit Vorankündigung. Und wenn er eintritt, zählt jede Minute. Unternehmen, die dann einfach in die Schublade greifen und auf einen konkreten, durchdachten Plan zurückgreifen können, sind im Vorteil – operativ, rechtlich und kommunikativ.

Disaster Recovery ist kein rein technisches Thema. Es ist ein strategisches Element moderner Unternehmensführung. Wer seine Systeme kennt, Abhängigkeiten bewertet, Verantwortlichkeiten definiert und Wiederanlaufszenarien durchspielt, ist nicht nur besser geschützt – sondern auch schneller wieder im Geschäft.
Dabei geht es nicht darum, jedes Szenario bis ins letzte Detail zu antizipieren. Vielmehr zählt die Fähigkeit, im Krisenfall schnell, geordnet und wirksam zu handeln. Und genau dafür ist ein guter Disaster-Recovery-Plan gemacht.

Sind Sie vorbereitet? Oder hoffen Sie noch auf Glück?
 Vielleicht läuft Ihre IT derzeit reibungslos. Vielleicht ist der letzte Ausfall schon vergessen. Doch genau jetzt – wenn alles stabil wirkt – ist der beste Zeitpunkt, das Fundament für den Ernstfall zu legen.
Denn die zentrale Frage ist nicht ob etwas passiert, sondern wie gut Sie darauf vorbereitet sind.

Jetzt handeln – mit einem starken Partner an Ihrer Seite

Bei KNS – Kurfer Network Support unterstützen wir Unternehmen seit Jahren dabei, ihre IT-Infrastruktur nicht nur leistungsfähig, sondern auch krisenfest aufzustellen. Wir kombinieren technische Kompetenz mit strategischem Denken – für Lösungen, die nicht nur im Normalbetrieb, sondern auch im Ausnahmezustand funktionieren.

Ob Analyse Ihrer aktuellen Systeme, Erstellung eines individuellen Disaster-Recovery-Plans oder Aufbau einer resilienten Private-Cloud-Umgebung – wir begleiten Sie persönlich, verlässlich und lösungsorientiert.

 

Vereinbaren Sie ein unverbindliches Erstgespräch.

Gemeinsam klären wir, wie Ihr Unternehmen im Notfall handlungsfähig bleibt – ohne blinden Aktionismus, aber mit klarer Struktur.