Die 14 wichtigsten Rahmenwerke für Cloud-Sicherheitsstandards im Jahr 2026

Wichtigste Erkenntnisse

• Cloud-Sicherheitsstandards lassen sich in fünf Arten der Durchsetzung einteilen, von Zertifizierungen und Bescheinigungen bis hin zu Vorschriften, Verträgen und Kontrollrahmenwerken.
• Die Norm ISO/IEC 27017 wurde zum ersten Mal seit 2015 vollständig überarbeitet, FedRAMP hat sein Regelwerk neu formuliert und die CSA hat CCM v4.1 veröffentlicht.
• Patches tauchen in fast jedem Standard auf, aber nur wenige legen dafür eine feste Frist fest.
• Die meisten Probleme bei der Revision entstehen in der Zeit zwischen den Prüfungen, während sich der Rückstand bei den Patches vergrößert und die Konfigurationen abweichen.

Ein Großteil dessen, worauf ein modernes Unternehmen heute basiert, läuft auf einer Infrastruktur, die ihm nicht gehört, und dieser Wandel hat dazu geführt, dass sich die Verantwortlichkeiten für die Sicherheit verschoben haben. Außerdem hat sich dadurch die Anzahl der Regelwerke vervielfacht, Sicherheitsteam gleichzeitig erfüllen muss. Cloud-Sicherheitsstandards sind diese Vorschriften in schriftlicher Form.

In diesem Artikel wird erläutert, was Cloud-Sicherheitsstandards sind, warum die Art des Standards eine Rolle spielt und welche 14 Standards für Cloud-Compliance-Programme im Jahr 2026 am wichtigsten sind.

Was ist Cloud-Sicherheit?

Cloud-Sicherheit bezeichnet die Gesamtheit der Kontrollmaßnahmen, die Workloads, Identitäten und Daten in Cloud-Umgebungen schützen – dabei handelt es sich in der Regel um Server, die von Dritten betrieben werden. Sie umfasst Konfiguration, Verschlüsselung, Zugriffsverwaltung, Patching und Überwachung in den Bereichen IaaS, PaaS und SaaS. Bei IaaS kümmert sich der Anbieter um die physischen Hosts und den Hypervisor, während Sie fast alles vom Gastbetriebssystem aufwärts selbst verwalten. Bei SaaS betreibt der Anbieter den Großteil des Stacks, sodass sich Ihre Aufgabe auf Identitäten, die Mandantenkonfiguration und die Nutzung der Daten durch die Benutzer beschränkt. PaaS liegt zwischen diesen beiden Modellen.

Was sind Cloud-Sicherheitsstandards?

Cloud-Sicherheitsstandards sind veröffentlichte Anforderungen, die definieren, was „ausreichend sicher“ in der Cloud bedeutet, und sie bieten Prüfern und Aufsichtsbehörden konkrete Maßstäbe für ihre Prüfungen. Einige sind mit einem echten Zertifikat verbunden, das abläuft und erneuert wird. Andere führen anstelle einer Bewertung („bestanden“ oder „nicht bestanden“) einen Bestätigungsbericht aus. Wieder andere sind gesetzlich vorgeschrieben und mit Geldstrafen verbunden. Andere wiederum sind freiwillige Leitlinien, die Unternehmen übernehmen, weil ein Kunde, ein Prüfer oder ihre eigene Risikobewertung sie dazu veranlasst.

Diese letzte Kategorie überschneidet sich mit dem, was man üblicherweise als Cloud-Sicherheits-Frameworksbezeichnet: NIST CSF, die Cloud Controls Matrix (CCM) der CSA und ähnliche Referenzwerke, die eher als Orientierungshilfe denn zur Zertifizierung dienen. Die Überschneidung ist real und wirkt in beide Richtungen. In zahlreichen Übersichten zu „Standards“ werden NIST CSF und CCM aufgeführt, obwohl beide als freiwillig eingestuft werden.

In diesem Leitfaden wird „Standard“ als Oberbegriff für Sicherheitsanforderungen im Bereich Cloud-Computing im weiteren Sinne verwendet und sortiert jeden Eintrag danach, wie er tatsächlich durchgesetzt wird (Zertifizierung, Bescheinigung, Vorschrift, vertragliche Anforderung oder Kontrollrahmen), anstatt eine strenge Trennung zwischen „Standards“ und „Rahmenwerken“ vorzunehmen.

Warum Cloud-Sicherheitsstandards wichtig sind

Dafür gibt es zwei Gründe: Sie sichern Einnahmen und sie mindern Risiken. Viele Unternehmenskunden unterzeichnen einen Vertrag erst, wenn ein SOC-2-Bericht oder ein ISO-Zertifikat vorliegt. Und die Aufsichtsbehörden können wegen Verstößen gegen die DSGVO oder HIPAA gegen Sie vorgehen, unabhängig davon, ob Sie über ein Zertifikat verfügen oder nicht.

Für Unternehmen, bei denen die Einhaltung von Vorschriften im Vordergrund steht, haben Standards eine konkretere Bedeutung als nur die Bekundung guter Absichten. Sie setzen die Aussage „Wir nehmen Sicherheit ernst“ in Kontrollkriterien um, die eine Aufsichtsbehörde, ein Wirtschaftsprüfer oder ein Beschaffungsteam tatsächlich überprüfen kann.

