Was ist Cloud-Sicherheit? Bedeutung und Sicherheitstipps für 2026

Wichtigste Erkenntnisse

• Unter Cloud-Sicherheit versteht man die Kontrollmechanismen, Richtlinien und Tools, die Daten, Anwendungen und die Infrastruktur in der Cloud schützen.
• Bei der geteilten Verantwortung werden die Sicherheitsaufgaben zwischen Ihnen und dem Anbieter aufgeteilt, wobei sich die Aufteilung je nach Servicemodell unterscheidet.
• Bei IaaS liegen das Gastbetriebssystem und dessen Patches in Ihrer Verantwortung, nicht in der des Anbieters.

Cloud-Anbieter betreiben die Rechenzentren, die Hardware und die Virtualisierungsebene, auf der Ihre Workloads laufen. Darüber hinaus hängt es vom Servicemodell ab. Bei IaaS liegen das Gastbetriebssystem, die Benutzerkonten und die gespeicherten Daten auf Ihrer Seite der Grenze, und diese Grenze verschiebt sich, je weiter Sie in Richtung verwalteter Plattformen und SaaS voranschreiten.

An dieser sich verändernden Grenze entstehen häufig Sicherheitslücken. Man geht leicht davon aus, dass der Anbieter sich um die Patch- oder eine Konfigurationsaufgabe übernimmt, die eigentlich Ihre Aufgabe ist.

Was ist Cloud-Sicherheit?

Cloud-Sicherheit ist die Kombination aus Kontrollmaßnahmen, Richtlinien und Tools, die Daten, Anwendungen und die Infrastruktur schützen, die in Cloud-Umgebungen. Sie erstreckt sich über die Identitäts-, Netzwerk-, Workload- und Datenebenen und gilt unabhängig davon, ob Sie virtuelle Maschinen, verwaltete Plattformen oder von einem Anbieter bereitgestellte Software betreiben.

Manchmal wird der Begriff „Cloud-basierte Sicherheit“ für Sicherheitstools verwendet, die selbst aus der Cloud bereitgestellt werden. In diesem Zusammenhang umfasst der Begriff die umfassendere Aufgabe, alles zu schützen, was in der Cloud läuft, bis hin zu den Linux-Server , auf denen ein Großteil dieser Workloads ausgeführt wird.

Das ist wichtig, weil schon eine einzige falsch konfigurierte Einstellung, ein Konto mit zu weitreichenden Berechtigungen oder ein Server ohne Patches dazu führen kann, dass Daten offengelegt werden oder ein Dienst ausfällt. Einige dieser Risiken bestehen unabhängig davon, für welches Servicemodell Sie sich entscheiden, wie die Matrix weiter unten zeigt.

Was versteht man unter dem Modell der geteilten Verantwortung in der Cloud-Sicherheit?

Das Modell der geteilten Verantwortung legt fest, welche Sicherheitsaufgaben in den Zuständigkeitsbereich des Cloud-Anbieters fallen und welche in Ihren. Ein häufiges Missverständnis ist, dass der Anbieter alles sichert, was er hostet. In der Praxis verschiebt sich die Grenze je nach Servicemodell und kann sich zudem von einem Dienst zum nächsten erneut verschieben.

AWS, Microsoft und Google stellen dies jeweils etwas anders dar. Microsoft veröffentlicht eine Matrix nach Servicemodellen. AWS unterscheidet zwischen der Sicherheit „der“ Cloud – also der Infrastruktur des Anbieters – und der Sicherheit „in“ der Cloud – also allem, was Sie dort ablegen. Google geht noch einen Schritt weiter mit dem sogenannten „Shared Fate“-Ansatz, bei dem der Anbieter eine aktivere Rolle dabei übernimmt, Kunden bei der Einrichtung einer sicheren Umgebung zu unterstützen. Microsoft selbst beschreibt seine Matrix als illustrativen Leitfaden, der die Bedingungen Ihres Vertrags nicht ändert. Betrachten Sie diese Modelle daher als Orientierungshilfe und prüfen Sie Ihren Vertrag sowie die Dokumentation für den jeweiligen Dienst, den Sie nutzen.

