ISO 27017 und 27018,
die Cloud-Erweiterungen

ISO/IEC 27017 und ISO/IEC 27018 sind beide Verhaltensregeln — Kontrollleitlinien, keine für sich zertifizierbaren Standards. Jede nimmt das bekannte Kontrollset aus ISO/IEC 27002 und erweitert es auf die Realität des Cloud Computing, wo die Grenze zwischen dem, der eine Kontrolle betreibt, und dem, der sich auf sie verlässt, nicht mehr offensichtlich ist.

ISO/IEC 27017 deckt Cloud-Sicherheit ab: wie die generischen ISO/IEC 27002-Kontrollen umzusetzen sind, wenn der betreffende Dienst in der Cloud läuft, plus einige wenige Kontrollen, die nur im Cloud-Kontext existieren. ISO/IEC 27018 deckt speziell den Datenschutz in der Cloud ab: wie ein Anbieter, der eine Public Cloud betreibt, die personenbezogenen Daten (PII) schützen sollte, die ihm seine Kunden anvertrauen.

Entscheidend ist von Anfang an: Sie zertifizieren sich nicht gegen 27017 oder 27018 für sich allein. Sie werden als Erweiterung einer ISO/IEC 27001-Zertifizierung umgesetzt und geprüft — Sie ziehen ihre Kontrollen in Ihr Managementsystem, und eine akkreditierte Zertifizierungsstelle prüft sie zusammen mit dem Rest Ihres ISMS. Wenn Sie ohnehin in ISO 27001 denken, behandeln Sie diese beiden als Ergänzungen zu diesem Geltungsbereich, nicht als separate Projekte.

ISO/IEC 27017, veröffentlicht 2015, ist die Verhaltensregel für Informationssicherheitskontrollen für Cloud-Dienste. Das meiste davon ist Umsetzungsleitlinie: Für die bereits in ISO/IEC 27002 aufgeführten relevanten Kontrollen erklärt sie, was "die Kontrolle umzusetzen" tatsächlich bedeutet, sobald das System in der Cloud eines anderen liegt statt in einem Serverraum, der Ihnen gehört.

Über diese Leitlinien hinaus ergänzt 27017 eine kleine Reihe von Kontrollen, die nur im Cloud-Kontext Sinn ergeben. Dazu gehören die geteilten Rollen und Verantwortlichkeiten zwischen dem Cloud-Service-Provider und dem Cloud-Service-Kunden, das Entfernen und die Rückgabe von Kundenwerten bei Vertragsende, die Härtung virtueller Maschinen, die Sicherheit administrativer Vorgänge am Cloud-Dienst und die Überwachung des Cloud-Dienstes selbst.

Sie ist für beide Seiten der Beziehung geschrieben. Ein Cloud-Service-Provider liest sie, um zu verstehen, was er seinen Kunden schuldet; ein Cloud-Service-Kunde liest sie, um zu verstehen, was er weiterhin selbst tun muss und was er vernünftigerweise vom Anbieter erwarten darf. Genau wegen dieser doppelten Zielgruppe steht das Modell der geteilten Verantwortung im Zentrum des Standards.

ISO/IEC 27018, erstmals 2014 veröffentlicht und 2019 überarbeitet, ist die Verhaltensregel zum Schutz personenbezogener Daten in Public Clouds, die als PII-Auftragsverarbeiter handeln. Wo es bei 27017 um Sicherheit in der Cloud im Allgemeinen geht, geht es bei 27018 eng um Datenschutz: was ein Public-Cloud-Anbieter tun muss, wenn die Daten, die er hält, seinen Kunden gehören und reale Personen identifizieren.

Sie ergänzt datenschutzorientierte Kontrollen und Leitlinien über der ISO/IEC 27002-Grundlinie. Die Themen sind jedem vertraut, der mit modernem Datenschutzrecht gearbeitet hat: Einwilligung und Wahlmöglichkeit über die Nutzung von PII, Zweckbindung, Transparenz über Unterauftragsverarbeiter und den Speicherort der Daten, die Möglichkeit, PII zurückzugeben oder zu löschen, und, als prägende Bestimmung, Kunden-PII nicht für eigene Zwecke des Anbieters wie Werbung zu nutzen.

