ISO 27001 A.5.23: Cloud-Dienste sicher nutzen

TL;DR

A.5.23 ist ein neues Control in der ISO 27001:2022 und fordert, dass Unternehmen Prozesse für den Erwerb, die Nutzung, das Management und den Ausstieg aus Cloud-Diensten definieren.
Das Shared-Responsibility-Modell bestimmt, wer für welche Sicherheitsaspekte verantwortlich ist. Die Verantwortung variiert je nach Servicemodell (IaaS, PaaS, SaaS) erheblich.
Eine Cloud-Nutzungsrichtlinie legt fest, welche Dienste erlaubt sind, welche Daten in die Cloud dürfen und welche Sicherheitsanforderungen Cloud-Anbieter erfüllen müssen.
Jeder Cloud-Dienst braucht eine Risikobewertung, die Datenlokation, Compliance-Anforderungen, Verfügbarkeits-SLAs und Abhängigkeiten berücksichtigt.
Eine Exit-Strategie ist kein optionaler Luxus, sondern Pflicht. Sie beschreibt, wie du Daten vom Anbieter zurückholst und den Dienst ohne Datenverlust ablöst.

Warum Cloud ein eigenes Control bekommen hat

In der Vorgängerversion ISO 27001:2013 kam das Wort „Cloud" praktisch nicht vor. Cloud-Dienste wurden unter allgemeine Controls wie Lieferantenmanagement oder Netzwerksicherheit subsumiert. Das war 2013 vielleicht noch vertretbar, aber 2022 nutzt so gut wie jedes Unternehmen Cloud-Dienste, ob als Microsoft 365, als AWS-Infrastruktur, als SaaS-ERP oder als scheinbar harmlose Projektmanagement-App.

Die ISO 27001:2022 hat darauf reagiert und mit A.5.23 ein dediziertes Control für Cloud-Dienste eingeführt. Der vollständige Titel lautet „Information security for use of cloud services" und die Anforderung ist klar: Unternehmen müssen Prozesse definieren, die den gesamten Lebenszyklus von Cloud-Diensten abdecken, vom Erwerb über die Nutzung und das laufende Management bis zum Ausstieg.

Für ein Unternehmen mit rund 100 Mitarbeitenden ist das besonders relevant, weil die Cloud-Nutzung hier oft gewachsen statt geplant ist. Einzelne Abteilungen haben Dienste eingeführt – ein typisches Shadow-IT-Problem – die IT hat davon teilweise erst erfahren, als die erste Rechnung kam. Die Folge: ein unübersichtliches Geflecht aus Cloud-Diensten ohne einheitliche Sicherheitsstandards.

Was der Standard konkret fordert

A.5.23 verlangt laut ISO 27002:2022, dass die Organisation einen themenspezifischen Ansatz für Cloud-Dienste entwickelt, der folgende Aspekte abdeckt:

Anforderungsdefinition: Bevor ein Cloud-Dienst beschafft wird, müssen die Informationssicherheitsanforderungen definiert werden. Welche Daten sollen in den Dienst fließen? Welchen Schutzbedarf haben diese Daten? Welche regulatorischen Anforderungen gelten?

Anbieterauswahl und -bewertung: Die Auswahl eines Cloud-Anbieters muss auf Basis definierter Kriterien erfolgen. Dazu gehören Zertifizierungen (ISO 27001, SOC 2), Standort der Datenverarbeitung, Verschlüsselungsmechanismen, Verfügbarkeits-SLAs und die Erfüllung vertraglicher Sicherheitsanforderungen.

Definition von Rollen und Verantwortlichkeiten: Das Shared-Responsibility-Modell muss für jeden Cloud-Dienst geklärt und dokumentiert sein. Wer ist für welche Sicherheitsaspekte verantwortlich: der Cloud-Anbieter oder das eigene Unternehmen?

Laufendes Management: Cloud-Dienste müssen kontinuierlich überwacht werden. Sicherheitskonfigurationen, Zugriffsrechte, Compliance-Status und Verfügbarkeit müssen regelmäßig geprüft werden.