Wie sich die Verantwortlichkeiten zwischen IaaS, PaaS und SaaS verlagern

Cloud-Dienste lassen sich in drei Servicemodelle einteilen: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Je mehr Teile des Stacks der Anbieter verwaltet, desto weniger müssen Sie selbst übernehmen, wobei Ihnen in allen drei Modellen einige Aufgaben weiterhin obliegen. Die aktuelle Matrix von Microsoft, die im Folgenden angepasst wurde, zeigt, wie sich die Aufgaben aufteilen.

Quelle: Microsoft Learn, „Geteilte Verantwortung in der Cloud“. Angepasst: „Kunde“ und „Microsoft“ erscheinen als „Sie“ und „Anbieter“, die Spalte „lokal“ wurde weggelassen, und die Zeilen „physische Hosts“, „Netzwerk“ und „Rechenzentrum“ wurden zu einer zusammengefasst.

Microsoft nennt außerdem vier Verantwortungsbereiche, die unabhängig vom Servicemodell bei Ihnen verbleiben: Daten, Endgeräte, Konten und Zugriffsverwaltung. Client-Geräte werden bei SaaS als „Gemeinsam genutzt“ angezeigt, da Microsoft dort bei deren Verwaltung helfen kann, doch der Schutz dieser Endgeräte liegt weiterhin in Ihrer Verantwortung.

Infrastructure as a Service (IaaS)

Bei IaaS mieten Sie Rechenleistung, Speicherplatz und Netzwerkkapazitäten, beispielsweise Amazon EC2, Azure Virtual Machines oder Google Compute Engine. Der Anbieter sorgt für die physische Infrastruktur und die Virtualisierungsebene. Sie kümmern sich um das Gastbetriebssystem (Guest OS), die installierte Software und die Netzwerkkonfiguration.

AWS macht dies unmissverständlich deutlich. Kunden, die eine EC2-Instanz bereitstellen, sind für die „Verwaltung des Gastbetriebssystems (einschließlich Updates und Sicherheitspatches)“ sowie für die von ihnen installierte Software und die Konfiguration der Sicherheitsgruppe auf jeder Instanz verantwortlich. AWS führt das Patch-Management zudem als gemeinsame Kontrollmaßnahme auf: AWS führt Patches an der Infrastruktur durch, während die Kunden ihre Gastbetriebssysteme und Anwendungen patchen. Die Matrix von Microsoft stimmt diesbezüglich für IaaS überein und überträgt die Verantwortung für das Betriebssystem auf den Kunden.

Platform as a Service (PaaS)

Verwaltete Plattformen wie Azure App Service, Azure Functions und Azure SQL Database, die Microsoft als PaaS einstuft, verlagern einen größeren Teil der Arbeit auf den Anbieter. Der Anbieter übernimmt das Betriebssystem, die Laufzeitumgebung und die Middleware. Anwendungen und Netzwerksteuerungen werden gemeinsam genutzt. Sie behalten die Anwendungskonfiguration, die Codesicherheit, die Zugriffskontrollen und die Bibliotheken, die Sie in Ihre Bereitstellung einbinden.

Auch Laufzeitversionen werden nach einem veröffentlichten Zeitplan aus dem Verkehr gezogen, und wenn das geschieht, liegt die Migrationsarbeit wieder bei Ihnen.

Software as a Service (SaaS)

Bei SaaS-Lösungen wie Microsoft 365 oder Dynamics 365 liegt fast der gesamte Stack in der Hand des Anbieters. Google drückt es so aus: Bei SaaS trägt der Anbieter den Großteil der Sicherheitsverantwortung, während Sie weiterhin für Ihre Zugriffskontrollen und die von Ihnen gespeicherten Daten verantwortlich sind. Microsoft betrachtet Client-Geräte in diesem Zusammenhang als gemeinsamen Bereich. Das Unternehmen kann zwar einige Funktionen zur Geräteverwaltung anbieten, doch der Schutz der Endgeräte und die Einhaltung von Compliance-Vorgaben liegen weiterhin in Ihrer Verantwortung.

