Patch Management

Patch Management einfach erklärt

Patch Management bezeichnet den strukturierten Prozess zur Erfassung, Bewertung, Prüfung, Verteilung und Überwachung von Software- und Firmwareaktualisierungen.

Ziel ist es, bekannte Sicherheitslücken zu schließen, Fehler zu beheben und IT-Systeme stabil sowie unterstützt zu halten. Ein professionelles Patch Management reduziert die Zeit, in der Schwachstellen von Angreifern ausgenutzt werden können.

Was ist ein Patch?

Ein Patch ist eine Aktualisierung für ein Betriebssystem, eine Anwendung, eine Firmware oder eine andere Softwarekomponente.

Patches können verschiedene Zwecke erfüllen:

  • Sicherheitslücken schließen
  • Programmfehler beheben
  • Stabilität verbessern
  • Kompatibilitätsprobleme lösen
  • vorhandene Funktionen optimieren
  • Unterstützung neuer Komponenten ermöglichen

Nicht jedes Update ist sicherheitskritisch. Umgekehrt kann ein einzelner Sicherheits-Patch besonders dringend sein, wenn eine Schwachstelle bereits aktiv ausgenutzt wird.

Welche Systeme müssen berücksichtigt werden?

Patch Management beschränkt sich nicht auf Windows-Computer oder Server. Zu einer vollständigen Betrachtung gehören unter anderem:

  • Arbeitsplatzcomputer und Notebooks
  • Serverbetriebssysteme
  • Fach- und Standardanwendungen
  • Webbrowser und Erweiterungen
  • Datenbanken
  • Virtualisierungsplattformen
  • Netzwerkgeräte
  • Firewalls und VPN-Systeme
  • Drucker und Multifunktionsgeräte
  • Smartphones und Tablets
  • Cloud-Ressourcen
  • Firmware und BIOS beziehungsweise UEFI
  • IoT- und Produktionssysteme

Gerade Anwendungen von Drittanbietern werden häufig übersehen, obwohl auch sie kritische Schwachstellen enthalten können.

Wie funktioniert Patch Management?

Ein wirksamer Patch-Prozess besteht aus mehreren aufeinander abgestimmten Schritten.

1. Systeme inventarisieren

Zunächst muss bekannt sein, welche Geräte, Anwendungen und Versionen im Unternehmen eingesetzt werden.

Ohne ein aktuelles Inventar lässt sich nicht zuverlässig feststellen, welche Systeme von einer Schwachstelle betroffen sind.

2. Verfügbare Patches erfassen

Hersteller veröffentlichen regelmäßig Sicherheitsmeldungen, Updates und Hinweise zu bekannten Problemen.

Diese Informationen müssen zentral erfasst und den betroffenen Systemen zugeordnet werden.

3. Risiken bewerten

Patches sollten nicht ausschließlich anhand einer technischen Schweregradbewertung priorisiert werden.

Zusätzlich relevant sind:

  • wird die Schwachstelle bereits ausgenutzt?
  • ist ein Exploit öffentlich verfügbar?
  • ist das System aus dem Internet erreichbar?
  • welche Daten und Geschäftsprozesse sind betroffen?
  • bestehen bereits andere Schutzmaßnahmen?
  • welche Auswirkungen hätte ein Ausfall?

Ein öffentlich erreichbares System kann dringender sein als ein stärker bewerteter, aber vollständig isolierter Rechner.

4. Updates testen

Vor einer breiten Verteilung sollten wichtige Patches auf repräsentativen Testsystemen oder einer begrenzten Pilotgruppe geprüft werden.

Dabei wird unter anderem kontrolliert:

  • startet das System weiterhin?
  • funktionieren Anwendungen und Schnittstellen?
  • entstehen Leistungsprobleme?
  • bleiben Sicherheitsrichtlinien wirksam?
  • ist ein Neustart erforderlich?

Tests reduzieren Betriebsrisiken, dürfen kritische Sicherheitsupdates jedoch nicht unnötig lange verzögern.

5. Rollout planen

Nach der Freigabe werden die Patches automatisiert oder manuell verteilt.

Für den Rollout werden häufig Wartungsfenster, Gerätegruppen und unterschiedliche Prioritätsstufen definiert. Kritische Systeme können dabei in mehreren Wellen aktualisiert werden.

6. Installation überprüfen

Die reine Verteilung eines Updates bedeutet noch nicht, dass es erfolgreich installiert wurde.

Nach dem Rollout muss geprüft werden:

  • welche Systeme wurden erreicht?
  • war die Installation erfolgreich?
  • fehlen notwendige Neustarts?
  • sind Geräte dauerhaft offline?
  • treten Fehler oder Rücksetzungen auf?
  • bestehen weiterhin verwundbare Versionen?

Fehlgeschlagene Installationen benötigen einen geregelten Nachbearbeitungsprozess.

Was ist der Unterschied zwischen Patch und Update?

Die Begriffe werden häufig ähnlich verwendet.

Ein Patch behebt meist einen konkreten Fehler oder eine Sicherheitslücke. Ein Update kann zusätzlich größere Funktionsänderungen, neue Komponenten oder mehrere Patches enthalten.

Für das Patch Management ist die Bezeichnung weniger entscheidend als die Frage, welche Risiken und Auswirkungen die Aktualisierung besitzt.

Warum sind Wartungsfenster wichtig?

Patches können Neustarts, kurze Unterbrechungen oder unerwartete Kompatibilitätsprobleme verursachen.

Geplante Wartungsfenster ermöglichen es, Updates kontrolliert durchzuführen und Benutzer rechtzeitig zu informieren.

Bei besonders kritischen Schwachstellen kann es jedoch notwendig sein, ein außerplanmäßiges Notfall-Update einzuspielen. Für solche Fälle sollte ein eigener Emergency-Patching-Prozess bestehen.

Welche Rolle spielen Backups und Rollback?

Vor Änderungen an geschäftskritischen Systemen muss geklärt sein, wie sich der vorherige Zustand wiederherstellen lässt.

Mögliche Maßnahmen sind:

  • aktuelle und geprüfte Datensicherungen
  • dokumentierte Wiederherstellungsverfahren
  • Snapshots für geeignete Systeme
  • gesicherte Konfigurationen
  • Rückfallplan für fehlerhafte Updates
  • verfügbare Installationsmedien und Vorversionen

Ein Snapshot ist jedoch nicht automatisch ein vollständiges Backup und sollte nicht als einzige Wiederherstellungsstrategie verwendet werden.

Was passiert mit nicht patchbaren Systemen?

Manche Anwendungen oder Geräte können nicht kurzfristig aktualisiert werden. Gründe können fehlende Herstellerfreigaben, technische Abhängigkeiten oder das Ende des Supports sein.

Dann sind vorübergehende Schutzmaßnahmen erforderlich, beispielsweise:

  • Netzwerkzugriff einschränken
  • System segmentieren
  • nicht benötigte Dienste deaktivieren
  • administrative Zugänge begrenzen
  • zusätzliche Überwachung aktivieren
  • virtuelle Patches oder Firewall-Regeln einsetzen
  • Ersatz oder Migration planen

Solche Ausnahmen müssen dokumentiert, genehmigt und regelmäßig überprüft werden. Dauerhaft ungepatchte Systeme stellen ein erhebliches Risiko dar.

Welche Kennzahlen sind sinnvoll?

Unternehmen können die Wirksamkeit des Patch Managements mit Kennzahlen überwachen.

Dazu gehören beispielsweise:

  • Anteil vollständig gepatchter Systeme
  • Zeit bis zur Installation kritischer Patches
  • Anzahl fehlgeschlagener Installationen
  • Zahl nicht unterstützter Systeme
  • Umfang genehmigter Ausnahmen
  • Geräte ohne aktuelle Inventardaten

Eine hohe Installationsquote allein reicht jedoch nicht aus. Entscheidend ist, ob besonders gefährdete und geschäftskritische Systeme rechtzeitig geschützt wurden.

Fazit

Patch Management ist ein zentraler Bestandteil der IT-Sicherheit und des stabilen IT-Betriebs. Es sorgt dafür, dass verfügbare Aktualisierungen systematisch bewertet, getestet, verteilt und kontrolliert werden.

Ein wirksamer Prozess benötigt ein vollständiges Inventar, risikobasierte Priorisierung, automatisierte Verteilung, klare Wartungsfenster und eine zuverlässige Erfolgskontrolle. Nicht patchbare Systeme müssen durch zusätzliche Maßnahmen abgesichert und möglichst zeitnah ersetzt werden.

CSPM

CSPM: Cloud Security Posture Management einfach erklärt

CSPM steht für Cloud Security Posture Management. Der Begriff bezeichnet die kontinuierliche Überprüfung und Verbesserung der Sicherheitskonfiguration von Cloud-Umgebungen.

CSPM-Lösungen erkennen beispielsweise öffentlich erreichbare Speicher, zu offene Netzwerkregeln, fehlende Verschlüsselung oder Abweichungen von vorgegebenen Sicherheitsrichtlinien. Ziel ist es, Fehlkonfigurationen frühzeitig zu beheben und den Sicherheitszustand der Cloud dauerhaft transparent zu machen.

Was bedeutet Security Posture?

Die Security Posture beschreibt den aktuellen Sicherheitszustand einer IT-Umgebung. In der Cloud gehören dazu unter anderem:

  • Konfigurationen von Cloud-Ressourcen
  • Netzwerk- und Firewallregeln
  • Benutzerrollen und Berechtigungen
  • Verschlüsselungseinstellungen
  • Protokollierung und Überwachung
  • öffentlich erreichbare Dienste
  • Einhaltung interner Sicherheitsvorgaben

Da Cloud-Umgebungen laufend verändert werden, kann sich auch ihr Sicherheitszustand schnell ändern. Neue Ressourcen werden bereitgestellt, Zugriffsrechte angepasst oder Dienste anders konfiguriert.

CSPM überprüft diese Veränderungen kontinuierlich.

Wie funktioniert CSPM?

Eine CSPM-Lösung verbindet sich mit einer oder mehreren Cloud-Plattformen und erfasst die vorhandenen Ressourcen sowie deren Konfigurationen.

