Daten verschlüsselt ablegen in einer Datenbank

[Lambda7]

Hallo zusammen,
ich habe eine Spring Boot Applikation mit einer Datenbank. Nun möchte ich manche Daten verschlüsselt in der Datenbank ablegen (nehmen wir als Beispiel eine Telefonnummer). Wie würde man sowas heutzutage machen,
also die Ablage von sensiblen Daten in einer Datenbank? Ich dachte nun, mit Java eine Funktion zu schreiben, die mittels AES-128 die Daten symmetrisch verschlüsselt und entschlüsselt. Sozusagen eine Funktion die als Übersetzer dient.
Den Schlüssel für die Verschlüsselung würde ich erstmal in den Properties hinterlegen.
Es würde mich interessieren, ob jmd. von euch sowas schon mal gemacht hat und wenn ja wie. Vielen Dank.
Google hat soweit nur die obige Lösung ausgespuckt, also via AES verschlüsseln. Daher frage ich einmal hier.

 

[abcddcba]

Spricht was dagegen im Spring Stack zu bleiben und das Crypto Modul von Spring Security Layer zu nehmen?

https://docs.spring.io/spring-security/site/docs/3.1.x/reference/crypto.html

Wenn du eh Hibernate verwenden solltest, bietet das doch eh Encryption ueber u.a. Jasypt oder so an, oder nicht?

 

[benneq]

Den Schlüssel für die Verschlüsselung würde ich erstmal in den Properties hinterlegen.

Da kannst du auch einfach die Festplatte vom Betriebssystem verschlüsseln lassen, das erfüllt quasi denselben Zweck.
Äquivalent: "Ich würde gerne meine Dokumente sicher im Safe verwahren. Den Code schreibe ich groß und deutlich vorne auf den Safe, damit ich ihn nicht vergesse."

Erst mal solltest du dir die Frage stellen: Für wen sollen die Daten verschlüsselt werden bzw. wer soll sie nicht lesen können bzw. wer darf sie entschlüsseln.

 

[Lambda7]

@benneq
Erstmal geht es nur darum, dass jemand, der Datenbankzugriff hat, nicht alles sofort lesen kann. Es ist natürlich klar, wenn jemand auf den normalen Server Zugriff hat, er auf alles Zugriff hat. Ich gehe von einer Konstellation aus, in welcher nur der Datenbankserver gefährdet ist und der Applikationsserver sicher ist.

@abcddcba
Solche Empfehlungen habe ich sonst gesucht. Das ganze ist für ein privates Projekt und ich bin nicht so versiert mit Spring. Ich schaue mir deren Modul einmal an. Danke.

 

[abcddcba]

Nein, alles gut. Ist ja auch sinnvoll dass du nachfragst. Spring ist uebrigens auch ein riesen Klotz, das muss man einfach mal sagen. So schoen Spring Boot Starter Projekte sind, in den tiefen von Spring kann man sehr viel machen, grade fuer Einsteiger kann es einen erschlagen.

Andere hier werden aber sich auch noch bessere und konkrete Vorschlaege machen, also nicht auf den Spring Hinweis jetzt fixieren.

Wie @benneq aber schon anmerkte, so genau wie moeglich spezifizieren, und dann kann man weitersehen.

Viel Erfolg dabei!

 

[Lambda7]

Ok, im ersten Schritt möchte ich nur Lösung implementieren, damit der Inhalt der Datenbank verschlüsselt ist und man mit reinem Datenbankzugriff keinen Zugriff auf die Daten hat. Langfristig möchte ich es noch erweitern. Dann möchte ich das Deployment mit Ansible automatisieren und Passwörter, welche in der Applications.Properties abgelegt sind, mit Ansible Vault verschlüsseln. Der Schlüssel für den Vault wird dann über Extern injected. Das muss ich dann nochmal genauer sehen. Aber das ist noch Zukunftsmusik, da ich nicht soviel Zeit in mein privates Projekt investieren möchte.

 

[benneq]

Nun gut. Dann kannst du das natürlich einfach so handhaben. Im Endeffekt sind die verschlüsselten Daten ja auch nur Strings bzw. byte-Arrays. Ob du die nun via Hibernate Annotation direkt ver- und entschlüsseln lässt, oder das bei jedem Lesen / Schreiben von Hand machst, macht keinen Unterschied. Das erste ist bequemer, aber macht dich von einem externen Projekt abhängig. Und das zweite ... genau das Gegenteil.

Aber bedenke noch, dass du die Daten nicht durchsuchen kannst. Bzw. man müsste sie vorher in den RAM laden, entschlüsseln und dann auf diesen Daten suchen.

In manchen Applikationen haben wir deshalb schon so ein Datenformat verwendet:

{
  id: "1234abcd",
  fKey1: "foo",
  fKey2: "bar",
  searchableData: "x y z"
  data: ENCRYPTED_DATA
}

Also so, dass das eigentliche Objekt in "data" hinterlegt ist und alle anderen Spalten nur für Foreign Keys und sonstige Daten benutzt werden, die für Suche und Sortierung relevant sind. Kann aber natürlich trotzdem sein, dass man jetzt über die Foreign Keys und Indizes irgendwelche Daten preisgibt, die geheim bleiben sollten.

Ansonsten gibt's noch eine (für Endbenutzer) super sichere Lösung:
Das Passwort beim Login entschlüsselt einen Schlüssel mit dem sämtliche Daten dieses Benutzers verschlüsselt sind. Nach dem Login lädt man dann sämtliche Daten des Benutzers auf dessen Rechner in den RAM (z.B. in eine SQLite Datenbank). Und wenn er fertig ist, wird der gesamte Bums wieder verschlüsselt und zum Server zurück geschickt. Auf dem Server braucht's dann natürlich keine wirkliche Datenbank mehr, sondern nur noch eine Datei pro Benutzer

 

[Dalek]

@benneq
Erstmal geht es nur darum, dass jemand, der Datenbankzugriff hat, nicht alles sofort lesen kann. Es ist natürlich klar, wenn jemand auf den normalen Server Zugriff hat, er auf alles Zugriff hat. Ich gehe von einer Konstellation aus, in welcher nur der Datenbankserver gefährdet ist und der Applikationsserver sicher ist.

Jemand der Datenbankzugriff hat kann in den meisten Fällen auch einfach Zugriff auf die Anwendung selbst Zugriff erlangen. Zum Beispiel in dem man einfach in der Datenbank einen neuen Admin User für die Anwendung anlegt, und sich dann einloggt.

Man muss sich da schon sehr viele Gedanken um die Angriffsszenarien machen um mit solchen Sachen tatsächlich die Sicherheit zu erhöhen. Und fast immer ist eigentlich die Anwendung der Schwachpunkt mit der größten Angriffsfläche, ein Angreifer sollte überhaupt nicht in die Nähe der Datenbank selbst kommen ohne durch die Anwendung zu gehen. Und in der Anwendung wo die Daten gebraucht werden müssen sie auch entschlüsselt vorliegen, da bringt es also nichts.

Und natürlich kann die Datenbank mit verschlüsselten Daten nichts anfangen, d.h. du kannst nicht mehr nach diesen Inhalten suchen oder filtern. Du kannst sie nur noch so wie sie sind zurückgeben.

 

[benneq]

@Dalek Noch als Ergänzung: Normalerweise liegen all diese Server (oder Services) im "Intranet" (oder wie auch immer geartete Kubernetes Cluster). Von außen kommt man über das Gateway ausschließlich an die API der Applikation, aber es gibt keinen Weg zu den Datenbanken. An die Datenbanken kommt man ausschließlich über die Applikation.

Filtern geht in einer verschlüsselten Datenbank sogar noch halbwegs, solang man sich auf (quasi) Enums beschränkt und diese überall mit demselben Schlüssel und ohne Salt (oder anderen Entropie erhöhenden Maßnahmen) verschlüsselt wurden.

 

[Mr.Baba]

Bei AWS kannst es z.B. so haben, dass die Datenbank verschlüsselt ist, aber nicht die Einträge selber. Die Einträge verschlüsseln macht das ganze Tricky finde ich.

heroku etc. könntest du zusätzlich nur bestimmten ip bereichen oder der App oder was auch immer Zugriff auf die Datenbank gewähren.

Ob ein Key in einer Property Datei soviel sicherer ist, bezweifle ich.
Außerdem kommt es auch mal vor, dass du selbst Daten in der Datenbank ändern musst und schon hast du ein Problem.

Zu "Datenbankeinträge verschlüsseln" findest du aber auch schon sehr viel im Internet.

 

[Kanibal]

Ich habe etwas länger darüber nachgedacht und finde die Idee nicht verkehrt. Damit erschwerst Du wahrscheinlich einigermaßen zuverlässig SQL-Injections. Auch einen neuen Benutzer anlegen geht dann nicht so einfach, da der Schlüssel ja unbekannt ist.