Vertrauen

Sicherheit

Was dieser Dienst tatsächlich tut, um Ihre Daten zu schützen. Jede Aussage unten entspricht etwas im Code, und der letzte Abschnitt nennt, was wir bewusst nicht behaupten.

Mandantentrennung

Jede Abfrage, die Geschäftsdaten berührt, ist auf den Arbeitsbereich eingegrenzt, der aus Ihrer Sitzung ermittelt wird. Die Kennung des Arbeitsbereichs wird nie aus einer URL, einem Formularfeld oder einem Anfragekörper gelesen; eine gültige Kennung eines anderen Kunden lässt sich also nicht unterschieben — eine Anfrage nach fremden Rechnungen liefert dasselbe „nicht gefunden“ wie eine Anfrage nach einer Rechnung, die es nie gab. Das ist in der Datenschicht durchgesetzt, nicht in der Oberfläche, und hat eigene Regressionstests.

Rollen und Berechtigungen

Fünf Rollen — Inhaber, Administrator, Mitglied, Buchhaltung, Betrachter — abgebildet als ausdrückliche Berechtigungsmatrix statt als Rangfolge. Dieser Unterschied ist wesentlich: die Buchhaltung darf Ihre Bücher exportieren, aber keine Rechnung ausstellen, was sich in einer einfachen Hierarchie nicht ausdrücken lässt. Jede Aktion und jede Route prüft die Berechtigung serverseitig; eine ausgeblendete Schaltfläche ist Darstellung, niemals Schutz.

Ausgestellte Dokumente werden nicht überschrieben

Wird eine Rechnung ausgestellt, werden PDF und XML einmal erzeugt und gespeichert. Spätere Downloads liefern genau diese Bytes aus, statt das Dokument neu zu erzeugen; eine nachträgliche Änderung Ihrer Unternehmensangaben kann eine Rechnung, die Ihr Kunde bereits hat, also nicht verändern. Die Anwendung hat keinen Programmpfad, der ein archiviertes Dokument überschreibt oder löscht: Schreibvorgänge verwenden ein Kennzeichen, das ein Überschreiben ausschließt, sodass eine Kollision ein Fehler ist und keine stille Ersetzung.

Um genau zu sein, was das ist und was nicht: Die Zusicherung wird von der Anwendung durchgesetzt, nicht von der Speicherebene. Der Bucket ist privat, mit einer restriktiven Zugriffsrichtlinie, und nur über diesen Dienst erreichbar. Es handelt sich nicht um Speicher mit Object Lock, und wer die Infrastruktur-Zugangsdaten besitzt, könnte ein Objekt weiterhin löschen. In unserer Architekturdokumentation steht dasselbe, und eine weitergehende Härtung ist als offene Aufgabe vermerkt.

Authentifizierung

Die Anmeldung erfolgt über einen per E-Mail zugesandten Einmal-Link. Es werden keine Passwörter gespeichert — es gibt also keine Passwortdatenbank, die kompromittiert werden könnte, und nichts von Ihnen, das anderswo wiederverwendet werden kann. Links laufen ab, sind einmal verwendbar und in ihrer Häufigkeit je Adresse und je Netz begrenzt. Sitzungen liegen in der Datenbank statt in einem in sich geschlossenen Token, sodass sie sofort widerrufen werden können, statt bis zum Ablauf gültig zu bleiben.

Zahlungen

Kartendaten werden auf der gehosteten Bezahlseite von Stripe eingegeben und berühren diesen Dienst nie. Wir speichern eine Kundenreferenz und den Status Ihres Abonnements, mehr nicht. Der Umgang mit Kartendaten und dessen PCI-DSS-Geltungsbereich liegen bei Stripe.

Dokumentformat

Rechnungen sind PDF/A-3U — ein ISO-Archivformat mit eingebetteten Schriften, sodass das Dokument in zehn Jahren so aussieht wie heute — und tragen die strukturierten Daten nach EN 16931 in derselben Datei. Ein Artefakt ist zugleich die menschenlesbare Rechnung und der maschinenlesbare Datensatz, und genau das verhindert, dass beide auseinanderlaufen.

Prüfung

Erzeugte Dokumente werden gegen eine ausführbare Kodierung von 42 benannten Geschäftsregeln aus EN 16931 und XRechnung geprüft, bei jedem Build. Ein Fehlschlag nennt die verletzte Regel — BR-CO-13, BR-DE-15 — statt einen Diff zu zeigen.

Das ist unsere eigene Umsetzung der benannten Regeln, nicht die offizielle KoSIT-Schematron-Distribution, die als XSLT ausgeliefert wird und einen Prozessor der Saxon-Klasse benötigt. Sie zusätzlich auszuführen ist als offene Aufgabe vermerkt. Ein Dokument, das hier besteht, hat den offiziellen Validator nicht durchlaufen.

Was wir nicht behaupten

Eine Sicherheitsseite, die übertreibt, ist ein Risiko und keine Beruhigung. Dieser Abschnitt steht deshalb bewusst hier.

  • Wir haben keine Sicherheitszertifizierung. Es gibt kein ISO 27001, kein SOC 2 und keinen externen Prüfbericht. Verlangt ein Beschaffungsverfahren so etwas, erfüllen wir das heute nicht.
  • Wir bieten keinen unveränderlichen Speicher und kein Write-once-Verfahren an. Was genau zugesichert ist und was nicht, steht im Abschnitt zur Archivierung oben.
  • Wir führen den offiziellen KoSIT-Validator nicht aus. Siehe den Abschnitt zur Prüfung oben.
  • Ein Penetrationstest durch Dritte wurde nicht beauftragt.

Sicherheitslücken melden

Wenn Sie glauben, ein Sicherheitsproblem gefunden zu haben, schreiben Sie an die im Impressum genannte Kontaktadresse, mit genügend Details zur Reproduktion. Wir bestätigen den Eingang und halten Sie auf dem Laufenden. Geben Sie uns bitte eine angemessene Gelegenheit zur Behebung, bevor Sie die Lücke öffentlich machen, und greifen Sie bei der Untersuchung nicht auf Daten anderer Kunden zu.

Nachrichten an diese Adresse beantworten wir innerhalb von zwei Werktagen.

Impressum