Bei jedem Kundengespräch mit dem Thema Cloud Deployment und Cloud Migration werden Bedenken bezüglich der Gefahren für die Cybersecurity geäussert. Obwohl sich mittlerweile das Gespräch seltener auf die Sicherheitsmöglichkeiten der Anbieter selbst fokussieren, erwähnen viele Kunden, dass sie da einfach ein schlechtes Bauchgefühl haben. Denn, seien wir mal ehrlich: Es gibt keine Cloud – Es gibt nur den Rechner von jemand anderem.

Ohne Zweifel sind die Umgebungen, wenn wir über die Big Player im Cloud-Business sprechen (Microsoft, Amazon & Google), besser geschützt als vieles, was ich in meinen mehr als 20 Jahren Erfahrung als ICT Security Spezialist gesehen habe. Dies liegt hauptsächlich daran, dass die Anbieter sehr konsequent ein Cybersecurity Risk Framework integrieren. Aber wieso, mag sich der eine oder andere fragen. Andernfalls wären sie sehr schnell out of business, denn Sicherheit ist mittlerweile ein zentrales Verkaufsargument: Security ist wichtig. Sodann findet man also hochsichere Datazentren, die mit physikalischem Schutz und Zutrittseinschränkungen aufwarten können. Massnahmen, die zu einem durchdachten Cybersecurity-Konzept gehören. Dies kostet natürlich. Doch diese Kosten wären für den Einzelnen ein Vielfaches und liessen sich wirtschaftlich nur in den wenigsten Fällen rechtfertigen. Während diesen Gesprächen fiel mir auf, dass ich immer wieder darauf hinweisen muss, dass ein sicherer Betrieb leider nicht gut skaliert…

Dieser erfordert ein Framework an gut etablierten Prozessen, Prozeduren und Werkzeugen, die ihrerseits durch gut ausgebildetes Personal genutzt werden muss. Die Kosten hierfür sind identisch, egal ob nun 100, 1’000 oder 10’000 Benutzer in der Organisation gegeben sind – Dementsprechend skalieren diese Kosten sehr schlecht. Selbstverständlich sollte nun nicht alles in Die Cloud verschoben werden. Doch die Diskussion sollte möglichst sachlich stattfinden und emotionale Aspekte weitestgehend ausblenden. Man sollte über Anforderungen, Vorteile und Kosten einer Lösung diskutieren, wobei es in erster Linie die folgenden Punkte zu definieren gilt:

• Gewährleistung von Prozessen bezüglich Governance, Risiko und Compliance
• Auditierung von operativen und geschäftlichen Prozessen
• Verwaltung von Rollen und Identitäten
• Gewährleistung eines angemessenen Schutzes von Daten und Informationen
• Durchsetzung von Privacy Policies
• Beurteilung der Sicherheitsvorteile bei cloudbasierten Applikationen
• Gewährleistung der Sicherheit von Netzwerken und Anbindungen
• Beurteilung der Security Controls der physischen Infrastruktur
• Im Vertragswerk definierte Pflichten bezüglich Sicherheit
• Verstehen der Sicherheitsanforderungen im Rahmen des Exit-Prozesses

Sobald man über Sicherheitsanforderungen in der Cloud spricht, beginnt Verschlüsselung (und das dazugehörige Key Management) eine wichtige Rolle zu spielen. Sicherheit ist ein Prozess, der gesteuert werden muss. Selbst wenn alle zuvor genannten Aspekte berücksichtigt werden, gibt es noch immer einen Punkt, der innerhalb der Cloud nicht ohne weiteres gesichert werden kann: Die Ausführung von Prozessen und die entsprechende Auslagerung ins RAM.

