Die Vorteile von Software-as-a-Service (SaaS) zu nutzen, ohne die Kontrolle über sensible Daten zu verlieren, ist ein langgehegter Traum. Unternehmen verlassen sich oft auf Drittanbieter, um ihre sensibelsten Daten oder Workloads zu schützen. Daraus resultieren jedoch Compliance- und Vertrauensprobleme. SaaS-Modelle, die Confidential Computing nutzen, versprechen eine Lösung für diesen Konflikt: Unternehmen sollen die Flexibilität von SaaS nutzen können, ohne die Vertraulichkeit ihrer Daten aufzugeben.
Ein kürzlich von mir durchgeführtes Security Review zeigte jedoch ein anderes Bild, denn genau diese Sicherheitsversprechen können zu gefährlichen blinden Flecken führen. Wenn wir davon ausgehen, dass eine Plattform «Secure by Design» ist, schauen wir bei der tatsächlichen Implementierung oft nicht mehr genau hin.
In diesem Blogartikel möchte ich aufzeigen, weshalb auch Confidential-Computing-Lösungen regelmässig und unabhängig überprüft werden sollten und wie Unternehmen die Sicherheit solcher Lösungen gewährleisten können.
Inhaltsverzeichnis
Eine Einführung in Confidential Computing und sichere SaaS-Modelle
Um die Tragweite eines solchen blinden Vertrauens zu verstehen, betrachten wir kurz, wie Confidential Computing funktioniert:
- Traditionelle Sicherheitsmassnahmen schützen ruhende Daten («Data at Rest») durch Festplattenverschlüsselung und übertragene Daten («Data in Transit») durch Protokolle wie TLS.
- Confidential Computing erweitert diesen Schutz auf Daten in Verwendung («Data in Use»), indem Anwendungen auf Hosts mit TPM-basierter Attestierung oder in speziellen, hardwarebasierten Trusted Execution Environments (TEEs) ausgeführt werden.
Der Kerngedanke ist, dass der genaue Zustand des gesamten Codes, der die Daten sieht oder mit ihnen in Berührung kommt, bekannt und ausgewiesen ist. Durch einen hardwaregestützten kryptografischen Beweis kann verifiziert werden, dass der Endpunkt, an den die Daten gesendet werden, tatsächlich (und ausschliesslich) die erwartete Firmware und Software ausführt. TEEs können auch weitere Schutzmechanismen wie Speicherverschlüsselung bieten.
Die kryptografischen Zusicherungen von Confidential Computing ermöglichen es uns also genau zu wissen, wer Zugriff auf unsere Daten hat – abgesehen von scheinbar unvermeidlichen Zero-Day-Schwachstellen in Software oder Hardware, die in jeder Lösung auftreten können.rom seemingly unavoidable zero-day vulnerabilities in software or hardware, which can occur in any solution.
Confidential-SaaS-Modell
Software-as-a-Service(SaaS)-Anbieter nutzen Confidential Computing zunehmend für die Bereitstellung von Zero-Trust-Umgebungen. Bei einem Confidential-SaaS-Modell stellt der Anbieter eine Umgebung zur Verfügung, auf deren Daten er selbst keinen Zugriff hat, und der Benutzer kann von dieser Umgebung einen kryptografischen Beweis – einen sogenannten «Attestation Quote» (Attestierungsnachweis) – anfordern. Dieser Nachweis verifiziert die zugrundeliegende Hardware und den exakten Zustand der darin geladenen Software. Kunden überprüfen diesen Nachweis anhand bekannter Messwerte, um sicherzustellen, dass sie mit der korrekten, nicht kompromittierten Software interagieren, bevor sie sensible Daten senden.
Blinder Fleck über sechs Monate – wie Confidential Computing nicht geht
In der Theorie ist die Sicherheit des Confidential-SaaS-Modells sehr gut, aber sie bricht zusammen, wenn der gehostete Code fehlerhaft oder undurchsichtig ist. Während eines kürzlich durchgeführten Security Review eines auf Confidential Computing basierenden Dienstes entdeckte ich eine kritische Anomalie in der «vertrauenswürdigen» Codebasis des Anbieters. Im Deployment-Prozess war eine Abhängigkeit über einen festen kryptografischen Hash eingebunden.
Während das Festpinnen von Abhängigkeiten per Hash eine gängige Sicherheitspraxis ist, um Manipulationen an Upstream-Quellen zu verhindern, war der mit diesem spezifischen Hash verbundene Quellcode unveröffentlicht und gänzlich unbekannt. Ein solcher unbekannter Code könnte theoretisch beliebige bösartige Payloads wie Backdoors oder Datenexfiltration enthalten.
Diese undurchsichtige Abhängigkeit befand sich bereits seit mehr als sechs Monaten in der Produktionsumgebung. Während dieses gesamten Zeitraums haben weder Kunden und Partner, die sich auf die Sicherheit der Plattform verlassen und ihr vertraut haben, noch Auditoren dies bemerkt oder hinterfragt. Da die Hardware-Attestierung erfolgreich mit den vom Anbieter veröffentlichten Messwerten übereinstimmte, gingen alle Beteiligten davon aus, dass das System vollkommen vertrauenswürdig war. Die Attestierung bewies jedoch nur, dass die Enklave exakt den Code des Anbieters ausführte – sie bewies jedoch nicht, dass der Code tatsächlich sicher, mit guten Absichten oder frei von bösartigen Backdoors war. In diesem Fall stellte sich der Code als harmlos heraus, aber kein Benutzer, der die Plattform in diesen sechs Monaten verwendete, konnte das mit Sicherheit wissen.
Warum kontinuierliche Überprüfungen zwingend erforderlich sind
Die Tatsache, dass der unbekannte, fehlende Code nicht erkannt und gemeldet wurde, zeichnet ein klares Bild: Selbst Organisationen, die sicherheitsbewusst genug sind, um sich für ein auf Confidential Computing basierendes SaaS-Modell zu entscheiden, verstehen das Vertrauensmodell und dessen Implikationen nicht vollständig. Wenn ein Unternehmen sich für ein Confidential-Computing-SaaS-Modell entscheidet, gibt es kein «einmal evaluieren» oder «alle paar Jahre evaluieren» wie bei einem normalen Dienstanbieter.
Der einzige Weg, um den vollen Sicherheitsnutzen aus diesem Ansatz zu ziehen, besteht darin, ein Security Review für JEDES Release der Plattform durchzuführen.
Ja, das ist aufwändig. Aber es ist auch der einzige Weg, der volles Vertrauen in die Anwendung ermöglicht. Werden keine regelmässigen Überprüfungen umgesetzt, gibt es hinsichtlich des effektiven Vertrauensniveaus keinen Unterschied zu einem normalen SaaS-Dienst – man hofft einfach nur, dass die Anbieter das Richtige tun.
Wenn es Angreifern oder böswilligen Insidern gelingt, bösartigen (veröffentlichten oder unveröffentlichten) Code in den genehmigten Build-Prozess einzuschleusen, wird Confidential Computing diese Malware perfekt schützen und ausführen – und die Attestierung wird bestätigen, dass dieser Code ausgeführt wird.
Grenzen KI-gestützter Security Reviews
Glücklicherweise lassen sich heute gewisse Code- und Sicherheitsanalysen durch KI unterstützen oder teilweise automatisieren. Dabei ist jedoch zu berücksichtigen, dass KI-gestützte Reviews nicht fehlerfrei sind.
In meinem Security Review wurde die Analyse ebenfalls durch KI unterstützt. Zwar erkannte das System die bestehenden Abhängigkeiten korrekt, bewertete diese jedoch als unkritisch – obwohl das gesamte Projekt sowie die relevanten Vertrauensbeziehungen als Kontext zur Verfügung standen. Dies zeigt, dass es auch in KI-basierten Bewertungen blinde Flecken gibt und eine fachliche Einordnung durch Sicherheitsexperten somit weiterhin unerlässlich bleibt.
Wie Unternehmen Confidential-Computing-SaaS-Modelle richtig absichern
Was sollten man also tun, um von einem auf Confidential Computing basierenden SaaS-Dienst profitieren zu können? Ich empfehle folgende Massnahmen:
- Totale Transparenz fordern: Reproduzierbare Builds sind das Minimum. Alles, was innerhalb der vertrauenswürdigen Umgebung ausgeführt oder geladen wird, sollte sichtbar und überprüfbar sein. Wenn der Dienst auf einer bestimmten Plattform aufgebaut ist, sollte diese ebenfalls einbezogen werden.
- Einen Audit-freundlichen Lebenszyklus fordern: Alle geplanten Deployment-Änderungen sollten (inklusive Code) mindestens ein paar Tage – besser mindestens eine Woche – vor dem Go-Live veröffentlicht werden; Notfalländerungen sollten klar eingegrenzt und leicht zu überprüfen sein. Alle Änderungen sollten eindeutig nachverfolgbar und mit einem Änderungsprotokoll oder einem ähnlichen Instrument verknüpft sein.
- Jedes Release überprüfen: Nach einem anfänglichen, gründlichen manuellen Security Review sollte eine Überprüfung aller Änderungen für jedes einzelne Release durchgeführt werden. Wenn einige dieser Überprüfungen mit KI automatisiert werden sollen, sollte sichergestellt werden, dass ein ordnungsgemäss validiertes Framework verwendet wird, das erzwingt, dass die richtigen Prüfungen auf die richtige Weise ausgeführt werden. Zudem sollten weiterhin regelmässige manuelle Überprüfungen sowie ein «Human-in-the-Loop»-Ansatz eingesetzt werden, um sicherzustellen, dass alle Vertrauenserwartungen erfüllt werden.
- Überwachen und verifizieren: Änderungen in den bereitgestellten Manifesten oder Hashes sollten überwacht und erkannt werden. Es sollte sichergestellt werden, dass jeder in einem Deployment-Manifest festgehaltene Hash einem Release entspricht, das überprüft wurde. Die Verfügbarkeit sollte sorgfältig gegenüber den Sicherheitsrisiken abgewogen werden, um zu entscheiden, ob der Zugriff auf den Dienst bei einer unerwarteten Änderung blockiert werden sollte.
Das zusätzliche Vertrauen in Confidential-Computing-SaaS-Modelle entsteht durch Transparenz. Wird diese Transparenz nicht genutzt, um regelmässig sicherzustellen, dass die Lösung das tut, was man erwartet, gibt es keinen wirklichen Vorteil gegenüber einem klassischen SaaS-Dienst.
Gemeinsam Vertrauen aufbauen
Möchten Sie Ihre bestehenden Prozesse oder Lösungen untersuchen lassen? Unsere Cybersecurity-Spezialisten begleiten Sie ganzheitlich:
