Vertrag zur Auftragsverarbeitung

§ 1 Gegenstand, Dauer und Rangfolge

Der Kunde beauftragt den Anbieter mit dem Betrieb von Kastalia als gehostetem Dienst. Dabei verarbeitet der Anbieter personenbezogene Daten im Auftrag und nach Weisung des Kunden. Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO ist der Kunde.

PlatzhalterVollständiger Firmenname und Anschrift des Anbieters als Auftragsverarbeiter

Dieser Vertrag kommt mit dem Hauptvertrag zustande, läuft so lange wie dieser und endet mit ihm. Er endet frühestens, wenn alle personenbezogenen Daten nach § 11 gelöscht oder zurückgegeben sind.

In Datenschutzfragen geht dieser Vertrag den Allgemeinen Geschäftsbedingungen vor. Wird Kastalia im Netz des Kunden betrieben und erhält der Anbieter dabei keinen Zugriff auf personenbezogene Daten, findet dieser Vertrag keine Anwendung; ein Fernzugriff zur Unterstützung wird gesondert vereinbart.

§ 2 Art und Zweck der Verarbeitung

Zweck ist die Bereitstellung einer unternehmensweiten Wissensbasis und ihre Auslieferung an Menschen und Maschinen nach den Regeln, die der Kunde selbst setzt. Die Verarbeitung umfasst:

• Erheben und Speichern der vom Kunden eingestellten oder aus seinen Quellen abgerufenen Inhalte,
• Zerlegen der Inhalte in Textabschnitte und Übermitteln dieser Abschnitte an den vom Kunden eingestellten Endpunkt zur Berechnung von Vektoren (Embeddings),
• Speichern der Textabschnitte und Vektoren in einem durchsuchbaren Index,
• Auslesen und Ausliefern auf Anfrage über Oberfläche, REST-Schnittstelle, semantische Suche und MCP — jeweils gefiltert auf das, was der Anfragende sehen darf,
• Verwalten von Konten, Mitgliedschaften, Rollen, Gruppen, Einladungen und API-Schlüsseln,
• Löschen auf Weisung des Kunden, einschließlich der Erstellung eines Löschnachweises.

Eine Verwendung der Daten zu eigenen Zwecken des Anbieters findet nicht statt. Insbesondere werden Kundeninhalte nicht zum Training von Modellen verwendet.

§ 3 Art der personenbezogenen Daten

Konto- und Zugangsdaten

Anzeigename, E-Mail-Adresse, Passwort ausschließlich als scrypt-Hash, Zeitpunkt der Registrierung, Mitgliedschaften, Rollen und Gruppenzugehörigkeiten, Einladungen (E-Mail-Adresse, Ablaufzeitpunkt, Token nur als SHA-256-Hash), API-Schlüssel (nur Präfix und SHA-256-Hash).

Inhaltsdaten

Alles, was der Kunde als Wissensknoten einstellt oder aus seinen Quellen anbinden lässt — Text, Titel, Kategorien, Zielgruppen, Sichtbarkeitsregeln — einschließlich personenbezogener Daten, die darin enthalten sind. Welche das sind, bestimmt allein der Kunde.

Abgeleitete Daten

Textabschnitte und ihre Vektoren im Suchindex sowie die Angabe, welche Prinzipale einen Abschnitt sehen dürfen.

Verbindungsdaten der Quellen

Adressen und Zugangsdaten der angebundenen Systeme. Zugangsdaten liegen ausschließlich verschlüsselt (AES-256-GCM) und an Mandant und Zweck gebunden.

Protokolldaten

Ereignisse über Anlage, Änderung, Veröffentlichung und Löschung von Wissensknoten samt handelnder Person und Zeitpunkt sowie technische Zugriffsprotokolle. Anwendungsprotokolle enthalten weder Inhalte noch Suchanfragen im Klartext.

Besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO sind nicht vorgesehen. Stellt der Kunde solche Daten ein, teilt er es dem Anbieter vorher mit, damit gegebenenfalls zusätzliche Maßnahmen vereinbart werden können.

§ 4 Kategorien betroffener Personen

• Beschäftigte des Kunden, die den Arbeitsbereich nutzen oder in ihm genannt werden
• Ansprechpartner des Kunden für Vertrag, Abrechnung und Betrieb
• Personen, die in den eingestellten Inhalten vorkommen — etwa Kunden, Lieferanten oder Bewerber des Kunden
• Leserinnen und Leser öffentlich gestellter Wissensknoten, soweit dabei Zugriffsdaten anfallen

§ 5 Weisungsrecht des Verantwortlichen

Der Anbieter verarbeitet personenbezogene Daten ausschließlich auf dokumentierte Weisung des Kunden. Der Hauptvertrag, dieser Vertrag und die Einstellungen, die der Kunde in seinem Arbeitsbereich vornimmt, sind die Erstweisung.

Weitere Weisungen erteilt der Kunde in Textform an die vom Anbieter benannte Stelle. Mündliche Weisungen bestätigt der Kunde unverzüglich in Textform. Der Anbieter dokumentiert jede Weisung.

