Datenbank mit Tabellenverschlüsselung benötigt.

**johndoe049**

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.

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.

**Frickler**

Zitat von johndoe049:

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.

Die GoBD verlangt in der Tat, dass alle Änderungen nachvollziehbar sein sollen. Was die Sache jetzt verschäft, ist vermutlich ein Urteil des FG Münster aus dem Jahr 2017. Da stellte ein Gutachter fest: "Es ist kein Grund ersichtlich, warum im Hinblick auf die durch ein System eröffneten Manipulationsmöglichkeiten zwischen solchen, die durch einen „normalen“ Anwender und solchen, die nur durch einen (vom Steuerpflichtigen beauftragten) IT-Spezialisten vorgenommen werden können, unterschieden werden sollte.". Mit anderen Worten: ist eine buchhalterisch relevante Software (im Fall von 2017 eine Kasse) mit welchem Aufwand auch immer theoretisch spurlos manipulierbar, dann darf der Prüfer hinzuschätzen.

**johndoe049**

Na toll.

Jetzt macht es für mich auch mehr Sinn, warum beim Audit das auch für die Warenwirtschaft gefordert wird.

Rechnungen, Lagerbewegungen, etc. Alles Daten, die irgendwie was mit Steuern zu tun haben.

Das dürfte noch lustig werden. Ich sollte eigentlich denen nur eine Software für die Kalkulation und Kalkulationsvergleiche erstellen, da dies im Moment noch schön einzeln in Excel Tabellen vorgenommen wird. Mal sehen, ob das auch im Audit bei denen Bemängelt wird.

Gibt es für das Urteil ein Aktenzeichen? Würde mal gerne nachlesen, was da so vom Gutachter ausgesprochen wurde. Dann kann man sich eher darauf einstellen, was notwendig wird.

**Uwe Raabe**

Zitat von Frickler:

Mit anderen Worten: ist eine buchhalterisch relevante Software (im Fall von 2017 eine Kasse) mit welchem Aufwand auch immer theoretisch spurlos manipulierbar, dann darf der Prüfer hinzuschätzen.

Wenn der nötige Aufwand nach oben unbegrenzt ist, dann wäre das aber wohl immer der Fall, oder? Es gibt immer einen Weg der theoretisch spurlosen Manipulation. Nur wird irgendwann der Aufwand größer als der erreichbare Nutzen.

**IBExpert**

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.

**johndoe049**

Hört sich interessant an.

Kann vermieden werden, dass ein DB Administrator den Trigger zeitweise deaktiviert oder löscht?

Anderen Server, weil das Transaktionsprotokoll gross wird dürfte kein Problem sein. Im Bereich von Hardwareresourcen ist der sehr spendabel.

Firebird hatte ich bisher nicht auf dem Radar. Ich hatte nur mal vor Jahren eine Anwendung als Demo gesehen, wo die fdb automatisch in viele kleine fdb Dateien aufgeteilt wurde. Sollte das Backup vereinfachen. Ist das Standart oder eine Eigenkreation?

Gibt es bei Firebird eine gute Dokumentation zum runterladen oder eine Buchempfehlung?

Wenn wir schon beim "Abschweifen" sind: Wie gut kann Firebird mit Blob Feldern umgehen? Gibt es da Geschwindigkeitsprobleme, wenn viele Blob Daten vorhanden sind? So ca. 80 % Datenbankanteil.

**mkinzler**

Zitat von johndoe049:

Hört sich interessant an.

Zitat:

Kann vermieden werden, dass ein DB Administrator den Trigger zeitweise deaktiviert oder löscht?

Wenn der (Administrator-)Benutzer nicht Eigentümer der Tabelle ist, ja.

Anderen Server, weil das Transaktionsprotokoll gross wird dürfte kein Problem sein. Im Bereich von Hardwareresourcen ist der sehr spendabel.

Zitat:

Firebird hatte ich bisher nicht auf dem Radar. Ich hatte nur mal vor Jahren eine Anwendung als Demo gesehen, wo die fdb automatisch in viele kleine fdb Dateien aufgeteilt wurde. Sollte das Backup vereinfachen. Ist das Standart oder eine Eigenkreation?

Ist nicht der Standard ist aber möglich. Richtige Tabelspaces unterstützt aber FireBird (noch) nicht. Ist/war für FireBird 4.0 geplant wird aber noch diskutiert.

Zitat:

Gibt es bei Firebird eine gute Dokumentation zum runterladen oder eine Buchempfehlung?

Das ist eine "kleine" Archillesferse von FireBird. Es gibt zwar vieles aber nicht so viel/geballt wie für andere Systeme.
Das ändert sich hoffentlich aber noch ( möglicherweise durch die Integration in LibreOffice).
Wenn wir schon beim "Abschweifen" sind: Wie gut kann Firebird mit Blob Feldern umgehen? Gibt es da Geschwindigkeitsprobleme, wenn viele Blob Daten vorhanden sind? So ca. 80 % Datenbankanteil.

FireBird kann Blobs getrennt von den restlichen Feldern einer Tabelle Speichern. Bei größeren Blobs steht dann in der Tabelle nur ein Verweis auf die Daten.

**IBExpert**

Zitat von johndoe049:

Hört sich interessant an.
Kann vermieden werden, dass ein DB Administrator den Trigger zeitweise deaktiviert oder löscht?

Ab Firebeird 3.0 gibt es Trigger auf DDL, also kann selbst ein ALTER TRIGGER getriggert werden. Wenn diese Trigger per EXECUTE STATEMENT ON EXTERNAL das ebenfalls in eine externe Datenbak schreiben und ein Datenbanktrigger ggf. vorher schon Anmeldungen auf der DB restriktiv halten, d.h. nur von bestimmmte IP Adresse erlauben oder andere Tricks erfordert (vor dem ersten commit bestimmte Werte in global Temp Tables oder Session variablen zu setzen, dann müsste der Admin schon extrem gutes Firebird Know haben um daran vorbei zu kommen und nicht sofort eine externe spur hinterlassen zu haben. Wenn man dem so mißtraut, dann sollte man sich lieber andere Mitarbeiter suchen ...

Trotzdem haben wir für Kunden auch spezielle Firebird Versionen erstellt, die das Abschalten der Datenbanktrigger deaktiviert, der Kunde mißtraute dabei nur einem ehemaligen Mitarbeiter, der sich mit einer Software in der selben Branche selbstständig gemacht hat und mit seinem InsiderknowHow fleissig Bestandskunden abgeworben hat und bis zu diesem Zeitpunkt beim Datenimport keine Restriktionen hatte. Dort wird aber demnächst die Database Encryption eingeführt, dann kann er das eh vergessen.

Zitat von johndoe049:

Anderen Server, weil das Transaktionsprotokoll gross wird dürfte kein Problem sein. Im Bereich von Hardwareresourcen ist der sehr spendabel.

Falls es bei Firebird landen wird, melde dich gerne bei uns, wir bauen spezielle Firebird Server, die für das manchmal sehr spezielle Verhalten von Firbeird I/O Operationen optimiert sind. Die sind für ca. 4000 € pro Server sehr nach am Optimum mit Firebird und haben andere Kundenserver für teilweise 30-40k € deutlich hinter sich gelassen beim Firebird Speed. Weil ein Server für andere Datenbanksoftware gut ist, muss der noch lange nicht mit Firebird gut sein.

Zitat von johndoe049:

Firebird hatte ich bisher nicht auf dem Radar. Ich hatte nur mal vor Jahren eine Anwendung als Demo gesehen, wo die fdb automatisch in viele kleine fdb Dateien aufgeteilt wurde. Sollte das Backup vereinfachen. Ist das Standart oder eine Eigenkreation?

Du sprichst vermutlich von secondary files, das war im zeitalter von FAT32 hilfreich, um Datenbank größer 2GB zu benutzen, ist aber momentan nicht erforderlich (obwohl bei NTFS glaub ich das Limit pro Datei aktuell 64TB ist, d.h ab einer DB Größe von 64TB auf Windows kannst du es wieder benutzen

Zitat von johndoe049:

Gibt es bei Firebird eine gute Dokumentation zum runterladen oder eine Buchempfehlung?

Bücher sind selten geworden, ist halt kein Produkt mehr wofür jemand Geld bezahlt
Trotzdem sind die Sachen von Helen Borrie lesenswert, auch wenn die in erster Linie
FB25 fokussieren, über die Releasenotes PDF in jeder Version kommt man schnell in
das rein, was neu und wichtig ist

https://www.ibphoenix.com/products/books/firebird_book

https://firebirdsql.org/en/books/

Außerdem sind hier auch Referenz Dokus und Quickstart Guides

https://firebirdsql.org/en/reference-manuals/

Zitat von johndoe049:

Wenn wir schon beim "Abschweifen" sind: Wie gut kann Firebird mit Blob Feldern umgehen? Gibt es da Geschwindigkeitsprobleme, wenn viele Blob Daten vorhanden sind? So ca. 80 % Datenbankanteil.

Nein, es gab sogar diverse Tests, die sogar festgestellt haben, das Firebird das wesentlich besser macht als das gern überschätzte Filesystem

http://blog.plasticscm.com/2008/09/f...ystem-for.html

Wie toll das Filesystem insbesondere unter Windows ist: Leg einfach mal 10 Millionen Datensätze in einem ordner an und versuche dann mit Bordmitteln wie explorer.exe eine davon zu löschen, viel spaß dabei für die nächsten Tage Wartezeit ...

Das Erstellen eigener Tabellen für Blobs wie von Markus empfohlen machen wir immer so, wenn es sich dabei um zB Bilder und PDFs handelt, Memos oder kleinerer Kram aber eher nicht, weil
Firebird kleinere Blobs inhalte anders speichert.

Ein Referenzkunde (sehr großes Patentanwaltsbüro) speichert ca 2TB als PDFs in einer Datenbank. Die größte DB, von der ich vonanderen Kunden gehört habe, kommt aus dem Medizinumfeld und soll 15TB sein.

Mit ganz simple Techniken (abruf der pdf Inhalte nicht direkt per select auf Tabelle, sondern immer per Stored Proc) kannst du mit eingebauten Techniken die PDFs ähnlich wie das oben erwähnte Transaktionslog jahreweise in eigene Readonly Datenbanken auslagern und deinen AbrufSP sucht passend zu den Metadaten des Datensatzes dann die passende DB raus. Damit haben wir bei dem oben genannten Kunden ca 2 Millionen odfs im ca 500GB Datenbanken abgelegt, brauchen beim täglichen Backup aber nur ca 20GB sichern und nicht 500GB, weil davon ca 490GB monatsweise ausgelagert sind.

Diese PDF Archivdatenbanken können auch wieder ausgeagert sein, Kopien in der Cloub haben, bei High End Userzahlen auf replizierten Servern liegen etc.

Im Oktober ist in Berlin eine Firebird Konferenz, da sind wir auch wieder dabei, wenn Leute vorher Lust auf eine öffentliche Schulung zu der Thematik haben, meldet euch einfach bei mir oder über info@ibexpert.de mit dem Betreff "Interesse öffentliche Firebird Schulung", ggf. koordinieren wir dann wieder mal eine Schulung zu dem Thema, gerne auch z.b. in Frankfurt, was für die meisten ja ganz gut erreichbar sein sollte.

**Dumpfbacke**

Zitat von IBExpert:

Ein Referenzkunde (sehr großes Patentanwaltsbüro) speichert ca 2TB als PDFs in einer Datenbank. Die größte DB, von der ich vonanderen Kunden gehört habe, kommt aus dem Medizinumfeld und soll 15TB sein.

Mit ganz simple Techniken (abruf der pdf Inhalte nicht direkt per select auf Tabelle, sondern immer per Stored Proc) kannst du mit eingebauten Techniken die PDFs ähnlich wie das oben erwähnte Transaktionslog jahreweise in eigene Readonly Datenbanken auslagern und deinen AbrufSP sucht passend zu den Metadaten des Datensatzes dann die passende DB raus. Damit haben wir bei dem oben genannten Kunden ca 2 Millionen odfs im ca 500GB Datenbanken abgelegt, brauchen beim täglichen Backup aber nur ca 20GB sichern und nicht 500GB, weil davon ca 490GB monatsweise ausgelagert sind.

Diese PDF Archivdatenbanken können auch wieder ausgeagert sein, Kopien in der Cloub haben, bei High End Userzahlen auf replizierten Servern liegen etc.

So etwas wollte ich auch schon mal machen. Hast du hier eventuell etwas Code für für mich ? Also wie bekomme ich eine PDF Datei in die Datenbank rein und wie bekomme ich die PDF dann heraus und kann die Datei Anzeigen un doder speichern ? Was ist den der Vorteil von einer Stored Proc und wie würde die Dann aussehen ?

Danke schon einmal Tanja.

**Frickler**

Zitat von Uwe Raabe:

Zitat von Frickler:

Mit anderen Worten: ist eine buchhalterisch relevante Software (im Fall von 2017 eine Kasse) mit welchem Aufwand auch immer theoretisch spurlos manipulierbar, dann darf der Prüfer hinzuschätzen.

Wenn der nötige Aufwand nach oben unbegrenzt ist, dann wäre das aber wohl immer der Fall, oder? Es gibt immer einen Weg der theoretisch spurlosen Manipulation. Nur wird irgendwann der Aufwand größer als der erreichbare Nutzen.

Beim konkreten

Urteil ging es um eine Kassensoftware in Access. Da ist die Manipulationshürde gar nicht mal so hoch. Von Kommentatoren wird das Urteil aber allgemein so verstanden, dass die Datenbank egal ist. Und dass nicht nur Kassen betroffen sind. Das hat vermutlich der erwähnte Auditor so verstanden.

--
P.S.: Eine vollverschlüsselte Firebird-Kassendatenbank kann man aber auch überlisten: morgens den Server anhalten, eine Kopie ziehen, dann kommt die Hochzeitsgesellschaft und den ganzen Vormittag wird kassiert. Z-Bon drucken, die Datenbank zurückspielen und das Geld in die Tasche stecken