Hallo,
ich habe ein paar Verständnisfragen zum Thema Datenbankverschlüsselung.
Soweit ich das verstanden habe unterscheidet man erstmal zwischen data-at-rest und data-in-transit. Darauf aufbauend gibt es verschiedene Ansätze die Daten in der Datenbank zu verschlüsseln, welche ein unterschiedliches Maß an Sicherheit mit sich bringen.
Bei der Application Layer Encryption (ALE) werden die Werte ja verschlüsselt in die Datenbank abgelegt und auch derart hin und her geschickt, falls beispielsweise eine Django-Applikation über den ORM etwas abfragt. Dadurch wären die Daten im liegenden und bewegendem Zustand sicher.
1) Wie läuft das denn dann mit dem Indexing? Funktioniert das denn dann überhaupt noch?
2) Wo wird der symmetrische Schlüssel abgelegt? Wenn man den in einem HSM ablegt, dann müsste Django den ja bei jedem Query erst abfragen. Performance?
3) Was passiert, wenn man beispielsweise das Passwort des Users mit in die Ver- und Entschlüsselung einbezogen wird und der User das dann vergisst? Sind die Daten dann verloren?
4) Was ist, wenn ich mit einem SQL-Client auf die Datenbank zugreifen möchte? Können SQL-Clients auch dann ein HSM nach einem Schlüssel fragen?
Anders ist es ja bei einer TDE, oder? Da wird ja eine Funktion vom DBMS genutzt, die die Daten nur dann verschlüsselt, wenn sie ruhig auf der Platte liegen. Authorisierte Apps oder SQL-User könnten die Daten unverschlüsselt einsehen.
5) Was kauft man sich da eigentlich für Sicherheit ein? Eigentlich nur die, dass wenn die DB eingetütet und mitgenommen wird, dass der Böse die Daten nicht lesen kann, oder?
6) Was ist genau der Unterschied zwischen TDE und Column-level encryption? Ist das eine nur spezifischer als das andere?
Generell:
7) Was sind denn so best practise für eine Datenbankverschlüsselung im freien Feld?
LG und Danke
Datenbank verschlüsseln
-
naheliegend
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Normalerweise nutzt man full disk encryption (at-rest) und TLS (in-transit). Ersteres ist interessant für Fälle wie z.B. dass die Festplatte nicht richtig entsorgt (lies: zerstört) werden, Festplatten geklaut werden o.ä.
TDE wird von einigen Datenbanken gar nicht unterstützt und ich würde mal bezweifeln dass es sinnvoll ist wenn man FDE nutzt. Bei TDE verschlüsselt bzw. entschlüsselt die Datenbank, alle Daten die auf die Festplatte geschrieben werden. Column-level encryption heisst nichts anderes als dass die Werte in einer Spalte verschlüsselt sind, hier ist die Datenbank möglicherweise gar nicht involviert.
Informationen bei denen ALE sinnvoll wäre möchtest du nicht normalerweise gar nicht verarbeiten. Dies wäre z.B. bei Kreditkarten der Fall und da verwendet man in der Regel einen Dienstleister wie PayPal, Stripe etc. um dies auszulagern. Da gehört dann nämlich noch einiges mehr hinzu als nur die Daten zu verschlüsseln und da gibt es auch Vorgaben wie genau dies zu tun ist. Das betrifft meines Wissens auch einer deiner Fragen:
Indexing geht natürlich nicht mit ALE. Performance ist natürlich auch nicht ideal wobei den Schlüssel für jeden Query abzufragen weniger auf die Performance schlagen dürfte als die Ver-/Entschlüsselung. Wie genau es sich mit einem SQL Client hier verhält lässt sich nicht pauschal sagen, dass hängt von der Datenbank ab, ob die überhaupt solche Funktionalität anbietet (wahrscheinlich nicht) und ob man sie nutzt.
TDE wird von einigen Datenbanken gar nicht unterstützt und ich würde mal bezweifeln dass es sinnvoll ist wenn man FDE nutzt. Bei TDE verschlüsselt bzw. entschlüsselt die Datenbank, alle Daten die auf die Festplatte geschrieben werden. Column-level encryption heisst nichts anderes als dass die Werte in einer Spalte verschlüsselt sind, hier ist die Datenbank möglicherweise gar nicht involviert.
Informationen bei denen ALE sinnvoll wäre möchtest du nicht normalerweise gar nicht verarbeiten. Dies wäre z.B. bei Kreditkarten der Fall und da verwendet man in der Regel einen Dienstleister wie PayPal, Stripe etc. um dies auszulagern. Da gehört dann nämlich noch einiges mehr hinzu als nur die Daten zu verschlüsseln und da gibt es auch Vorgaben wie genau dies zu tun ist. Das betrifft meines Wissens auch einer deiner Fragen:
Passwörter von Nutzern so einzubeziehen wäre meines Wissens unter PCI nicht erlaubt. Die Daten wären in so einem Szenario natürlich verloren.Was passiert, wenn man beispielsweise das Passwort des Users mit in die Ver- und Entschlüsselung einbezogen wird und der User das dann vergisst? Sind die Daten dann verloren?
Indexing geht natürlich nicht mit ALE. Performance ist natürlich auch nicht ideal wobei den Schlüssel für jeden Query abzufragen weniger auf die Performance schlagen dürfte als die Ver-/Entschlüsselung. Wie genau es sich mit einem SQL Client hier verhält lässt sich nicht pauschal sagen, dass hängt von der Datenbank ab, ob die überhaupt solche Funktionalität anbietet (wahrscheinlich nicht) und ob man sie nutzt.
-
naheliegend
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Warum möchte man das nicht?
ist die Applikation dann wirklich so viel langsamer? Ich meine jede DB eines Shops hat Adressdaten oder die Emailadresse des Kunden. Diese einzelnen sensiblen Felder könnte man doch auf Applikationsebene verschlüsseln, oder?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Da die DB mit den Daten nichts anfangen kann, muss die Anwendung sie immer laden, entschluesseln, selber auswerten, verschluesseln & speichern. Und entsprechend teuer wird das. Und dann ist ja die primaere Angriffsflaeche nicht die Datenbank, sondern deine Anwendung. Die ist ja aus dem Netz erreichbar. Und damit hat man dann auch trivial die Datenbank-Eintraege in der Hand. Das zu machen lohnt sich also nur, wenn man sowohl die Anwendung haertet, als auch befuerchtet, dass einem die Datenbank *direkt* (zb durch physischen Zugriff) entwendet wird. Das ist fuer Addressdaten nicht der Fall. Kreditkarteninformationen hingegen schon.
Sinnvoll wäre dies bei Zahlungsinformationen oder sensitive personal data. Da musst du es dann auch tun und es gibt Anforderungen die eingehalten werden müssen. Adressdaten und Emailaddresse sind so sensibel nicht und gerade letzteres zu verschlüsseln ist ohnehin nicht möglich da die wahrscheinlich auch als Username genutzt wird.naheliegend hat geschrieben: ↑Samstag 12. März 2022, 22:04 Warum möchte man das nicht?
ist die Applikation dann wirklich so viel langsamer? Ich meine jede DB eines Shops hat Adressdaten oder die Emailadresse des Kunden. Diese einzelnen sensiblen Felder könnte man doch auf Applikationsebene verschlüsseln, oder?
Wirklich sensible Daten möchte man nicht Verarbeiten weil die Anforderungen die zu erfüllen sind sehr hoch sind. Auf der technischen Ebene ist es wie __deets__ schon erwähnt hat mit ein bisschen Verschlüsselung bei weitem nicht getan. Du kannst dir mal PCI DSS anschauen um eine Idee davon zu bekommen womit man es da zu tun hat.
Darüberhinaus hat man natürlich noch die rechtliche und PR Risiken wenn man dies nicht hinbekommt. Deswegen ist es sinnvoll solche Daten nicht zu verarbeiten, sofern dies möglich ist, z.B. in dem man Zahlungsdienstleister nutzt.
-
naheliegend
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Danke, ich verstehe.
Aber wenn man doch irgendwelche IBANs bei sich in der DB hat? Kann man nicht nur die dann nochmal separat verschlüsseln?
Aber wenn man doch irgendwelche IBANs bei sich in der DB hat? Kann man nicht nur die dann nochmal separat verschlüsseln?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Wenn du das willst, mach das doch. Welchen Wert das hat, wenn diese IBANs auf Webseiten und Briefköpfen auftauchen weiß ich zwar nicht, aber es gibt ja viele Dinge im Leben, die Menschen machen, weil es sich besser anfühlt. Nicht, weil es messbar besser ist. Löffel in 
zb.
Wenn es aber um eine ernsthafte Betrachtung von Sicherheitsrisiken geht, dann muss man ein Bedrohungsmodell erstellen, und anhand dessen die Vor- und Nachteile bestimmter Maßnahmen abwägen. Und im konkreten Fall zb die Frage beantworten, wie sich denn die Sicherheit des Webservers, mit dem sich die Verschlüsselung trivial rückgängig machen lässt, zur Gefahr eines Angriffs auf die Datenbank verhält. Den Angreifer interessiert nur das schwächste Glied. Nicht, ob du da eines irgendwie extra verschnörkelt hast.
zb. Wenn es aber um eine ernsthafte Betrachtung von Sicherheitsrisiken geht, dann muss man ein Bedrohungsmodell erstellen, und anhand dessen die Vor- und Nachteile bestimmter Maßnahmen abwägen. Und im konkreten Fall zb die Frage beantworten, wie sich denn die Sicherheit des Webservers, mit dem sich die Verschlüsselung trivial rückgängig machen lässt, zur Gefahr eines Angriffs auf die Datenbank verhält. Den Angreifer interessiert nur das schwächste Glied. Nicht, ob du da eines irgendwie extra verschnörkelt hast.