Technische und organisatorische Maßnahmen

1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)

Zutrittskontrolle und Serverstandort

• Der Betrieb erfolgt ausschließlich in Rechenzentren auf dem Gebiet der Bundesrepublik Deutschland. Infrastrukturanbieter ist die dogado GmbH, Dortmund (siehe Subprozessoren).
• Physische Zutrittssicherung, Brandschutz, unterbrechungsfreie Stromversorgung und Videoüberwachung liegen beim Rechenzentrumsbetreiber und richten sich nach dessen Zertifizierungen und vertraglichen Zusagen.
• Eigene Hardware wird nicht betrieben; es gibt keinen physischen Zugriff unsererseits.

Zugangskontrolle (Systemebene)

• Systemadministration ausnahmslos über verschlüsselte SSH-Verbindungen mit Public-Key-Authentifizierung. Passwort-Anmeldung ist serverseitig deaktiviert (PasswordAuthentication no).
• Kein direkter Root-Login; administrative Schritte laufen über ein unprivilegiertes Konto mit gezielter Rechteerhöhung.
• Paketfilter (ufw) mit Default-Deny; erreichbar sind ausschließlich SSH sowie 80/443 für den Reverse-Proxy.
• Sicherheitsaktualisierungen des Betriebssystems werden automatisch eingespielt (unattended-upgrades).
• Der Anwendungscontainer veröffentlicht keinen öffentlich erreichbaren Port; er ist ausschließlich über den Reverse-Proxy ansprechbar.

Zugangskontrolle (Anwendungsebene)

• Anmeldung mit E-Mail und Passwort; Passwörter werden ausschließlich als Hash mit Salt gespeichert, niemals im Klartext.
• Sitzungs-Cookies sind signiert und mit HttpOnly, Secure sowie SameSite=Lax gesetzt.
• Getrennte Rate-Limits für Anmeldung, Upload und API. Ein Anmeldeversuch in Serie sperrt dadurch nicht den produktiven Upload-Pfad.
• Keine öffentliche Selbstregistrierung: Zugänge werden ausschließlich vom Betreiber angelegt. Das hält die Angriffsfläche klein.

Zugriffskontrolle und Mandantentrennung

• Row Level Security in PostgreSQL. Die Mandantengrenze wird von der Datenbank erzwungen, nicht vom Anwendungscode. Die Rolle, mit der die Anwendung arbeitet, besitzt kein BYPASSRLS; ein Programmfehler kann die Grenze deshalb nicht überschreiten.
• Die Richtlinien sind auf Default-Deny gesetzt: Ist die Mandantenkennung für eine Transaktion nicht gesetzt, liefert die Datenbank keine Zeile – nicht etwa alle.
• Getrennte Datenbankrollen für Migration (Eigentümer), Anwendung und Betreibersicht. Die privilegierte Rolle wird ausschließlich dort verwendet, wo der Mandant noch nicht feststeht oder die Aufgabe mandantenübergreifend ist: Anmeldung per E-Mail, Auflösung eines API-Schlüssels, Einlösen eines Einladungslinks, Eintrag in die Warteliste sowie das Beanspruchen von Aufträgen aus der gemeinsamen Warteschlange. Die eigentliche Arbeit an Mandantendaten läuft anschließend wieder über die unprivilegierte Rolle.
• API-Schlüssel werden nur als SHA-256-Hash gespeichert und tragen Scopes (ingest, read, search, mcp, admin); ein Schlüssel für die Ablage kann nicht lesen, wenn ihm der Scope fehlt. Schlüssel sind einzeln widerrufbar.
• Schlüssel lassen sich an einen einzelnen Store binden. Ein gebundener Schlüssel erhält auf jedem Weg – Programmierschnittstelle wie MCP-Schnittstelle, lesend wie löschend – für andere Stores dieselbe Antwort wie für nicht vorhandene. Wird der Store gelöscht, erlischt der Schlüssel mit ihm, statt auf den ganzen Mandanten auszuweichen.

Trennungskontrolle

• Jeder Datensatz trägt eine Mandantenkennung; sämtliche Tabellen mit Mandantenbezug sind mit FORCE ROW LEVEL SECURITY versehen.
• Zusätzlich filtert die Anwendung selbst nach Mandant – Verteidigung in der Tiefe, nicht als Ersatz für die Datenbankdurchsetzung.
• Das gilt auch für die Suche: sie läuft über dieselbe Verbindung mit gesetzter Mandantenkennung. Der Ähnlichkeitsindex ist ein Näherungsverfahren und kennt die Mandantengrenze nicht; die Datenbank filtert deshalb nach dem Index und der Index wird so lange weitergelesen, bis genügend eigene Treffer vorliegen. Ergebnis: ein Mandant sieht keine fremden Abschnitte – auch keine Bruchstücke in der Trefferbewertung.
• Produktiv- und Entwicklungsumgebung sind vollständig getrennt; in der Entwicklung werden keine Kundendaten verwendet.

