Sicherheit der DocPilot-Plattform

Authentifizierung

Der Zugriff auf die API und die Anwendungen beruht auf einer tokenbasierten Authentifizierung, nicht auf einer klassischen Serversitzung.

• Passwort mit Argon2id gehasht; niemals im Klartext gespeichert. Mindestanforderungen: 10 Zeichen, Groß- und Kleinbuchstabe sowie eine Ziffer.
• Kurzlebiges JWT-Zugriffstoken (15 Minuten), übermittelt im Authorization-Header.
• Opakes Refresh-Token, serverseitig gehasht gespeichert und in einem httpOnly-Cookie übertragen (in der Produktion zusätzlich secure). Rotation bei jeder Erneuerung, mit Erkennung von Wiederverwendung.
• Bestätigung der E-Mail-Adresse vor der ersten Anmeldung verpflichtend.
• Zurücksetzen des Passworts über einen Einmal-Link (eine Stunde gültig).
• Team-Einladungen und Aktivierungslinks zum Beitritt zu einer Organisation.
• Ratenbegrenzung für Anmeldung, Registrierung und Anforderung zum Zurücksetzen des Passworts (Schwellenwert in der Anwendung und Schutz am Reverse-Proxy).
• Abmeldung der aktuellen Sitzung oder aller Sitzungen (Ungültigmachung der aktiven Token).

Berechtigungen

Die Zugriffsrechte werden über ein RBAC-Modell (Rollen und Berechtigungen) verwaltet, das serverseitig durchgesetzt wird.

• Vordefinierte Systemrollen: Organisationsadministrator, Manager, Freigebender, Benutzer, Leser.
• Granulare Berechtigungen (Dokumente, Verträge, Workflows, Mitglieder, Audit usw.), die durch Guards an jedem Endpunkt geprüft werden.
• Zusätzliche Geltungsbereiche: Abteilung, Bereich und Dokumentfreigaben — ein Mitglied sieht nur, was seine Rechte und sein Geltungsbereich erlauben.
• Separate Administrationskonsole für die Plattform, mit eigenen Berechtigungen und Guards.

Organisation und Arbeitsbereich

DocPilot ist mandantenfähig: Jede Organisation verfügt über einen isolierten Bereich.

• Die aktive Organisation wird über das Authentifizierungstoken festgelegt. Ein clientseitiger Header vom Typ „Organisation“ wird nicht zur Auswahl des Mandanten verwendet.
• Datenbankabfragen sind auf die Organisation beschränkt und werden durch PostgreSQL-RLS-Richtlinien verstärkt, sobald die Anwendungsrolle eingerichtet ist.
• Objekte werden unter einem eigenen Präfix pro Organisation gespeichert (`tenants/{id}/…`).
• Eine gesperrte Organisation kann sich nicht mehr authentifizieren.
• Automatisierte Isolationstests für Dokumente, Suche, Audit und organisationsübergreifende Zugriffe.

Speicherung

Die Dateien werden in einem S3-kompatiblen Objektspeicher außerhalb der Anwendungsdatenbank abgelegt.

• Privater Bucket: kein anonymer öffentlicher Zugriff.
• Serverseitige Verschlüsselung beim Schreiben angefordert (SSE-S3, AES-256).
• Dateizugriff über zeitlich begrenzte signierte URLs (Upload, Download, Vorschau).
• Unveränderliche Versionen: Eine neue Version wird hinzugefügt; das Original wird nicht stillschweigend überschrieben.
• Prüfung des Dateityps (Magic Bytes) beim Abschluss eines Uploads.
• Virenscan (ClamAV) im E-Mail-Eingangsprozess, vor OCR und Weiterleitung.

Übertragung

Die Kommunikation zwischen Clients und API ist auf Transport- und Anwendungsebene geschützt.

• HTTPS zwischen den Anwendungen (Web, Mobil) und der API.
• HTTP-Sicherheitsheader (Helmet): CSP-Richtlinie, Frame Deny, HSTS in der Produktion, nosniff.
• CORS auf die konfigurierten Ursprünge beschränkt, Authentifizierungs-Cookies nur für diese Ursprünge zugelassen.
• CSRF-Prüfung bei schreibenden Anfragen, wenn das Authentifizierungs-Cookie vorhanden ist (Prüfung von Origin / Referer).
• API-Antworten mit no-store gekennzeichnet (außer Health-Check und technischer Dokumentation).
• Ratenbegrenzung am Reverse-Proxy (API, Authentifizierung, Frontend).

Audit

Sensible Aktionen werden für die fachliche Nachvollziehbarkeit und den Support protokolliert.

• Audit-Protokoll pro Organisation, nur beschreibbar (append-only): keine API zum Ändern oder Löschen von Einträgen.
• Erfasste Aktionen: Authentifizierung, Dokumente, Workflows, Berechtigungen, Mitglieder und weitere sensible Ereignisse aus dem Produktkatalog.
• Angereicherte Metadaten (Nutzer, Datum, IP-Adresse, User-Agent, Anfragekennung); Geheimnisse werden vor der Speicherung entfernt.
• Ergänzendes Aktivitätsprotokoll für Dokumente zur Nachverfolgung einer Akte.
• Separates Audit-Protokoll für Vorgänge in der Plattformkonsole.

Vertraulichkeit

Die Vertraulichkeit der Daten beruht auf der technischen Trennung und auf den in der Datenschutzerklärung beschriebenen Zusagen.

• Hosting des Dienstes auf einer Cloud-Infrastruktur in der Europäischen Union.
• Anwendungsprotokolle mit Schwärzung sensibler Pfade (Passwörter, Token, Authorization-Header).
• Logische Löschung (Soft Delete) von Konten, Mitgliedschaften und Dokumenten je nach Produktablauf.
• Eingehende Webhooks werden vor der Verarbeitung geprüft (Signatur) (E-Mail-Eingang, Abrechnung).
• OCR-/KI-Anbieter werden pro Organisation ausgewählt; DocPilot beansprucht kein Training von Modellen mit Ihren Dokumenten.
• Einzelheiten zu Verarbeitungen, Speicherdauer und Betroffenenrechten: Datenschutzerklärung. Zusammenfassung der Praktiken: DSGVO-Seite.

Datenschutzerklärung lesen

Was DocPilot nicht beansprucht

Diese Seite beschreibt Maßnahmen, die im Produkt tatsächlich umgesetzt sind. Sie stellt keine Konformitätsbescheinigung dar.

• Es wird keine ISO-, SOC-2- oder HDS-Zertifizierung beansprucht.
• Auf dieser Website wird keine pauschale regulatorische Garantie angegeben.
• Multi-Faktor-Authentifizierung (MFA) und SSO (SAML / OIDC) werden derzeit nicht angeboten.

Zur DSGVO-Seite

Kontakt

Bei Sicherheitsfragen oder für einen Lieferantenfragebogen: social@docpilot-app.com.