DSGVO-konforme Cloud: woran Sie eine erkennen

Was eine DSGVO-konforme Cloud ausmacht

Wer nach einer DSGVO-konformen Cloud sucht, sucht meistens nach einer einzigen Eigenschaft, die alles erledigt. Die gibt es nicht. Konformität entsteht aus drei Ebenen, die unabhängig voneinander scheitern können: dem Vertrag zwischen Ihnen und dem Anbieter, der technischen Architektur der Plattform und dem Betriebsmodell, nach dem im Alltag gearbeitet wird.

Auf der Vertragsebene geht es um die Auftragsverarbeitung. Sie bleiben verantwortlich für die Daten, der Anbieter verarbeitet sie in Ihrem Auftrag und in Ihrem Rahmen. Dazu gehören Weisungsrechte, eine benannte Liste der eingesetzten Unterauftragnehmer, Regeln für Löschung und Rückgabe und die Frage, was bei einer Störung passiert. Ein Anbieter, der seine Unterauftragnehmer nicht vollständig benennen kann, kann auch nicht erklären, wer an Ihren Daten arbeitet.

Auf der Architekturebene geht es um Datenhaltung, Verschlüsselung, Netzwerksegmentierung und Zugriffskontrolle. Diese Dinge gehören in die Plattform selbst und nicht in ein nachgelagertes Add-on, das später aufgesetzt wird. Wer Governance und Security erst nach dem Aufbau einplant, baut sie in eine Umgebung ein, die bereits läuft, und das ist ungleich teurer.

Auf der Betriebsebene geht es um die Frage, die in Audits am häufigsten unbeantwortet bleibt: Wer hat administrativen Zugriff auf die kritischen Systeme, Dienstleister eingeschlossen, und ist das dokumentiert? Solange diese Frage offen ist, hilft weder der Standort noch das schönste Zertifikat.

Die drei Fragen hinter jeder DSGVO-Diskussion über Cloud

Unabhängig davon, wie eine Cloud technisch aussieht, kommen in der Praxis immer dieselben drei Fragen auf den Tisch. Sie zu kennen hilft, ein Anbietergespräch in eine brauchbare Richtung zu lenken.

Wer verarbeitet in wessen Auftrag?

Die Auftragsverarbeitung ist der Rahmen, in dem ein Cloud-Anbieter überhaupt tätig werden darf. Interessant ist weniger, ob ein Vertrag existiert, sondern ob er das beschreibt, was tatsächlich passiert. Wenn ein Anbieter Support aus mehreren Zeitzonen leistet, gehört das hinein. Wenn Backups an einem zweiten Ort liegen, gehört das hinein. Verträge, die allgemeiner sind als der Betrieb, den sie abbilden sollen, fallen spätestens im Audit auf.

Verlassen Daten den Rechtsraum, und wer kann darauf zugreifen?

Ein Drittlandtransfer beginnt nicht erst dann, wenn Daten physisch kopiert werden. Auch ein administrativer Fernzugriff aus einem anderen Rechtsraum ist ein Zugriff. Genau hier setzt die Diskussion um den Cloud Act an: Sie betrifft nicht nur den Ort der Festplatte, sondern die Frage, welchem Recht das Unternehmen unterliegt, das die Systeme betreut. Für die Praxis heißt das: Klären Sie, aus welchen Ländern heraus administriert wird und wie dieser Zugriff protokolliert ist.

Was passiert im Fehlerfall?

Meldepflichten, Wiederanlauf und Nachweisführung sind keine Themen für den Ernstfall, sondern für den Aufbau. Wenn niemand sagen kann, wie lange ein Wiederanlauf dauert und woher die Konfiguration dafür kommt, existiert der Notfallplan nur auf dem Papier. Ein reproduzierbarer Wiederanlauf aus dokumentierter Konfiguration ist deshalb auch ein Compliance-Merkmal und nicht nur ein technisches.

Warum ein deutsches Rechenzentrum allein nicht reicht

Der Satz, der in diesem Markt am häufigsten fällt, lautet: Die Server stehen in Deutschland, also ist alles in Ordnung. Das ist die Hälfte der Wahrheit. Der Standort ist eine notwendige Bedingung für viele Anforderungen, aber er ist keine hinreichende. Kontrolle entsteht aus dem Betriebsmodell, nicht aus der Postleitzahl des Rechenzentrums.

Daraus folgen zwei Fehlschlüsse, die beide teuer sind. Der erste: im eigenen Rechenzentrum, also souverän. Ein Server im eigenen Haus ist noch keine Kontrolle, solange nicht dokumentiert ist, wer administrativen Zugriff hat, solange die Plattform sich aus der Dokumentation nicht reproduzieren lässt und solange niemand weiß, was mit dem Betrieb passiert, wenn das Team nicht verfügbar ist. Viele On-Premise-Landschaften erfüllen die Standortanforderung perfekt und die Nachweisanforderung überhaupt nicht.

Der zweite Fehlschluss: bei einem Dienstleister, also nicht souverän. Auch das stimmt so nicht. Ein Betriebspartner, der Zugriffe protokolliert, Konfiguration als Code führt und den Wiederanlauf regelmäßig prüft, liefert mehr Nachvollziehbarkeit als ein Eigenbetrieb, in dem drei Personen historisch gewachsene Rechte haben. Die Frage ist nicht, ob jemand anders beteiligt ist, sondern ob die Beteiligung geregelt und nachvollziehbar ist.

Praktisch lässt sich das an vier Merkmalen prüfen, die nichts mit dem Standort zu tun haben: nachvollziehbare Zugriffe, dokumentierte Konfiguration, reproduzierbarer Wiederanlauf und Wechselfähigkeit beim Betriebspartner. Wer alle vier belegen kann, hat eine belastbare Grundlage. Wer nur den Standort nennen kann, hat einen Marketingsatz.

Kostenloses Whitepaper · 7 Seiten

Your Own Cloud in Your Own Datacenter

Von Andreas Hankel, CTO onehundred. Download gegen E-Mail-Adresse, ohne Vertriebsanruf.

Whitepaper laden

Sieben Kriterien, an denen Sie einen Cloud-Anbieter prüfen

Die folgenden Punkte lassen sich in einem Erstgespräch abfragen. Sie sind bewusst so formuliert, dass eine ausweichende Antwort auffällt.

• Zertifikate und Prüfberichte. ISO 27001 belegt ein Managementsystem für Informationssicherheit, ein BSI-C5-Testat beschreibt geprüfte Kriterien für Cloud-Dienste. Beides ist ein Hinweis auf Prozessreife. Fragen Sie nach, worauf sich das Zertifikat bezieht: auf das Rechenzentrum, auf den Anbieter oder auf einen einzelnen Dienst. Anbieter, die zertifizierte Rechenzentren nutzen, sind damit nicht selbst zertifiziert. Wer diesen Unterschied verwischt, verwischt auch andere.
• Administrativer Zugriff. Wer kann sich auf welchen Systemen anmelden, aus welchem Land heraus, und wie wird das protokolliert? Gibt es ein Vier-Augen-Prinzip für kritische Eingriffe?
• Unterauftragnehmer. Eine vollständige, aktuelle Liste mit Zweck und Ort. Änderungen sollten angekündigt werden, nicht nachträglich auffallen.
• Verschlüsselung und Schlüsselverwaltung. Verschlüsselung im Transport ist selbstverständlich. Interessanter ist die Verschlüsselung im Ruhezustand und die Frage, wer die Schlüssel hält und wie sie gewechselt werden.
• Wiederanlauf und Backup. Wie lange dauert ein vollständiger Wiederanlauf, wann wurde er zuletzt geprüft, und liegen Backups so, dass sie einen Angriff auf die Produktionsumgebung überstehen?
• Exit-Fähigkeit. In welchem Format bekommen Sie Ihre Daten und Ihre Konfiguration zurück, und wie lange dauert das? Ein Anbieter, dessen Plattform nur er selbst bedienen kann, ist ein Risiko unabhängig von seinem Standort. Bei uns liegen Konfigurationen als Git-Repositories beim Kunden, und der Stack ist so gewählt, dass jeder kompetente Dienstleister ihn übernehmen kann.
• Betriebsmodell. Gibt es Rufbereitschaft rund um die Uhr, Monitoring und Alerting, ein geregeltes Patch- und Eskalationsmanagement? Compliance ohne Betriebsdisziplin hält genau bis zum ersten Zwischenfall.