Realitätscheck: Das Bestehen eines Audits beweist nicht, dass Ihre Kontrollmaßnahmen auch im Alltag zwischen den Audits funktionieren. ISO 27001-Überwachungsaudits finden in der Regel einmal im Jahr statt, und ein SOC-2-Typ-II-Beobachtungszeitraum kann für sich genommen fast ein ganzes Jahr dauern. Zwischen diesen Kontrollpunkten häufen sich Patch-Rückstände an, Konfigurationen weichen ab und neue Dienste werden außerhalb des Umfangs der letzten Prüfung in Betrieb genommen. Ohne kontinuierliche Überwachung wird vieles davon erst bei der nächsten Prüfung zutage treten. Unsere Liste der aktuellen Bedrohungen für die Cloud-Sicherheit umfasst all das, was sich in dieser Lücke tendenziell ansammelt.

Die 14 wichtigsten Standards für Cloud-Sicherheit

Welche Norm Sie im Blick haben, bestimmt, was Sie tatsächlich unternehmen müssen. Durch die Verwechslung der fünf Arten kommt es vor, dass Teams einem Kunden ein „ISO 27017-Zertifikat“ versprechen, das es als eigenständiges Dokument gar nicht gibt, oder einem Auditor mitteilen, sie seien „NIST CSF-zertifiziert“, obwohl es für das CSF überhaupt keinen Zertifizierungspfad gibt.

1. ISO/IEC 27017 (Ausgabe 2026)

ISO und IEC pflegen diese Norm gemeinsam im Rahmen ihres gemeinsamen technischen Ausschusses für Informationssicherheit, und die Ausgabe von 2026 ist eine echte Neugestaltung und keine bloße Überarbeitung. Sie wurde im Juli 2026 veröffentlicht, ersetzt die ursprüngliche Fassung von 2015 vollständig und überführt die Norm auf die Kontrollstruktur der ISO/IEC 27002:2022, anstelle der Struktur von 2013, auf der sie ursprünglich basierte.

Die Ausgabe von 2015 enthielt sieben zusätzliche Cloud-Kontrollmaßnahmen mit CLD-Nummern, die unter anderem die Absicherung virtueller Maschinen und die Rückgabe von Kundenressourcen bei Vertragsende abdeckten. Die Ausgabe von 2026 reduziert die cloudspezifischen Ergänzungen auf vier: die grundlegende Aufteilung der gemeinsamen Verantwortung zwischen Anbieter und Kunde, eine Vereinbarung über die Rollen und Verantwortlichkeiten aller beteiligten Cloud-Service-Partner, wie beispielsweise eines Vermittlers oder eines Auditors, der in der Lieferkette des Anbieters tätig ist Lieferkette, die Trennung in virtuellen Rechenumgebungen sowie die Erkennung und Verhinderung unbefugter Cloud-Nutzung.

Der Großteil der verbleibenden Leitlinien zum Thema Cloud ist nun in Form von cloudspezifischen Anmerkungen enthalten, die den entsprechenden Kontrollmaßnahmen der Norm ISO/IEC 27002:2022 selbst überlagert sind.

Wie bisher gibt es hierfür kein eigenständiges Zertifikat. Die Prüfung erfolgt im Rahmen einer ISO/IEC 27001-Zertifizierung, deren Geltungsbereich Cloud-Dienste umfasst. Wenn in Ihrer Compliance-Dokumentation das alte Set aus sieben Kontrollmaßnahmen noch anhand der CLD-Nummern aufgeführt wird, bezieht sich dies auf eine veraltete Struktur, und ein Prüfer, der nach der Ausgabe von 2026 arbeitet, wird dies möglicherweise beanstanden.

Dies ist vor allem für Cloud-Anbieter von Nutzen, die Unternehmenskunden den Reifegrad ihrer Kontrollmechanismen nachweisen möchten, sowie für Kunden, die die Aufgabenteilung in einer Cloud-Partnerschaft in einer konkreteren Form festhalten möchten als nur in einem Verkaufsgespräch.

2. SOC 2

SOC 2 stammt vom AICPA und funktioniert anders als die meisten Punkte auf dieser Liste. Eine zugelassene Wirtschaftsprüfungsgesellschaft prüft Ihre Kontrollmechanismen und erstellt einen Prüfungsbericht. Es gibt kein offizielles „SOC 2-zertifiziert“-Siegel, auch wenn die Homepage eines Anbieters dies vielleicht suggerieren mag.

Die Prüfung erfolgt auf der Grundlage der Trust Services Criteria von 2017und stützt sich auf die überarbeiteten Schwerpunkte, die der AICPA im Jahr 2022 herausgegeben hat, um die Leitlinien angesichts neuerer Technologien und Bedrohungen auf dem neuesten Stand zu halten. Die zugrunde liegenden Kriterien selbst haben sich seit 2017 nicht geändert. Es gibt fünf Kategorien: Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. Sicherheit ist in jedem SOC-2-Bericht vorgeschrieben, und die übrigen Kategorien fügen Sie je nach den Verpflichtungen hinzu, die Sie gegenüber Ihren Kunden eingegangen sind.