Hält der Anbieter eine Weisung für rechtswidrig, teilt er dies dem Kunden unverzüglich mit und darf ihre Ausführung aussetzen, bis der Kunde sie bestätigt oder ändert (Art. 28 Abs. 3 Satz 3 DSGVO). Eine Verarbeitung aufgrund einer gesetzlichen Verpflichtung teilt der Anbieter dem Kunden vorher mit, sofern das Gesetz das nicht verbietet.

§ 6 Vertraulichkeit

Der Anbieter setzt zur Verarbeitung nur Personen ein, die zur Vertraulichkeit verpflichtet sind oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen (Art. 28 Abs. 3 lit. b DSGVO). Die Verpflichtung gilt über das Ende der Tätigkeit hinaus.

Der Anbieter macht die eingesetzten Personen mit den für sie geltenden Datenschutzvorschriften und mit der Weisungsgebundenheit vertraut und wiederholt das in angemessenen Abständen.

Ein Zugriff auf Inhalte des Kunden findet nur statt, soweit er für die Erbringung der Leistung, für die Fehlersuche oder auf Weisung des Kunden erforderlich ist. Die Anwendung selbst arbeitet mit einer Datenbankrolle ohne Eigentümerrechte; ein administrativer Zugriff auf die Daten eines Mandanten verlangt einen gesonderten Zugang zum Datenserver.

§ 7 Technische und organisatorische Maßnahmen

Der Anbieter trifft die in Anlage 1 beschriebenen technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO. Anlage 1 ist Bestandteil dieses Vertrags.

Die Maßnahmen unterliegen dem technischen Fortschritt. Der Anbieter darf sie ändern, solange das Schutzniveau erhalten bleibt; wesentliche Änderungen dokumentiert er und teilt sie dem Kunden mit. Anlage 1 nennt zu jeder Maßnahme ihren Beleg und benennt ausdrücklich, was noch aussteht.

§ 8 Unterauftragsverarbeiter

Der Kunde stimmt dem Einsatz der in Anlage 2 genannten Unterauftragsverarbeiter zu (allgemeine schriftliche Genehmigung nach Art. 28 Abs. 2 Satz 2 DSGVO).

Einen Wechsel oder die Hinzunahme eines weiteren Unterauftragsverarbeiters teilt der Anbieter mindestens vier Wochen vorher in Textform mit. Der Kunde kann innerhalb von zwei Wochen aus einem wichtigen datenschutzrechtlichen Grund widersprechen; kommt keine Einigung zustande, kann er den Hauptvertrag zum geplanten Wechselzeitpunkt kündigen.

Der Anbieter wählt Unterauftragsverarbeiter sorgfältig aus, verpflichtet sie vertraglich auf Pflichten, die denen dieses Vertrags entsprechen, und bleibt dem Kunden gegenüber für ihre Leistung verantwortlich. Leistungen ohne Bezug zur Verarbeitung — etwa Telekommunikation oder Reinigung — sind keine Unterauftragsverarbeitung.

§ 9 Unterstützung bei den Rechten betroffener Personen

Der Anbieter unterstützt den Kunden mit geeigneten technischen und organisatorischen Maßnahmen dabei, Anträge betroffener Personen nach den Art. 12 bis 22 DSGVO zu beantworten. Was das Produkt dafür von sich aus mitbringt:

Auskunft und Datenübertragbarkeit (Art. 15, 20)

Der Kunde exportiert seine Inhalte jederzeit selbst — über die REST-Schnittstelle und über den Export des Arbeitsbereichs als tar-Archiv mit Markdown-Dateien und Metadaten als JSON. Eine Mitwirkung des Anbieters ist dafür nicht nötig.

Berichtigung (Art. 16)

Der Kunde bearbeitet und veröffentlicht Wissensknoten selbst; die Änderung wirkt sich auf Suche und Auslieferung aus, sobald der Index nachgezogen ist.

Löschung (Art. 17)

Einzelne Wissensknoten löscht der Kunde selbst. Für die Löschung des gesamten Arbeitsbereichs gilt Anlage 3. Für einzelne Beschäftigte sieht das Löschkonzept Krypto-Shredding vor — dieser Teil ist noch nicht gebaut und in Anlage 3 als offen gekennzeichnet.

Einschränkung (Art. 18)

Der Kunde kann die Sichtbarkeit eines Wissensknotens auf einzelne Prinzipale beschränken oder ihn zurückziehen; er ist dann auch über Suche und Schnittstellen nicht mehr auffindbar.

Wendet sich eine betroffene Person unmittelbar an den Anbieter, leitet er die Anfrage unverzüglich an den Kunden weiter und beantwortet sie nicht selbst.

§ 10 Unterstützung bei Sicherheit, Meldepflichten und Folgenabschätzung

