TRANSIT Datentreuhand – FAQ Sicherheitsaspekte

Die Zwecke werden bei der Registrierung in den AGBs und in Aufträgen festgelegt. Andere Nutzungen, z.B. für Forschung, erfolgen ausschließlich nach vorheriger Absprache und Zustimmung der beteiligten Partner.

Eine explizite „Verarbeitungsbeschränkung“ ist derzeit nicht umgesetzt. Daten werden gelöscht, wenn der Account gelöscht wird oder nach Aufbewahrungsfrist der Plattform (aktuell 10 Jahre, basierend auf Erstellzeitstempel), sofern sie nicht noch für laufende Aufträge benötigt werden.

Widerspruch gegen Verarbeitungen wird respektiert. Notwendige Mindestverarbeitungen, z.B. für Auftragsabwicklung, können rechtlich erforderlich bleiben. Komplexe Auswertungen sind nicht integriert.

Löschungen sind an Account-Löschungen bzw. Fristen (10 Jahre) gebunden. Vor Löschung wird geprüft, ob Daten noch in laufenden Aufträgen anderer Partner benötigt werden.

Interne Rollen (Keycloak) und eine Graphdatenbank-Logik steuern, welche Daten pro Rolle sichtbar sind. Firmenübergreifend können definierte Rollen festlegen, welche Daten für andere Firmen einsehbar sind.

Anmeldungen werden in Keycloak protokolliert. 2FA ist geplant, derzeit aber nicht verfügbar. API-Zugriffe erscheinen im Print-Log; es gibt noch keinen zentralen Log-Server.

Keycloak protokolliert Anmeldungen; API-Zugriffe sind sichtbar, aber nicht granular je Datensatz. Ein zentraler Log-Server mit vollständiger Zugriffsdokumentation ist vorgesehen.

Sicherer Datenaustausch mit Dritten gemäß NIS2 (Supply Chain Security) ist noch nicht implementiert. Mindestanforderungen werden konzipiert und phasenweise eingeführt.

Externe Verbindungen sind TLS‑gesichert (Domain‑Zertifikate). Interne Services kommunizieren ausschließlich im Cluster‑/Subnetzwerk.

Eine Festplattenverschlüsselung wird geprüft. Ziel ist die Umsetzung im Produktivbetrieb unter Wahrung der feingranularen Zugriffskontrollen.

Die eingesetzten Protokolle sind branchenüblich und mit gängigen Compliance‑Vorgaben kompatibel. Speicher‑Verschlüsselung wird so geplant, dass die Zugriffspolicy‑Logik erhalten bleibt.

Keycloak protokolliert Anmeldungen automatisch. API-Zugriffe erscheinen im Print-Log. Es gibt derzeit keine Datensatz-Granularität und keinen zentralen Log-Server – Nachbesserung geplant.

Aktuell sind Anmelde- und API-Ereignisse verfügbar. Der Ausbau zu einem zentralen Logging mit detaillierten Zugriffsreports ist vorgesehen.

Transparenz für Partner und Behörden. Der Reifegrad wird durch Einführung eines zentralen Log-Systems mit Datensatz-Granularität erhöht.

Aufbewahrungsfristen sind vom Use Case abhängig. Eine zentrale Policy wird erstellt und in der Doku veröffentlicht.

DSGVO und DGA standen im Mittelpunkt der Umsetzung. Ein Datenschutzgutachten der InfAI Infinity GmbH liegt vor.

Incident-Handling und Meldewege sind gesetzlich erforderlich und werden für den Produktivbetrieb eingeführt.

Ein Datenschutzgutachten (InfAI Infinity) liegt vor. Roadmap und Lückenanalyse für ISO 27001 werden bereitgestellt.

KRITIS-Anforderungen und BSI-Anbindung wurden in der Projektlaufzeit noch nicht analysiert.

Abstimmung zwischen Projektbetreuung/Entwicklung sowie InfAI- oder Universitäts-DSB. Konkrete Kontaktkette wird veröffentlicht.

Konkrete Angaben zum Umfang (Policies/Technik/Organisation) liegen derzeit nicht vollständig vor und werden sukzessive ergänzt.

Schulungen und Awareness-Themen (Sicherheit/Datenschutz) werden im Rahmen des Onboardings adressiert.

Über Zertifizierung der Plattformteilnehmer wurde nachgedacht; ein Konzept wurde noch nicht umgesetzt.

Das Dashboard ist nutzerfreundlich, zeigt aber aktuell kein Zugriffsprotokoll in der GUI. Auskünfte/Exporte erfolgen durch Anfrage des Betreibers.

Änderungen sind in den meisten Fällen möglich, nicht jedoch während ein Auftrag auf PROCESSING steht. Exporte sind maschinenlesbar (JSON).

Komplexe Auswertungen/Profiling sind nicht integriert.

Weniger manueller Aufwand und schnellere Prozesse. GUI-Zugriffsprotokolle werden noch ausgebaut.

Auditfreundliche, maschinenlesbare Formate (JSON) vorhanden; Dateiexport und GUI-Zugriffsprotokoll sind aktuell nicht vorgesehen.

Identitätsprüfung erforderlich. Dateiexporte sind nicht vorgesehen; strukturierte Exporte über die API.

Opt-out ist standardmäßig berücksichtigt; automatisierte Entscheidungen sind nicht vorgesehen.

Zutrittskontrollen, Brandschutz und Überwachung sind etabliert. Das interne Subnetz ist abgeschottet.

Zielbild: regelmäßige, verschlüsselte Backups und definierte Wiederherstellungsprozesse im Produktivbetrieb.

Kritische Komponenten sind aktuell nicht mehrfach geografisch vorhanden. Redundanz wird für den Betrieb bewertet.

Innerhalb der Plattform ist kein IDS/IPS integriert. Über das API-Gateway (Kong) sind zusätzliche Analysen/Rate-Limits realisierbar.

Der Datenbereitsteller wählt die Partner, zu denen vermittelt wird. Liefergebiete sind auf einer Karte einsehbar; Auswahl im Auftragsprozess.

Das Datenmodell ist auf Logistikdaten ausgelegt. Der Freigabeservice ist allgemein gehalten und könnte andere Sektoren unterstützen.

Sicherheitskritische Daten (z.B. Lieferungen von/zu Flughäfen) sind ausgenommen. Ein direkter Kanal ist nicht integriert.

Die Rolle als neutraler Vermittler ist teilweise umgesetzt; Governance-Dokumente werden ergänzt.

Das Modul wurde bislang nicht eingeplant. Minimierungsmaßnahmen können vertraglich/technisch nachgerüstet werden.

Bei Einführung würden technische und organisatorische Maßnahmen dokumentiert und auditierbar gestaltet.

Weniger Personenbezug reduziert Pflichten und Prüfaufwände. Umsetzung ist optional planbar.

Bei Einführung: Freigabedokumente, Verfahren und Profile werden auditierbar beschrieben.