2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)

Transportverschlüsselung

• Sämtliche Schnittstellen – Weboberfläche wie API – sind ausschließlich über TLS erreichbar. Zertifikate werden automatisch bezogen und erneuert (Let's Encrypt); unverschlüsselte Aufrufe werden umgeleitet.
• Strict-Transport-Security (HSTS) ist mit einem Jahr Gültigkeit einschließlich Subdomains gesetzt.
• Ergänzende Schutz-Header: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer.

Der einzige ausgehende Aufruf

• Damit Dokumente durchsuchbar werden, wird jeder Textabschnitt einmalig an den AI Model Hub der IONOS SE (Verarbeitung in Deutschland) gesendet und dort in eine Zahlenreihe umgerechnet. Das ist der einzige Vorgang, bei dem wir von uns aus Inhalte an einen Dritten senden. Abrufe durch den Auftraggeber selbst – über die Programmierschnittstelle oder eine von ihm verbundene KI – sind im Abschnitt „MCP-Schnittstelle“ beschrieben.
• Auch die Suchanfrage selbst wird auf demselben Weg in eine Zahlenreihe umgerechnet – sonst ließe sie sich nicht mit den Abschnitten vergleichen. Übertragen wird der eingegebene Suchtext, sonst nichts. Suchanfragen werden bei uns nicht gespeichert und nicht protokolliert. Die reine Wortlaut-Suche (Volltext) läuft vollständig in unserer Datenbank, ohne jeden ausgehenden Aufruf.
• Keine Textgenerierung. Es ist kein Sprachmodell eingebunden, das Texte erzeugt, zusammenfasst oder bewertet – auch kein deutsches. Der Dienst bekommt einen Abschnitt und gibt Zahlen zurück.
• Die Übertragung erfolgt TLS-verschlüsselt gegen einen Endpunkt in Deutschland. Dieser Aufruf ist keine Drittlandübermittlung.
• Abschaltbar. Ohne hinterlegten Zugang findet der Aufruf nicht statt; Dokumente werden dann weiterhin umgewandelt, zerlegt und verwahrt, nur nicht durchsuchbar gemacht. Auf Wunsch schalten wir die Funktion je Mandant ab – dann verlässt kein Byte den Server.
• Keine Inhalte in Protokollen. Zu diesen Aufrufen werden ausschließlich Anzahl, Dauer und Fehlercode festgehalten, niemals der gesendete Text.

MCP-Schnittstelle für KI-Werkzeuge

• Unter annibox.de/mcp kann ein Auftraggeber eine KI seiner Wahl anbinden (Model Context Protocol). Die Schnittstelle ist ausschließlich lesend: Stores auflisten, suchen, Dokumente lesen. Hochladen, Ändern und Löschen sind über sie nicht möglich – auch nicht mit einem Schlüssel, der dazu berechtigt wäre.
• Zugang nur mit einem API-Schlüssel, der ausdrücklich die Berechtigung mcp trägt – auch admin schließt sie nicht ein; empfohlen gebunden an einen Store. Der Schlüssel wird geprüft, bevor die Anfrage gelesen wird. Jede Anfrage enthält genau einen Aufruf (keine Stapel), ist in der Größe begrenzt und je Mandant im Takt begrenzt; Suchen zählen zusätzlich je Schlüssel und gegen dieselbe Grenze wie über die Programmierschnittstelle.
• Anfragen aus einem Browser mit fremder Herkunft (Origin) werden abgewiesen – Schutz gegen DNS-Rebinding.
• Übermittlung an den Anbieter der KI: Suchtreffer und angeforderte Dokumentinhalte gehen an die KI, die der Auftraggeber verbunden hat – auf seine Weisung. Deren Anbieter ist kein Subprozessor des Auftragnehmers; eine Drittlandübermittlung dabei verantwortet der Auftraggeber.
• Abgerufene Inhalte werden nicht protokolliert, nur Werkzeugname und Mandant.

Architekturprinzip „Pull statt Push“

• annibox schreibt niemals selbsttätig in Quell- oder Zielsysteme Dritter. Die Systeme des Mandanten rufen die Inhalte mit ihrem eigenen Schlüssel ab. Es gibt folglich keine bei uns hinterlegten Zugangsdaten zu Kundensystemen, die abfließen könnten.
• Die Umwandlungs-Engine kennt keine Zielprodukte. Sie liefert ausschließlich Markdown und Metadaten zurück und trifft keine Entscheidung darüber, wohin etwas fließt.

Eingabekontrolle

• Serverseitige Allowlist zulässiger Dateitypen. Audiodateien sind vollständig ausgeschlossen; die zuständige Komponente der Umwandlungsbibliothek ist aus dem Dienst entfernt, weil sie Tonspuren an einen externen Spracherkennungsdienst übermittelt hätte.
• Archive (ZIP) sind in der Voreinstellung ausgeschlossen und werden nur für einzelne Auftraggeber freigeschaltet. Auch dann wird ein Archiv erst nach ausdrücklicher Bestätigung entpackt; der Auftraggeber sieht vorher die Liste der enthaltenen Dateien. Verarbeitet werden ausschließlich Mitglieder mit zulässigem Dateityp, verschachtelte Archive gar nicht. Anzahl, entpackte Gesamtgröße und Kompressionsverhältnis sind begrenzt.
• Zusätzlich wird geprüft, ob der Inhalt einer Datei zu ihrer Endung passt. Eine als PDF benannte Archivdatei wird abgewiesen – sonst ließe sich die Allowlist über den Dateinamen umgehen.
• Größenbegrenzung greift in zwei Stufen: zuerst am Reverse-Proxy, dann in der Anwendung noch vor dem Einlesen des Datenstroms. Eine übergroße Datei wird abgewiesen, bevor sie überhaupt zwischengespeichert wird.
• Authentifizierung wird ebenfalls vor dem Einlesen des Inhalts geprüft.
• Änderungen an Dokumenten erzeugen eine neue Version; die vorherige bleibt referenzierbar. Dubletten werden über eine Prüfsumme der Quelldatei erkannt. Verarbeitungsvorgänge werden als Jobs mit Zeitstempel, Status und Fehlertext protokolliert – nachvollziehbar, wer wann was eingestellt hat.

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b, c DSGVO)

