In Zeiten von Cloud Computing arbeiten Unternehmen immer häufiger nicht mehr auf eigenen Systemen, sondern nutzen Rechenleistung und Speicherplatz von externen Anbietern. Die Frage, die sich Unternehmen dabei stellt müssen, ist: Wer –und welche Komponente – kann auf meine Daten zugreifen, wenn sie gerade verarbeitet werden? Und noch wichtiger: Wie kann ich sicherstellen, dass selbst der Betreiber der Infrastruktur keinen Zugriff hat? Confidential Computing liefert auf diese Frage eine umfassende Antwort.
Foto: Amazon Web Services
Bertram Dorn ist Principal in the Office of the CISO bei AWS und unterstützt interne und externe AWS-Kunden sowie Partner dabei, sich in sicherheitsrelevanten Themen rund um AWS zurechtzufinden. Er verfügt über mehr als 30 Jahre Erfahrung in der Technologiebranche, mit einem Schwerpunkt auf Sicherheit, Netzwerke, Speicher- und Datenbanktechnologien.
Confidential Computing beschreibt eine grundlegende Strategie in der Art und Weise, wie Daten in heutigen IT-Umgebungen verarbeitet und geschützt werden. Es geht darum, den Zugriff auf Daten während der Verarbeitung zu verhindern – und zwar auch für privilegierte Akteure wie Administratoren oder den Betreiber der zugrunde liegenden Cloud-Infrastruktur. Der zentrale Gedanke ist, dass selbst jemand mit höchsten Rechten nicht automatisch Einblick in die verarbeiteten Informationen erhält, wenn das nicht ausdrücklich gewünscht ist.
Oft wird Confidential Computing direkt mit spezialisierter Hardware in Verbindung gebracht, aber das greift zu kurz. Denn eigentlich beschreibt der Begriff eine Sicherheitsarchitektur, die sich über mehrere Ebenen – oder eine Hierarchie – eines Computersystems erstreckt. Der normale Benutzer operiert auf einer Anwendungsebene und hat bestimmte Rechte. Darunter gibt es eine Administrator-Ebene, die mehr Kontrolle über das System hat. Darunter wiederum existiert der Kernel, also der zentrale Bestandteil des Betriebssystems, der darüber entscheidet, welche Prozesse und Datenströme zugelassen werden. Unter dem Kernel haben wir die Hypervisor-Schicht, die virtuelle Maschinen verwaltet, und noch eine Ebene tiefer befindet sich die eigentliche Hardware. In traditionellen IT-Systemen kann jede dieser Ebenen auf die darüberliegenden zugreifen – der Administrator kann sehen, was der Benutzer tut, der Kernel kann auf alles zugreifen, der Hypervisor kann ganze Betriebssysteme verändern und letztendlich kann auch jemand mit direktem Hardwarezugriff sämtliche Schutzmaßnahmen aushebeln.
Genau hier setzt Confidential Computing an. Das Ziel ist es, eine Architektur zu schaffen, in der es nicht mehr automatisch möglich ist, von einer höheren Ebene aus auf Daten zuzugreifen, selbst wenn man die Berechtigung dazu hätte. Das hat in Zeiten von Cloud Computing eine enorme Bedeutung, weil Unternehmen immer häufiger nicht mehr auf eigenen Systemen arbeiten, sondern Rechenleistung und Speicherplatz von externen Anbietern nutzen. Die Frage, die sich Unternehmen dabei stellt müssen, ist: Wer – und welche Komponente – kann auf meine Daten zugreifen, wenn sie gerade verarbeitet werden? Und noch wichtiger: Wie kann ich sicherstellen, dass selbst der Betreiber der Infrastruktur keinen Zugriff hat?
Zunächst sollte man die Formulierung „hochsensible Daten“ hinterfragen. Natürlich denkt man bei Confidential Computing sofort an Finanztransaktionen, Gesundheitsdaten oder geheime Forschungsergebnisse. Doch es geht nicht nur um einzelne besonders kritische Datenbereiche, sondern um eine grundsätzliche Architekturentscheidung. Denn wenn ich nur bestimmte Daten besonders schütze, bleibt immer das Risiko, dass sich an anderer Stelle ein Angriffspunkt findet. Viel sinnvoller ist es also, von vornherein sicherzustellen, dass alle Daten während der Verarbeitung durchgängig geschützt sind.
Technologisch gibt es verschiedene Möglichkeiten, das zu erreichen. Ein wichtiger Bestandteil ist die Trennung von Betriebssystem-Ebenen. Ein traditionelles Virtualisierungssystem, und insbesondere der Einsatz von „Containern“ bringt das Risiko mit sich, dass sich mehrere Kunden eine physische Maschine teilen, bei Containern ggf. auch noch gemeinsam auf einem Kernel aufsetzen. Falls der Hypervisor (oder bei Containern deren Implementierung im Kernel) kompromittiert wird, kann das dazu führen, dass Angreifer von einer Instanz auf eine andere übergreifen können. Um das zu verhindern, setzen fortschrittliche Sicherheitsarchitekturen darauf, dass jeder Workload auf einem isolierten Kernel, und auf eigenen CPU-Kernen läuft.
Ein weiteres zentrales Element ist die Kontrolle darüber, welcher Code überhaupt ausgeführt wird. In einer Welt, in der Software aus zahlreichen Drittanbieter-Komponenten besteht, reicht es nicht aus, nur den Zugriff auf Daten zu regulieren. Unternehmen müssen sicherstellen, dass auch die Software, die auf ihren Systemen läuft, nicht manipuliert wurde. Hier kommen kryptografische Attestierungen ins Spiel: Diese ermöglichen es, dass ein System zur Laufzeit überprüft, ob eine Software genau der Version entspricht, die ursprünglich freigegeben wurde. Gerade mit Blick auf Angriffe, die sich gezielt auf Software-Supply-Chains richten, ist das eine entscheidende Schutzmaßnahme.
Neben diesen technischen Konzepten spielt auch die Isolation auf Hardware-Ebene eine zentrale Rolle. Durch den Einsatz spezieller mandantenorientierter Speicherverwaltung kann verhindert werden, dass ein kompromittierter Prozess auf sensible Daten zugreift. Fortschrittliche Ansätze setzen zudem darauf, dass Ressourcen wie Arbeitsspeicher oder CPU-Kapazitäten nicht gemeinsam genutzt werden, um potenzielle Angriffsflächen zu minimieren.
Die IT-Industrie hat sich in den letzten Jahren intensiv mit der Frage beschäftigt, wie man Workloads so sicher wie möglich betreiben kann. Unterschiedliche Anbieter setzen dabei auf verschiedene Ansätze. Einige Lösungen basieren auf CPU-Funktionen wie Intel SGX oder AMD SEV, die geschützte Speicherbereiche innerhalb der CPU bereitstellen. Diese Technologien bieten eine gewisse Isolation, erfordern aber eine enge Integration in bestehende Anwendungen, was in der Praxis nicht immer einfach umzusetzen ist.
AWS geht mit der Nitro-Plattform einen anderen Weg. Nitro wurde von Grund auf so entwickelt, dass es eine vollständige Mandanten-Trennung bietet. Das bedeutet, dass AWS als Anbieter sich selbst aus der Hypervisorebene ausschließt. Auf Betriebssysteme des Kunden hatte AWS ohnehin nie Zugriff. Es gibt keinen Hypervisor-Administrator, keinen AWS-Mitarbeiter mit Zugriff und keine Möglichkeit, Speicher oder Netzwerkverkehr auf einer geteilten Plattform mitzulesen. Ein wichtiger Unterschied liegt darin, dass AWS den gesamten Ein- und Ausgabe-Prozess über dedizierte Nitro-Chips abwickelt. Dadurch werden klassische Angriffsszenarien – wie das unautorisierte Mitschneiden von Speicherinhalten oder das Überwachen von Netzwerkpaketen auf der Hypervisor-Ebene – vollständig eliminiert.
Für Unternehmen, die besonders kritische Workloads haben, bietet AWS zusätzlich die Möglichkeit, Nitro Enclaves zu nutzen. Diese Enklaven sind vollständig isolierte Umgebungen, in denen selbst der eigene Administrator des Kunden keinen Zugriff mehr hat. Während andere Lösungen auf softwarebasierte Sicherheitsmechanismen oder bestimmte CPU-Funktionen setzen, bietet AWS mit Nitro eine plattformunabhängige, vollständig hardware-gestützte Lösung.
Mehr zu Confidential Computing von Bertram Dorn:
Folge 2: Die Vorstellung einer vollständigen Absicherung ist trügerisch