Berichte vom Typ I beschreiben die Ausgestaltung der Kontrollmechanismen zu einem bestimmten Zeitpunkt. Berichte vom Typ II beschreiben die operative Wirksamkeit über einen bestimmten Zeitraum, in der Regel zwischen drei und zwölf Monaten, und genau diese Art von Bericht wird von Unternehmenskunden üblicherweise angefordert. Unser Leitfaden zur Erfüllung und Aufrechterhaltung der SOC-2-Konformität behandelt das Spannungsfeld zwischen Verfügbarkeitszusagen und Patch-Fenstern.

3. DSGVO

DSGVO, offiziell Verordnung (EU) 2016/679, gilt für Organisationen mit Sitz in der EU sowie für Organisationen außerhalb der EU, die Waren oder Dienstleistungen für Personen in der EU anbieten oder das Verhalten dieser Personen überwachen. Speziell im Cloud-Bereich ist die Unterscheidung zwischen Verantwortlichem und Auftragsverarbeiter von größter Bedeutung. Sie benötigen einen Auftragsverarbeitungsvertrag, dokumentierte Garantien für Datenübermittlungen außerhalb des Europäischen Wirtschaftsraums sowie ein Verfahren, das es dem Verantwortlichen ermöglicht, die Aufsichtsbehörde unverzüglich und, soweit möglich, innerhalb von 72 Stunden nach Bekanntwerden einer meldepflichtigen Datenschutzverletzung zu benachrichtigen. Auftragsverarbeiter müssen ihrerseits die Verantwortlichen unverzüglich informieren.

Die Höchststrafen belaufen sich auf 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

4. HIPAA

Das Health Insurance Portability and Accountability Act (HIPAA) legt die Grundvoraussetzungen für den Schutz von Gesundheitsdaten in den USA fest und wird vom HHS Office for Civil Rights durchgesetzt. Wie die DSGVO handelt es sich dabei um ein Gesetz und nicht um einen freiwilligen Rahmen. Es gilt für betroffene Einrichtungen (Gesundheitsdienstleister, Krankenkassen und Clearingstellen im Gesundheitswesen) sowie für deren Geschäftspartner. Ein Cloud-Anbieter, der im Auftrag einer betroffenen Einrichtung elektronische geschützte Gesundheitsdaten (ePHI) erstellt, empfängt, verwaltet oder übermittelt, gilt als Geschäftspartner, selbst wenn er die Daten niemals einsehen darf.

In einer Business-Associate-Vereinbarung (BAA) werden die Pflichten jeder Partei festgelegt und der Anbieter vertraglich verpflichtet, ePHI zu schützen. Ein Cloud-Anbieter in dieser Rolle haftet zudem unmittelbar für die Einhaltung der geltenden HIPAA-Anforderungen, wobei diese Haftung nicht von der BAA abhängt.

Die technischen Anforderungen sind in der Sicherheitsvorschrift festgelegt: Zugriffskontrolle, Prüfmechanismen, Integrität, Übertragungssicherheit und Risikoanalyse. Eine vorgeschlagene Aktualisierung würde die derzeitige Unterscheidung zwischen „erforderlichen“ und „empfehlenswerten“ Vorgaben aufheben und Verschlüsselung, Multi-Faktor-Authentifizierung sowie ein dokumentiertes Bestandsverzeichnis der technischen Ressourcen mit nur wenigen Ausnahmen verbindlich vorschreiben. Bis Oktober 2026 ist diese endgültige Regelung noch immer nicht veröffentlicht worden. In der Regulierungsagenda des HHS wird nun Juli 2027 als Zieltermin genannt, nachdem ein früherer Termin im Mai 2026 bereits verstrichen ist.

5. PCI DSS

Der PCI Security Standards Council veröffentlicht diese Version, und die aktuelle Version ist v4.0.1. Der Name lautet zwar „Standard“, die Durchsetzung erfolgt jedoch auf vertraglicher Basis. Für die Durchsetzung sind Ihre akquirierende Bank und die Kreditkartenunternehmen zuständig, nicht eine staatliche Aufsichtsbehörde.

Die hier relevanten Termine sind bereits abgelaufen. Mit Version 4.0 wurde eine Reihe neuer Anforderungen eingeführt, und die 51 Anforderungen mit einem späteren Stichtag traten am 31. März 2025 in Kraft. Sie gelten nun alle, und es gibt keine Übergangsfrist mehr, auf die man sich stützen könnte.

PCI DSS enthält zudem eine der eindeutigsten Vorgaben zur Installation von Patches auf dieser Liste. Anforderung 6.3.3 besagt, dass Patches für kritische Schwachstellen innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen, während für alle anderen relevanten Patches ein Zeitrahmen gilt, den das Unternehmen auf der Grundlage seiner eigenen Risikoeinstufung festlegt. In der ursprünglichen Fassung (v4.0) wurde dieses einmonatige Zeitfenster kurzzeitig ausgeweitet, um auch Patches mit hohem Schweregrad abzudecken. Der Rat hat dies in Version 4.0.1 wieder auf „nur kritische Schwachstellen“ zurückgesetzt, was die engere, derzeit geltende Anforderung darstellt. Anforderung 11.3.1 schreibt separat vor, dass interne Schwachstellenscans mindestens einmal alle drei Monate sowie nach jeder wesentlichen Änderung durchgeführt werden müssen.