Wofür sind Cloud-Anbieter verantwortlich?

Die Provider kümmern sich um die Schichten, die der Hardware am nächsten liegen. In der Dokumentation von Microsoft wird dieser Bereich in mehrere Teilbereiche unterteilt, und AWS zieht eine ähnliche Abgrenzung.

Physische Infrastruktur

Die Sicherheit des Rechenzentrums liegt in der Verantwortung des Anbieters: Einrichtungen, physische Zugangskontrollen und Umgebungskontrollen sowie die physischen Server, auf denen Ihre Workloads gehostet werden.

Grundlagen der Netzwerktechnik

Router, Switches und die Verkabelung im Rechenzentrum unterliegen der Verwaltung durch den Anbieter. Bei PaaS stellt Microsoft eine Grundausstattung an Netzwerksicherheit, und bei SaaS verwaltet Microsoft die Netzwerksicherheit. Firewall-Regeln und Segmentierung für Ihre eigenen Instanzen liegen in IaaS weiterhin in Ihrer Verantwortung.

Virtualisierung und Host-Ebenen

Der Hypervisor und das Host-Betriebssystem gehören ebenfalls zum Anbieter. AWS beschreibt seinen Zuständigkeitsbereich als den Bereich, der vom Host-Betriebssystem und der Virtualisierungsschicht bis hin zur physischen Sicherheit der Einrichtungen reicht, wodurch Ihr Gastbetriebssystem außerhalb dieses Bereichs liegt.

Compliance-Dokumentation

AWS, Microsoft und Google Cloud veröffentlichen jeweils Compliance-Dokumentationen. AWS gibt an, dass Kunden die eigenen Kontroll- und Compliance-Unterlagen für ihre eigene Bewertung und Überprüfung der Kontrollen nutzen können. Außerdem verweist das Unternehmen auf Prüfungsbescheinigungen von Drittanbietern, anhand derer Kunden ermitteln können, welche Kontrollen bereits vorhanden sind und welche noch implementiert werden müssen. Microsoft veröffentlicht Prüfungsberichte über sein Service Trust Portal, und Google Cloud bietet Auditberichte und Zertifizierungen über seinen Compliance Reports Manageran. Für einige Ressourcen von Microsoft und Google ist eine Anmeldung erforderlich, und bestimmte Materialien werden unter Vertraulichkeitsbedingungen bereitgestellt.

Wofür sind Organisationen zuständig?

Bei IaaS sind Sie für den Großteil des Stacks verantwortlich. Das beginnt mit der Installation von Patches für das Gastbetriebssystem und den Kernel auf jeder Instanz – einschließlich derjenigen, die aus alten Images gestartet wurden – und erstreckt sich bis hin zu den von Ihnen ausgeführten Anwendungen und den von diesen eingebundenen Bibliotheken, selbst wenn Sie diese nie direkt ausgewählt haben.

Außerdem konfigurieren Sie das Netzwerk. Bei IaaS umfasst dies Sicherheitsgruppen, Firewall-Regeln und Segmentierung. Bei PaaS sind damit Netzwerksteuerungen auf Anwendungsebene gemeint. Auch die Protokollierung und Überwachung müssen Sie selbst einrichten. Bei Google Cloud sind beispielsweise die Protokollierung der Datenzugriffe standardmäßig für alle Dienste deaktiviert – mit Ausnahme einiger weniger BigQuery-Dienste –, sodass Sie bei den meisten Diensten erst dann über diese Protokollierung verfügen, wenn Sie sie aktivieren.

Sicherung und Wiederherstellung variieren je nach Dienst. Bei Amazon EC2 richten Sie Snapshots oder Sicherungsrichtlinien für Ihre Volumes selbst ein – mithilfe von Tools wie AWS Backup oder Amazon Data Lifecycle Manager. Bei Amazon RDS sind automatische Sicherungen standardmäßig aktiviert, aber wie lange diese aufbewahrt werden, entscheiden Sie selbst.

Informationen zu sicheren Entwicklungs- und Bereitstellungsverfahren finden Sie in unserem Leitfaden zu den Best Practices für Softwaresicherheit.

Arten von Cloud-Sicherheitsmaßnahmen

Rahmenwerke für Cloud-Sicherheit umfassen in der Regel Bereiche wie die folgenden fünf.

Identitäts- und Zugriffsmanagement

Rollen, Richtlinien, Dienstkonten und Verbundstrukturen bestimmen oft, worauf eine kompromittierte Anmeldeinformation Zugriff hat. Das Prinzip der geringsten Berechtigungen, die Multi-Faktor-Authentifizierung für Benutzerkonten sowie die regelmäßige Rotation (oder vollständige Löschung) statischer Schlüssel schränken diesen Zugriff ein. Für einmalige Aufgaben eingerichtete Dienstkonten sollten regelmäßig überprüft werden, und alles, was nicht mehr benötigt wird, sollte gelöscht werden.

Datenschutz und Verschlüsselung

Ordnen Sie die Daten zunächst nach ihrer Vertraulichkeitsstufe ein und legen Sie dann fest, wer die Schlüssel verwaltet. Vom Anbieter verwaltete Schlüssel sind einfacher zu handhaben, während Sie bei vom Kunden verwalteten Schlüsseln mehr Kontrolle über die Rotation und den Widerruf haben. Unabhängig davon, für welche Variante Sie sich entscheiden, sollten Sie festhalten, welche Datensätze welche Variante verwenden.

Netzwerksteuerung und Segmentierung

Sicherheitsgruppen, Netzwerk-ACLs, private Endpunkte und Dienstperimeter steuern, welche Systeme miteinander kommunizieren dürfen. Durch die Segmentierung wird begrenzt, wie weit sich eine kompromittierte Workload ausbreiten kann, und durch das Filtern des ausgehenden Datenverkehrs wird eingeschränkt, welche Ziele diese Workload ansprechen kann.

Workload und Patches für Gastbetriebssysteme

Bei IaaS gehört das Installieren von Patches zu den umfangreicheren wiederkehrenden Aufgaben, die Sie übernehmen. Linux ist auf Cloud- und Hosting-Servern weit verbreitet, und ein Kernel-Update erforderte bisher in der Regel einen Neustart der Instanz. Bei einer großen Serverflotte kann die Suche nach einem Wartungsfenster für jeden Neustart die Installation von Patches verzögern.

Die Anbieter stellen hier tatsächlich entsprechende Tools zur Verfügung. AWS Systems Manager Patch Manager, die automatische Gast-Patch-Verwaltung von Azure und Google Cloud VM Manager Patch können alle die Installation von Patches für das Gastbetriebssystem auf Ihren Instanzen automatisieren. Jede dieser Lösungen kann die Instanz im Rahmen des Vorgangs neu starten, und jede hat ihren eigenen Anwendungsbereich. Die automatische Patch-Verwaltung von Azure deckt beispielsweise nur Patches ab, die als „kritisch“ oder „Sicherheit“ eingestuft sind. In jedem Fall bleibt das Gastbetriebssystem selbst bei IaaS auf Ihrer Seite der Grenze.

Live-Patching verfolgt einen anderen Ansatz und wendet Kernel-Sicherheitspatches auf ein laufendes System an. Einige Distributionen und Anbieter bieten eigene Live-Patching-Lösungen für ausgewählte Plattformen an, sodass eine Flotte mit gemischten Distributionen unter Umständen mehrere Tools kombinieren muss. KernelCare bietet Live-Patching für den Linux-Kernel für über 70 Linux-Distributionsversionen, sodass Sie Sicherheitslücken im Kernel auf laufenden Cloud- und Hosting-Servern schließen können, ohne einen Neustart einplanen zu müssen.