Das grundlegende Problem besteht darin, dass praktisch alle Inhalte während der Programmausführung im Klartext vorliegen und durch andere Prozesse oder Drittpersonen eingesehen werden könnten. Das Verschlüsseln von gespeicherten Daten oder während ihrer Netzwerkübertragung kann hier nicht greifen. Wenn wir davon ausgehen, dass der physische Prozessor eines Cloud-Stacks mehrere virtuelle Maschinen zeitgleich ausführt, dann wird also ebenfalls der flüchtige Speicher zwischen den Instanzen geteilt. Die Möglichkeit des Auslesens von Daten im Klartext, ohne die einzelne virtuelle Maschine kompromittieren zu können, ist eine offensichtliche und eminente Gefahr.

Herausforderung: PKI CA in der Cloud

Lassen Sie uns ein Beispiel heranziehen, um die Problematik zu verdeutlichen. Zuvor habe ich erwähnt, dass aufgrund der Sicherheitsanforderungen nicht alle Lösungen in die Cloud verschoben werden sollten. Nehmen wir als Beispiel eine PKI Certificate Authority. Hierbei handelt es sich um ein komplexes Konstrukt, das schon in einer eigenständigen physischen Umgebung schwierig zu bewältigen ist. Verliert man nämlich die Kontrolle über den Root Private/Signing Key, ist das gesamte System kompromittiert. Da dieser Key jedoch im Speicher der VM im Klartext vorliegen muss (und dementsprechend auch im RAM als solcher gegeben ist), könnte eine Kompromittierung stattfinden.

In diesem Szenario könnte ein böswilliger Cloud-Administrator ein grosses Risiko darstellen, da er den im Klartext vorliegenden Key aus dem Speicher des Hypervisor extrahieren könnte. Ein durchdachtes Cybersecurity Risk Framework vermag dabei helfen, einen solchen Zwischenfall zu erschweren. Komplett verhindern kann es dies aber nicht, da nun mal die Einschränkungen der Hardware gegeben sind. Erst spezialisierte Hardware macht es möglich, solche Angriffe grundsätzlich auf technische Ebene zu verhindern. Zu diesem Zweck wird HSM (Hardware Security Module) eingesetzt, welches verhindert, dass die Schlüssel nie im geteilten RAM des Systems zu finden sind.

Die Software Guard Extension (SGX), welche durch Intel in ihrem neuen Skylake Prozessor implementiert wird, stellt eine konkrete Lösung dar.

SGX Enklave

Intel hat im September 2013 angekündigt, dass sie die SGX (Software Guard eXtension) in ihren Prozessoren implementieren wollen. Es brauchte seine Zeit, bis die Technologie für den Massenmarkt zugänglich wurde. Momentan ist sie ausschliesslich in der neuesten Prozessorgeneration Skylake vorhanden.

In seinem Kern ist Skylake ein Set von x86-64 CPU Erweiterungen, die ein geschütztes Umfeld namens Enclaves zur Verfügung stellen. Der Prozessor schränkt damit den Zugriff zum Enclave-Speicher ein. Instruktionen, die ausserhalb der Enklave auf diese zugriefen wollen, schlagen fehl. Die Enclave Cache Lines sind verschlüsselt und ihre Integrität geschützt, bevor sie ins RAM geschrieben werden.

Der Schutz von sensitiven Daten setzt die Verhinderung von Preisgabe (Confidentiality) und Manipulation (Integrity) voraus. Dies sind zwei Aspekte, die durch eine kryptografische Lösung adressiert werden können. SGX schützt Daten und sensitiven Code, indem die Daten wirklich at rest und während der Ausführung verschlüsselt bleiben können.

Um nun sensitive Daten bzw. Code (wie unsere PKI CA Keys) zu schützen, müssen diese in verschlüsselte und damit nicht mehr einsehbare Enclaves abgelegt werden. Sobald die Daten die VM verlassen, sind sie geschützt. Dies verhindert andere Teile der Infrastruktur oder Administratoren, auf die geschützten Daten zuzugreifen. Durch das Anwenden von SGX, können einfache Policies wie die folgende etabliert werden:

Alle Encryption Keys werden durch SGX in einer Enclave abgelegt (verschlüsselt)

Falls nun ein Snapshot des des Hypervistor Speichers im Rohformat durchgeführt wird, werden die sensitiven Daten nicht zugänglich sein. Und da ein Angreifer keinen Zugriff auf den für die Entschlüsselung der Daten erforderlichen Key hat, kann er sie nicht einfach so zugänglich machen.

Der Hauptunterschied zwischen SGX und der Standardarchitektur ist, dass das Threat Model von SGX davon ausgeht, dass die System-Software nicht vertrauenswürdig ist. Wie zuvor beschrieben, fasst dies das Problem von Cloud-Lösungen sehr gut zusammen. Das SGX Threat Model impliziert, dass die System-Software für einen Angriff innerhalb einer Enclave eingespannt werden kann.

Als weiteres Beispiel könnte eine Cloud-Plattform nun eingesetzt werden, um sensitive Bilddaten (z.B. im Rahmen von medizinischen Untersuchungen) zu übertragen und speichern. Diese wären dann ebenfalls in der Enclave verschlüsselt und nicht ohne weiteres angreifbar.

Einschränkungen

Ist SGX wirklich sicher? Wir gehen mal davon aus, dass Intel keine Hintertür eingebaut hat – Dementsprechend kann man von einer ziemlich sicheren Lösung sprechen. Angriffe auf Software-Ebene (Malware, Reverse Engineering, etc.) werden ziemlich sicher nicht erfolgreich ausfallen können. Die relevanten Daten lassen sich dementsprechend durch die Verschlüsselung des Prozessors schützen.

Trotzdem gibt es einige Angriffsszenarien auf der Ebene der Hardware bzw. des Microcodes. Anbei eine Liste mit möglichen Risiken, wie sie sich im Cloud-Umfeld vorfinden.

Lediglich die Zeit kann zeigen, ob SGX gegen diese und andere mögliche Angriffe gewappnet ist. Und ob die Technologie eine breite Akzeptanz erfahren wird. Nichts desto trotz ist der Ansatz sehr spannend und ein Schritt in die richtige Richtung. Dies wird durch eine Reihe von Projekten bestätigt, die den Einsatz von SGX vorsehen:

• Microsoft Haven
• Microsoft VC3
• Ubuntu LXD Container Hypervisor (geplant)

Fazit

Intel SGX ist eine spannende Technologie, die konkret aufzeigen kann, wie mehr Sicherheit im Rahmen von Cloud Computing gewährleistet werden kann. Die heutigen Cloud-Plattformen bieten viele Vorteile – Diese zu geniessen erfordert aber immer, dass man dem Cloud-Anbieter ein gewisses Mass an Vertrauen entgegenbringt. In gewissen Situationen kann dies jedoch schlichtweg nicht getan werden. Um diese Risiken adressieren (oder akzeptieren) zu können, müssen Technologien etabliert werden, die einen vertrauenswürdigen Cloud-Host erstellen lassen. SGX hilft dabei, einen Schritt näher an das echte Utility Computing Modell, bei dem der Provider den Zugriff auf Ressourcen gewährleistet (Verarbeitung, Speicherung und Netzwerk), zu kommen.

Über den Autor

Andrea Covello ist seit den 1990er Jahren im Bereich der Informationssicherheit tätig. Seine Schwerpunkte liegen traditionell im Engineering, wobei er als Spezialist im Bereich Windows-Sicherheit, Firewalling und Virtualisierung gilt.

Links

• https://en.wikipedia.org/wiki/Hardware_security_module
• https://en.wikipedia.org/wiki/Skylake_(microarchitecture
• https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx
• https://www.microsoft.com/en-us/research/publication/shielding-applications-from-an-untrusted-cloud-with-haven
• https://www.microsoft.com/en-us/research/publication/vc3-trustworthy-data-analytics-in-the-cloud-using-sgx
• https://www.ubuntu.com/cloud/lxd