Ausstieg (Exit): Es muss eine Strategie geben, wie Daten vom Anbieter zurückgeholt und der Dienst beendet werden kann, ohne Daten zu verlieren oder die Geschäftskontinuität zu gefährden.

Das Shared-Responsibility-Modell verstehen

Das Shared-Responsibility-Modell ist das zentrale Konzept bei der Nutzung von Cloud-Diensten. Es beschreibt die Aufteilung der Sicherheitsverantwortung zwischen Cloud-Anbieter und Kunde. Die genaue Aufteilung hängt vom Servicemodell ab.

Infrastructure as a Service (IaaS)

Bei IaaS (z.B. AWS EC2, Azure Virtual Machines, Hetzner Cloud) stellt der Anbieter die physische Infrastruktur bereit: Rechenzentrum, Server-Hardware, Netzwerk, Speicher. Die Verantwortung für alles darüber liegt beim Kunden: Betriebssystem, Middleware, Anwendungen, Daten, Zugriffsrechte, Verschlüsselung, Patch Management, Firewall-Regeln.

Das bedeutet für ein Unternehmen mit rund 100 Mitarbeitenden: Wenn du virtuelle Server in der Cloud betreibst, musst du sie genauso patchen, härten und überwachen wie On-Premises-Server. Die Cloud nimmt dir nur die physische Infrastruktur ab.

Platform as a Service (PaaS)

Bei PaaS (z.B. Azure App Service, AWS Elastic Beanstalk, Heroku) übernimmt der Anbieter zusätzlich das Betriebssystem, die Runtime und die Middleware. Der Kunde ist verantwortlich für die Anwendung, die Daten, die Zugriffssteuerung und die Konfiguration der Plattform.

Software as a Service (SaaS)

Bei SaaS (z.B. Microsoft 365, Salesforce, Slack, HubSpot) übernimmt der Anbieter nahezu die gesamte technische Verantwortung. Der Kunde ist verantwortlich für die Konfiguration des Dienstes, die Zugriffssteuerung, die Klassifizierung der Daten und die Einhaltung regulatorischer Anforderungen hinsichtlich der Daten, die er in den Dienst eingibt.

Dokumentation der Verantwortungsteilung

Für jeden Cloud-Dienst sollte eine Responsibility-Matrix existieren, die für die relevanten Sicherheitsdomänen dokumentiert, wer verantwortlich ist. ISMS Lite unterstützt dich dabei mit cloud-relevanten Controls und konkreten Umsetzungshinweisen, sodass du weißt, welche Aspekte du pro Dienst dokumentieren musst. Die Domänen umfassen typischerweise: physische Sicherheit, Netzwerksicherheit, Betriebssystem-Sicherheit, Anwendungssicherheit, Datensicherheit, Identitäts- und Zugriffsmanagement, Verschlüsselung, Backup, Incident Response, Compliance und Audit.

Ein Auditor wird fragen: „Wer ist für die Verschlüsselung der Daten at rest in Ihrem CRM-System verantwortlich?" Wenn du diese Frage nicht beantworten kannst, hast du das Shared-Responsibility-Modell nicht ausreichend durchdrungen.

Die Cloud-Nutzungsrichtlinie

Eine Cloud-Nutzungsrichtlinie setzt den Rahmen für die gesamte Cloud-Strategie des Unternehmens. Sie sollte folgende Kapitel enthalten:

Geltungsbereich und Definitionen

Definiere, was unter „Cloud-Dienst" fällt. Das klingt trivial, ist es aber nicht. Zählt die gehostete Webseite? Das Online-Backup? Die Videokonferenz-Software? Die Antwort sollte lauten: Ja, alles, worüber Unternehmensdaten verarbeitet, gespeichert oder übertragen werden und das von einem externen Anbieter als Dienst bereitgestellt wird.

Klassifizierung und Freigabe

Nicht jeder Cloud-Dienst muss den gleichen Prüfungsprozess durchlaufen. Definiere Kategorien basierend auf dem Schutzbedarf der Daten:

Kategorie 1 (Standard): Cloud-Dienste, die nur öffentliche oder interne Daten mit normalem Schutzbedarf verarbeiten. Hier reicht eine vereinfachte Prüfung mit Standardkriterien.

Kategorie 2 (Erweitert): Cloud-Dienste, die vertrauliche Daten oder personenbezogene Daten verarbeiten. Hier ist eine vollständige Risikobewertung erforderlich, inklusive Prüfung der Zertifizierungen, des Vertragswerks und der technischen Sicherheitsmaßnahmen.

Kategorie 3 (Kritisch): Cloud-Dienste, die streng vertrauliche Daten verarbeiten oder geschäftskritische Prozesse unterstützen. Hier sind zusätzlich Penetrationstests, Audits beim Anbieter oder detaillierte Sicherheitsfragebögen erforderlich.

Anforderungen an Cloud-Anbieter

Definiere Mindestanforderungen, die jeder Cloud-Anbieter erfüllen muss:

ISO 27001 Zertifizierung oder gleichwertiger Nachweis (SOC 2 Type II)
Datenverarbeitung innerhalb der EU oder in Ländern mit angemessenem Datenschutzniveau
Verschlüsselung der Daten in Transit (TLS 1.2+) und at Rest (AES-256)
Verfügbarkeits-SLA mit definierten Werten (mindestens 99,5 % für geschäftskritische Dienste)
Möglichkeit zum vollständigen Datenexport in einem standardisierten Format
Dokumentierter Incident-Response-Prozess mit definierten Benachrichtigungsfristen
Auftragsverarbeitungsvertrag (AVV) bei Verarbeitung personenbezogener Daten

Verbotene Nutzungsformen

Die Richtlinie sollte klar benennen, was nicht erlaubt ist:

Nutzung privater Cloud-Speicher (Dropbox-Privataccount, Google Drive mit privater E-Mail) für Unternehmensdaten
Einrichtung von Cloud-Diensten ohne Freigabe durch die IT oder den ISB
Speicherung streng vertraulicher Daten in Cloud-Diensten ohne Genehmigung
Nutzung von Cloud-Diensten, die keine Verschlüsselung bieten

Risikobewertung für Cloud-Dienste

Jeder Cloud-Dienst der Kategorie 2 oder 3 braucht eine individuelle Risikobewertung. Die folgenden Risikokategorien solltest du systematisch durchgehen.

Datenlokation und Rechtsraum

Wo werden die Daten physisch gespeichert? In welchem Rechtsraum operiert der Anbieter? Haben Behörden des Anbieterlandes Zugriff auf die Daten (Stichwort: US CLOUD Act)? Gibt es eine Möglichkeit, die Datenverarbeitung auf die EU zu beschränken?

Für ein Unternehmen mit rund 100 Mitarbeitenden, das DSGVO-pflichtige Daten verarbeitet, ist die Datenlokation ein kritischer Faktor. Die Nutzung eines US-Anbieters ist nicht automatisch ausgeschlossen, erfordert aber zusätzliche Schutzmaßnahmen (Standardvertragsklauseln, Transfer Impact Assessment, Verschlüsselung mit eigener Schlüsselhoheit).

Verfügbarkeit und Abhängigkeit

Wie abhängig ist dein Geschäftsbetrieb von diesem Cloud-Dienst? Was passiert, wenn der Dienst für Stunden oder Tage ausfällt? Gibt es einen Workaround oder einen alternativen Dienst?

Berechne die Auswirkung eines Ausfalls auf deine Geschäftsprozesse. Wenn dein ERP-System als SaaS läuft und ausfällt, können keine Rechnungen geschrieben, keine Aufträge bearbeitet und keine Lieferungen veranlasst werden. Das ist ein ganz anderes Risiko als der Ausfall eines Projektmanagement-Tools.

Vendor Lock-in

Wie leicht kannst du den Anbieter wechseln? Gibt es standardisierte Export-Formate? Sind die Datenstrukturen proprietär? Wie hoch ist der Migrationsaufwand?

Vendor Lock-in ist eines der am häufigsten unterschätzten Risiken bei Cloud-Diensten. Wenn du ein Jahr lang Daten in einem proprietären System gesammelt hast und der Anbieter die Preise verdoppelt, die Geschäftsbedingungen ändert oder den Dienst einstellt, brauchst du eine realistische Möglichkeit, die Daten zu extrahieren und den Dienst zu wechseln.

Datenintegrität und Backup

Wer ist für das Backup der Daten im Cloud-Dienst verantwortlich? Viele Unternehmen gehen davon aus, dass der Cloud-Anbieter automatisch Backups erstellt. Das ist bei IaaS grundsätzlich falsch und bei SaaS oft nur eingeschränkt richtig. Microsoft 365 zum Beispiel bietet keine langfristige Wiederherstellung gelöschter Daten. Wenn ein Mitarbeitender eine Datei löscht und du es erst nach 90 Tagen bemerkst, kann die Datei unwiederbringlich verloren sein.

Kläre für jeden Cloud-Dienst: Werden Backups erstellt? Durch wen? Wie lange werden sie aufbewahrt? Wie funktioniert die Wiederherstellung? Brauchst du ein zusätzliches Backup durch einen Drittanbieter?

Multi-Tenant-Risiken

Die meisten Cloud-Dienste sind Multi-Tenant-Systeme, bei denen mehrere Kunden die gleiche Infrastruktur teilen. Das birgt theoretische Risiken wie Side-Channel-Angriffe, Datenlecks zwischen Mandanten oder „Noisy Neighbors", die die Performance beeinträchtigen. Bei etablierten Anbietern mit ISO-27001-Zertifizierung sind diese Risiken in der Regel angemessen adressiert, sollten aber in der Risikobewertung dokumentiert werden.

Exit-Strategie

Die Exit-Strategie ist der Teil von A.5.23, den die meisten Unternehmen vernachlässigen. Sie wird erst dann relevant, wenn es zu spät ist: wenn der Anbieter den Dienst einstellt, die Preise unerträglich werden, ein Sicherheitsvorfall beim Anbieter das Vertrauen zerstört oder regulatorische Anforderungen einen Wechsel erzwingen.

Bestandteile einer Exit-Strategie

Datenexport-Plan: Welche Daten müssen exportiert werden? In welchem Format? Wie groß ist das Datenvolumen? Wie lange dauert der Export? Bietet der Anbieter eine API oder einen Bulk-Export?

Zielumgebung: Wohin werden die Daten migriert? In einen anderen Cloud-Dienst? Auf eigene Infrastruktur? In ein neues System, das die gleiche Funktion erfüllt?

Zeitrahmen: Wie lange dauert die Migration realistisch? Berücksichtige nicht nur den technischen Export, sondern auch die Konfiguration des neuen Systems, die Datenmigration, Tests und die Umschulung der Mitarbeitenden.

Vertragliche Regelungen: Welche Kündigungsfristen gelten? Stellt der Anbieter die Daten nach Vertragsende für einen definierten Zeitraum zur Verfügung? In welchem Format? Werden die Daten nach der Rückgabe beim Anbieter gelöscht?

Kosten: Was kostet die Migration? Entstehen beim Anbieter Kosten für den Datenexport (Egress Fees)?

Regelmäßige Tests

Eine Exit-Strategie, die nur auf dem Papier existiert, hilft im Ernstfall wenig. Teste den Datenexport regelmäßig, mindestens einmal pro Jahr für geschäftskritische Cloud-Dienste. Prüfe, ob die exportierten Daten vollständig und nutzbar sind. Dokumentiere die Testergebnisse.

Typische Audit-Findings bei A.5.23

Finding 1: Kein Inventar der Cloud-Dienste

Der Auditor fragt nach einer Übersicht aller Cloud-Dienste und erhält keine vollständige Liste. Einzelne Abteilungen nutzen Dienste, die der IT nicht bekannt sind (Shadow IT).

