Da ich glaube, das das Thema mittlerweile doch eher von der Verschlüsselung weggeht und mehr in Richtung Transaktionslog .
mal ein Beispiel aus der Praxis was wir da machen
1. In jeder Tabelle werden für alle Schreibvorgänge redo und undo sqls per trigger erzeugt und in einer selbsterstellten Transaktionslog gespeichert
-wenn es auf einer Tabelle einen Insert gab, dann wird genau dieser insert nur mit den eingefügten werten als redo
sql gespeichert und der passende delete als undo
-wenn es auf einer Tabelle einen delete gab, dann wird genau dieser delete als redo
sql gespeichert und der passende insert mit den letzten Werten als undo
-wenn es auf einer Tabelle einen update gab, dann wird genau dieser update mit den neuen Werten als redo
sql gespeichert und der update mit den vorherigen Werten als undo
-In Firebird lassen sich sclhe Trigger relativ einfach automatisiert erzeugen, wenn man mal das Prinzip verstanden hat und die new. und old. variablen liefern alles was man braucht
-zusätzlich steht im Transaktionslog ein zeitstempel, der datenbankuser, der das gemacht hat und seine Transaktions ID und ebenso seine Connection ID
2. Damit die Trigger, die in der gleich Transaktion laufen, zeitnah weggeschrieben werden können, landen die alle zunächst mal in einer Transaktionslogtabelle in der Produktions
DB
3. Damit diese Transaktionslogtabelle aber nicht die Produktionsdatenbank übertrieben aufbläht, werden die Transaktionslog Datensätze in einem eigenen serverbasierenden batch per execute statement on external in einer zweite Datenbank übertragen und danach in der Produktions
DB gelöscht. Auch das ist transaktionssicher.
4. Für diese Transaktionslog
DB kann du eine eigene Firebird Instanz auf einem anderen Server benutzen und der aus der ProduktionsDB schreibende User darf nur inserts, alles andere wird ihm verboten
5. Wenn du willst kann du in bestimmmten Zeiträumen die Transaktionslog
DB umbenennen, zB LOG2018.fdb, LOG2017.fdb usw. und diese DBs dann als Readonly
DB betreiben
6. Da im Transaktionlog neben den o.a. Daten auch Tabellenname und Primärschlüsselfeld in indizierten Feldern gespeichert werden, ist es exterm einfach, darüber alle SQLs zu finden, die zB die Rechnung mit PK 123 betroffen hat, auch wenn es diesen Datensatz aufgrund eines Deletes gar nicht mehr gibt (auch dieser delete mit daten wer das wann von wo gemacht hat steht im Log)
7. In der Realität hat diese Transaktionslog
DB mit Daten eine mittelständischen Produktionsbetriebs (60 MA) in 7 Jahren ca 600GB erreicht, es ist aber ausnahmslos jeder vorhandene Datensatz protokolliert.
8. durch die Undo SQLs konnten wir auch schon versehentlich gelöschte Datensätze mit sehr vielen abhängigen Daten durch ausruf einer simplen Prozedur rückgängig machen, diese Prozedur braucht nur Datum, connection ID und Transaktions ID und hat zu dieser Transaktion alle Befehle im Undo in umgekehrter Reihenfolge wieder ausgeführt.
9. Die Frage ist also, ob dein Kunde durch eine Datenbankverschlüsselung irgendwelche Vorteile im Falle einer Prüfung hat oder ob er auf basis der geschilderten Informationssammlung in den Transaktionslogs jede noch so abstruse Frage innerhalb kurzer Zeit beantwortet bekommen kann.
10. Es hindert dich keiner daran, die daten in der externe Transaktionslog
DB, die dort eingeführt werden, zusammen mit der Vorgänger Transaktionlogeintrag gemeinsam zu verschlüsseln und damit nichts anderes als eine sinnvolle Implementation einer Blockchain aufzubauen (falls ein vorgänger manipuliert würde, werden dieser und der Nachfolger einen anderen Verschlüsselungswert bekommen und dadurch ist der Zeitpunkt einer Manipulation im Transaktionslog nachvollziehbar, aber: Wenn der Inhaber des unternehmen mit dem Admin gemeinsam was verstecken will, dann geht das auch auf diesem Weg, ist aber wesentlich aufwändiger.
11. Die von dir geschilderten Urteile basieren ziemlich sicher auf einer Gastronomiesoftware, weil dort aufgrund des sehr hohen Anteils an Bareinnahmen ein ganz wichtiger Punkt der Kontrollierbarkeit fehlt. Derartige Entscheidungen haben nichts generelles mit Godb zu tun, weil es immer noch bewiesen werden muss, das beschissen wurde, glauben hilft den Prüfern da auch nicht.
In normalen Handelsunternehmen kann es aber ausreichen, das dem Prüfer aufgrund einer anderen Prüfung bei einem Geschäftspartner eine Rechnung vorliegt, die nicht mit den Daten in deiner Wawi übereinstimmt, weil der Sachbearbeiter die nach Versand an den Kunden nicht korrekt per Rechnungskorrektur und Neuerstellung angepasst hat, sondern einfach mit korrigierten Werten übergebügelt hat, der Geschäftspartner aber ncoh die alte Version in seinen Dokumenten hat. Wenn deine Software dann die Veränderungen aufgezeichnet hat bist du auf jeden Fall außen vor, ob der Kunde die dann falsch bedient hat oder bewusst damit bescheissen wollte, ist dann nicht dein Problem.
Wer aber mal mit einem Prüfer über ein Fahrtenbuch diskutiert hat, der weiß, wie schnell eine ganz banale Information aus den Daten dem Rest widerspricht (Beispiel: Laut Fahrtenbuch um 8 Uhr morgens zuhause losgefahren, aber um 9 Uhr in 300 km Entfernung getankt). Das du da evtl. die falsche Uhrzeit erfasst hast , weil deine Uhr falsch ging ist dem Prüfer egal, nach so was sucht er und dann gibt es nachträglich die 1% Regelung reingedrückt. Und auch in anderen Bereichen sind die Prüfer echt clever und suchen halt nach Mustern, die erfolg Versprechen, um Steuern nachzufordern.
ich merke aber, ich schweife ab, zurück zum Thema: Wenn dein Kunde nicht gerade eine Kneipe hat und sehr viele Bareinnahmen, dann treffen viele Faktoren aus allgemeinen Urteilen zu dem Thema gar nicht auf Ihn zu. Trotzdem hilft es dir als Softwarehersteller, die Fähigkeiten deiner Software generell schon drin zu haben, alles nachvollziehen zu können, was da in der Datenbank drin ist. Eine simple Verschlüsselung der Datenbank oder der Tabellen bringt dafür gar nix, in gelöschter Datensatz in einer verschlüsselten
DB ist immer noch weg und seine existenz kann auch nicht nachvollzogen werden, wenn der Admin mit im Boot ist.
Verschlüsselung bringt etwas, um zum Beispiel es deinem Außendienstler, der den kompletten Kundenstamm auf seinem Laptop dabei hat, schwerer zu machen, das er sich zusammen mit diesen Daten bei einem Mitbewerber um eine Stelle zu bewerben.
Das o.a. Beispiel läuft in anderen Prodjekten auch mit 2,5 Millionen Logeinträgen pro tag, die auf 160 Servern deutschlandweit erstellt werden und an 10 Server weiterverteilt werden müssen. Das setzt aber eine brauchbare für Firebird geeignete Hardware voraus, ist aber mit so eine Open Source Datenbank problemlos machbar, wenn man den richtigen fragt, wie es geht.