6. ISO/IEC 27001 (Ausgabe 2022)

Im Gegensatz zu ISO/IEC 27017 und 27018 erhalten Sie mit ISO/IEC 27001 erhalten Sie ein echtes, eigenständiges Zertifikat. Eine akkreditierte Zertifizierungsstelle prüft Ihr Informationssicherheits-Managementsystem und stellt alle drei Jahre ein Zertifikat aus, wobei jährliche Überwachungsaudits in der Zwischenzeit die Einhaltung der Anforderungen sicherstellen.

Im Rahmen der Überarbeitung von 2022 wurde Anhang A erheblich überarbeitet, wobei 114 Kontrollmaßnahmen auf 93 zusammengefasst und in vier Themenbereiche gegliedert wurden. Im Zuge dieser Umstrukturierung wurden elf völlig neue Kontrollmaßnahmen eingeführt, darunter Bedrohungsinformationen, Informationssicherheit für Cloud-Dienste und Schutz vor Datenlecks.

Das Übergangsfenster für die Ausgabe 2013 endete am 31. Oktober 2025, und Zertifikate, die noch auf der Ausgabe 2013 basieren, sind nicht mehr gültig. Falls Ihre Organisation den Übergang versäumt hat, müssen Sie mit einem vollständigen Erstzertifizierungsaudit statt mit einem vereinfachten Übergangsaudit rechnen.

7. ISO/IEC 27018 (Ausgabe 2025)

Diese Norm wird vom selben ISO/IEC-Ausschuss wie die ISO/IEC 27017 gepflegt und weist eine ähnliche Struktur auf. Sie ist nicht eigenständig zertifizierbar. Es handelt sich um einen Leitfaden, der ein auf ISO/IEC 27001 basierendes Informationssicherheits-Managementsystem (ISMS) ergänzt, und einige Zertifizierungsstellen bewerten die Einhaltung dieser Norm im Rahmen eines 27001-Audits. Die Norm liegt nun in ihrer dritten Auflage vor, die im August 2025 veröffentlicht wurde und die Version von 2019 ersetzt. Die Kontrollmaßnahmen wurden an ISO/IEC 27002:2022 angepasst und ein neuer Anhang B hinzugefügt.

Während sich 27017 allgemein mit Cloud-Sicherheit befasst, so befasst sich eingehend mit einem speziellen Aspekt: dem Schutz personenbezogener Daten (PII) in öffentlichen Clouds, in denen der Anbieter als Auftragsverarbeiter für diese Daten fungiert. Damit fallen die Einwilligung, die Zweckbindung, die Offenlegung etwaiger Unterauftragsverarbeiter, die Transparenz darüber, wo Daten verarbeitet und gespeichert werden, sowie die Löschung nach Beendigung der Geschäftsbeziehung in den Geltungsbereich.

Es ist die ideale Lösung für Public-Cloud-Anbieter, die ein anerkanntes Set an Datenschutzmaßnahmen suchen, das sich nahtlos auf die Verpflichtungen von Auftragsverarbeitern gemäß der DSGVO abbilden lässt.

8. CSA STAR und die Cloud Controls Matrix

Die Cloud Security Alliance verwaltet beide Komponenten hier, und sie lassen sich leicht miteinander verwechseln. Die Cloud Controls Matrix ist das Kontroll-Framework selbst. STAR ist das darauf aufbauende Zertifizierungsprogramm. CCM v4.1 erschien Ende Januar 2026 mit 11 neuen Kontrollmaßnahmen, wodurch sich die Gesamtzahl auf 207 in denselben 17 Bereichen erhöhte.

STAR umfasst drei Stufen. Stufe 1 ist eine kostenlose Selbsteinschätzung auf der Grundlage des CAIQ-Fragebogens, deren Ergebnisse in einem öffentlichen Register veröffentlicht werden, das jeder einsehen kann. Stufe 2 umfasst zusätzlich eine unabhängige Bewertung durch Dritte, die häufig parallel zu einem bereits laufenden ISO 27001- oder SOC 2-Projekt durchgeführt wird. Die CSA beschreibt zudem eine Stufe 3, die auf kontinuierlichen Audits basiert, doch in dem Register werden Sie tatsächlich nur Einträge der Stufen 1 und 2 finden.

Der praktische Nutzen liegt in der Datenbank selbst. Wenn Sie einen Cloud-Anbieter bewerten, der Daten bei STAR veröffentlicht hat, sind dessen CAIQ-Antworten öffentlich einsehbar und konkret genug, um sie mit den übrigen Nachweisen abzugleichen. Denken Sie jedoch daran, dass die Antworten der Stufe 1 auf Selbstauskünften beruhen.

9. NIST SP 800-53 (Version 5.2.0)

Das NIST veröffentlicht dieses Dokument als Kontrollkatalog und nicht als Zertifizierung; es dient als Grundlage für die FedRAMP-Baselines und wird zudem häufig für die Zuordnung von Kontrollen im privaten Sektor herangezogen.

Die Version 5.2.0 wurde am 27. August 2025 veröffentlicht, und jeder, der für die Installation von Patches zuständig ist, sollte sie lesen. Als Reaktion auf eine Verordnung der Bundesregierung zur Sicherheit von Software-Updates wurden darin eine Verbesserung der Ursachenanalyse für Systemprobleme und -ausfälle – einschließlich fehlgeschlagener Updates (SI-02(07)) –, eine Verbesserung der Protokollierungssyntax (SA-15(13)) sowie eine neue Designkontrolle zur Cyber-Resilienz (SA-24) hinzugefügt.

