6
Datenverschlüsselung im virtuellen Rechenzentrum in der Public Cloud
Hallo,
Wir betreiben Webapplikationen, die Dienste für Kunden bereitstellen, die schützenswerte Daten verarbeiten und speichern. Die Webapplikationen sind vorwiegend Eigenentwicklungen, die über die Jahre gewachsen sind.
Diese sollen nun als virtuelles Rechenzentrum in die Cloud verlagert werden.
Da stellt sich nun für mich erstmals die Frage, wie man schützenswerte Daten (der Kunden, aber auch unseren Source Code) da so verschlüsselt, dass sie vor eventuellem Fremdzugriff sicher sind und dass der Betrieb soweit praktikabel ist.
Die Daten sind in MS SQL und MySQL Datenbanken gespeichert, als Dokumentspeicher soll soll ein S3 Objektspeicher des Cloud-Anbieters genutzt werden, der Source Code liegt üblicherweise am Laufwerk in den Webroots, in SVN und Git.
Mit Ausnahme des S3 sollen vorerst keine Cloud-Services genutzt werden. Alles andere soll in eigenen VMs, auf Windows und Linux eingerichtet werden.
Für den Storage hätten wir die Datenverschlüsselung abgeklärt. Es geht mir jetzt um die Datenbanken, um VM-Datenträger und um die Code-Repositories.
Bei der Recherche kommt man schnell auf die Datenträger Verschlüsselung. Mit dieser wäre meiner Ansicht doch auch gleich die Verschlüsselung der Datenbanken und Repositories ausreichend abgedeckt, wenn die auf einem verschlüsselten Datenträger gespeichert sind. Aber vielleicht bedenke ich da jetzt nicht alles.
Jedoch ist da offenbar das noch typische Szenario, dass man beim Booten den Key eingeben muss, was ich mir als ungeeignet für den gedachten Betrieb in der Cloud erscheint, zumal da auch keine wirklich tolle Konsole zur Verfügung steht.
Gibt es da einen besseren Ansatz.
Ein Gedanke war da, eine eigene Key Wallet zu betreiben, bei welcher man etwa zwar erstmal beim Starten den Key eingeben müsste, die anderen VM könnten sich aber dann von da die Keys ziehen.
Der Provider bietet nichts derartiges an. Auch würde ich bei einem Provider-Service die Sinnhaftigkeit in Frage stellen.
Die Systempartion müsste meiner Meinung nicht verschlüsselt werden. Da gibt es vielleicht aber andere Ansichten.
So könnte man vielleicht die Schlüssel irgendwie doch verschlüsselt auf der Systemplatte ablegen?
Ich wäre dankbar, wenn mich jemand bei diesem Thema in die richtige Richtung lenken könnte.
VG
Wir betreiben Webapplikationen, die Dienste für Kunden bereitstellen, die schützenswerte Daten verarbeiten und speichern. Die Webapplikationen sind vorwiegend Eigenentwicklungen, die über die Jahre gewachsen sind.
Diese sollen nun als virtuelles Rechenzentrum in die Cloud verlagert werden.
Da stellt sich nun für mich erstmals die Frage, wie man schützenswerte Daten (der Kunden, aber auch unseren Source Code) da so verschlüsselt, dass sie vor eventuellem Fremdzugriff sicher sind und dass der Betrieb soweit praktikabel ist.
Die Daten sind in MS SQL und MySQL Datenbanken gespeichert, als Dokumentspeicher soll soll ein S3 Objektspeicher des Cloud-Anbieters genutzt werden, der Source Code liegt üblicherweise am Laufwerk in den Webroots, in SVN und Git.
Mit Ausnahme des S3 sollen vorerst keine Cloud-Services genutzt werden. Alles andere soll in eigenen VMs, auf Windows und Linux eingerichtet werden.
Für den Storage hätten wir die Datenverschlüsselung abgeklärt. Es geht mir jetzt um die Datenbanken, um VM-Datenträger und um die Code-Repositories.
Bei der Recherche kommt man schnell auf die Datenträger Verschlüsselung. Mit dieser wäre meiner Ansicht doch auch gleich die Verschlüsselung der Datenbanken und Repositories ausreichend abgedeckt, wenn die auf einem verschlüsselten Datenträger gespeichert sind. Aber vielleicht bedenke ich da jetzt nicht alles.
Jedoch ist da offenbar das noch typische Szenario, dass man beim Booten den Key eingeben muss, was ich mir als ungeeignet für den gedachten Betrieb in der Cloud erscheint, zumal da auch keine wirklich tolle Konsole zur Verfügung steht.
Gibt es da einen besseren Ansatz.
Ein Gedanke war da, eine eigene Key Wallet zu betreiben, bei welcher man etwa zwar erstmal beim Starten den Key eingeben müsste, die anderen VM könnten sich aber dann von da die Keys ziehen.
Der Provider bietet nichts derartiges an. Auch würde ich bei einem Provider-Service die Sinnhaftigkeit in Frage stellen.
Die Systempartion müsste meiner Meinung nicht verschlüsselt werden. Da gibt es vielleicht aber andere Ansichten.
So könnte man vielleicht die Schlüssel irgendwie doch verschlüsselt auf der Systemplatte ablegen?
Ich wäre dankbar, wenn mich jemand bei diesem Thema in die richtige Richtung lenken könnte.
VG
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 92854889592
Url: https://administrator.de/contentid/92854889592
Printed on: May 6, 2024 at 10:05 o'clock
6 Comments
Latest comment
Hallo,
muss es denn zwingend eine Public Cloud sein? Ich gehe davon aus, dass ihr es aufgrund der Anbindung auslagern wollt. Ggf. ist ja aber auch eine CoLocation mit eigener Hardware eine Variante.
Leider sagst du nichts über den eingesetzten HyperVisor.
Falls VMware eingesetzt wird, so gibt es die Lektüre hier Verschlüsselung von Virtuellen Maschinen
muss es denn zwingend eine Public Cloud sein? Ich gehe davon aus, dass ihr es aufgrund der Anbindung auslagern wollt. Ggf. ist ja aber auch eine CoLocation mit eigener Hardware eine Variante.
Leider sagst du nichts über den eingesetzten HyperVisor.
Falls VMware eingesetzt wird, so gibt es die Lektüre hier Verschlüsselung von Virtuellen Maschinen
Hallo,
die Motivation für die Cloud ist vordergründig die Skalierbarkeit. Auch sollten später eventuell SaaS des Providers genutzt werden. Ja, das geht zwar auch, wenn man die VMs on-premises betreibt, aber dann ist ja ohnehin ein Teil schon in der Cloud.
Und jetzt ist gerade der Zeitpunkt, wo die Hardware bald erneuert werden sollte, wenn wir es weiter selbst betreiben möchten. Ist aktuell ein Housing-Konzept. Das sollte aber nicht weitergeführt werden. Es müsste also auf jeden Fall woanders hin gewechselt werden.
Die Cloud wäre EXOSCALE. Die ist vollkommen abstrahiert wie Azure oder andere große Anbieter.
Der darunterliegende Hypervisor ist KVM, aber auf dessen Konfiguration können wir keinen Einfluss nehmen.
die Motivation für die Cloud ist vordergründig die Skalierbarkeit. Auch sollten später eventuell SaaS des Providers genutzt werden. Ja, das geht zwar auch, wenn man die VMs on-premises betreibt, aber dann ist ja ohnehin ein Teil schon in der Cloud.
Und jetzt ist gerade der Zeitpunkt, wo die Hardware bald erneuert werden sollte, wenn wir es weiter selbst betreiben möchten. Ist aktuell ein Housing-Konzept. Das sollte aber nicht weitergeführt werden. Es müsste also auf jeden Fall woanders hin gewechselt werden.
Die Cloud wäre EXOSCALE. Die ist vollkommen abstrahiert wie Azure oder andere große Anbieter.
Der darunterliegende Hypervisor ist KVM, aber auf dessen Konfiguration können wir keinen Einfluss nehmen.
Hallo,
die Verschlüsselung kann natürlich nicht dazu dienen, Daten vor dem Zugriff des Cloudproviders zu schützen (es geht um die Nutzung von dessen Sicherheitsorganisation/-segmentierung und kryptografische Datenentfernung).
Erwartet wird in dem Zusammenhang entweder Datenträgerverschlüsselung oder Datenbankverschlüsselung/TDE (oder beides). Ein Schritt weiter wäre anwendungsbasierte Verschlüsselung, die dann dem SaaS-Kunden BYOK etc. erlaubt - mit entsprechendem Entwicklungsaufwand.
Datenträgerverschlüsselung muss auf alle Volumes einer VM angewandt werden. Ich würde auch darüber nachdenken, sie auf der gesamten Infrastruktur zu nutzen. Bei den Anbietern aus dem kapitalistischen Ausland hast du vernünftige Schlüsselverwaltungsinstrumente wie Azure Key Vaults. Man kann im schlechtesten Fall auch mit Schlüsseleingabe über VNC-Konsole und ansonsten automatisierten temporären Boot-Schlüsseln leben, aber ein Restrisiko (für die Verfügbarkeit) bleibt.
Grüße
Richard
die Verschlüsselung kann natürlich nicht dazu dienen, Daten vor dem Zugriff des Cloudproviders zu schützen (es geht um die Nutzung von dessen Sicherheitsorganisation/-segmentierung und kryptografische Datenentfernung).
Erwartet wird in dem Zusammenhang entweder Datenträgerverschlüsselung oder Datenbankverschlüsselung/TDE (oder beides). Ein Schritt weiter wäre anwendungsbasierte Verschlüsselung, die dann dem SaaS-Kunden BYOK etc. erlaubt - mit entsprechendem Entwicklungsaufwand.
Datenträgerverschlüsselung muss auf alle Volumes einer VM angewandt werden. Ich würde auch darüber nachdenken, sie auf der gesamten Infrastruktur zu nutzen. Bei den Anbietern aus dem kapitalistischen Ausland hast du vernünftige Schlüsselverwaltungsinstrumente wie Azure Key Vaults. Man kann im schlechtesten Fall auch mit Schlüsseleingabe über VNC-Konsole und ansonsten automatisierten temporären Boot-Schlüsseln leben, aber ein Restrisiko (für die Verfügbarkeit) bleibt.
Grüße
Richard
Jedoch ist da offenbar das noch typische Szenario, dass man beim Booten den Key eingeben muss, was ich mir als ungeeignet für den gedachten Betrieb in der Cloud erscheint, zumal da auch keine wirklich tolle Konsole zur Verfügung steht.
Clevis in Verbindung mit einem Tang Server ermöglicht eine automatische und sichere Entsperrung von Datenträgern beim Boot übers Netzwerk.
Configuring automated unlocking of encrypted volumes by using policy-based decryption
Gruß schrick
Moin,
was du suchst ist "confidential computing" - das gibt es bei einigen cloud-providern schon (bspw. AWS https://aws.amazon.com/de/blogs/security/confidential-computing-an-aws-p ..).
Alles andere erhöht nur ein wenig die Sicherheit, mindestens aber der cloud-provider hat weiterhin Zugriff auf die Daten, wenn er möchte. Anhand deiner Formulierung lässt sich aber erraten, dass selbst das schon ein Fortschritt für euch wäre.
Bevor ihr Datenbanken selbst betreibt macht es Sinn einmal zu prüfen, ob euer ORM denn nicht einfach die Daten verschlüsseln kann, bevor er sie in die DB schreibt - dann die DB as service holen und die Sorgen sind verkauft. Euer Framework (Spring?) wird ja sowieso schon genutzt um verschlüsselt auf S3-kompatiblem Speicher zu speichern, dann wäre der nächste Schritt nur konsequent. Gepaart mit confidential VMs hat dann - erstmal - niemand außer euch Zugriff auf die Daten.
Ein key-wallet (aka secrets manager, aka vault) verschiebt die credentials nur woanders hin und du speicherst halt credentials, um credentials zu holen, auf deinen VMs. Ja, macht man heute so, ist aber auch nur eine weitere Hürde für potentielle Angreifer.
Last but not least - wenn Container interessant sind dann wäre confidential kubernetes sicherlich sehr spannend - da werden dann auch gleich die volumes verschlüsselt; das setzen wir bei einem hochkritischen Kundenprojekt (öffentliche Hand) ein (as service in der cloud).
Viele Grüße, Flo
was du suchst ist "confidential computing" - das gibt es bei einigen cloud-providern schon (bspw. AWS https://aws.amazon.com/de/blogs/security/confidential-computing-an-aws-p ..).
Alles andere erhöht nur ein wenig die Sicherheit, mindestens aber der cloud-provider hat weiterhin Zugriff auf die Daten, wenn er möchte. Anhand deiner Formulierung lässt sich aber erraten, dass selbst das schon ein Fortschritt für euch wäre.
Bevor ihr Datenbanken selbst betreibt macht es Sinn einmal zu prüfen, ob euer ORM denn nicht einfach die Daten verschlüsseln kann, bevor er sie in die DB schreibt - dann die DB as service holen und die Sorgen sind verkauft. Euer Framework (Spring?) wird ja sowieso schon genutzt um verschlüsselt auf S3-kompatiblem Speicher zu speichern, dann wäre der nächste Schritt nur konsequent. Gepaart mit confidential VMs hat dann - erstmal - niemand außer euch Zugriff auf die Daten.
Ein key-wallet (aka secrets manager, aka vault) verschiebt die credentials nur woanders hin und du speicherst halt credentials, um credentials zu holen, auf deinen VMs. Ja, macht man heute so, ist aber auch nur eine weitere Hürde für potentielle Angreifer.
Last but not least - wenn Container interessant sind dann wäre confidential kubernetes sicherlich sehr spannend - da werden dann auch gleich die volumes verschlüsselt; das setzen wir bei einem hochkritischen Kundenprojekt (öffentliche Hand) ein (as service in der cloud).
Viele Grüße, Flo
Hallo,
danke für die Antworten.
Interessant, das werde ich mir genauer ansehen.
Danke für den Hinweis.
Nein, ich hätte nicht mal gedacht, dass es so etwas geben würde.
Wir suchen erst mal eine "Data at Rest" Verschlüsselung.
Und es würde das Gewissen beruhigen.
Dem Provider müssen wir wohl soweit vertrauen. Aber die Daten sollen auch weitgehend sicher vor Angreifern sein, die sich über andere Wege Zugriff zur Cloud verschaffen, wie es schon bspw. bei MS letztes Jahr passierte.
Inwiefern ein Angreifer aber Daten von einem virtuellen Datenträger abziehen könnte, vermag ich gar nicht zu beurteilen.
.Net
MS SQL bietet der Provider aktuell noch nicht as a Service. Da müssten wir selbst eine Instanz betreiben.
Ich habe gesehen, dass man bei MS SQL die Datenbanken im Server verschlüsseln kann. Wenn ich das richtig verstanden habe, bewirkt das die Verschlüsselung am Datenträger wie auch das von Backups.
Es müsste aber jede Datenbank einzeln verschlüsselt werden, was bei hunderten Datenbanken wohl aufwendig wäre. Da sind vielleicht andere Methoden sinnvoller.
Und für MySQL habe ich nichts dergleichen gefunden.
Ob es da auch eine relativ sichere Methode gibt, wollte ich herausfinden.
Aktuell nicht. Das ist ein Thema für die Zukunft.
Viele Grüße
danke für die Antworten.
Zitat von @12764050420:
Clevis in Verbindung mit einem Tang Server ermöglicht eine automatische und sichere Entsperrung von Datenträgern beim Boot übers Netzwerk.
Configuring automated unlocking of encrypted volumes by using policy-based decryption
Clevis in Verbindung mit einem Tang Server ermöglicht eine automatische und sichere Entsperrung von Datenträgern beim Boot übers Netzwerk.
Configuring automated unlocking of encrypted volumes by using policy-based decryption
Interessant, das werde ich mir genauer ansehen.
Danke für den Hinweis.
Zitat von @flo72it:
was du suchst ist "confidential computing" - das gibt es bei einigen cloud-providern schon (bspw. AWS https://aws.amazon.com/de/blogs/security/confidential-computing-an-aws-p ..).
was du suchst ist "confidential computing" - das gibt es bei einigen cloud-providern schon (bspw. AWS https://aws.amazon.com/de/blogs/security/confidential-computing-an-aws-p ..).
Nein, ich hätte nicht mal gedacht, dass es so etwas geben würde.
Wir suchen erst mal eine "Data at Rest" Verschlüsselung.
Alles andere erhöht nur ein wenig die Sicherheit, mindestens aber der cloud-provider hat weiterhin Zugriff auf die Daten, wenn er möchte.
Und es würde das Gewissen beruhigen.
Dem Provider müssen wir wohl soweit vertrauen. Aber die Daten sollen auch weitgehend sicher vor Angreifern sein, die sich über andere Wege Zugriff zur Cloud verschaffen, wie es schon bspw. bei MS letztes Jahr passierte.
Inwiefern ein Angreifer aber Daten von einem virtuellen Datenträger abziehen könnte, vermag ich gar nicht zu beurteilen.
Bevor ihr Datenbanken selbst betreibt macht es Sinn einmal zu prüfen, ob euer ORM denn nicht einfach die Daten verschlüsseln kann, bevor er sie in die DB schreibt - dann die DB as service holen und die Sorgen sind verkauft. Euer Framework (Spring?)
.Net
MS SQL bietet der Provider aktuell noch nicht as a Service. Da müssten wir selbst eine Instanz betreiben.
Ich habe gesehen, dass man bei MS SQL die Datenbanken im Server verschlüsseln kann. Wenn ich das richtig verstanden habe, bewirkt das die Verschlüsselung am Datenträger wie auch das von Backups.
Es müsste aber jede Datenbank einzeln verschlüsselt werden, was bei hunderten Datenbanken wohl aufwendig wäre. Da sind vielleicht andere Methoden sinnvoller.
Und für MySQL habe ich nichts dergleichen gefunden.
Ein key-wallet (aka secrets manager, aka vault) verschiebt die credentials nur woanders hin und du speicherst halt credentials, um credentials zu holen, auf deinen VMs. Ja, macht man heute so, ist aber auch nur eine weitere Hürde für potentielle Angreifer.
Ob es da auch eine relativ sichere Methode gibt, wollte ich herausfinden.
Last but not least - wenn Container interessant sind dann wäre confidential kubernetes sicherlich sehr spannend
Aktuell nicht. Das ist ein Thema für die Zukunft.
Viele Grüße