Anschließend vergleicht sie diese mit:

  • anerkannten Sicherheitsempfehlungen
  • technischen Benchmarks
  • gesetzlichen oder regulatorischen Anforderungen
  • internen Unternehmensrichtlinien
  • Vorgaben des jeweiligen Cloud-Anbieters

Erkannte Abweichungen werden als Sicherheitsbefunde dargestellt und nach Risiko oder Dringlichkeit priorisiert.

Welche Risiken erkennt CSPM?

Typische CSPM-Befunde sind:

  • öffentlich zugängliche Speicherbereiche
  • unnötig offene Netzwerkports
  • fehlende oder deaktivierte Verschlüsselung
  • unzureichende Protokollierung
  • nicht aktivierte Sicherheitsfunktionen
  • veraltete oder unsichere Konfigurationen
  • Cloud-Ressourcen ohne zuständige Person
  • Abweichungen von internen Richtlinien
  • unzureichend geschützte administrative Zugänge
  • falsch konfigurierte Datenbanken oder Webdienste

Ein CSPM-System kann außerdem Zusammenhänge zwischen mehreren Befunden sichtbar machen. Eine einzelne Fehlkonfiguration besitzt möglicherweise nur ein begrenztes Risiko, kann in Kombination mit einer öffentlichen Erreichbarkeit oder weitreichenden Berechtigungen jedoch kritisch werden.

Warum ist CSPM wichtig?

Cloud-Ressourcen können innerhalb weniger Minuten erstellt oder verändert werden. Dadurch entstehen neue Server, Datenbanken, Speicher, Schnittstellen und Netzwerkverbindungen deutlich schneller als in klassischen Rechenzentren.

Manuelle Sicherheitsprüfungen reichen in solchen dynamischen Umgebungen häufig nicht aus. Fehlkonfigurationen können lange unentdeckt bleiben oder nach einer bereits erfolgten Prüfung neu entstehen.

CSPM schafft deshalb eine kontinuierliche Übersicht über die Sicherheitslage und hilft Sicherheitsteams, relevante Probleme schneller zu erkennen.

Welche Aufgaben übernimmt CSPM?

Zu den zentralen Funktionen gehören:

Inventarisierung

CSPM erfasst vorhandene Cloud-Konten, Ressourcen und Dienste. Dadurch werden auch vergessene oder nicht ausreichend dokumentierte Systeme sichtbar.

Konfigurationsprüfung

Die Einstellungen der Cloud-Ressourcen werden automatisiert auf unsichere oder unerwünschte Konfigurationen untersucht.

Risikobewertung

Befunde werden nach Kritikalität priorisiert. Dabei können Erreichbarkeit, Datenzugriff, Berechtigungen und Bedeutung der betroffenen Ressource berücksichtigt werden.

Compliance-Prüfung

CSPM kann prüfen, ob festgelegte Sicherheitsstandards und Richtlinien eingehalten werden. Die Ergebnisse unterstützen Berichte und Audits, stellen aber allein noch keinen vollständigen Compliance-Nachweis dar.

Handlungsempfehlungen

Zu erkannten Problemen werden Hinweise zur sicheren Konfiguration oder konkrete Schritte zur Behebung bereitgestellt.

Automatisierte Korrektur

Bestimmte Fehlkonfigurationen können automatisiert korrigiert werden. Solche Eingriffe sollten kontrolliert getestet werden, da Änderungen den Betrieb einer Anwendung beeinflussen können.

Was ist der Unterschied zwischen CSPM und Schwachstellenmanagement?

CSPM konzentriert sich hauptsächlich auf die sichere Konfiguration von Cloud-Ressourcen.

Das klassische Schwachstellenmanagement sucht dagegen vor allem nach bekannten Sicherheitslücken in Betriebssystemen, Anwendungen, Bibliotheken oder Containern.

Beide Bereiche ergänzen sich:

  • CSPM erkennt beispielsweise einen öffentlich erreichbaren Server.
  • Ein Schwachstellenscanner erkennt eine ungepatchte Software auf diesem Server.

Die Kombination beider Informationen ermöglicht eine bessere Risikobewertung.

Was ist der Unterschied zwischen CSPM und CWPP?

Cloud Workload Protection Platforms, kurz CWPP, schützen laufende Workloads wie virtuelle Maschinen, Container und Serverless-Anwendungen.

CSPM bewertet hauptsächlich Konfigurationen und Richtlinien der Cloud-Plattform. CWPP überwacht stärker das Verhalten und die Sicherheit der tatsächlich ausgeführten Workloads.

Moderne Cloud-Sicherheitsplattformen kombinieren beide Funktionen häufig in einer umfassenderen Cloud-Native Application Protection Platform, kurz CNAPP.

Eignet sich CSPM für Multi-Cloud-Umgebungen?

CSPM ist besonders hilfreich, wenn ein Unternehmen mehrere Cloud-Konten, Abonnements oder Anbieter verwendet.

Eine zentrale Plattform kann Sicherheitsbefunde aus Umgebungen wie Microsoft Azure, Amazon Web Services oder Google Cloud zusammenführen. Dadurch lassen sich einheitliche Richtlinien und Prioritäten über verschiedene Plattformen hinweg umsetzen.

Die tatsächliche Abdeckung hängt jedoch von der jeweiligen CSPM-Lösung und den unterstützten Cloud-Diensten ab.

Welche Grenzen hat CSPM?

CSPM verbessert die Transparenz, ersetzt aber kein vollständiges Cloud-Sicherheitskonzept.

Die Lösung verhindert nicht automatisch:

  • kompromittierte Benutzerkonten
  • Schadsoftware auf Cloud-Servern
  • Sicherheitslücken in Anwendungen
  • unsicheren Programmcode
  • Datenmissbrauch durch berechtigte Benutzer
  • Fehler in Geschäftsprozessen
  • unzureichende Notfall- und Backup-Konzepte

Außerdem müssen Befunde fachlich bewertet werden. Nicht jede Abweichung besitzt im jeweiligen Unternehmenskontext die gleiche Bedeutung.

Fazit

Cloud Security Posture Management überwacht den Sicherheitszustand von Cloud-Umgebungen und erkennt unsichere Konfigurationen sowie Abweichungen von festgelegten Richtlinien.

CSPM schafft Transparenz über dynamische und komplexe Cloud-Infrastrukturen, unterstützt bei der Priorisierung von Risiken und erleichtert die kontinuierliche Umsetzung von Sicherheits- und Compliance-Vorgaben. Die Lösung sollte dabei mit Identitätsschutz, Schwachstellenmanagement, Workload-Schutz und einer geregelten Reaktion auf Sicherheitsvorfälle kombiniert werden.

Cloud-native

Cloud-native einfach erklärt

Cloud-native bezeichnet einen Ansatz zur Entwicklung und zum Betrieb von Anwendungen, der gezielt auf moderne Cloud-Umgebungen ausgerichtet ist. Cloud-native Anwendungen sollen flexibel skalierbar, automatisiert betreibbar und widerstandsfähig gegenüber Ausfällen sein.

Dabei geht es nicht nur darum, eine vorhandene Anwendung auf einen Cloud-Server zu verschieben. Architektur, Entwicklung, Bereitstellung und Betrieb werden von Anfang an an die Möglichkeiten der Cloud angepasst.

Was bedeutet cloud-native?

Eine cloud-native Anwendung nutzt typische Cloud-Prinzipien wie:

  • automatisierte Bereitstellung
  • flexible Skalierung
  • klar getrennte Komponenten
  • standardisierte Schnittstellen
  • kontinuierliche Überwachung
  • schnelle und regelmäßige Updates
  • automatisierte Wiederherstellung bei Fehlern

Die Anwendung wird so entworfen, dass einzelne Bestandteile möglichst unabhängig voneinander betrieben und verändert werden können.

Dadurch lassen sich neue Funktionen schneller bereitstellen und einzelne Komponenten gezielt skalieren, ohne die gesamte Anwendung anpassen zu müssen.

Ist eine Anwendung in der Cloud automatisch cloud-native?

Nein. Eine bestehende Anwendung kann auf eine virtuelle Maschine in der Cloud übertragen werden, ohne cloud-native zu sein.

Bei einer solchen Migration bleibt die ursprüngliche Architektur häufig weitgehend unverändert. Die Anwendung läuft dann zwar in einer Cloud-Umgebung, nutzt deren Möglichkeiten aber nur eingeschränkt.

Eine cloud-native Anwendung wird dagegen gezielt für flexible Ressourcen, Automatisierung und verteilte Systeme entwickelt oder entsprechend modernisiert.

Welche Merkmale haben cloud-native Anwendungen?

Cloud-native Architekturen können verschiedene Technologien und Arbeitsweisen kombinieren.

Microservices

Bei einer Microservices-Architektur wird eine Anwendung in kleinere, eigenständige Dienste unterteilt.

Jeder Dienst übernimmt eine klar definierte Aufgabe und kann unabhängig entwickelt, bereitgestellt und skaliert werden. Die Kommunikation erfolgt in der Regel über APIs oder Nachrichtendienste.

Microservices sind häufig Bestandteil cloud-nativer Anwendungen, aber keine zwingende Voraussetzung.

Container

Container bündeln eine Anwendung mit ihren benötigten Laufzeitkomponenten und Abhängigkeiten. Dadurch kann sie in unterschiedlichen Umgebungen weitgehend einheitlich ausgeführt werden.

Für die Verwaltung vieler Container werden häufig Plattformen wie Kubernetes eingesetzt.

Ein Container allein macht eine Anwendung jedoch noch nicht cloud-native. Entscheidend sind auch Architektur, Automatisierung und Betriebsmodell.

APIs

Über Programmierschnittstellen kommunizieren einzelne Dienste miteinander oder stellen Funktionen für andere Anwendungen bereit.

Klare und dokumentierte APIs erleichtern die Integration, Erweiterung und unabhängige Weiterentwicklung einzelner Komponenten.

DevOps und CI/CD

Cloud-native Entwicklung ist häufig eng mit DevOps verbunden. Entwicklung und IT-Betrieb arbeiten dabei eng zusammen und übernehmen gemeinsam Verantwortung für die Anwendung.

Über CI/CD-Pipelines können Änderungen automatisiert:

  • erstellt
  • getestet
  • geprüft
  • bereitgestellt
  • bei Problemen zurückgesetzt werden