Vermeidung: Führe ein Cloud-Dienst-Inventar, das mindestens den Dienstnamen, den Anbieter, das Servicemodell, den Datentyp, den Verantwortlichen und das Vertragsenddatum enthält. Überprüfe das Inventar regelmäßig, z.B. durch Analyse der Zahlungsströme.

Finding 2: Shared Responsibility nicht dokumentiert

Es existiert kein Dokument, das die Verantwortungsteilung zwischen Anbieter und Unternehmen beschreibt. Die IT-Abteilung hat ein intuitives Verständnis, aber nichts Schriftliches.

Vermeidung: Erstelle für jeden Cloud-Dienst der Kategorie 2 und 3 eine Responsibility-Matrix.

Finding 3: Keine Exit-Strategie

Der Auditor fragt: „Was passiert, wenn Anbieter X den Dienst einstellt?" und bekommt keine dokumentierte Antwort.

Vermeidung: Dokumentiere für jeden geschäftskritischen Cloud-Dienst eine Exit-Strategie mit den oben genannten Bestandteilen.

Finding 4: Cloud-Dienste ohne Risikobewertung

Cloud-Dienste wurden eingeführt, ohne dass eine Risikobewertung stattgefunden hat. Die Entscheidung basierte auf Funktionalität und Preis, Sicherheitsaspekte wurden nicht systematisch geprüft.

Vermeidung: Integriere die Risikobewertung in den Beschaffungsprozess. Kein Cloud-Dienst der Kategorie 2 oder 3 darf ohne abgeschlossene Risikobewertung freigeschaltet werden.

Wie ISMS Lite den Nachweis unterstützt

583 Controls mit Umsetzungshinweisen: ISMS Lite enthält 11 Frameworks mit insgesamt 583 Controls – darunter alle cloud-relevanten Controls wie A.5.23. Jedes Control wird mit praxisnahen Implementierungsempfehlungen geliefert, sodass du genau weißt, was zu tun ist.

KI-gestützte Richtlinienerstellung: Die lokale KI unterstützt dich bei der Erstellung deiner Cloud-Nutzungsrichtlinie, Exit-Strategie und weiterer Dokumente – basierend auf den Anforderungen der Controls.

Strukturierte Dokumentation: Alle Bewertungen, Richtlinien und Nachweise lassen sich versioniert und mit Freigabe-Workflows dokumentieren – ideal für den Audit-Nachweis.

Verknüpfung verwandter Controls: Cloud-Sicherheit betrifft viele Controls gleichzeitig (Lieferantenmanagement, Kryptografie, Business Continuity). ISMS Lite zeigt dir die Zusammenhänge und hilft, nichts zu übersehen.

Zusammenspiel mit anderen Controls

A.5.23 steht nicht isoliert. Es interagiert eng mit mehreren anderen Controls:

A.5.19-A.5.22 (Lieferantenmanagement): Cloud-Anbieter sind Lieferanten und müssen entsprechend bewertet und überwacht werden.
A.5.1 (Richtlinien): Die Cloud-Nutzungsrichtlinie ist eine der themenspezifischen Richtlinien, die A.5.1 fordert.
A.8.24 (Kryptografie): Verschlüsselungsanforderungen für Cloud-Dienste leiten sich aus der Kryptografie-Richtlinie ab.
A.5.29-A.5.30 (Business Continuity): Die Verfügbarkeit von Cloud-Diensten ist Teil der Business-Continuity-Planung.
A.8.10 (Informationslöschung): Bei Beendigung eines Cloud-Dienstes muss sichergestellt sein, dass die Daten beim Anbieter gelöscht werden.

Wenn du A.5.23 sauber umsetzt, erleichterst du dir die Arbeit bei all diesen verwandten Controls erheblich. Und umgekehrt: Wenn du bei A.5.23 Lücken hast, werden sich diese bei den verwandten Controls ebenfalls bemerkbar machen.

Weiterführende Artikel

ISO 27001 Annex A Cloud-Sicherheit Shared Responsibility Exit-Strategie ISMS A.5.23