Der Anbieter unterstützt den Kunden bei der Einhaltung der Art. 32 bis 36 DSGVO, soweit ihm das mit den ihm zur Verfügung stehenden Informationen möglich ist.

Eine Verletzung des Schutzes personenbezogener Daten meldet der Anbieter dem Kunden unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntnis, in Textform. Die Meldung beschreibt, soweit bekannt: Art des Vorfalls, betroffene Datenkategorien und ungefähre Zahl betroffener Personen, wahrscheinliche Folgen sowie ergriffene und vorgeschlagene Gegenmaßnahmen. Die Meldung an die Aufsichtsbehörde nach Art. 33 DSGVO obliegt dem Kunden.

Für eine Datenschutz-Folgenabschätzung stellt der Anbieter die Angaben aus diesem Vertrag und seinen Anlagen bereit. Anlage 1 nennt zu jeder Maßnahme ihren Beleg, sodass der Kunde sie prüfen und nicht bloß glauben muss.

§ 11 Löschung und Rückgabe nach Vertragsende

Nach Beendigung des Hauptvertrags löscht der Anbieter alle personenbezogenen Daten des Kunden oder gibt sie zurück — nach Wahl des Kunden. Das Verfahren, die Fristen und der Nachweis stehen in Anlage 3.

Der Kunde erhält einen maschinell erzeugten Löschnachweis mit den Zählwerten vor und nach dem Vollzug. Der Nachweis liegt bewusst außerhalb der gelöschten Daten und überdauert die Löschung.

Ausgenommen bleiben Daten, für die eine gesetzliche Aufbewahrungspflicht besteht — insbesondere Rechnungsdaten nach § 147 AO. Diese werden für die Dauer der Aufbewahrung in der Verarbeitung eingeschränkt und danach gelöscht. Wissensinhalte sind davon nicht betroffen.

§ 12 Nachweise und Kontrollen

Der Anbieter weist die Einhaltung seiner Pflichten nach Art. 28 Abs. 3 lit. h DSGVO nach. Vorrangig geschieht das durch Unterlagen:

• diese Seite mit Anlage 1, in der jede Maßnahme ihren Beleg im Quelltext oder in der Betriebsdokumentation nennt,
• das Prüfprotokoll des Rechenzentrumsbetreibers für die Standorte in Falkenstein,
• das Protokoll des vierteljährlichen Wiederherstellungs-Probelaufs,
• auf Anfrage: Auskunft zu einzelnen Maßnahmen in Textform, innerhalb von zwei Wochen.

Genügen diese Unterlagen im Einzelfall nicht, kann der Kunde nach Ankündigung mit einer Frist von vier Wochen während der üblichen Geschäftszeiten eine Kontrolle durchführen oder durch einen zur Verschwiegenheit verpflichteten Prüfer durchführen lassen, der kein Wettbewerber des Anbieters ist. Die Kontrolle darf den Betrieb nicht unangemessen stören und findet in der Regel einmal jährlich statt; bei einem konkreten Anlass auch häufiger.

Eine Kontrolle in den Räumen des Rechenzentrumsbetreibers findet nicht statt; dafür tritt dessen Prüfprotokoll ein. Kosten einer über die Unterlagen hinausgehenden Prüfung trägt der Kunde, sofern die Prüfung keinen erheblichen Mangel zutage fördert.

§ 13 Schlussbestimmungen

Änderungen dieses Vertrags bedürfen der Textform. Bei Widersprüchen zwischen diesem Vertrag und dem Hauptvertrag geht dieser Vertrag in Datenschutzfragen vor. Ist eine Bestimmung unwirksam, bleibt der übrige Vertrag wirksam.

Es gilt das Recht der Bundesrepublik Deutschland. Die Haftung richtet sich nach Art. 82 DSGVO und im Übrigen nach dem Hauptvertrag.

Anlage 1 Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Die folgenden Maßnahmen sind im Quelltext oder in der Betriebsdokumentation belegt; die Fundstelle steht jeweils dabei. Was noch nicht umgesetzt ist, trägt die Markierung „Noch offen" — eine Anlage, die Geplantes als Bestehendes ausgibt, ist im Streitfall wertlos.

A.1 Vertraulichkeit — Zutritt und Zugang

Zutrittskontrolle im Rechenzentrum

Die Server stehen im Rechenzentrumspark Falkenstein der Hetzner Online GmbH. Zutritt, Videoüberwachung, Brandschutz und Stromversorgung verantwortet der Betreiber und weist sie durch ein jährliches Prüfprotokoll nach (docs/plan/20).

Netzseitige Firewall vor jedem Server

Eine Cloud-Firewall lässt im Grundzustand nichts durch; offen sind nur 80 und 443, SSH und der Datenserver ausschließlich für hinterlegte Administrationsadressen (infra/modules/network/main.tf). Sie wirkt netzseitig und damit auch dort, wo Docker eine Firewall auf dem Host unterlaufen würde.

Getrennte Server, privates Netz