CI/CD steht für Continuous Integration und Continuous Delivery beziehungsweise Continuous Deployment.

Infrastructure as Code

Bei Infrastructure as Code wird die benötigte Infrastruktur als maschinenlesbare Konfiguration beschrieben.

Server, Netzwerke, Zugriffsregeln und Plattformdienste können dadurch automatisiert und wiederholbar bereitgestellt werden. Änderungen lassen sich dokumentieren, prüfen und versionieren.

Automatische Skalierung

Cloud-native Anwendungen können ihre Ressourcen abhängig von der Auslastung anpassen.

Steigt die Zahl der Anfragen, werden zusätzliche Instanzen bereitgestellt. Sinkt die Auslastung, können nicht benötigte Ressourcen wieder reduziert werden.

Dies kann Leistung und Kosten verbessern, muss jedoch durch geeignete Grenzwerte und Überwachung kontrolliert werden.

Resilienz

Cloud-native Anwendungen werden so entworfen, dass der Ausfall einer einzelnen Komponente nicht automatisch zum Ausfall des gesamten Systems führt.

Mögliche Maßnahmen sind:

  • redundante Instanzen
  • automatische Neustarts
  • Verteilung auf mehrere Standorte
  • kontrollierte Zeitüberschreitungen
  • Wiederholungsmechanismen
  • Lastverteilung
  • Überwachung des Systemzustands

Welche Rolle spielen verwaltete Cloud-Dienste?

Cloud-native Anwendungen nutzen häufig verwaltete Dienste des Cloud-Anbieters.

Dazu können gehören:

  • Datenbanken
  • Identitätsdienste
  • Nachrichtensysteme
  • Monitoring-Plattformen
  • Objektspeicher
  • serverlose Funktionen
  • Sicherheits- und Protokollierungsdienste

Der Anbieter übernimmt dabei bestimmte Aufgaben wie Updates, Verfügbarkeit oder Skalierung der Plattform.

Dies reduziert den eigenen Betriebsaufwand, kann jedoch zu stärkeren Abhängigkeiten von einem Cloud-Anbieter führen.

Welche Vorteile bietet cloud-native?

Ein cloud-nativer Ansatz kann Unternehmen mehrere Vorteile bieten:

  • schnellere Bereitstellung neuer Funktionen
  • flexible Skalierung bei wechselnder Auslastung
  • höhere Ausfallsicherheit
  • automatisierte Entwicklungs- und Betriebsprozesse
  • unabhängige Weiterentwicklung einzelner Komponenten
  • bessere Unterstützung agiler Arbeitsweisen
  • effizientere Nutzung von Cloud-Ressourcen
  • schnellere Reaktion auf neue Anforderungen

Die Vorteile entstehen jedoch nicht automatisch. Cloud-native Systeme benötigen geeignete Architekturkenntnisse, klare Prozesse und eine leistungsfähige Überwachung.

Welche Herausforderungen gibt es?

Cloud-native Anwendungen können technisch und organisatorisch komplex sein.

Zu den typischen Herausforderungen gehören:

  • viele verteilte Komponenten
  • aufwendigere Überwachung und Fehlersuche
  • sichere Verwaltung von Identitäten und Schnittstellen
  • steigender Bedarf an Automatisierung
  • veränderte Aufgaben für Entwicklung und Betrieb
  • Kostenkontrolle bei dynamischen Ressourcen
  • Abhängigkeiten von Plattformdiensten
  • höhere Anforderungen an Fachwissen und Dokumentation

Nicht jede Anwendung muss deshalb vollständig cloud-native aufgebaut werden. Bei stabilen oder wenig veränderlichen Systemen kann eine einfachere Architektur wirtschaftlicher und leichter zu betreiben sein.

Wo können cloud-native Anwendungen betrieben werden?

Cloud-native ist nicht auf eine bestimmte Cloud-Form beschränkt.

Entsprechende Anwendungen können betrieben werden in:

  • Public Clouds
  • Private Clouds
  • Hybrid-Cloud-Umgebungen
  • Multi-Cloud-Umgebungen
  • lokalen Kubernetes- oder Containerplattformen

Entscheidend ist weniger der Standort als die konsequente Nutzung von Automatisierung, standardisierten Schnittstellen, flexiblen Ressourcen und modernen Betriebsprozessen.

Fazit

Cloud-native beschreibt einen modernen Ansatz zur Entwicklung und zum Betrieb von Anwendungen. Im Mittelpunkt stehen Automatisierung, Skalierbarkeit, Resilienz und die schnelle Bereitstellung von Änderungen.

Technologien wie Microservices, Container, APIs, CI/CD und Infrastructure as Code unterstützen diesen Ansatz. Sie sind jedoch keine Garantie dafür, dass eine Anwendung tatsächlich cloud-native ist. Entscheidend ist das Zusammenspiel aus Architektur, Technologie und Arbeitsweise.

Azure AD Connect (Legacy)

Azure AD Connect (Legacy)

Azure AD Connect (Legacy) ist ein Microsoft-Werkzeug zur Synchronisierung von Identitäten zwischen einer lokalen Windows Server Active Directory-Umgebung und Microsoft Entra ID, ehemals Azure Active Directory. Es war über viele Jahre ein zentraler Baustein für hybride Identitätslösungen und ermöglichte die Verbindung lokaler Verzeichnisdienste mit Cloud-Diensten wie Microsoft 365 und Azure.

Mit Azure AD Connect konnten Unternehmen Benutzerkonten, Gruppen und ausgewählte Attribute automatisch zwischen dem lokalen Active Directory und der Cloud synchronisieren. Dadurch entstand ein einheitliches Identitätsmanagement, bei dem sich Benutzer mit denselben Anmeldedaten sowohl lokal als auch in Cloud-Anwendungen anmelden konnten.

Wofür wurde Azure AD Connect eingesetzt?

Azure AD Connect wurde vor allem genutzt, um hybride IT-Umgebungen aufzubauen. Viele Unternehmen betreiben weiterhin lokale Active Directory-Strukturen, möchten aber gleichzeitig Cloud-Dienste wie Microsoft 365, Exchange Online, SharePoint Online oder Teams verwenden.

Das Tool stellte die notwendige Verbindung zwischen On-Premises-Identitäten und Microsoft Entra ID her. Dadurch konnten vorhandene Benutzerkonten weiterverwendet werden, ohne Identitäten vollständig neu in der Cloud anlegen zu müssen.

Typische Einsatzbereiche waren:

  • Synchronisierung von Benutzern, Gruppen und Attributen
  • Aufbau einer Hybrid Identity-Umgebung
  • einheitliche Anmeldung an lokalen und cloudbasierten Diensten
  • Unterstützung von Microsoft 365- und Azure-Szenarien
  • Integration bestehender Active Directory-Strukturen in die Cloud

Authentifizierungsmodelle mit Azure AD Connect

Azure AD Connect unterstützte verschiedene Authentifizierungsmodelle, mit denen Unternehmen ihre Identitätsstrategie an technische und organisatorische Anforderungen anpassen konnten.

Password Hash Sync:
Bei diesem Modell werden Passwort-Hashes aus dem lokalen Active Directory mit Microsoft Entra ID synchronisiert. Benutzer können sich anschließend mit ihren bekannten Anmeldedaten an Cloud-Diensten anmelden.

Pass-through Authentication:
Bei der Pass-through Authentication erfolgt die Prüfung der Anmeldedaten weiterhin gegen das lokale Active Directory. Die Cloud-Anmeldung wird dabei über einen lokalen Agenten validiert.

AD FS-Integration:
Für komplexere Single-Sign-on-Szenarien konnte Azure AD Connect auch mit Active Directory Federation Services kombiniert werden. AD FS wurde häufig eingesetzt, wenn Unternehmen besondere Anforderungen an Authentifizierung, Richtlinien oder Federation hatten.

Warum gilt Azure AD Connect als Legacy?

Azure AD Connect wird heute häufig als klassische oder Legacy-Lösung betrachtet, weil Microsoft zunehmend modernere Synchronisationsansätze wie Microsoft Entra Cloud Sync in den Vordergrund stellt. Diese cloudbasierten Alternativen reduzieren den lokalen Verwaltungsaufwand und sind stärker auf moderne Identity- und Zero-Trust-Strategien ausgerichtet.

Azure AD Connect ist dennoch weiterhin in vielen Unternehmen im Einsatz. Das gilt besonders für Organisationen mit komplexen Active Directory-Strukturen, individuellen Synchronisationsregeln, mehreren Gesamtstrukturen oder besonderen Compliance-Anforderungen.

Herausforderungen im Betrieb

Der Betrieb von Azure AD Connect erforderte lokale Infrastruktur, regelmäßige Wartung und administrative Pflege. Dazu gehörten unter anderem Updates, Monitoring, Fehleranalyse, Synchronisationsprüfungen und die Absicherung der beteiligten Systeme.

Gerade für kleine und mittelständische Unternehmen konnte diese Komplexität zur Herausforderung werden. Fehlerhafte Synchronisationen, veraltete Installationen oder nicht sauber gepflegte Konfigurationen konnten Auswirkungen auf Benutzeranmeldungen, Berechtigungen und den Zugriff auf Cloud-Dienste haben.

Auch Sicherheitsaspekte spielten eine wichtige Rolle. Alte oder nicht aktualisierte Installationen können Risiken erzeugen, insbesondere wenn sie mit privilegierten Konten, sensiblen Verzeichnisdaten oder kritischen Authentifizierungsprozessen verbunden sind.

Azure AD Connect und moderne Alternativen

Mit Microsoft Entra Cloud Sync steht eine modernere Alternative zur Verfügung, die viele Synchronisationsaufgaben schlanker und cloudnäher abbildet. Cloud Sync nutzt leichtgewichtigere Agenten und reduziert den Administrationsaufwand im Vergleich zu klassischen Azure AD Connect-Installationen.

Ein Wechsel ist jedoch nicht in jedem Fall sofort möglich. Unternehmen mit komplexen Anforderungen müssen sorgfältig prüfen, welche Funktionen benötigt werden und ob diese durch moderne Alternativen vollständig abgedeckt werden.

Bedeutung für IT-Dienstleister

