6
S3 Objektspeicher mit Datenverschlüsselung einbinden
Hallo,
ich suche nach einer geeigneten Möglichkeit, einen S3 Objektspeicher mit Datenverschlüsselung im Betriebssystem einzubinden.
Die Herausforderung:
Wir betreiben Webapplikationen, die auch ein Dokumentmanagement bereitstellen.
Diese sollen nun in die Cloud verlagert werden und als Speicher für die DM-Daten soll ein S3 Objektspeicher des Cloud-Anbieters genutzt werden.
Der Cloud-Anbieter ist zwar ein europäischer und das Rechenzentrum ist ebenfalls im Inland beheimatet, dennoch sollen oder müssen die abgelegten Daten verschlüsselt werden.
Hier dachte ich an eine clientseitige Verschlüsselung, also auf unseren Servern (VMs), so dass der Provider mit dem Schlüssel nichts zu tun hat.
Meine Frage ist jetzt, wie ich den Datenspeicher im Betriebssystem einbinde, damit Daten, die darauf gespeichert werden, automatisch verschlüsselt und Daten, die gelesen werden, automatisch entschlüsselt werden.
Die Betriebssysteme sind Linux und Windows, jedoch verwenden beide unterschiedliche Daten. Es können also unterschiedliche Verschlüsselungssystem zum Einsatz kommen.
Ich stelle mir vor, dass das soweit transparent ablaufen sollte, so dass ich im Dateibrowser des Betriebssystems die Daten ganz normal sehen und verwenden kann, das ist aber nicht Bedingung. Jedoch sollten sie für die Webapplikationen transparent vorliegen.
Hat hier jemand Erfahrung damit oder kann jemand Tipps für die richtigen Werkzeuge geben?
Ich weiß, dass es für beide Systeme Verschlüsselungen für Volumes gibt, habe diese bislang jedoch nicht verwendet und weiß nicht, ob sich diese auch für einen S3 Objektspeicher verwenden lassen.
Grüße
ich suche nach einer geeigneten Möglichkeit, einen S3 Objektspeicher mit Datenverschlüsselung im Betriebssystem einzubinden.
Die Herausforderung:
Wir betreiben Webapplikationen, die auch ein Dokumentmanagement bereitstellen.
Diese sollen nun in die Cloud verlagert werden und als Speicher für die DM-Daten soll ein S3 Objektspeicher des Cloud-Anbieters genutzt werden.
Der Cloud-Anbieter ist zwar ein europäischer und das Rechenzentrum ist ebenfalls im Inland beheimatet, dennoch sollen oder müssen die abgelegten Daten verschlüsselt werden.
Hier dachte ich an eine clientseitige Verschlüsselung, also auf unseren Servern (VMs), so dass der Provider mit dem Schlüssel nichts zu tun hat.
Meine Frage ist jetzt, wie ich den Datenspeicher im Betriebssystem einbinde, damit Daten, die darauf gespeichert werden, automatisch verschlüsselt und Daten, die gelesen werden, automatisch entschlüsselt werden.
Die Betriebssysteme sind Linux und Windows, jedoch verwenden beide unterschiedliche Daten. Es können also unterschiedliche Verschlüsselungssystem zum Einsatz kommen.
Ich stelle mir vor, dass das soweit transparent ablaufen sollte, so dass ich im Dateibrowser des Betriebssystems die Daten ganz normal sehen und verwenden kann, das ist aber nicht Bedingung. Jedoch sollten sie für die Webapplikationen transparent vorliegen.
Hat hier jemand Erfahrung damit oder kann jemand Tipps für die richtigen Werkzeuge geben?
Ich weiß, dass es für beide Systeme Verschlüsselungen für Volumes gibt, habe diese bislang jedoch nicht verwendet und weiß nicht, ob sich diese auch für einen S3 Objektspeicher verwenden lassen.
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 43296415885
Url: https://administrator.de/contentid/43296415885
Ausgedruckt am: 21.11.2024 um 16:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
Blob-Storage sollte man meines Erachtens auf Anwendungsebene implementieren. Zur Verschlüsselung siehe dann z.B. "Amazon S3 Encryption Client".
Virtuelle Dateisysteme, fuse-Treiber etc. werden nicht nur von Anfang an unnötige Performance-Einbußen bedeuten, sondern machen ein horizontales Skalieren der Anwendung praktisch unmöglich.
Grüße
Richard
Blob-Storage sollte man meines Erachtens auf Anwendungsebene implementieren. Zur Verschlüsselung siehe dann z.B. "Amazon S3 Encryption Client".
Virtuelle Dateisysteme, fuse-Treiber etc. werden nicht nur von Anfang an unnötige Performance-Einbußen bedeuten, sondern machen ein horizontales Skalieren der Anwendung praktisch unmöglich.
Grüße
Richard
Moin,
JuiceFS (https://juicefs.com/) ist ggf. das was du suchst. Die Performance ist technologiebedingt okay, erwarte hier halt keine Wunder.
Viele Grüße, Flo
JuiceFS (https://juicefs.com/) ist ggf. das was du suchst. Die Performance ist technologiebedingt okay, erwarte hier halt keine Wunder.
Viele Grüße, Flo
Hallo,
schönen Dank mal für die Antworten.
Was ich nicht erwähnt hatte, neben der Anwendung soll auch noch ein Elastic Search über den Datenspeicher laufen und die Files indizieren. Das könnte ggf. doch höhere Ansprüche an die Performance bedeuten.
Die Applikation selbst speichert die Dokumente einmal ab. Abgerufen werden sie dann nur gelegentlich, erneuert äußerst selten bis gar nicht.
Die eine Anwendung ist Nextcloud, also PHP, die ja eine Verschlüsselung implementiert hätte. Allerdings weiß ich nicht, ob ich dieser trauen kann. Die andere Anwendung ist eine Eigenentwicklung auf ASP.Net Basis.
Danke. Ich werde mir das mal ansehen.
Grüße
schönen Dank mal für die Antworten.
Was ich nicht erwähnt hatte, neben der Anwendung soll auch noch ein Elastic Search über den Datenspeicher laufen und die Files indizieren. Das könnte ggf. doch höhere Ansprüche an die Performance bedeuten.
Die Applikation selbst speichert die Dokumente einmal ab. Abgerufen werden sie dann nur gelegentlich, erneuert äußerst selten bis gar nicht.
Die eine Anwendung ist Nextcloud, also PHP, die ja eine Verschlüsselung implementiert hätte. Allerdings weiß ich nicht, ob ich dieser trauen kann. Die andere Anwendung ist eine Eigenentwicklung auf ASP.Net Basis.
JuiceFS (https://juicefs.com/) ist ggf. das was du suchst.
Danke. Ich werde mir das mal ansehen.
Grüße
Ahoi,
wenn du verschiedene Applikationen einsetzt und einen object store dann müssen entweder alle Applikationen die Ver-/Entschlüsselung können oder du setzt ein Dateisystem ein (wie bspw. JuiceFS), welches den Job übernimmt.
Was du da vorhast klingt nicht besonders sinnvoll - das würde ich nochmal überdenken.
Viele Grüße, Flo
wenn du verschiedene Applikationen einsetzt und einen object store dann müssen entweder alle Applikationen die Ver-/Entschlüsselung können oder du setzt ein Dateisystem ein (wie bspw. JuiceFS), welches den Job übernimmt.
Was du da vorhast klingt nicht besonders sinnvoll - das würde ich nochmal überdenken.
Viele Grüße, Flo
Hi!
So hatte ich mir die schöne neue Object Storage Welt vorgestellt.
Ich habe es aber infolge eurer Antworten und weiterer Recherchen nochmals überdacht. Das hier war ja erstmal eine Anfrage und Teil meiner Recherche, wie man so etwas anbindet.
Auch andere gefundene Artikel zum Thema liefen darauf hinaus, dass die Anwendungen selbst den Storage ansprechen, die Files verwalten und ver- und entschlüsseln sollten.
Es geht hier um zwei Speicher:
A: Daten werden von eigenentwickelter ASP.Net Anwendung genutzt. Aktuell gut 500 k Files, 600 GB
B: Daten werden von Nextcloud genutzt. Elastic Search ist in Nextlcoud eingebunden. Aktuell 0 Files
Für A möchte ich es mit JuiceFS versuchen. Der Storage sollte in Zukunft eher runter skaliert werden.
Funktioniert das nicht in brauchbarer Weise, müssen unsere Entwickler eben Hand anlegen und den Storage direkt einbinden.
Für B soll der Storage direkt in Nextcloud eingebunden werden. Auch die Verschlüsselung soll in Nextcloud passieren.
Elastic Search läuft auch über Nextcloud. Daher hoffe ich, dass das mit der Verschlüsselung klappt.
Das möchte ich als Nächstes mal einrichten und testen.
VG
Was du da vorhast klingt nicht besonders sinnvoll - das würde ich nochmal überdenken.
So hatte ich mir die schöne neue Object Storage Welt vorgestellt.
Ich habe es aber infolge eurer Antworten und weiterer Recherchen nochmals überdacht. Das hier war ja erstmal eine Anfrage und Teil meiner Recherche, wie man so etwas anbindet.
Auch andere gefundene Artikel zum Thema liefen darauf hinaus, dass die Anwendungen selbst den Storage ansprechen, die Files verwalten und ver- und entschlüsseln sollten.
Es geht hier um zwei Speicher:
A: Daten werden von eigenentwickelter ASP.Net Anwendung genutzt. Aktuell gut 500 k Files, 600 GB
B: Daten werden von Nextcloud genutzt. Elastic Search ist in Nextlcoud eingebunden. Aktuell 0 Files
Für A möchte ich es mit JuiceFS versuchen. Der Storage sollte in Zukunft eher runter skaliert werden.
Funktioniert das nicht in brauchbarer Weise, müssen unsere Entwickler eben Hand anlegen und den Storage direkt einbinden.
Für B soll der Storage direkt in Nextcloud eingebunden werden. Auch die Verschlüsselung soll in Nextcloud passieren.
Elastic Search läuft auch über Nextcloud. Daher hoffe ich, dass das mit der Verschlüsselung klappt.
Das möchte ich als Nächstes mal einrichten und testen.
VG
Hallo,
ich habe mittlerweile einiges getestet und für uns ein Lösung gefunden.
Ja, ich gebe euch absolut recht, die Anbindung des Storages sollte besser durch die Applikation erledigt werden und ebenso die Verschlüsselung. Das haben auch weiterer Recherchen untermauert.
Das würde allerdings erfordern, dass diese Funktionen in unsere Applikation implementiert werden, und das stößt bei unserem technischen Leiter auf taube Ohren. Dieses Modul ist ein Auslaufmodell, in das man nicht mehr viel investieren möcht und die Entwickler haben keine Zeit dafür. Darüber brauchen wir nicht weiter zu diskutieren.
In die Cloud sollen die Daten aber dennoch. Also braucht es, wie eingangs erwähnt, eine transparente Anbindung des S3 Speichers.
Mit JuiceFS war ich auf Windows leider absolut nicht erfolgreich. Das lief in den Tests mit ein paar hundert oder tausend Dateien noch brauchbar, mit 700k, die wir aktuell mit diesem System verwalten, aber überhaupt nicht.
Keine Ahnung, warum. Ich hatte es auf 3 Windows Maschinen (2016 u. 2022) getestet. CPU und RAM hatte die genug, das wurde während der Tests auch nicht knapp.
Dabei soll erwähnt sein, dass wir das Filesystem gar nicht durchsuchen müssen. Jedes File, das auf dem Speicher abgelegt ist, hat einen eindeutigen Namen und dieser ist mit der Dateigröße in der Applikations-Datenbank abgelegt.
Zugriffe auf Files erfolgen also ganz gezielt mit dem absoluten Pfad, aber auch das war mit JuiceFS unmöglich.
JuiceFS auf einen Laufwerkbuchstaben gemountet ging oft noch ein dir auf ein File in der Commandline mit Erfolg, ein copy endete aber mit einem IO-Fehler, oder es tat sich stundenlang gar nichts. Gleiches gilt für Kopieren im Explorer.
JuiceFS via WebDAV bereitgestellt, ließ zwar einen Lesezugriff zu, aber keinen Schreibzugriff.
Ich bin sämtliche Optionen der Kommandos mehrmals durchgegangen und habe alle relevanten ausprobiert, aber ohne Erfolg.
Auch die Suche nach den Phänomenen im Web blieb ergebnislos und hinterließ den Eindruck, als ob niemand anderer JuiceFS auf Windows verwenden würde.
Auf Linux läuft es jedoch einwandfrei mit demselben Datenspeicher gefüllt mit denselben Daten.
Mein Workaround wäre dann eben, mit JuiceFS auf Linux den S3 Storage anzubinden und via WebDAV bereit zu stellen, was ich auch getestet hatte. Damit ließen auch sich alle nötigen Operation problemlos ausführen. Aber der Umstand, dass so die Applikation auf einen zusätzlichen Server angewiesen wäre, gefällt mir nicht so ganz.
Auf der Suche nach eine Lösung, um Backups verschlüsselt auf einem S3 Speicher abzulegen, habe ich mich dann mit rclone beschäftigt, das ich auch private auf Linux schon längere Zeit nutze, um Files verschlüsselt auf ein WebDAV zu kopieren.
rclone bietet nämlich auch die Möglichkeiten, eine S3 Storage als Speicher zu verwenden und kann diesen auf unterschiedliche Arten bereitstellen. Es kommt auch aus der Linux-Welt und benötigt ebenso FUSE, ist aber auch für Windows (mit WinFsp) verfügbar.
So habe ich das Mounting damit in Windows getestet, und es erfüllt die Aufgabe ausgezeichnet.
Einzig beim ersten Zugriff auf eine Verzeichnis dauert es lange, bis was passiert. Hier muss erstmal der Verzeichnisinhalt in den Speicher geladen werden. Dann ist es aber ganz normal für unsere Zwecke nutzbar.
Wie gesagt, wir machen keine Scans im Filesystem. Wir kennen die absoluten Pfade der gespeicherten Files und neue geschriebene bekommen einen neuen, eindeutigen Namen.
Das Cachen der Dateinamen (u. -größe) mache ich automatisiert nach dem Mounten, indem ich in jedem Verzeichnis (es sind nur 2) ein dir auf eine Datei mache. Ob der Name existiert oder nicht, spielt dabei keine Rolle. Das Einlesen das gesamten Verzeichnisses wird damit in jedem Fall ausgelöst. Datei-Änderungs-, Erstellungs- oder Zugriffszeiten werden nicht erfasst, weil in rclone durch Parameter abgeschaltet. Diese Daten, die wir ohnehin nicht benötigen, aus dem Speicher zu holen, würde erheblich mehr Zeit in Anspruch nehmen.
Die Cachedauer ist begrenzt, aber konfigurierbar. Um den Zähler zurückzusetzen, wiederhole ich den o.g. Dateizugriff einmal täglich.
Hoch zu ladende Files werden lokal gecacht. Somit wird die Applikation durch anstehende Uploads nicht gebremst. Auch dazu gibt es mehrere Optionen für eine Feineinstellung.
Seit ein paar Tagen haben wir den Storage mit rclone nun produktiv im Einsatz, bislang völlig problemlos.
Grüße
ich habe mittlerweile einiges getestet und für uns ein Lösung gefunden.
Ja, ich gebe euch absolut recht, die Anbindung des Storages sollte besser durch die Applikation erledigt werden und ebenso die Verschlüsselung. Das haben auch weiterer Recherchen untermauert.
Das würde allerdings erfordern, dass diese Funktionen in unsere Applikation implementiert werden, und das stößt bei unserem technischen Leiter auf taube Ohren. Dieses Modul ist ein Auslaufmodell, in das man nicht mehr viel investieren möcht und die Entwickler haben keine Zeit dafür. Darüber brauchen wir nicht weiter zu diskutieren.
In die Cloud sollen die Daten aber dennoch. Also braucht es, wie eingangs erwähnt, eine transparente Anbindung des S3 Speichers.
Mit JuiceFS war ich auf Windows leider absolut nicht erfolgreich. Das lief in den Tests mit ein paar hundert oder tausend Dateien noch brauchbar, mit 700k, die wir aktuell mit diesem System verwalten, aber überhaupt nicht.
Keine Ahnung, warum. Ich hatte es auf 3 Windows Maschinen (2016 u. 2022) getestet. CPU und RAM hatte die genug, das wurde während der Tests auch nicht knapp.
Dabei soll erwähnt sein, dass wir das Filesystem gar nicht durchsuchen müssen. Jedes File, das auf dem Speicher abgelegt ist, hat einen eindeutigen Namen und dieser ist mit der Dateigröße in der Applikations-Datenbank abgelegt.
Zugriffe auf Files erfolgen also ganz gezielt mit dem absoluten Pfad, aber auch das war mit JuiceFS unmöglich.
JuiceFS auf einen Laufwerkbuchstaben gemountet ging oft noch ein dir auf ein File in der Commandline mit Erfolg, ein copy endete aber mit einem IO-Fehler, oder es tat sich stundenlang gar nichts. Gleiches gilt für Kopieren im Explorer.
JuiceFS via WebDAV bereitgestellt, ließ zwar einen Lesezugriff zu, aber keinen Schreibzugriff.
Ich bin sämtliche Optionen der Kommandos mehrmals durchgegangen und habe alle relevanten ausprobiert, aber ohne Erfolg.
Auch die Suche nach den Phänomenen im Web blieb ergebnislos und hinterließ den Eindruck, als ob niemand anderer JuiceFS auf Windows verwenden würde.
Auf Linux läuft es jedoch einwandfrei mit demselben Datenspeicher gefüllt mit denselben Daten.
Mein Workaround wäre dann eben, mit JuiceFS auf Linux den S3 Storage anzubinden und via WebDAV bereit zu stellen, was ich auch getestet hatte. Damit ließen auch sich alle nötigen Operation problemlos ausführen. Aber der Umstand, dass so die Applikation auf einen zusätzlichen Server angewiesen wäre, gefällt mir nicht so ganz.
Auf der Suche nach eine Lösung, um Backups verschlüsselt auf einem S3 Speicher abzulegen, habe ich mich dann mit rclone beschäftigt, das ich auch private auf Linux schon längere Zeit nutze, um Files verschlüsselt auf ein WebDAV zu kopieren.
rclone bietet nämlich auch die Möglichkeiten, eine S3 Storage als Speicher zu verwenden und kann diesen auf unterschiedliche Arten bereitstellen. Es kommt auch aus der Linux-Welt und benötigt ebenso FUSE, ist aber auch für Windows (mit WinFsp) verfügbar.
So habe ich das Mounting damit in Windows getestet, und es erfüllt die Aufgabe ausgezeichnet.
Einzig beim ersten Zugriff auf eine Verzeichnis dauert es lange, bis was passiert. Hier muss erstmal der Verzeichnisinhalt in den Speicher geladen werden. Dann ist es aber ganz normal für unsere Zwecke nutzbar.
Wie gesagt, wir machen keine Scans im Filesystem. Wir kennen die absoluten Pfade der gespeicherten Files und neue geschriebene bekommen einen neuen, eindeutigen Namen.
Das Cachen der Dateinamen (u. -größe) mache ich automatisiert nach dem Mounten, indem ich in jedem Verzeichnis (es sind nur 2) ein dir auf eine Datei mache. Ob der Name existiert oder nicht, spielt dabei keine Rolle. Das Einlesen das gesamten Verzeichnisses wird damit in jedem Fall ausgelöst. Datei-Änderungs-, Erstellungs- oder Zugriffszeiten werden nicht erfasst, weil in rclone durch Parameter abgeschaltet. Diese Daten, die wir ohnehin nicht benötigen, aus dem Speicher zu holen, würde erheblich mehr Zeit in Anspruch nehmen.
Die Cachedauer ist begrenzt, aber konfigurierbar. Um den Zähler zurückzusetzen, wiederhole ich den o.g. Dateizugriff einmal täglich.
Hoch zu ladende Files werden lokal gecacht. Somit wird die Applikation durch anstehende Uploads nicht gebremst. Auch dazu gibt es mehrere Optionen für eine Feineinstellung.
Seit ein paar Tagen haben wir den Storage mit rclone nun produktiv im Einsatz, bislang völlig problemlos.
Grüße