Das Update betrachtet die Patch-Pipeline selbst als Angriffsfläche, die es zu sichern gilt, und nicht nur die Schwachstellen, zu deren Behebung diese Pipeline dient.

10. NIST-Rahmenwerk für Cybersicherheit 2.0

Auch diese Richtlinie wird vom NIST veröffentlicht; Version 2.0 erschien im Februar 2024. Es handelt sich um freiwillige Leitlinien ohne Zertifizierungsverfahren und ohne die Notwendigkeit, die Anforderungen eines Auditors zu erfüllen.

CSF 2.0 ergänzte die ursprünglichen fünf Funktionen – Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen – um eine sechste Funktion: Steuern. Zudem wurde der Anwendungsbereich über den Schwerpunkt auf kritische Infrastrukturen, der die Version 1.1 prägte, hinaus erweitert und richtet sich nun an Organisationen jeder Größe und aus allen Branchen.

Stellen Sie es sich als Organigramm für Ihr Sicherheitsprogramm vor, dem die detaillierten Kontrollmaßnahmen aus 800-53, CIS oder CCM zugeordnet sind. Das CSF ist zwar nicht besonders gut darin, Ihnen zu sagen, was Sie konfigurieren müssen, aber sehr gut darin, Ihnen aufzuzeigen, wem Sie noch keinen Verantwortlichen zugewiesen haben.

11. FedRAMP

Betrieben vom FedRAMP-PMO unter der Leitung der GSA, FedRAMP genehmigt Cloud-Dienste für die Nutzung durch US-Bundesbehörden, und im Jahr 2026 fand die größte Überarbeitung seit Jahren statt.

FedRAMP hat die konsolidierten Vorschriften für 2026 veröffentlicht. Diese traten am 4. Juli 2026 in Kraft, womit eine Phase der vorzeitigen Einführung begann, und FedRAMP 20x soll Rev5 im Laufe der Zeit ersetzen. Mit der Struktur änderte sich auch die Terminologie. Aus „Autorisierung“ wurde „FedRAMP-Zertifizierung“, die Risikostufen wurden durch die Zertifizierungsklassen A bis D ersetzt, und Anbieter führen keine Aktions- und Meilensteinpläne (POA&Ms) mehr. Stattdessen führen sie Schwachstellenprotokolle und eine Liste akzeptierter Schwachstellen, während Behörden weiterhin eigene POA&Ms für behördeninterne Maßnahmen und Risikobewertungen erstellen können.

Welche Termine maßgeblich sind, hängt davon ab, in welcher Situation Sie sich befinden. Wenn Sie bereits über eine Rev5-Zertifizierung verfügen, werden die „Consolidated Rules“ am 1. Januar 2027 verbindlich, wobei einige Regelwerke eigene Inkrafttretungsdaten und Übergangsfristen vorsehen, von denen die letzte am 1. Februar 2028 endet. Falls Sie noch einen Rev5-Antrag planen: FedRAMP nimmt ab dem 11. Juni 2027 keine neuen Anträge mehr entgegen; danach ist der einzige Weg eine 20x-Zertifizierung. Wenn in Ihren Unterlagen noch „FedRAMP Moderate ATO“ steht, handelt es sich um Rev5-Terminologie, und die für Sie geltende Frist ist der 1. Januar 2027, wenn die konsolidierten Vorschriften verbindlich werden. Es bleibt noch Zeit, aber nicht mehr viel. 

FIPS-validierte Kryptografie spielt hier nach wie vor eine Rolle, auch wenn die neuen Vorschriften ihren Anwendungsbereich einschränken. FedRAMP erwartet nun, dass sensible Daten durch FIPS-140-Verschlüsselung geschützt werden, und verlangt von den Anbietern, dass sie dokumentieren, wo sie diese einsetzen, damit die Behörden die Eignung für ihre eigenen Systeme beurteilen können. Auf AlmaLinux, bietet TuxCare Enterprise Support FIPS-konforme Updates für das gesamte FIPS-Paket (Kernel, OpenSSL, libgcrypt, NSS und GnuTLS) im Rahmen der „Extended Security Updates“ für ausgewählte Nebenversionen bereit. AlmaLinux 9.2 und 9.6 verfügen beide über aktive CMVP-Zertifikate für alle fünf Module, wobei das jüngste im August 2026 ausgestellt wurde. 

12. NIS2-Richtlinie

NIS2, offiziell Richtlinie (EU) 2022/2555, funktioniert anders als eine Verordnung, da es sich um eine Richtlinie handelt. Die Richtlinie ist für die Mitgliedstaaten verbindlich, doch die Verpflichtungen für Unternehmen treten erst in Kraft, sobald jeder Staat sie in nationales Recht umgesetzt hat, und dieser Prozess ist innerhalb der Union uneinheitlich verlaufen.