Für IT-Dienstleister bleibt Azure AD Connect ein wichtiges Thema im Betrieb hybrider Microsoft-Umgebungen. Viele Kunden nutzen weiterhin lokale Active Directory-Strukturen und benötigen eine stabile, sichere und nachvollziehbare Verbindung zur Cloud.

Typische Aufgaben von IT-Dienstleistern sind:

  • Überprüfung bestehender Azure AD Connect-Installationen
  • Aktualisierung und Absicherung der Synchronisationsumgebung
  • Analyse von Synchronisationsfehlern
  • Planung von Migrationen zu Microsoft Entra Cloud Sync
  • Beratung zu Hybrid Identity und Zero-Trust-Strategien

Fazit

Azure AD Connect war lange Zeit das zentrale Werkzeug für hybride Identitätslösungen zwischen lokalem Active Directory und Microsoft Entra ID. Es ermöglichte Unternehmen, bestehende Identitäten weiterzuverwenden und nahtlos mit Microsoft-Cloud-Diensten zu verbinden.

Auch wenn moderne Alternativen zunehmend an Bedeutung gewinnen, bleibt Azure AD Connect in vielen IT-Umgebungen relevant. Entscheidend ist, bestehende Installationen regelmäßig zu prüfen, sicher zu betreiben und langfristig eine passende Migrationsstrategie zu entwickeln.

Conditional Access

Conditional Access: bedingten Zugriff einfach erklärt

Conditional Access, auf Deutsch bedingter Zugriff, steuert den Zugriff auf Anwendungen und Daten anhand festgelegter Bedingungen. Dabei wird nicht nur geprüft, wer sich anmeldet, sondern auch, von welchem Gerät, aus welchem Netzwerk und unter welchem Risiko der Zugriff erfolgt.

Im Microsoft-Umfeld ist Conditional Access eine Funktion von Microsoft Entra ID. Unternehmen können damit festlegen, wann ein Zugriff erlaubt, blockiert oder nur nach einer zusätzlichen Sicherheitsprüfung freigegeben wird.

Wie funktioniert Conditional Access?

Conditional Access arbeitet nach einem Wenn-Dann-Prinzip:

Wenn bestimmte Bedingungen erfüllt sind, dann wird eine festgelegte Zugriffsregel angewendet.

Ein Beispiel:

Wenn sich ein Benutzer von einem nicht verwalteten Gerät bei einer sensiblen Cloud-Anwendung anmeldet, muss er eine Multi-Faktor-Authentifizierung durchführen oder der Zugriff wird blockiert.

Microsoft Entra wertet die zutreffenden Richtlinien aus und prüft, ob alle geforderten Zugriffsbedingungen erfüllt sind.

Welche Bedingungen können berücksichtigt werden?

Eine Conditional-Access-Richtlinie kann verschiedene Signale und Bedingungen einbeziehen.

Benutzer und Gruppen

Richtlinien können für bestimmte Personen, Gruppen oder Verzeichnisrollen gelten. Administratoren lassen sich beispielsweise strenger absichern als normale Benutzer.

Anwendung oder Ressource

Die Richtlinie legt fest, welche Anwendung oder Ressource geschützt werden soll. Dazu können Microsoft 365, Azure-Dienste und angebundene Unternehmensanwendungen gehören.

Netzwerk und Standort

IP-Adressen, Länder, Regionen oder definierte Unternehmensnetzwerke können bei der Entscheidung berücksichtigt werden.

Ein Standort allein ist jedoch kein zuverlässiger Vertrauensnachweis. Auch Zugriffe aus einem bekannten Netzwerk sollten durch weitere Sicherheitsmerkmale geschützt werden.

Gerätezustand

Der Zugriff kann davon abhängig gemacht werden, ob ein Gerät:

  • vom Unternehmen verwaltet wird
  • als konform eingestuft ist
  • einer bestimmten Geräteplattform angehört
  • bestimmte technische Merkmale erfüllt

Die Bewertung des Gerätezustands erfolgt häufig in Verbindung mit einer Geräteverwaltung wie Microsoft Intune.

Anmelderisiko

Bei entsprechender Lizenzierung können erkannte Risiken in die Entscheidung einbezogen werden. Hinweise auf ein erhöhtes Risiko können beispielsweise ungewöhnliche Anmeldeaktivitäten oder kompromittierte Zugangsdaten sein.

Verwendete Anwendung

Richtlinien können unterscheiden, ob der Zugriff über einen Webbrowser, eine mobile App oder einen Desktop-Client erfolgt.

Welche Zugriffsmaßnahmen gibt es?

Treffen die festgelegten Bedingungen zu, kann Conditional Access unterschiedliche Maßnahmen verlangen.

Typische Maßnahmen sind:

  • Zugriff vollständig blockieren
  • Multi-Faktor-Authentifizierung verlangen
  • eine bestimmte Authentifizierungsstärke fordern
  • ein konformes Gerät voraussetzen
  • ein verwaltetes oder hybrid eingebundenes Gerät verlangen
  • Nutzungsbedingungen bestätigen lassen
  • Sitzungsdauer oder Zugriffsmöglichkeiten einschränken

Mehrere Anforderungen können miteinander kombiniert werden.

Typische Einsatzbeispiele

Conditional Access wird häufig für folgende Szenarien eingesetzt:

  • Administratoren müssen eine besonders starke Authentifizierung verwenden.
  • Veraltete Anmeldeverfahren werden blockiert.
  • Sensible Anwendungen dürfen nur mit verwalteten Geräten genutzt werden.
  • Zugriffe aus bestimmten Ländern werden eingeschränkt.
  • Externe Benutzer erhalten nur Zugriff auf ausgewählte Anwendungen.
  • Bei riskanten Anmeldungen wird eine zusätzliche Prüfung verlangt.
  • Nicht konforme Geräte dürfen Daten anzeigen, aber nicht herunterladen.

Die Richtlinien sollten zum tatsächlichen Schutzbedarf des Unternehmens passen. Zu viele oder widersprüchliche Regeln können Benutzer unnötig behindern und die Administration erschweren.

Was ist der Unterschied zwischen Conditional Access und MFA?

Die Multi-Faktor-Authentifizierung ist eine mögliche Sicherheitsanforderung. Conditional Access entscheidet dagegen, unter welchen Bedingungen diese Anforderung gilt.

MFA kann beispielsweise grundsätzlich für alle Benutzer vorgeschrieben werden. Mit Conditional Access lässt sich die Regel genauer steuern, etwa abhängig von Anwendung, Gerätezustand, Benutzerrolle oder Risiko.

Conditional Access ersetzt MFA daher nicht, sondern ermöglicht deren gezielten Einsatz.

Welche Rolle spielt Conditional Access bei Zero Trust?

Conditional Access ist ein wichtiger Bestandteil einer Zero-Trust-Strategie.

Zero Trust geht davon aus, dass kein Zugriff allein aufgrund des Standorts oder eines bereits bekannten Geräts automatisch vertrauenswürdig ist. Stattdessen werden Identität, Ressource, Gerät und Kontext geprüft.

Conditional Access setzt dieses Prinzip technisch um, indem Zugriffe anhand aktueller Signale bewertet und geeignete Sicherheitsanforderungen durchgesetzt werden.

Was ist bei der Einführung zu beachten?

Fehlerhaft konfigurierte Richtlinien können Benutzer und Administratoren vollständig aussperren. Deshalb sollten neue Regeln kontrolliert eingeführt werden.

Wichtige Maßnahmen sind:

  • klare Ziele für jede Richtlinie definieren
  • Richtlinien zunächst im Nur-Bericht-Modus testen
  • Auswirkungen in den Anmeldeprotokollen überprüfen
  • Notfallkonten sinnvoll von bestimmten Regeln ausnehmen
  • Richtlinien schrittweise für Benutzergruppen aktivieren
  • Ausnahmen dokumentieren und regelmäßig kontrollieren
  • bestehende Regeln regelmäßig bereinigen
  • Änderungen und Verantwortlichkeiten dokumentieren

Notfallkonten dürfen nicht für normale administrative Tätigkeiten verwendet werden und müssen besonders überwacht werden.

Fazit

Conditional Access ermöglicht eine kontextabhängige Steuerung von Zugriffen auf Cloud-Anwendungen und Unternehmensressourcen. Dabei können unter anderem Benutzer, Anwendung, Netzwerk, Gerät und Anmelderisiko berücksichtigt werden.

Richtig eingesetzt verbindet bedingter Zugriff hohe Sicherheitsanforderungen mit einer möglichst reibungslosen Benutzererfahrung. Voraussetzung sind sorgfältig geplante, getestete und regelmäßig überprüfte Richtlinien.

Managed Identity

Managed Identity in Azure einfach erklärt

Eine Managed Identity, auf Deutsch verwaltete Identität, ermöglicht Azure-Ressourcen die sichere Authentifizierung gegenüber anderen Diensten. Anwendungen benötigen dafür keine dauerhaft gespeicherten Passwörter, Zertifikate oder Anwendungsschlüssel.

Azure verwaltet die zugrunde liegende Identität und stellt bei Bedarf ein zeitlich begrenztes Zugriffstoken aus. Welche Ressourcen und Funktionen die Anwendung nutzen darf, wird anschließend über Rollen und Berechtigungen geregelt.

Was ist eine Managed Identity?

Eine Managed Identity ist eine digitale Identität für eine Anwendung, einen Dienst oder eine Azure-Ressource. Sie gehört zur Gruppe der sogenannten Workload-Identitäten und wird nicht von einer natürlichen Person verwendet.

Managed Identities können beispielsweise für folgende Azure-Ressourcen aktiviert werden:

  • virtuelle Maschinen
  • Azure App Service
  • Azure Functions
  • Logic Apps
  • Automation Accounts
  • bestimmte Daten- und Integrationsdienste

Die Anwendung kann sich anschließend gegenüber Diensten authentifizieren, die Microsoft Entra ID unterstützen.

Wie funktioniert eine Managed Identity?

Eine Azure-Ressource erhält eine verwaltete Identität in Microsoft Entra ID. Benötigt die darauf ausgeführte Anwendung Zugriff auf einen anderen Dienst, fordert sie ein Zugriffstoken für diese Zielressource an.

