Licensed to be used in conjunction with basebox, only.
// sicherheit
Speicherung
Gilt für
Produkt: Cloud · Server · Zielgruppe: Sicherheits- / Compliance-Prüfer
Wo Dokumente, Embeddings, Chatdaten, Audit-Logs und Secrets gespeichert werden – und wie diese Speicherorte im Ruhezustand geschützt sind. Die Betriebssicht (Volumes, Storage Classes, Größen) steht unter Speicher; hier geht es um die Frage der Prüfer: Welche Daten liegen wo, wer kommt heran, was passiert im Backup?
Was wo liegt
| Daten | Speicherort | Enthält Personenbezug? | Anmerkung |
|---|---|---|---|
| Benutzer, Organisationen, Rollen, Gruppen, Einstellungen | PostgreSQL aisrv-db |
Ja – Namen, E-Mail-Adressen | Kern der Anwendung |
| Apps, App-Konfiguration, System-Prompt | aisrv-db |
Möglich (Inhalte des System-Prompts) | – |
| Audit-Log | aisrv-db |
Ja – Benutzerkennung, Zeitstempel, Client-Adresse; auf Stufe „Hoch“ zusätzlich Fragen und Antworten, serverseitig und getrennt vom Chatverlauf | 6 Monate, vom Administrator auf 3–36 Monate einstellbar (Aufbewahrung) |
| Konnektor-Zugangsdaten je Nutzer | aisrv-db, nur schreibend gespeichert |
Ja | Administratoren sehen sie nicht; nie in Produktionslogs |
| Chatverlauf | Lokal im Browser des Nutzers, nicht dauerhaft auf dem Server; keine Synchronisation zwischen Geräten (Chatverlauf & Daten) | Ja – Inhalte | Liegt beim Nutzer; Administratoren und basebox haben keinen Zugriff darauf |
| Dokumentabschnitte und Embeddings der Wissensbasen | PostgreSQL ragsrv-db (pgvector) |
Ja, wenn die Dokumente welchen enthalten – Embeddings sind aus dem Text ableitbar zu behandeln | Wächst mit der Zahl der Dokumente |
| Hochgeladene Dateien / Medien | Persistentes Volume AISRV_MEDIA_ROOT |
Ja, je nach Inhalt | Chat-Uploads und Wissensbasis-Dateien |
| Temporäre RAG-Dateien | /tmp/ragsrv (gemeinsames Volume) |
Ja, vorübergehend | Wird während der Verarbeitung genutzt |
| Identitäten, Realms, OIDC-Clients | PostgreSQL idp-db (Keycloak) |
Ja – Konten, ggf. Passwort-Hashes lokaler Konten | Bei LDAP-Federation bleiben Passwörter im Verzeichnis |
| Modellgewichte, Caches | Volumes von inference und ragsrv-support | Nein | Neu erzeugbar |
| Secrets: Datenbank-Passwörter, Keycloak-Admin, TLS-Schlüssel, Inferenz-/Registry-Schlüssel | Kubernetes-Secrets (etcd) | Nein, aber sicherheitskritisch | Zugriff über Kubernetes-RBAC |
Quelle für die Zuordnung: basebox-Komponenten → Was wo gespeichert wird.
Wo diese Speicher physisch sind
| Deployment | Physischer Ort | Wer hat administrativen Zugriff |
|---|---|---|
| basebox Cloud | Server von FAST LTA, betrieben von basebox, im Rechenzentrum der noris network AG in München-Ost, in Ihrer eigenen virtuellen Umgebung; Sicherungen in einem zweiten Rechenzentrum in Deutschland | basebox-Betrieb als Plattformbetreiber (Administrativer Zugriff); Sie über die Anwendung |
| basebox Server | Der Server des Kunden – in seinem Haus oder im Rechenzentrum von basebox | Ihr Platform Operator; basebox nur bei Beauftragung über Fernwartung |
| basebox Cloud (Übergangsbetrieb) | Bis zum Umzug gemeinsame Umgebung bei Hetzner in Nürnberg, logisch getrennt; Modellanfragen an Google Vertex AI in Frankfurt | basebox als Betreiber der Umgebung; Sie über die Anwendung |
Auf einem Server bleiben alle genannten Speicher im Kundennetz; nichts davon wird zu basebox gespiegelt (es gibt keine Telemetrie).
Schutz im Ruhezustand
Die basebox-Anwendung verschlüsselt gespeicherte Daten derzeit nicht selbst – die Infrastruktur-Richtlinie und der Sicherheitshinweis sagen das ausdrücklich. Der Schutz im Ruhezustand kommt von der Ebene darunter:
- Speicherebene: verschlüsselte Datenträger oder eine verschlüsselnde Storage Class (Server: Sache des Platform Operators; Cloud: basebox, Einzelheiten auf Anfrage).
- Zugriffskontrolle: Datenbanken sind nur im Cluster erreichbar, Zugangsdaten liegen in Secrets; Kubernetes-RBAC begrenzt, wer Secrets lesen darf; etcd-Verschlüsselung ist eine Cluster-Einstellung.
- Backups: enthalten dieselben Daten wie die Datenbanken – Dumps und Objektspeicher-Ziele müssen verschlüsselt und zugriffsbeschränkt sein (Backup & Wiederherstellung). In der Cloud sind die Sicherungen verschlüsselt.
Konsequenz für die Prüfung: Nehmen Sie die Speicherebene in Ihr Sicherheitskonzept auf; sie ist die Kontrolle, die die fehlende Anwendungsverschlüsselung ersetzt. Details: Verschlüsselung.
Besondere Datenkategorien
- Embeddings sind keine Anonymisierung. Aus Dokumentabschnitten und ihren Vektoren lässt sich der Inhalt rekonstruieren oder zumindest erschließen; behandeln Sie
ragsrv-dbwie die Dokumente selbst. - Wissensbasen (hochgeladene Dateien und beim Server Dateien von einem Netzlaufwerk) haben keine Rechteprüfung je Nutzer: Wer die App nutzen darf, kann alle ihre Dokumente über das Modell erreichen (Wissensbasen verwalten). Sensible Inhalte gehören hinter einen Konnektor mit persönlichen Zugangsdaten: Dort gelten die Rechte der Person im Zielsystem. Wer eine App teilt, teilt ihre Dokumente, nie den eigenen Zugang.
- Audit-Log mit Gesprächsinhalten ist die sensibelste Tabelle der Installation, sobald das Audit Log Level auf „Hoch“ steht – Zugriff begrenzen, Exporte schützen (Audit & Logging).
- Konnektor-Zugangsdaten sind nur schreibend gespeichert, aber in Datenbank-Dumps enthalten – Dumps entsprechend behandeln.
Was Nutzer sehen
Nutzer sehen ihre eigenen Chats und Uploads. Administratoren sehen Benutzer, Apps, Wissensbasen und das Audit-Log – nicht die Chats anderer Nutzer, außer über die ausdrücklich eingestellte Aufzeichnung im Audit-Log, die dann allen Nutzern im Chat angezeigt wird (Wo sind meine Daten?).
Nächster Schritt: Verschlüsselung · Aufbewahrung