Die Umsetzungsfrist endete am 17. Oktober 2024. Im Juli 2026 verwies die Europäische Kommission Irland, Spanien, Frankreich und die Niederlande vor den Gerichtshof der Europäischen Union, da sie die vollständige Umsetzung nicht gemeldet hatten, und forderte den Gerichtshof auf, finanzielle Sanktionen zu verhängen. Die Niederlande haben ihr Cybersicherheitsgesetz am 15. August 2026 in Kraft gesetzt, während Irland, Spanien und Frankreich Mitte September noch an ihren jeweiligen Gesetzen arbeiteten. Da es sich bei NIS2 um eine Richtlinie handelt, hängen die Verpflichtungen privater Einrichtungen von den nationalen Umsetzungsgesetzen der einzelnen Staaten ab; daher sollte man die geltenden innerstaatlichen Rechtsvorschriften prüfen, anstatt von einer einheitlichen unmittelbaren Wirkung auszugehen. NIS2 verpflichtet die Mitgliedstaaten, die Leitungsorgane nach nationalem Recht zur Rechenschaft zu ziehen, und die nationalen Vorschriften müssen für wesentliche Stellen Geldbußen in Höhe von mindestens 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes vorsehen, je nachdem, welcher Betrag höher ist.

NIS2 gilt für Unternehmen in 18 Branchen, darunter Cloud-Computing-Anbieter, Rechenzentrumsdienstleister und Anbieter von Managed Security Services.

13. DORA

Das Gesetz über digitale Betriebsresilienz, die Verordnung (EU) 2022/2554, trat im Januar 2023 in Kraft und ist seit dem 17. Januar 2025 in vollem Umfang anwendbar. Die europäischen Aufsichtsbehörden koordinieren dessen Umsetzung.

DORA gilt unmittelbar für Finanzinstitute in der gesamten EU und stützt sich auf fünf Säulen: IKT-Risikomanagement, Meldung von Vorfällen, Prüfung der digitalen Betriebsresilienz, IKT-Risikomanagement in Bezug auf Dritte sowie Informationsaustausch.

Die Säule der Drittanbieter wird von Cloud-Anbietern häufig übersehen. Finanzinstitute müssen die Anforderungen der DORA in ihre IKT-Verträge aufnehmen, und ein Anbieter, der als kritischer IKT-Drittanbieter eingestuft wird, unterliegt der direkten Aufsicht durch eine federführende Aufsichtsbehörde, die aus den Europäischen Aufsichtsbehörden (ESAs) stammt. Das bedeutet, dass der Verkauf von Infrastruktur an EU-Banken dazu führen kann, dass Sie in den Geltungsbereich der DORA fallen, auch wenn Sie selbst kein Finanzinstitut sind.

14. CIS-Benchmarks und CIS-Kontrollen, Version 8.1

Das Center for Internet Security veröffentlicht hier zwei miteinander verbundene Ressourcen: die „Controls“, eine nach Priorität geordnete Sammlung von Sicherheitsmaßnahmen, und die „Benchmarks“, plattformspezifische Konfigurationsrichtlinien. Keine der beiden ist im herkömmlichen Sinne zertifizierbar.

CIS Controls v8.1, veröffentlicht im Juni 2024, gliedert 18 priorisierte Kontrollmaßnahmen anhand von Risiko, Ressourcen und Komplexität in drei Umsetzungsgruppen ein, sodass für ein kleines Team und ein großes Unternehmen nicht dieselben Ausgangserwartungen gelten. CIS-Benchmarks sind das Pendant auf Konfigurationsebene: Leitfäden zur Absicherung, die für bestimmte Plattformen verfasst wurden, darunter AWS Foundations, Azure Foundations, GCP, Kubernetes und wichtige Linux-Distributionen.

Bei Benchmarks werden Standards nicht mehr nur abstrakt, sondern geben Ihnen konkrete Hinweise darauf, welche Einstellungen Sie ändern sollten. Viele Tools für das Cloud-Posture-Management bieten bereits standardmäßig CIS-Benchmark-Prüfungen an, was sie zu einem der einfachsten Einstiegspunkte auf dieser Liste macht.

Für AlmaLinux, umfasst der TuxCare Enterprise Support umfasst Unterstützung bei der Sicherheitshärtung, die CIS- und STIG-Kontrollen auf Compliance-Rahmenwerke wie PCI DSS und ISO 27001 abbildet.

Best Practices für Cloud-Sicherheit

Standards legen fest, was nachgewiesen werden muss. Diese fünf Vorgehensweisen zeigen, wie Teams die entsprechenden Nachweise tatsächlich erbringen.

Regelmäßige Sicherheitsbeurteilungen

Führen Sie Bewertungen in festgelegten Abständen durch und nicht nur dann, wenn ein Prüfer vor der Tür steht. Die Häufigkeit variiert je nach Standard – einige schreiben jährliche Zyklen vor, andere sind risikobasiert und sehen keine festen Intervalle vor. Die PCI-DSS-Anforderung 12.5.2 sieht zusätzlich zu dem von Ihnen gewählten Rhythmus eine jährliche Überprüfung des Umfangs vor.

Aus wirtschaftlicher Sicht spricht einiges dafür, daran festzuhalten. Der IBM-Bericht „Cost of a Data Breach 2026“ beziffert die durchschnittlichen Kosten einer Datenpanne weltweit auf 4,99 Millionen US-Dollar – ein Anstieg um 12 % und ein neuer Rekord, der den kurzen Rückgang des Vorjahres wieder zunichte macht.