Der Ablauf besteht vereinfacht aus folgenden Schritten:

  1. Für die Anwendung oder Azure-Ressource wird eine Managed Identity aktiviert.
  2. Die Identität erhält Berechtigungen auf der benötigten Zielressource.
  3. Die Anwendung fordert ein Zugriffstoken von Azure an.
  4. Das Token wird an den Zieldienst übermittelt.
  5. Der Zieldienst prüft Identität und Berechtigungen.
  6. Der Zugriff wird erlaubt oder abgelehnt.

Im Anwendungscode müssen dafür keine dauerhaften Zugangsdaten hinterlegt werden.

Welche Arten von Managed Identities gibt es?

Azure unterscheidet zwei grundlegende Varianten.

System-assigned Managed Identity

Eine systemseitig zugewiesene Managed Identity ist direkt mit einer bestimmten Azure-Ressource verbunden.

Wird beispielsweise eine virtuelle Maschine gelöscht, wird auch ihre Managed Identity entfernt. Diese Variante eignet sich, wenn die Identität ausschließlich von einer einzelnen Ressource benötigt wird.

Vorteile sind:

  • einfache Aktivierung
  • eindeutige Zuordnung zu einer Ressource
  • gemeinsamer Lebenszyklus von Ressource und Identität

Wird die Ressource neu erstellt, entsteht allerdings eine neue Identität. Vorherige Berechtigungen müssen dann erneut zugewiesen werden.

User-assigned Managed Identity

Eine benutzerseitig zugewiesene Managed Identity wird als eigenständige Azure-Ressource angelegt.

Sie kann mehreren unterstützten Azure-Ressourcen zugewiesen werden und bleibt bestehen, wenn eine davon gelöscht wird.

Diese Variante eignet sich beispielsweise für:

  • mehrere Anwendungen mit denselben Berechtigungen
  • wiederkehrende Bereitstellungen
  • automatisierte Infrastruktur
  • getrennte Lebenszyklen von Anwendung und Identität
  • Umgebungen mit austauschbaren Rechenressourcen

Gemeinsam verwendete Identitäten können die Verwaltung vereinfachen. Sie erschweren jedoch unter Umständen die Zuordnung einzelner Aktivitäten zu einer bestimmten Anwendung.

Managed Identity und RBAC

Die Managed Identity weist nach, wer auf eine Ressource zugreifen möchte. Sie bestimmt jedoch nicht automatisch, was erlaubt ist.

Die Berechtigungen werden häufig über Azure Role-Based Access Control, kurz Azure RBAC, vergeben.

Eine Identität kann beispielsweise folgende Rollen erhalten:

  • Leserechte auf einen Storage Account
  • Zugriff auf bestimmte Key-Vault-Inhalte
  • Schreibrechte auf eine Datenressource
  • Berechtigungen zur Verwaltung ausgewählter Azure-Ressourcen

Einige Dienste verwenden zusätzlich eigene Berechtigungsmodelle. Deshalb muss für jede Zielressource geprüft werden, welche Form der Autorisierung unterstützt wird.

Unterschied zwischen Managed Identity und Service Principal

Ein Service Principal ist eine Identität, die eine Anwendung in einem Microsoft-Entra-Mandanten repräsentiert. Für klassische Service Principals müssen häufig Zertifikate, Secrets oder föderierte Anmeldedaten eingerichtet werden.

Eine Managed Identity ist technisch eine besondere Art von Service Principal, deren Zugangsdaten von Azure verwaltet werden.

Dadurch entfällt insbesondere:

  • das Speichern von Secrets
  • die manuelle Rotation von Anwendungsschlüsseln
  • die Verteilung von Zugangsdaten an Anwendungen
  • die Überwachung ablaufender Kennwörter oder Zertifikate

Managed Identities sind jedoch an unterstützte Azure-Szenarien gebunden. Für Anwendungen außerhalb von Azure kann beispielsweise Workload Identity Federation geeigneter sein.

Typische Anwendungsfälle

Managed Identities werden häufig für die Kommunikation zwischen Azure-Diensten eingesetzt.

Beispiele sind:

  • Eine Azure Function liest ein Zertifikat aus Azure Key Vault.
  • Ein App Service greift auf Daten in Azure Storage zu.
  • Eine virtuelle Maschine schreibt Protokolle in einen Azure-Dienst.
  • Eine Logic App ruft eine geschützte Azure-Ressource auf.
  • Ein Automatisierungsdienst verwaltet ausgewählte Cloud-Ressourcen.

Dabei ersetzt die Managed Identity die Zugangsdaten der aufrufenden Anwendung. Ein in Key Vault gespeichertes Datenbankpasswort bleibt beispielsweise weiterhin ein Secret – die Anwendung benötigt jedoch kein zusätzliches Secret, um auf den Key Vault zuzugreifen.

Managed Identity in Kubernetes und CI/CD

Für Anwendungen in Azure Kubernetes Service wird in der Regel Microsoft Entra Workload ID verwendet. Dabei wird ein Kubernetes-Servicekonto über eine föderierte Vertrauensstellung mit einer Identität in Microsoft Entra ID verbunden.

Auch bei extern betriebenen CI/CD-Plattformen wie GitHub Actions ist Workload Identity Federation häufig geeigneter als ein gespeichertes Client Secret.

Eine Managed Identity kann direkt genutzt werden, wenn der Build-Agent oder die Automatisierung auf einer unterstützten Azure-Ressource ausgeführt wird.

Welche Vorteile bieten Managed Identities?

Zu den wichtigsten Vorteilen gehören:

  • keine dauerhaften Zugangsdaten im Quellcode
  • weniger Secrets in Konfigurationsdateien
  • keine manuelle Rotation von Identitätsnachweisen
  • einfache Integration mit Azure-Diensten
  • automatisierbare Bereitstellung
  • Unterstützung des Least-Privilege-Prinzips
  • geringeres Risiko versehentlich veröffentlichter Schlüssel

Managed Identities unterstützen damit cloud-native und automatisierte Betriebsmodelle.

Welche Grenzen und Risiken gibt es?

Managed Identities lösen nicht alle Sicherheitsprobleme.

Zu beachten ist:

  • Nicht jeder Dienst unterstützt Microsoft-Entra-Authentifizierung.
  • Berechtigungen müssen weiterhin korrekt vergeben werden.
  • Zu weitreichende Rollen erhöhen das Schadenspotenzial.
  • Wer eine Azure-Ressource kompromittiert, kann möglicherweise deren Identität missbrauchen.
  • Gemeinsam genutzte Identitäten erschweren teilweise die Nachvollziehbarkeit.
  • Rollenänderungen können eine gewisse Zeit benötigen, bis sie wirksam sind.

Managed Identities sollten deshalb mit minimalen Berechtigungen, Netzwerkbeschränkungen, Protokollierung und regelmäßigen Zugriffsprüfungen kombiniert werden.

Fazit

Eine Managed Identity ermöglicht Azure-Anwendungen die Authentifizierung gegenüber anderen Diensten, ohne dauerhaft gespeicherte Passwörter, Zertifikate oder Anwendungsschlüssel zu benötigen.

Azure verwaltet die Identität und die benötigten Anmeldeinformationen. Unternehmen bleiben jedoch dafür verantwortlich, passende Rollen zu vergeben, Zugriffe zu überwachen und Berechtigungen auf das notwendige Minimum zu begrenzen.

Hybrid Cloud

Hybrid Cloud einfach erklärt

Eine Hybrid Cloud verbindet lokale IT-Systeme oder eine Private Cloud mit Diensten aus einer Public Cloud. Beide Umgebungen bleiben technisch eigenständig, werden aber durch Netzwerke, Identitäten, Verwaltungswerkzeuge und gemeinsame Prozesse miteinander verbunden.

Unternehmen können dadurch lokale Systeme weiterbetreiben und gleichzeitig Cloud-Dienste für zusätzliche Rechenleistung, Datenspeicherung, Datensicherung oder moderne Anwendungen nutzen.

Wie funktioniert eine Hybrid Cloud?

Bei einer Hybrid Cloud werden lokale und cloudbasierte Ressourcen so miteinander verbunden, dass sie gemeinsam genutzt und verwaltet werden können.

Ein Unternehmen kann beispielsweise:

  • eine Warenwirtschaft im eigenen Rechenzentrum betreiben
  • Microsoft 365 als Cloud-Dienst verwenden
  • lokale Server zentral über eine Cloud-Plattform überwachen
  • Backups zusätzlich in einem Cloud-Speicher ablegen
  • Cloud-Ressourcen für Entwicklungs- und Testumgebungen nutzen
  • Anwendungen in der Cloud mit lokalen Datenbanken verbinden

Für die Kommunikation zwischen den Umgebungen werden meist verschlüsselte VPN-Verbindungen oder dedizierte Netzwerkverbindungen eingesetzt.

Welche Bestandteile gehören zu einer Hybrid Cloud?

Eine hybride Cloud-Umgebung kann verschiedene Komponenten verbinden:

  • lokale physische und virtuelle Server
  • eine Private-Cloud-Plattform
  • Public-Cloud-Dienste
  • Cloud-Anwendungen
  • zentrale Identitäts- und Zugriffsverwaltung
  • Netzwerk- und Sicherheitslösungen
  • Backup- und Disaster-Recovery-Dienste
  • zentrale Überwachung und Protokollierung

Welche Komponenten eingesetzt werden, hängt von den Anwendungen, Sicherheitsanforderungen und der bestehenden IT-Infrastruktur ab.

Was ist der Unterschied zwischen Public, Private und Hybrid Cloud?

Public Cloud

Bei einer Public Cloud stellt ein Anbieter standardisierte IT-Ressourcen für mehrere Kunden bereit. Die einzelnen Kundenumgebungen werden logisch voneinander getrennt.

Bekannte Public-Cloud-Plattformen sind Microsoft Azure, Amazon Web Services und Google Cloud.

Private Cloud

Eine Private Cloud wird ausschließlich für eine Organisation betrieben. Sie kann sich im eigenen Rechenzentrum oder bei einem externen Dienstleister befinden.

Im Unterschied zu einer klassischen Serverumgebung bietet eine Private Cloud typischerweise automatisierte Bereitstellung, zentrale Verwaltung und flexibel zuweisbare Ressourcen.