• Container-Härtung: Ausführung als unprivilegierter Benutzer (nicht root), schreibgeschütztes Dateisystem, flüchtige RAM-Disk für Temporärdaten sowie feste Grenzen für Arbeitsspeicher und Prozessanzahl.
• Begrenzte Parallelität: Gleichzeitige Umwandlungen sind gedeckelt. Bei Überlast antwortet der Dienst mit einem klaren Fehler, statt eine unbegrenzt wachsende Warteschlange aufzubauen.
• Harte Zeitgrenze: Jede Umwandlung läuft in einem eigenen Teilprozess mit eigener Prozessgruppe. Läuft sie zu lange, wird die gesamte Gruppe beendet – auch die von der Texterkennung gestarteten Hilfsprozesse bleiben nicht als Waisen zurück.
• Aufwendige Verarbeitung läuft als Hintergrund-Job, damit Lastspitzen den interaktiven Betrieb nicht ausbremsen.
• Wiederherstellbarkeit der Umgebung: Die gesamte Umgebung ist aus versionierten Artefakten reproduzierbar – Container-Abbild mit festgeschriebenen Abhängigkeiten, Deployment-Beschreibung und idempotente Datenbankmigrationen. Die Einrichtung eines Ersatzservers ist skriptiert.
• Datensicherung: Die Datenbank wird täglich automatisch gesichert (verschlüsselter Transport entfällt – die Sicherung verlässt den Server nicht). Die Sicherungen sind komprimiert, ausschließlich für den Dienstbenutzer lesbar und werden nach 14 Tagen automatisch überschrieben.
• Geprüfte Sicherungen. Jede Sicherung wird unmittelbar nach dem Schreiben auf Vollständigkeit geprüft, bevor ältere verfallen – ein abgebrochener Auszug ist sonst nicht vom vollständigen zu unterscheiden. Die Wiederherstellung ist skriptiert und wird in einer Wegwerf-Umgebung erprobt, ohne den Produktivbetrieb zu berühren. Eine ungeprüfte Sicherung gilt uns nicht als Sicherung.
• Automatischer Neustart der Dienste nach Absturz oder Server-Neustart.

4. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d DSGVO)

Datenschutz durch Technikgestaltung und Voreinstellung (Art. 25 DSGVO)