Anwendungsserver und Datenserver sind verschiedene Maschinen. Postgres und Qdrant lauschen ausschließlich auf der privaten Adresse und auf der Loopback-Adresse, niemals auf 0.0.0.0 (deploy/data/docker-compose.yml).

Härtung des Betriebssystems

SSH nur mit Schlüssel, kein Root-Login, eigener Dienstbenutzer, fail2ban und automatische Sicherheitsupdates werden beim Erstellen des Servers eingerichtet, nicht nachträglich (infra/modules/server/cloud-init.yaml.tftpl).

Anwendung ohne Root-Rechte im Container

Das Laufzeitabbild legt einen Systembenutzer an und wechselt zu ihm; Quelltext und Entwicklungsabhängigkeiten sind nicht enthalten (Dockerfile).

Transportverschlüsselung

Der vorgeschaltete Proxy erzwingt TLS mit automatisch bezogenen Zertifikaten (deploy/kamal/deploy.yml, docs/betrieb/einrichtung.md).

A.2 Vertraulichkeit — Zugriff und Authentisierung

Passwörter nur als scrypt-Hash

Passwörter werden mit scrypt gehasht und zeitkonstant verglichen; im Klartext werden sie nirgends gespeichert. Der Vergleich beim Anmelden antwortet auf eine unbekannte E-Mail-Adresse genauso wie auf ein falsches Passwort, damit die Antwort keine Adressen bestätigt (server/utils/account-deps.ts, server/features/accounts/authenticate-account.ts). Mindestlänge acht Zeichen (server/features/accounts/schemas.ts).

Versiegelte Sitzungs-Cookies

Die Sitzung liegt versiegelt im Cookie und enthält keine Befugnisse; diese werden bei jeder Anfrage neu aus den Ereignissen abgeleitet, sodass ein Rollenentzug sofort wirkt (server/utils/session.ts, auth.d.ts). Das Sitzungsgeheimnis kommt aus der Prozessumgebung; startet die Anwendung in Produktion mit dem Entwicklungsgeheimnis, bricht sie ab (server/utils/boot-check.ts).

API-Schlüssel nur als Hash

Ein Schlüssel wird genau einmal im Klartext ausgeliefert; gespeichert werden nur ein achtstelliges Präfix zur Wiedererkennung und ein SHA-256-Hash. Der Vergleich ist zeitkonstant (server/features/workspace/api-key.ts, server/features/workspace/queries.ts). Ein Test hält fest, dass der Klartext auch im Ereignis nicht vorkommt (server/features/workspace/api-keys.spec.ts).

Einladungen mit gehashtem Token und Ablauf

Einladungstoken bestehen aus 24 Zufallsbytes, werden nur als SHA-256-Hash gespeichert, zeitkonstant verglichen und laufen nach 14 Tagen ab (server/features/access/invitation-token.ts, server/features/access/issue-invitation.ts).

Bremse gegen Passwort-Durchprobieren

Zehn Anmeldeversuche je Adresse und Konto in 15 Minuten, zusätzlich 50 Versuche je Adresse, fünf Registrierungen je Adresse und Stunde, 60 Suchanfragen je API-Schlüssel und Minute; abgewiesen wird mit HTTP 429 und Retry-After (server/utils/rate-limits.ts). Der Zähler liegt auf Adresse und eingegebener E-Mail-Adresse, damit ein Angreifer nicht alle Nutzer hinter demselben Firmenanschluss aussperren kann.

Rollen, Gruppen und Befugnisse je Anfrage

Jede geschützte Route verlangt eine Befugnis aus einem festen Katalog; ohne Sitzung antwortet sie mit 401, ohne Befugnis mit 403. Vor jeder Befugnis steht die Prüfung, ob das Konto jetzt noch Mitglied ist (server/utils/tenant-context.ts, server/features/access/capabilities.ts).

Sichtbarkeit als Vorfilter, nicht als Nachfilter

Jeder Textabschnitt trägt die Menge der Prinzipale, die ihn sehen dürfen; die Suche filtert im Index, bevor sie Ergebnisse bildet. Ein nicht sichtbarer Wissensknoten wird wie ein unbekannter behandelt — 404, nie 403 (docs/plan/15, tests/unit/article-visibility.spec.ts).

A.3 Vertraulichkeit — Trennung der Mandanten

Die Trennung ist strukturell und hängt nicht an der Disziplin der Entwickler. Vier unabhängige Schlösser:

Row Level Security mit FORCE

Auf events und kb_chunks sind Richtlinien aktiv, und zwar mit FORCE ROW LEVEL SECURITY — sie gelten damit auch für den Eigentümer der Tabelle. Die Richtlinie vergleicht den aus dem Ereignis abgeleiteten Mandanten mit der Sitzungsvariablen app.current_tenant (server/core/db/migrate.ts).

Anwendungsrolle ohne Eigentümerrechte

