„Darf nicht“ vs. „kann nicht“: Der Cloud-Betreiber darf nicht zugreifen? Dann soll er es auch nicht können!

Ein Finanzinstitut verlagert sensible Daten in die Cloud. Der Vertrag schließt Betreiber-Zugriff aus. Nachts um drei kann sich trotzdem ein Admin mit Root-Rechten auf den Host schalten. „Darf nicht“ setzt auf Regeln, „Kann nicht“ auf eine Architektur, die Einzelnen keinen Zugriffspfad lässt.

von Andreas Dirscherl, Director of Engineering Technology bei idgard

Ob ein solcher Pfad existiert, entscheidet sich unterhalb der Ebene, die das Finanzinstitut selbst administriert. Bei Software as a Service endet die Kontrolle häufig an der Anwendung, bei einer virtuellen Maschine am Gastbetriebssystem. Hypervisor, Host-Betriebssystem, Firmware und Hardware bleiben beim Betreiber.

Kann sich ein Administrator per SSH auf einen produktiven Host schalten und besitzt dort Root-Rechte, verfügt er über Möglichkeiten, die von den Berechtigungen des Finanzinstituts nicht erfasst werden. Auch privilegierte Rechte auf dem Hypervisor liegen außerhalb dieser Kontrollgrenze. Je nach Umgebung kann der Betreiber Prozesse inspizieren oder auf Speicherzustände laufender Workloads zugreifen. Hinzu kommen separate Managementzugänge, etwa über einen Baseboard Management Controller. Solche Rechte liegen unterhalb der normalen Tenant-Berechtigungen. Das Identity and Access Management des Finanzinstituts greift dort nicht.

Verschlüsselung schützt bis zur Entschlüsselung

Für die Daten wird diese Kontrollgrenze vor allem während der Verarbeitung relevant. Auf dem Datenträger und während der Übertragung können sie verschlüsselt sein. Eine Anwendung muss sie für Suche, Berechnung oder Analyse jedoch in nutzbarer Form verarbeiten können. Deshalb muss auch klar sein, wo Daten entschlüsselt werden und wer diese Umgebung kontrolliert.

Schlüsselhoheit ist nicht Zugriffshoheit

Für die Entschlüsselung braucht die Anwendung Zugriff auf kryptografische Schlüssel oder auf einen Dienst, der die entsprechende Operation für sie ausführt. Schlüssel können etwa über einen Key Management Service (KMS) verwaltet oder in einem Hardware Security Module (HSM) geschützt werden.

Ein KMS oder HSM allein beantwortet die Betreiberfrage noch nicht. Relevant ist auch, wer die zugehörigen Berechtigungen kontrolliert. Auch ein kundenseitig kontrollierter Schlüssel schließt Betreiberzugriffe nicht automatisch aus. Die Anwendung braucht weiterhin eine Service- oder Workload-Identität, die eine Entschlüsselung auslösen darf. Kann ein Administrator diese Identität übernehmen, muss er den Schlüssel selbst nicht sehen.

Am Beispiel Kubernetes zeigen sich beide Varianten. Wird ein Secret aus einem externen Secret Store in den Cluster übernommen und einem Pod als Umgebungsvariable oder Volume bereitgestellt, liegt es dort in einer Form vor, die die Anwendung nutzen kann. Ein ausreichend privilegierter Cluster-Administrator kann je nach Konfiguration Secrets lesen oder mit kubectl exec auf laufende Pods zugreifen. Bleibt der Schlüssel dagegen im HSM oder KMS, verlagert sich die Prüfung auf die Identität, die die Entschlüsselungsfunktion aufrufen darf.

Für Finanzinstitute reicht deshalb die Aussage des Betreibers, die Daten seien verschlüsselt, nicht aus. Sie müssen nachvollziehen können, wer den Schlüssel nutzen oder eine Entschlüsselung auslösen kann und wer die Umgebung kontrolliert, in der die Daten verarbeitet werden.

Der bessere Admin-Zugang ist der, den es nicht gibt

