Verschlüsselung von MYSQL selbst

[Forumsgast]

Hallo liebe Forumianer,

welche Möglichkeiten gibt es, MySQL selbst zu verschlüsseln?
D.h. damit man z.B. den Debug-Modus nicht starten kann, um die Abfragen mitschneiden kann oder die Struktur in der Datenbank selbst einsehen.

Der Grund dafür ist recht einfach: Es handelt sich um ein Software-Projekt das unter MySQL arbeitet, ABER niemand (ausser die Entwickler selbst) die Funktionsweise kennen dürfen.

Vielen Dank für eure Hilfe.

MfG Andreas

[Forumsgast]

Ja gibt es, aber nicht kostenlos. Das wird über einen speziellen Treiber geregelt. Den muss man kaufen. Den Debug-Mode kann man aber nicht ausschalten. Hat ja mit dem Treiber nichts zu tun. Das wäre aber sowieso nur möglich wenn ein Kunde Zugang zum Server hat - also zum Beispiel bei einer Distribution auf CD/DVD. In diesem Fall kann man aber auch überlegen auf SQLite zu portieren ...
Wir hatten das Problem schon mal. Für uns war es aber ausreichend die Datenbank zu komprimieren. Mit MyISAM-Tabellen geht das mit Bordmitteln. Die Tabellen sind hinterher nicht mehr im Klartext lesbar, aber dafür "read-only". In unserem Fall okay: wir haben den Server von einer DVD aus betrieben.

[Forumsgast]

Der Grund dafür ist recht einfach: Es handelt sich um ein Software-Projekt das unter MySQL arbeitet, ABER niemand (ausser die Entwickler selbst) die Funktionsweise kennen dürfen.

Hört sich nach Fail-Prinzip an.
Entweder handelt es sich um sensible Daten, dann sind diese vor dem Schreiben in die Datenbank zu verschlüsseln oder dein Konzept ist falsch. Wenn es sich um total geheime Algorithmen handelt und du deshalb die Querys verschlüsseln willst, dann solltest du dir eher darüber Gedanken machen, wer denn noch so alles Zugriff auf den Server hat und warum.

[Forumsgast]

Die Algorithmen könnten später unsere Kunden im Debugmodus sehen, da sie auch den vollen Zugriff auf ihren Server haben werden.

Wir stehen allgemein vor dem Problem, dass Unternehmen Ihre Daten aus Datenschutz an uns nicht übermitteln. In diesem Fall hätten wir allein die volle Kontrolle über den Server,

...ABER das ist nunmal nicht der Fall.

MfG Andreas

[Forumsgast]

Ist mir zu hoch - muss ich nicht verstehen, oder?

[Forumsgast]

Wenn es sich um total geheime Algorithmen handelt und du deshalb die Querys verschlüsseln willst, dann solltest du dir eher darüber Gedanken machen, wer denn noch so alles Zugriff auf den Server hat und warum.
Gestern 21:08

Der Server, auf dem unser Tool genutzt wird steht beim Endkunden, und nicht bei uns im Unternehmen. Daher müssen wir eine Möglichkeit finden MySQL selbst zu verschlüsseln, damit der Endkunde nicht den vollen Zugriff auf MySQL hat (Debugmodus, etc.)

[Forumsgast]

Sagte ich ja, Fail-Prinzip. Wer seinen Kunden Lösungen verkauft, die auch beim Kunden gehostet werden, der sollte damit rechnen, dass der Kunde sich diese auch genauer ansehen kann.

[Forumsgast]

Dein "Lösungsansatz" ist also Kritik zu üben? ^^

Ein kreativer Lösungsansatz wäre wünschenswerter

[Forumsgast]

Nutze andere Datenbanken. Es gibt genug, die das leisten was du brauchst. Diese kosten jedoch auch entsprechend ...

[Forumsgast]

Sagte ich ja, Fail-Prinzip.

Fragt sich, wer genau "failed".
Es gibt durchaus Anwendungsfälle, in denen unveränderlichkeit der Daten vorgeschrieben wird.
Schau dir z.B. mal Lexware an, wird auch beim Kunden gehostet und trotzdem kommst du nicht an die DB.
Liegt wohl unter anderem auch daran, dass es um BuHa geht, die eben unveränderlich sein muss, damit man seine Bücher nicht mal eben so frisieren kann, wenn der Prüfer grade Kaffee trinkt.

[Forumsgast]

http://www.postgresql.org/docs/8.3/static/pgcrypto.html

Sollte das können, was du haben möchtest.

Grüße Basti

[Forumsgast]

http://www.postgresql.org/docs/8.3/static/pgcrypto.html

Sollte das können, was du haben möchtest.

Hab' ich was übersehen oder geht's in dem Link tatsächlich nur um "normale" Verschlüsselung der Daten?
Der OP möchte den kompletten DB-Server verschlüsselt haben, nicht nur Daten, sprich auch Tabellen oder hinterlegte Views, Procedures etc.


Um noch etwas Produktives zum Thema beizutragen:
http://www.gazzang.com/products/eznc...andard-edition
Laut Website mit PCI-DSS-Compliance, das dürfte dann wohl auch für deinen Anwendungsfall ausreichen.
Allerdings nicht gerade ein Schnäppchen.

http://www.vormetric.com/products/index.html
und
http://www.packetgeneral.com/products/pci-general-mysql
Die haben wohl auch was im Angebot.

Schwierig bei allen Lösungen ist und bleibt, dass es sich um wechselnde Rechner handelt.
Ansonsten hätte ich vorgeschlagen, einen TrueCrypt-Container auszuliefern - der braucht aber Key/Pass beim Starten des Dienstes, ergo könnte ihn jeder auch "von Hand" entschlüsseln.
Es würde sich da also wohl fast schon eher lohnen, eine eigene Lösung für diesen speziellen Fall zu entwickeln.
Mögliche Optionen wären da sicherlich File-Encryption mit HardCoded-Keys im selbstkompilierten MySQL-Binary oder ein Ergänzungsmodul, das On-The-Fly arbeitet.

[Forumsgast]

Der PHP-Code liegt dennoch offen. Selbst wenn die komplette Datenbank verschlüsselt ist, ist dies kein Garant für Unauslesbarkeit oder Unveränderbarkeit. Wenn der Kunde den PHP-Code manipulieren kann, dann kann er auch die Datenbank manipulieren und über die Verschlüsselung von PHP-Code haben wir hier schon des Öfteren diskutiert.

[Forumsgast]

FÜr das Verschlüsseln von PHP-Code gibt es Zusatz-Extensions, die man verwenden kann. Die Verschlüsselung selbst ist kostenpflichtig. Die zum Ausführen benötigte Extension hingegen frei verfügbar in der Regel. Gibt da mehrere Anbieter.

[Forumsgast]

Verwendet man Zend Guard oder IonCube hat man sein Möglichstes getan.
Und für 99,99% der User ist das vollkommen ausreichend.