Die Anwendung verbindet als kh_app: NOSUPERUSER, NOBYPASSRLS, NOCREATEDB, NOCREATEROLE, ohne Eigentum an den Tabellen. Auf events hat sie nur SELECT und INSERT — UPDATE, DELETE und TRUNCATE sind entzogen, der Ereignisspeicher ist damit auf Datenbankebene anfügend (deploy/data/initdb/01-app-role.sh, server/core/db/migrate.ts).

Selbstprüfung der Verbindung beim Start

Beim Start fragt die Anwendung die Datenbank, für wie privilegiert sie die Verbindung hält. Superuser, BYPASSRLS oder Eigentum an events brechen den Start ab; bis die Prüfung durch ist, antwortet jede Adresse mit 503 (server/core/db/runtime-role.ts, server/middleware/00-boot-gate.ts, tests/e2e/boot-guard.spec.ts). Ohne diese Prüfung wäre eine falsch gesetzte Datenbankadresse eine stille Aufhebung der Trennung.

Mandant je Transaktion, niemals je Verbindung

Der Mandant wird als SET LOCAL innerhalb der Transaktion gesetzt und ist nach dem Commit fort; ein Wechsel innerhalb einer Transaktion wird abgewiesen. Ohne diese Eigenschaft leckte der Wert hinter einem Verbindungspool in den nächsten Mandanten (server/core/db/tenant-scope.ts).

Eine Vektorsammlung je Mandant

Der Sammlungsname kb_v1_<Mandanten-Id> entsteht an genau einer Stelle und ist nicht konfigurierbar; zusätzlich trägt jeder Punkt den Mandanten als Payload-Feld und jede Suche den entsprechenden Pflichtfilter (server/core/ports/vector-index/qdrant.ts).

Nachgewiesen durch Tests gegen eine echte Datenbank

Die Prüfungen verbinden sich als kh_app und stellen fest: ohne gesetzten Mandanten keine Zeile, mit fremdem Mandanten keine Zeile, kein Schreiben in einen fremden Mandanten, kein Ändern und kein Löschen im Ereignisspeicher (server/core/db/tenant-scope.spec.ts). Über HTTP prüft tests/e2e/access.spec.ts dasselbe aus Sicht eines fremden Arbeitsbereichs — auch über einen API-Schlüssel.

A.4 Integrität — Weitergabe und Eingabe

Verschlüsselte Geheimnisse mit Datenschlüssel je Mandant

Zugangsdaten angebundener Quellen liegen mit AES-256-GCM verschlüsselt. Ein Datenschlüssel je Mandant wird seinerseits mit einem Hauptschlüssel aus der Prozessumgebung verpackt; Mandant und Zweck gehen als zusätzliche authentifizierte Daten in die Verschlüsselung ein, sodass ein Chiffrat in einem fremden Mandanten nicht zu entschlüsseln ist (server/core/crypto/secret-store.ts, server/core/crypto/master-key.ts). Belegt durch server/core/crypto/secret-store.spec.ts, einschließlich Schlüsselwechsel.

Schutz vor Anfragen ins eigene Netz

Adressen für Connectoren, Embedding-Endpunkt und Vektorstore stellt der Kunde selbst ein. Eine Prüfung blockt private Adressbereiche und Metadatendienste und lässt nur http und https zu; die einzige Ausnahme ist eine Freigabeliste aus der Prozessumgebung, die kein Kunde setzen kann (server/core/net/address-guard.ts, nuxt.config.ts).

Fremdantworten stehen in keiner Fehlermeldung

Fehlermeldungen nennen Ziel und Status, niemals den Antwortkörper des fremden Systems. Meldungen fremder Systeme werden gekürzt und von Zugangsdaten befreit, bevor sie in ein Ereignis gehen (Annahme J5, docs/plan/18 Abschnitt 6).

Eingabevalidierung an der Grenze

Jede Route prüft ihren Rumpf und ihre Abfrageparameter gegen ein Schema und antwortet sonst mit 400; zu große Rümpfe werden mit 413 abgewiesen (server/utils/api-errors.ts). Uploads sind auf 200 Dateien und 8 MB je Anfrage begrenzt (server/features/connectors/upload/connector.ts).

Nachvollziehbarkeit durch anfügende Ereignisse

Jede fachliche Änderung ist ein Ereignis mit handelnder Person und Zeitpunkt. Es gibt genau einen Codepfad, der Ereignisse löscht — die Mandantenlöschung, immer für den gesamten Arbeitsbereich, nie für einzelne Ereignisse (server/core/db/tenant-erasure.ts).

Zeitlimits für ausgehende Anfragen

Jede Connector-Anfrage hat ein Zeitlimit von 120 Sekunden je Anfrage und je Umleitungssprung; Vektorstore und Embedding-Endpunkt haben engere Grenzen. Eine schweigende Quelle belegt damit keinen Arbeitsplatz auf Dauer (Annahme J14).

Geheimnisse gelangen nicht ins Repository

Die Pipeline durchsucht Arbeitsverzeichnis und ausgeliefertes Browser-Bündel nach Schlüsselmustern und verweigert .env-Dateien, terraform.tfvars und Kamal-Geheimnisse (.gitlab/ci/secret-scan.yml).