Keines dieser Kriterien ist exotisch. Auffällig ist eher, wie oft sie in Ausschreibungen fehlen, während der Serverstandort dreimal abgefragt wird.

On-Premise, Private Cloud oder Public Cloud im Vergleich

Die Entscheidung zwischen den drei Modellen fällt selten für ein ganzes Unternehmen, sondern sinnvollerweise pro Workload. Die folgende Übersicht vergleicht qualitativ, ohne Preise und ohne pauschale Wertung.

Die Tabelle zeigt vor allem eines: Die klassische Gegenüberstellung on premise gegen Cloud greift zu kurz, weil sie die mittlere Spalte unterschlägt. Eine Private Cloud übernimmt das Betriebsmodell der Public Cloud und die Kontrollmerkmale des eigenen Rechenzentrums. Genau deshalb landen viele Landschaften am Ende hybrid: planbare, datenintensive Workloads in der eigenen oder gemieteten Umgebung, stark schwankende oder eng an verwaltete Dienste gebundene Workloads dort, wo sie sind.

Colocation und eigenes Rechenzentrum: was sich damit ändert

Zwischen der eigenen Serverfläche und einem Rechenzentrum in Deutschland liegt die Colocation: Sie stellen eigene Hardware in ein fremdes, professionell betriebenes Rechenzentrum. Strom, Kühlung, physische Sicherheit und Anbindung kommen vom Betreiber, die Systeme bleiben Ihre.

Für die DSGVO-Frage ändert Colocation zunächst wenig, denn die Verantwortung für Daten und Zugriffe bleibt bei Ihnen. Praktisch ändert sie viel: Die physische Sicherheit und die Verfügbarkeit der Fläche sind vertraglich zugesichert und geprüft, was sich im Audit deutlich leichter belegen lässt als eine Klimaanlage im eigenen Keller. Hardware bleibt dabei ein Asset des Unternehmens statt einer Betriebskostenposition in einem fremden Ökosystem.

Wann sich welcher Betriebsort anbietet

• Eigenes Rechenzentrum, wenn es bereits existiert und modernisiert statt abgeschafft werden soll, oder wenn Latenz zu Produktionsanlagen eine Rolle spielt.
• Colocation, wenn Sie Kontrolle über die Hardware behalten wollen, aber weder Fläche noch Gebäudetechnik selbst verantworten möchten.
• Deutsches Rechenzentrum eines Betreibers, wenn Sie gar keine eigene Hardware beschaffen wollen. Ein eigenes Rechenzentrum ist keine Voraussetzung für eine Private Cloud. Wir wählen in diesem Fall ein deutsches, ISO-27001-zertifiziertes Rechenzentrum aus und betreiben die Plattform dort. Die Daten verlassen diese Rechenzentren nicht.

In allen drei Fällen bleibt die entscheidende Ebene dieselbe: die Plattform darüber. Ohne Automatisierung, Self-Service und dokumentierte Konfiguration ist auch das beste Rechenzentrum nur ein Raum mit Servern darin.

Cloud Repatriation: wann die Rückverlagerung sinnvoll ist

Rückverlagerung aus der Public Cloud ist kein Trendbruch, sondern eine Korrektur einzelner Entscheidungen. Der Gang in die Cloud war in den meisten Fällen richtig, und für viele Workloads bleibt er es. Die Korrektur betrifft die Fälle, in denen sich die Rechnung nicht mehr trägt oder in denen regulatorische Anforderungen später dazugekommen sind.

Wann eine Rückverlagerung sich rechnet

• Die Last ist planbar und wächst stetig statt sprunghaft. Elastizität, die nie gebraucht wird, zahlt sich nicht aus.
• Der Workload ist datenintensiv, und ein spürbarer Teil der Rechnung entfällt auf Datenverkehr nach außen und zwischen Zonen.
• Die Daten müssen ohnehin in einem bestimmten Rechtsraum bleiben, und jede Ausnahme kostet Freigabeaufwand.
• Es gibt eine Nachweispflicht gegenüber Kunden oder Aufsicht, die sich mit geteilter Verantwortung nur mühsam abbilden lässt.

Wann sie es nicht tut

