Cloud-Daten­platt­form

Eine Datenplattform ist nur so zuverlässig wie die Infrastruktur darunter. Wo die Daten liegen, wer zugreifen darf, wie Änderungen ausgerollt werden und was der Betrieb kostet, wird in Projekten oft früh und nebenbei entschieden. Später lassen sich diese Entscheidungen nur mit Aufwand korrigieren.

Hier geht es um den technischen Unterbau: Rechen- und Speicherdienste, Netzwerk, Identitäten, Verschlüsselung, Umgebungen, Backup und Kosten. Wie die Daten darin strukturiert werden, steht bei Data Warehouse und Data Lakehouse, Regeln zu Qualität und Zuständigkeiten gehören zur Data Governance. Eine Plattform, die mit der Zeit teurer oder langsamer geworden ist, behandeln wir unter Datenplattform optimieren.

Cloud, eigenes Rechenzentrum oder beides

Für die Cloud sprechen Skalierbarkeit, verbrauchsabhängige Abrechnung und die Breite des Dienstangebots. Ein eigenes Rechenzentrum kann sinnvoll sein, wenn Daten den Standort nicht verlassen sollen, vorhandene Hardware weiter genutzt wird oder die Quellsysteme ohnehin vor Ort stehen.

Hybride Architekturen verbinden beides. Sensible oder sehr große Quellen bleiben lokal, Auswertung und Plattformdienste laufen in der Cloud, und eine gesicherte Verbindung überträgt nur, was gebraucht wird. Wir entscheiden das je Datenart und nicht pauschal für die ganze Plattform. Es zählen Datenschutzvorgaben, Latenz, Datenmengen, das Wissen im Team und die Frage, wie leicht sich später wechseln lässt.

Anbieter und was „souverän“ heißen kann

Bei der Anbieterwahl zählen vorhandene Systeme, Dienstumfang, Standort und Betreiber, Preismodell und Teamwissen. Neben den großen US-Anbietern gibt es europäische Clouds, etwa aus Deutschland und Frankreich. Wir beraten herstellerunabhängig.

Für Vorgaben zu Standort und Kontrolle gibt es inzwischen eigene Angebote. AWS beschreibt seine European Sovereign Cloud mit Rechenzentren in Deutschland als von den übrigen Regionen getrennt und von Personal mit Sitz in der EU betrieben. Microsoft fasst unter Sovereign Cloud eine öffentliche Variante in europäischen Regionen, eine private für den Betrieb im eigenen Umfeld und Partner-Clouds in einzelnen Ländern zusammen. Google arbeitet ebenfalls mit Partnern, in Frankreich etwa mit S3NS.

Was „souverän“ im Einzelfall bedeutet, unterscheidet sich stark: Standort der Daten, Betreiber und Rechtsraum, Kontrolle über die Schlüssel, Dienstumfang. Auch Zertifikate gelten oft nur für Teile des Angebots. STACKIT nennt nach eigenen Angaben unter anderem BSI C5 und ISO 27001, bei IONOS Cloud liegt die C5-Testierung für einzelne Dienste wie Compute Engine, Cloud Cubes und S3 Object Storage vor. Wir verlassen uns deshalb nicht auf den Prospekt, sondern prüfen, ob die Dienste, die wir brauchen, im jeweiligen Angebot überhaupt verfügbar sind. Ob es die rechtlichen Anforderungen erfüllt, bewertet die Rechtsberatung.

Wer an die Daten kommt

Netzwerk, Identitäten und Verschlüsselung legen fest, wer an die Daten kommt. Nachträglich sind sie aufwendig zu ändern, die Planung gehört deshalb an den Anfang.

Datendienste sollten nicht offen im Internet erreichbar sein. Wir setzen auf getrennte Netzsegmente, private Verbindungen zu den Diensten, etwa über Private Endpoints, und gesicherte Verbindungen zum eigenen Standort per VPN oder dedizierter Leitung. Personen melden sich über das zentrale Identitätssystem des Unternehmens an, mit Single Sign-on und Mehrfaktor-Authentifizierung. Dienste und Pipelines bekommen eigene Identitäten statt geteilter Passwörter, und Rechte vergeben wir über Gruppen nach dem Prinzip der geringsten Rechte. Geteilte Zugänge und langlebige Schlüssel sind schwer nachzuvollziehen und ein häufiger Ausgangspunkt für Sicherheitsvorfälle.

Verschlüsselt sind Daten im Speicher und bei der Übertragung bei den meisten Anbietern ohnehin. Zu klären ist, wer die Schlüssel kontrolliert. Eigene Schlüssel in einem Key-Management-Dienst oder Hardware-Sicherheitsmodul geben mehr Kontrolle, bringen aber Aufgaben wie Rotation und Wiederherstellung mit. Passwörter und Zugangsschlüssel gehören in einen Secret Store und nie in den Code.

Umgebungen und Infrastructure as Code

Eine Plattform braucht mindestens drei getrennte Umgebungen: Entwicklung, Test, Produktion. Getrennt wird über eigene Konten, Subscriptions oder Projekte mit eigenen Rechten. Produktionsdaten gelangen nur mit gutem Grund in die Entwicklung, und dann pseudonymisiert oder anonymisiert, soweit das geht.

Der häufigste Fehler ist eine Plattform, die jemand im Portal zusammengeklickt hat. Niemand weiß später, wie sie konfiguriert ist, und ein Neuaufbau ist kaum möglich. Bei Infrastructure as Code steht die Umgebung in Dateien, die in einem Repository liegen und automatisch ausgerollt werden. Änderungen sind nachvollziehbar, Umgebungen lassen sich identisch neu aufbauen, und manuelle Eingriffe fallen auf.

Bei mehreren Clouds oder europäischen Anbietern nehmen wir meist Terraform oder OpenTofu. Terraform ist weit verbreitet und hat Provider für die großen Clouds und viele weitere Anbieter, steht aber inzwischen unter der Business Source License von HashiCorp. OpenTofu ist der offene Fork unter dem Dach der Linux Foundation und nach eigenen Angaben als direkter Ersatz gedacht. In reinen Azure-Umgebungen reicht oft Bicep, Microsofts Sprache nur für Azure, die in ARM-Vorlagen übersetzt wird und deren Zustand Azure selbst verwaltet.

Die Infrastruktur wird wie Software behandelt. Änderungen laufen per Pull Request, werden automatisch geprüft, zuerst in Test ausgerollt und nach Freigabe in Produktion. Dieselbe Pipeline-Logik gilt für Datenpipelines, Transformationen und Berichte.

Backup, Monitoring und Kosten

Die Konfiguration liegt im Code, die Daten brauchen dagegen eine eigene Sicherung: Versionierung, Snapshots, Kopien in einer zweiten Region. Aufbewahrungsdauer und Wiederherstellungszeit werden festgelegt. Und die Wiederherstellung wird regelmäßig getestet, denn erst im Ernstfall zeigt sich sonst, ob die Sicherung taugt.

Überwacht werden Dienste, Pipeline-Läufe, Speicherplatz und Zugriffe. Alarme gehen an Personen, die zuständig sind, und nicht an ein Postfach, das niemand liest.

Kosten ordnen wir von Anfang an zu. Ressourcen erhalten Kennzeichnungen nach Projekt, Umgebung und Team, für jede Umgebung gelten Budgets und Alarme, und Entwicklungs- und Testumgebungen fahren außerhalb der Arbeitszeit herunter. Das folgt den Grundsätzen von FinOps. Anbieterspezifische Dienste sind oft sinnvoll, aber sie sollten bewusst gewählt sein, damit man sich nicht zu früh an einen Anbieter bindet.