A.5 Verfügbarkeit und Belastbarkeit

Tägliche Sicherung, verschlüsselt und nur anfügbar

Ein systemd-Timer erstellt täglich um 03:15 Uhr eine Sicherung mit restic auf eine Storage Box; restic verschlüsselt das Repository, und das Unterkonto darf nur anfügen. Aufbewahrung 30 Tage (deploy/backup/restic-backup.sh, deploy/backup/kastalia-backup.timer, deploy/backup/backup.env.example).

Vierteljährlicher Wiederherstellungs-Probelauf

Der Probelauf findet Anfang Januar, April, Juli und Oktober auf einem Wegwerf-Server statt und benutzt ausschließlich ein nur lesendes Unterkonto, damit ein Fehler die Produktionssicherung nicht beschädigen kann. Ein Backup, das nie zurückgespielt wurde, ist keins (deploy/backup/restore-drill.md).

Auslieferung ohne Ausfallzeit, Rücksprung auf einen Commit

Ein vorgeschalteter Proxy schaltet erst um, wenn die neue Fassung auf ihrem Gesundheitspfad antwortet; ausgeliefert wird immer auf einen Commit, niemals auf latest, sodass ein Rücksprung gezielt möglich ist (deploy/kamal/deploy.yml, docs/plan/20).

Migrationen als eigener Schritt

Schemaänderungen laufen vor der Auslieferung mit einer eigenen Verbindung des Eigentümers, nicht beim Start des Anwendungscontainers. Sonst bräuchte jeder Container Schemarechte (deploy/migrate/run-migration.sh, docs/plan/20).

Kontingente gegen Überlast

Registrierungen, Anmeldungen und Suchanfragen unterliegen Kontingenten; ein Arbeitsbereich ist eine Sammlung im Vektorstore, und deren Zahl ist begrenzt, weshalb schon die Registrierung gebremst wird (server/utils/rate-limits.ts, server/api/register.post.ts).

Ein einzelner Anwendungsserver Noch offen

Fällt der Anwendungsserver aus, ist die Anwendung bis zu seinem Ersatz nicht erreichbar. Das ist bewusst so entschieden und in docs/plan/20 als offener Punkt benannt. Eine Verfügbarkeit in Prozent wird deshalb nicht zugesagt.

A.6 Verfahren zur regelmäßigen Überprüfung

Automatisierte Prüfung bei jeder Änderung

Die Pipeline baut, prüft Typen, führt die Testsuiten aus, sucht nach Geheimnissen und liefert erst danach aus — Staging automatisch, Produktion nach ausdrücklicher Freigabe (.gitlab-ci.yml, docs/plan/20).

Tests, die die Schutzmaßnahmen selbst prüfen

Mandantentrennung gegen eine echte Datenbank und über HTTP, Kontingente, Verschlüsselung samt Schlüsselwechsel, Sammlungstrennung im Vektorstore, Adressprüfung, Löschvollzug und Löschnachweis — jeweils als eigene Suite (server/core/db/tenant-scope.spec.ts, tests/e2e/access.spec.ts, tests/e2e/rate-limits.spec.ts, server/core/crypto/secret-store.spec.ts, server/core/ports/vector-index/qdrant.spec.ts, server/features/erasure/erasure.spec.ts).

Infrastruktur als Code

Server, privates Netz, Firewall, Speicher und Sicherungen stehen als Code im Repository und werden nicht im Webbrowser zusammengeklickt (infra/). Damit ist jede Änderung an der Umgebung nachvollziehbar und überprüfbar.

Sicherheitsreviews Noch offen

Zwei dokumentierte Durchgänge mit Befunden und Entscheidungen stehen in ASSUMPTIONS.md, Abschnitt J. Ein regelmäßiger Rhythmus und eine externe Prüfung sind noch nicht festgelegt.

A.7 Was noch fehlt

Diese Punkte sind geprüft und im Repository nicht belegbar. Sie stehen hier, weil ein Kunde sie erfahren muss, bevor er unterschreibt — und nicht danach.

Verschlüsselung der Datenträger Noch offen

Eine Verschlüsselung der Festplatten oder Volumes des Datenservers ist nicht eingerichtet. Verschlüsselt sind belegbar: die Sicherungen (durch restic) und die Zugangsdaten angebundener Quellen (AES-256-GCM). Inhalte in Postgres und Qdrant liegen auf dem Datenträger unverschlüsselt; der Schutz beruht dort auf Zutritts-, Netz- und Zugriffskontrolle.

Sicherheits-Kopfzeilen der Antworten Noch offen

Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options und Referrer-Policy werden derzeit nicht gesetzt.

Ausdrücklicher Schutz vor Anfragefälschung von fremden Seiten Noch offen

Ein CSRF-Token oder eine Prüfung des Origin-Kopfes gibt es nicht. Es wirkt allein die Voreinstellung SameSite=Lax des Sitzungs-Cookies aus der eingesetzten Bibliothek; httpOnly, secure und die Lebensdauer sind im Repository nicht ausdrücklich gesetzt.

