Ebenen der Vertraulichkeit in der Cloud : Bewertung der Verschlüsselungsmöglichkeiten bei Microsoft Azure und Google Cloud Platform

Von Inés Atug und André Windsch, Bonn

Der IT-Grundschutz thematisiert Verschlüsselung in diversen Bausteinen, um die Vertraulichkeit von Daten sicherzustellen. Bei der Auslagerung in die Cloud ist die Bedeutung der Vertraulichkeit und damit der Verschlüsselung weiter erhöht, denn Kundensysteme, Anwendungen und damit auch Kundendaten sind in der Cloud zumindest gegenüber dem Cloud-Anbieter exponierter, als dies auf eigener Hardware im eigenen Haus der Fall ist. Im eigenen Rechenzentrum oder Serverraum haben in der Regel nur die Mitarbeiter des jeweiligen Unternehmens und gegebenenfalls eines Dienstleisters Zugriff auf die Systeme; Externe können gegebenenfalls durch eigene Mitarbeiter begleitet werden.

Betreibt man kein eigenes Rechenzentrum, sondern nutzt ein Housing von Hardware in einem fremden Rechenzentrum, könnten zwar Mitarbeiter des jeweiligen Dienstleisters Zugriff auf Systeme und Daten erlangen. Doch auch hier hat der Kunde typischerweise Einfluss auf die Sicherheit seiner physischen Systeme. Beispielsweise können Mittel zur Zutritts- und Zugangsbeschränkung umgesetzt sowie über die Protokollierung eventuelle Zugriffe erkannt werden. Während man beim Housing noch Herr über die Protokollierungsdaten ist, ist dies bei der Cloud nicht mehr der Fall: Sofern der Cloud-Dienstanbieter die Protokollierungsdateien nicht zur Verfügung stellt, kann man nicht nachvollziehen, ob er oder seine Dienstleister Zugriff auf die Daten des Kunden hatten.

Daher ist ein erhöhtes Maß an Vertrauen in Cloud-Anbieter notwendig, weshalb man sich im Voraus angemessen mit dem Anbieter und den angebotenen Lösungen beschäftigen sollte. Da auch das Berechtigungsmanagement vom Cloud-Dienstanbieter bereitgestellt wird, kann auch hier nur bedingt ein Zugriff durch diesen unterbunden werden. Microsoft Azure bietet hierzu den Service „Customer Lockbox“ an, über den sich der Zugriff von Supportpersonal im Sinne des Kunden regeln lässt: So kann der Kunde einstellen, dass Supportpersonal erst nach Freigabe durch ihn auf seine Daten zugreifen darf. Jedoch muss man auch hier der korrekten Umsetzung der Customer Lockbox vertrauen – und gegen einen Insiderangriff wirkt dieser Service nur begrenzt.

Um den Zugriff auf die eigenen Daten gegenüber Mitarbeitern des Cloud-Anbieters abzusichern, ist die Verschlüsselung der gespeicherten Daten eine angemessene Lösung – zumindest insofern die jeweiligen Mitarbeiter keinen Zugriff auf den jeweiligen Schlüssel zur Entschlüsselung haben.

Gefährdungen und Wirksamkeit von Verschlüsselung

Eine Verschlüsselung von Daten während der Übertragung und Speicherung erschwert das Ausspähen von Daten durch Unberechtigte und wirkt so gegen die elementaren Gefährdungen G 0.14 „Ausspähen von Informationen (Spionage)“, G 0.15 „Abhören“ und G 0.19 „Offenlegung schützenswerter Informationen“. Die jeweilige Wirksamkeit hängt davon ab, welche Art Verschlüsselung (siehe Tabelle 1) gewählt wurde: So kann etwa ein Datenbank-Administrator in der Regel auch auf die Daten einer verschlüsselten Datenbank zugreifen, aber ein unberechtigter Dritter kann die Datenbank nicht entschlüsseln, da ihm die Zugangsberechtigungen fehlen. Werden personenbezogene Schlüssel verwendet, kann je nach Umsetzung selbst der Datenbank-Administrator die Daten nicht mehr einsehen.

Bei Diebstahl oder Verlust von Datenträgern (elementare Gefährdungen G 0.16 und G 0.17) kann die Verschlüsselung zwar den eigentlichen Diebstahl/Verlust nicht verhindern, jedoch bleiben die Vertraulichkeit sowie die Integrität der Daten (beim Wiederauffinden) erhalten, insofern dem Auffindenden beziehungsweise Dieb der zugehörige Schlüssel nicht ebenfalls bekannt ist.

Beim Einsatz von Verschlüsselung nach dem Stand der Technik ist es Unbefugten (ohne Schlüssel) in der Regel nicht möglich, gezielt (sinnvoll) den Inhalt von verschlüsselten Daten zu manipulieren. Daher kann Verschlüsselung auch gegen das Manipulieren von Informationen wirken (G 0.22).

Weiterhin kann eine Verschlüsselung notwendig sein, um gesetzliche Vorgaben zu erfüllen (G 0.29 „Verstoß gegen Gesetze oder Regelungen“). Die angebotenen Optionen von Google und Microsoft entsprechen dem Stand der Technik und sind somit geeignet, generelle Anforderungen nach sicherer Verschlüsselung zu erfüllen. Liegen präzisere Anforderungen vor, sind diese gezielt zu betrachten. Besonders bei dieser Gefährdung sollte man beachten, dass ein Cloud-Dienstanbieter zumindest theoretisch bei allen Cloud-nativen Lösungen Zugriff auf die jeweiligen Schlüssel haben könnte: im RAM, im Schlüsselspeicher oder/und auf den Systemen.

Sofern die Verschlüsselung nicht ordnungsgemäß zusammen mit einem passenden Schlüsselmanagement (vgl. [1]) durchgeführt wird, kann es zu Datenverlust (G 0.45) kommen – beispielsweise durch den Verlust der Schlüssel. Fehlplanung oder fehlende Anpassungen (G 0.18) der Verschlüsselung können zu einem Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit führen. Für die angebotenen Cloud-nativen Verschlüsselungsoptionen von Google oder Microsoft sind die zu beachtenden Punkte und Aspekte allerdings gut dokumentiert oder bereits seitens des Cloud-Providers so adressiert, dass Fehler im Rahmen dieser Gefährdung deutlich unwahrscheinlicher sind.

Tabelle 1 stellt die Vor- und Nachteile verschiedener Verschlüsselungsarten einander gegenüber. Gerade in der Cloud erfolgt die Verschlüsselung häufig transparent für den Benutzer oder die Anwendung, was bedeutet, dass der Benutzer in der Regel kein spezielles Passwort zum Entschlüsseln eingeben muss. Entsprechend wichtig ist es, über das Berechtigungsmanagement die Zugriffe möglichst nach dem Need-to-know-Prinzip zu vergeben und vor allem bei Administratoren das Least-Privilege-Prinzip durchzusetzen.

Geteilte Verantwortung

Wie bei den meisten Themen in der Cloud, ist auch bei der Verschlüsselung die geteilte Verantwortung zwischen Dienstanbieter und Kunden zu berücksichtigen. Je nachdem, welches Service-Modell (Infrastructure, Platform oder Software as a Service – IaaS, PaaS, SaaS) betrachtet wird, hat der Cloud-Benutzer mehr (IaaS) oder weniger (SaaS) Möglichkeiten, die Verschlüsselung gemäß eigenen Anforderungen umzusetzen oder aus bereitgestellten Lösungen eine geeignete auszuwählen.

Auch wenn die Verantwortung für die Umsetzung in der Cloud geteilt sein mag, verbleibt – wie auch bei anderen Auslagerungen oder dem Einsatz von Dienstleistern – die Verantwortung für die Sicherheit seiner Daten doch beim Cloud-Benutzer. Daher ist es wichtig, vorab einen geeigneten Dienstanbieter und geeignete Cloud-Services zu identifizieren. Hierbei ist besonders hervorzuheben, dass die angebotenen Lösungen sich nicht nur stark zwischen verschiedenen Dienstanbietern unterscheiden können, sondern auch verschiedene Dienste des gleichen Anbieters unterschiedliche Möglichkeiten umfassen können. Bei der Auswahl sollten die folgenden Punkte berücksichtigt werden:

• Alle bereitgestellten Möglichkeiten sowie standardmäßig durch den Cloud-Dienstanbieter umgesetzte Maßnahmen sollten so detailliert dokumentiert werden, dass sie nachvollziehbar sind und eine grobe Sicherheitseinschätzung seitens des (potenziellen) Kunden ermöglichen.
• Es sollte unterstützende Dokumentationen zur Umsetzung durch den Cloud-Benutzer geben.
• Die angebotenen und standardmäßig umgesetzten Maßnahmen sollten auf geeigneten Standards und Best Practices basieren (etwa gem. NIST oder der BSI TR-02102 Kryptografische Verfahren: Empfehlungen und Schlüssellängen).
• Die geeignete Umsetzung sollte durch unabhängige Prüfungen attestiert/zertifiziert sein.
• Alle ruhenden Daten von Kunden sollten auf den Systemen der Cloud-Umgebung immer verschlüsselt gespeichert werden.
• Daten, die innerhalb der Cloud versendet/bewegt werden, sollten verschlüsselt sein, vor allem wenn der Transfer zwischen verschiedenen Rechenzentren des Cloud-Dienstanbieters stattfindet.

Hierbei ist es naturgemäß wichtig, diese Bewertung durchzuführen, bevor eine Entscheidung beziehungsweise Wahl getroffen wird. Es sollte zudem immer eine Option sein, einen Cloud-Dienst überhaupt nicht oder nur für bestimmte Schutzbedarfskategorien zu verwenden, wenn er keine den eigenen Anforderungen entsprechende Sicherheitslösungen anbietet.

Generell können die Möglichkeiten zur Verschlüsselung von Daten in drei grobe Überkategorien unterteilt werden, die auf den Stadien der Datenverarbeitung basieren:

• Verschlüsselung von Daten bei der Übertragung (Data in Motion / in Transit): Der Datentransfer sollte möglichst immer verschlüsselt werden können. Optimalerweise sollte dies bereits standardmäßig umgesetzt sein, ohne dass Benutzer dies erst aktivieren müssten.
• Verschlüsselung von gespeicherten Daten (Data at Rest): Die Verschlüsselung von in der Cloud gespeicherten Kundendaten sollte möglichst immer möglich sein. Optimalerweise sollten dabei verschiedene Verschlüsselungsarten zur Verfügung stehen.
• Verschlüsselung von Daten während der Verarbeitung (Data in Use): Diese Verschlüsselungskategorie befindet sich noch in den Anfängen, könnte aber im Hinblick auf die Zukunft eine aussichtsreiche Option werden, um Daten vor dem Zugriff durch Personen oder andere Prozesse zu schützen, die Zugriff auf das physische System haben beziehungsweise auf dem gleichen physischen System ablaufen.

Microsoft Azure bietet zur Absicherung von Daten während der Verarbeitung den Cloud-Dienst „Azure Confidential Computing“ an, der sich derzeit noch im sogenannten Preview-Modus befindet. Über diesen Dienst soll sichergestellt werden, dass sich Daten während der Verarbeitung in einem Trusted-Execution-Environment (TEE) befinden und damit dem Zugriff anderer Ressourcen, die gleichzeitig Daten verarbeiten, entzogen bleiben.

Data in Motion

Die Verschlüsselung von Daten, die übertragen werden, ist keine neue Sicherheitsmaßnahme. Da jedoch die Kommunikation mit der jeweiligen Cloud-Infrastruktur in der Regel über öffentliche Netzwerke erfolgt, sollte man darauf achten, dass Daten nicht unverschlüsselt übertragen werden. Auch in der Cloud-Infrastruktur selbst sollten die Daten nur verschlüsselt übertragen werden, da man sich diese Infrastruktur ja üblicherweise mit anderen Kunden teilen muss.

Aus dem Baustein CON.1 „Kryptokonzept“ stammt die Anforderung CON.1.A3 „Verschlüsselung der Kommunikationsverbindungen“: Demnach ist zu prüfen, ob Kommunikationsverbindungen verschlüsselt werden können, und wenn dies möglich ist, sollte es auch umgesetzt werden. Im Fall der Cloud-Dienste von Microsoft Azure und Google Cloud Platform werden Kommunikationsverbindungen bereits standardmäßig verschlüsselt – der Kunde hat dann je nach Cloud-Dienst noch die Möglichkeit, etwa eigene Schlüssel zu verwenden oder weitergehende Verschlüsselungsmaßnahmen zu ergreifen.

