Sicherheit im KI-Workplace
Welche Sicherheitsmechanismen den KI-Workplace absichern: von Sitzungsverwaltung über Passwort-Hashing bis zu Rate Limiting, SSRF-Schutz und verschlüsselter Token-Speicherung.
Der KI-Workplace setzt mehrere Sicherheitsmechanismen ein, um Benutzerkonten, Daten und die Kommunikation zwischen Client und Server zu schützen. Diese Seite fasst zusammen, was im Hintergrund passiert: als Nachschlagewerk für IT-Verantwortliche, Sicherheits-Owner und alle, die wissen wollen, wie der Workplace abgesichert ist.
📌 Bewusst technisch gehalten: Dieser Guide geht an manchen Stellen tief in die Implementierung. Wenn du eine kompaktere Einordnung suchst (was wird geschützt, mit welchem Schutzniveau, ohne Implementierungsdetails), findest du sie auf der Seite Sicherheit.
Sitzungsverwaltung
Die Authentifizierung basiert auf einem sitzungsbasierten System mit HTTP-Only-Cookies.
Funktionsweise
- Nach erfolgreicher Anmeldung wird eine Sitzung erstellt und ein Cookie an den Browser gesendet.
- Bei jeder weiteren Anfrage wird das Cookie automatisch mitgesendet und die Sitzung validiert.
- Die Sitzung wird bei Aktivität automatisch verlängert (Sliding Window).
Sitzungsparameter
| Parameter | Wert | Beschreibung |
|---|---|---|
| Inaktivitäts-Timeout | 3 Tage | Die Sitzung läuft nach 3 Tagen ohne Aktivität ab |
| Maximale Lebensdauer | 30 Tage | Absolutes Maximum, auch bei ständiger Aktivität |
| Cookie-Typ | HTTP-Only | Cookie ist nicht per JavaScript auslesbar |
| SameSite | Lax | Cookie wird nur bei gleichem Ursprung gesendet |
| Secure | Ja (Produktion) | Cookie wird nur über HTTPS übertragen |
📌 Sliding Window: Bei jeder authentifizierten Anfrage wird die Sitzung um weitere 3 Tage verlängert, solange die maximale Gesamtlebensdauer von 30 Tagen nicht überschritten ist. So müssen aktive Benutzer sich nicht ständig neu anmelden.
Passwort-Hashing
⚠️ Sicherheitshinweis: Passwörter werden niemals im Klartext gespeichert.
Alle Passwörter werden mit dem Argon2id-Algorithmus gehasht. Argon2id ist der Gewinner des Password Hashing Competition und gilt als einer der sichersten Algorithmen für die Passwortspeicherung. Er ist speziell gegen Brute-Force-Angriffe mit spezialisierter Hardware (GPUs, ASICs) geschützt.
CSRF-Schutz
Der KI-Workplace schützt sich gegen Cross-Site Request Forgery (CSRF) durch die Validierung von Origin- und Referer-Headern:
- Bei jeder zustandsändernden Anfrage (POST, PUT, DELETE, PATCH) wird der Origin-Header geprüft.
- Falls kein Origin-Header vorhanden ist, wird der Referer-Header als Fallback verwendet.
- Nur Anfragen von erlaubten Ursprüngen werden akzeptiert.
- In Kombination mit SameSite=Lax-Cookies bietet das einen umfassenden CSRF-Schutz.
Rate Limiting
Um die Plattform vor Überlastung und Missbrauch zu schützen, sind für verschiedene Endpunkttypen individuelle Rate-Limits konfiguriert:
| Endpunkt | Limit | Zeitfenster | Beschreibung |
|---|---|---|---|
| Authentifizierung | 5 Anfragen | 1 Minute | Login, Registrierung |
| Chat / LLM | 30 Anfragen | 1 Minute | Chat-Nachrichten und KI-Anfragen |
| API (allgemein) | 100 Anfragen | 1 Minute | Alle übrigen API-Aufrufe |
| Bildgenerierung | 5 Anfragen | 1 Minute | Bilderzeugung (kostenintensiv) |
| Uploads | 10 Anfragen | 1 Minute | Datei-Uploads |
| Sensible Aktionen | 3 Anfragen | 5 Minuten | Passwortzurücksetzung u.a. |
Bei Überschreitung des Limits erhält der Benutzer eine Fehlermeldung mit der Angabe, wann die nächste Anfrage möglich ist.
📌 Rate Limiting pro IP: Die Begrenzung erfolgt auf Basis der IP-Adresse. Alle Anfragen von derselben IP-Adresse teilen sich das jeweilige Limit.
Sicherheits-Header
Alle Antworten des Servers enthalten die folgenden Sicherheits-Header:
| Header | Wert | Schutz gegen |
|---|---|---|
| Content-Security-Policy | Restriktive Richtlinie | Cross-Site Scripting (XSS), Dateninjektionen |
| X-Frame-Options | DENY | Clickjacking |
| X-Content-Type-Options | nosniff | MIME-Type-Sniffing |
| X-XSS-Protection | 1; mode=block | XSS (Legacy-Browser) |
| Referrer-Policy | strict-origin-when-cross-origin | Ungewollte Weitergabe von Referrer-Informationen |
| Permissions-Policy | Eingeschränkt | Missbrauch von Browser-APIs (Kamera, Geolocation) |
Zusätzlich werden API-Antworten mit Cache-Control: no-store versehen, um das Caching sensibler Daten zu verhindern.
SSRF-Schutz
Bei benutzerdefinierten Tools, die externe URLs aufrufen, wird ein SSRF-Schutz (Server-Side Request Forgery) angewendet:
- Aufrufe an interne Netzwerkadressen (z.B.
localhost,127.0.0.1, private IP-Bereiche) werden blockiert. - Nur Anfragen an öffentlich erreichbare Adressen sind zugelassen.
- Verdächtige SSRF-Versuche werden im Audit Log protokolliert.
⚠️ Benutzerdefinierte Tools: Wenn du benutzerdefinierte Tools erstellst, die externe APIs aufrufen, stell sicher, dass die Ziel-URLs öffentlich zugänglich sind. Anfragen an interne Netzwerke werden aus Sicherheitsgründen automatisch blockiert.
Verschlüsselte OAuth-Token-Speicherung
OAuth-Tokens (digitale Zugangsschlüssel für externe Dienste, nicht zu verwechseln mit den Text-Token der KI-Modelle) für externe Verbindungen (z.B. SharePoint) werden serverseitig verschlüsselt gespeichert:
- Die Verschlüsselung erfolgt mit einem dedizierten Schlüssel (
CONNECTION_ENCRYPTION_KEY). - Tokens werden vor dem Speichern verschlüsselt und erst bei Bedarf entschlüsselt.
- Ohne den Verschlüsselungsschlüssel sind die gespeicherten Tokens nicht lesbar.
Weiterführende Themen
- Zugriffsrechte und Rollen: Wer was im Workplace darf, regelt das Rollen- und Berechtigungen-System.
- Admin-Konfiguration: Einstellungen, die Admins für die gesamte Instanz vornehmen, findest du im Admin-Einstellungen-Guide.
- Audit Log: Sicherheitsrelevante Ereignisse (z.B. SSRF-Versuche, fehlgeschlagene Logins) werden im Audit Log protokolliert. Mehr dazu in den Admin-Einstellungen.
Hintergründe zum Nachlesen
Kostenlose Lektionen, die das Konzept dahinter erklären.
War dieser Guide hilfreich?
Deine Rückmeldung fließt direkt in die nächste Überarbeitung ein.
