Datenbank mit Tabellenverschlüsselung benötigt.

[Klaus01]

Zitat:

Zitat von johndoe049 (Beitrag 1431961)

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

[johndoe049]

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

[mkinzler]

Zitat:

Zitat von Frickler (Beitrag 1431962)

Zitat:

Zitat von IBExpert (Beitrag 1431951)

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...

FireBird bietet die Schnittstelle und keine feste Implementierung wie bei anderen DBMS. Als Beispiel wird der Source für ein einfache "Verschlüsselung" mitgeliefert.

https://firebirdsql.org/file/documen...ncryption.html
https://github.com/FirebirdSQL/fireb...amples/dbcrypt

[Delphi.Narium]

Zitat:

Zitat von johndoe049 (Beitrag 1431961)

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:

Zitat von johndoe049 (Beitrag 1431961)

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 ;-))

[Bernhard Geyer]

Zitat:

Zitat von Frickler (Beitrag 1431962)

... 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...

Was manche unter stolzer Preis ansehen, verursacht bei anderen Anbietern nur ein Müdes lächern...

Schau dir mal die Preise für eine EE-Edition von Oracle an, die du hier benötigen würdest.
Locker mal 47 k$ pro Prozessor ....

[Bernhard Geyer]

Zitat:

Zitat von Delphi.Narium (Beitrag 1431969)

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.

Ob man das so korrekt hinbekommt.
Er ist ja für die Betreung zuständig, wenn er aber nix mehr darf.
Wie steht es mit Backup?
Wie mit evtl. nötigen Optimierungsmaßnahmen?
Wie mit Zuweisen von Bereichtigungen für andere User...
Ein solche Szenario müsste man als DB-Admin ablehnen.

Zitat:

Zitat von Delphi.Narium (Beitrag 1431969)

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.

Wie kommt du darauf das der Admin das sieht? Solange er das Verschlüsselungs-PW nicht kennt (was ja irgenwie gesichert im Kontext der Anwendung liegt) sieht er auf DB-Ebene nix.
Auch ein Hex-Editor bringt nur Byte-Salat.

[Delphi.Narium]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1431971)

Zitat:

Zitat von Delphi.Narium (Beitrag 1431969)

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.

Ob man das so korrekt hinbekommt.
Er ist ja für die Betreung zuständig, wenn er aber nix mehr darf.
Wie steht es mit Backup?
Wie mit evtl. nötigen Optimierungsmaßnahmen?
Wie mit Zuweisen von Bereichtigungen für andere User...
Ein solche Szenario müsste man als DB-Admin ablehnen.

Zitat:

Zitat von Delphi.Narium (Beitrag 1431969)

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.

Wie kommt du darauf das der Admin das sieht? Solange er das Verschlüsselungs-PW nicht kennt (was ja irgenwie gesichert im Kontext der Anwendung liegt) sieht er auf DB-Ebene nix.
Auch ein Hex-Editor bringt nur Byte-Salat.

Wenn die Datenbank selbst verschlüsselt, muss dann jeder Nutzer das Passwort eingeben (bzw. die Software) oder ist die Verschlüsselung ein Teil der Datenbankfunktionalität?

Hier müssten wir mal klären, was wir genau unter datenbankseitiger Verschlüsselung verstehen. Ich bin bisher davon ausgegangen, dass sie für alle Anwender transparent ist, also die Daten von der Datenbank selbst verschlüsselt in der Datenbankdatei abgelegt werden, aber bei der Auslieferung an den Anwender, unabhängig von der genutzten Software, unverschlüsselt von der Datenbank ausgegeben werden (ohne irgendeine extra Passworteingabe. Ok, eventuell eine etwas naive Ansicht ;-))

Wenn softwareseitig verschlüsselt wird, muss der DB Administrator natürlich das Passwort zum Entschlüsseln kennen, aber ob ihm das beim Anzeigen der Daten über irgendeine Datenbankoberfläche hilft, wage ich zu bezweifeln.
Wenn softwareseitig verschlüsselt wird, muss jede Software, mit der die Daten angezeigt werden können, die entsprechende Funktionalität zur Entschlüsselung (ggfls. nach Passworteingabe) mitbringen, das ist eher unwahrscheinlich.

Wenn man dem DB Administrator die Rechte auf einige Tabellen entzieht, wird sein Arbeit sicherlich eingeschränkt werden. Aber für ein Backup benötigt er nicht auf alle Tabellen Lese ... rechte. Er muss nur das Recht haben, ein Backup und ggfls. ein Restore machen zu dürfen. Dies ist unabhängig von den Rechten auf einzelne Tabellen.

Und natürlich: Rechtevergabe durch den DB Administartor scheidet dann aus oder ist nur eingeschränkt möglich. Optimierungen, naja, eher schwierig.

Zitat:

Ein solche Szenario müsste man als DB-Admin ablehnen.

Uneingeschränk: ja!!!

[Bernhard Geyer]

Zitat:

Zitat von Delphi.Narium (Beitrag 1431972)

Wenn die Datenbank selbst verschlüsselt, muss dann jeder Nutzer das Passwort eingeben (bzw. die Software) oder ist die Verschlüsselung ein Teil der Datenbankfunktionalität?

Hier müssten wir mal klären, was wir genau unter datenbankseitiger Verschlüsselung verstehen. Ich bin bisher davon ausgegangen, dass sie für alle Anwender transparent ist, also die Daten von der Datenbank selbst verschlüsselt in der Datenbankdatei abgelegt werden, aber bei der Auslieferung an den Anwender, unabhängig von der genutzten Software, unverschlüsselt von der Datenbank ausgegeben werden (ohne irgendeine extra Passworteingabe. Ok, eventuell eine etwas naive Ansicht ;-))

Am besten einmal einlesen:
https://docs.microsoft.com/de-de/sql...ql-server-2017

[johndoe049]

Zitat:

Zitat von Delphi.Narium (Beitrag 1431969)

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.
...

Es gibt keinen Arbeitgeber. Es ist eine ganz normale Kundenanfrage für eine Auftragsarbeit. Entwickeln einer Warenwirtschaft mit den entsprechenden Vorgaben.

Es geht einfach gesprochen darum, dass man entweder Datenänderungen durch einen DB Administrator nachvollziehen, d.h. loggen kann. Direkt über den Datenbankserver. Ist dies nicht möglich, darf der DB Administrator keinen direkten Zugriff auf die Daten haben und diese nicht ändern können.

Arbeitsverträge, etc. sind an sich eine schöne Sache. Lt. dem Auditor verlangt das Steuerrecht jedoch eine technische Lösung. Keine vertragliche. Es sollen auch keine Änderungen möglich sein über Backup + Restore in anderem Datenbankserver und Ändern + Backup + Restore zurück zum richtigen Datenbankserver. Theorie dahinter (Lt. Auditor): Auch wenn sich ein DB Administrator nicht an den Vertrag hält, muss man die Änderung, etc. nachvollziehen können. Ich lasse das jetzt mal so stehen und kommentiere das nicht. :zwinker:

Wegen dem technischen Ansatz: Man geht davon aus, dass der Firmenintere Admin selbst den Datenbanksrver installiert, verwaltet und dass es nur einen Admin für alles gibt. Wie in vielen kleinen Firmen üblich.

[Uwe Raabe]

Zitat:

Zitat von Delphi.Narium (Beitrag 1431969)

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?

Es geht wohl nicht darum, daß der DB-Admin die Änderungen nachvollziehen kann, sondern daß der Steuerprüfer auch die Änderungen nachvollziehen kann, die vom DB-Admin direkt auf der Datenbank gemacht wurden.