Architekturbeschreibung

Der Diskriminator zur Auswahl der Integrations-Architektur ist das operational environment. Als operational environment wird vom BSI jene Umgebung interpretiert, welche unter physischer Kontrolle des Steuerpflichtigen steht. In einer strengen Auslegung bedeutet dies, dass zum Beispiel durch den Steuerpflichtigen folgende Aufgaben durchgeführt werden können: Kabel ein- und ausstecken, physischen Speicher tauschen, Ein- und Ausschaltknöpfe bedienen, etc.

In den technischen Richtlinien des BSI ist festgelegt, dass in jenem operational environment die SMA (Security Module Application) laufen muss.

Nach den uns vorliegenden Informationen aus den Bieterfragen sind alle Server sowie alle Kassenplätze im operational environment des Integrators. Daher können potentiell beide Architektur-Szenarien umgesetzt werden, die direkte Integration der SMA in die Kassensoftware, wie auch die Bereitstellung von SMA-Servern in das LAN einer Filiale.

Die CSP Komponenten, welche die Signaturen erzeugen, wird durch fiskaly in deren Cloud bereitgestellt.

In diesem Dokument wird die Umsetzung des Cloud-Szenario fokussiert, Integration der SMA-Komponenten im operational environment des Kassensystems, direkte Kommunikation mit den API + CSP Komponenten in der fiskaly Cloud.

Software Development Kit

Das Software Development Kit (SDK) wird von uns zur Verfügung gestellt. Es besteht aus:

  • Schnittstelle zur Integration (siehe auch kassensichv.io, fiskaly TSS / TSE API)
  • CC-zertifizierte SMA-Komponente in binärer, ausführbarer Form
  • optional: Kompensationsmechanismen für Ausfallszenarien & Loging der Ausfallszenarien

Das SDK wird von uns für verschiedene Plattformen und Betriebssysteme zur Verfügung gestellt, u.a. für Linux, Windows, MacOS, Android, iOS, als 32 Bit oder 64 Bit Architektur.

Der Quellcode des SDKs wird ebenfalls zur Verfügung gestellt, u.a. für Java, .Net, Node.js. Eine Übersicht der zum jeweiligen Zeitpunkt veröffentlichten Clients und SDKs finden Sie unter github.com/fiskaly.

Auf Anfrage stellen wir auch gerne Implementierungen für andere Plattformen oder Sprachen um.

TSE-Integration direkt am Kassenplatz

Erfolgt die Integration der TSE direkt am Kassenplatz, so wird die SMA am Kassenplatz angebunden. Im Schaubild zur TSE-Integration direkt am Kassenplatz entspricht der Host A dem Kassenplatz.

Am Host A befindet sich das SDK mit der SMA. Über das SDK werden die abzusichernden Daten an die SMA weitergeleitet. Die SMA ist dafür verantwortlich, die abzusichernden Daten über einen sicheren Kanal (TC, trusted channel) an die entfernte CSP auf Host B zu übermitteln. Die CSP erstellt die erforderlichen Signaturwerte und meldet diese wieder zurück an die SMA. Von dort werden die nun abgesicherten Daten an den Host C übermittelt und persistiert. Host C stellt die Schnittstellen der TSE sowie den Speicher zur Verfügung.

Architektur-High-Livele Architektur

Technische Anforderungen

KategorieAnforderung
Antwortzeiten50 - 250ms, abhängig von der Netzwerklatenz
ProzessablaufAsynchron. Start- und Update-Transaction verursachen somit keine Verzögerung im Aufzeichnungssystem. Nur für Finish-Transaction muss auf die Antwort gewartet werden.
Service-FunktionenIdempotent. Ein Vorgang kann beliebig oft wiederholt werden. Der erwartete Seiteneffekt tritt jedoch nur ein einziges Mal ein.
Gleichzeitig geöffnete Transaktionen pro TSEunbegrenzt
Unterstützte BetriebssystemeLinux, Windows, u.a. (plattformunabhängig)

Datenvolumen für eine Transaktion

Das Datenvolumen für eine Transaktion ist abhängig vom zu signierenden Payload, jedoch pauschal sehr gering.

Geht man von einem absoluten Minimum an abzusichernden Daten aus, so beträgt das Datenvolumen pro Transaktion << 1 Kilobyte. Ist ein größeres Volumen an Daten abzusichern, zum Beispiel um POSLog Transaktionen vollständig zu erfassen, steigt auch das Datenvolumen. Das Maximum der abzusichernden Daten ist theoretisch unbegrenzt.

Die vollständige Absicherung von POSLog Transaktionen bringt den Vorteil, dass weitere Servicedienste wie z.B. Archivierung oder Accounting die Transaktionsdaten weiter verarbeiten können.

Beispiel eines Payloads: Mindestdaten des Attributs processData für einen processType “Kassenbeleg” lt. Feldspezifikation der DSFinV-K Beleg^123.45_67.89_0.00_0.00_0.00^111.11:Bar_80.23:Unbar Es ist anzunehmen, dass pro Transaktion 1 kB - 256 kB an zB. Daten übermittelt werden. Je nachdem, ob es sich um einen Kassenbeleg, eine Bestellung (lang andauernder Vorgang) oder anderen Vorgang handelt.

Die Bandbreite kann aufgrund unserer asynchronen Architektur sehr gering sein, z.B. via ISDN. Für den Abschluss einer Transaktion muss jedoch auf die Antwort unseres Systems gewartet werden. Hier ist die Latenzzeit des Netzwerkes die einschränkende Komponente, da die zu übermittelnden Daten ein sehr geringes Volumen einnehmen.

Antwortzeiten

Die Antwortzeiten der fiskaly cloud werden maßgeblich durch die Latenzzeiten der Netzwerkanbindung beeinflusst. Innerhalb der fiskaly cloud können wir in unserem Testsystem zur KassenSichV bereits Antwortzeiten von durchschnittlich 64 ms aufweisen. Zu beachten ist, dass das Testsystem noch nicht auf Durchsatz optimiert ist. Es können Antwortzeiten von unter 50 ms in unserem Produktivsystem erwartet werden.

Postman Worfklow and Performance (Screenshot eines fiskaly Cloud-TSE Testdurchlaufs)

Zu berücksichtigen ist die Latenzzeit der Netzwerkanbindung des Integrators an die Rechenzentren der fiskaly cloud. Aktueller Standort der fiskaly cloud Infrastruktur ist Frankfurt am Main (redundant), weitere Standorte können bei Bedarf zum Beispiel in Düsseldorf und München zur Verfügung gestellt werden.

Simultan geöffnete Transaktionen

Die Anzahl der gleichzeitig geöffneten Transaktionen pro TSE ist in der fiskaly cloud nicht begrenzt. Es können beliebig viele Transaktionen offen gehalten werden.

Last updated on