nicht angemeldet
MySQL verschlüsseln
TS
Rolf BGuten Tag,und noch eine Frage die mich beschäftigt. Überall geistert der Datenschutz umher. Da will man ja alles richtig machen. Also denke ich sollte ich die Daten in der MySQL Datenbank auch verschlüsseln.
Aber dich komme mit etwas nicht klar bzw. Verstehe ich das nicht.
Die Daten werden also mittels Script in die Datenbank geschrieben und verschlüsselt.
Anschliessend werden sie wieder ausgelesen und entschlüsselt. Dazu braucht man doch einen Key, ein Passwort das den verschlüsselungsvorgang unterstützt. Aber wo lege ich dieses Passwort ab?
Auf dem Server? Aber dann kann doch jeder die Daten entschlüsseln der das Passwort findet.
Oder verstehe mich da etwas nicht?
Was meint ihr denn dazu wie man hierbei vorgeht
-
Tach!
Also denke ich sollte ich die Daten in der MySQL Datenbank auch verschlüsseln.
Generell gesehen eine schlechte Idee, denn dann brauchst du keine Datenbank mehr, weil es eine einfache Datei auch tut.
Die Daten werden also mittels Script in die Datenbank geschrieben und verschlüsselt.
Und um sie zu verarbeiten muss man sie erst entschlüsseln. Damit fällt ein Großteil der Such- und Sortiermöglichkeiten und andere wichtige Merkmale eines DBMS aus.
Anschliessend werden sie wieder ausgelesen und entschlüsselt. Dazu braucht man doch einen Key, ein Passwort das den verschlüsselungsvorgang unterstützt. Aber wo lege ich dieses Passwort ab?
Auf dem Server? Aber dann kann doch jeder die Daten entschlüsseln der das Passwort findet.
Ja. Oder du gibst es jedes Mal beim Anmelden ein.
dedlfix.
-
Hello,
wie Dedlfix schon schrieb, gibt es für die Verschlüsselung von Datenbanken im Betrieb (noch) kein schlüssiges Konzept. Man sollte die Datenbank und ihre Zugriffsmodule nebst Geschäftsregeln daher immer in einem sicheren Bereich hosten und kapseln.
Den Übertragungsweg zur Frontend-API sollte man hingegen mit Transportsicherung verschlüsseln.
Alle Statements für Datenabfrage und -veränderung sollten ausschließlich im sichern Bereich erstellt und gespeichert werden (SQL-Injection verhindern). Diese kann man dann durch Datenbank-Benutzerfunktionen zur Verfügung stellen, die nur noch wenige Parameter übernehmen können und keine funktionelle Veränderung der Statements mehr zulassen. Diese Funktionen kann man nach DDS, DMS, DSS (Data Definition, Data Manipulation, Data Selection) für unterschiedliche User mit abgestuften Rechten zugänglich machen, sodaß eine einfache Abfrageseite niemals Datenveränderungen in Auftrag geben kann. Die Frontend-API sollte keinen direkten Zugriff mehr auf die Tabellen bekommen.
Wenn Du dieses Schema einhältst, hast Du nach dem Stand der Technik alles z. Zt. mögliche für die Sicherheit getan.
Glück Auf
Tom vom Berg--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Aber dich komme mit etwas nicht klar bzw. Verstehe ich das nicht.
Einfach mal machen! MFG
-
Etwas machen wovon man nichts versteht?
Wir sind doch kein Politikforum 😂-
Etwas machen wovon man nichts versteht?
Wir sind doch kein Politikforum 😂Stimmt. Hier sind nur Theoretiker. Oder hast Du hier irgendwo gelesen daß einer über seine Erfahrungen schreibt die er diesbezüglich mal gemacht hat!? MFG
-
-
-
Hallo Dieter,
du hast Recht, das ist keine triviale Angelegenheit.
Zu unterscheiden ist Verschlüsselung ruhender Daten (also der Dateien, in denen die DB-Engine die Datenbank ablegt) und Verschlüsselung beim Transport (SSL, TLS).
TLS ist ein Thema, das zwischen PHP und MYSQL ausgehandelt werden muss, und wird dem Anschein nach mit Zertifikaten realisiert. Wenn MYSQL und Webserver auf dem gleichen Gerät laufen (localhost connection), ist sie uninteressant. Generell findet man bei PHP und MYSQL Informationen dazu unter "encrypted connection". Ich habe allerdings den Eindruck, dass das bei PHP erbärmlich dokumentiert ist. Und gegen einen User mit root Rechten (oder auch nur Lesezugriff auf die Zertifikate) schützt das alles nicht, weil die Zertifikate in lesbaren Dateien vorliegen müssen. Unter Windows gäbe es ja den geschützten Zertifikatspeicher, aber offenbar unterstützt PHP den nicht.
Verschlüsselung ruhender Daten (data at rest) ist etwas, das die DB Engine unterstützen muss. Es ist nicht sinnvoll, die Daten in der Application zu verschlüsseln - aus den bereits von anderen Postern genannten Gründen.
MYSQL ab Version 5.7 unterstützt Tablespace Encryption in der InnoDB Engine. Hier steht, wie man es macht. Gegen einen root-User, der auf dem Server Amok läuft, wird das aber auch kein sicherer Schutz sein. Es schützt gegen geklaute Backups und gegen Leute, die irgendwie Lesezugang zu den Tablespace-Dateien bekommen haben. Und es schützt ein bisschen gegen übermäßige Server-Performance...
Rolf
--
sumpsi - posui - clusi