Protokollierung und Überwachung

Dienste wie AWS CloudTrail, Azure Monitor und Google Cloud Audit Logs protokollieren Aktivitäten in Ihrer Umgebung. Durch das Senden von Protokollen an ein separates Konto oder Projekt wird es schwieriger, im Falle einer Kompromittierung einer Umgebung den eigenen Prüfpfad zu löschen – insbesondere, wenn der Zugriff auf das Ziel streng eingeschränkt ist. Regelmäßige Sicherheitsaudits helfen dabei, sicherzustellen, dass die Protokolle alle erforderlichen Aspekte abdecken.

Inwiefern hängen gängige Cloud-Bedrohungen mit Ihren Verantwortlichkeiten zusammen?

Cloud-Bedrohungen folgen in der Regel dem Prinzip der geteilten Verantwortung, wodurch sich leichter erkennen lässt, gegen welche man etwas unternehmen kann. Laut der Matrix von Microsoftliegen falsch konfigurierte Einstellungen und kompromittierte Identitäten bei allen drei Servicemodellen in Ihrer Verantwortung. Sicherheitslücken im Betriebssystem liegen bei IaaS in Ihrer Verantwortung und gehen bei PaaS und SaaS auf den Anbieter über. Wenn Sie Ihre eigenen Container-Images und Abhängigkeiten erstellen und bereitstellen, bleiben diese in Ihrer Verantwortung, unabhängig davon, auf welcher Plattform sie ausgeführt werden. Unser Beitrag zu Bedrohungen der Cloud-Sicherheit behandelt jede Kategorie ausführlich.

Für nicht gepatchte und nicht mehr unterstützte Systeme gilt in der IaaS dieselbe Regel: Die Wartung des Betriebssystems liegt in Ihrer Verantwortung. Eine Cloud-Instanz kann jahrelang auf einem längst erstellten Image weiterlaufen. Wenn die Linux-Distribution, die Laufzeitumgebung oder das Framework das Ende der Lebensdauer erreicht, stellt der Anbieter die Veröffentlichung von Sicherheitsupdates ein, doch die Workload bedient oft weiterhin den Datenverkehr, während die Migration geplant wird. Der „Endless Lifecycle Support“ (ELS) von TuxCare stellt Sicherheitspatches für Linux-Distributionen, Laufzeiten, Frameworks und Anwendungen bereit, deren Lebensdauer abgelaufen ist, nachdem der Standardsupport der jeweiligen Anbieter beendet wurde. Dies gibt Ihnen Spielraum, die Migration nach Ihrem eigenen Zeitplan durchzuführen.

Häufige Herausforderungen bei geteilter Verantwortung

Die Linie verschiebt sich mit jedem Dienst

Bei einem verwalteten Kubernetes-Dienst betreibt der Anbieter die Steuerungsebene, und was mit den Worker-Knoten geschieht, hängt von der von Ihnen gewählten Option ab. Bei Amazon EKS übernimmt AWS immer mehr Aufgaben, je weiter Sie sich von selbstverwalteten Knoten über verwaltete Knotengruppen hin zu Fargate bewegen. Selbst bei verwalteten Knotengruppen müssen Sie das Update auf eine neuere AMI-Version noch selbst auslösen; EKS führt die Bereitstellung dann auf Ihren Knoten durch. Ein Modell, das auf einem bestimmten Dienst basiert, kann bei einem anderen Dienst irreführend sein. Überprüfen Sie daher die Dokumentation zu den Zuständigkeiten der einzelnen Dienste.

Patches können zwischen den Teams unter den Tisch fallen

