GoBD/GDPdU

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

moin,

es wohl wird immer Auslegungssache des Prüfers werden was verschieden ausfallen kann.
bei "Technischen" oder "Mathematischen" Lösungen oder auch "abgesicherten Umgebungen" macht der Prüfer schnell "dicht" [-X

was der Prüfer am liebsten hat ist immer noch das "gedruckte" Papier was technisch einfach zu lösen wäre :
bei jedem BON läuft ein Drucker mit !
klar wäre der Ausdruck "Sichtbar" ... dann braucht man auch die Datenbank nicht zu verschlüsseln.

wenn der Prüfer so einen Ausdruck akzeptiert dann ist alles gut :D

wenn er "mehr" verlangt wird es vermutlich auf eine 3-PP hinauslaufen deren Zertifikat dann ein Argument wäre.
ob ein "kleiner" Hersteller solche Auflagen, die immer einen Finanziellen Aufwand erfordern, überhaupt erfüllen kann fragt der Gesetzgeber leider gar nicht :(
gruss by OHR
Jimmy
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: GoBD/GDPdU

Beitrag von mikehoffmann »

Wir haben da noch einen Trick im Ärmel, um die Daten vor dem Benutzer zu schützen und nur für die Applikationen verfügbar zu machen. Unsere G4-Applikation simuliert einen Shell-Folder, sie holt sich sogar die Links und Icons aus einem angegebenen echten Folder. Außer der Ladezeit ist da für den User fast keine Unterschied. Jedem Link ist ein Execution Environment zugeordnet, das sich auch mehrere Links teilen können. Wird ein Link geklickt, wird das Ziel im angegebenen Execution Environment gestartet. So ein Execution Environment hat eine Anmeldung an den Server (mit den notwendigen Rechten für die Daten) und ein eigenes Laufwerks-Mapping. So sieht der Benutzer in seiner normalen Shell nur dir Daten, die er auch wirklich anfassen darf und nur die Applikation kommt an die heißen Daten, die ihn direkt nichts angehen. Ein bißchen wie RunAs mit ein paar Blümchen extra, z.B. Druckerzurverfügungstellung in den Execution Environments.
Viele Grüße
Michael
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: GoBD/GDPdU

Beitrag von HaPe »

Hallo Michael !
So sieht der Benutzer in seiner normalen Shell nur dir Daten, die er auch wirklich anfassen darf und nur die Applikation kommt an die heißen Daten, die ihn direkt nichts angehen. Ein bißchen wie RunAs mit ein paar Blümchen extra, z.B. Druckerzurverfügungstellung in den Execution Environments.
Also rechtemäßig eine Art Application-Role bzw. Anwendungsrolle:
https://docs.microsoft.com/de-de/sql/re ... tion-roles
--
Hans-Peter
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: GoBD/GDPdU

Beitrag von mikehoffmann »

Ja, so kann man sich das vorstellen. Das Zugriffsprotokoll ist halt File System und damit bestens geeignet für unsere Dbf-Jonglierprogramme. Mit den Usern halten wir es so, dass es jeden zweimal gibt. Es gibt also z.B. einen Hoffmann und einen G4_Hoffmann. Der Hoffmann weiß nix vom G4_Hoffmann, der darf aber alle Daten sehen. So sieht man bei Problemen mit den Servermonitorfunktionen gut, wer der eigentliche Verursacher ist. Sonst würde auch ein einziger User reichen.
Ähnliches machen wir auch auf Einzelrechnern, deren Benutzer in Ihren Rechten komplett beschnitten sind, z.B. öffentliche Terminals. Da installieren wir unser "WormHole." Mit einem Hotkey (Ctrl-Alt-Ins, was sonst...) wird WormHole zum Leben erweckt, der Benutzer kann sich als Administrator authentifizieren und hat dann die entsprechenden Rechte. Zeitweise haben wir dafür sogar auf einen zweiten Desktop geschaltet, damit der erste komplett unangetastet bleibt. Aber damit steckt man wieder in der anderen Identität fest. Und die Shell (Explorer) kommt damit auch nicht so ganz zurecht.

Viele Grüße
Michael
flanelli
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 151
Registriert: Di, 11. Mai 2010 16:27
Hat sich bedankt: 3 Mal
Danksagung erhalten: 9 Mal

Re: GoBD/GDPdU

Beitrag von flanelli »

AUGE_OHR hat geschrieben: Mo, 15. Jan 2018 18:57 die Verschlüsselung, ob überhaupt vorgeschrieben, ist NICHT das Problem [-X
es geht um den "lückenlosen" Nachweis das wirklich alles gebucht wurde.

das was das Finanzamt im Prinzip will ist das "Blockchain" Verfahren wie beim BitCoin.
wie bekannt ist der "Blockchain" selbst nicht verschlüsselt
man kann jede Transaktion "sehen" und nicht nachträglich manipulieren.
Hallo Jimmy,

Es ist kaum vorstellbar, dass die Finanz in der BRD auch nur
ansatzweise eine Methode "Blockchain" Verfahren wie beim BitCoin
für die angedachte neue Registrierkassenverordnung andenkt und
auch sicher nicht in Anwendung bringen wird.
Der Grund dafür ist jedem klar der dieses Blockchainverfahren kennt
und Du hast das ja auch bereits in rudimentären Ansätzen begrundet.

In Österreich wurde per 01.04.2017 ein verpflichtendes Verfahren
verordnet das eine Manipulation der Belegsdaten nahezu unmöglich
macht und sich die Datenmengen dieser Protokolle auch bei Belegsanzahlen
im Millionenbereich pro Jahr noch in handlebaren Dimensionen bewegt.
Dies auch im Hinblick auf die zwingende Speicherung dieses Protokolles
für einen Mindestzeitraum von 7 bzw. 10 Jahren.

Jeder einzelne Datensatz in diesem Protokoll stellt einen Beleg dar
und dieser Datensatz ist sehr wohl verschlüsselt aber er vergrößert sich
nicht mit der Erstellung jedes weiteren ( allenfalls um ein paar wenige
Byte mehr oder weniger je nach dem Ergebnis einer Base64-Verschlusselung
von den Daten stets gleicher Felder aber unterschiedlicher Inhalte.

Beispiel:
Datenprotokoll Beleg 1
eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMF9ERU1PLUNBU0gtQk9YODE3XzgzNDY4XzIwMTUtMTEtMjVUMTk6MjA6MTBfMCwwMF8wLDAwXzAsMDBfMCwwMF8wLDAwX3NxdjNYSGNJOG1VPV8tMzY2Nzk2MTg3NTcwNjM1Njg0OV9kM1lVYlM0Q29Sbz0.7xi1XGF613-KuNA65Ov7fVnRPuw3aFfuSy0mKpXsSaCvRLw-zNKaH0rcifAYRBTxsqsKDoi9v4-4rchs_CI3SQ

Datenprotokoll Beleg 2
eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMF9ERU1PLUNBU0gtQk9YODE3XzgzNDY5XzIwMTUtMTEtMjVUMTk6MjA6MTFfMjksNzNfMCwwMF8zNiw0MV8wLDAwXzIxLDE5X1UxUlBfLTM2Njc5NjE4NzU3MDYzNTY4NDlfVkR1dVVINGwzT3c9.U2ljaGVyaGVpdHNlaW5yaWNodHVuZyBhdXNnZWZhbGxlbg

Datenprotokoll Beleg 3
eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMF9ERU1PLUNBU0gtQk9YODE3XzgzNDcwXzIwMTUtMTEtMjVUMTk6MjA6MTFfMCwwMF8wLDAwXzAsMDBfMCwwMF8wLDAwX3ZYdnFsV3kwemNNPV8tMzY2Nzk2MTg3NTcwNjM1Njg0OV9SSGZrVGtJY0h1bz0.lmNPnzblcm3Puc_oyMSA8yIrrGR0Z27NPbcUFO124PMEI8WjAHWZgzEZgQmygDrMeUfnT0B752AbCWmupfXkaA

usw.

Die Programmiereoutinen für die entsprechende Erstellung der Basisdaten
die in der Folge z.B. durch ein akkreditiertes Zertikat eines der 3 österreichischen
zertifizierten Anbieters signiert werden ist wahrlich kein Kunststück.
Die Signaturerstellungseinheiten gibt es als Steckkarte, USB-Stick oder auch
webbasiert von diversen Middlewareanbietern.

Bzgl. der zusätzlich auch manipulationssicheren Speicherung aller Protokolle
lautet es im österreichischen Gesetzestext zwar auch sinngemaß
"Die Daten müssen unveränderbar vierteljährlich auf einem externen Medium
gespeichert werden" aber in der Realität reicht lt. später nachgefolgtem
Erlaß auch eine laufende Speicherung mit allen Daten von Beginn des
Kasseneinsatzes weg ohne jede weiter Verschlüsselung oder ähnlichen Mumpitz
wie Worm oder Datensafe und auch weitere reine "Abzock"dienste" diverwer Anbieter.
Auch hier ist der Grund für die Lockeruing des "unveränderbar" ein recht simpler
denn durch die Verkettung ist eine Manipulation ohnehin nicht realiserbar und
auch ein krampfhaftes "Neuerstellen aller Daten im Nachhinein" führt zu keiner
erfolgreichen Manipüulation da auf jedem ausgefolgten Beleg bestimmte Teile dieser
signierten Daten als QR_Code angedruckt werden und damit würde jeder manipulierte
Datensatz ein wahre Tanz auf dem Vulkan werden.
Ahoile aus dem Süden
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: GoBD/GDPdU

Beitrag von AUGE_OHR »

flanelli hat geschrieben: Mi, 17. Jan 2018 14:27 Die Programmiereoutinen für die entsprechende Erstellung der Basisdaten
die in der Folge z.B. durch ein akkreditiertes Zertikat eines der 3 österreichischen
zertifizierten Anbieters signiert werden ist wahrlich kein Kunststück.
Die Signaturerstellungseinheiten gibt es als Steckkarte, USB-Stick oder auch
webbasiert von diversen Middlewareanbietern.
genau "so" hatte ich mir das gedacht das es wohl laufen würde.

@Michael : such mal nach "FakeDesk" im Forum ...
Korrektur : hier viewtopic.php?f=27&t=9902&p=115157
gruss by OHR
Jimmy
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: GoBD/GDPdU

Beitrag von mikehoffmann »

Hab den Thread durchgesehen. Was soll ich da finden?
Antworten