E2E Verschlüsselung in Azure Cloud

[SaxnPaule]

Hallo Community,

im Rahmen eines Projektes ist der Kundenwunsch Daten aus einem onPremise System in die Azure Cloud zu transferieren.

Als Einstiegspunkt in die Cloud ist EventHub gesetzt. Grundsätzlich alles kein Problem, allerdings ist eine Anforderung eine E2E Verschlüsselung.

Genau an dieser Stelle habe ich noch einen Knoten im Kopf oder denke vielleicht falsch.

Für alles was im Azure passiert kann man einen Key hinterlegen und somit in allen beteiligten Services auf die Daten zugreifen. Klar soweit.

Nun sollen aber die Daten bereits im onPremise System verschlüsselt und anschließend übertragen werden. Genau das ist der Knackpunkt.
Angenommen ich habe einen eigenen Schlüssel im onPremise System, damit verschlüssele ich die Daten und schicke sie dann ans EventHub. Da kommt doch dann nur Datensalat an, da das Eventhub zum entschlüsseln keinen Key hat.

Mit der BYOK Funktion kann ich mit meinem eigenen Schlüssel ja ausschließlich den von MS genutzten Schlüssel nochmalig verschlüsseln. Zudem wird dieser ja nur für ruhende Daten verwendet und nicht für Daten, die aus dem EventHub an andere Services weitergereicht, modifiziert und letzten Endes in einer Datensenke persistiert werden.
https://docs.microsoft.com/de-de/azure/event-hubs/configure-customer-managed-key


Ist die Anforderung an eine E2E Verschlüsselung ohne "eigene" Komponenten in der Cloud überhaupt umsetzbar?


Falls nicht wäre vielleicht noch ein Ansatz, den Datensalat so wie er ist im EventHub entgegenzunehmen, anschließend an eine Custom-Komponente (z.B. kleine Spring Boot App als Docker Container) weiterzureichen, welche die Daten entschlüsselt und diese dann "entschlüsselt" zur Weiterverarbeitung weiterreicht. Der gesamte Transfer innerhalb der Cloud wäre dann ja immer noch verschlüsselt mit dem in der Cloud im Key-Vault hinterlegten Key.
Die E2E Verschlüsselung wäre dann vom onPremise System bis zu Custom Komponente in der Cloud und eine weitere Verschlüsselung über alle Komponenten innerhalb der Cloud. Für das Stück vom EventHub bis zur Custom Komponente gäbe es dann eine doppelte Verschlüsselung.

 

[Murray B.]

Wo sind denn die beiden E von E2E?

 

[SaxnPaule]

Idealerweise beim Start onPremise in einer Custom Applikation und in der Datensenke nach allen Transformationen in der Cloud. Aber genau dieses Szenario bekomme ich irgendwie nicht zu Ende gedacht.

onPremise [Anfang 1] ---> Azure Event Hub ---> Datentransformation ---> Datensenke/Persistenz [Ende 1]

Die von mir genannte Alternative hätte zwei sich überschneidende, also temporär doppelt verschlüsselte Abschnitte.

onPremise [Anfang 1] ---> Azure Event Hub [Anfang 2] ---> Custom Decryption Komponente [Ende 1] ---> Datentransformation ---> Datensenke/Persistenz [Ende 2]

 

[KitKat::new()]

Ist die Anforderung an eine E2E Verschlüsselung ohne "eigene" Komponenten in der Cloud überhaupt umsetzbar?

Wenn die Cloud auf den echten Daten arbeiten muss, eher nicht.

Möglichkeiten, die du hast:

• Daten E2EE und, falls der Inhalt der Daten eingesehen werden muss oder sie bearbeitet werden müssen, die Daten an einen on premise Dienst (oder anderen im Sinne des premisses vertrauenswürdigen Dienst) weitergeben (der ja die Daten entschlüsseln kann) und verschlüsselt wieder entgegennehmen.
• Daten homomorph E2EE (https://de.m.wikipedia.org/wiki/Homomorphe_Verschlüsselung). Dadurch kannst du in der Cloud bestimmte Operationen auf den Daten durchführen ohne sie entschlüsseln zu müssen.

 

[SaxnPaule]

@KitKat::new() also kommt tatsächlich nur das Alternativszenario in Frage, wo die Daten in der Cloud mit dem ersten Schlüssel entschlüsselt werden und dann jede Cloud Komponente den zweiten Schlüssel aus dem Key Vault zieht und dann mit den Daten machen kann was sie möchte.

 

[Murray B.]

Wobei homonorphe Verschlüsselung meiner Meinung nach eher in Richtung Schlangenöl tendiert. Dann kann man das mit der Verschlüsselung auch gleich lassen.

Aber das ist nur meine Meinung.

Falls die verarbeiteten Daten ohnehin entschlüsselt in der Cloud landen, kann ich das mit dem E2E ohnehin nicht nachvollziehen. Entweder die Cloud kriegt die Daten nie zu sehen - oder doch. Und falls doch, macht das mit der Verschlüsselung eh nicht viel Sinn.

 

[KitKat::new()]

Wobei homonorphe Verschlüsselung meiner Meinung nach eher in Richtung Schlangenöl tendiert. Dann kann man das mit der Verschlüsselung auch gleich lassen.

Aha, und wieso?

 

[Murray B.]

Aha, und wieso?

Ich verweise mal auf Fefe, der hat das gut erklärt. Zusammenfassung: je mehr Operationen auf den homonorph "verschlüsselten" Daten möglich sind, umso schwächer ist die Verschlüsselung und umso einfacher lässt sich auf die echten Daten rückschließen. Das kann zur Folge haben, dass die Verschlüsselung nicht der geforderten Stärke entspricht, die im Lastenheft steht, oder dass man nicht die Kalkulationen ausführen kann, die man gerne möchte. Summen bilden mag vielleicht noch gehen, Gruppieren nach distinkten Werten auch, aber das war es dann auch schon.

Fefe ist da etwas weniger diplomatisch, und ich neige dazu, ihm eher zu glauben als den Cloud-Verkäufern:
https://blog.fefe.de/?ts=9eb87c1e

 

[SaxnPaule]

Falls die verarbeiteten Daten ohnehin entschlüsselt in der Cloud landen, kann ich das mit dem E2E ohnehin nicht nachvollziehen. Entweder die Cloud kriegt die Daten nie zu sehen - oder doch. Und falls doch, macht das mit der Verschlüsselung eh nicht viel Sinn.

Ich denke du hast den UseCase nicht verstanden. Die Daten landen natürlich verschlüsselt in der Cloud. Nur hat jeder Service in der Cloud der darauf zugreifen soll auch den entsprechenden Schlüssel. Das Problem ist, dass die Daten bereits onPremise verschlüsselt werden sollen und dort nicht der gleiche Schlüssel verwendet werden kann wie in der Cloud, wenn ich es richtig verstanden habe (siehe Link im Eröffnungspost).

Somit muss die onPremise Verschlüsselung innerhalb der Cloud erstmal geöffnet werden um die Daten dort fachlich weiterverarbeiten zu können.

Da keine Berechnungen durchgeführt werden sollen, ist das Thema Homomorphe Verschlüsselung in diesem Kontext irrelevant. Daher brauchen wir bitte darüber in diesem Topic auch nicht weiter zu diskutieren.

 

[Murray B.]

Datentransformation

Da keine Berechnungen durchgeführt werden sollen, ist das Thema Homomorphe Verschlüsselung in diesem Kontext irrelevant.

Woraus besteht denn die gewünschte Datentransformation, wenn nicht aus (irgendeiner) algorithmischen Berechnung?

Wenn nichts berechnet werden soll, können die Daten ja 1:1 verschlüsselt in die Cloud geschoben werden und da liegen bleiben.

Ich weiß, dass ich jetzt spitzfindig klinge, aber ich verstehe gerade den konkreten Use Case noch nicht. Vielleicht wurde die Frage unpräzise gestellt, vielleicht fehlen mir noch Informationen.

 

[KitKat::new()]

Fefe ist da etwas weniger diplomatisch, und ich neige dazu, ihm eher zu glauben als den Cloud-Verkäufern:
https://blog.fefe.de/?ts=9eb87c1e

TLDR: jemand, der keine Ahnung von homomorpher Verschlüsselung hat, hatet über die Cloud...
Klassischer Fefismus.

Hast du seinen Beitrag überhaupt zu Ende gelesen?

 

[SaxnPaule]

@Murray B. Es sollen aus verschiedenen Datensätzen fachliche Objekte gebaut , welche dann letztenendes persistiert werden.

Abstraktes Beispiel: Ein Datensatz beinhaltet eine Seriennummer eines Mainboards, der nächste Datensatz eine Seriennummer einer CPU, dann noch ein paar Stammdaten dazu und weggespeichert wird dann ein Fachobjekt "Computer". Andere Daten werden einfach verworfen, weil nicht UseCase relevant.

Vielleicht hätte ich auch Aggregation an Stelle von Transformation schreiben sollen.

 

[Murray B.]

Klassischer Fefismus.

Hast du seinen Beitrag überhaupt zu Ende gelesen?

Ja: "Was ist hier das Business Model? Dass du deine Datenbank unter Tisch stehen hast, aber die Daten darin einmal verschlüsselt in die Cloud exportierst, damit die eine bestimmte Liste von Operationen darauf durchführen können, dir andere verschlüsselte Daten zurückgeben, und die entschlüsselst du dann und tust sie wieder in die Datenbank?"

Wie gesagt: ich suche gerade nach dem Use Case. Daten liegen on premise. Und sollen so verschlüsselt sein, dass der Cloud-Anbieter sie nicht erkennen kann, aber die Anwendung soll doch in der Cloud laufen und die Daten sichtbar machen. Oder habe ich das falsch verstanden?

Falls das aber der Use Case ist, dann brauche ich die Daten gar nicht erst zu verschlüsseln, denn dann sieht mein Cloud-Anbieter die ja ohnehin. Und dann bleiben nur noch zwei Möglichkeiten: ich vertraue dem Anbieter - dann kann ich auch dessen Verschlüsselung verwenden und die Daten auf dem Weg dorthin nur per Transportverschlüsselung absichern. Oder ich vertraue dem Anbieter nicht, dann sollte ich das mit der Cloud vielleicht noch mal überdenken.

 

[KitKat::new()]

Wie gesagt:

Nein das hast du zuvor gesagt:

je mehr Operationen auf den homonorph "verschlüsselten" Daten möglich sind, umso schwächer ist die Verschlüsselung und umso einfacher lässt sich auf die echten Daten rückschließen.

aber die Anwendung soll doch in der Cloud laufen und die Daten sichtbar machen.

Woher diese Einschränkung?

 

[Murray B.]

Nein das hast du zuvor gesagt:

An der Stelle hast du zwei komplett unterschiedliche Aussagen von mir verglichen, die mit der jeweils anderen nichts zu tun haben.

Woher diese Einschränkung

Ich weiß es nicht, das war eine Frage von mir. Ja, ich hätte das deutlicher als Frage formulieren sollen.

Ich versuche es also noch einmal:

Die Daten sind on Premise. Die Daten sollen dort verschlüsselt und dann in die Cloud übertragen werden. In der Cloud sollen die Daten konsolidert werden. Dann sollen sie dort auch abgespeichert werden.

Und jetzt meine Frage: was soll danach mit den Daten geschehen? Sollen die nur da liegen wie ein Backup? Oder sollen die in irgendeiner Art und Weise von einer Anwendung gelesen und angezeigt werden können? Wenn sie gelesen und angezeigt werden sollen, müsste man sich Gedanken über Filter- oder Suchfunktionen machen, es sei denn, man möchte immer die komplette Datenmenge an die Applikation schicken und dort erst entschlüsseln.

Wenn wir den genauen und vollständigen Use Case kennen, können wir vielleicht auch eine gute Antwort liefern.

 

[SaxnPaule]

Und dann bleiben nur noch zwei Möglichkeiten: ich vertraue dem Anbieter - dann kann ich auch dessen Verschlüsselung verwenden und die Daten auf dem Weg dorthin nur per Transportverschlüsselung absichern. Oder ich vertraue dem Anbieter nicht, dann sollte ich das mit der Cloud vielleicht noch mal überdenken.

Genau das ist der Punkt. In meinen Augen genügt es die Rohdaten über einen gesicherten Kanal in die Cloud zu übertragen und anschließend die dortige Verschlüsselung zu verwenden.

Manchmal ist es aber leider so, dass der Kunde es nicht verstehen will und auf seiner Anforderung wider besseren Wissens beharrt. Und da der Kunde König ist....

Die Visualisierung der persistierten Daten geschieht auch mittels eines Azure Services. Somit kennt dieser den Schlüssel auch.
Leider kann/darf ich den UseCase nicht noch genauer beschreiben.

 

[Murray B.]

Und da der Kunde König ist....

Solche Kunden hatte ich früher auch häufig. Ich war damals aber in der luxuriösen Lage, den entsprechenden Kunden dann auch absagen zu können. Das ist je nach Situation natürlich nicht ganz so einfach.

Die Visualisierung der Daten geschieht auch mittels eines Azure Services. Somit kennt dieser den Schlüssel auch.

Dann wäre für mich der Fall klar: es reicht eine Transportverschlüsselung plus die Verschlüsselung in der Cloud selbst.

Leider kann/darf ich den UseCase nicht noch genauer beschreiben.

Das obige ist meiner Meinung nach ausreichend, um eine brauchbare Antwort geben zu können. Aber meine Antwort beruht natürlich ebenfalls auf meiner persönlichen Meinung und Erfahrung

 

[SaxnPaule]

Dann wäre für mich der Fall klar: es reicht eine Transportverschlüsselung plus die Verschlüsselung in der Cloud selbst.

Ja, dass das reicht ist auch meine Meinung.
Aber eine E2E Verschlüsselung ist das meines Erachtens nicht. Und wenn der Kunde darauf besteht die Daten bereits onPremise zu verschlüsseln, muss eine Lösung gefunden werden.

Was ich jetzt mitnehme: Es bedarf zwingend einer Custom Komponente in der Cloud, die die onPremise Verschlüsselung vor der Weiterverarbeitung in der Cloud öffnet. Also die bereits im Eröffnungspost angedachte Alternative. Ist dann halt so und kostet extra.