Sicherheit durch Design, nicht durch Behauptung
Jeder QR-Code ist im Ruhezustand verschlüsselt und standardmäßig nie öffentlich — ein Betrachter muss erst ein Zugangstor passieren, bevor etwas entschlüsselt wird. Diese Seite erklärt genau, wie — bis hin zu den kryptografischen Grundbausteinen und dem Zugriffsmodell —, damit ein Sicherheitsprüfer es nicht einfach auf unsere Aussage hin glauben muss.
// 01 · Verschlüsselungsmodell
Dreischichtige Envelope-Verschlüsselung
Jeder Inhalt durchläuft drei verschachtelte Schlüsselebenen, bevor er den Speicher erreicht. Die Kompromittierung einer einzelnen Ebene legt die Daten nicht offen — ein Angreifer benötigt alle drei.
// Ebene 1 · KMS
Master-Schlüssel (AWS KMS / HSM)
Hardwaregestützt. Verlässt das HSM nie. Wird ausschließlich verwendet, um mandantenbezogene DEKs zu verpacken und zu entpacken.
// Ebene 2 · DEK pro Mandant
Datenschlüssel (AES-256-GCM)
Ein Schlüssel pro Mandant. Verschlüsselt in der Datenbank gespeichert — verpackt durch den Master-Schlüssel. Der entschlüsselte DEK befindet sich nur im Prozessspeicher mit einer TTL von 5 Minuten; er wird nie nach Redis, auf die Festplatte oder in einen Speicher im Ruhezustand geschrieben.
// Ebene 3 · Inhalt pro QR-Code
Chiffrat (AES-256-GCM + AAD)
Der Inhalt jedes QR-Codes wird mit einem frischen 96-Bit-IV verschlüsselt. Die eigene ID des QR-Codes und seine Mandanten-ID werden als GCM Associated Authenticated Data gebunden, sodass das Chiffrat nicht in einen anderen Datensatz oder Mandanten verschoben werden und dabei weiterhin entschlüsselt werden kann.
// 02 · Schlüsseleigenschaften
Was das Verschlüsselungsmodell robust macht
DEK nie im Ruhezustand
Der Klartext-DEK des Mandanten befindet sich nur im Prozessspeicher. Ein vollständiger Redis-Dump oder ein Datenbank-Backup liefert nur verpacktes Chiffrat — ohne KMS-Zugriff unbrauchbar.
AAD-Bindung
Jedes Chiffrat wird als GCM Additional Authenticated Data an seine qr_id und tenant_id gebunden. Wird ein Chiffrat in einen anderen Datensatz oder Mandanten verschoben, schlägt die Entschlüsselung fehl.
Schlüsselisolierung pro Mandant
Jeder Mandant hat einen eigenen DEK. Selbst wenn zwei Mandanten denselben KMS-Master-Schlüssel nutzen, sind ihre verschlüsselten DEKs getrennte Chiffrate. Eine mandantenübergreifende Entschlüsselung kann nicht gelingen.
Nonce-Budget verwaltet
Zufällige 96-Bit-IVs sind bis zu etwa 2^32 Verschlüsselungen pro Schlüssel sicher. Die DEK-Rotation wird sowohl durch manuelle Aktion als auch durch einen Schwellenwert der Verschlüsselungsanzahl ausgelöst, sodass Mandanten mit hohem Volumen sich der Geburtstagsgrenze nie nähern.
// 03 · Authentifizierung
Undurchsichtige Server-Sitzungen statt Client-JWTs
Der Sitzungszustand liegt auf dem Server (Redis + Datenbank). Der Browser hält nur ein undurchsichtiges httpOnly-Cookie — es enthält keine Ansprüche, die der Client lesen, manipulieren oder wiederverwenden könnte. Bei jeder Anfrage löst der Server user, tenant_id, role aus dem Sitzungsdatensatz auf.
// was der Server speichert
- Sitzungsdatensatz (Benutzer-ID, Mandanten-ID, Rolle, Ablauf)
- Kurze Access-Token-TTL: 15 Minuten
- Rotation des Refresh-Tokens bei jeder Nutzung
// was der Browser speichert
- Ein undurchsichtiges Cookie (httpOnly, Secure, SameSite=Strict)
- Keine Mandanten-ID, keine Rolle, keine Benutzer-ID im Client-Speicher
- Kein eigenständiges JWT in der URL
// 04 · Zugangstore
Jeder QR-Code ist standardmäßig abgesichert
Ein Eigentümer wählt pro QR-Code ein oder mehrere Zugangstore. Das Scannen eines abgesicherten QR-Codes ohne aktive Sitzung oder gültiges Zugangstor legt nichts offen — nicht einmal, dass ein Inhalt existiert.
Anmeldung und Autorisierung
Ein Teammitglied mit aktiver Sitzung und der richtigen Rolle und dem richtigen Mandanten sieht den Inhalt direkt — für Personen, die sich bereits im Mandanten befinden, ist kein separates Zugangstor nötig.
Magic Link (Standard)
Ein zeitlich begrenzter, einmalig verwendbarer Link unter /a/<id>. Undurchsichtig und zustandsbehaftet — jederzeit widerrufbar, unabhängig von seinem Ablauf.
PIN-Code
Eine vom Eigentümer festgelegte PIN, nur als Hash gespeichert. Die Prüfung ist pro undurchsichtiger ID und IP ratenbegrenzt, mit einer Sperre nach wiederholten Fehlversuchen.
Einmalcode per E-Mail
Ein kurzlebiger Code, der an eine verifizierte Adresse gesendet wird, mit einer begrenzten Anzahl von Fehlversuchen, bevor er ungültig wird.
Optionaler öffentlicher Modus — standardmäßig aus, Aktivierung pro QR-Code
Für QR-Codes im Weiterleitungsstil (Kampagnen-Links, dynamische Shortener) kann ein Eigentümer einen einzelnen QR-Code ausdrücklich in den öffentlichen Modus versetzen, wodurch das Zugangstor nur für diesen QR-Code entfällt. Das Ziel bleibt weiterhin im Ruhezustand unter demselben AES-256-GCM-Verfahren verschlüsselt, mit qr_id und tenant_id als AAD gebunden — der öffentliche Modus entfernt die Zugriffsprüfung, nicht die Verschlüsselung. Jeder QR-Code ist standardmäßig abgesichert; nichts wird ohne eine bewusste, auf den einzelnen QR-Code bezogene Handlung öffentlich.
Magic Links als undurchsichtige, zustandsbehaftete IDs
Das Teilen eines QR-Codes mit einem Betrachter erzeugt einen Zugriffslink unter /a/<id>. Die ID ist kurz, zufällig und undurchsichtig — sie ist kein eigenständiges JWT. Ein JWT in der URL leckt über den Browserverlauf, CDN- und Proxy-Zugriffsprotokolle sowie den Referer-Header. Eine undurchsichtige ID leckt nichts.
Zustandsbehaftet
Der Server verfolgt Ablauf, Nutzungsanzahl und Widerrufsstatus. Der Link kann jederzeit widerrufen werden, unabhängig von seinem Ablaufdatum.
Nutzungsbegrenzt
Eine optionale Obergrenze für die Nutzung verhindert, dass ein Link unbegrenzt wiederverwendet wird. Der Nutzungszähler wird bei jedem erfolgreichen Zugriff atomar erhöht.
No-referrer
Referrer-Policy: no-referrer ist auf allen /a/*- und /q/*-Routen gesetzt. Das Token wird nach dem ersten Austausch zudem aus der URL entfernt.
// 05 · Datenisolation
Mandanten-Isolation
Mandantenbezug auf Zeilenebene
Jede mandantenbezogene Tabelle trägt eine Spalte tenant_id. Alle Abfragen sind auf den aus der Sitzung aufgelösten Mandanten beschränkt — es gibt keinen Pfad von der Sitzung eines Mandanten zu den Zeilen eines anderen Mandanten.
PostgreSQL Row-Level Security
RLS-Richtlinien in der Datenbank setzen Mandantengrenzen als mehrschichtige Verteidigung durch. Eine Abfrage, die die Anwendungsebene umgeht, kann trotzdem keine Zeilen eines anderen Mandanten zurückgeben.
// 06 · Datenschutz und Betrieb
Nachvollziehbar, exportierbar, auf Anfrage löschbar
HMAC-gehashte IPs in Zugriffsprotokollen
Zugriffsprotokolle speichern niemals rohe IP-Adressen. Jede IP wird mit HMAC-SHA256 und einem serverseitigen geheimen Schlüssel gehasht. Reines SHA-256 wäre über den IPv4-Raum umkehrbar (nur 2^32 mögliche Werte); HMAC mit einem geheimen Schlüssel ist es nicht.
Audit-Protokollierung
Das Erstellen, Aktualisieren und Löschen von QR-Codes; Benutzereinladungen und Rollenänderungen; Schlüsselrotation; Abrechnungsänderungen; sowie das Erstellen und Widerrufen von Zugriffslinks werden alle in einem mandantenbezogenen Audit-Protokoll aufgezeichnet.
DSGVO-Datenexport
Ein Mandanteneigentümer kann einen vollständigen Export seiner Daten, einschließlich QR-Datensätzen und Metadaten, direkt über sein Konto anfordern — ohne Support-Ticket.
Crypto-Shredding zur Löschung
Die Löschung vernichtet zuerst den DEK des Mandanten. Ohne ihn wird jeder unter diesem Schlüssel verschlüsselte Inhalt dauerhaft unwiederbringlich; anschließend werden die verbleibenden Metadaten endgültig gelöscht — eine irreversible Aktion, abgesichert durch eine getippte Bestätigung.
// 07 · Transport und Verschlüsselung im Ruhezustand
Was verschlüsselt ist — und wo
| Daten | Schutz | Hinweise |
|---|---|---|
| QR-Inhalte | AES-256-GCM (DEK des Mandanten) | qr_id + tenant_id als AAD gebunden |
| Mandanten-DEK | KMS-verpackt | Klartext-DEK wird nie auf die Festplatte oder in Redis geschrieben |
| Benutzer-E-Mail | AES-256-GCM (eigener PII-Schlüssel) | Suche über HMAC-Hash, nicht über Klartext |
| Passwörter | argon2id (Einweg) | Niemals umkehrbar gespeichert |
| IP-Adressen | HMAC-SHA256 (Server-Geheimnis) | Nur Zugriffsprotokolle; rohe IP wird nie gespeichert |
| Zugriffslink-IDs | Hash der undurchsichtigen ID gespeichert | Rohe ID wird nie in die Datenbank geschrieben |
| Bei der Übertragung | TLS 1.3 (Cloudflare) | HSTS-Preload; Überwachung der Zertifikatstransparenz |
// 08 · Lieferantenbewertung
Fragen, die eine Sicherheitsprüfung stellt
Die Fragen, die ein Compliance- oder Beschaffungsprüfer üblicherweise stellt, direkt beantwortet — es werden keine Zertifizierungen behauptet, die wir nicht besitzen.
- Ja. Jeder QR-Inhalt wird mit AES-256-GCM verschlüsselt, bevor er den Speicher erreicht, und zwar unter einem Schlüssel, der nur dem besitzenden Mandanten zugeordnet ist. Die Datenbank und jedes Backup enthalten nur Chiffrat.
- Es gibt keinen dauerhaften Weg. Der einzige Code, der entschlüsselt, ist derselbe abgesicherte Betrachterablauf, den jeder Endnutzer passieren muss — es gibt keinen Admin- oder Support-Endpunkt, der Klartext zurückgibt. Das für diese einzelne Anfrage verwendete entschlüsselte Schlüsselmaterial befindet sich nur im Server-Prozessspeicher, für die Dauer der Anfrage, und wird danach verworfen.
- Ein Angreifer erhält Chiffrat und einen KMS-verpackten Data Encryption Key (DEK) — beides ohne den KMS-Master-Schlüssel nutzlos. Der Klartext-DEK wird nie in Redis, auf die Festplatte oder in einen ruhenden Speicher geschrieben; er existiert nur vorübergehend im Anwendungsspeicher.
- Ein Magic Link ist eine kurze, zufällige, undurchsichtige ID, die serverseitig zu einem zustandsbehafteten Datensatz aufgelöst wird — kein eigenständiges JWT, daher gibt es keine Ansprüche, die leaken könnten. Referrer-Policy: no-referrer ist auf jeder /a/*- und /q/*-Antwort gesetzt, und das Token wird nach dem ersten Austausch aus der URL entfernt.
- Ja, auf drei Ebenen: Jeder Mandant hat einen eigenen Data Encryption Key; jedes Chiffrat ist als zusätzliche GCM-authentifizierte Daten an seine qr_id und tenant_id gebunden, sodass ein in einen anderen Mandanten verschobenes Chiffrat nicht entschlüsselt werden kann; und jede mandantenbezogene Tabelle trägt eine tenant_id, die durch PostgreSQL Row-Level Security als mehrschichtige Verteidigung durchgesetzt wird.
- Ein zeitlich begrenzter Magic Link ist der Standard. Eigentümer können zusätzlich eine PIN verlangen (gehasht, ratenbegrenzt mit einer Sperre nach wiederholten Fehlversuchen) oder einen Einmalcode per E-Mail (Ablauf nach 5 Minuten, begrenzte Versuche). Ein QR-Code kann zudem in den öffentlichen Modus versetzt werden, wodurch das Zugangstor nur für diesen QR-Code entfällt, während der Inhalt im Ruhezustand verschlüsselt bleibt — jeder QR-Code ist standardmäßig abgesichert, und der öffentliche Modus ist eine bewusste, auf den einzelnen QR-Code bezogene Aktivierung.
- Noch nicht im verwalteten Cloud-Angebot — der KMS-Master-Schlüssel wird in unserem Cloud-Konto bereitgestellt und ist eng auf ausschließliches Ver-/Entschlüsseln beschränkt. Self-hosted-Bereitstellungen ermöglichen es Ihnen bereits, Ihren eigenen Master-Schlüssel bereitzustellen. Eine BYOK-Option (kundenverwaltete Schlüssel) für das verwaltete Produkt steht auf der Roadmap und ist heute noch nicht ausgeliefert.
- Ja. Ein Mandanteneigentümer kann einen vollständigen Datenexport anfordern oder die Löschung über sein eigenes Konto auslösen. Die Löschung vernichtet zuerst den Data Encryption Key des Mandanten (Crypto-Shredding, wodurch jedes vorhandene Chiffrat dauerhaft unwiederbringlich wird) und löscht anschließend die verbleibenden Metadaten endgültig — eine irreversible Aktion, abgesichert durch eine getippte Bestätigung.
- Ja. Das Erstellen, Aktualisieren und Löschen von QR-Codes; Benutzereinladungen und Rollenänderungen; Schlüsselrotation; Abrechnungsänderungen; sowie das Erstellen und Widerrufen von Zugriffslinks werden alle in einem auf den Mandanten bezogenen Audit-Protokoll aufgezeichnet.
- Derzeit nicht. Wir beschreiben die Kontrollen, die wir tatsächlich haben — Envelope-Verschlüsselung, Schlüsselisolierung pro Mandant, kein Klartext im Ruhezustand, widerrufbare zustandsbehaftete Zugriffslinks, Audit-Protokollierung — und werden keine Zertifizierung behaupten, die wir nicht besitzen. Wenn Ihre Bewertung eine erfordert, kontaktieren Sie uns, um die Roadmap zu besprechen.
// 09 · Kontakt
Sicherheitslücke melden
Wenn Sie ein Sicherheitsproblem finden, kontaktieren Sie uns bitte direkt, bevor Sie es öffentlich machen. Siehe unsere Sicherheitsrichtlinie für Umfang, Safe-Harbour-Bedingungen und Reaktions-SLAs. Wir bestätigen Meldungen innerhalb von 3 Werktagen und arbeiten mit Forschenden an einer verantwortungsvollen Lösung.