Sicherheit ist in der IT ein Dauerbrenner und täglich gibt es Berichte über Sicherheitslücken, digitale Einbrüche, verschlüsselte Systeme und entwendete Daten. Genauso oft liest man, dass Verschlüsselung die Lösung sei. Stichworte sind Bring Your Own Key (BYOK), Double Key Encryption oder Confidential Computing. Aber was hilft wirklich und vor wem muss ich mich überhaupt schützen? Und ist Verschlüsselung eventuell die Lösung für mehr Kontrolle in der Public Cloud? Darüber sprechen wir mit Jan Tietjen, Sicherheitsexperte bei Accenture.
Jockel: Wie funktioniert Verschlüsselung in der Cloud und was ist dabei wichtig?
Jan: Verschlüsselung in der Cloud funktioniert genauso, wie anderswo auch. Unterschieden wird zwischen der Plattform-Verschlüsselung, der Verschlüsselung auf Applikationsebene und der Transportverschlüsselung beim Zugriff auf Cloud-Daten.
Aber fangen wir mit Plattform-Verschlüsselung an. Nehmen wir als Beispiel Microsoft Azure. Die bieten an, dass sie auf der Plattform eine sogenannte Bitlocker-Verschlüsselung einsetzen. Diese stellt sicher, dass alle Festplatten der Cloud-Server verschlüsselt werden. Den Schlüssel besitzt allerdings Microsoft und den bekommt der Kunde nie zu sehen. Aber das ist eine Verschlüsselung, die dafür sorgt, dass jemand, der ins Rechenzentrum einbricht und die Festplatten stiehlt, damit nichts anfangen kann. Man schützt sich also vor einem Diebstahl.
Auf Applikationsebene gibt es verschiedene Möglichkeiten der Verschlüsselung. Als Kunde kann ich entscheiden, ob grundsätzlich alle Daten auf der Plattform verschlüsselt sein sollen. Dann gibt es verschiedene Schlüsselverfahren. Im besten Fall hat jeder Mandant, also jeder Kunde, seinen eigenen Schlüssel. Damit werden die Daten bei einem Durchbruch, von einem Mandanten zum anderen, unbenutzbar.
Falls der Cloud-Anbieter diesen Schlüssel erstellt hat und diesen auch besitzt, schützt mich das natürlich nicht vor diesem. Wenn ich den Schlüssel selbst generiere und dem Cloud-Anbieter übergebe, ist dieser auch weiterhin der Hüter des Schlüssels. Aber ich habe die Schlüsselqualität selbst bestimmt. Dies spielt bei Verschlüsselung immer eine große Rolle. Denn die Güte des Schutzes durch Verschlüsselung ist direkt abhängig von der Qualität des Schlüssels und davon, wie der Hüter des Schlüssels diesen vor Fremdzugriff schützt.
Die Transportebene wird in der Regel über HTTPS verschlüsselt, also was wir unter SSL- oder TLS-Verschlüsselung kennen. Das ist zertifikatsbasiert. Außerdem gibt es Hashverfahren, um die Daten vor Manipulationen zu schützen, beziehungsweise um zu überprüfen, ob Daten verändert wurden oder kaputtgegangen sind. Bei dem Übertragungsverfahren spielt ebenfalls wieder der Schlüssel eine große Rolle. Wie wird er ausgetauscht, wo wird er erzeugt, wie oft wird er gewechselt, also Schlüsselwechselverfahren und co.
Wirklich wichtig ist im Grunde, wer den Schlüssel besitzt und wer ihn kennt. Das ist essenziell. Deswegen sollte je nach Datenkritikalität verschlüsselt werden und desto kleiner sollte der Kreis der Mitwisser für einen Schlüssel sein. Grundsätzlich sollte man sich überlegen, ob es Möglichkeiten gibt, nachträglich einen Teilnehmer aus dem verschlüsselten Kontext wieder zu entfernen. Diesem also den Zugriff auf die Daten zu entziehen. Was zum Beispiel über Zertifikate möglich ist.
Jockel: Vor wem muss ich mich wirklich schützen, was ist meine größte Gefahr?
Jan: Grundsätzlich sollte ich mich vor jedem schützen, den die Informationen nichts angehen. Diese Gruppe ist groß, wenn es um eine Firma geht, also Firmeninhalte oder auch Intellectual Property, also die jeweiligen Kronjuwelen. Da geht es um Wettbewerbsvorteile, da geht es um Absprachen, da geht es um Geschäftsgeheimnisse. Es geht zum Beispiel auch um Krankenakten oder Krankschreibungen. Ich will ja nicht, dass jeder weiß, was ich mit meinem Arzt kommuniziere. Solche Daten müssen geschützt werden.
Dann gibt es zusätzlich die Thematik der Strafverfolgungsbehörden, beziehungsweise der Geheimdienste. Wir haben gewisse Rechte, die uns Sicherheit, zumindest in unserer Demokratie, garantieren. Aber wenn ein anderes Land im Spiel ist, sieht das Ganze schon anders aus. Alle wollen heutzutage raus aus der „vor Snowden“- Situation, als alle Informationen einfach unverschlüsselt im Internet verteilt wurden. Niemand hat sich früher, also vor 2012, wirklich darum gekümmert, dass mitgelesen werden kann. Niemand ging davon aus, dass irgendjemand den gesamten Internetverkehr mitschneidet. Und dann kam raus, dass die NSA genau das macht.
Heutzutage gehört es einfach zum guten Ton, dass man Inhalte und Kommunikation verschlüsselt. Wollen wir vorneweg grundsätzliche Verschlüsselung, dann muss man sich überlegen, wie kritisch die Daten sind, die ich übertragen will. Wie kritisch ist die Anwendung? Und je nachdem muss das Verschlüsselungsverfahren gewählt und auch die Verteilung der Schlüssel geregelt sein. Es muss auch entsprechend sinnvoll eingesetzt werden und schützt nicht vor allem und jedem. Denn es gibt keine hundertprozentige Sicherheit und somit auch keinen hundertprozentigen Schutz!
Im Cloud-Kontext ist größte Gefahr, dass jemand Zugriff auf meine Daten bekommt und sie zum Beispiel verschlüsselt, in diesem Fall also ein Ransomware Angriff. Informationen sind heutzutage die Währung. Das heißt, wir schützen uns im Endeffekt durch geeignete Verschlüsselung und geeignete Schlüsselhaltung vor unbefugtem Zugriff. Und auch vor Schaden, den wir nehmen können, zum Beispiel durch Veröffentlichung oder Manipulation von Daten.
Jockel: Welche Verschlüsselungs-Standards gibt es in der Public Cloud und vor wem schützen sie?
Jan: Symmetrische und asymmetrische Verschlüsselungsverfahren, wie zum Beispiel AES und RSA. Es gibt dazu sehr gute Übersichten, zum Beispiel vom BSI (Bundesamt für Sicherheit in der Informationstechnik) oder ECRYPT (European Network of Excellence in Cryptology). Dort steht genau beschrieben, welche Verschlüsselungsverfahren heutzutage als gut und welche als schlecht gelten. Das Interessante ist ja, dass es sehr, sehr viele Varianten und Verfahren gibt, auch in Kombinationsmöglichkeiten. So gibt es welche, die alt sind und als gebrochen gelten, beziehungsweise als mathematisch angreifbar.
Cloud-Plattformbetreiber kennen sich mit sowas aus und nutzen nur die besten Verfahren. Können sie auch machen, weil es sie nichts kostet. Gerade die modernen Verfahren werden heutzutage in Hardware unterstützt. Das heißt, dass das früher oft angebrachte Argument, gute Verschlüsselungsverfahren belasten die CPU zu stark, heutzutage einfach nicht mehr gilt.
Aber wir erinnern uns, es geht immer darum wer den Schlüssel besitzt und wer ihn ausgewürfelt hat. Dazu muss man sich wirklich Gedanken machen. Wenn ich jetzt Azure Active Directory benutze, so ist dieses in der Lage eine sogenannte Public Key Infrastruktur für meine Schlüsselverteilung für mich als Kunden aufzubauen. Es würfelt nun für mich alle Schlüssel und kennt diese dann selbstverständlich auch. Nun kann man sich überlegen, ob man das will und ob man daran glaubt, dass der Schlüssel nicht doch, ohne mein Wissen, woanders hingeschoben, beziehungsweise jemand anderem zur Verfügung gestellt wird.
Die sicherste Methode ist den Schlüssel selbst zu erzeugen und selbst zu verwalten. Ich schützte mich durch Verschlüsselung also vor allen unberechtigten Zugriffen, im Falle von AAD, aber nicht vor dem Anbieter selbst. Solange der Server bei einem Cloud-Service-Providers steht, hat dieser auch Zugriff darauf. Den muss er auch haben, weil ein Kunde im Zweifelsfall anruft, wenn er den Schlüssel „verloren“ hat. Und dann will er Ersatz, damit nicht alle seine Unternehmensdaten weg sind. So gesehen haben wir hier auch eine Art Backup-Funktion des Cloud-Service-Providers, was Schlüssel angeht.
Jockel: Schützt der Standard auch vor dem Zugriff der USA mit Hilfe des Cloud Acts?
Jan: Solange der Schlüssel bei einem amerikanischen Anbieter liegt, kann man nicht ausschließen, dass er abgezogen werden könnte. Ob das gemacht wird oder nicht, ist unklar. Große Cloud-Service-Provider veröffentlichen in regelmäßigen Abständen die Anzahl der Anfragen von Regierungen und Strafverfolgungsbehörden. Aber nicht die Anfragen von Geheimdiensten, denn diese Information dürfen sie gar nicht publizieren.
Wenn die US-Regierung versuchte Vertrauen aufzubauen, dann hat sie es mit dem Cloud Act wieder kaputt gemacht. Dementsprechend sollte man bei kritischen Daten, wo man wirklich sicher sein will, schauen, dass diese auf einer Plattform liegen, wo keine Geheimdienste drankommen. Da der Cloud-Anbieter den Schlüssel hat, hat im Zweifel auch ein Geheimdienst Zugriff. Das dementieren zwar alle Hyper-Scaler aus den USA, aber wenn man sich den Cloud Act anguckt, dann können die das eigentlich gar nicht garantieren.
Für die meisten Firmen ist der Zugriff von Geheimdiensten im Prinzip erstmal egal, solange es keine regulierten Branchen, wie Banken oder Versicherungen, sind. Die meisten schlucken die Kröte dann doch und machen den Schritt in die Public Cloud einfach. Außerdem glauben viele noch immer, dass sie nicht im Fokus stünden. Obwohl: wenn alle überwacht werden, warum dann nicht auch du?
Letztendlich ist es immer ein Spagat zwischen „wie sicher will ich sein“ und „wieviel Funktionalität möchte ich noch benutzen können“. Denn was nützt mir eine Cloud-Plattform, wenn ich die ganzen Cloud-Plattform-Funktionen nicht mehr nutzen kann? Dann kann ich genauso gut Dropbox benutzen.
Deutsche Behörden sehen den Schritt in die Public Cloud kritisch, weil sie sich genau diese Fragen stellen. Auf der einen Seite sind die Amerikaner unsere Freunde, aber das kann auch ganz schnell vorbei sein und man landet am anderen Ende einer Sanktionsliste. Das ist eine wichtige Überlegung, die man immer bedenken sollte, gerade wenn man mit Public Clouds arbeitet. Was passiert zum Beispiel, wenn der Anbieter pleitegeht und wie bekomme ich meine Daten so schnell wie möglich wieder runter von der Plattform? Und wie sorge ich dafür, dass meine Daten nicht weiterverwendet oder weitergegeben werden können?
Jockel: Welche erweiterten Verschlüsselungsmethoden bietet die Public Cloud?
Jan: Es gibt zum Beispiel auf der Azure-Plattform eine Verschlüsselungsmethodik, die sich Double Key Encryption (DKE) nennt. Also eine Zwei-Schlüssel-Variante. Dabei verwendet Microsoft für die Verschlüsselung auf der Plattform den einen Schlüssel und ich als Kunde habe auch noch einen weiteren Schlüssel.
Die Ver- und Entschlüsselung passiert dann in zwei Stufen. Die erste Entschlüsselung mit dem Microsoft-Schlüssel für die Applikationsdaten auf der Plattform und die zweite Entschlüsselung für die Daten mit meinem Schlüssel auf meinem Kundenrechner. Meinen Schlüssel habe nur ich und den habe ich auch nie auf der Plattform abgelegt. Das bietet den Vorteil, dass ich 1. gegen andere Mandanten, 2. aber auch vor dem Zugriff durch Microsoft geschützt bin.
Hört sich jetzt erstmal nach der Lösung schlechthin an. Ist es aber nur zum Teil, weil die allerwenigsten Applikationen diese Double Key Encryption unterstützen. Microsoft kann mit den Daten nicht arbeiten und dementsprechend kann ich keine Cloud-Tools oder -Analysen nutzen, sondern nur reine Daten. Das sind natürlich massive Einschränkungen und das erklärt auch, warum diese Art der Verschlüsselung lange nicht für alle Dienste angeboten wird.
Im Marketing wird suggeriert, dass Double Key Encryption für alles bereitsteht, aber wenn man dann genauer hinschaut, wird man die Einschränkungen schnell feststellen. Microsoft bietet dann an, dass man eine andere Verschlüsselung nutzen könne, denn sie seien ja eh Vertrauenswürdig. Was kann da schon schiefgehen?
Jockel: Welche Abwägungen und Abstriche muss ich bei diesen erweiterten Methoden machen?
Jan: Sichere Verschlüsselungsverfahren kann man sich suchen und die werden auch angeboten auf den Plattformen. Aber jetzt sind wir wieder am Anfang der Thematik. Wie sieht es denn mit dem Schlüssel aus? Und ist das Verschlüsselungsverfahren zum Beispiel Quantensicher? Es gibt Verschlüsselungsverfahren, die sind mit Quantencomputern, wenn sie denn verfügbar sind, einfach und schnell zu entschlüsseln. Da kann man sich jetzt schon die Verfahren aussuchen, die für einen längeren Zeitraum Dinge verschlüsseln und auch von Quantencomputern nicht einfach geknackt werden können.
Die Frage ist: Welche Abwägungen und Abstriche muss ich machen, wenn ich erweiterte Verschlüsselungsmethoden verwenden will? Bei Double Key Encryption ist es ein hoher Funktionalitätsverlust, da ich auf Plattformfunktionalität verzichte. Man sollte grundsätzlich mindestens „Bring your own key“ (BYOK) nutzen, um die Schlüsselqualität nachweislich hochzuhalten und es damit für potentielle Mithörer und Datendiebe so anstrengend wie möglich zu machen. Ziel sollte also sein die Komplexität der sogenannten „brute force“-Entschlüsselung für Angreifer, die nicht direkt auf den Key Holder oder seine Mitarbeiter zugreifen können, so weit wie möglich hochzuziehen.
Alternativen könnten intermediate Verschlüsselungen sein, also sowas wie ein Cloud Access Security Broker (CASB), der sich zwischen mich als Anwender und die Kommunikation mit der Cloud hängt. Da gibt es Anbieter, die versprechen, dass sie die Nutzung von Microsoft Office Tools dahingehend ändern, dass sie die Daten transparent in der Mitte verschlüsseln. Ich persönlich sehe diese Idee kritisch. Erstmal ist es wahnsinnig komplex und erfordert, dass der Anbieter von dieser Zwischenlösung unglaublich nah an Microsoft dran ist, um Veränderungen im Protokoll anpassen zu können.
Also letztendlich vertraue ich Microsoft nicht mehr, aber dafür vertraue ich jetzt zum Beispiel einer israelischen Firma, die diese Software herstellt. Und jetzt sagt die “wir sichern den Schlüssel total super mit einem High Security Hardware Security Module” oder so ähnlich. Aber, das sagt Microsoft doch auch bereits!
Jockel: Für Souveränität versuchen Organisationen Leistungsfähigkeit und Kontrolle gleichermaßen zu optimieren. Welches Verschlüsselungskonzept würdest du öffentlichen Organisationen diesbezüglich empfehlen?
Jan: Nehmen wir als Beispiel die Beantragung für ein amtliches Dokument. Hier geht es vor allem um persönliche Daten, die nach DSGVO geschützt werden müssen. Erstmal gibt es die verschlüsselte Verbindung zum Server. Bei der Verarbeitung der Daten, welche ja nur temporär wichtig sind, müsste nur das Ergebnis gespeichert werden. Man könnte es so regeln, dass die übersendeten Informationen nachträglich wieder gelöscht werden. Es werden bestimmte Basisdaten der Behörden genutzt, die aber in der Private Cloud, also im behördlichen Rechenzentrum, bleiben. Die Erzeugung des tatsächlichen Dokumentes passiert also in der Private Cloud.
Die Benutzeroberfläche verlagert man aber in die Public Cloud. In der Public Cloud können auch alle Vorarbeiten gemacht werden, wenn also noch keine kritische Datenverarbeitung stattfindet. Zum Beispiel könnte eine AI-geführte Beratung stattfinden, damit die richtigen Daten eingegeben werden und alle Fragen geklärt sind, bevor die Daten an eine Behörde geschickt werden. Manuelle Arbeiten und vermeidbare Rückfragen werden so minimiert.
Nur das finale Dokument geht zurück und wird dem Benutzer über ein Public Cloud Interface bereitgestellt. Aber die ganze Mechanik in der Public Cloud hätte gar nicht die Möglichkeit weitere Dokumente anzufordern. Es ist eine One-Way-Verbindung. Eine andere interessante Idee wäre, dass die Public Cloud gar nicht das entschlüsselte Dokument sieht, sondern dieses verschlüsselt an den Kunden übertragen wird. Dann bekommt der Nutzer einen Schlüssel auf einem anderen Weg, mit dem er außerhalb der Plattform entschlüsseln kann.
Jockel: Welche Möglichkeiten zur Datensouveränität siehst du, bezogen auf den Schutz vor dem Cloud Act, durch Hybrid oder Multi-Cloud-Ansätze?
Jan: Die Lösung kann sein, dass man je nach Datentyp eine geeignete Abschätzung macht. Sich also überlegt, wie wichtig die zu verarbeitenden Daten sind und wie sehr sie geschützt werden müssen. Auch das Militär hat kein Thema mit amerikanischer Abhängigkeit, weil sie da drin sind, wie sonst kaum einer. Bei der pragmatischen Datenkategorisierung muss dieser Punkt berücksichtigt werden, zumindest, wenn es um 80% der Standardanwendungen geht.
Die Frage ist also: Vor wem schütze ich mich? Daher sollte eine Gesamtarchitektur betrachten werden, in der auch die Risikobetrachtung mit drin ist. Man sollte die Risiken ehrlich darstellen und sich bei jedem Schritt überlegen, ob das im eigenen Rechenzentrum oder in der Public Cloud passieren muss. Aufgrund dieser Bewertung fällt die Entscheidung, welche Plattformen ich benutzen kann. Das Restrisiko, dass die Vereinigten Staaten oder ein anderer Geheimdienst da drankommen können, bleibt bestehen. Und das tut es sowieso. Platt gesagt, schicken die einen Agenten los, der meine Familie bedroht. All diese Punkte sollte man immer mit einbeziehen, wenn der Kreis der Personen groß ist und sich kaum sinnvoll einschränken lässt. Allein schon das Risiko durch hohe Fluktuation der Mitarbeiter besteht immer.
Am Ende bleibt es ein Trade Off. Der ist nicht vermeidbar und eigentlich wäre die souveräne Cloud dann die beste Lösung. Wirtschaftlich interessant ist das tatsächlich für die Anbieter dieser souveränen Clouds, also zum Beispiel SAP und Arvato. Die bauen auf dem Microsoft Cloud-Stack auf, den man wahrscheinlich nicht komplett kontrollieren kann. Dabei vergessen wir oft, dass das wirklich 1 zu 1 das gleiche Problem, wie in der Private Cloud, ist.
Es gibt andere Anbieter, die zum Beispiel auf reine Open-Source-Lösungen setzen. Da muss man sich überlegen, ob das wirklich viel besser ist. Man kann sich den Source Code angucken, aber ob das viel sicherer ist? Millionen Zeilen an Programmcode lassen sich nicht kontrollieren. Zumindest sind die USA nicht drin, aber trotzdem bleibt am Ende das alte Geheimdienst-Risiko. Deswegen ist Open-Source tatsächlich schon eine gute Sache. Es löst die Sanktionsproblematik, aber es bleibt ein sehr heftiges Szenario mit hohem Aufwand für den Betreiber. Das geht in Richtung Autarkie im Gegensatz zu Souveränität.
Jockel: Was könnten Lösungen sein?
Jan: Es bleibt die Frage der Datenkategorisierung. Also was ist eine wirklich gute Datenkategorisierung, auf der man eine sinnvolle Entscheidung für Plattform-Verwendung treffen kann? Auch eine pragmatische Entscheidung.
Was uns fehlt ist ein vernünftiges Framework, beziehungsweise Werkzeuge, mit dem wir unsere Applikationen nach Datenkritikalität auf Multi-Cloud oder Hybrid-Cloud verteilen können. Auch fehlen zusätzlich noch die Tools dafür, mit denen sich diese Verteilung sicher gestaltet. Ansätze sind aber vorhanden. Aber da braucht man sicherlich ein großes Maß an Standardisierung und nicht nur einzelne souveräne Cloud-Anbieter. In dem Sinne wird es wahrscheinlich gar nicht die eine souveräne Cloud geben, sondern das wird ein Verbund aus Leistungen, die von verschiedenen Herstellern kommen. Und dann brauche ich eben dieses Framework, um dieses Konstrukt wie EINE Plattform zu verwenden.
Die Frage kann auch sein, welche Funktionalität ist „Mandatory“, „Optional“ oder “nice to have”. Dann kannst du alles, was “nice to have” ist ignorieren, wenn etwas passiert und diese Funktionen wegfallen. Das merken vielleicht ein paar Kunden, aber die „Mandatory“-Funktionalität bleibt bestehen und das Produkt ist benutzbar.
Dementsprechend müsste man, ausgehend von der Datenkategorisierung, eigentlich den kompletten Stack modularisieren. Also im Grunde wie eine Supply Chain, die dafür sorgt, dass Daten einer bestimmten Kritikalität gar nicht auf einer nicht dafür zugelassenen Plattform auftauchen können.
