|
Datenbank: SQLite • Version: x • Zugriff über: x
Welche Datenbank für Kassensoftware
Hallo Forum,
Momentan schreibe ich an einem Kassenprogramm. Nun heißt es ja, Daten dürften nicht veränderbar sein. Ich frage mich aber, wie man das realistisch gesehen überhaupt umsetzen soll. Selbst bei einer verschlüsselbaren Datenbank wie MS-SQL hat man ja immer noch das Problem, dass man das Passwort irgendwie in der Exe hinterlegen muss. Findet man das Passwort in der Exe oder im Arbeitsspeicher, so sind die Daten ja direkt wieder änderbar bzw. manipulierbar. Daher mal so eine generelle Frage: Wie ist das mit der Nichtveränderbarkeit eigentlich gemeint? Weiß darüber jemand mehr? Soll das nur heißen, dass die Software, die man programmiert, keine Daten ändern können soll? Wo soll man da realistisch gesehen eine Grenze setzen, ab wann man es als nichtveränderbar bezeichnen kann? Aktuell benutze ich SQLite. Der Grund: Die meiner Erfahrung nach extrem hohe Stabilität. Hat jemand andere Empfehlungen, um "nichtveränderbarkeit" in die Software reinzukriegen? SQLite unterstützt ja leider keine Verschlüsselung. 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? Bin gespannt auf Eure Gedanken dazu, Markus |
AW: Welche Datenbank für Kassensoftware
Hallo Markus,
ABSOLUTE Database  https://www.componentace.com/bde_rep...e_database.htm hat eine eingebaute Verschlüsselung. Allerdings kann ich nicht beurteilen, ob die DB sonst für Deine Zwecke geeignet ist. Du kannst aber eine kostenlose Demo-Version herunterladen.Gruß, Andreas |
AW: Welche Datenbank für Kassensoftware
Eine encrypted firebird 3.0 datenbank ohne den benutzten schlüssel zu verändern, halte ich für nahzu unmöglich.
wie man das macht und was man ggf braucht findest du zum Beispiel hier https://www.ibexpert.net/ibe/pmwiki....ptionPluginFB3Wie und wo du in deiner applikation den benutzten key dann speicherst ist ein ganz anderes thema, aber ganz wichtig: kein Finanzamt der welt wird in irgendeiner Software die Unveränderbarkeit von Daten fordern können, weil veränderungen von Daten (zum Beispiel Lagerbestände) elementarer Bestandteil von Software ist. Wenn du aber egal ob encrypted db oder auch in einer normalen DB sämtliche Änderungen sauber protokollierst und bei jedem betroffenen Datensatz alle Änderungen im Protokoll hast, ist das wesentlich wichtiger, mit diesen Informationen dem schnüffelnden Prüfer eine ausführliche Möglichkeit gibst, Veränderungen der Datensätze nachsehen zu können. Ob du dafür am Ende Trigger basierende Protkolldatensätze erstellst, oder ganz modern irgendwelche Blockchain Techniken einbaust, ist als Medium ziemlich egal. Auf Anfrage solltest du in der Lage sein, technisch zu begründen, warum du der Meinung bist, das deine Software Mechanismen eingebaut hat, die nachträglich gemachte Veränderungen erkennbar protokolliert und auf Anfrage als Historie exportieren kannst. Wenn du als Softwarehersteller, der den Key der Datenbank aber nun mal kennt, deinen Kunden aber ein kleines Zusatzprogramm anbietest, mit dem zum Beispiel ein Restaurant Inhaber einfach mal die Tagessumsätze ausbuchen kann, ohne das am Ende Datensätze überbleiben, dann wird das niemals jemand finden können, es sei denn, das Finanzamt macht mal ein paar Testkäufe und prüft dann ob die dabei erstellten umsätze in der Datenbank auch wirklich erkennbar vorhanden sind (was ja vor kurzem einem Softwarehersteller mit ziemlich vielen Chinarestaurants als Kunden so passiert ist und wo nun die beiden Gründer der Softwarefirma wohl im Knast sitzen ....) Aufgrund aktueller Verordnungen wirst du bei der Sicherung der Datenbankinhalte mit ganz normalen Sicherungsmechnismen und ggf per Trigger erstellen Datensatzänderungsprotokollen ganz gut klar kommen, weil du im Kassenbereich sowieso nicht um die Nutzung von einer TSE https://de.wikipedia.org/wiki/Techni...itseinrichtungherumkommen wirst, weil nur da drin zertifizierte Hardware verbaut ist, die dein Kunde seinem Prüfer auch glaubhaft als sicheren Mechanismus zeigen kann und gefordert ist. Wenn auf dem Wege alle relevanten Dokumente erstellt wurde und in diesem System (zB der Kassendrucker) sauber und vollständig gespeichert wurde, wird ein Prüfer jederzeit mit Stichproben in deiner Software nachschauen können, ob die denn die gleichen Inhalte anzeigt. Warum da wer was und wann geändert hat, solltest du in deiner Software ziemlich lückenlos anzeigen können Beispiel: Auf dem Bon und damit in der TSE steht ein verkauftes Schnitzel zu 7 €, der Preis in der Kasse ist aber aktuell 14 €. Wenn der Prüfer das seltsam findet und deine Software nicht nachweisen kann, warum der preis mal 7 Euro und mal 14 Euro ist, wird der ziemlich schnell davon ausgehen, das deine Software da nicht konsistent ist und dein Kunde vorwerfen, das er vermutlich 14€ dafür kassiert hat, aber nur 7€ abgerechnet hat und damit ziemlich einfach nachvollziehbar mit Hilfe deiner Software bescheisst. Kein schöner Moment für Fragen .... Warum wirst du niemals etwas wie eine TSE Sicherheit in der Software haben können? Starte deine Software in einer VM und niemand hindert dich ggf mit geeigneten Mitteln daran, beliebige Inhalte direkt im Arbeitsspeicher zu manipulieren, ohne das deine Software davon überhaupt irgemand was merkt. Es gibt übrigend auch zum Beispiel eine Banking Software von Oracle, bei der alle beteiligten Softwaremodule so dermaßen gegen manipulation abgesichert sind, wie es nur gehen kann. Das hindert aber einen in den Betrug involvierten Administrator, der aus welchen Gründen auch immer sämtliche Adminzugänge und Rechte an der Software direkt auf Datenbankebene kennt oder benutzte Software reverse engineert und anpasst, da auch einfach mal ein paar Konten zu manipulieren oder Records zu löschen. So was scheint bei Banken, die genau so schnell vom Markt verschwinden, wie die gekommen sind, gar nicht mal so unüblich zu sein, Mitarbeiter mit entsprechendem Wissen sind sehr gesuchte Arbeitskräfte in solchen unseriösen Unternehmen ... Oder als Fazit: konzentrier dich auf Integration der TSE und versuche, deine Software so abzusichern, das nicht jeder 08/15 Datenbank Browser da die Inhalte manipulieren kann. In einer Firebird Datenbank, die nicht encrypted ist, änder ich dir nahezu alles an daten, was ich will, in IBExpert ist mit Tools-Database Inside ein Werkzeug eingebaut, mit dem man nicht nur defekte Datenbanken retten kann, sondern auch die Inhalte auslesen kann, egal ob irgendein Datenbanktrigger das verhindern will oder nur ein User da angeblich reinkommt, weil das Modul gar keinen Firebird Server benutzt, sondern die Inhalte direkt ausliest und man schnell per Hex Editor die Position findet, um sachen zu ändern, die per Software oder Firebird SQL gar nicht gehen würde. Im Vergleich zu anderen Datenbank ist der Aufbau einer FB Db sogar noch ziemlich kompliziert. Ähnliche Tools findet man zu fast allen Datenbankformaten oder nimmt einfach einen Hex Editor und try and error ... Mit einer in FB3 encrypteten Datenbank, von der wir den Key nicht kennen, kannst du das Tool und auch einen Hex Editor aber direkt vergessen. Daher wäre das schon ein weg, sicherer zu sein, als ohne, meine Erfahrung sagt mir aber, das im Handels- oder Dienstleistungsbereich ganz wenig Kunden auch nur drüber nachdenken, an den Daten was verändern zu können, wenn der Hersteller der Software das nicht als Feature per Mund zu Mund Propaganda streut. Das Knast Risiko muss dann aber jeder für seine eigene Lebensplanung abwägen ... |
AW: Welche Datenbank für Kassensoftware
Ich würde mir erstmal überlegen - warum überhaupt eine Kassensoftware, ich würde davon abraten das zu versuchen. Es gibt schon viele und der Aufwand ist groß. Unterschätzt man vorher meistens. Sagen wir mal 3-5 Mannjahre bis was brauchbares erzeugt ist. Wir machen auch Kassensoftware und selbst nach vielen Jahren muss man konstant dran arbeiten. Es geht mir nicht darum einem neuen "Konkurrenten" zu verhindern, ob es 120 oder 130 Mitbewerber gibt ist völlig uninteressant.
|
AW: Welche Datenbank für Kassensoftware
Das stimmt, wenn es etwas sein soll, das dann auch verkauft werden kann. Dann sind 3-5 Mannjahre eher schon zu niedrig gegriffen.
Es kommt aber ganz auf das Ziel an. Eine kleine einfache Kassenanwendung kannst du auch alleine in ein paar Monaten schreiben. Nur kann die dann eben auch nicht mehr. Wenn das z.B. eine kleine Kasse für die Nutzung im eigenen Betrieb sein soll, z.B. in der Kantine, ist das aber ggf. auch schon vollkommen ausreichend. Viele vergessen aber was da alles dran hängt und welche Gesetze es zu dem Thema gibt. Da ist die eingangs genannte Unveränderbarkeit der Daten (soweit das eben machbar ist) noch der kleinste Punkt. Und deshalb ist vor allem eines wichtig: Fachwissen Ich gebe mal ein paar Stichworte: Fiskalisierung (wie schon genannt) mit Fiskalexporten usw. (z.B. §146 AO), Abschläge, Kassensturz, Ausdrucke, Schnittstellen zu anderen Systemen, Bedienerführung, ... (und das könnte man noch fast beliebig fortführen) Hier im Forum sind ja einige Mitarbeiter von Firmen unterwegs, die in der Branche sind. |
AW: Welche Datenbank für Kassensoftware
Meines Wissens nach kann FireDAC auch SQLite Datenbanken
verschlüsseln. Ist dann aber ein FireDAC Feature. |
AW: Welche Datenbank für Kassensoftware
Zitat:
|
AW: Welche Datenbank für Kassensoftware
Muss man überhaupt verschlüsseln, es wir doch alles über die TSE abgesichert?
|
AW: Welche Datenbank für Kassensoftware
Zitat:
|
AW: Welche Datenbank für Kassensoftware
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. |
AW: Welche Datenbank für Kassensoftware
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. |
AW: Welche Datenbank für Kassensoftware
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.
|
AW: Welche Datenbank für Kassensoftware
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.
|
AW: Welche Datenbank für Kassensoftware
Zitat:
In der Grundfrage ging es aber um die vorgeschriebene Unveränderlichkeit Zitat:
|
AW: Welche Datenbank für Kassensoftware
Zitat:
Anders formuliert: Das, was fast alle (jetzt schon) machen, ist (für etwas Neues) in der Regel zu wenig. |
AW: Welche Datenbank für Kassensoftware
Zitat:
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:
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:
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. |
AW: Welche Datenbank für Kassensoftware
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. |
AW: Welche Datenbank für Kassensoftware
Zitat:
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 ? |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 08:11 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz