Datenbank mit Tabellenverschlüsselung benötigt.

[IBExpert]

http://www.ibexpert.net/ibe/index.ph...ptionPluginFB3

Wobei bei firebird gleich die gesamte DB verschlüsselt ist, was aber auch keineswegs als
Nachteil zu sehen ist, wenn die Anforderung des Kunden eben eine Verschlüsselung erfordert.

[Klaus01]

postgreSQL kann da auch was: https://www.postgresql.org/docs/8.1/...n-options.html und http://www.postgresonline.com/journa...-pgcrypto.html

Grüße
Klaus

[Andreas L.]

Du kannst auch die Daten der Felder verschlüsseln. Z. B. mit dem DEC -> https://github.com/decfpc/DelphiEncryptionCompendium oder https://github.com/winkelsdorf/Delph...ionCompendium/

[Uwe Raabe]

Zitat von Andreas L.:

Du kannst auch die Daten der Felder verschlüsseln. Z. B. mit dem DEC -> https://github.com/decfpc/DelphiEncryptionCompendium oder https://github.com/winkelsdorf/Delph...ionCompendium/

Das kann aber Probleme geben, wenn die verschlüsselten Felder zur Sortierung verwendet werden sollen. Auch in WHERE Clauses mit größer, kleiner oder BETWEEN wird das vermutlich nicht funktionieren.

[Bernhard Geyer]

Zitat von Uwe Raabe:

Das kann aber Probleme geben, wenn die verschlüsselten Felder zur Sortierung verwendet werden sollen. Auch in WHERE Clauses mit größer, kleiner oder BETWEEN wird das vermutlich nicht funktionieren.

Definitiv nicht mehr. Eine nicht auf DB-Ebene laufende Verschlüsselung ist eine KO-Kriterium wenn man mal etwas mehr als ein paar Datensätze benötig.
Auch sowas wie Abfragen mit Like und Wildcards geht auch nicht mehr.
Da kann man gleich ohne DBMS arbeiten.

[johndoe049]

Hallo,

danke für die Hinweise.

Bei MsSQL habe ich Informationen zur Version 2016 gefunden. Tabellenverschlüsselung, dass der DB Administrator das nicht lesen kann, bedeutet, dass man u.a. auf joins und where verzichten muss. Wie von Bernhard Geyer geschrieben, ist das nicht sinnvoll.

Bei PostrgeSQL ist unter pgcrypto folgendes geschrieben.

Zitat:

The /contrib function library pgcrypto allows certain fields to be stored encrypted. This is useful if only some of the data is sensitive. The client supplies the decryption key and the data is decrypted on the server and then sent to the client.

The decrypted data and the decryption key are present on the server for a brief time while it is being decrypted and communicated between the client and server. This presents a brief moment where the data and keys can be intercepted by someone with complete access to the database server, such as the system administrator.

Problem ist, dass der Kunde ein Audit hat und man auf dieses Scenario besteht.

Angeblich würde das Steuerrecht vorgeben, dass auch auch Änderungen vom DB Administrator nachvollzogen werden müssen, bzw. wenn dies nicht möglich ist unterbunden werden müssen.

Nur mal so gefragt: Kennt jemand so eine Vorgabe, oder ist dass von den Auditoren eine Wunschvorstellung?

[Klaus01]

Zitat von johndoe049:

Hallo,

danke für die Hinweise.

Bei MsSQL habe ich Informationen zur Version 2016 gefunden. Tabellenverschlüsselung, dass der DB Administrator das nicht lesen kann, bedeutet, dass man u.a. auf joins und where verzichten muss. Wie von Bernhard Geyer geschrieben, ist das nicht sinnvoll.

Wenn ich Bernhard richtig verstanden habe bezog er sich auf nicht DBMS verschlüsselungs Methoden.
D.h. wenn Du von deinem Client die Daten verschlüsselt in dei Datenbank ablegst - dann hat das DBMS Probleme mit where, joins etc.
Es kann die Daten schlichtweg nicht lesen.

Wenn es eine Verschlüsselung ist, die vom DBMS unterstütz ist, dann kann das DBMS diese Daten bei SQL Abfragen auch entschlüsseln.

Grüße
Klaus

[Delphi.Narium]

Zitat von johndoe049:

Angeblich würde das Steuerrecht vorgeben, dass auch auch Änderungen vom DB Administrator nachvollzogen werden müssen, bzw. wenn dies nicht möglich ist unterbunden werden müssen.

Das finde ich irgendwie befremdlich:

Wenn also Änderungen vom DB Administartor nachvollzogen werden können, ist alles ok und man braucht keine Verschlüsselung?

Wenn man Änderungen aber nicht nachvollziehen kann, dann verschlüsselt man die Daten einfach, denn damit kann man dann sicherstellen, dass der DB Administrator die nicht nachvollziehbaren Änderungen sehen und erkennen kann und damit nicht feststellen kann, dass sie nicht nachvollziehbar sind?

Zugegeben: Etwas arg überspitzt formuliert. Aber mir scheint das nicht der richtige Ansatz zu sein.

