Sicherheit und Auftragsverarbeitung

Aletura läuft als modularer Monolith auf Java 21 / Spring Boot — eine einzelne deployable Anwendung, keine Microservices. Der Volltext-Index (Lucene/BM25) liegt pro Anfrage im Prozess und ist auf die Sitzung begrenzt. Standard-Inferenz läuft über den konfigurierten Mistral-EU-Endpunkt (https://api.eu.mistral.ai); optionale BYOK-Anbieter (OpenAI, Azure OpenAI, Azure Claude) sind nur hinter einer Endpunkt-Allowlist erreichbar. Das Hosting erfolgt bei Scaleway in der EU.

• In transit: ausschließlich TLS/HTTPS.
• At rest: AES-256-GCM für gespeicherte Analysen (und mitgespeicherte Originaldokumente, wo die Speichern-Funktion das vorsieht), für BYOK- und Organisations-Schlüssel sowie für Unternehmenswissen. Schlüssel liegen als Konfiguration/Secrets außerhalb des Repositories; Schlüsselrotation über einen „previous key“ ist vorgesehen.
• Passwörter werden nur als Hash gespeichert.

Autorisierung basiert ausschließlich auf dem authentifizierten Principal und serverseitigen Organisations-/Abteilungs-Mitgliedschaften — niemals auf vom Client geschickten Plan- oder Konto-Headern. Arbeitsbereiche (Organization Workspaces) haben Rollen (Admin/Member) mit getrennten Rechten; Unternehmenswissen und Playbooks sind eigene, getrennt autorisierte und belegte Typen und können nie zu Klauseln eines hochgeladenen Vertrags werden. Roh-IPs werden weder geloggt noch gespeichert; das Gast-Kontingent wird über ein anonymes Geräte-Cookie plus einen gehashten IP-Missbrauchsschutz geführt.

Vor Indexierung und jedem Modellruf werden erkannte persönliche Identifikatoren deterministisch lokal durch anfragegebundene Platzhalter ersetzt; ein Ausgangs-Guard prüft jeden Prompt, und Modell-Antworten werden auf Schema, Canary-Lecks und unzulässige Felder validiert. Die Maskierung ist eine Pseudonymisierung mit Erkennunggrenzen — kein absoluter Schutz. Vertragsinhalte werden standardmäßig nicht gespeichert.

Uploads, gespeicherte Belege, Vergleichsinhalte und Folgefragen gelten als nicht vertrauenswürdige Daten. Anweisungsartige Texte in Dokumenten werden erkannt und als Daten behandelt — sie werden nie ausgeführt und können keine Werkzeuge, URL-Abrufe, Shells, E-Mails oder Persistenz auslösen. Prompts werden über einen JSON-isolierenden, sicheren Prompt-Builder erzeugt; nicht vertrauenswürdige Inhalte werden niemals in vertrauenswürdige Anweisungen interpoliert.

Pro Organisation führt Aletura ein Audit-Protokoll mit HMAC-SHA256-Integritätskette (Schlüsselrotation unterstützt). Die Aufbewahrung ist pro Workspace konfigurierbar: 30, 90 oder 365 Tage (Standard 90 Tage, `PUT /api/account/workspaces/{id}/audit/retention`), mit stündlichem Cleanup. Ein rate-limitierter CSV-Export steht zur Verfügung (`GET .../audit/export`).

Eine AVV-Vorlage nach Art. 28 DSGVO steht zum Download bereit und muss vom Kunden ausgefüllt und gegengezeichnet werden — der Abschluss erfolgt nicht automatisch: AVV-Vorlage (Deutsch, Markdown) · DPA template (English, Markdown).

• Audit-Protokolle: 30 / 90 / 365 Tage, pro Workspace wählbar (Standard 90 Tage).
• Gespeicherte Analysen und Originaldokumente: jederzeit durch den Nutzer löschbar; verschlüsselte Backups laufen mit der Backup-Retention der Bereitstellung aus.
• Kontolöschung löscht verknüpfte gespeicherte Ergebnisse (Kaskade).
• Ungespeicherte Vertragsinhalte, Indizes und Maskierungen sind kurzlebig und werden nach der Sitzung bzw. per TTL gelöscht.
• E-Mail-Verifizierungs- und Reset-Links sind einmalig, als Hash gespeichert und nach 24 h bzw. 30 Minuten ungültig.

SSO über Microsoft Entra ID (OIDC, mit PKCE) ist im Code vorhanden, aber noch nicht selbst bedienbar und in der Produkt-API als PLANNED markiert. Bis zur Freischaltung gilt die E-Mail-/Passwort-Anmeldung. Das Onboarding läuft derzeit sales-assisted über den Betreiber — die frühere „setup-required“-Platzhalteranzeige wird durch folgende Checkliste ersetzt:

1. Anfrage stellen: Kontakt über Kontaktformular oder paulcurcean@protonmail.com mit Angabe der gewünschten Organisation.
2. Tenant-ID bereitstellen: die Microsoft-Entra-ID-Tenant-ID des Kunden.
3. App-Registrierung: der Betreiber legt die Entra-App-Registrierung an und übermittelt Client-ID und Secret über einen sicheren Kanal (nie per E-Mail im Klartext).
4. Aktivierung: der Betreiber konfiguriert und aktiviert OIDC für den Workspace serverseitig.
5. Test: ein Test-Login über den Workspace-SSO-Test-Endpunkt (POST /api/account/workspaces/{id}/sso/test).
6. Rollout: Freischaltung für die Mitglieder der Organisation.

Aletura beansprucht keine Zertifizierung (z. B. ISO/IEC 27001) und keine Compliance, die nicht gemessen wurde. Die Maskierung hat Erkennunggrenzen; den aktuellen Validierungsstand der Analyse veröffentlicht Aletura auf der Methodik-Seite. Aletura ist keine Rechtsberatung — siehe AGB und Datenschutzerklärung.