ISO 27017 beantwortet eine Frage, die in Cloud-Verträgen regelmäßig unbeantwortet bleibt: Wer sorgt für welche Sicherheitsmaßnahme — der Anbieter oder der Kunde? Die Norm nimmt den Maßnahmenkatalog der ISO 27002 und schreibt zu einem großen Teil der Maßnahmen cloudspezifische Hinweise dazu, getrennt nach den beiden Rollen. Ergänzt wird sie um sieben eigene Maßnahmen, die es außerhalb der Cloud nicht gibt.
Sie ist damit kein eigenständiges Managementsystem, sondern ein Aufsatz. Wer sie umsetzt, hat in aller Regel bereits ein ISMS nach ISO 27001 oder baut es gerade auf. Der Anlass ist fast immer der Vertrieb: Ein Großkunde schickt einen Sicherheitsfragebogen, in dem nach cloudspezifischen Nachweisen gefragt wird, und die reine ISO 27001 reicht als Antwort nicht mehr aus.
Der Grund für diese Lücke liegt in der Bauweise der ISO 27001. Ihr Maßnahmenkatalog ist bewusst technikneutral formuliert, damit er für eine Werkstatt genauso gilt wie für ein Rechenzentrum. Genau diese Neutralität wird zum Problem, sobald geklärt werden muss, wer eine virtuelle Maschine härtet oder wie Mandanten voneinander getrennt sind. ISO 27017 füllt diese Lücke, ohne den Aufbau des Managementsystems anzutasten.
Die geteilte Verantwortung ist der Kern
Der wesentliche Beitrag der Norm ist nicht die Liste der Maßnahmen, sondern die Zweiteilung. Zu jeder relevanten Maßnahme steht, was der Anbieter des Cloud-Dienstes umzusetzen hat und was der Kunde. Diese Aufteilung ist in der Praxis die häufigste Ursache für Sicherheitsvorfälle in Cloud-Umgebungen: Beide Seiten gehen davon aus, dass die andere zuständig ist.
Das klassische Beispiel ist die Sicherung von Daten. Der Anbieter garantiert die Verfügbarkeit der Plattform, sichert aber nicht zwangsläufig die Inhalte des Kunden gegen versehentliches Löschen. Ähnlich bei Zugriffsrechten: Die Plattform stellt ein Rechtesystem bereit, wer es falsch konfiguriert, hat trotzdem ein offenes Datenverzeichnis. ISO 27017 zwingt beide Seiten, diese Grenze schriftlich zu ziehen, statt sie im Vertragswerk zu umschiffen.
Wie die Aufteilung ausfällt, hängt vom Betriebsmodell ab. Bei reiner Infrastruktur liegt fast alles oberhalb der virtuellen Maschine beim Kunden: Betriebssystem, Aktualisierungen, Anwendungen, Rechte. Bei einer fertigen Anwendung verschiebt sich nahezu alles zum Anbieter, beim Kunden bleiben Benutzerverwaltung, Rechtevergabe und der Umgang mit den eigenen Inhalten. Dazwischen liegt der Bereich, in dem Streit entsteht — Plattformdienste, bei denen der Anbieter die Laufzeitumgebung stellt und der Kunde den Code. Die Norm gibt keine Musterverteilung vor. Sie verlangt, dass die Verteilung benannt und beiden Seiten bekannt ist.
Die sieben cloudspezifischen Maßnahmen
Die eigenen Maßnahmen der Norm tragen das Präfix CLD und lassen sich in drei Gruppen ordnen: Rollen und Daten, Virtualisierung, Betrieb.
| Maßnahme | Worum es geht | Was in der Praxis daran hängt |
|---|---|---|
| Geteilte Rollen und Verantwortlichkeiten | Festlegen, wer welche Maßnahme umsetzt | Eine Verantwortungsmatrix, die Vertrieb, Betrieb und Kunde kennen |
| Entfernung von Kundendaten | Rückgabe und Löschung bei Vertragsende | Dokumentierte Löschfristen, Umgang mit Sicherungskopien |
| Trennung in virtuellen Umgebungen | Mandanten dürfen einander nicht erreichen | Netz- und Speichertrennung, Nachweis der Isolation |
| Härtung virtueller Maschinen | Sichere Grundkonfiguration von Instanzen | Gehärtete Abbilder, Abschalten nicht benötigter Dienste |
| Administrative Betriebssicherheit | Absicherung hochprivilegierter Tätigkeiten | Getrennte Administrationszugänge, mehrstufige Anmeldung, Protokollierung |
| Überwachung der Cloud-Dienste | Der Kunde muss die eigene Nutzung überwachen können | Zugängliche Protokolle und Schnittstellen für den Kunden |
| Gleichlauf virtueller und physischer Netze | Ein Regelwerk für beide Netzebenen | Keine Sonderwege für virtuelle Netzsegmente |
Besonders unterschätzt wird die vorletzte Maßnahme. Sie verpflichtet den Anbieter, dem Kunden überhaupt die Möglichkeit zur Überwachung zu geben. Viele Anbieter erfüllen ihre eigenen Anforderungen an Protokollierung sauber, stellen dem Kunden aber keine auswertbaren Daten bereit. Im Audit ist das eine Feststellung, weil der Kunde damit seine eigene Sorgfaltspflicht nicht erfüllen kann.
Für wen sich die Erweiterung lohnt
Sinnvoll ist ISO 27017 für Anbieter, deren Geschäft an Sicherheitsfragebögen hängt: SaaS-Häuser, Managed-Service-Provider, Rechenzentrumsbetreiber, Anbieter von Branchensoftware mit Betriebsleistung. Sie beantwortet Fragen, die die reine ISO 27001 offen lässt, und ersetzt einen erheblichen Teil individueller Kundenaudits.
Für Cloud-Kunden lohnt sie sich, wenn die eigene Cloud-Nutzung erheblich ist und intern geregelt werden muss. Dann dient die Norm als Prüfliste für die Anbieterauswahl und für die eigene Konfiguration. Eine Zertifizierung ist in dieser Rolle selten nötig — die Kundenspalte der Norm als Grundlage für die Lieferantenbewertung zu verwenden, reicht meist aus.
Wenig sinnvoll ist die Erweiterung in drei Fällen. Wer noch kein ISMS betreibt, sollte zuerst die ISO 27001 aufbauen; ISO 27017 ohne Unterbau ist nicht prüfbar. Wer nur Standard-Bürodienste aus der Cloud nutzt und selbst nichts anbietet, hat keinen Adressaten für das Zertifikat. Und wer im deutschen öffentlichen Sektor verkauft, wird oft trotzdem nach dem C5-Testat gefragt — dann ist zu klären, ob beides gebraucht wird oder eines genügt.
Der Weg zum Nachweis
Der Ablauf der Zertifizierung folgt dem normalen Muster mit Stufe-1- und Stufe-2-Audit, Überwachung und Rezertifizierung. Der Unterschied liegt im Prüfgegenstand, nicht im Verfahren: Geprüft wird das ISMS nach ISO 27001, erweitert um die cloudspezifischen Maßnahmen.
Zwei Vorarbeiten entscheiden über den Aufwand. Erstens muss das Statement of Applicability die CLD-Maßnahmen aufnehmen und für jede die Umsetzung oder den begründeten Ausschluss benennen. Zweitens braucht es eine Zuordnungstabelle zwischen der Nummerierung der ISO 27017 und der aktuellen Struktur der ISO 27002, weil die Cloud-Norm noch der älteren Gliederung folgt. Wer diese Tabelle nicht mitbringt, verbringt den ersten Audittag mit Suchen.
Der zeitliche Zuschlag gegenüber einem reinen ISO-27001-Audit hält sich in Grenzen, weil der Auditor ohnehin im Rechenzentrumsumfeld prüft. Er wächst dort, wo Nachweise fehlen: Jede Maßnahme ohne belegte Umsetzung erzeugt Rückfragen, und cloudspezifische Nachweise lassen sich schlechter improvisieren als organisatorische. Wer die CLD-Maßnahmen erst kurz vor dem Termin einbaut, verschiebt den Aufwand nur in das Nachaudit.
Der Geltungsbereich verdient dabei mehr Sorgfalt als üblich. Zu benennen ist nicht nur die Organisationseinheit, sondern der konkrete Dienst: welche Plattform, welche Rechenzentrumsstandorte, welche Betriebsmodelle. Ein Zertifikat, dessen Geltungsbereich „Cloud-Dienste” lautet, hilft im Vertrieb nicht weiter, weil der Kunde nicht erkennt, ob sein Produkt darunterfällt.
Woran Projekte im Audit scheitern
Die Verantwortungsmatrix existiert nur als Folie. Es gibt eine Darstellung im Vertrieb, aber keine verbindliche Fassung, die Vertragsbestandteil ist und im Betrieb gilt. Der Auditor fragt nach dem Dokument, nicht nach der Präsentation.
Löschung endet vor den Sicherungskopien. Die Produktivdaten werden bei Vertragsende gelöscht, die Backups laufen 90 Tage weiter, und niemand hat dem Kunden das jemals gesagt. Die Maßnahme zur Entfernung von Kundendaten verlangt genau diese Transparenz.
Trennung wird behauptet, nicht belegt. Mandantentrennung ist im Architekturbild eingezeichnet, ein Nachweis über Konfiguration oder Test fehlt. Zunehmend wird hier ein Prüfergebnis erwartet, kein Schaubild.
Administrationszugänge laufen über normale Arbeitsplätze. Administratoren nutzen dieselben Geräte und Konten wie für E-Mail und Recherche. Das ist die häufigste Hauptabweichung in diesem Umfeld, weil ein kompromittierter Arbeitsplatz sofort die gesamte Plattform betrifft.
Der Kunde bekommt keine Protokolle. Es wird umfassend protokolliert, aber ausschließlich für den eigenen Betrieb. Für den Kunden gibt es keine Schnittstelle und keinen Auszug.
Unterauftragnehmer stehen nicht in der Kette. Der Dienst läuft auf fremder Infrastruktur, die eigene Verantwortungsmatrix endet aber an der eigenen Softwaregrenze. Wer weiterverkauft, muss die Kette bis zur physischen Ebene abbilden.
Der Notfallplan endet an der Plattformgrenze. Für den Ausfall der eigenen Anwendung gibt es ein Vorgehen, für den Ausfall des zugrunde liegenden Anbieters keines. Genau dieses Szenario ist der Grund, warum Kunden zusätzlich nach ISO 22301 fragen.
Konfigurationsvorgaben ohne Prüfung. Es gibt eine Härtungsrichtlinie für virtuelle Maschinen, aber keine regelmäßige Kontrolle, ob laufende Instanzen ihr entsprechen. Genau diese Lücke sucht ein internes Audit, das seinen Namen verdient.
Abgrenzung zu verwandten Normen und Prüfschemata
| Regelwerk | Gegenstand | Verhältnis zu ISO 27017 |
|---|---|---|
| ISO 27001 | Managementsystem für Informationssicherheit | Voraussetzung; ISO 27017 wird als Erweiterung geprüft |
| ISO 27002 | Umsetzungshinweise zu den Maßnahmen | Grundlage; ISO 27017 ergänzt cloudspezifische Hinweise |
| ISO 27018 | Personenbezogene Daten in öffentlichen Clouds | Gleiche Bauweise, anderes Schutzziel; oft gemeinsam geprüft |
| ISO 27701 | Managementsystem für Datenschutz | Weiter gefasst, erfasst auch die Rolle des Verantwortlichen |
| BSI C5 | Prüfkatalog für Cloud-Dienste mit Prüfbericht | Höhere Nachweistiefe, im deutschen Behördenumfeld häufig gefordert |
| SOC 2 | Prüfbericht nach US-Standard | International verbreitet, Typ 2 prüft die Wirksamkeit über einen Zeitraum |
| ISO 22301 | Business Continuity | Deckt Ausfallszenarien ab, die Cloud-Kunden vertraglich absichern wollen |
Die praktische Reihenfolge ist meist eindeutig: zuerst ISO 27001, dann die Erweiterungen, die der Markt tatsächlich abfragt. Wer alle Schemata gleichzeitig angeht, bindet Kapazität, die im Betrieb fehlt — und liefert am Ende Nachweise, nach denen niemand gefragt hat.