Wegen dieses Fokus verbindet sich 27018 natürlich mit Datenschutzregulierung. Sie ersetzt weder die GDPR noch das Schweizer nFADP, und sie zu halten ist nicht dasselbe wie mit einer von beiden konform zu sein — aber die geforderten Kontrollen decken sich eng mit dem, was diese Gesetze von einem Auftragsverarbeiter erwarten, weshalb sie in Datenschutzprüfungen europäischer und Schweizer Kunden häufig verlangt wird.

Der wichtigste Punkt zu beiden Standards ist struktureller Natur: Sie leben innerhalb einer ISO/IEC 27001-Zertifizierung, nicht daneben. Es gibt kein eigenständiges "ISO 27017-Zertifikat" oder "ISO 27018-Zertifikat", wie es ein ISO 27001-Zertifikat gibt. Stattdessen entscheiden Sie, dass die 27017- und/oder 27018-Kontrollen im Geltungsbereich Ihres Informationssicherheits-Managementsystems liegen, setzen sie um und lassen sie von Ihrer Zertifizierungsstelle im selben Audit prüfen.

Für ein Team, das ISO 27001 bereits hält oder aktiv anstrebt, ist das wirklich eine gute Nachricht. Sie stellen kein zweites Managementsystem auf, wiederholen keine frische Risikobewertung von Grund auf und buchen keinen separaten Audit-Zyklus. Sie erweitern den Geltungsbereich des ISMS, das Sie bereits betreiben, und fügen der Statement of Applicability, die Sie bereits pflegen, eine definierte Reihe von Cloud- und Datenschutzkontrollen hinzu.

Praktisch heisst das: Die Reihenfolge zählt. ISO 27001 kommt zuerst; 27017 und 27018 werden aufgesetzt, sobald dieses Fundament besteht. Den Cloud-Erweiterungen ohne das darunterliegende Managementsystem hinterherzulaufen heisst, das Dach vor den Wänden zu errichten.

Beide Standards beruhen auf derselben Idee: In der Cloud kontrolliert keine einzelne Partei alles, also werden Sicherheit und Datenschutz zwischen dem Cloud-Service-Provider und dem Cloud-Service-Kunden geteilt. Der Anbieter sichert die Teile, die er betreibt; der Kunde sichert die Teile, die er konfiguriert, und die Daten, die er einspielt. Eine Kontrolle, die in einem Aufbau ganz Sache des Anbieters ist, kann in einem anderen teilweise oder ganz Sache des Kunden sein.

Die meisten Cloud-Vorfälle, die Schlagzeilen machen, sind nicht der Anbieter, der seine Hälfte verfehlt — es ist ein Kunde, der annimmt, der Anbieter habe eine Kontrolle abgedeckt, während die Verantwortung dafür eigentlich bei ihm lag. ISO/IEC 27017 investiert echte Mühe, diese Aufteilung explizit zu machen, gerade weil die Unklarheit der Ort ist, an dem Dinge schiefgehen.

Für Ihr eigenes ISMS bedeutet das: Jede Kontrolle im Geltungsbereich braucht einen Eigentümer, schriftlich festgehalten: unser, der des Anbieters oder geteilt mit klarer Grenze. Diese Zuordnung ehrlich zu machen ist der grösste Teil der Arbeit bei der Einführung von 27017 und 27018 — und genau der Teil, den Teams überspringen, wenn sie die Standards als Checkliste statt als Arbeitsteilung behandeln.

Diese Standards werden meist von Cloud-Service-Providern und SaaS-Anbietern verfolgt — Teams, deren Produkt in der Cloud läuft und deren Kunden ihre Daten hindurchleiten. Der Auslöser ist fast immer extern: Die Sicherheits- oder Datenschutzprüfung eines Interessenten verlangt zusätzlich zu ISO 27001 cloud-spezifische Sicherheitszusicherung (27017) oder Cloud-PII-Schutz (27018), und der Deal stockt, bis Sie darauf verweisen können.