Damit Betreiberrechte auf Host, Cluster oder Entschlüsselungsumgebung nicht einfach für einen Zugriff genutzt werden können, müssen privilegierte Pfade aus dem Produktivbetrieb verschwinden. Auf produktiven Hosts gibt es dann beispielsweise keinen SSH-Zugang und keine interaktive Shell. Administratoren besitzen keine dauerhaft nutzbaren Credentials oder Cluster-Admin-Zertifikate für direkte Eingriffe.

Wer direkte Administratorzugänge entfernt, muss auch den Betrieb entsprechend organisieren. Immutable Infrastructure setzt deshalb auf reproduzierbare Systemzustände. Betriebssystem und Konfiguration werden vorab definiert und kontrolliert ausgerollt. Ein fehlerhafter Node wird neu aufgebaut oder ersetzt. Logs, Metriken und Traces liefern die Informationen für die Diagnose.

Wenn Änderungen nicht mehr direkt auf dem Produktivsystem erfolgen, muss der Sollzustand vorab definiert und über einen kontrollierten Pfad verändert werden. Bei GitOps liegt die Infra­struktur­konfi­guration dafür versioniert in einem Repository. Änderungen werden geprüft und automatisiert ausgerollt. Continuous Reconciliation vergleicht Soll und Ist und erkennt Abweichungen. Policy-as-Code kann Konfigurationen blockieren, die gegen festgelegte Regeln verstoßen.

Diese Mechanismen kontrollieren den vorgesehenen Änderungspfad, beseitigen aber keine tieferliegenden Betreiberrechte. Root auf dem Host kann am GitOps-Operator vorbeiführen, eine Kubernetes-Policy kontrolliert den Hypervisor nicht. Auch ein automatisierter Betrieb hilft wenig, wenn daneben ein dauerhafter Notfall- oder Managementzugang bestehen bleibt.

Was „kann nicht“ tatsächlich bedeutet

Fehlen solche direkten Host-, Cluster- und Managementzugänge und sind auch die Entschlüsselungsrechte begrenzt, müsste der Betreiber für einen neuen Zugriff den freigegebenen Systemaufbau verändern, etwa einen administrativen Zugang ergänzen oder Boot- und Deployment­konfi­gurationen anpassen. Eine solche Änderung könnte ein einzelner Administrator nicht mehr mit seinen vorhandenen Betriebsrechten vornehmen. Sie müsste auf Ebene der Betreiberorganisation angestoßen und umgesetzt werden. Dafür wären mehrere Beteiligte, Freigaben und technische Validierungen nötig. Änderungen am Sollzustand lassen sich über Versionierung, Signaturen, Reviews und den Abgleich von Soll und Ist nachvollziehen.

Für Banken, Versicherer und andere regulierte Finanzunternehmen ist das ein anderes Risikoprofil. Ein vorhandener Root- oder Managementzugang kann von einer einzelnen privilegierten oder kompromittierten Identität genutzt werden. Ist dieser Pfad entfernt, müsste die Betreiberorganisation erst den freigegebenen Systemaufbau verändern und einen neuen Zugriffspfad schaffen.

Was Finanzinstitute tatsächlich prüfen müssen

Bei der technischen Bewertung eines Cloud-Anbieters zählt deshalb die Zugriffskette. Finanzinstitute sollten wissen, wo ihre eigene Kontrolle endet, welche privilegierten Rechte der Betreiber auf Host-, Hypervisor-, Cluster- und Managementebene besitzt und welche Identitäten Entschlüsselungen auslösen dürfen. Ebenso relevant ist, welche Änderungen nötig wären, um einen heute nicht vorhandenen Zugriff zu schaffen und wie diese erkannt würden. Zertifizierungen, Audit-Logs und Berechtigungskonzepte bleiben wichtige Nachweise.

Wer auf „Können Ihre Administratoren an unsere Daten und Workloads?“ nur mit Verträgen, Prozessen und Protokollen antwortet, hat die technische Frage trotzdem nicht beantwortet. Maßgeblich ist, welche privilegierten Zugriffspfade tatsächlich existieren und welche durch die Architektur ausgeschlossen sind. Andreas Dirscherl, idgard