Die Abweichung vom Umfang ist der Fehlermodus, auf den man besonders achten sollte. Stellen Sie sich ein 40-köpfiges SaaS-Team vor, das für eine Migration eine Staging-Umgebung einrichtet, vergisst, diese außer Betrieb zu nehmen, und sie monatelang außerhalb der festgelegten Grenzen stehen lässt.

Wenn bei einer Überprüfung überhaupt nichts festgestellt wird, ist der Untersuchungsumfang wahrscheinlich zu eng gefasst. Wenn dabei jedes Quartal dieselben drei Probleme festgestellt werden, liegt das Problem eher bei der Zuständigkeit für die Behebung als bei der Erkennung.

Scannen auf Schwachstellen

Führen Sie zusätzlich zu externen Scans authentifizierte Scans innerhalb der Umgebung durch. Bei nicht authentifizierten externen Scans werden Schwachstellen auf Paketebene in laufenden Workloads übersehen – und genau dort befinden sich tatsächlich viele der ausnutzbaren Schwachstellen.

Die Mindesthäufigkeit variiert je nach Standard stark. PCI DSS schreibt interne und externe Scans alle drei Monate sowie nach jeder wesentlichen Änderung vor, wobei die erforderlichen externen Scans von einem zugelassenen Scan-Anbieter (Approved Scanning Vendor) durchgeführt werden müssen. Die technischen Standards von DORA verlangen automatisierte Schwachstellenscans mindestens einmal wöchentlich für IKT-Ressourcen, die kritische oder wichtige Funktionen unterstützen, jährliche Tests der hinter diesen Funktionen stehenden Systeme sowie bedrohungsorientierte Penetrationstests mindestens alle drei Jahre für die von den Aufsichtsbehörden benannten Einrichtungen. Die vorgeschlagene HIPAA-Aktualisierung würde automatisierte Scans mindestens alle sechs Monate und Penetrationstests mindestens einmal jährlich vorschreiben. CIS Controls v8.1 verlangt automatisierte Scans interner Ressourcen mindestens vierteljährlich (Safeguard 7.5) und extern exponierter Ressourcen mindestens monatlich (Safeguard 7.6). NIS2 bleibt risikobasiert und überlässt die Einzelheiten den einzelnen Mitgliedstaaten.

Ergebnisse mit dem CISA-Katalog bekannter ausgenutzter Sicherheitslücken abgleichen, bevor Sie Maßnahmen zur Behebung priorisieren. Ein CVSS-Wert allein führt dazu, dass eine aktiv ausgenutzte Schwachstelle mit einem Wert von 7,5 unter einem Berg theoretischer Schwachstellen mit einem Wert von 9,8 begraben wird, für die keine Ausnutzung bekannt ist.

Die oben genannten Kadenzregeln gehen davon aus, dass ein Scanner bereits behobene Probleme korrekt meldet – unter Linux trifft diese Annahme jedoch oft nicht zu. Distributionen portieren Sicherheitskorrekturen zurück, ohne die Versionsnummer des Upstreams zu ändern, und ein ohne Neustart im Speicher angewendeter Patch wird bei einer Überprüfung der Paketversion möglicherweise gar nicht angezeigt. TuxCare Radar überprüft den tatsächlichen Patch-Status, einschließlich Patches ohne Neustart und durch ELS abgedeckter Korrekturen, die bei einer einfachen Versionsprüfung übersehen würden, sodass ein Scan-Zyklus nicht zu einem manuellen Abgleich zwischen den Angaben des Scanners und denen Ihrer Patch-Protokolle wird.

Starke Zugangskontrollen

Durchsetzen die Multi-Faktor-Authentifizierung für jedes Benutzerkonto mit Konsolenzugriff durch, ohne Ausnahmen für Dienstinhaber oder Auftragnehmer. PCI DSS v4.x hat die MFA über Administratoren hinaus auf alle Zugriffe in die Karteninhaberdatenumgebung ausgeweitet, mit einer engen Ausnahme für Konten, die eine phishingresistente Authentifizierung verwenden, und die vorgeschlagene HIPAA-Aktualisierung geht in die gleiche Richtung.

Über MFA hinaus sollten Sie den rollenbasierten Zugriff mit dem Prinzip der geringsten Berechtigungen als Standard festlegen und diesen mindestens vierteljährlich überprüfen. Trennen Sie Identitäten von Menschen und Maschinen voneinander und vermeiden Sie gemeinsame Anmeldedaten für Dienstkonten in CI-Pipelines. Bevorzugen Sie kurzlebige Anmeldedaten gegenüber langlebigen API-Schlüsseln, sofern der Anbieter dies unterstützt. Dokumentieren Sie außerdem Ihren „Joiner-Mover-Leaver“-Prozess, da Prüfer diesen regelmäßig stichprobenartig überprüfen.

Datenverschlüsselung

Die Verschlüsselung von Daten im Ruhezustand und während der Übertragung sollte als Mindestanforderung gelten. Gerade bei der Schlüsselverwaltung scheitern Audits häufig: Wer verwahrt die Schlüssel, wie oft werden sie gewechselt und können Sie genau nachweisen, was der Anbieter entschlüsseln darf und was nicht?