Dauerhafte Sperre eines Kontos nach Fehlversuchen Noch offen

Die Bremse gegen Passwort-Durchprobieren zählt im Arbeitsspeicher eines Prozesses. Sie beginnt nach einem Neustart von vorn und wirkt je Instanz getrennt (server/core/rate-limit.ts).

Prüfung hochgeladener Dateitypen Noch offen

Für Uploads gelten Grenzen für Anzahl und Größe, jedoch keine Liste erlaubter Dateitypen.

Krypto-Shredding für einzelne Beschäftigte Noch offen

Die Löschung einer einzelnen Person durch Vernichtung eines personenbezogenen Schlüssels ist im Löschkonzept vorgesehen und noch nicht gebaut (Annahme H5).

Auswertbares Zugriffsprotokoll in der Oberfläche Noch offen

Fachliche Änderungen sind als Ereignisse vollständig vorhanden; eine Oberfläche, die sie einem Datenschutzbeauftragten aufbereitet, gibt es noch nicht.

Passwortregeln über die Mindestlänge hinaus Noch offen

Es gilt eine Mindestlänge von acht Zeichen. Weitere Regeln, ein Abgleich gegen bekannte Passwortlisten und eine zweite Stufe der Anmeldung fehlen.

Anlage 2 Unterauftragsverarbeiter

Hetzner Online GmbH, Industriestraße 25, 91710 Gunzenhausen

Server, privates Netz, Firewall, Blockspeicher, Objektspeicher und Storage Box für Sicherungen. Verarbeitungsort: Rechenzentrumspark Falkenstein, Sachsen, Deutschland. Grundlage: Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO im Kundenkonto des Anbieters. Betroffen sind alle in § 3 genannten Datenarten, da sie auf dieser Infrastruktur liegen.

Embedding-Endpunkt

Für die semantische Suche werden Textabschnitte an einen OpenAI-kompatiblen Endpunkt übermittelt. Welcher das ist, stellt der Kunde in seinem Arbeitsbereich selbst ein. Steht dort ein Modell im eigenen Netz des Kunden oder des Anbieters, entsteht keine weitere Unterauftragsverarbeitung. Wählt der Kunde einen fremden Anbieter, ist dessen Einsatz seine eigene Entscheidung und in seinem Verzeichnis der Verarbeitungstätigkeiten zu führen; der Anbieter übermittelt dann nur, was der Kunde eingestellt hat.

Angebundene Quellen des Kunden

Beim Abgleich ruft der Dienst die vom Kunden angegebenen Systeme ab — etwa Notion, ein Markdown-Repositorium oder eine Website. Diese Systeme sind Quellen des Kunden und keine Unterauftragsverarbeiter des Anbieters. Die Zugangsdaten dazu liegen ausschließlich verschlüsselt.

Weitere Dienstleister für Abrechnung, Zahlungsabwicklung, Buchhaltung oder E-Mail-Versand trägt der Betreiber hier ein, sobald er sie einsetzt. Ein E-Mail-Versand ist für den Betrieb nicht erforderlich: Einladungen entstehen als kopierbarer Link in der Anwendung.

PlatzhalterWeitere Unterauftragsverarbeiter mit Zweck und Sitz

Anlage 3 Löschkonzept

Wer eine Löschung beweisen will, muss zuerst vollständig wissen, wo etwas liegt. Es sind genau vier Orte, und zwei davon werden regelmäßig vergessen.

C.1 Die vier Orte

1. Ereignisspeicher in Postgres (Tabelle events)

Alle Fachdaten als Ereignisse — Konten, Arbeitsbereiche, Rollen, Gruppen, Wissensknoten samt Fassungen, Quellen, Einstellungen. Gelöscht wird über den Mandanten-Scope.

2. Suchindex (Tabelle kb_chunks und Vektorsammlung kb_v1_<Id>)

Textabschnitte im Klartext und ihre Vektoren. Gelöscht wird die Sammlung als Ganzes und die Zeilen des Mandanten in kb_chunks.

3. Datenschlüssel (Tabelle tenant_keys)

Der mit dem Hauptschlüssel verpackte Datenschlüssel des Mandanten. Seine Vernichtung macht alle mit ihm verschlüsselten Geheimnisse wertlos — Krypto-Shredding.

4. Sicherungen und Protokolle

Kopien der ersten drei Orte sowie technische Protokolle. Dieser Ort ist der ehrliche Punkt: Eine Sicherung von gestern lässt sich nicht nachträglich umschreiben. Es wirkt deshalb die feste Aufbewahrungsfrist von 30 Tagen. Die Vernichtung des Datenschlüssels wirkt hier nur auf die Zugangsdaten der angebundenen Quellen; die Wissensinhalte selbst liegen im Klartext im Ereignisspeicher, weil die Suche über den Ereignissen darauf angewiesen ist.

