.png){kind=logo}
Trennen Sie Infrastrukturrechte vom Klartextzugriff
Cloud- und Service-Provider verfügen für den Plattformbetrieb über privilegierte Zugriffsrechte – und somit auch über Zugang zu sensiblen Daten. enclaive schiebt dem einen Riegel vor und schützt Workloads in hardwareisolierten Ausführungsumgebungen mit kundenseitiger Schlüsselkontrolle.
hardware-basiert und attestierbar. Technisch erzwungen statt organisatorisch vereinbart.
Komplexe Infrastruktur lässt sich ohne weitreichende administrative Rechte nicht betreiben. Mit diesen weitreichenden Zugriffsrechten gehen allerdings strukturelle Risiken einher.
Zu viele administrative Zugriffspfade
Erweiterte Rechte gibt es an vielen Stellen: auf Plattformebene, in Managed Services und im laufenden Betrieb. Jeder einzelne Zugriff kann dabei notwendig sein. Zusammengenommen vergrößern sie jedoch die Angriffsfläche und eröffnen zusätzliche Wege zu sensiblen Workload-Daten.
Zugriffe steuern heißt nicht Zugriffe verhindern
SIEM und EDR überwachen verdächtige Aktivitäten, PAM steuert privilegierte Zugriffe. Diese Kontrollen sind wichtig, beseitigen den technischen Zugriff aber nicht. Genau dieser wird aber zum Risiko, wenn Konten oder Zugangsdaten kompromittiert werden.
Ein einziger Zugang kann viel anrichten
Je umfassender die Berechtigungen eines Accounts, desto größer die möglichen Auswirkungen einer Kompromittierung. Ein einzelner Zugang kann dadurch zum Ausgangspunkt für Zugriffe auf zahlreiche Systeme und sensible Daten werden.
Das Prinzip ist einfach: Zugriffe auf Infrastruktur und Daten werden technisch voneinander getrennt. Workloads laufen hardwareisoliert, Schlüssel werden selbst kontrolliert und nur an verifizierte Workloads und Identitäten freigegeben. Damit reicht ein kompromittierter Admin-Zugang allein nicht mehr aus, um vertrauliche Daten im Klartext zu lesen.
Sensible Anwendungen laufen in hardwareisolierten und verschlüsselten Confidential-Computing-Umgebungen. Dadurch werden Daten auch während der Verarbeitung geschützt – nicht nur im Ruhezustand und während der Übertragung –, sodass privilegierte Zugriffe praktisch ausgeschlossen sind.
Schlüssel bleiben unter kundenseitiger Kontrolle und werden nur freigegeben, wenn Identität und Zustand des Workloads den definierten Policies entsprechen ("Not attest, no key"). Ein gestohlenes Zugangskonto allein genügt damit nicht für die Schlüsselfreigabe.
Zugriffe und Secrets lassen sich an die verifizierte Identität eines Workloads binden und zeitlich oder funktional begrenzen. Dadurch sinkt die Abhängigkeit von langlebigen Credentials, die bei einer Kompromittierung weiterverwendet werden können.
In Managed-Kubernetes-Umgebungen laufen Pods als abgeschottete Confidential VMs. Cluster-Admins können die Infrastruktur weiterhin verwalten, ihr Zugriff endet jedoch an der Grenze des geschützten Pods. Auf die darin verarbeiteten Daten können sie nicht zugreifen.
Viele Risiken rund um administrative Zugriffe werden heute vor allem durch Prozesse, Zugriffskontrollen und Monitoring begrenzt. Technisch sind Datenzugriffe über Infrastrukturrechte aber weiterhin möglich. Confidential Computing verändert genau diese Ausgangslage.
Die Darstellung dient der Einordnung und ersetzt keine individuelle Risikobewertung. Eintrittswahrscheinlichkeit und Schadensausmaß hängen von Ihrer Architektur und Ihren bestehenden Kontrollen ab.
Die Darstellung dient der Einordnung und ersetzt keine individuelle Risikobewertung. Eintrittswahrscheinlichkeit und Schadensausmaß hängen von Ihrer Architektur und Ihren bestehenden Kontrollen ab.
Betreiberausschluss ersetzt kein Security-Framework. Phishing bleibt ein Risiko, Endpoints müssen geschützt und Anwendungsschwachstellen geschlossen werden. Auch ein Betreiber ohne Klartextzugriff kann Services stören oder Daten löschen. Betreiberausschluss schützt die Vertraulichkeit – Verfügbarkeit und Anwendungssicherheit bleiben eigenständige Aufgaben.
Was sich ändert: Privilegierten Rollen wird der Klartextzugriff entzogen, statt diese Zugriffe nur besser zu kontrollieren. PAM bleibt trotzdem wichtig, um administrative Rechte zu steuern, SIEM, um Aktivitäten zu erfassen und auszuwerten. Welche geschützten Daten über diese Rechte überhaupt lesbar sind, begrenzt dagegen die Architektur selbst.
Was Security-Verantwortliche wissen wollen
Ersetzt Confidential Computing unser PAM, SIEM oder EDR?
Nein. Diese Werkzeuge behalten ihre Aufgabe: PAM steuert administrative Rechte, SIEM und EDR unterstützen Überwachung und Erkennung. Confidential Computing ergänzt diese Kontrollen um eine harte technische Grenze für den Datenzugriff. Monitoring bleibt damit wichtig – ist aber nicht mehr die letzte Verteidigungslinie für die Vertraulichkeit.
Was können Administratoren weiterhin tun?
Die Infrastruktur betreiben – und theoretisch auch beeinträchtigen. Administratoren können Systeme stoppen, löschen oder falsch konfigurieren. Verfügbarkeit und Integrität bleiben deshalb Aufgaben der bestehenden Sicherheits- und Betriebskontrollen. Was Infrastrukturrechte allein aber nicht mehr ermöglichen, ist der Klartextzugriff auf geschützte Workload-Daten oder Schlüssel.
Was ist mit Side-Channel-Angriffen und TEE-Schwachstellen?
Diese Risiken sind real und gehören in jedes seriöse Threat Model. Sicherheitslücken in TEEs werden veröffentlicht und gepatcht, Attestation-Policies können aktuelle Firmware- und Sicherheitszustände voraussetzen. Confidential Computing ersetzt deshalb weder Patch Management noch Defense in Depth. Entscheidend ist der Vergleich, wie exponiert Daten sind: auf der einen Seite eine speziell geschützte, überprüfbare Ausführungsumgebung – auf der anderen ein Arbeitsspeicher, in dem Daten über privilegierte Infrastrukturzugriffe grundsätzlich lesbar sind.
Was passiert bei physischem Zugriff auf den Server?
Bei einer entsprechend abgesicherten TEE bleiben Daten im Arbeitsspeicher verschlüsselt, während Schlüssel an den verifizierten Zustand der Ausführungsumgebung gebunden sind. Der Ausbau oder die forensische Analyse eines Datenträgers oder Servers führt damit nicht automatisch zu lesbaren Workload-Daten. Physische Angriffe auf Hardware bleiben dennoch Teil des Threat Models und müssen bei besonders hohen Schutzanforderungen gesondert bewertet werden.
Wie lässt sich die Risikoreduktion messen?
Zwei Größen sind besonders hilfreich: erstens die Zahl und Reichweite administrativer Zugriffsmöglichkeiten vor und nach der Einführung, zweitens der Anteil kritischer Workloads, die während der Verarbeitung geschützt und an attestierungsbasierte Schlüsselfreigaben gebunden sind. Beides lässt sich in die bestehende Risikobewertung übernehmen und macht die Veränderung des Restrisikos nachvollziehbar.
Welche Rolle kann dies für unsere Compliance-Anforderungen spielen?
Dieselben technischen Kontrollen können Anforderungen aus unterschiedlichen Regelwerken unterstützen: etwa Zugriffsschutz und Supply-Chain-Sicherheit unter NIS2, Verschlüsselung von Data in Use und IKT-Drittparteienrisiken unter DORA oder erhöhte Schutzanforderungen im IT-Grundschutz. Welche Anforderungen konkret gelten und wie sie nachzuweisen sind, hängt jedoch vom jeweiligen Regelwerk und Einsatzszenario ab.
Betreiberausschluss entsteht bei enclaive aus dem Zusammenspiel dieser vier technischen Bausteine.
Workloads bleiben auch während der Verarbeitung in hardwarebasierten Trusted Execution Environments geschützt. Betreiber sehen nur verschlüsselten Text.
Kubernetes-Workloads werden auf Pod-Ebene isoliert. Die Control Plane verwaltet den Cluster, hat aber keinen Zugriff auf die geschützten Pods.
Schlüssel bleiben unter Ihrer Kontrolle und werden nur an Workloads freigegeben, deren attestierter Zustand den definierten Policies entspricht.
Workload-Identität und Remote Attestation machen überprüfbar, welche Umgebung tatsächlich läuft und ob die Voraussetzungen für eine Freigabe erfüllt sind.
Wo sensible Workloads heute noch an Grenzen stoßen
Wenn mögliche Betreiberzugriffe Ihre Cloud-Migration oder den Weg zu Managed Services verhindern, schauen wir uns gerne die Architektur an – und zeigen Ihnen, wie sich Betrieb und Datenzugriff technisch trennen lassen.
