AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Welche Datenbank für Kassensoftware

Welche Datenbank für Kassensoftware

Ein Thema von AnonyM.E · begonnen am 2. Apr 2021 · letzter Beitrag vom 7. Apr 2021
Antwort Antwort
Seite 1 von 2  1 2   
AnonyM.E

Registriert seit: 26. Apr 2019
9 Beiträge
 
#1

Welche Datenbank für Kassensoftware

  Alt 2. Apr 2021, 17:21
Datenbank: SQLite • Version: x • Zugriff über: x
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
  Mit Zitat antworten Zitat
Andreas13

Registriert seit: 14. Okt 2006
Ort: Nürnberg
430 Beiträge
 
Delphi XE5 Professional
 
#2

AW: Welche Datenbank für Kassensoftware

  Alt 2. Apr 2021, 18:50
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
Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher.
John C. Cornelius
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
524 Beiträge
 
FreePascal / Lazarus
 
#3

AW: Welche Datenbank für Kassensoftware

  Alt 2. Apr 2021, 19:04
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....ptionPluginFB3

Wie 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...itseinrichtung
herumkommen 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 ...
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
IBExpert and Firebird Power Workshops jederzeit auch als Firmenschulung
  Mit Zitat antworten Zitat
Neumann

Registriert seit: 6. Feb 2006
Ort: Moers
505 Beiträge
 
Delphi 10.4 Sydney
 
#4

AW: Welche Datenbank für Kassensoftware

  Alt 3. Apr 2021, 13:54
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.
Ralf
Gruß vom Niederrhein
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.093 Beiträge
 
Delphi 10.4 Sydney
 
#5

AW: Welche Datenbank für Kassensoftware

  Alt 3. Apr 2021, 15:30
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
1.650 Beiträge
 
Delphi 10.3 Rio
 
#6

AW: Welche Datenbank für Kassensoftware

  Alt 3. Apr 2021, 18:49
Meines Wissens nach kann FireDAC auch SQLite Datenbanken
verschlüsseln. Ist dann aber ein FireDAC Feature.
  Mit Zitat antworten Zitat
Frickler

Registriert seit: 6. Mär 2007
Ort: Osnabrück
360 Beiträge
 
Delphi XE6 Enterprise
 
#7

AW: Welche Datenbank für Kassensoftware

  Alt 6. Apr 2021, 19:22
Meines Wissens nach kann FireDAC auch SQLite Datenbanken
verschlüsseln. Ist dann aber ein FireDAC Feature.
UniDAC kann das auch. Es gibt aber auch eine "offizielle" SQLite Verschlüsselung, die "SQLite Encryption Extension". Die ist nur ziemlich teuer ($2000,-).
  Mit Zitat antworten Zitat
Neumann

Registriert seit: 6. Feb 2006
Ort: Moers
505 Beiträge
 
Delphi 10.4 Sydney
 
#8

AW: Welche Datenbank für Kassensoftware

  Alt 6. Apr 2021, 20:05
Muss man überhaupt verschlüsseln, es wir doch alles über die TSE abgesichert?
Ralf
Gruß vom Niederrhein
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.577 Beiträge
 
Delphi 10.4 Sydney
 
#9

AW: Welche Datenbank für Kassensoftware

  Alt 6. Apr 2021, 20:27
Muss man überhaupt verschlüsseln, es wir doch alles über die TSE abgesichert?
Klingt so, als will er eine eigene "TSE" aus irgendeiner DB bauen.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Daniel
(Administrator)

Registriert seit: 30. Mai 2002
Ort: Hamburg
15.470 Beiträge
 
Delphi 10.4 Sydney
 
#10

AW: Welche Datenbank für Kassensoftware

  Alt 7. Apr 2021, 07:09
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.
Daniel R. Wolf
Admin Delphi-PRAXiS
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +2. Es ist jetzt 11:31 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf