Datenbank mit Tabellenverschlüsselung benötigt.

**johndoe049**

Bernhard Geyer

Da steht folgender Hinweis:

Transparente Datenverschlüsselung und FILESTREAM-Daten

FILESTREAM-Daten werden nicht verschlüsselt, auch dann nicht, wenn TDE aktiviert ist.

Bei der anderen Methode Allways encrypted sind folgende Hinweise

Die Entschlüsselung findet über den Client statt. Das bedeutet, dass einige Aktionen, die nur serverseitig auftreten, nicht funktionieren, wenn Always Encrypted verwendet wird

Führen Sie folgende Schritte durch, um die Spalte erfolgreich zu aktualisieren:

Wählen Sie über die Anweisung SELECT die Datei aus der SSN-Spalte aus, und speichern Sie diese in einem Resultset in der Anwendung. Dadurch kann die Anwendung (Clienttreiber) die Spalte entschlüsseln.
Fügen Sie über INSERT die Daten aus dem Resultset in SQL Server ein.

Super bei Massenänderungen, wie z.B. Preisstufen in Artikeln. Alles über das Netzwerk kopieren.
Weiters ist auch noch aufgeschrieben. Macht die Arbeit mit einem SQL Server nicht so wirklich sinnig. Aber egal, wenns gefordert wird.

**Delphi.Narium**

Zitat von Uwe Raabe:

Zitat von Delphi.Narium:

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.

Aber wie soll den hier jetzt eine Verschlüsselung der Datenbank helfen?

Es geht doch letztlich darum, dass "irgendwer" an der Software vorbei, was in der Datenbank ändert. Man muss also sicherstellen, dass nur mit Hilfe der vorgesehenen Software auf die Datenbank zugegriffen wird und nur mit ihr Änderungen vorgenommen werden.

Also muss man sicherstellen, dass mit Hilfe dieser Software alle Arbeiten erledigt werden können, die für die korrekte Arbeit erforderlich sind. Also z. B. auch das Anlegen und / oder Löschen von Datenbankusern ... Dann kann man ggfls. den DB Administrator "aussperren", wenn man softwareseitig für einen adäquaten Ersatz gesorgt hat.

Aber das jetzt hier alles aufzuführen dürfte den Sinn der ursprünglichen Fragestellung deutlich überschreiten.

Zitat von Bernhard Geyer:

Am besten einmal einlesen:

https://docs.microsoft.com/de-de/sql...ql-server-2017

Sowas in der Art meinte ich mit datenbankseitiger Verschlüsselung.

Zitat von johndoe049:

Super bei Massenänderungen, wie z.B. Preisstufen in Artikeln. Alles über das Netzwerk kopieren.
Weiters ist auch noch aufgeschrieben. Macht die Arbeit mit einem SQL Server nicht so wirklich sinnig. Aber egal, wenns gefordert wird.

Irgendwie erscheint mir das bestenfalls suboptimal

**johndoe049**

Datenbankverschlüsselung macht nur dann einen Sinn, wenn das Passwort für die Entschlüsselung nur in der Anwendung vorhanden ist und nicht dem Administrator beim Kunden gegeben wird.

Entsprechende Konfiguration vom Datenbankserver beim Kunden kann man auch vergessen. Es wird nur die Standartinstallation ohne Anpassungen bzw. nachträglichem Aussperren vom Administrator geprüft.

Lt. Auditor wird so geprüft, als ob jemand ohne viel Kenntnisse den Datenbankserver installiert und die Anwendung. Dann wird geprüft, ob in dieser Konstellation der DB Administrator an den Testdaten Änderungen machen kann, die nicht protkoliert sind und man den vorherigen Informationsstand wiederherstellen kann.

Wäre letztes nicht Prüfungsobjekt, würde ich einfach alle Datensätze signieren und Aus die Maus.

Reicht aber lt. Vorgaben nicht mehr aus, weil man muss ja nachvollziehen können, was vor der Änderung in der Zeile stand.

Was alles im Bezug auf Datenbanken einzuhalten ist, wurde mir von einem der Auditoren als zweiseitiges Dokument vorgelegt. Rechtsvorgaben wurden aufgeführt, jedoch nicht mitgegeben, da dies einiges mehr an Text ist.

Kurz zusammengefasst: siehe meine Ursprungsfrage.

**Bernhard Geyer**

Zitat von johndoe049:

Transparente Datenverschlüsselung und FILESTREAM-Daten

FILESTREAM-Daten werden nicht verschlüsselt, auch dann nicht, wenn TDE aktiviert ist.

Dann nimm halt keine FILESTREAM-Daten. Musst du ja nicht.
Ich denke der Großteil der MS SQL-Server-Datenbanken nutzt keine FILESTREAMs

Zitat von johndoe049:

Bei der anderen Methode <encrypted sind folgende Hinweise

Kann sein das da was anderes steht. Aber ich meint ja nur "Transparente Datenverschlüsselung (TDE)"

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