Hybrid Cloud

Eine Hybrid Cloud kombiniert lokale oder private Infrastrukturen mit Public-Cloud-Diensten. Entscheidend ist, dass die Umgebungen nicht nur parallel existieren, sondern technisch oder organisatorisch miteinander verbunden sind.

Können Anwendungen beliebig zwischen den Umgebungen verschoben werden?

Nicht automatisch.

Ob eine Anwendung zwischen lokaler Infrastruktur und Public Cloud verschoben werden kann, hängt unter anderem ab von:

  • ihrer technischen Architektur
  • verwendeten Datenbanken und Plattformdiensten
  • vorhandenen Schnittstellen
  • Netzwerkverbindungen
  • Datenmengen und Latenzanforderungen
  • Softwarelizenzen
  • Sicherheits- und Compliance-Vorgaben

Anwendungen, die speziell für eine bestimmte Cloud-Plattform entwickelt wurden, lassen sich möglicherweise nicht ohne Anpassungen lokal betreiben. Eine hybride Architektur muss deshalb gezielt geplant werden.

Welche Vorteile bietet eine Hybrid Cloud?

Eine Hybrid Cloud kann Unternehmen mehrere Vorteile bieten:

Bestehende Systeme weiter nutzen

Nicht alle Anwendungen müssen sofort in die Cloud migriert werden. Unternehmen können vorhandene Systeme weiterbetreiben und neue Cloud-Dienste schrittweise integrieren.

Flexible Ressourcen

Zusätzliche Rechen- oder Speicherkapazitäten können bei Bedarf aus der Cloud bezogen werden. Ob eine kurzfristige Auslagerung von Lastspitzen möglich ist, hängt jedoch von der jeweiligen Anwendung ab.

Lokale Datenverarbeitung

Daten können lokal verarbeitet werden, wenn niedrige Latenzzeiten, technische Abhängigkeiten oder organisatorische Vorgaben dies erfordern.

Moderne Cloud-Dienste

Unternehmen können Cloud-Dienste für Analyse, künstliche Intelligenz, Datensicherung, Identitätsmanagement oder Softwareentwicklung verwenden, ohne ihre gesamte IT-Infrastruktur zu verlagern.

Schrittweise Cloud-Migration

Eine Hybrid Cloud ermöglicht einen kontrollierten Übergang. Anwendungen können einzeln bewertet, modernisiert und bei Bedarf in die Cloud migriert werden.

Welche Herausforderungen gibt es?

Eine hybride Infrastruktur kann komplexer sein als eine ausschließlich lokale oder vollständig cloudbasierte Umgebung.

Typische Herausforderungen sind:

  • unterschiedliche Verwaltungsplattformen
  • sichere Verbindung der Umgebungen
  • einheitliche Benutzer- und Rechteverwaltung
  • Überwachung verteilter Ressourcen
  • Abhängigkeiten zwischen Anwendungen
  • Datenschutz und Datenklassifizierung
  • Kostenkontrolle
  • Datensicherung über mehrere Plattformen
  • klare Zuständigkeiten zwischen Anbieter und Unternehmen

Ohne einheitliche Standards können parallele Werkzeuge, doppelte Prozesse und unübersichtliche Berechtigungen entstehen.

Welche Technologien werden eingesetzt?

Für Aufbau und Betrieb hybrider Umgebungen kommen unterschiedliche Technologien infrage.

Dazu gehören beispielsweise:

  • VPN und dedizierte Cloud-Verbindungen
  • Microsoft Azure Arc
  • Azure Local
  • AWS Outposts
  • Container und Kubernetes
  • zentrale Identitätsplattformen
  • Infrastructure as Code
  • zentrale Monitoring- und Sicherheitslösungen

Azure Arc kann beispielsweise Ressourcen außerhalb von Azure in die Azure-Verwaltung einbinden. Solche Plattformen vereinfachen die Verwaltung, ersetzen aber nicht die technische Planung und Absicherung der hybriden Infrastruktur.

Für welche Unternehmen eignet sich eine Hybrid Cloud?

Eine Hybrid Cloud eignet sich besonders für Unternehmen, die:

  • weiterhin lokale Fachanwendungen benötigen
  • bestehende Rechenzentrumsinvestitionen nutzen möchten
  • schrittweise in die Cloud wechseln
  • mehrere Standorte oder Edge-Systeme betreiben
  • besondere Latenzanforderungen besitzen
  • lokale und cloudbasierte Datenverarbeitung kombinieren
  • moderne Cloud-Dienste in vorhandene Systeme integrieren möchten

Nicht jedes Unternehmen benötigt jedoch eine komplexe Hybrid-Cloud-Architektur. Bei überwiegend standardisierten Anwendungen kann eine weitgehend cloudbasierte Umgebung einfacher zu betreiben sein.

Fazit

Eine Hybrid Cloud verbindet lokale oder private IT-Infrastrukturen mit Public-Cloud-Diensten. Unternehmen können dadurch bestehende Systeme weiterverwenden und gleichzeitig flexible Cloud-Ressourcen und moderne Plattformdienste nutzen.

Damit die verschiedenen Umgebungen sicher und zuverlässig zusammenarbeiten, müssen Netzwerk, Identitäten, Berechtigungen, Datensicherung und Überwachung einheitlich geplant werden.

Weitere Informationen finden Sie auf unserer Leistungsseite zum Cloud Computing.

Cloud & Identitätsmanagement

Cloud- und Identitätsmanagement einfach erklärt

Cloud- und Identitätsmanagement bezeichnet die zentrale Verwaltung von Benutzerkonten, digitalen Identitäten und Zugriffsrechten in Cloud- und Hybridumgebungen.

Ziel ist es, sicherzustellen, dass Benutzer nur auf die Anwendungen, Daten und Systeme zugreifen können, die sie für ihre Aufgaben benötigen. Dabei spielt es keine Rolle, ob Mitarbeitende im Büro, im Homeoffice oder unterwegs arbeiten.

Was ist Cloud-Identitätsmanagement?

Eine digitale Identität bildet einen Benutzer, ein Gerät, eine Anwendung oder einen technischen Dienst innerhalb einer IT-Umgebung ab.

Zu einer Benutzeridentität gehören beispielsweise:

  • Benutzername und Kontaktdaten
  • Abteilung und Position
  • Gruppenmitgliedschaften
  • Rollen und Berechtigungen
  • registrierte Geräte
  • verwendete Authentifizierungsmethoden
  • Zugriff auf Anwendungen und Daten

Eine zentrale Identitätsplattform verwaltet diese Informationen und prüft bei jeder Anmeldung, wer auf welche Ressource zugreifen darf.

Bekannte Lösungen sind unter anderem Microsoft Entra ID, Okta und Ping Identity.

Welche Aufgaben übernimmt das Identitätsmanagement?

Cloud-Identitätsmanagement umfasst mehr als das Anlegen und Löschen von Benutzerkonten.

Zu den wichtigsten Aufgaben gehören:

  • Benutzerkonten zentral verwalten
  • Zugriffsrechte vergeben und entziehen
  • Anmeldungen absichern
  • Anwendungen mit einer zentralen Identität verbinden
  • Geräte und Standorte bei Zugriffsentscheidungen berücksichtigen
  • administrative Konten besonders schützen
  • Zugriffe protokollieren und überprüfen
  • Benutzer beim Ein- und Austritt automatisiert verwalten

Damit bildet das Identitätsmanagement eine zentrale Sicherheitsinstanz zwischen Benutzern und Unternehmensressourcen.

Was ist der Unterschied zwischen Authentifizierung und Autorisierung?

Bei der Authentifizierung wird geprüft, ob ein Benutzer tatsächlich die Person ist, für die er sich ausgibt. Dies kann beispielsweise durch ein Passwort, eine Authenticator-App oder einen Sicherheitsschlüssel erfolgen.

Die Autorisierung legt anschließend fest, auf welche Anwendungen, Dateien und Funktionen der Benutzer zugreifen darf.

Ein Mitarbeiter kann sich also erfolgreich anmelden, ohne automatisch Zugriff auf alle Unternehmensdaten zu erhalten.

Was bedeutet Single Sign-On?

Single Sign-On, kurz SSO, ermöglicht Benutzern den Zugriff auf mehrere Anwendungen mit einer zentralen Anmeldung.

Nach einer erfolgreichen Authentifizierung können beispielsweise Microsoft 365, ein CRM-System und weitere Cloud-Anwendungen genutzt werden, ohne für jeden Dienst ein eigenes Passwort einzugeben.

SSO verbessert den Benutzerkomfort und reduziert die Anzahl separat verwalteter Zugangsdaten. Die zentrale Identität muss dafür jedoch besonders sorgfältig geschützt werden.

Welche Rolle spielt die Multi-Faktor-Authentifizierung?

Die Multi-Faktor-Authentifizierung, kurz MFA, verlangt neben dem Passwort einen weiteren Identitätsnachweis.

Dies kann beispielsweise sein:

  • eine Authenticator-App
  • ein Hardware-Sicherheitsschlüssel
  • ein Passkey
  • eine Smartcard
  • ein biometrisches Merkmal

MFA erschwert Kontoübernahmen, da ein gestohlenes Passwort allein normalerweise nicht für eine erfolgreiche Anmeldung ausreicht.

Besonders wichtig ist MFA für administrative Konten, Cloud-Dienste, E-Mail-Zugänge und externe Zugriffe.

Was ist bedingter Zugriff?

Beim bedingten Zugriff wird nicht nur geprüft, ob Benutzername und Passwort korrekt sind. Zusätzlich werden weitere Bedingungen bewertet.

Dazu können gehören:

  • Standort des Benutzers
  • verwendetes Gerät
  • Sicherheitsstatus des Geräts
  • aufgerufene Anwendung
  • erkannte Anmelderisiken
  • Rolle des Benutzers
  • ungewöhnliches Anmeldeverhalten

Je nach Risiko kann der Zugriff erlaubt, blockiert oder nur nach einer zusätzlichen MFA-Prüfung freigegeben werden.

Was bedeutet rollenbasierte Zugriffskontrolle?

