Kreditverträge enthalten zwei der sensibelsten Datenkategorien, die es gibt: Finanzdaten und Identitätsdaten. Kreditbetrag, Zinssatz, Tilgungsplan, Bonität — kombiniert mit Name, Adresse, Geburtsdatum und Bankverbindung. Ein Datenleck in diesem Kontext ist nicht nur ein Compliance-Verstoß — es ist ein existenzielles Risiko für die betroffene Kanzlei und ihre Mandanten.
„Vertrauen ist die Währung jeder Kanzlei. Wer Mandantendaten in eine Cloud schickt, muss lückenlos nachweisen können, dass diese Daten geschützt sind — nicht irgendwann, sondern jetzt, in jedem einzelnen Request."
Warum Legal Tech besondere Sicherheitsanforderungen hat
Legal Tech unterscheidet sich fundamental von anderen SaaS-Kategorien. Anwälte unterliegen der Verschwiegenheitspflicht — ein Grundprinzip, das älter ist als jede Datenschutzverordnung. Die Kombination aus anwaltlicher Verschwiegenheitspflicht, DSGVO und branchenspezifischen Anforderungen erzeugt ein Sicherheitsniveau, das über Standard-Cloud-Security hinausgeht.
KLAGMA wurde von Grund auf für dieses Sicherheitsniveau konzipiert. Nicht als nachträgliches Feature, sondern als architektonisches Fundament. Das Ergebnis ist eine Zero-Trust-Architektur, die auf drei Säulen ruht.
Die 3-Säulen-Architektur von KLAGMA
| Säule | Komponente | Standort | Funktion |
|---|---|---|---|
| Säule 1 | Frontend & API-Gateway | AWS eu-north-1 (Stockholm) | Benutzerinteraktion, Authentifizierung, API-Routing |
| Säule 2 | Analyse-Backend | Wedel IT, Österreich | Dokumentenverarbeitung, Flowchart-Logik, Qualitätssicherung |
| Säule 3 | LLM-Processing | Azure OpenAI, EU-Region | Textverständnis, Extraktion, Klassifikation |
Die bewusste Trennung in drei unabhängige Infrastruktur-Säulen ist kein Zufall — sie ist das Kern-Designprinzip. Kein einzelner Anbieter hat Zugriff auf den vollständigen Datenfluss. Das Frontend kennt die Analyseergebnisse nicht im Detail. Das Analyse-Backend hat keinen Zugriff auf Benutzerdaten. Der LLM-Provider sieht nur anonymisierte Textfragmente, niemals vollständige Verträge oder personenbezogene Daten.
API-Sicherheit im Detail: Fünf Schutzschichten
Jeder API-Call zwischen den drei Säulen durchläuft fünf unabhängige Sicherheitsprüfungen. Das Prinzip: Fail-secure — wenn eine Prüfung fehlschlägt, wird der Request abgelehnt. Es gibt keinen Fallback, kein Degraded Mode, kein „wir loggen das und lassen es durch".
1. HMAC-Signaturprüfung
Jeder Request wird mit einem HMAC signiert. Der Empfänger berechnet den HMAC auf seiner Seite neu und vergleicht ihn mit der mitgesendeten Signatur. Stimmen sie nicht überein, wurde der Request manipuliert oder stammt nicht vom autorisierten Absender. Der Request wird sofort abgelehnt — ohne Fehlermeldung, die einem Angreifer Informationen liefern könnte.
2. Mutual TLS (mTLS)
Standard-HTTPS authentifiziert nur den Server gegenüber dem Client. Bei mTLS authentifizieren sich beide Seiten gegenseitig mit Zertifikaten. Das bedeutet: Selbst wenn ein Angreifer den Netzwerkverkehr abfangen könnte, kann er keine gültigen Requests senden — ihm fehlt das Client-Zertifikat.
3. IP-Whitelisting
API-Zugriffe sind auf bekannte IP-Adressen beschränkt. Requests von nicht-gelisteten IP-Adressen werden auf Netzwerkebene blockiert — bevor sie die Anwendungsschicht erreichen. In Kombination mit mTLS entsteht eine doppelte Zugangsbarriere.
4. Nonce-basierte Replay-Protection
Jeder Request enthält eine einmalige Nonce — einen kryptografischen Zufallswert, der in Redis gespeichert und nach Verwendung gesperrt wird. Ein abgefangener Request kann nicht erneut gesendet werden, weil die Nonce bereits verbraucht ist. Zusätzlich gilt ein 5-Minuten-Zeitfenster: Requests, deren Timestamp älter als 5 Minuten ist, werden verworfen.
5. Fail-Secure-Prinzip
Im Fehlerfall — sei es ein Timeout, ein ungültiges Zertifikat oder eine abgelaufene Nonce — wird der Request immer abgelehnt. Es gibt kein Fail-Open, kein Bypass, keine Ausnahme. Sicherheitsrelevante Fehler werden geloggt, aber die Fehlermeldung an den Aufrufer enthält keine diagnostischen Informationen, die einem Angreifer nützen könnten.
Zero-Trust bedeutet: Wir vertrauen weder dem Netzwerk, noch dem Absender, noch dem Zeitpunkt. Jeder einzelne Request muss sich vollständig legitimieren — ohne Ausnahme.
Verschlüsselung: Daten in Transit und at Rest
Die Verschlüsselungsstrategie von KLAGMA folgt dem Prinzip der maximalen Tiefenstaffelung:
| Schicht | Technologie | Zweck |
|---|---|---|
| Transport | TLS 1.3 / HTTPS | Verschlüsselung aller Daten in Transit |
| Objektspeicher | S3 SSE-S3 / SSE-KMS | Serverseitige Verschlüsselung gespeicherter Dokumente |
| Passwörter | bcrypt (Cost Factor 12) | Irreversible Passwort-Hashes |
| Session-Management | JWT mit RS256-Signatur | Authentifizierte, zeitlich begrenzte Sessions |
Privacy by Design: Datensparsamkeit als Architekturprinzip
Privacy by Design ist bei KLAGMA keine Compliance-Checkbox — es ist ein Architekturprinzip, das jede Designentscheidung beeinflusst:
- Minimale Datenerfassung: KLAGMA erhebt nur die Daten, die für die Analyse zwingend erforderlich sind. Keine Tracking-Pixel, keine Analytics-Cookies, keine Nutzerprofile.
- Presigned URLs für Dokumenten-Upload: Verträge werden nicht über die Anwendung hochgeladen, sondern direkt in den verschlüsselten S3-Bucket — über zeitlich begrenzte Presigned URLs, die nach einmaliger Nutzung verfallen.
- Kein Tracking: Keine Google Analytics, keine Facebook Pixel, keine Third-Party-Tracker. Punkt.
- Transiente LLM-Verarbeitung: Textfragmente, die an Azure OpenAI gesendet werden, werden nur für die Dauer der Verarbeitung gehalten. Keine Speicherung, kein Caching, kein Training.
DSGVO-Rollenverteilung: Wer ist verantwortlich?
Die DSGVO unterscheidet klar zwischen Verantwortlichen und Auftragsverarbeitern. In KLAGMAs Architektur ist die Rollenverteilung eindeutig definiert:
| Rolle | Organisation | Verantwortung |
|---|---|---|
| Verantwortlicher | Ventum IQ GmbH | Zweckbestimmung, Rechtsgrundlage, Betroffenenrechte |
| Unterauftragsverarbeiter | AWS (eu-north-1) | Infrastruktur Säule 1 — gebunden durch AVV |
| Unterauftragsverarbeiter | Wedel IT (Österreich) | Analyse-Backend Säule 2 — gebunden durch AVV |
| Unterauftragsverarbeiter | Microsoft/Azure OpenAI (EU) | LLM-Processing Säule 3 — gebunden durch Microsoft DPA |
Alle Unterauftragsverarbeiter sind durch Auftragsverarbeitungsverträge gemäß DSGVO Art. 28 gebunden. Die TOM (Technische und Organisatorische Maßnahmen) sind für jede Säule individuell definiert und werden regelmäßig auditiert.
Microsoft DPA: Kein Modelltraining mit Kundendaten
Ein häufiges Bedenken bei der Nutzung von LLM-APIs: Werden unsere Daten zum Training des Modells verwendet? Bei Azure OpenAI ist die Antwort vertraglich gesichert: Nein. Das Microsoft Data Processing Addendum (DPA) schließt explizit aus, dass Kundendaten für das Training von Foundation Models verwendet werden. Die Verarbeitung ist transient — nach Abschluss des API-Calls existieren die Daten nicht mehr im Azure-System.
Die Sicherheit einer Legal-Tech-Lösung bemisst sich nicht an der Anzahl der Zertifizierungen auf der Website. Sie bemisst sich an der Architektur — und an der Frage, ob Sicherheit nachträglich aufgeschraubt oder von Anfang an eingebaut wurde.
Incident Response und Monitoring
Zero-Trust endet nicht bei der Prävention. KLAGMAs Sicherheitsarchitektur umfasst ein umfassendes Monitoring- und Incident-Response-Framework:
- Real-Time-Alerting: Anomalien in API-Zugriffsmustern (ungewöhnliche Zeiten, Volumenspitzen, geografische Abweichungen) lösen sofortige Alerts aus.
- Audit-Logging: Alle sicherheitsrelevanten Ereignisse werden unveränderbar geloggt — inklusive erfolgreicher und fehlgeschlagener Authentifizierungsversuche.
- Automatische Sperrung: Nach 5 fehlgeschlagenen Authentifizierungsversuchen wird der Zugang temporär gesperrt. Nach 10 Versuchen erfolgt eine permanente Sperre mit manueller Freischaltung.
- Regelmäßige Penetrationstests: Externe Sicherheitsaudits überprüfen die Wirksamkeit aller Schutzmaßnahmen in realistischen Angriffsszenarien.
Fazit: Sicherheit als Wettbewerbsvorteil
Für Kanzleien, die Legal-Tech-Lösungen evaluieren, ist Sicherheit kein differenzierendes Feature — es ist eine Grundvoraussetzung. Doch die Tiefe und Konsequenz der Sicherheitsarchitektur unterscheidet professionelle Lösungen von solchen, die Sicherheit als Marketing-Claim behandeln.
KLAGMAs 3-Säulen-Architektur mit Zero-Trust-API-Sicherheit, durchgängiger Verschlüsselung, Privacy by Design und transparenter DSGVO-Rollenverteilung setzt den Standard für datensensible Legal-Tech-Anwendungen. Nicht weil Regulierung es verlangt — sondern weil das Vertrauen der Mandanten es verdient.
Für CIOs und CISOs bedeutet das: KLAGMA lässt sich in bestehende Sicherheitsarchitekturen integrieren, ohne Kompromisse einzugehen. Jede Schnittstelle, jeder Datenfluss, jede Speicherung ist dokumentiert, auditierbar und konform. Das ist keine Marketingaussage — das ist Architektur.