Während in Microsoft Azure allgemein bekannte Verschlüsselungsarten eingesetzt werden, nutzt die Google Cloud Platform zur internen Verschlüsselung die sogenannte Application-Layer-Transport-Security (ALTS). Dieses von Google entwickelte System zur gegenseitigen Authentifizierung und Transportverschlüsselung sichert innerhalb der Google Cloud Platform die Remote-Procedure-Call-(RPC)-Kommunikation ab. Das Konzept von ALTS entspricht in etwa Transport-Layer-Security (TLS) mit gegenseitiger Authentifizierung, wobei ALTS speziell für den Cloud-Einsatz entwickelt wurde und daher beispielsweise die Identitäten an Entitäten und nicht an bestimmte Servernamen gebunden sind.

Auch bei der Kommunikation zwischen Microservices geht Google einen neuen, eigenen Weg mit dem Einsatz von istio, nach eigener Aussage ein „Open Platform-Independent Service Mesh that provides Traffic Management, Policy Enforcement, and Telemetry Collection“ [4]. Mit istio lässt sich eine verteilte Microservice-Architektur betreiben, die Sicherheitsfunktionen – wie beispielsweise Monitoring und gegenseitige Authentifizierung – nativ unterstützt. Tabelle 2 stellt die Möglichkeiten von Microsoft Azure und Google Cloud Platform hinsichtlich der Verschlüsselung der Kommunikation einander gegenüber.

Data at Rest

Da die Infrastruktur zur Speicherung von Kundendaten mit anderen Cloud-Kunden und dem Cloud-Dienstanbieter geteilt wird, kann es sein, dass Sicherheitsmaßnahmen wie der Einsatz eines feingranularen Berechtigungsmanagements als nicht ausreichend angesehen werden und man im IT-Sicherheitskonzept die verschlüsselte Speicherung von Daten fordert. Da jedoch in der Cloud Verschlüsselung, sofern man sie nicht selbst implementiert, transparent für den Benutzer ist, kann man auch mit ihr nicht auf ein feingranulares Berechtigungsmanagements verzichten. Die Anforderungen an ein feingranulares Berechtigungsmanagement, das die Prinzipien des „need to know“ für Benutzer und „least Privilege“ für Administratoren umsetzt, lässt sich nicht durch eine Datenverschlüsselung ersetzen.

Im Grundschutz-Baustein OPS.2.2 „Cloud-Nutzung“ wird in der Anforderung OPS.2.2.A17 „Einsatz von Verschlüsselung bei Cloud-Nutzung“ gefordert, hinsichtlich der Verschlüsselung die Besonderheiten des jeweiligen Cloud-Service-Modells (IaaS, PaaS, SaaS) zu betrachten. Der vorliegende Artikel geht dazu auf die Verschlüsselungsmöglichkeiten in IaaS und PaaS ein, wo Daten in der Regel entweder in einem Speicherdienst oder einer Datenbank gespeichert werden. Für diese beiden Varianten bieten die Cloud-Serviceprovider Google und Microsoft jeweils Verschlüsselungsmöglichkeiten an.

Daten, die mittels PaaS verarbeitet werden, landen in der Regel in einem gängigen Cloud-Speicher, der auch für IaaS zur Verfügung steht. In diesem Fall können auch solche Daten, die im PaaS-Umfeld verarbeitet werden, mit gängigen Speicherverschlüsselungsmethoden verschlüsselt werden.

Bei beiden Cloud-Dienstanbietern kommt in der Regel für die Verschlüsselung gespeicherter Daten mindestens AES-256 zum Einsatz. Tabelle 3 stellt die Möglichkeiten von Microsoft Azure und Google Cloud Platform zur Verschlüsselung von gespeicherten Daten einander gegenüber.

Verschlüsselung reicht nicht

Die bisher genannten Aspekte zeigen auf, dass Verschlüsselung alleine (selbst mit einem guten Schlüsselmanagement) nicht vollumfänglich schützen kann. Es bedarf darüber hinaus in Cloud-Umgebungen weiterer Sicherheitsmaßnahmen – beispielsweise Protokollierung und/oder Berechtigungsmanagement.