• Keine dauerhafte Speicherung der Originaldateien. Gespeichert wird das umgewandelte Markdown nebst wenigen technischen Metadaten und einer Prüfsumme. Was nicht gespeichert wird, kann nicht abfließen. Bis zum Ende der Verarbeitung liegt die Datei in der Datenbank (mandantengetrennt wie alle übrigen Daten) und wird danach gelöscht – der Preis dafür, dass ein Neustart keinen Auftrag verliert. Ein Archiv, das auf die Entscheidung über das Entpacken wartet, liegt bis zu dieser Entscheidung dort und wird danach – oder beim Verwerfen sofort – gelöscht.
• Aufträge überstehen einen Neustart. Verarbeitungsaufträge stehen in der Datenbank, nicht im Arbeitsspeicher, und werden mit einer Laufzeit-Reservierung bearbeitet. Bricht der Dienst ab, wird der Auftrag nach Ablauf der Reservierung wieder aufgenommen statt verworfen.
• Kein Sprachmodell zur Textgenerierung. Die Texterkennung läuft lokal im Container. Es ist kein Zugang zu einem generativen Sprachmodell konfiguriert, und Erweiterungen der eingesetzten Umwandlungsbibliothek sind abgeschaltet. Komponenten dieser Bibliothek, die von sich aus externe Dienste aufrufen könnten – Spracherkennung für Tonspuren sowie der Abruf fremder Webseiten – sind aus dem Dienst entfernt. Der einzige ausgehende Aufruf ist die oben beschriebene Vektorisierung bei IONOS; sie erzeugt keinen Text.
• Keine Inhalte für Modelltraining – weder für fremde noch für eigene Modelle.
• Kein Tracking, keine Web-Analyse, keine externen Schriftarten, kein CDN, keine Telemetrie.
• Geheimnisse ausschließlich über Umgebungsvariablen, dateisystemseitig auf den Dienstbenutzer beschränkt und nicht in der Versionsverwaltung.

Löschkonzept

• Löschungen sind kaskadierend in der Datenbank verankert: Mit einem Mandanten fallen Nutzer, Schlüssel, Stores, Dokumente, sämtliche Versionen und Jobs weg. Es gibt keinen Papierkorb und kein „weiches“ Löschen mit verstecktem Restbestand.
• Löschung auf Weisung des Auftraggebers erfolgt unverzüglich; auf Wunsch wird sie schriftlich bestätigt.
• Sicherungskopien: Gelöschte Daten sind in den täglichen Sicherungen noch bis zu 14 Tage enthalten und laufen dann automatisch aus. Ein gezielter Eingriff in bestehende Sicherungen findet nicht statt – er würde deren Beweiswert zerstören. In dieser Zeit sind die Daten in der Verarbeitung eingeschränkt: sie werden ausschließlich zur Wiederherstellung nach einem Zwischenfall verwendet.

Überprüfung und Auftragskontrolle

• Automatisierte Testfälle sichern insbesondere die sicherheitsrelevanten Pfade ab: Größen- und Authentifizierungsprüfung vor dem Einlesen, Wirksamkeit der Mandantentrennung, Rate-Limits.
• Abhängigkeiten sind über eine Sperrdatei festgeschrieben; Aktualisierungen erfolgen bewusst und nachvollziehbar.
• Änderungen sind vollständig versioniert und werden vor der Übernahme in den Betrieb geprüft; sicherheitsrelevante Befunde werden dokumentiert behoben.
• Der Kreis der Personen mit Zugriff auf Produktivsysteme ist auf den Betreiber beschränkt und zur Vertraulichkeit verpflichtet.
• Subprozessoren werden ausschließlich mit Vertrag zur Auftragsverarbeitung und ausschließlich mit Standort in Deutschland eingesetzt.

5. Noch nicht umgesetzt – ausdrücklich keine Zusicherung

Die folgenden Funktionen sind konzipiert, aber nicht Bestandteil des heutigen Betriebs. Solange sie hier stehen, existieren sie nicht:

• Anmeldung einer KI an der MCP-Schnittstelle per OAuth (für KI-Dienste im Browser). Heute gilt ausschließlich der API-Schlüssel.
• Webhooks zur Ereignisbenachrichtigung.
• Auslagerung der Sicherungen auf ein zweites, räumlich getrenntes System. Die täglichen Sicherungen liegen derzeit auf demselben Server wie die Datenbank. Das schützt gegen Fehlbedienung, fehlerhafte Änderungen und Datenverlust in der Datenbank – nicht gegen den Totalverlust des Servers.

Vor einer Inbetriebnahme werden diese TOMs entsprechend fortgeschrieben und betroffene Auftraggeber informiert. Es gilt weiterhin: Sollte für Einbettungen künftig ein Dienstleister erforderlich werden, kommen ausschließlich Anbieter mit Verarbeitung in Deutschland in Betracht – ein Rückgriff auf US-amerikanische LLM-Dienste ist ausgeschlossen.