Welche Datenbank für Kassensoftware

[jaenicke]

Was man an der Stelle nicht vergessen darf:
Auch Stammdatenänderungen müssen protokolliert werden. Wenn die Datenbank zu leicht manuell änderbar ist, dürfte das schwierig werden. Mindestens ein Login sollte daher notwendig sein.

Von daher macht eine Verschlüsselung schon Sinn, auch wenn sie gesetzlich nicht gefordert ist.

[mkinzler]

Aber eine (nachvollziehbare) Unveränderlichkeit erhält man nur durch die TSE. Eine (Datenbank-)Verschlüssselung erschwert eine Manipulation aber erheblich und ist auf jeden Fall sinnvoll.

[Daniel]

Selbstverständlich ist das eine der zentralen Eigenschaften der TSE - aber ich werde doch nicht sämtliche Kassen-Stammdaten in die TSE stopfen ? Aus meiner Sicht braucht es etwas, das parallel zur TSE liegt.

[mkinzler]

Zitat von Daniel:

Selbstverständlich ist das eine der zentralen Eigenschaften der TSE - aber ich werde doch nicht sämtliche Kassen-Stammdaten in die TSE stopfen ? Aus meiner Sicht braucht es etwas, das parallel zur TSE liegt.

Ich bin absolut bei Dir.

In der Grundfrage ging es aber um die vorgeschriebene Unveränderlichkeit

Zitat:

Nun heißt es ja, Daten dürften nicht veränderbar sein. Ich frage mich aber, wie man das realistisch gesehen überhaupt umsetzen soll.

[TigerLilly]

Zitat:

Bin hier unsicher. Und so wirklich beantworten kann oder will die Frage niemand. Das Finanzamt sagt, man "kann" solche Fragen nicht beantworten. Steuerberater und Rechtsanwälte sagen, man wisse es nicht. Beim Bundesministerium der Finanzen kommt die Aussage, man sei für diese Frage nicht zuständig. Obwohl diese Regelung von denen kommt?

Das ist bis jetzt ein bisschen untergegangen. Der Gesetzgeber sagt nie, WIE etwas technisch umzusetzen ist, er formuliert allgemeine Anforderungen, die man dann nach dem "Stand der Technik" umzusetzen hat. Achtung: Von den „allgemein anerkannten Regeln der Technik“ unterscheidet sich der „Stand der Technik“ dadurch, dass er in der Praxis (noch!) nicht allgemein angewendet wird. Der "Stand von Wissenschaft und Technik": Er stellt die höchste Stufe dar und umfasst die jeweils neuesten Erkenntnisse.

Anders formuliert: Das, was fast alle (jetzt schon) machen, ist (für etwas Neues) in der Regel zu wenig.

[himitsu]

Zitat von Daniel:

Das liest sich mittlerweile fast so, als wäre es anrüchig, eine Datenbank verschlüsseln zu wollen. Dafür kann es viele Gründe geben und keiner davon muss euch genannt werden.

Schlimm ist sowas bestimmt nicht.
Die Verschlüsselung würde "ich" aber nur als Schutz Hinternis zum Auslesen sehen. Und weniger als Schutz Hinternis vor Veränderungen.

Schutz vor Veränderung bietet es nur so weit, dass wenn jemand das Kennwort/Schlüssel kennt/rausbekommt, er/sie die Datenbank öffnen und problemlos verändern könnte.

Zitat:

Nun heißt es ja, Daten dürften nicht veränderbar sein. Ich frage mich aber, wie man das realistisch gesehen überhaupt umsetzen soll.

Nunja, es gibt physikalishe WriteOnce-Speicher, die sind per se unveränderlich.
Eine CD/DVD-R liese sich stückchenweise beschreiben. oder auch ein PROM-Chip wäre sowas.
Bei größeren Speichern sind es meistens SD-Karten und Festplatten mit veränderter Firmware.

Im Falle der TSE kommen "normale" SD-Karten/Festplatten zum Einsatz, die quasi in der Firmeware vor Veränderung "geschützt" sind.
Praktisch ein "gekapselter" kleiner Computer, der über seine Schnittstelle keine Änderung zulässt. (nur schreiben, auslesen, aber nicht überschreiben ... dass dann vielleicht noch verschlüsselt)

Klar, kann man sowas auch mit einer Datenbank machen und selbst ohne Verschlüsselung.

Eine Lösung wäre z.B. eine Blockchain.
Da werden die Datensätze signiert (ein prüfbarer asymmetrisch verschlüsselter Hash) und die der Signatur des/der Vorgänger integriert, wodurch man Veränderungen erkennen würde, da dann die vorhergegenden/nachfolgenden Signaturen nicht mehr stimmen.
Die Signatur sollte besser (ganz/teilweise) mit zum angezeigten Datensatz gehören, z.B. als ID auf dem Kassenbon gedruckt. (sonst könnte jemand auf die Idee kommen nach dem Ändern der Daten "einfach" alle Signaturen neu zu berechnen)
"einfach": Hier greift die Blockchain, z.B. bei den Cryptowährungen ala Bitcoin, mit einer stärkeren Verschlüsselung ein. Die ist einfach nur so "aufwändig"/ineffizient gebaut, dass die Berechung viel Zeit braucht und so das Fälschen/Neuberechnen erschwert wird. Außerdem ist dort die Blockchain als mehrfache Kopie frei in der Wildnis verteilt, damit man dort etwas hat, um Gegenzuprüfen.

Zitat von Daniel:

Das liest sich mittlerweile fast so, als wäre es anrüchig, eine Datenbank verschlüsseln zu wollen. Dafür kann es viele Gründe geben und keiner davon muss euch genannt werden.
Und nein, eine TSE lässt sich nicht selber entwickeln. Ich habe auch nicht herausgelesen dass dies auch nur ansatzweise geplant sei. Ich weiß nicht, warum ihm das jetzt unterstellt werden muss.

Sorry, es klang halt ansatzweise schon etwas danach, als wenn er selbst eine "ähnliche" Lösung für seine "Kassensoftware" bauen wöllte.

Im Falle einer eigenen Entwicklung müsste man dass dann wohl noch zertifizieren lassen, damit es rechtssicher als "zertifizierte technische Sicherheitseinrichtung" (TSE) genutzt werden könnte.
Drum kaufen ja die Meisten eine fertige TSE, um sich selbst nicht damit beschäftigen zu müssen.

[IBExpert]

vielleicht muss man noch mal unterscheiden, was die Motivation für Encrypted DB ist!

Wenn das jemand machen will, weil er meint, das irgendeine externe Instanz (wie zum Beispiel
das Finanzamt) dafür seinen Segen erteilt und dann alles toll findet, was auf dem Wege
gemacht wurde, ist sowieso auf einem völlig falschen Weg.

Auch wenn Hardwarehersteller das vor Jahren immer gerne behauptet haben, es gab niemals
einen Gesetzestext, in dem drin steht, das man seine Sicherung auf einer bestimmten
Technik machen muss.

In vielen Bereichen, zum Beispiel bei der Nutzung von Kartenmaterial für Piloten steht
auch nicht drin, das man die auf Papier dabei haben muss, auch wenn diverse fluglehrer
dazu immer wieder ihr Halbwissen selbstbewusst verbreiten.

Es wird wie schon von anderen hier erwähnt immer medienneutral formuliert.

Ob irgendwas am Ende geeignet ist, ergibt sich nicht pauschal durch Nutzung einer
bestimmten Technik. Wenn du deine Karten als Pilot auf einem ipad in aktueller Version
digital dabei hast, dann ist das absolut ok, es sei denn, dein Akku ist alle und du
hast kein Backup, wenn dich ein Heini von der Bezirksregierung mal persönlich
sprechen will, nachdem du vielleicht irgendwo geflogen bist, wo du
nichts zu suchen hast.

Wenn du dann aber Papierluftfahrtkarten als Backup hast, auf denen noch die DDR
Luftraumgrenzen sind, wird auch das nicht als geeignet angesehen.

Zurück zu Datenbanken:

Wenn derjenige die Datenbanktechnik aber für sein Produkt wählt, weil er damit verhindern
will oder es zumindest möglichst schwer machen will, das irgendein dritter zum Beispiel
auch nur die Daten auslesen kann oder sogar schreibend zu verändern, dann ist eine
verschlüsselte DB ein ganz guter Weg.

konkreter Grund aus der Praxis: Ex Mitarbeiter gründet eigene Softwarefirma in der
gleichen Branche, nimmt ähnliche Datenstrukturen und kann auf dem Wege jeden Kunden
seines Ex Arbeitgebers direkt anbaggern, weil der Datenimport extrem einfach ist.

Unser Kunde (der Ex Arbeitgeber) erstellte daher mit unserer Hilfe zu FB2x Zeiten
eine funktionsgleiche, aber binär unterschiedlich speichernde Firebird Version,
von der man nicht mal eben einfach die Datenbank-Datei kopieren konnte und in einem
anderen Firebird Server dann ohne weitere Hindernisse öffnen kann (ist übrigens nicht
nur bei Firebird so).

Wenn der Kunde wechselwillig ist und dem neuen Anbieter vollen Zugriff
auf den Datenbankserver bietet, bleiben da nicht wirklich viele
Hindernisse. Mit der nicht öffentlich bekannten Datenbankdateistruktur war
das aber schon weit schwieriger.

Anderer Grund aus der Praxis: Eine Justizbehörde mit Außendienstlern
brauchte zu Zeiten, als noch nicht alles online ging, große Datenbestände auf dem Laptop,
um vor Ort Untersuchungen starten zu können, deren Gründe sich erst durch vor Ort
gefundene Beweismittel ergaben. Genauere Details hatte ich am Ende auch nicht, weil
da aufgrund der Dateninhalte relativ hohe Geheimhaltung galt. Das wurde am Ende
durch einen betriebssystembasierenden bzw hardwarebasierenden Datenträger-
verschlüsselungsmechanismus gelöst, auf dem die Datenbank dann aber trotzdem
ohne weiteres lief. Ohne den beim booten/anmelden erforderlichen Schlüssel war
der Datenträger nach dem Stand der Technik unbrauchbar, das reichte dem Auftraggeber
(sicher hätte man mit Brute Force das umgehen können, aber das war für die ausreichend
sicher).


Ein verschlüsselte Datenbank kann sicherlich sinnvoll sein, aber warum das sinnvoll
ist, wird man immer selber abwägen müssen, wenn man die wahl hat. Es gibt diverse
Vorteile aber auch nicht unwesentliche Nachteile und eine gute Software kann
weit mehr als einfach nur alles speichern und nie wieder etwas löschen, um
Datenänderungen transparent zu machen.

[Rollo62]

Zitat von IBExpert:

...
konkreter Grund aus der Praxis: Ex Mitarbeiter gründet eigene Softwarefirma in der
gleichen Branche, nimmt ähnliche Datenstrukturen und kann auf dem Wege jeden Kunden
seines Ex Arbeitgebers direkt anbaggern, weil der Datenimport extrem einfach ist.
..

+1
Sehr schöner Grund, ich denke das trifft schonmal auf 95% aller Fälle zu.
Hier würde es vieleicht reichen nur tabellenweise zu verschlüsseln ?