Wenn die Plattformentwicklung für die Kontostruktur zuständig ist, die Anwendungsteams für ihre Bereitstellungen und die Sicherheitsabteilung für die Richtlinien, kann das Patchen von Gastbetriebssystemen in den Zuständigkeitsbereich aller drei Bereiche fallen. Bestimmen Sie einen Verantwortlichen. Eine nützliche Frage für Ihre nächste Überprüfung lautet: Wer hat den Kernel auf der ältesten Produktionsinstanz gepatcht und wann?

Vergessene Fälle lassen sich leicht übersehen

Ein System, das nie in Ihr Asset-Inventar aufgenommen wurde, taucht auch nicht in Ihren Patch-Berichten auf. Durch den Abgleich dieses Inventars mit Ihren Cloud-Ressourcenlisten und Abrechnungsdaten lassen sich Systeme aufspüren, für die sich kein Team verantwortlich zeigt.

Tipps zur Cloud-Sicherheit für 2026

Lesen Sie die Dokumentation zu den Verantwortlichkeiten für einen neuen Dienst, bevor Sie ihn bereitstellen – nicht erst danach. Wenden Sie Kernel-Patches auf das Gastbetriebssystem und Kernel-Patches in jeder IaaS-Umgebung einen namentlich benannten Verantwortlichen zu. Stärken Sie die Identitätssicherheit durch das Prinzip der geringsten Berechtigungen, Multi-Faktor-Authentifizierung und regelmäßige Rotation statischer Anmeldedaten, und legen Sie fest, wer die Verschlüsselungsschlüssel für jeden Datensatz verwahrt (und notieren Sie dies anschließend).

Auf der operativen Seite sollten Sie Protokolle an ein separates Konto oder Projekt weiterleiten und sicherstellen, dass Warnmeldungen eine zuständige Person erreichen. Planen Sie Systeme ein, die auch nach Ablauf des Hersteller-Supports weiterlaufen, einschließlich Laufzeitsystemen und Basis-Images. Und erstellen Sie Ihren Workflow für die Incident-Response , bevor Sie ihn benötigen, denn mitten in einem Vorfall ist es zu spät, damit anzufangen.

Sichere Umgebungen mit TuxCare betreiben

Bei IaaS stellt der Anbieter die Infrastruktur bereit, während das Gastbetriebssystem auf jeder Instanz in der Verantwortung Ihres Teams bleibt. Die Open-Source-Abhängigkeiten, die Sie in Ihre eigene Software integrieren, gehören ebenfalls Ihnen – unabhängig davon, wo diese ausgeführt wird. Unbegrenzter Lebenszyklus-Support stellt Sicherheitspatches für Linux-Distributionen, Laufzeitumgebungen, Frameworks und Anwendungen bereit, deren Lebenszyklus abgelaufen ist, sodass die Migration nach Ihrem Zeitplan erfolgen kann und nicht nach der Frist eines Anbieters. SecureChain bietet Ihnen für Ihre Builds verifizierte, auf Malware geprüfte und kontinuierlich gepatchte Open-Source-Pakete für JavaScript, Python, Java, Go, Rust und PHP. Und KernelCare wendet Kernel-Sicherheitspatches auf laufende Linux-Server ohne Neustart an, sodass Kernel-Korrekturen nicht auf ein Wartungsfenster warten müssen.

Um zu erfahren, wie sich das Patchen in einen umfassenderen Cloud-Alltag einfügt, lesen Sie unseren Leitfaden zum Thema Cloud-Patch-Management.

Zusammenfassung

Artikel Name

Was ist Cloud-Sicherheit? Bedeutung und Tipps für 2026

Beschreibung

Erfahren Sie, was Cloud-Sicherheit umfasst, wie sich die gemeinsame Verantwortung auf IaaS, PaaS und SaaS verteilt und welche Aufgaben weiterhin in der Zuständigkeit Ihres Teams liegen.

Autor

Claudia Cejas

Name des Herausgebers

TuxCare

Logo des Herausgebers