ISO 27017 kommt meist auf, wenn ein Kunde Wert darauf legt, wie seine Workloads in Ihrer Cloud gesichert sind — die Härtung, der Administratorzugang, die saubere Rückgabe seiner Werte beim Austritt. ISO 27018 kommt auf, wenn der Kunde selbst für personenbezogene Daten verantwortlich ist und seinen eigenen Regulierern zeigen muss, dass sein Auftragsverarbeiter PII verantwortungsvoll behandelt. Für einen europäischen oder Schweizer Käufer, der die GDPR oder das Schweizer nFADP abwägt, ist diese 27018-Zeile im Geltungsbereich Ihres Zertifikats eine Abkürzung durch einen langen Fragebogen.

Wenn Sie kein Cloud-Anbieter sind oder Ihre Kunden nie cloud- oder PII-spezifische Bedenken geäussert haben, lohnt sich der zusätzliche Geltungsbereich vielleicht noch nicht. Der ehrliche Test ist derselbe wie bei jedem Framework: Kosten oder verzögern diese Fragen Deals? Wenn ja, ist es meist günstiger, Ihren ISO 27001-Geltungsbereich zu erweitern, um sie sauber zu beantworten, als sie für immer ad hoc zu beantworten.

Weil 27017 und 27018 auf einer ISO 27001-Zertifizierung aufsetzen, folgt die Mechanik dem 27001-Audit, das Sie bereits kennen. Sie fügen die Cloud- und Datenschutzkontrollen Ihrer Statement of Applicability hinzu, setzen sie um, sammeln die Nachweise, dass sie funktionieren, und die akkreditierte Zertifizierungsstelle prüft sie in denselben Stage-1- und Stage-2-Audits sowie im selben jährlichen Überwachungs- und dreijährigen Rezertifizierungszyklus wie den Rest Ihres ISMS.

Es gibt kein separates Zertifikat zum Aufhängen. Was sich ändert, ist die Geltungsbereichsangabe auf Ihrem ISO 27001-Zertifikat: Sie hält fest, dass die 27017- und/oder 27018-Kontrollen einbezogen und geprüft wurden. Genau nach dieser einen Zeile sucht der Prüfer eines Kunden, daher lohnt es sich, die Formulierung des Geltungsbereichs richtig zu treffen, statt die Cloud-Erweiterungen implizit zu lassen.

Was die Reihenfolge angeht, ist der günstigste Weg, die Erweiterungen in eine Rezertifizierung oder ein geplantes Überwachungsaudit zu falten, statt mitten im Zyklus zusätzliche Auditzeit zu buchen — aber wenn ein Deal darauf wartet, können Zertifizierungsstellen einen zusätzlichen Geltungsbereich früher prüfen. So oder so liegt die eigentliche Arbeit bei den Kontrollen, nicht bei der Audit-Logistik.

Cloud-Landschaften ändern sich schneller als fast alles andere in einem ISMS. Neue Dienste werden eingeführt, Unterauftragsverarbeiter kommen und gehen, Daten wandern zwischen Regionen, und Administratorzugang wird wöchentlich erteilt und entzogen. Die 27017- und 27018-Kontrollen sind nur so gut, wie aktuell dieses Bild ist — eine vor achtzehn Monaten dokumentierte Aufteilung der geteilten Verantwortung wird gegen eine seither weiterentwickelte Architektur ein Überwachungsaudit nicht überstehen.

Dieselbe Pflegedisziplin, die ISO 27001 am Leben hält, hält auch diese aktuell: die Verantwortungszuordnung korrekt, die Aufzeichnungen zu Unterauftragsverarbeitern und Datenstandort auf dem neuesten Stand, die Nachweise fliessend statt vor jedem Audit rekonstruiert. Weil die Cloud-Erweiterungen im selben Managementsystem sitzen, ist die Pflege geteilte Arbeit, einmal über den gesamten Geltungsbereich erledigt, statt eines zweiten Ordners, der für sich am Leben gehalten werden muss.