01Ausgangslage: revDSG und sensible Daten in Formularen
Mit dem Inkrafttreten des revidierten Schweizer Datenschutzgesetzes (revDSG) stehen Unternehmen vor einer zentralen Frage: Wie können sensible Kundendaten – insbesondere Gesundheits- oder Finanzdaten – über Online-Formulare rechtssicher und geschützt erhoben werden?
Viele Standard-Formular-Tools speichern Antworten im Klartext in ihren Datenbanken. Bei einem potenziellen Data Breach oder unbefugtem internen Zugriff liegen diese Informationen offen. Formsly geht einen entscheidenden Schritt weiter: Wir verschlüsseln sensible Daten bereits auf Applikationsebene, bevor sie in die Datenbank geschrieben werden.
In diesem Artikel zeigen wir die technische Architektur dahinter und erklären, wie sie die strengen Vorgaben des Schweizer DSG praktisch unterstützt.
02Der Standard: Server-Side Encryption (At Rest Encryption)
Die meisten modernen Cloud-Datenbanken bieten Encryption at Rest. Das schützt primär den physischen Datenträger – etwa bei einem Diebstahl von Storage-Hardware aus dem Rechenzentrum.
Wird jedoch die Datenbank selbst kompromittiert oder ein privilegierter Zugriff missbraucht, liegen Daten häufig weiterhin im Klartext vor. Für besonders schützenswerte Personendaten reicht das allein in vielen Szenarien nicht aus.
03Der Formsly-Ansatz: Application-Level Encryption mit AES-256-GCM
Formsly verschlüsselt Formularantworten in der Applikationslogik, bevor sie in der Supabase-Datenbank gespeichert werden. Dadurch wird die Vertraulichkeit unabhängig von der reinen Datenbankverschlüsselung gestärkt.
Zum Einsatz kommt AES-256-GCM (Advanced Encryption Standard mit Galois/Counter Mode). Dieser Modus liefert nicht nur Vertraulichkeit, sondern prüft beim Entschlüsseln auch kryptografisch die Integrität. Manipulierte Datenblöcke werden erkannt und abgewiesen.
04Kryptografischer Prozess im Detail
1) Key Derivation (PBKDF2): Der eigentliche Schlüssel wird über PBKDF2 mit 100'000 Iterationen abgeleitet, statt direkt verwendet zu werden.
2) Dynamischer Salt: Für jede Verschlüsselung erzeugt Formsly einen kryptografisch sicheren, zufälligen Salt (16 Bytes). Das reduziert die Angriffsfläche gegenüber vorberechneten Tabellenangriffen.
3) Initialisierungsvektor (IV): Für AES-GCM wird pro Datensatz ein neuer, eindeutiger IV (12 Bytes) erzeugt.
4) Sichere Speicherung: Salt, IV und Ciphertext werden in einem Base64-codierten Datenblock kombiniert gespeichert.
Ergebnis: Selbst bei einem hypothetischen direkten Lesezugriff auf Datenbankinhalte sind sensible Formulareingaben ohne getrennt verwaltetes Encryption-Secret nicht verwertbar.
05Was das für Ihre DSG-Compliance bedeutet (Art. 8 DSG)
Gemäss Art. 8 DSG müssen Personendaten durch angemessene technische und organisatorische Massnahmen (TOMs) geschützt werden. Die Formsly-Architektur unterstützt zentrale Anforderungen direkt auf technischer Ebene.
Vertraulichkeit: Nur berechtigte Instanzen können Formulareingaben im Klartext verarbeiten.
Integrität: Manipulationsversuche an gespeicherten verschlüsselten Daten führen bei AES-GCM zur Entschlüsselungsfehler-Erkennung.
Datenstandort: Die verschlüsselten Daten werden ausschliesslich in der Schweiz auf Exoscale-Infrastruktur (Zürich) verarbeitet und gespeichert.
06Fazit
Sicherheit darf bei Formularen kein Nachgedanke sein – insbesondere bei Gesundheitsdaten, Anamnesebögen oder sensiblen Kundeninformationen.
Bei Formsly ist moderne Kryptografie ein integraler Bestandteil der Produktarchitektur. Während wir uns um AES-GCM, PBKDF2 und sicheres Schweizer Hosting kümmern, können Sie sich auf Ihr Kerngeschäft und das Vertrauen Ihrer Kunden fokussieren.
Verschlüsselungs-Flow als Mermaid-Diagramm
Sie können den folgenden Mermaid-Code direkt in Ihrem Tooling (z. B. Mermaid Live Editor) verwenden, um das Diagramm zu rendern oder als Bild zu exportieren.
sequenceDiagram
autonumber
actor P as Patient (Browser)
participant F as Formsly App (Frontend / API)
participant K as Web Crypto API (AES-256-GCM)
participant DB as Supabase Datenbank (Exoscale Zürich)
P->>F: Formular absenden (Sensible Daten im Klartext)
rect rgb(234, 245, 255)
Note over F,K: Application-Level Encryption Phase
F->>K: Generiere zufälligen Salt (16 Bytes) & IV (12 Bytes)
F->>K: Leite Schlüssel ab (PBKDF2 mit Encryption Secret)
K-->>F: Starker AES-GCM Schlüssel
F->>K: Verschlüssele Formulardaten
K-->>F: Ciphertext (unlesbarer Datensalat)
F->>F: Kombiniere Salt + IV + Ciphertext
F->>F: Kodiere als Base64-String
end
F->>DB: Speichere Base64-String (INSERT)
Note over DB: Daten liegen verschlüsselt auf<br/>Schweizer Servern (Zero US-Cloud).<br/>Ohne das Secret sind sie wertlos.