Unterlagen für Institutionen

Technische und organisatorische Maßnahmen

Diese Seite gibt einen strukturierten Überblick über die technischen und organisatorischen Maßnahmen, mit denen Acadex personenbezogene Daten schützt.

Die vollständige und für ein konkretes Vertragsverhältnis maßgebliche Fassung unserer TOM wird als eigenständiges Dokument versioniert und kann Bestandteil eines Auftragsverarbeitungsvertrags sein.

Was die TOM beschreiben

Technische und organisatorische Maßnahmen sollen nicht möglichst viele Sicherheitsbegriffe aufzählen.

Sie sollen nachvollziehbar machen, wie personenbezogene Daten tatsächlich geschützt werden.

Unsere TOM umfassen deshalb insbesondere:

• administrative Zugriffe und Berechtigungen,
• Authentifizierung,
• Verschlüsselung,
• Schlüssel- und Secret-Management,
• Trennung von Systemumgebungen,
• externe Verarbeitung,
• Logging und Product Metrics,
• Löschprozesse,
• Datensicherung und Wiederherstellung,
• Entwicklungs- und Deployment-Prozesse,
• Umgang mit Sicherheitsvorfällen,
• sowie die Überprüfung der eingesetzten Maßnahmen.

Die TOM beschreiben den Ist-Zustand.

Wir führen eine Maßnahme nur dann als bestehend auf, wenn sie technisch oder organisatorisch tatsächlich umgesetzt ist.

Eine geplante Maßnahme wird nicht dadurch zu einer bestehenden Sicherheitsmaßnahme, dass sie auf unserer Roadmap steht.

Deshalb können unsere öffentlichen Sicherheitsinformationen auch ausdrücklich benennen, was noch nicht umgesetzt ist.

Sicherheit & Datenschutz →

1. Administrative Zugriffe

Zugriff auf Produktionssysteme ist auf Personen beschränkt, die diesen Zugriff für Betrieb, Wartung oder Sicherheit benötigen.

Administrativer Serverzugriff erfolgt über personenbezogene SSH-Schlüssel.

Eine passwortbasierte SSH-Anmeldung ist deaktiviert.

Administrative Konten bei STRATO, Plesk und GitHub werden mit Multi-Faktor-Authentifizierung geschützt.

Zukünftige Administratoren erhalten individuelle Accounts.

Gemeinsam genutzte administrative Zugangsdaten sind nicht vorgesehen.

2. Authentifizierung von Nutzern

Acadex-Accounts werden derzeit über E-Mail-Adresse und Passwort authentifiziert.

Passwörter werden nicht im Klartext gespeichert.

Wir speichern ausschließlich mit Argon2id erzeugte Passwort-Hashes.

Für authentifizierte Zugriffe verwendet Acadex kurzlebige kryptografisch signierte Zugriffstoken.

Multi-Faktor-Authentifizierung für individuelle Acadex-Accounts sowie institutionelles SSO sind derzeit noch nicht allgemein verfügbar.

3. Verschlüsselung bei der Übertragung

Verbindungen zu Acadex werden über TLS verschlüsselt.

Das betrifft insbesondere die Übertragung zwischen:

• Browser und Anwendung,
• internen beziehungsweise angebundenen Diensten, soweit unterstützt,
• sowie externen APIs über verschlüsselte HTTPS-Verbindungen.

4. Verschlüsselung gespeicherter Inhalte

Besonders relevante Inhaltsdaten werden innerhalb unserer Anwendungsdatenbank zusätzlich feldweise mit AES-256-GCM verschlüsselt.

Dazu gehören insbesondere:

• Gesprächsinhalte,
• gespeicherte Erinnerungen,
• Inhalte hochgeladener Dokumente,
• Chat-Titel,
• gespeicherte Anfrageinhalte.

Der hierfür verwendete Schlüssel wird getrennt von der Anwendungsdatenbank verwaltet.

Eine alleinige Kopie der Datenbank reicht deshalb nicht aus, um diese Inhalte zu entschlüsseln.

5. Grenzen der feldweisen Verschlüsselung

Nicht sämtliche Daten können mit derselben feldweisen Verschlüsselung gespeichert werden.

Insbesondere bestimmte Texte, die für die semantische Suche innerhalb gespeicherter Erinnerungen benötigt werden, müssen technisch durchsuchbar bleiben.

Diese Daten werden derzeit nicht mit derselben feldweisen Verschlüsselung gespeichert.

Auch öffentlich verfügbare bibliografische Daten und bestimmte technische Metadaten unterliegen anderen Schutzanforderungen als private Gesprächsinhalte.

Diese Unterschiede dokumentieren wir bewusst, statt pauschal jede Speicherung als gleichartig verschlüsselt zu bezeichnen.

6. Secret- und Schlüsselmanagement

Dauerhafte Secrets werden in einem dafür vorgesehenen verschlüsselten Passwortmanager verwaltet.

Das Schlüsselmaterial für diesen Passwortmanager wird getrennt auf einem physischen Medium aufbewahrt und zusätzlich gesichert.

Zur Laufzeit werden die jeweils benötigten Secrets als Umgebungsvariablen in die entsprechenden Systeme eingebracht.

Der Schlüssel für die feldweise Verschlüsselung von Anwendungsinhalten wird getrennt von der Anwendungsdatenbank gespeichert.

Der Zugriff auf produktive Secrets ist derzeit auf den technischen Betreiber von Acadex beschränkt.

Secrets werden regelmäßig sowie bei konkretem Verdacht auf eine Kompromittierung ausgetauscht.

7. Trennung von Umgebungen

Produktions-, Entwicklungs- und Testumgebungen werden voneinander getrennt betrieben.

Produktionsdaten werden nicht regulär in Entwicklungs- oder Testumgebungen kopiert.

Dienste innerhalb der Produktionsumgebung werden soweit möglich über interne Netzwerke beziehungsweise definierte Schnittstellen voneinander getrennt.

Öffentlich erreichbare Dienste werden über die dafür vorgesehenen Zugriffswege bereitgestellt.

8. Externe Modellanbieter

Acadex ist nicht an einen einzelnen KI-Modellanbieter gebunden.

Welche Modellanbieter Daten erhalten dürfen, hängt von der jeweiligen Account- beziehungsweise Institutionskonfiguration ab.

Wenn ein externer Modellanbieter eine Anfrage verarbeitet, werden nur die für den jeweiligen Verarbeitungsschritt erforderlichen Informationen übermittelt.

Dazu können insbesondere gehören:

• aktuelle Nutzereingabe,
• relevanter Gesprächskontext,
• benötigte Erinnerungen,
• bibliografische Informationen,
• erforderliche Ausschnitte aus Dokumenten.

Die vollständige Account-Datenhaltung wird externen Modellanbietern nicht pauschal zur Verfügung gestellt.

9. Institutionelle Providerbeschränkungen

Für institutionelle Accounts können zugelassene Modellanbieter und Verarbeitungsprofile technisch eingeschränkt werden.

Eine entsprechende Vorgabe kann nicht durch die Auswahl eines anderen Modells innerhalb eines einzelnen Gesprächs umgangen werden.

So können institutionelle Anforderungen beispielsweise auf bestimmte:

• Anbieter,
• Regionen,
• API-Endpunkte,
• Retention-Einstellungen,
• Provider-Funktionen

beschränkt werden.

Welche Providerprofile für eine konkrete Institution zulässig sind, wird separat dokumentiert.

Externe Dienste & Unterauftragsverarbeiter →

10. Embeddings und interne Suchsysteme

Embeddings für die semantische Suche in gespeicherten Erinnerungen werden auf unserer eigenen Infrastruktur erzeugt.

Hierfür wird derzeit kein externer Embedding-Anbieter benötigt.

Auch die internen Such- und Vektorsysteme werden von Acadex selbst betrieben.

Dadurch müssen Inhalte nicht allein für Retrieval- oder Embedding-Zwecke an einen zusätzlichen externen Dienst übermittelt werden.

11. Operative Logs

Gesprächsinhalte werden nicht routinemäßig in operative Logs geschrieben.

Für technische Fehleranalysen können interne Nutzerkennungen protokolliert werden.

IP-Adressen werden insbesondere für technische Sicherheitsmaßnahmen wie Rate Limiting und Missbrauchsprävention verarbeitet.

Operative Logs werden grundsätzlich sieben Tage auf den Produktivsystemen vorgehalten.

Anschließend werden erforderliche Logs komprimiert und verschlüsselt auf einen getrennten Archivserver übertragen.

Die maximale Aufbewahrungsdauer dort beträgt derzeit drei Monate.

Der Zugriff auf diese Logs ist auf berechtigte Personen beschränkt.

12. Website-Statistiken

Acadex erstellt auf eigener Infrastruktur aggregierte Statistiken über Aufrufe ausgewählter Websitebereiche.

Dabei werden für den langfristigen Analytics-Datensatz insbesondere keine dauerhaften:

• Besucherkennungen,
• Browser-Fingerprints,
• vollständigen IP-Adressen,
• URL-Queryparameter,
• Suchbegriffe,
• vollständigen Referrer-URLs

benötigt.

Gezählt werden vor allem Seiten beziehungsweise definierte Seitenkategorien und Zeiträume.

Langfristige Website-Statistik und operative Serverlogs sind voneinander getrennte Verarbeitungszwecke.

13. Product Metrics

Zur Beurteilung der grundlegenden Nutzung und wirtschaftlichen Entwicklung verarbeitet Acadex eine begrenzte Menge definierter Produktzustände.

Dazu können insbesondere gehören:

• Registrierung,
• erstmalige Aktivierung einer zentralen Funktion,
• Beginn eines Researcher-Abonnements,
• Tarifwechsel,
• Kündigung.

Soweit möglich, werden diese Kennzahlen aus bereits vorhandenen Account-, Vertrags-, Billing- und Betriebsdaten abgeleitet.

Wir bauen keinen vollständigen Klickstream über die Nutzung einzelner Accounts auf.

14. Keine Inhaltsanalyse für Product Metrics

Für Product Analytics verwenden wir insbesondere nicht:

• Gesprächsinhalte,
• generierte Antworten,
• Inhalte hochgeladener Dokumente,
• gespeicherte Erinnerungen,
• individuelle Forschungsthemen,
• bibliografische Suchanfragen.

Die Auswahl der erfassten Metriken ist technisch so begrenzt, dass diese Inhalte für die vorgesehenen Unternehmens- und Produktkennzahlen nicht benötigt werden.

Unser Grundsatz lautet:

Wir messen, ob Acadex genutzt wird – nicht, was einzelne Menschen darin erforschen.

15. Datenminimierung bei neuen Metriken

Bevor wir neue Product Metrics einführen, prüfen wir, ob die gewünschte Aussage aus bereits vorhandenen Daten abgeleitet werden kann.

Kann beispielsweise eine Conversion-Rate aus bestehenden Registrierungs- und Vertragszeitpunkten berechnet werden, bevorzugen wir diese Ableitung gegenüber der Einführung zusätzlicher Tracking-Ereignisse.

Zusätzliche personenbezogene Eventdaten sollen nur entstehen, wenn sie für eine konkrete legitime Kennzahl tatsächlich benötigt werden.

16. Löschung einzelner Inhalte

Nutzer können insbesondere:

• Gespräche,
• gespeicherte Erinnerungen,
• hochgeladene Dokumente

selbst löschen.

Diese Löschung ist nicht von einer manuellen Supportanfrage abhängig.

17. Accountlöschung

Bei Löschung eines Accounts werden die zugehörigen personenbezogenen Nutzerdaten aus den aktiven Systemen entfernt, soweit keine gesetzlichen Aufbewahrungspflichten entgegenstehen.

Die Beziehungen innerhalb der primären Datenbank sind so angelegt, dass abhängige Datensätze in den Löschprozess einbezogen werden.

Zusätzlich existiert eine automatisierte Prüfung des Datenbankschemas, mit der Tabellen erkannt werden sollen, die personenbezogene Nutzerdaten enthalten, aber nicht von der vorgesehenen Löschlogik erfasst werden.

Auch relevante abgeleitete Daten in Such- und Vektorsystemen werden in den Löschprozess einbezogen beziehungsweise entsprechend rekonstruiert.

18. Product Metrics nach Accountlöschung

Accountbezogene Product-Metric-Daten werden grundsätzlich gemeinsam mit dem jeweiligen Account gelöscht, soweit keine andere gesetzliche Aufbewahrungspflicht besteht.

Bereits erzeugte Statistiken können erhalten bleiben, wenn sie so aggregiert wurden, dass keine Zuordnung zu einem einzelnen Account mehr möglich ist.

Eine anonymisierte Gesamtzahl wie die Anzahl der Registrierungen eines Monats wird deshalb nicht rückwirkend verändert, wenn später ein einzelner Account gelöscht wird.

19. Primäre und rekonstruierbare Daten

Nicht alle von Acadex verwendeten Datenbestände haben dieselbe Bedeutung für die Wiederherstellung.

Die PostgreSQL-Datenbank enthält die primären Account- und Nutzerdaten.

Andere Systeme enthalten überwiegend abgeleitete oder rekonstruierbare Informationen.

Dazu gehören insbesondere Teile von:

• Suchindizes,
• Vektordaten,
• bibliografischen Datensätzen.

Bibliografische Daten können zu großen Teilen aus externen wissenschaftlichen Primärquellen erneut aufgebaut werden.

Such- und Vektorsysteme können aus vorhandenen Primärdaten rekonstruiert werden.

Der Sicherung der primären PostgreSQL-Daten kommt deshalb eine besondere Bedeutung zu.

20. Datensicherung

Acadex erstellt eine separate Sicherung der PostgreSQL-Primärdaten.

Backup-Intervall: [vor Veröffentlichung ergänzen]
Aufbewahrungsdauer: [vor Veröffentlichung ergänzen]

Daneben werden in größeren Abständen vollständige Sicherungen umfangreicher Systemdaten erstellt.

Da große Teile dieser Daten rekonstruierbar sind, behandeln wir diese vollständigen Sicherungen anders als die Sicherung nicht ohne Weiteres rekonstruierbarer Account- und Nutzerdaten.

Die von Acadex verwalteten Backups werden in Deutschland gespeichert.

21. Daten in bestehenden Backups

Eine Löschung aus dem aktiven System führt nicht zwangsläufig dazu, dass sämtliche bereits bestehenden Sicherungskopien sofort technisch neu geschrieben werden.

Gelöschte Daten können deshalb bis zum Ablauf der jeweiligen Backup-Rotation noch in bestehenden Backups enthalten sein.

Diese Sicherungen werden nicht für den normalen Produktivbetrieb verwendet.

Nach Ablauf ihrer Aufbewahrungsdauer werden sie ersetzt beziehungsweise gelöscht.

Wird eine ältere Sicherung wiederhergestellt, sollen zuvor wirksam gelöschte Daten nicht dauerhaft erneut in den laufenden Produktivbestand übernommen werden.

22. Wiederherstellung

Backup-Verfahren sind nur sinnvoll, wenn Daten daraus wiederhergestellt werden können.

Deshalb gehört die Überprüfung des PostgreSQL-Wiederherstellungsverfahrens zu unseren technischen Maßnahmen.

Aktueller Testzyklus: [vor Veröffentlichung ergänzen]

Für den vollständigen Forschungsdatenbestand veröffentlichen wir derzeit keine garantierten Recovery-Time- oder Recovery-Point-Werte.

23. Verfügbarkeit

Acadex wird derzeit auf einer einzelnen Anwendungsinstanz betrieben.

Die Architektur kann technisch auf mehrere Instanzen erweitert werden.

Eine produktive Hochverfügbarkeitsarchitektur ist derzeit jedoch nicht eingerichtet.

Ein Ausfall der aktiven Instanz kann deshalb zu einer Unterbrechung der Anwendung führen.

Wir veröffentlichen derzeit keine garantierte prozentuale Verfügbarkeit.

24. Monitoring

Der technische Betrieb wird derzeit administrativ überwacht.

Ein umfassendes externes Uptime- und Alerting-System befindet sich noch im Ausbau.

Wir behaupten deshalb derzeit keine permanente automatische Verfügbarkeitsüberwachung, solange diese nicht entsprechend umgesetzt ist.

Nach Einführung eines solchen Systems wird die TOM-Dokumentation entsprechend aktualisiert.

25. Entwicklung und Versionskontrolle

Der Acadex-Quellcode wird über Git verwaltet.

Die Entwicklung erfolgt in einem gemeinsamen strukturierten Repository.

Änderungen werden über Feature-Branches entwickelt.

Pull Requests und Code-Reviews sind Bestandteil des Entwicklungsprozesses.

Automatisierte Tests und manuelle User-Acceptance-Tests werden je nach Änderung eingesetzt.

Acadex wird containerisiert betrieben.

26. Deployment

Produktivdeployments werden derzeit durch den technischen Betreiber von Acadex durchgeführt.

CI/CD-Prozesse unterstützen Entwicklung und Bereitstellung.

Betriebssystemupdates werden über die Serveradministration eingespielt.

Updates von Containerimages und Abhängigkeiten erfolgen derzeit ereignisbezogen beziehungsweise nach technischem Bedarf.

Der Patch- und Updateprozess wird mit zunehmender Infrastruktur weiter formalisiert.

27. Sicherheitsvorfälle

Für technische Sicherheitsvorfälle ist intern eine klare operative Zuständigkeit vorgesehen.

Bei einem möglichen Vorfall werden abhängig von Art und Umfang insbesondere folgende Schritte durchgeführt:

• Eingrenzung des Vorfalls,
• Sperrung beziehungsweise Rotation betroffener Credentials,
• Sicherung relevanter Logs,
• Analyse betroffener Systeme und Daten,
• Bewertung der möglichen Auswirkungen,
• technische Behebung,
• Bewertung erforderlicher Kundeninformationen,
• Prüfung gesetzlicher Meldepflichten,
• Nachbereitung des Vorfalls.

Institutionelle Kunden werden bei relevanten Verletzungen personenbezogener Daten nach Maßgabe des jeweiligen Auftragsverarbeitungsvertrags informiert.

28. Unterauftragsverarbeiter

Externe Anbieter werden nur für definierte Zwecke eingesetzt.

Welche Anbieter für einen bestimmten Account tatsächlich personenbezogene Daten erhalten, hängt von der jeweiligen Nutzung und Konfiguration ab.

Bei institutionellen Accounts kann die Auswahl technisch beschränkt werden.

Die aktuell möglichen externen Dienste und Providerprofile dokumentieren wir gesondert.

Externe Dienste & Unterauftragsverarbeiter →

29. Überprüfung der Maßnahmen

Technische und organisatorische Maßnahmen sind kein einmalig abgeschlossenes Dokument.

Ihre Wirksamkeit wird im Rahmen verschiedener technischer und organisatorischer Prozesse überprüft.

Dazu gehören unter anderem:

• automatisierte Tests,
• Code-Reviews,
• User-Acceptance-Tests,
• Überprüfung der Löschlogik,
• Kontrolle administrativer Zugriffsschutzmaßnahmen,
• Secret-Rotation,
• Wiederherstellungstests,
• Prüfung sicherheitsrelevanter Änderungen.

Die TOM selbst werden zusätzlich regelmäßig und bei wesentlichen Änderungen der Architektur oder Verarbeitung überprüft.

Regelmäßiger Review-Zyklus: [vor Veröffentlichung ergänzen]

30. Was derzeit noch nicht besteht

Die TOM sollen den tatsächlichen Stand dokumentieren.

Deshalb gehören folgende Punkte derzeit nicht zu den bestehenden Maßnahmen beziehungsweise Nachweisen:

• ISO-27001-Zertifizierung,
• SOC-2-Bericht,
• externer formaler Penetrationstest,
• MFA für individuelle Acadex-Nutzeraccounts,
• institutionelles SSO,
• produktive Hochverfügbarkeitsarchitektur,
• allgemeines SLA,
• veröffentlichte RTO-/RPO-Garantien,
• zertifiziertes ISMS.

Diese Punkte können sich mit der weiteren Entwicklung von Acadex ändern.

Sie werden aber erst dann als bestehende Maßnahmen dokumentiert, wenn sie tatsächlich umgesetzt beziehungsweise nachgewiesen sind.

31. Versionierung

Die vollständigen technischen und organisatorischen Maßnahmen werden als eigenes Dokument versioniert.

Dadurch lässt sich nachvollziehen, welche Maßnahmen zu einem bestimmten Zeitpunkt dokumentiert waren.

Für institutionelle Vertragsverhältnisse kann im jeweiligen Auftragsverarbeitungsvertrag auf eine konkrete TOM-Version Bezug genommen werden.

Änderungen der Maßnahmen sind möglich, sofern das vereinbarte Schutzniveau dadurch nicht insgesamt unterschritten wird.

Dokumente

Auftragsverarbeitungsvertrag →

Sicherheit & Datenschutz →

Externe Dienste & Unterauftragsverarbeiter →

Datenschutzerklärung →

Fragen zu den TOM?

Institutionen prüfen Sicherheit unterschiedlich.

Wenn eine konkrete Anforderung in unseren Unterlagen nicht beantwortet wird, stellen wir die benötigten Informationen soweit möglich direkt bereit.

Auch Security- und Datenschutzfragebögen können uns zugesendet werden.

info@acadex.io