Neben der Anforderung OPS.2.2.A17 „Einsatz von Verschlüsselung bei Cloud-Nutzung“ sind beim Thema Verschlüsselung in der Cloud je nach Geltungsbereich noch weitere Verschlüsselungsanforderungen aus anderen Grundschutz-Bausteinen zu beachten. So müssen auch in der Cloud beispielsweise Passwörter verschlüsselt übertragen werden, wie dies ORP.4.A23 „Regelung für Passwortverarbeitende Anwendungen und IT-Systeme“ fordert. Sowohl bei Microsoft Azure als auch bei der Google Cloud Platform ist allerdings sichergestellt, dass sichere Authentifizierungs- und Autorisierungsprotokolle verwendet und Passwörter somit verschlüsselt übertragen werden.

Zudem kann es notwendig sein, Protokollierungsdaten nach OPS.1.1.5.A12 „Verschlüsselung der Protokollierungsdaten“ verschlüsselt zu speichern: In der Google Cloud Platform werden alle gespeicherten Daten grundsätzlich mittels AES-256 verschlüsselt. Sofern die Protokolldaten in einen separaten Speicher verschoben werden, können diese auch mittels eines vom Kunden in Googles „Cloud Key Management Service“ (Cloud KMS) erstellten und verwalteten Schlüssels verschlüsselt werden. Bei Azure hingegen kann direkt ein vom Kunden verwalteter Schlüssel (Customer-Managed Key, CMK) verwendet werden, um die Log-Analytics-Arbeitsbereiche und Application-Insights-Komponenten zu verschlüsseln. Nach der Konfiguration werden alle Daten, die an deren Arbeitsbereiche oder Komponenten gesendet werden, mit dem CMK aus dem Azure Key Vault verschlüsselt. Allerdings ist dieser Service nur eingeschränkt anwendbar, da er beispielweise nur für neue Daten gilt – bereits vorhandene Daten sind weiterhin mit dem von Microsoft bereitgestellten Schlüssel verschlüsselt.

Fazit

Sowohl Microsoft Azure als auch Google Cloud Platform setzen Verschlüsselungsmethoden ein, die dem Stand der Technik entsprechen, also in der Fachwelt allgemein als sicher anerkannt sind. Dabei ist jedoch anzumerken, dass Google beispielsweise mit dem Einsatz des alternativen Protokolls ALTS für die Verschlüsselung internen Datenverkehrs auf ein Protokoll setzt, das noch nicht in der gleichen Tiefe wie etwa TLS untersucht worden ist.

Informationen darüber, was und wo standardmäßig verschlüsselt wird, liegen sowohl bei Google Cloud Platform als auch bei Microsoft Azure verteilt in der Dokumentation vor. Diese Dokumente haben bei beiden Anbietern eine gute Qualität und einen angemessenen Detaillierungslevel.

Zusätzlich zu den vorgestellten Möglichkeiten könnte man Daten bereits lokal, also vor dem Transfer in die Cloud, verschlüsseln. Diese Option wurde im Rahmen dieses Artikels jedoch nicht weiter adressiert, da es die Funktionalität der Cloud auf eine Datenablage und -Austauschplattform reduziert.

Wichtig ist, nochmals zu betonen, dass auch eine eingerichtete Verschlüsselung ihre Wirkung nur dann entfalten kann, wenn weitere Sicherheitsmaßnahmen, wie beispielsweise ein granulares Berechtigungsmanagement und eine geeignete Schlüsselverwaltung, umgesetzt sind.

Inés Atug ist Senior Expert, André Windsch ist Consultant bei der HiSolutions AG – zu ihren Schwerpunkten gehören Cloud-Security und kritische Infrastrukturen.

Literatur

[1] Microsoft, Übersicht über die Azure-Verschlüsselung, September 2018, https://docs.microsoft.com/de-de/azure/security/fundamentals/encryption-overview
[2] Google, Inaktive Daten in der Google Cloud Platform verschlüsseln, April 2017, https://cloud.google.com/security/encryption-at-rest/default-encryption/
[3] Google, Verschlüsselung bei der Übertragung in Google Cloud, Dezember 2017, https://cloud.google.com/security/encryption-in-transit/
[4] Istio – connect, secure, control, and observe services, Projektwebsite, https://istio.io
[5] Inés Atug, Schlüsselmanagement in der Cloud, Bewertung der Funktionalität von Azure Key Vault und Cloud Key Management Service, <kes> 2020#1, S. 58