Alternativ könnte man dem DB Administartor doch einfach auch den Zugriff auf die DB untersagen / ihm keine entsprechenden Rechte geben, dann kann er auch nicht in die Daten schauen.

Wenn man ihm jedoch Zugriff auf die Datenbank gewährt, so kann er auch die Daten in der Datenbank sehen, da die Verschlüsselung ja (höchstwahrscheinlich) für alle Datenbankanwender funktioniert. Oder anders formuliert: Wenn der DB Administartor die Daten in der Datenbank nicht lesen darf und sie deshalb verschlüsselt werden, so scheidet eine datenbankseitige Verschlüsselung aus, da sie ja letztlich für alle Anwender, also auch den DB Administrator, transparent ist, also nicht sichtbar. Verschlüsselt die Datenbank, so bekommen alle Anwender bei 'nem select * from tabelle die unverschlüsselten Daten zu sehen, auch der DB Administrator ist nur ein Anwender, wenn er auf die Daten schaut. Schaut man aber mit 'nem HEX-Editor ... an der Datenbank vorbei in die Daten, dann bekommt man nur "verschlüsseltes Gelumpe" zu sehen.

Oder soll die Datenbank hergehen und die Daten nur entschlüsselt liefern, wenn eine bestimmte Software sie anfordert und andernfalls die verschlüsselten Daten?

Das hieße dann: Die Verschlüsselung muss durch die Software erfolgen, damit ist eigentlich jede sinnvolle Arbeit mit der Datenbank hinfällig.

Natürlich kann man Abfragen parametrisiert gestalten und über die Parameter dann die verschlüsselten Werte an die Abfragen geben.
Aber, wie weiter oben schon erwähnt, wird es dann bei allem, was auch nur im Ansatz zu einer unscharfen Suche dient, wie like, between, Substrings aber auch Order By, dann eher "spaßig" werden oder zu unerwarteten Ergebnissen führen.

Einzig funktionieren könnten dann noch exakte Abfragen auf Werte, wie z. B. technische Datensatzschlüssel, Namen in exakter Schreibweise. Alles andere wird gnadenlos scheitern.

Zitat von johndoe049:

Nur mal so gefragt: Kennt jemand so eine Vorgabe, oder ist dass von den Auditoren eine Wunschvorstellung?

Egal ob es diese Vorgabe gibt oder nicht: Die gefolgerte Konsequenz erscheint mir fraglich.
Wenn ich nicht will, dass der DB Administrator in die Daten schauen kann, dann untersage ich ihm den Zugriff auf die Daten Punkt
Aber die Daten unlesbar und in letzter Konsequenz unbrauchbar zu machen, erscheint mir der falsche Ansatz.

In Arbeitsverträgen ist für gewöhnlich geregelt, wer wo in welche Daten Einsicht nehmen darf und welche Folgen die Nichtbeachtung hat.
Details regelt man über entsprechende Rechtevergaben für Datenbanken, Filesysteme ...
Man stellt ja auch nicht sicher, dass jemand alle Emails aller Nutzer einsehen kann, indem man sie so verschlüsselt, das bestimmte Emails nur von einem bestimmten Nutzer gelesen werden können, aber nicht von den anderen.

Bevor Du da jetzt weiterforschst, lass von Deinem Arbeitgeber erstmal definitiv klären, ob die "behauptete Rechtsgrundlage" eine "real existierende Rechtsgrundlage" ist, weise ihn schonmal auf die zu erwartenden Konsequenzen in Bezug auf die Nutzbarkeit der Software hin und lass ihn dann entscheiden, ob er den Auftrag überhaupt annehmen mag

PS:
Abgesehen davon kann man in "gewöhnlichen" Datenbanken per Grant Rechte vergeben.
Wenn der DB Administrator keine Rechte auf die Tabellen mit Geschäftsdaten bekommen soll, dann kann man sie ihm ja per Revoke entziehen und damit kann er dann auch nicht mehr in die Daten schauen. Natürlich wird das den Umfang seiner Arbeitsmöglichkeiten einschränken, aber sicherlich seine Arbeit nicht unmöglich machen.
(Achso: Der DB Administrator sollte in diesem Fall nicht das Recht haben, sich selbst beliebige Rechte zu erteilen )

[Frickler]

Zitat von IBExpert:

http://www.ibexpert.net/ibe/index.ph...ptionPluginFB3

Wobei bei firebird gleich die gesamte DB verschlüsselt ist, was aber auch keineswegs als
Nachteil zu sehen ist, wenn die Anforderung des Kunden eben eine Verschlüsselung erfordert.

Was ist das für eine Verschlüsselung? IBPhoenix und IBSurgeon bieten beide AES-Verschlüsselung (IBPhoenix AES128 und AES256, IBSurgeon nur AES256), allerdings zu einem stolzen Preis, zumindest wenn man das jeweilige Modul mit eigener Software ausliefern will: da braucht man jeweils die "unlimited" Version und ist bei IBPhoenix mit $2500 und bei IBSurgeon mit €2500 dabei...

[johndoe049]

Für den Preis kann man aber auch andere Datenbanken bekommen.
Sind wengistens Firmenanteile dabei?