Bei der rollenbasierten Zugriffskontrolle, kurz RBAC, werden Berechtigungen nicht einzeln an jeden Benutzer vergeben. Stattdessen erhalten Benutzer eine Rolle, die zu ihrer Aufgabe passt.

Mögliche Rollen sind beispielsweise:

  • Vertriebsmitarbeiter
  • Personalabteilung
  • Buchhaltung
  • IT-Administrator
  • externer Dienstleister

Jede Rolle besitzt festgelegte Zugriffsrechte. Dadurch können Berechtigungen einheitlicher und übersichtlicher verwaltet werden.

Grundlage sollte das Prinzip der minimalen Berechtigung sein: Benutzer erhalten nur die Rechte, die sie tatsächlich benötigen.

Wie funktioniert das Onboarding und Offboarding?

Beim Eintritt eines neuen Mitarbeiters müssen häufig mehrere Konten, Gruppenmitgliedschaften und Anwendungszugriffe eingerichtet werden.

Ein zentrales Identitätsmanagement kann diese Abläufe automatisieren. Die benötigten Berechtigungen werden beispielsweise anhand der Abteilung oder Position vergeben.

Beim Austritt müssen alle Zugänge zeitnah deaktiviert und Berechtigungen entzogen werden. Ein unvollständiges Offboarding kann dazu führen, dass ehemalige Mitarbeitende weiterhin Zugriff auf Unternehmensdaten besitzen.

Was ist eine hybride Identität?

Viele Unternehmen betreiben sowohl lokale Systeme als auch Cloud-Dienste.

Bei einer hybriden Identität werden lokale Benutzerkonten, beispielsweise aus einem Active Directory, mit einer Cloud-Identitätsplattform wie Microsoft Entra ID verbunden.

Dadurch können Benutzer mit einer einheitlichen Identität auf lokale Anwendungen und Cloud-Dienste zugreifen.

Die Synchronisation und Absicherung müssen sorgfältig geplant werden, da Fehler oder kompromittierte Konten Auswirkungen auf beide Umgebungen haben können.

Welche Vorteile bietet Cloud-Identitätsmanagement?

Ein zentrales Identitätsmanagement kann Unternehmen mehrere Vorteile bieten:

  • einheitliche Verwaltung von Benutzerkonten
  • sicherer Zugriff von unterschiedlichen Standorten
  • weniger separate Passwörter durch SSO
  • automatisiertes Onboarding und Offboarding
  • nachvollziehbare Berechtigungen
  • bessere Kontrolle administrativer Zugänge
  • zentrale Protokollierung von Anmeldungen
  • Unterstützung von Compliance- und Audit-Anforderungen
  • schnellere Integration neuer Cloud-Anwendungen

Welche Risiken müssen beachtet werden?

Da die zentrale Identitätsplattform den Zugriff auf viele Systeme steuert, ist sie ein attraktives Ziel für Angreifer.

Wichtige Schutzmaßnahmen sind:

  • konsequente Nutzung von MFA
  • besonders geschützte Administratorkonten
  • regelmäßige Prüfung von Rollen und Berechtigungen
  • Überwachung auffälliger Anmeldungen
  • sichere Wiederherstellungsverfahren
  • zeitnahe Deaktivierung nicht benötigter Konten
  • begrenzte Rechte für Anwendungen und Dienstkonten
  • regelmäßige Zugriffskontrollen

Ein falsch konfiguriertes Identitätsmanagement kann dazu führen, dass Benutzer zu viele Rechte besitzen oder sensible Anwendungen unzureichend geschützt sind.

Fazit

Cloud- und Identitätsmanagement ermöglicht die zentrale Verwaltung von Benutzern, Zugriffsrechten und Anmeldungen in Cloud- und Hybridumgebungen.

Funktionen wie Single Sign-On, Multi-Faktor-Authentifizierung, bedingter Zugriff und rollenbasierte Berechtigungen verbessern Sicherheit und Benutzerkomfort. Voraussetzung ist eine klare Rechtevergabe, eine zuverlässige Überwachung und ein geregelter Identitätslebenszyklus vom Eintritt bis zum Austritt eines Mitarbeiters.

CVE

CVE: Sicherheitslücken eindeutig identifizieren

CVE steht für Common Vulnerabilities and Exposures. Das international verwendete System vergibt eindeutige Kennungen für öffentlich bekannte Sicherheitslücken in Software und Hardware.

Eine solche Kennung wird als CVE-ID bezeichnet, beispielsweise CVE-2025-12345. Hersteller, Sicherheitsforscher, IT-Abteilungen und Sicherheitslösungen können damit eindeutig auf dieselbe Schwachstelle verweisen.

Was ist eine CVE?

Eine CVE-ID ist eine standardisierte Bezeichnung für eine bestimmte Sicherheitslücke. Sie verhindert, dass Hersteller, Sicherheitsexperten und IT-Dienstleister unterschiedliche Namen für dasselbe Problem verwenden.

Ein CVE-Eintrag enthält üblicherweise:

  • eine eindeutige CVE-ID
  • eine kurze Beschreibung der Schwachstelle
  • Angaben zu betroffenen Produkten oder Versionen
  • Verweise auf Herstellerinformationen und Sicherheitsmeldungen
  • gegebenenfalls zusätzliche technische Angaben

Die CVE-ID selbst sagt jedoch noch nicht aus, wie gefährlich eine Schwachstelle für ein bestimmtes Unternehmen ist oder ob sie bereits aktiv ausgenutzt wird.

Wie ist eine CVE-ID aufgebaut?

Eine CVE-ID besteht aus drei Teilen:

CVE-Jahr-Nummer

Das Beispiel CVE-2025-12345 setzt sich folgendermaßen zusammen:

  • CVE: Bezeichnung des Systems
  • 2025: Jahr der Zuweisung oder öffentlichen Bekanntmachung
  • 12345: eindeutige Identifikationsnummer

Die Jahreszahl zeigt nicht zwingend, wann die Schwachstelle entdeckt oder in ein Produkt eingebaut wurde. Eine Sicherheitslücke kann bereits seit mehreren Jahren bestehen, bevor sie öffentlich bekannt wird und eine CVE-ID erhält.

Wer vergibt CVE-IDs?

CVE-IDs werden von sogenannten CVE Numbering Authorities, kurz CNAs, vergeben. Dazu gehören unter anderem Softwarehersteller, Sicherheitsorganisationen und Forschungseinrichtungen.

Ein Hersteller kann beispielsweise für eine Schwachstelle im eigenen Produkt eine CVE-ID reservieren und später einen vollständigen CVE-Eintrag veröffentlichen.

Das CVE-Programm sorgt für gemeinsame Regeln und ein einheitliches Format. Dadurch können Sicherheitsinformationen weltweit automatisiert verarbeitet und miteinander verknüpft werden.

Was ist der Unterschied zwischen CVE und CVSS?

CVE und CVSS erfüllen unterschiedliche Aufgaben:

  • CVE identifiziert eine Sicherheitslücke eindeutig.
  • CVSS bewertet ihre technischen Eigenschaften und Schwere.

CVSS steht für Common Vulnerability Scoring System. Der Wert liegt üblicherweise zwischen 0 und 10. Ein hoher Wert weist auf eine technisch schwerwiegende Schwachstelle hin.

Ein CVSS-Wert ist jedoch keine vollständige Risikobewertung. Für ein Unternehmen sind zusätzlich folgende Fragen wichtig:

  • Ist das betroffene Produkt überhaupt im Einsatz?
  • Ist die anfällige Funktion aktiviert?
  • Ist das System aus dem Internet erreichbar?
  • Gibt es bereits bekannte Angriffe?
  • Welche Daten und Geschäftsprozesse sind betroffen?
  • Existieren wirksame Schutzmaßnahmen?
  • Steht ein Sicherheitsupdate zur Verfügung?

Eine Schwachstelle mit einem niedrigeren CVSS-Wert kann für ein öffentlich erreichbares, geschäftskritisches System dringender sein als eine höher bewertete Schwachstelle auf einem isolierten Testsystem.

Was ist der Unterschied zwischen CVE, CWE und NVD?

Die Begriffe werden häufig gemeinsam verwendet, bezeichnen aber unterschiedliche Dinge.

CVE

CVE benennt eine konkrete, öffentlich bekannte Sicherheitslücke eindeutig.

CWE

Common Weakness Enumeration beschreibt Arten grundlegender Software- und Hardwarefehler. Eine unsichere Speicherverarbeitung oder eine fehlerhafte Zugriffskontrolle kann beispielsweise einer CWE-Kategorie zugeordnet werden.

Eine CWE beschreibt somit eine Fehlerklasse, während eine CVE eine konkrete Schwachstelle in einem bestimmten Produkt bezeichnet.

NVD

Die National Vulnerability Database, kurz NVD, übernimmt CVE-Daten und ergänzt sie um weitere Informationen. Dazu können CVSS-Bewertungen, Produktzuordnungen und technische Klassifizierungen gehören.

CVE und NVD sind deshalb nicht dasselbe. Das CVE-Programm stellt die eindeutige Identifikation bereit, während die NVD diese Informationen für das Schwachstellenmanagement anreichert.

Wie nutzen Unternehmen CVEs?

CVE-IDs bilden eine wichtige Grundlage für das Schwachstellen- und Patch-Management.

Typische Einsatzbereiche sind:

  • Abgleich eingesetzter Software mit bekannten Sicherheitslücken
  • Priorisierung verfügbarer Sicherheitsupdates
  • Auswertung von Schwachstellenscans
  • Zuordnung von Herstellerwarnungen
  • Dokumentation von Sicherheitsmaßnahmen
  • Überwachung besonders gefährdeter Systeme
  • Abstimmung zwischen IT-Abteilung, Herstellern und Dienstleistern
  • automatisierte Verarbeitung in SIEM- und Sicherheitsplattformen

Ein Schwachstellenscanner kann beispielsweise erkennen, dass auf einem Server eine bestimmte Softwareversion installiert ist, und dazu passende CVE-Einträge melden.

Muss jede CVE sofort gepatcht werden?

Nicht jede veröffentlichte CVE ist für jedes Unternehmen relevant. Vor einer Maßnahme muss geprüft werden, ob das betroffene Produkt und die anfällige Version tatsächlich verwendet werden.