Bei regulierten Workloads ist die Implementierung ebenso wichtig wie die Wahl des Algorithmus selbst. In US-Bundesbehörden sind in der Regel FIPS 140-3-validierte Kryptografiemodule vorgeschrieben, wo immer zugelassene Kryptografie vorgeschrieben ist, und auch in kommerziellen Verträgen werden diese zunehmend gefordert. TLS 1.2 ist die Mindestanforderung, und TLS 1.3 ist das Ziel, sofern Ihr Stack dies unterstützt.

Achtung: Die Verschlüsselung im Ruhezustand mit vom Anbieter verwalteten Schlüsseln erfüllt zwar viele Compliance-Anforderungen, schützt jedoch in erster Linie vor Risiken auf der Speicherebene, wie beispielsweise einer gestohlenen Festplatte oder unsachgemäß entsorgten Speichermedien. Sie bietet keinerlei Schutz vor kompromittierten Zugangsdaten innerhalb Ihres eigenen Kontos, mit denen eine Entschlüsselung möglich ist. Auditoren gehen selten auf diesen Unterschied ein. Angreifer nutzen ihn jedoch regelmäßig aus.

Regelmäßige Patches und Updates

Genau an dieser Stelle scheitern die meisten Cloud-Compliance-Programme still und leise. Auf dem Papier klingen die Kontrollmaßnahmen einfach, in der Praxis erweisen sie sich jedoch als schwer umsetzbar, da das Installieren eines Patches für einen Produktionskernel in der Regel einen Neustart erfordert – und ein Neustart bedeutet, dass mit allen Beteiligten, die auf diese Verfügbarkeit angewiesen sind, ein Wartungsfenster ausgehandelt werden muss.

Die Uhr wird in mehreren Standards ausdrücklich erwähnt:

Ein Zeitfenster von 30 Tagen klingt großzügig, bis man die tatsächlich erforderlichen Schritte zählt: Triage, Test, Terminierung, Benachrichtigung, Neustart, Überprüfung, Dokumentation. Bei einer Flotte von einigen hundert Hosts, für die Verfügbarkeits-SLAs einzuhalten sind, kann das den größten Teil des Monats in Anspruch nehmen, bevor der Patch überhaupt in die Produktion gelangt.

Abschließende Überlegungen

Wählen Sie Ihre Standards zunächst nach den gesetzlichen Anforderungen aus, dann nach den Anforderungen der Kunden, und belassen Sie es dabei. Wenn kleine Sicherheitsteams ISO 27001, SOC 2 und CSA STAR gleichzeitig umsetzen, nur weil auf der Vertrauensseite eines Mitbewerbers alle drei aufgeführt sind, verschwenden sie ein ganzes Jahr mit Dokumentation statt mit Kontrollmaßnahmen.

Eines gilt unabhängig davon, welche Standards für Sie gelten: Bei fast allen wird von Ihnen erwartet, dass Sie bekannte Sicherheitslücken aufspüren und beheben und dass Sie Nachweise vorlegen können, die Sie auf Verlangen vorlegen müssen. Die Art der Zertifizierung variiert. Die Durchsetzung variiert. Bei den meisten dieser Programme hängt es jedoch von den Patch-Maßnahmen ab, ob diese Nachweise termingerecht vorgelegt werden oder nicht.

Unbegrenzter Lebenszyklus-Support sorgt dafür, dass Sicherheitsupdates auch nach Ablauf des Herstellersupports weiterhin für Betriebssysteme, Sprach-Runtimes und Bibliotheken bereitgestellt werden, deren Lebenszyklus abgelaufen ist. So erhalten nicht mehr unterstützte Komponenten weiterhin Korrekturen, anstatt zu einer dauerhaften Compliance-Lücke zu werden. Für die Open-Source-Abhängigkeiten, auf die Ihre Cloud-Workloads zurückgreifen, bietet SecureChain bietet Teams geprüfte private Repositorien für JavaScript-, Python-, Java-, Go-, Rust- und PHP-Pakete, was die in ISO/IEC 27017 und CCM v4.1 beschriebenen Kontrollen der Lieferkette unterstützt. TuxCare Enterprise Support deckt die FIPS-validierte Kryptografie und Compliance-Härtung ab, die in Bundesbehörden und anderen regulierten Umgebungen häufig gefordert wird. Und KernelCare wendet Kernel-Patches ohne Neustart an, sodass die Einhaltung der von PCI DSS und ähnlichen Standards festgelegten Fristen nicht von der Genehmigung eines Wartungsfensters abhängt. Sie testen, überprüfen und dokumentieren weiterhin wie bei jedem anderen Patch, aber der Neustart entfällt aus dem Zeitplan.

Haben Sie Fragen dazu, welche dieser Standards für Ihre Umgebung gelten oder wo genau die Nachweislücken in Ihrem Compliance-Programm liegen? Sprechen Sie mit einem Sicherheitsexperten von TuxCare.

Zusammenfassung

Artikel Name

Die 14 wichtigsten Rahmenwerke für Cloud-Sicherheitsstandards im Jahr 2026

Beschreibung

ISO 27017, SOC 2, FedRAMP, NIS2, DORA und weitere. Was die einzelnen Cloud-Sicherheitsstandards im Jahr 2026 von Ihnen verlangen und wie sie tatsächlich durchgesetzt werden.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers