5
Datenbank Verschlüsselung - Welcher Ansatz?
Hallo,
ich befasse mich zur Zeit mit der Verschlüsselung von einer MySQL Datenbank. Dabei habe ich jetzt mehrere Ansätze gelesen und hätte noch ein paar Fragen dazu. Die Ansätze dich ich gelesen habe: Festplattenverschlüsselung (komplett), Verschlüsselung der Datenbankdateien, Verschlüsselung von Spalten mittels AES_ENCRYPT().
Das Ziel der Verschlüsselung ist doch, dass ein Angreifer der Zugriff auf die Datenbank / den PC hat, die Daten nicht lesen kann. So hätte ich das zumindest verstanden. Aber dann fallen die ersten beiden Ansätze doch flach oder? Denn zur Laufzeit des PCs, zu dem ein Angriff meist stattfindet, sind die Daten doch lesbar, oder nicht? Das heißt für mich, die ersten beiden Ansätze sind nur dann Interessant, wenn die Festplatte ausgebaut ist. Daher bleibt nur Ansatz 3, AES_ENCRYPT(). Aber gibt es da wirklich keine einfachere Möglichkeit um eine vergleichbare Sicherheit zu erzielen? Also dass nur die Anwendung selbst, die den Schlüssel kennt, die Daten lesen kann? Ist das überhaupt ein sinnvoller Ansatz? Immerhin macht das Schema-Änderungen und Wartungsarbeiten fast unmöglich oder zumindest schwer durchführbar.
Daher bleibt zum Schluss noch die Frage: wenn es heißt, Daten müssen verschlüsselt gespeichert werden (z.B. Gesundheitsdaten), reicht dann eine "einfache" Fesplattenverschlüsselung?
Danke, Gruß homedom
ich befasse mich zur Zeit mit der Verschlüsselung von einer MySQL Datenbank. Dabei habe ich jetzt mehrere Ansätze gelesen und hätte noch ein paar Fragen dazu. Die Ansätze dich ich gelesen habe: Festplattenverschlüsselung (komplett), Verschlüsselung der Datenbankdateien, Verschlüsselung von Spalten mittels AES_ENCRYPT().
Das Ziel der Verschlüsselung ist doch, dass ein Angreifer der Zugriff auf die Datenbank / den PC hat, die Daten nicht lesen kann. So hätte ich das zumindest verstanden. Aber dann fallen die ersten beiden Ansätze doch flach oder? Denn zur Laufzeit des PCs, zu dem ein Angriff meist stattfindet, sind die Daten doch lesbar, oder nicht? Das heißt für mich, die ersten beiden Ansätze sind nur dann Interessant, wenn die Festplatte ausgebaut ist. Daher bleibt nur Ansatz 3, AES_ENCRYPT(). Aber gibt es da wirklich keine einfachere Möglichkeit um eine vergleichbare Sicherheit zu erzielen? Also dass nur die Anwendung selbst, die den Schlüssel kennt, die Daten lesen kann? Ist das überhaupt ein sinnvoller Ansatz? Immerhin macht das Schema-Änderungen und Wartungsarbeiten fast unmöglich oder zumindest schwer durchführbar.
Daher bleibt zum Schluss noch die Frage: wenn es heißt, Daten müssen verschlüsselt gespeichert werden (z.B. Gesundheitsdaten), reicht dann eine "einfache" Fesplattenverschlüsselung?
Danke, Gruß homedom
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: 195545
Url: https://administrator.de/contentid/195545
Printed on: April 19, 2024 at 12:04 o'clock
5 Comments
Latest comment
Hallo homedom,
vorerst eins, bitte nimm nicht die original Datenbank, bitte arbeite mit einer Kopie!
Zweitens mach ein Backup der Datenbank und zwar ein Vollbackup!
Mit dem Hinblick auf die Gesundheitsdaten gibt es zum Einen bestimmt Vorschriften oder aber zumindest
Hinweise darauf wie solche Daten zu handhaben sind! Und eben dort solltest Du zuerst ansetzen um heraus zu
finden was gegeben und vor allem was erfüllt sein muss, im Hinblick auf genau diese Gesundheitsdaten!
Man kann Zugriffe auf Datenbanken beschränken, so dass nicht jeder Benutzer alle Daten einsehen, drucken, auslesen oder abspeichern so wie exportieren kann.
Und man kann diese Daten auch noch zusätzlich verschlüsseln wenn sie abgespeichert werden, damit niemand (intern) einfach diese Datenbank stiehlt und die Daten verwerten kann!
Sollte nun jemand auch gewisse Daten zugreifen wird zum einen überprüft ob Sie/Er berechtigt ist diese einzusehen und zum anderen werden diese dann entschlüsselt und Sie/er kann damit arbeiten.
Dieses Vorgehen ist allerdings an eine gewissen Größe und Mitarbeiterzahl gebunden und nicht zu guter Letzt auch eine Implementationsfrage und hier liegt meist der wirkliche Fallstrick!
Was nützt Dir denn, sagen wir einmal der AES-256 Chipher wenn Du den jetzt falsch implementierst
und das ganze ist trotzdem zu umgehen oder zu entschlüsseln? Nichts, rein garnichts, ich meine wenn es um
die Kundendatenbank mit Margen, Tarifen und/oder Konditionen der Kunden geht ist das halt Pech für den
Betrieb und Dich, aber wenn es nun um Patientendaten oder Gesundheitsdaten geht, steht auch noch recht schnell der Landesbeauftragte für Datenschutz auf der Matte und stellt komische Fragen und dann ist es eben besser man kann sagen das es sich um eine zertifizierte Lösung der Firma x, y oder z handelt
um meist großen und teuren Ärger zu vermeiden!
Um sich aber gegen externe agierende Datendiebe zu schützen, wird Dir die Verschlüsselung alleine nicht ausreichen! Da kommt es wohl auch eher darauf an das Gesamtkonzept an.
Wo steht die Datenbank? (LAN, DMZ)
Wie ist diese geschützt, gesichert oder wird diese Verteidigt?
Sind das Geräte von einem namhaften Herstellern die nach einem bestimmten Standard zertifiziert sind?
z.B. die pfSense und auch mOnOwall sind tolle Firewall, aber nach was sind die zertifiziert worden und
wer bürgt oder haftet im Fall der Fälle dafür? Klar bei der normalen Firma und der o.g. Kundendatenbank
fragt danach keiner oder besser niemand, aber im Falle von Patientendaten oder Gesundheitsdaten
fragt der Landesbeauftragte des jeweiligen Bundeslandes danach und das dummer weise auch noch ziemlich energisch!
Da kann man halt nicht sagen das ist aber ne schicke Firewall und die Nehmen die Anderen Kumpels auch alle.
Mag ja alles richtig sein, nur in einem solchen Fall würde ich lieber sagen können, verhau wen anderes,
vor allem anderen aber wenn jemand klagt und die Versicherung dann nicht haften will, weil ja nichts
zertifiziert war und Standards nicht eingehalten wurden, dann wird es richtig ungemütlich, für Dich.
Zu guter Letzt falls Du vorhast die Festplatten alle am Feierabend zu verschlüsseln und dann
die Rechner und Server runter zu fahren, keine schlechte Idee vielleicht, aber bitte nimm das dann auch mit
in Deinen Backup Plan so auf und werde dem auch gerecht!
Wenn es wirklich um Gesundheitsdaten und/oder Patientendaten geht würde ich an Deiner Stelle da nicht selber etwas zusammen "schustern" und nachher sagt Dr. XYZ, das hat der EDV Dienstleister erledigt haut den und nicht mich!
Gruß und schönes WE
Dobby
vorerst eins, bitte nimm nicht die original Datenbank, bitte arbeite mit einer Kopie!
Zweitens mach ein Backup der Datenbank und zwar ein Vollbackup!
Mit dem Hinblick auf die Gesundheitsdaten gibt es zum Einen bestimmt Vorschriften oder aber zumindest
Hinweise darauf wie solche Daten zu handhaben sind! Und eben dort solltest Du zuerst ansetzen um heraus zu
finden was gegeben und vor allem was erfüllt sein muss, im Hinblick auf genau diese Gesundheitsdaten!
Man kann Zugriffe auf Datenbanken beschränken, so dass nicht jeder Benutzer alle Daten einsehen, drucken, auslesen oder abspeichern so wie exportieren kann.
Und man kann diese Daten auch noch zusätzlich verschlüsseln wenn sie abgespeichert werden, damit niemand (intern) einfach diese Datenbank stiehlt und die Daten verwerten kann!
Sollte nun jemand auch gewisse Daten zugreifen wird zum einen überprüft ob Sie/Er berechtigt ist diese einzusehen und zum anderen werden diese dann entschlüsselt und Sie/er kann damit arbeiten.
Dieses Vorgehen ist allerdings an eine gewissen Größe und Mitarbeiterzahl gebunden und nicht zu guter Letzt auch eine Implementationsfrage und hier liegt meist der wirkliche Fallstrick!
Was nützt Dir denn, sagen wir einmal der AES-256 Chipher wenn Du den jetzt falsch implementierst
und das ganze ist trotzdem zu umgehen oder zu entschlüsseln? Nichts, rein garnichts, ich meine wenn es um
die Kundendatenbank mit Margen, Tarifen und/oder Konditionen der Kunden geht ist das halt Pech für den
Betrieb und Dich, aber wenn es nun um Patientendaten oder Gesundheitsdaten geht, steht auch noch recht schnell der Landesbeauftragte für Datenschutz auf der Matte und stellt komische Fragen und dann ist es eben besser man kann sagen das es sich um eine zertifizierte Lösung der Firma x, y oder z handelt
um meist großen und teuren Ärger zu vermeiden!
Um sich aber gegen externe agierende Datendiebe zu schützen, wird Dir die Verschlüsselung alleine nicht ausreichen! Da kommt es wohl auch eher darauf an das Gesamtkonzept an.
Wo steht die Datenbank? (LAN, DMZ)
Wie ist diese geschützt, gesichert oder wird diese Verteidigt?
Sind das Geräte von einem namhaften Herstellern die nach einem bestimmten Standard zertifiziert sind?
z.B. die pfSense und auch mOnOwall sind tolle Firewall, aber nach was sind die zertifiziert worden und
wer bürgt oder haftet im Fall der Fälle dafür? Klar bei der normalen Firma und der o.g. Kundendatenbank
fragt danach keiner oder besser niemand, aber im Falle von Patientendaten oder Gesundheitsdaten
fragt der Landesbeauftragte des jeweiligen Bundeslandes danach und das dummer weise auch noch ziemlich energisch!
Da kann man halt nicht sagen das ist aber ne schicke Firewall und die Nehmen die Anderen Kumpels auch alle.
Mag ja alles richtig sein, nur in einem solchen Fall würde ich lieber sagen können, verhau wen anderes,
vor allem anderen aber wenn jemand klagt und die Versicherung dann nicht haften will, weil ja nichts
zertifiziert war und Standards nicht eingehalten wurden, dann wird es richtig ungemütlich, für Dich.
Zu guter Letzt falls Du vorhast die Festplatten alle am Feierabend zu verschlüsseln und dann
die Rechner und Server runter zu fahren, keine schlechte Idee vielleicht, aber bitte nimm das dann auch mit
in Deinen Backup Plan so auf und werde dem auch gerecht!
Wenn es wirklich um Gesundheitsdaten und/oder Patientendaten geht würde ich an Deiner Stelle da nicht selber etwas zusammen "schustern" und nachher sagt Dr. XYZ, das hat der EDV Dienstleister erledigt haut den und nicht mich!
Gruß und schönes WE
Dobby
Hallo Dobby,
danke für deine ausführliche Antwort.
Leider hat das meine Frage nicht ganz beantwortet. Mir geht es mehr um die Datenbankverschlüsselung an sich.
Gruß, homedom
danke für deine ausführliche Antwort.
Leider hat das meine Frage nicht ganz beantwortet. Mir geht es mehr um die Datenbankverschlüsselung an sich.
Gruß, homedom
Hallo Dobby,
Dann scheint mir, Du kennst MySQL nicht.
Grundsätzlich ist es so, daß die Datenbanken ja zum einen als Dateien vorliegen (bei MySQL kann man die sogar im laufenden Betrieb woandershinkopieren, und die Chancen stehen nicht schlecht, daß die dann auch werkeln...)
Und wie der Threadstarter gesagt hat, wenn die DB erst mal läuft, sind die Daten ohnehin unencrypted.
Grundsätzlich ist das aber bei ALLEN Datenbanken so:
ab dem Zeitpunkt, ab dem sie laufen, kann man durch sog. Injections an die Daten kommen, sofern man Fehler in der Drumherum-Applikation findet.
Daher lautet die wohl logischste Lösung für Dein Problem:
sauberer Code, prepared statements und mehrere Berechtigungsebenen
Lonesome Walker
Zitat von @108012:
Man kann Zugriffe auf Datenbanken beschränken, so dass nicht jeder Benutzer alle Daten einsehen, drucken, auslesen oder
abspeichern so wie exportieren kann.
Man kann Zugriffe auf Datenbanken beschränken, so dass nicht jeder Benutzer alle Daten einsehen, drucken, auslesen oder
abspeichern so wie exportieren kann.
Dann scheint mir, Du kennst MySQL nicht.
Grundsätzlich ist es so, daß die Datenbanken ja zum einen als Dateien vorliegen (bei MySQL kann man die sogar im laufenden Betrieb woandershinkopieren, und die Chancen stehen nicht schlecht, daß die dann auch werkeln...)
Und wie der Threadstarter gesagt hat, wenn die DB erst mal läuft, sind die Daten ohnehin unencrypted.
Grundsätzlich ist das aber bei ALLEN Datenbanken so:
ab dem Zeitpunkt, ab dem sie laufen, kann man durch sog. Injections an die Daten kommen, sofern man Fehler in der Drumherum-Applikation findet.
Daher lautet die wohl logischste Lösung für Dein Problem:
sauberer Code, prepared statements und mehrere Berechtigungsebenen
Lonesome Walker
Moin,
ich denke du musst einfach klar sagen wogegen du dich schützen möchtest… Es gibt keine Methode "ProtectAnywhere".
Möchtest du dich dagegen schützen das jemand deinen Server klaut - dann wären die Platten zu verschlüsseln. Wenn man jetzt mal davon ausgeht das derjenige nicht das System erst mit Flüssigstickstoff behandelt und so wirklich das System einfriert sondern einfach ausschaltet und mitnimmt bist du dann schon auf dem richtigen Weg (natürlich nur wenn die nicht automatisch beim Start entschlüsselt werden - sondern hier irgendein Key/Token benötigt wird).
Möchtest du die Dateninhalte schützen (sei es SQL-Injection oder sei es einfach nen Physikalischer Zugriff auf die DB) dann musst du deine Daten dann selbst verschlüsseln. Dabei kannst du wählen ob du eine "Einweg-Verschlüsselung" wie MD5 nutzt (ja, ich weiss, ist keine Verschlüsselung!) - zum Beispiel für Passwörter die du ja nie wieder im Klartext zurück benötigst. Oder brauchst du die Entschlüsselung auch - dann musst du dir hier eines der bekannten Verfahren aussuchen…
Die dritte Stelle wäre die Datenübertragung. Es bringt ja wenig wenn du deine Daten mit 500000 Millionen Bits verschlüsselt hast und selbst in 1 Mrd. Jahren das keiner knacken kann - du aber die Daten dann im Klartext über die Leitung jagst so das jeder Sharki die einfach mal mitschneidet… Dagegen hilft dann natürlich auch keine Festplattenverschlüsselung usw…
Und dann hast du eben die schlimmste Stelle - das ist der Client. Denn alle 3 anderen Stellen kannst du beeinflussen. Aber: Wenn die Daten beim Client lokal zwischengespeichert werden, der Client nen Trojaner oder sonst was hat was da alle Daten mit weghaut dann guckst du dumm aus der Wäsche. Deine Platten verschlüsselt, deine DB alles verschlüsselt, beste SSL-Verschlüsselung für die Datenübertragung, saubere Keys das ein "Man in the middle" ausgeschlossen werden kann -> und auf dem Client sendet der Trojaner fröhlich munter alle deine Daten ins Web. HIER hilft dann eben nur ein vernünftiges Berechtigungskonzept -> so das der Client eben nur das sehen darf was er unbedingt muss und die anderen Daten gar nicht zum Client wandern…
Schönen Gruß,
Mike
ich denke du musst einfach klar sagen wogegen du dich schützen möchtest… Es gibt keine Methode "ProtectAnywhere".
Möchtest du dich dagegen schützen das jemand deinen Server klaut - dann wären die Platten zu verschlüsseln. Wenn man jetzt mal davon ausgeht das derjenige nicht das System erst mit Flüssigstickstoff behandelt und so wirklich das System einfriert sondern einfach ausschaltet und mitnimmt bist du dann schon auf dem richtigen Weg (natürlich nur wenn die nicht automatisch beim Start entschlüsselt werden - sondern hier irgendein Key/Token benötigt wird).
Möchtest du die Dateninhalte schützen (sei es SQL-Injection oder sei es einfach nen Physikalischer Zugriff auf die DB) dann musst du deine Daten dann selbst verschlüsseln. Dabei kannst du wählen ob du eine "Einweg-Verschlüsselung" wie MD5 nutzt (ja, ich weiss, ist keine Verschlüsselung!) - zum Beispiel für Passwörter die du ja nie wieder im Klartext zurück benötigst. Oder brauchst du die Entschlüsselung auch - dann musst du dir hier eines der bekannten Verfahren aussuchen…
Die dritte Stelle wäre die Datenübertragung. Es bringt ja wenig wenn du deine Daten mit 500000 Millionen Bits verschlüsselt hast und selbst in 1 Mrd. Jahren das keiner knacken kann - du aber die Daten dann im Klartext über die Leitung jagst so das jeder Sharki die einfach mal mitschneidet… Dagegen hilft dann natürlich auch keine Festplattenverschlüsselung usw…
Und dann hast du eben die schlimmste Stelle - das ist der Client. Denn alle 3 anderen Stellen kannst du beeinflussen. Aber: Wenn die Daten beim Client lokal zwischengespeichert werden, der Client nen Trojaner oder sonst was hat was da alle Daten mit weghaut dann guckst du dumm aus der Wäsche. Deine Platten verschlüsselt, deine DB alles verschlüsselt, beste SSL-Verschlüsselung für die Datenübertragung, saubere Keys das ein "Man in the middle" ausgeschlossen werden kann -> und auf dem Client sendet der Trojaner fröhlich munter alle deine Daten ins Web. HIER hilft dann eben nur ein vernünftiges Berechtigungskonzept -> so das der Client eben nur das sehen darf was er unbedingt muss und die anderen Daten gar nicht zum Client wandern…
Schönen Gruß,
Mike
Hallo,
AES ist gut und sicher. Ich weiß, Firmen sollen in Foren nichts reinschreiben, aber wir haben eine kostenfrei OpenSource Datenverschlüsselungs-Lösung: http://eperi.de/open-source/secrt/
Viele Grüße,
WOlfgang
AES ist gut und sicher. Ich weiß, Firmen sollen in Foren nichts reinschreiben, aber wir haben eine kostenfrei OpenSource Datenverschlüsselungs-Lösung: http://eperi.de/open-source/secrt/
Viele Grüße,
WOlfgang