Bei der Priorisierung sollten mehrere Faktoren berücksichtigt werden:

  • technische Kritikalität
  • öffentliche Erreichbarkeit
  • Bedeutung des betroffenen Systems
  • vorhandene Angriffsmöglichkeiten
  • bekannte aktive Ausnutzung
  • verfügbare Updates oder Gegenmaßnahmen
  • mögliche Auswirkungen des Updates

Besonders wichtig sind Schwachstellen, die nachweislich bereits von Angreifern ausgenutzt werden. Der Known Exploited Vulnerabilities Catalog der US-Sicherheitsbehörde CISA kann hierfür eine zusätzliche Informationsquelle sein.

Kann ein Update nicht sofort installiert werden, kommen möglicherweise vorübergehende Maßnahmen infrage. Dazu gehören das Deaktivieren einer anfälligen Funktion, eingeschränkte Netzwerkzugriffe oder eine stärkere Überwachung.

Bedeutet eine CVE automatisch, dass ein System gehackt wurde?

Nein. Eine CVE beschreibt eine bekannte Schwachstelle, nicht einen erfolgreichen Angriff.

Ob ein System tatsächlich betroffen oder bereits kompromittiert ist, muss gesondert geprüft werden. Dazu können Protokollanalysen, Sicherheitsüberwachung und forensische Untersuchungen erforderlich sein.

Umgekehrt bedeutet das Fehlen einer bekannten CVE nicht, dass ein Produkt vollständig sicher ist. Noch unbekannte oder nicht veröffentlichte Schwachstellen besitzen möglicherweise keine CVE-ID.

Fazit

CVE ermöglicht die eindeutige Benennung öffentlich bekannter Sicherheitslücken. Das standardisierte Format erleichtert den Austausch zwischen Herstellern, IT-Abteilungen, Sicherheitsexperten und automatisierten Werkzeugen.

Für ein wirksames Schwachstellenmanagement reicht es jedoch nicht aus, nur CVE-Listen zu beobachten. Unternehmen müssen prüfen, welche Produkte betroffen sind, das tatsächliche Risiko bewerten und notwendige Updates oder Schutzmaßnahmen kontrolliert umsetzen.

Exploit

Exploit einfach erklärt

Ein Exploit ist ein Programm, Code oder eine Methode, mit der eine Schwachstelle in Software, Hardware oder einer IT-Konfiguration gezielt ausgenutzt wird.

Angreifer können einen Exploit beispielsweise verwenden, um Schadcode auszuführen, Benutzerrechte zu erweitern, Sicherheitsmechanismen zu umgehen oder unbefugt auf ein System zuzugreifen.

Ein Exploit ist dabei nicht die Schwachstelle selbst. Er ist das Mittel, mit dem eine vorhandene Sicherheitslücke ausgenutzt wird.

Wie funktioniert ein Exploit?

Eine Software kann einen Programmierfehler oder eine unsichere Funktion enthalten. Unter bestimmten Bedingungen führt dieser Fehler dazu, dass sich die Anwendung anders verhält als vorgesehen.

Ein Exploit erzeugt gezielt genau diese Bedingungen.

Ein möglicher Ablauf ist:

  1. Eine Schwachstelle wird entdeckt.
  2. Die technischen Voraussetzungen werden analysiert.
  3. Ein Exploit wird entwickelt, der die Schwachstelle ausnutzt.
  4. Der Exploit wird gegen ein betroffenes System eingesetzt.
  5. Bei Erfolg kann der Angreifer weitere Aktionen ausführen.

Welche Auswirkungen möglich sind, hängt von der jeweiligen Sicherheitslücke und den Berechtigungen des betroffenen Prozesses ab.

Welche Arten von Exploits gibt es?

Exploits lassen sich nach ihrem Einsatzgebiet und ihrer Wirkung unterscheiden.

Remote Exploit

Ein Remote Exploit kann über ein Netzwerk oder das Internet gegen ein entferntes System eingesetzt werden.

Ist der betroffene Dienst öffentlich erreichbar, kann ein Angreifer möglicherweise ohne direkten Zugriff auf das Gerät angreifen.

Local Exploit

Ein Local Exploit setzt voraus, dass der Angreifer bereits lokal auf dem System angemeldet ist oder dort Programmcode ausführen kann.

Solche Exploits werden häufig verwendet, um vorhandene Rechte zu erweitern.

Privilege-Escalation-Exploit

Ein Exploit zur Privilege Escalation ermöglicht es einem Benutzer oder Prozess, höhere Berechtigungen zu erlangen.

Ein Angreifer kann dadurch beispielsweise von einem normalen Benutzerkonto zu administrativen oder systemweiten Rechten wechseln.

Zero-Day-Exploit

Ein Zero-Day-Exploit nutzt eine Schwachstelle, für die zum Zeitpunkt des Angriffs noch kein Sicherheitsupdate verfügbar ist oder die dem Hersteller bislang nicht bekannt war.

Zero-Day-Exploits gelten als besonders gefährlich, weil Unternehmen die zugrunde liegende Schwachstelle noch nicht durch ein reguläres Update schließen können.

Web-Exploit

Web-Exploits richten sich gegen Webanwendungen, Schnittstellen oder Webserver. Sie können beispielsweise fehlerhafte Eingabeprüfungen, unsichere Dateiuploads oder mangelhafte Zugriffskontrollen ausnutzen.

Was ist der Unterschied zwischen Exploit und Schwachstelle?

Eine Schwachstelle ist ein Fehler oder eine unsichere Eigenschaft eines Systems.

Ein Exploit ist die Methode oder der Code, der diese Schwachstelle tatsächlich ausnutzt.

Ein vereinfachtes Beispiel:

  • Eine Anwendung verarbeitet eine bestimmte Eingabe fehlerhaft.
  • Dieser Fehler ist die Schwachstelle.
  • Ein speziell erstellter Code, der den Fehler gezielt auslöst, ist der Exploit.

Nicht für jede bekannte Schwachstelle ist ein öffentlich verfügbarer Exploit vorhanden. Umgekehrt kann ein funktionierender Exploit das Risiko einer Schwachstelle deutlich erhöhen.

Ist ein Exploit dasselbe wie Malware?

Nein. Malware ist schädliche Software wie ein Trojaner, eine Ransomware oder Spyware.

Ein Exploit dient zunächst dazu, eine Schwachstelle auszunutzen. Anschließend kann er verwendet werden, um Malware einzuschleusen oder auszuführen.

Ein Angriff kann beispielsweise so ablaufen:

  1. Ein Exploit verschafft Zugriff auf ein System.
  2. Der Angreifer lädt Schadsoftware nach.
  3. Die Malware verschlüsselt Daten oder stiehlt Informationen.

Exploits und Malware können somit zusammen eingesetzt werden, sind aber nicht dasselbe.

Bekannte Beispiele für Exploits

Zu den bekannten Sicherheitslücken und Angriffsmethoden gehören:

  • EternalBlue: nutzte eine Schwachstelle im SMB-Protokoll von Windows und wurde unter anderem bei der Verbreitung von WannaCry eingesetzt.
  • PrintNightmare: bezeichnete Schwachstellen im Windows-Druckwarteschlangendienst.
  • Shellshock: betraf die Bash-Shell auf Unix- und Linux-Systemen.
  • Log4Shell: ermöglichte unter bestimmten Bedingungen die Ausführung von Code über die Java-Bibliothek Log4j.

Solche Beispiele zeigen, dass Exploits sowohl Betriebssysteme als auch Anwendungen, Bibliotheken und Netzwerkdienste betreffen können.

Wie können sich Unternehmen vor Exploits schützen?

Ein vollständiger Schutz ist nicht möglich. Mehrere Sicherheitsmaßnahmen können das Risiko jedoch deutlich reduzieren.

Patch-Management

Sicherheitsupdates sollten zeitnah bewertet, getestet und installiert werden. Besonders wichtig sind öffentlich erreichbare und geschäftskritische Systeme.

Vulnerability Management

Unternehmen sollten ihre Systeme regelmäßig auf bekannte Schwachstellen überprüfen und gefundene Risiken priorisieren.

Eingeschränkte Berechtigungen

Benutzer und Anwendungen sollten nur die Rechte besitzen, die sie tatsächlich benötigen. Dadurch lassen sich mögliche Auswirkungen eines erfolgreichen Exploits begrenzen.

Netzwerksegmentierung

Kritische Systeme sollten von anderen Bereichen des Netzwerks getrennt werden. So kann sich ein Angreifer nach einem erfolgreichen Angriff weniger leicht weiterbewegen.

EDR und Sicherheitsüberwachung

Endpoint Detection and Response, Intrusion-Detection-Systeme und zentrale Protokollierung können verdächtige Exploit-Aktivitäten erkennen und eine schnelle Reaktion ermöglichen.

Reduzierung der Angriffsfläche

Nicht benötigte Dienste, Anwendungen, Benutzerkonten und Netzwerkzugänge sollten deaktiviert oder entfernt werden.

Was tun, wenn kein Sicherheitsupdate verfügbar ist?

Steht noch kein Patch bereit, können vorübergehende Schutzmaßnahmen notwendig sein.

Dazu gehören beispielsweise:

  • betroffene Funktionen deaktivieren
  • Zugriff auf den Dienst einschränken
  • Systeme vom Internet trennen
  • Netzwerkregeln verschärfen
  • Hersteller-Workarounds umsetzen
  • verdächtige Aktivitäten verstärkt überwachen
  • besonders gefährdete Systeme vorübergehend außer Betrieb nehmen

Solche Maßnahmen sollten dokumentiert und nach Veröffentlichung eines Updates erneut bewertet werden.

Fazit

Ein Exploit nutzt eine vorhandene Schwachstelle gezielt aus. Dadurch können Angreifer unter anderem unbefugten Zugriff erhalten, Schadcode ausführen oder höhere Berechtigungen erlangen.

Ein wirksamer Schutz kombiniert regelmäßige Sicherheitsupdates, Schwachstellenmanagement, minimale Berechtigungen, Netzwerksegmentierung und kontinuierliche Überwachung. Je schneller bekannte Schwachstellen erkannt und behoben werden, desto kleiner ist das Zeitfenster für erfolgreiche Exploit-Angriffe.