Hochgeladene Dateien gehören zu Ort 1 beziehungsweise zum Objektspeicher und werden im selben Vorgang geleert; ihre Zahl steht im Löschnachweis.

C.2 Fristen

Karenzzeit vor dem Vollzug

14 Tage, auf Wunsch des Kunden null.

Sicherungen

30 Tage, danach laufen sie aus.

Anwendungsprotokolle

14 Tage, ohne Inhalte und ohne Suchanfragen im Klartext.

Einladungen

14 Tage bis zum Ablauf des Tokens.

Löschnachweise

Dauerhaft, außerhalb der gelöschten Daten. Sie enthalten nur Zählwerte, Zeitstempel, den Namen des Arbeitsbereichs und die E-Mail-Adresse der beauftragenden Person.

Rechnungsdaten

10 Jahre nach § 147 AO — Firmenname, Anschrift, Rechnungsbeträge. Keine Wissensinhalte.

C.3 Wie gelöscht wird

Die Löschung bestellt der Inhaber im Produkt oder schriftlich; im zweiten Fall führt sie ein Betreiber mit protokolliertem Auftrag aus. Der Ablauf steht fest:

• Sperren. Der Arbeitsbereich ist sofort für alle Zugriffe gesperrt — Anmeldung, Wechsel, Beitritt, API-Schlüssel und MCP. Die Sperre sitzt an der einen Stelle, an der aus einer Anfrage ein Mandant wird, und gilt auch für Hintergrundarbeit: Ein gesperrter Arbeitsbereich fragt seine Quellen nicht weiter ab. Herein kommt nur noch, wer den Löschvorgang selbst verwalten darf — sonst gäbe es nach dem nächsten Abmelden keinen Weg mehr zum Widerruf.
• Zählen. Was der Arbeitsbereich in diesem Augenblick trägt, wird gemessen und in der Beauftragung festgehalten. Diese Zahl ist später die Spalte „vorher" im Nachweis.
• Export anbieten (Art. 20). Alle Wissensknoten als Markdown plus Metadaten als JSON, abrufbar bis zum Vollzug — oder auf Wunsch sofortiger Verzicht.
• Karenzzeit von 14 Tagen gegen Fehlbedienung, auf Wunsch null.
• Vollzug in fester Reihenfolge: Vektorsammlung löschen und die Löschung beim Server nachfragen, Textabschnitte löschen, Ereignisse des Mandanten löschen, Datenschlüssel vernichten, hochgeladene Dateien leeren.
• Nachweis erzeugen und dem Kunden zustellen.
• Sicherungen laufen nach 30 Tagen aus. Bis dahin sind die Inhalte dort enthalten; die Zugangsdaten der angebundenen Quellen sind durch die Schlüsselvernichtung bereits wertlos. Die Zusage ist damit zweiteilig und beides ist prüfbar: aus dem laufenden System sofort und mit Zählwerten belegt gelöscht, aus den Sicherungen binnen 30 Tagen ausgelaufen.

Es gibt genau einen Codepfad, der Ereignisse löscht. Er löscht immer den gesamten Arbeitsbereich, nie einzelne Ereignisse. Selektives Löschen einzelner Ereignisse gibt es nicht und wird es nicht geben — das wäre Geschichtsfälschung und technisch der Anfang vom Ende der Nachvollziehbarkeit.

C.4 Wie der Nachweis aussieht

Der Löschnachweis ist ein maschinell erzeugtes Protokoll, das der Kunde bekommt und archiviert. Er nennt den Arbeitsbereich, Beauftragung und Vollzug mit Zeitpunkt und beauftragender Person und dann die Zählwerte:

• gelöschte Ereignisse mit der Zählung vorher und nachher,
• gelöschte Textabschnitte, vorher und nachher,
• die Vektorsammlung mit dem Ergebnis der Nachfrage beim Server — der Server bestätigt die Löschung, sie wird nicht behauptet,
• den Datenschlüssel: vernichtet (Krypto-Shredding),
• die Zahl der hochgeladenen Dateien, vorher und nachher,
• das Datum, bis zu dem die Sicherungen auslaufen,
• die Angabe, welche Daten aus gesetzlichen Gründen bleiben.

Die Zählungen vorher und nachher sind der eigentliche Beweis: Sie sind reproduzierbar und nachprüfbar, eine Beteuerung wäre es nicht. Vor dem Erstellen des Nachweises werden die Werte ein zweites Mal erhoben; weicht etwas ab, bricht der Vollzug ab, statt eine Zahl zu behaupten. Ein gescheiterter Vollzug ist reparierbar, ein falscher Nachweis nicht.

Der Nachweis liegt als Ereignis außerhalb des gelöschten Arbeitsbereichs und überdauert ihn. Abrufen kann ihn das Konto, das die Löschung beauftragt hat — nach dem Vollzug gibt es keine Mitgliedschaft mehr, an der eine Befugnis hängen könnte (server/features/erasure/proof.ts).