Datenbank mit Tabellenverschlüsselung benötigt.

[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

[jobo]

Hab den Thread überflogen. Worum geht es am Ende? Verschlüsselung wegen Geheimniswahrung oder Nachvollziehbarkeit?
Verschlüsselungsprobleme und Folgeeffekte (Nutzungseinschränkung) gibt es natürlich, wenn man jeder Spalte verschlüsselt. Das ist selbst bei Geheimniswahrung aber nicht notwendig. Es gibt idR. ein Modell und Nutzdaten, letztere müssen wahrscheinlich auch nur teilweise verschlüsselt werden.

Wenn es "nur" um Nachvollziehbarkeit geht, müsste eine einzige Spalte diese garantieren (bzw. ein einziger Mechanismus, transaktionsbasiert, wie hier auch schon beschrieben), z.B. durch eine Signatur mit Zertifikat. Hab das praktisch noch nicht gemacht, aber es müsste einen Appserver geben, der "als letzter" einen Datensatz signiert. Dabei müsste er einen Rückgabewert über diesen Vorgang erhalten, den er bei der nächsten Signatur mit dem Vorgängersatz vergleicht, um Backup Hacks zu unterbinden.
Referentielle Integrität und Constraints allgemein sind ja Grundfunktionen von ACID Datenbanken und bilden die beste Ausgangsbasis für solche Mechanismen.

Ansonsten gibt es auch fertig Software wie schon angeklungen.
Oracle bietet diverse Sachen an, z.B. Audit Vault, das gleich die Analyse der Audits mitliefert. Wahrscheinlich gibt es das auch kleinteiliger ohne das Endprodukt.

Und ja, es kostet, weiß nicht, was diese Punkte immer sollen. Oder arbeitet hier jemand umsonst für seine Kunden? Spätestens für nicht triviale Anforderungen muss ein Kunde am Ende vielleicht etwas tiefer in die Tasche greifen. Die Problematik des Aufwands für eine "wasserdichte" Lösung wurde ja bereits angesprochen.

[IBExpert]

Zitat von Frickler:

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

ja, dafür muss aber der Inhaber und ggf der Programmierer zusammenarbeiten und das überhaupt ermöglichen, bei einer Kassensoftware im Kiosk Mode ist das nicht so banal, wenn der Entwickler das nicht völlig daneben umgesetzt hat. Und richtig blöd wird es, wenn dein Hochzeitspaar dann am ende einen Beleg haben will und per Karte zahlen möchte.

Wer übrigens kein Bock auf Steuerbescheisser in der Gastronomie hat, ganz einfacher Tip: niemals bar, immer nach Beleg fragen und per karte zahlen, dann wird es schwierig, für den Gastronomen die Einnahmen vor der Steuer zu verstecken.

p.s.: Und wenn der Wirt dann behauptet, das sein Kartenlesegerät leider gerade jetzt nicht funktioniert, dann sagen, das man kein Bargeld hat, aber den Betrag auch gerne überweisen kann. Man glaubt gar nicht wie viele Kartenlesegeräte sich danach wieder ganz spontan selbst geheilt haben ...

[mkinzler]

Zitat:

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.

Ich hatte eigentlich nicht vorgeschlagen, eigene Tabellen hierfür zu nehmen (schadet natürlich nicht). Firebird entscheidet ja selber ob in der Tabelle die Daten selber oder nur eine Verweis (Blobpointer) auf die eigentlichen Daten steht (diese werden dann in einem anderen Bereich der Datenbank unabhängig gespeichert).

[IBExpert]

Zitat von mkinzler:

Ich hatte eigentlich nicht vorgeschlagen, eigene Tabellen hierfür zu nehmen (schadet natürlich nicht). Firebird entscheidet ja selber ob in der Tabelle die Daten selber oder nur eine Verweis (Blobpointer) auf die eigentlichen Daten steht (diese werden dann in einem anderen Bereich der Datenbank unabhängig gespeichert).

Stimmt, da hatte ich deinem Satz wohl ein paar hinzu gemogelt, ist aber im Prinzip fast egal, dann eben nur ich und nicht du

ich mach das mittlerweile fast immer so, das große Inhalte wie pdf, jpg, png usw. in einer extra Tabelle sind und diese Inhalte sich eben auf verschiedene Datenbanken oder sogar Serverinstanzen verteilen, weil Terabyte DB immer normaler wird mit solchen Inhalten und das am Ende das zentrale Handling dadurch vereinfacht wird, wenn das nicht auf dutzenden Tabellen verteilt ist