• Der Workload hängt tief an verwalteten Diensten, deren Nachbau mehr kostet, als die Migration einspart.
• Die Last schwankt stark und unvorhersehbar.
• Es gibt niemanden, der die Plattform danach betreibt. Rückverlagerung ohne Betriebsmodell verschiebt das Problem nur.

Der häufigste Fehler ist nicht die falsche Richtung, sondern die fehlende Plattformschicht. Wer zurückverlagert und dabei bei Ticket-gesteuerter Provisionierung landet, verliert Self-Service und Elastizität und damit genau das, wofür die Cloud ursprünglich gewählt wurde. Die Fachabteilung ist an Minuten gewöhnt und bekommt Tage. Dieser Akzeptanzverlust taucht in keiner Kostenrechnung auf und kippt trotzdem Projekte. Eine realistische Rechnung enthält deshalb auch den Betriebsaufwand der eigenen Plattform, nicht nur Hardware und Fläche.

Cloud-Sicherheit ist Betriebsdisziplin, kein Produkt

Compliance und Sicherheit überschneiden sich, sind aber nicht dasselbe. Ein Setup kann vertraglich sauber und technisch angreifbar sein. Die Maßnahmen, die im Betrieb tatsächlich wirken, sind unspektakulär und werden genau deshalb oft aufgeschoben.

• Rechte minimieren und regelmäßig prüfen. Historisch gewachsene Administratorrechte sind der häufigste Befund in Bestandsumgebungen.
• Patch-Management mit festem Rhythmus. Sicherheitsupdates brauchen Wartungsfenster, auch nachts und an Feiertagen. Wer sie einplanen muss, plant sie irgendwann nicht mehr ein.
• Netzwerksegmentierung. Ein kompromittierter Dienst sollte nicht den Weg zu allen anderen öffnen.
• Backups prüfen, nicht nur anlegen. Ein Backup, dessen Rückspielung nie getestet wurde, ist eine Annahme.
• Monitoring und Alerting mit echter Reaktion. Sie sollten von einer Störung aus dem Bericht des Betriebs erfahren und nicht von Ihren Nutzern.

Die ausführliche Fassung dieser Punkte steht in unserem Artikel Sicherheit in der Cloud: Best Practices für Unternehmen. Für die Compliance-Perspektive ist vor allem eines wichtig: Alle genannten Maßnahmen erzeugen Nachweise, wenn sie regelmäßig und dokumentiert stattfinden. Nachweise entstehen im Betrieb und lassen sich vor einem Audit nicht nachträglich herstellen.

Vorgehen: von der Bestandsaufnahme zur Zielarchitektur

Ein Projekt, das mit der Anbieterwahl beginnt, beginnt zu spät. Die Reihenfolge, die sich in der Praxis bewährt, sieht anders aus.

1. Workloads erfassen und klassifizieren. Welche Daten, welche Anforderungen, welche Last, welche Abhängigkeiten? Fünf große Workloads reichen für den Anfang, der Rest folgt dem Muster.
2. Zugriffe dokumentieren. Wer kann heute auf welche Systeme administrativ zugreifen, Dienstleister eingeschlossen? Diese Liste ist unangenehm und der wichtigste Einzelschritt.
3. Zielbild je Workload entscheiden. Public Cloud, eigene oder gemietete Umgebung, hybrid. Mit Kosten und Risiken, nicht als Grundsatzbeschluss.
4. Plattform vor Migration. Erst die Schicht mit Automatisierung, Self-Service und Konfiguration als Code, dann die Workloads darauf. Andersherum entsteht wieder eine Landschaft, die niemand reproduzieren kann.
5. Migration mit Rückfallweg. Service für Service statt Stichtag, an jedem Übergang eine Go-Entscheidung, die auch Nein lauten darf.
6. Betrieb und Nachweise. Monitoring, Patch- und Eskalationsmanagement, geprüfter Wiederanlauf. Ab hier entstehen die Belege, die im Audit gebraucht werden.

Wir arbeiten in fünf Phasen mit einer Go-oder-No-Go-Entscheidung an jedem Übergang: Analyse, Zielbild, Testumgebung, Migration, Betrieb. Der Sinn dieser Struktur ist nicht die Struktur, sondern die Ausstiegsmöglichkeit: Nach jeder Phase können Sie aufhören, ohne dass etwas Produktives umgestellt wurde.