6 Verfahren und Technik
Zweck der Verarbeitung ist die Bereitstellung und der technische Betrieb einer Online-Beratungsplattform (nachfolgend „Plattform"), über die Träger und Beratungsstellen ihren …
6.1 Zweck
Zweck der Verarbeitung ist die Bereitstellung und der technische Betrieb einer Online-Beratungsplattform (nachfolgend „Plattform"), über die Träger und Beratungsstellen ihren fachlichen Beratungsauftrag digital, ortsunabhängig und niedrigschwellig erfüllen können. Die inhaltliche Beratung selbst sowie deren Fachdokumentation verantworten die Träger; eine inhaltliche Falldokumentation findet auf der Plattform nicht statt. Beratungsinhalte werden Ende-zu-Ende-verschlüsselt übertragen und gespeichert (im Einzelnen Abschnitt 6.9).
6.2 Beratungsarten
6.2.1 Einzelberatung (1:1-Chat)
Registrierte Ratsuchende richten ihre Erstanfrage an eine Beratungsstelle; die Zuordnung erfolgt über die angegebene Postleitzahl sowie das gewählte Beratungsthema. Der Beratungsverlauf findet in einem eigenständigen, nicht öffentlich auffindbaren, Ende-zu-Ende-verschlüsselten Chatraum statt; Beratung ist sowohl synchron als auch asynchron möglich. Der Zugriff einer weiteren beratenden Person auf einen bestehenden Fall ist ausschließlich über das protokollierte Übergabeverfahren vorgesehen (Abschnitt 6.13).
6.2.2 Anonymer Live-Einzelchat
Der Live-Einzelchat ist ohne Registrierung nutzbar. Die ratsuchende Person betritt einen virtuellen Warteraum unter einem systemgenerierten Pseudonym; personenbezogene Angaben werden nicht erhoben. Auch dieser Chat ist Ende-zu-Ende-verschlüsselt. Anonyme Konten werden nach Inaktivität automatisiert deaktiviert und anschließend gelöscht (Abschnitt 6.18).
6.2.3 Gruppenchat
Der Gruppenchat ermöglicht moderierte n:n-Beratung, insbesondere für Selbsthilfeformate. Die Moderation legt Chatangebote mit Thema, Datum, Uhrzeit sowie einmaliger oder wiederkehrender Terminfolge an; abgelaufene Gruppenchats werden automatisiert deaktiviert. Auch Gruppenräume werden mit aktivierter Ende-zu-Ende-Verschlüsselung angelegt.
Risiko und Kompensation. In einer Gruppe nehmen die Teilnehmenden einander wahr; die Vertraulichkeit gegenüber anderen Ratsuchenden beruht damit auf der Pseudonymität und auf der Moderation, nicht auf technischer Trennung. Kompensierend wirken die systemgenerierten Pseudonyme (Abschnitt 6.3), die Moderationsrechte einschließlich des Entfernens von Teilnehmenden sowie die Beschränkung der Teilnehmendenzahl. Eine wiederkehrende Terminserie kann für sich genommen ein Teilnahmeprofil erkennen lassen; dieses Restrisiko ist im Rahmen der Moderation und der Aufklärung der Teilnehmenden zu adressieren.
6.2.4 Video- und Audio-Beratung
Die Videoberatung erfolgt browserbasiert über eine selbst betriebene Medienvermittlung; sie ist in Abschnitt 6.10 gesondert beschrieben.
6.2.5 Sprachnachrichten
Sprachnachrichten sind in allen Chat-Formen möglich und je Träger und Chat-Typ abschaltbar; sie sind wegen ihres besonderen Risikoprofils in Abschnitt 6.11 gesondert beschrieben.
6.2.6 Terminverwaltung — nicht ausgeliefert
Eine Terminverwaltung im Sinne eines Kalender- oder Buchungsmoduls ist nicht Bestandteil des aktuellen Leistungsumfangs. Ein entsprechendes Modell ist als Architekturentscheidung beschrieben (ADR-020, „Scheduled calls, secure invitations, and a unified contact calendar", Status „Accepted"); ausgeliefert ist davon bisher nichts. Ein im Datenmodell vorhandener Termin-Datensatz stammt aus der Vorgängerplattform und ist im Auslieferungsstand nicht aktiviert. Diese DSFA bewertet die geplante Funktion daher nicht; sie ist bei Auslieferung zu ergänzen.
6.3 Registrierung, Anonymität und Pseudonymität der Ratsuchenden
Die Registrierung ist ohne Angabe identifizierender Daten möglich. Der Benutzername wird systemseitig erzeugt (Kombination aus Adjektiv, Tierbezeichnung und Namensbestandteil, ergänzt um eine Avatarfarbe); ein frei gewählter, potenziell identifizierender Klarname ist konstruktionsbedingt ausgeschlossen. Dies ist eine bewusste Verbesserung gegenüber der Vorgängerplattform, auf der Benutzernamen frei wählbar waren. Pflichtangabe ist die Postleitzahl zur Zuordnung der zuständigen Beratungsstelle; ihre Richtigkeit wird nicht geprüft. Die Angabe einer E-Mail-Adresse ist optional.
Ehrliche Einordnung. Ein systemgeneriertes Pseudonym ist kein anonymes Datum. Es ist über die Kontokennung dauerhaft mit allen Beratungsvorgängen derselben Person verkettbar und daher personenbezogen zu behandeln. Vollständige Anonymität besteht allein im registrierungsfreien Live-Einzelchat, solange die ratsuchende Person keine identifizierenden Angaben von sich aus macht. Ob eine Nutzung anonym ist, ergibt sich damit aus dem gewählten Zugangsweg und dem Kontostatus — sie lässt sich insbesondere nicht aus dem angezeigten Namen ableiten.
Wirksame Datenminimierung, aber begrenzt. Neben der Sitzung werden je nach Fachbereich Angaben gespeichert, die zusammen ein enges Quasi-Identifikator-Set bilden: Postleitzahl, Alter, Geschlecht, Beratungsanlass und Beziehungskonstellation stehen in einer Datenzeile nebeneinander. Für kleine Beratungsstellen ist damit ein Re-Identifikationsrisiko nicht auszuschließen. Kompensierend wirken die Freiwilligkeit der Zusatzangaben, die fachbereichsbezogene Steuerung des Erhebungsumfangs und der Verzicht auf jede Verknüpfung mit externen Datenquellen. Ebenfalls gespeichert wird ein Herkunftsverweis (Referrer) der Registrierung; er ist für die Zwecke der Beratung nicht erforderlich und als Minimierungskandidat auszuweisen.
Belege aus dem Code — Abschnitt 6.3 3
- live
Benutzernamen sind nicht verschlüsselt, sondern lediglich Base32-kodiert; sie sind als Klartext zu behandeln.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/helper/UsernameTranscoder.java:3–15GitHub
- live
Postleitzahl, Alter, Geschlecht, Beratungsanlass, Beziehungskonstellation und Herkunftsverweis stehen in einer Datenzeile der Beratungssitzung.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/model/Session.java:47–221GitHub
- live
Welche fachbereichsbezogenen Zusatzangaben erhoben werden, steuert die Konfiguration der Beratungsart.
- ORISO-ConsultingTypeService/src/main/resources/schemas/consulting-type.json:274–426GitHub
6.4 Konten der Beratenden, Administration und Einladungsverfahren
Konten für Beratende und für administrative Rollen werden nicht durch die Betroffenen selbst angelegt, sondern über ein Einladungsverfahren durch die Administration des jeweiligen Trägers bzw. der Beratungsstelle. Verarbeitet werden dabei Vor- und Nachname, die dienstliche E-Mail-Adresse, die Zielrolle sowie die Zuordnung zu Träger und Beratungsstelle. Die Einladung wird per E-Mail mit einem zeitlich befristeten, kryptografisch gesicherten Link zugestellt; der Zugriffsschlüssel wird nur als Hashwert gespeichert.
Bei Beratenden handelt es sich um Klarnamen; der Anzeigename im Chat-Dienst entspricht dem Realnamen, während Ratsuchende ausschließlich unter ihrem Pseudonym erscheinen. Ein Bulk-Import einzuladender Personen aus einer Datei ist möglich; in diesem Fall stammen die Daten nicht von der betroffenen Person selbst, weshalb die Informationspflicht bei Erhebung bei Dritten nach § 16 KDG (Art. 14 DSGVO) durch den einladenden Träger zu erfüllen ist.
Restrisiko. Der Versandvorgang wird mit einer vollständigen Kopie der versendeten Nachricht einschließlich Empfängeradresse archiviert; eine Aufbewahrungsfrist ist bislang nicht definiert. Ebenso ist für abgelaufene, nicht angenommene Einladungen kein Löschlauf eingerichtet. Beide Punkte sind als Löschkonzept-Maßnahmen ausgewiesen (Abschnitt 6.18).
Belege aus dem Code — Abschnitt 6.4 2
- live
Einladungen speichern Name und E-Mail-Adresse von Personen vor deren Registrierung, dazu Token-Hash und 2FA-Status.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/model/AccountInvite.java:1–160GitHub
- live
Der vollständige Text versendeter Einladungs-E-Mails wird mit Empfängeradresse archiviert; eine Frist besteht nicht.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/model/InviteEmailDelivery.javaGitHub
6.5 Authentifizierung, Rollen und Zwei-Faktor-Authentisierung
Die Anmeldung erfolgt über ein zentrales Identitätsmanagement (Keycloak) auf Basis von OAuth 2.0 und OpenID Connect mit signierten Token; Passwörter werden ausschließlich als gesalzene Hashwerte im Identitätsmanagement gespeichert und sind der Anwendung zu keinem Zeitpunkt im Klartext zugänglich. Sämtliche Verbindungen sind transportverschlüsselt.
Rollenmodell. Die Plattform kennt vier Personalebenen sowie die ratsuchende Person; intern bilden feingranulare Realm-Rollen die API-Rechte ab.
| Ebene | Aufgabe | Zugriff auf Beratungsinhalte |
|---|---|---|
| Plattform-Administration | Betrieb der Plattform, Anlage von Trägern, Pflege der Rechtstext-Vorlagen der Plattformebene | nein |
| Träger-Administration | Verantwortung für einen Träger: Anlage von Beratungsstellen und deren Administration, Pflege der Rechtstexte der Trägerebene | nein |
| Beratungsstellen-Administration | Leitung einer Beratungsstelle: Einladung Beratender, Konfiguration von Themen, Postleitzahlbereichen und Live-Chat-Zugang | nein |
| Beratende | Annahme von Anfragen und Führung der verschlüsselten Beratung; Supervision ist eine Funktion an dieser Rolle, keine eigene Rolle | nur eigene Fälle |
| Ratsuchende | Nutzung der Beratung | nur eigene Sitzung |
Es gelten zwei durchgängige Regeln: hierarchische Isolation — kein Träger sieht einen anderen, keine Beratungsstelle sieht Ratsuchende oder Beratende einer anderen — und Vererbung der Rechtstexte: Impressum, Datenschutzerklärung und Einwilligungstext bestehen auf jeder Ebene; ohne eigene Fassung gilt die der übergeordneten Ebene.
Komposit-Rollen der Administration. Die Anlage einer Träger-Administration vergibt systemseitig ein Bündel mehrerer Rollen (Nutzerverwaltung, Agenturverwaltung, Mandantenverwaltung sowie, außerhalb des Single-Domain-Betriebs, Themenverwaltung). Die Plattform-Administration ist technisch dieselbe Rollenkombination ohne Mandantenbindung; sie ist damit trägerübergreifend lesend umfassend berechtigt. Eine Rolle, die den Betrieb eines Trägers erlaubt, ohne dessen vertrauliche Betriebs- und Beratungsmetadaten einsehen zu können, existiert derzeit nicht. Dieses Restrisiko ist in Abschnitt 6.16 behandelt.
Zwei-Faktor-Authentisierung. Als zweiter Faktor stehen eine Authenticator-Anwendung (TOTP, sechsstelliger Code, 30-Sekunden-Intervall) sowie ein E-Mail-Einmalcode (sechsstellig, Gültigkeit 15 Minuten, höchstens drei Fehlversuche) zur Verfügung. Für Ratsuchende ist die Einrichtung optional. Für alle über das Einladungsverfahren angelegten Konten — insbesondere Träger- und Beratungsstellen-Administration sowie Beratende — ist die Einrichtung verbindlicher Bestandteil der Kontoaktivierung: Das Konto bleibt gesperrt, bis ein zweiter Faktor aktiv ist. Eine Befreiung ist ausschließlich administrativ möglich, setzt die Angabe eines Grundes voraus und wird personenbezogen mit Zeitpunkt und veranlassender Person dokumentiert. Für die Plattform-Administration besteht demgegenüber lediglich eine Aufforderung beim Anmelden, die sitzungsweise zurückgestellt werden kann („später einrichten") und bei der nächsten Anmeldung erneut erscheint; ein technischer Zwang besteht insoweit nicht.
Ehrliche Grenzbenennung. Die maßgebliche Konfiguration des Identitätsmanagements wird beim Erststart importiert und anschließend zur Laufzeit durch Skripte verändert; keine der im Quellcode versionierten Konfigurationsdateien ist daher für den Live-Zustand autoritativ. Für die abschließende Fassung dieser DSFA ist ein Export des Live-Realms erforderlich. Aus den versionierten Ständen ergibt sich ferner, dass ein automatischer Anmeldeschutz gegen systematisches Durchprobieren (Brute-Force-Sperre) nicht aktiviert ist — was zugleich bedeutet, dass keine Fehlversuchs- und IP-Historie gespeichert wird — und dass die Gültigkeitsdauer von Zugriffstoken mit fünf Stunden großzügig bemessen ist. Eine Passwortrichtlinie (Mindestlänge, Zeichenklassen) ist aus den Repositorien nicht belegbar und darf in dieser DSFA nicht behauptet werden, bevor sie am Live-System nachgewiesen ist.
Belege aus dem Code — Abschnitt 6.5 7
- live
Die Anlage einer Träger-Administration vergibt ein Bündel mehrerer Rollen (Komposit-Rollen).
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/admin/service/admin/create/CreateAdminService.java:87–94GitHub
- live
Über Einladung angelegte Konten bleiben gesperrt, bis ein zweiter Faktor aktiv, befreit, nicht erforderlich oder per Richtlinie abgeschaltet ist.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/service/accountinvite/AccountInviteService.java:379–412GitHub
- live
Eine Befreiung von der Zwei-Faktor-Pflicht erfordert einen Grund und wird mit Person und Zeitpunkt dokumentiert.
- live
Für die Plattform-Administration ist die 2FA-Einrichtung nur eine Aufforderung, die sitzungsweise zurückgestellt werden kann.
- Live-Prüfung offen
Zweiter Faktor: TOTP (6 Stellen, 30 s) oder E-Mail-Einmalcode (6 Stellen, 15 min, max. 3 Fehlversuche).
- Live-Prüfung offen
Ein automatischer Anmeldeschutz gegen systematisches Durchprobieren ist nicht aktiviert; es werden keine Fehlversuchs-/IP-Historien gespeichert.
- ORISO-Helm/charts/keycloak/keycloak-resources/realm.jsonGitHub
- Live-Prüfung offen
Zugriffstoken sind fünf Stunden gültig; Offline-Sitzungen haben keine harte Obergrenze.
- ORISO-Helm/charts/keycloak/keycloak-resources/realm.json:6–16GitHub
6.6 Verarbeitung der IP-Adresse und Protokollierung im Transportweg
Die Anwendungsdienste selbst speichern keine IP-Adressen betroffener Personen in ihren Fachdatenbeständen; sie arbeiten mit pseudonymen Kennungen und signierten Token. Für die Weitergabe der Client-IP an die Fachdienste existiert ein Filter mit einem strengen Modus, der den entsprechenden Weiterleitungs-Header entfernt; standardmäßig ist dieser strenge Modus nicht aktiv.
Ehrlich auszuweisen ist, dass IP-Adressen an anderer Stelle des Transportwegs anfallen:
- Der vorgelagerte Eingangs-Proxy (Ingress) protokolliert im Standardformat die Client-IP, den aufgerufenen Pfad und die Browserkennung. Ein zentraler Log-Versand ist nicht eingerichtet; die Aufbewahrung folgt der Rotationsvorgabe der Container-Plattform und ist damit nicht ausdrücklich festgelegt.
- Das Identitätsmanagement persistiert zwar keine Anmeldeereignisse in seiner Datenbank, schreibt diese aber über den aktiven Protokoll-Zuhörer einschließlich der IP-Adresse in den Server-Log-Strom. Eine IP-freie Variante dieses Zuhörers liegt vor, ist jedoch nicht aktiviert — eine naheliegende und aufwandsarme Härtungsmaßnahme.
- Einzelne Endpunkte der Zwei-Faktor-Erweiterung führen den Benutzernamen im URL-Pfad; er gelangt dadurch in die Zugriffsprotokolle der vorgelagerten Komponenten.
- Beim Aufbau einer Videoverbindung werden derzeit öffentliche STUN-Server eines US-amerikanischen Anbieters angefragt; dabei werden Client-IP-Adressen an einen Empfänger in einem Drittland übermittelt (Abschnitt 6.10).
Kompensation und Maßnahme. Der Container der Administrationsoberfläche protokolliert bereits bewusst ohne Client-IP; dasselbe Format ist für die übrigen Web-Container vorgesehen. Als Maßnahmen sind festzuhalten: Aktivierung des IP-freien Protokoll-Zuhörers im Identitätsmanagement, Festlegung einer ausdrücklichen Aufbewahrungsfrist für Zugriffsprotokolle, Maskierung tokenhaltiger URL-Parameter in den Zugriffsprotokollen sowie Ersetzung der externen STUN-Server durch eigene Komponenten. Die Aussage der Vorgängerdokumentation, IP-Adressen würden „zu keiner Zeit vom System mitgeschrieben", ist für diese Plattform in dieser Absolutheit nicht haltbar und wird bewusst nicht übernommen.
Belege aus dem Code — Abschnitt 6.6 5
- live
Der Filter zum Entfernen des Weiterleitungs-Headers hat einen strengen Modus, ist standardmäßig aber nicht aktiv.
- live
Der Eingangs-Proxy protokolliert im Standardformat mit Client-IP; ein Log-Versand ist nicht eingerichtet.
- ORISO-Helm/templates/nginx/ingress-nginx-controller-configmap.yamlGitHub
- live
Der Container der Administrationsoberfläche protokolliert bewusst ohne Client-IP.
- ORISO-Admin/nginx.conf:1–11GitHub
- Live-Prüfung offen
Anmeldeereignisse werden nicht in der Datenbank gespeichert, aber mit IP-Adresse in den Server-Log-Strom geschrieben; eine IP-freie Variante existiert, ist aber nicht aktiviert.
- Live-Prüfung offen
Endpunkte der Zwei-Faktor-Erweiterung führen den Benutzernamen im URL-Pfad und gelangen so in Zugriffsprotokolle.
- ORISO-Keycloak/keycloak-image/otp-config-spi/src/main/java/.../RealmOtpResourceProvider.java:66–190GitHub
6.7 Cookies und Websitenutzungsdaten
Die Plattform verzichtet vollständig auf Tracking, Analysedienste, Werbenetzwerke, externe Schriftarten und Drittanbieter-Skripte; sämtliche Bestandteile werden von der Plattform selbst ausgeliefert. Im Browser der Nutzer:innen wird keine Produkt- oder Fehlertelemetrie an Dritte erhoben. Es werden ausschließlich technisch notwendige Cookies eingesetzt; ein Einwilligungsbanner ist daher nicht erforderlich. Ohne Cookie-Unterstützung ist die Anwendung nicht nutzbar; hierauf wird vor der Anmeldung hingewiesen.
| Cookie | Setzende Stelle | Zweck | Speicherdauer | Attribute |
|---|---|---|---|---|
keycloak | Anwendung | API-Authentifizierung (Zugriffstoken) | Sitzung | SameSite=Strict, Secure |
refreshToken | Anwendung | Erneuerung der Anmeldesitzung | Sitzung | SameSite=Strict, Secure |
CSRF-TOKEN | Anwendung | Schutz vor Cross-Site-Request-Forgery | Sitzung | SameSite=Strict |
lang | Anwendung | Sprachwahl | Sitzung | SameSite=Strict |
useInformal | Anwendung | Du-/Sie-Anrede | Sitzung | SameSite=Strict |
tenantId | Anwendung | Mandantenzuordnung | Sitzung | SameSite=Strict |
ui-version | Anwendung | Wahl der Oberflächenversion | befristet (Ablaufdatum) | SameSite=Lax |
matrix_sso_user_id, matrix_sso_access_token, matrix_sso_device_id, matrix_sso_hs_url | Anwendung | Übergabe der Chat-Sitzung beim Wechsel der Oberflächenversion | Sitzung | SameSite=Lax, Secure |
oriso-admin.language | Administrationsoberfläche | Sprachwahl | befristet | — |
AUTH_SESSION_ID, KEYCLOAK_IDENTITY, KEYCLOAK_SESSION, KC_RESTART, KEYCLOAK_LOCALE, KC_AUTH_STATE (jeweils ggf. _LEGACY) | Identitätsmanagement | Single-Sign-on-Sitzung | an die Sitzungslaufzeiten des Realms gebunden | HttpOnly, Secure |
Restrisiko. Die beiden Authentifizierungs-Cookies der Anwendung sind nicht mit dem Attribut
HttpOnly versehen und werden zusätzlich im lokalen Speicher des Browsers gespiegelt; sie sind
damit für Skripte im Seitenkontext lesbar. Die Cookies zur Übergabe der Chat-Sitzung tragen
zudem ein Matrix-Zugriffstoken bei gelockertem SameSite-Attribut. Beides erhöht die Auswirkung
einer erfolgreichen Cross-Site-Scripting-Attacke und ist als Härtungsmaßnahme (HttpOnly,
serverseitige Sitzungsführung, Verzicht auf die Spiegelung) auszuweisen. Eine Content-Security-
und Referrer-Policy ist am Eingangs-Proxy derzeit nicht gesetzt.
Belege aus dem Code — Abschnitt 6.7 3
6.8 Nutzung auf verschiedenen Endgeräten
Die fachliche Verarbeitung erfolgt serverseitig; auf den Endgeräten verbleiben Sitzungsdaten, Anzeigeeinstellungen und — konstruktionsbedingt — das kryptografische Schlüsselmaterial der Ende-zu-Ende-Verschlüsselung. Die Absicherung des Endgeräts liegt in der Verantwortung der Nutzer:innen; für Beratende gelten zusätzlich die organisatorischen Vorgaben ihres Trägers (dienstliche bzw. freigegebene Geräte).
Im Einzelnen werden auf dem Endgerät abgelegt: Zugriffs- und Erneuerungstoken sowie deren Gültigkeitszeitpunkte, die Anmeldedaten des Chat-Dienstes (Zugriffstoken, Nutzer- und Gerätekennung), der kryptografische Speicher der Ende-zu-Ende-Verschlüsselung in einer Browser-Datenbank (IndexedDB) sowie Oberflächeneinstellungen.
Zwei Befunde sind offen auszuweisen. Erstens werden noch nicht versendete Nachrichtenentwürfe im Klartext im lokalen Speicher des Browsers abgelegt; die Ende-zu-Ende-Verschlüsselung greift erst mit dem Versand. Auf gemeinsam genutzten Geräten kann dies Beratungsinhalte offenlegen. Zweitens wird beim Abmelden zwar der lokale und der Sitzungsspeicher geleert, nicht jedoch der kryptografische Speicher in der Browser-Datenbank; Schlüsselmaterial verbleibt daher nach dem Abmelden auf dem Gerät. Beides ist als Maßnahme zu führen (Verschlüsselung bzw. Verzicht auf persistente Entwürfe; vollständiger Wipe des Krypto-Speichers beim Abmelden). Bis dahin ist der Hinweis auf die Nutzung eigener, gesperrter Geräte Teil der Nutzerinformation.
Belege aus dem Code — Abschnitt 6.8 2
- live
Noch nicht versendete Nachrichtenentwürfe liegen im Klartext im lokalen Speicher des Browsers.
- ORISO-Frontend/src/services/draftStore.ts:1–15GitHub
- live
Der kryptografische Speicher in der Browser-Datenbank wird beim Abmelden nicht geleert.
6.9 Ende-zu-Ende-Verschlüsselung und Schlüsselkonzept
Die Plattform basiert auf dem offenen Kommunikationsprotokoll Matrix mit einem selbst betriebenen Heimserver. Sämtliche Beratungsräume — Einzelberatung, anonymer Live-Chat, Gruppenchat, Supervision und interne Fallkoordination — werden serverseitig verpflichtend mit aktivierter Ende-zu-Ende-Verschlüsselung angelegt; ein unverschlüsselter Sendepfad existiert nicht.
Schlüsselkonzept.
- Geräteschlüssel und Olm. Jedes Endgerät erzeugt bei der ersten Anmeldung ein eigenes Schlüsselpaar. Der direkte Austausch zwischen Geräten (insbesondere die Weitergabe von Raumschlüsseln) erfolgt paarweise verschlüsselt nach dem Olm-Verfahren.
- Raumschlüssel und Megolm. Nachrichteninhalte werden mit einem Raumschlüssel nach dem
Megolm-Verfahren (
m.megolm.v1.aes-sha2) verschlüsselt. Der Raumschlüssel wird ausschließlich an die berechtigten Endgeräte der Raummitglieder verteilt; der Server erhält ihn zu keinem Zeitpunkt. Die Verschlüsselung ist Eigenschaft des Raums, nicht eines Schalters in der Oberfläche — ein Herabstufen einzelner Nachrichten ist konstruktionsbedingt ausgeschlossen. - Geräteprüfung (Cross-Signing). Schlüssel werden grundsätzlich nur an gegengezeichnete, also verifizierte Geräte weitergegeben. Ausgenommen sind die Endgeräte anonymer Live-Chat-Nutzer:innen, bei denen die Erreichbarkeit der Beratung Vorrang vor der Geräteisolation hat; die Verschlüsselung selbst bleibt auch dort vollständig wirksam.
- Dateianhänge. Dateien werden zusätzlich clientseitig mit einem einmaligen AES-256-Schlüssel verschlüsselt, bevor sie das Endgerät verlassen. Der Server erhält weder Dateinamen noch Inhaltstyp, sondern einen nicht entschlüsselbaren Datenblock; der zugehörige Schlüssel wird ausschließlich innerhalb der Megolm-verschlüsselten Nachricht transportiert.
- Serverseitiges Schlüssel-Backup („Silent Key Backup"). Zur Wiederherstellung nach Geräteverlust oder Neuanmeldung wird ein serverseitiges, seinerseits verschlüsseltes Backup aller Raumschlüssel geführt. Der Schlüssel zu diesem Backup liegt in einem verschlüsselten Geheimspeicher (Secret Storage), der ausschließlich über einen beim Nutzer verbleibenden Wiederherstellungsschlüssel geöffnet werden kann. Der Server kann die gesicherten Schlüssel nicht lesen. Ein Zurücksetzen des Backups ist destruktiv: Die zuvor gesicherte Historie wird dauerhaft unlesbar.
- Geparktes Gerät (Device Dehydration). Ein zusätzliches, hinterlegtes Pseudo-Gerät zur nahtlosen Wiederaufnahme ist implementiert, steht jedoch unter einem Freigabeschalter und ist nur bei dessen Aktivierung wirksam. Es erweitert die Angriffsfläche um eine serverseitig geparkte Identität und ist bei Aktivierung gesondert zu bewerten.
- Schlüsselübergabe bei Fallübergabe. Für die Weitergabe der Beratungshistorie an eine neu hinzutretende, berechtigte Fachkraft werden die betreffenden Raumschlüssel gezielt und verschlüsselt an deren Gerät übertragen (Abschnitt 6.13).
Keine Föderation. Der Verbund mit fremden Matrix-Servern ist bewusst deaktiviert; es verlassen keine Beratungsdaten den Heimserver der Plattform in Richtung fremder Server.
Ehrliche Abgrenzung — was zugesichert wird und was nicht. Zugesichert wird, dass Beratungsinhalte den Server ausschließlich verschlüsselt erreichen und verlassen und dass Betreiber und Dienstleister sie nicht im Klartext einsehen können. Nicht zugesichert wird ein kryptografischer Ausschluss jeder denkbaren Betreiberhandlung: Der Heimserver verfügt über administrative Funktionen, mit denen sich Sitzungstoken für Nutzerkonten ausstellen lassen; ein so erlangter Zugang könnte künftige Schlüssel empfangen. Innerhalb einer Beratungsstelle ist die maßgebliche Vertraulichkeitsgrenze zudem nicht die Verschlüsselung, sondern die anwendungsseitige Zugriffskontrolle in Verbindung mit dem protokollierten Übergabeverfahren (ADR-002, Abschnitt 6.13). Diese Unterscheidung wird bewusst offengelegt, weil ein pauschales Verschlüsselungsversprechen den tatsächlichen Schutz falsch beschreiben würde. Als flankierende organisatorische Maßnahme ist der administrative Zugriff auf den Heimserver beim Betreiber vertraglich zu binden und zu protokollieren.
Verbesserung gegenüber der Vorgängerplattform. Auf der Vorgängerplattform war die Ende-zu-Ende-Verschlüsselung funktionsschaltergesteuert und stand neben einem serverseitigen Verschlüsselungspfad, dessen Schlüsselbestandteile vollständig auf dem Server lagen; der Betreiber konnte Inhalte dort technisch entschlüsseln. Der anonyme Live-Chat war von der Ende-zu-Ende-Verschlüsselung praktisch ausgenommen, weil das Schlüsselmaterial aus dem Anmeldepasswort abgeleitet wurde. Ferner bestand für Teilnehmende ohne eigenen öffentlichen Schlüssel ein Rückfallverfahren, dessen Ersatzschlüssel aus einer serverbekannten Kennung ableitbar war, sowie ein stiller Rückfall auf die serverseitige Verschlüsselung im Fehlerfall. In der vorliegenden Plattform bestehen weder ein serverseitiger Entschlüsselungspfad noch ein Rückfallverfahren; die Verschlüsselung gilt durchgängig für alle Chat-Formen einschließlich des anonymen Live-Chats sowie für Dateien und Sprachnachrichten.
Systembedingt verbleibende Metadaten. Auch bei wirksamer Ende-zu-Ende-Verschlüsselung verarbeitet der Heimserver Metadaten: Raumzugehörigkeit und Mitgliedschaften, pseudonyme Absenderkennung, Zeitstempel, Ereignistyp, Bezugsereignis bei Antworten und Reaktionen, Größe des Chiffrats, Lesebestätigungen sowie den Online-Status (Presence). Der Online-Status ist derzeit nicht deaktiviert; für eine Beratungsplattform ist die Abschaltung als Maßnahme zu prüfen. Reaktionen und Beziehungsangaben zwischen Ereignissen sind serverseitig sichtbar; für Reaktionsereignisse ist dies protokollbedingt.
Belege aus dem Code — Abschnitt 6.9 8
- live
Alle Beratungsräume werden serverseitig mit aktivierter Ende-zu-Ende-Verschlüsselung angelegt; ein unverschlüsselter Sendepfad existiert nicht.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/adapters/matrix/MatrixRoomClient.javaGitHub
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/adapters/matrix/MatrixSynapseService.java:864–869GitHub
- ORISO-Helm/templates/userservice/userservice-configmap-env.yaml:140–145GitHub
- live
Dateien werden clientseitig mit einem einmaligen AES-256-Schlüssel verschlüsselt; Dateiname und Inhaltstyp erreichen den Server nicht.
- live
Serverseitiges, verschlüsseltes Schlüssel-Backup mit Geheimspeicher (4S); der Wiederherstellungsschlüssel verbleibt beim Nutzer, der Server kann die Schlüssel nicht lesen.
- ORISO-Frontend/src/services/matrixKeyBackupService.ts:6–175GitHub
- standardmäßig aus
Ein geparktes Pseudo-Gerät (Device Dehydration) ist implementiert, steht aber unter einem Freigabeschalter.
- ORISO-Frontend/src/services/matrixDeviceDehydration.ts:1–40GitHub
- live
Raumschlüssel werden nur an gegengezeichnete Geräte verteilt; Ausnahme sind anonyme Live-Chat-Nutzer:innen.
- live
Die Föderation mit fremden Matrix-Servern ist deaktiviert.
- ORISO-Helm/templates/matrix/matrix-configmaps.yamlGitHub
- 0 - Docs/ADR-005-matrix-federation-off-dns-server-name.md
- live
Der Heimserver verfügt über eine administrative Funktion, mit der sich Sitzungstoken für Nutzerkonten ausstellen lassen.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/adapters/matrix/MatrixSynapseService.java:379–449GitHub
- live
Der Online-Status (Presence) ist am Chat-Dienst nicht deaktiviert.
6.10 Video- und Audio-Beratung
Die Video- und Audioberatung erfolgt browserbasiert über eine im eigenen Betrieb befindliche Medienvermittlung (LiveKit) und die darauf aufsetzende Anwendung Element Call. Die Räume für Anrufe werden nicht öffentlich beitretbar angelegt; Zutritt erhalten nur Mitglieder des zugehörigen Beratungsraums. Die Medienströme werden zwischen den Teilnehmenden Ende-zu-Ende verschlüsselt; ist die Verschlüsselung nicht verfügbar, wird der Anruf nicht aufgebaut (Fail-closed). Eine Aufzeichnung ist nicht konfiguriert; ein Aufzeichnungs- oder Ausleitungsdienst ist nicht Bestandteil des Auslieferungsstands. Räume ohne Teilnehmende werden nach kurzer Frist automatisch verworfen. Die ausgelieferte Konfiguration der Anrufanwendung enthält keine Produkt-, Absturz- oder Fehlertelemetrie an Dritte.
Restrisiko. Beim Verbindungsaufbau werden derzeit öffentliche STUN-Server eines US-amerikanischen Anbieters angefragt. Dabei werden Client-IP-Adressen an einen Empfänger in einem Drittland übermittelt. Die Umstellung auf eigene STUN-/TURN-Komponenten ist eine erforderliche Maßnahme; bis dahin ist die Übermittlung in der Datenschutzerklärung auszuweisen.
Verbesserung gegenüber der Vorgängerplattform. Dort war die Medienverschlüsselung nur unter engen Bedingungen wirksam (bestimmte Browserfamilien, Unterstützung durch alle Teilnehmenden) und wurde beim Eintreffen weiterer Personen im Warteraum automatisch abgeschaltet; im Regelfall sah die Medienvermittlung die Inhalte.
Belege aus dem Code — Abschnitt 6.10 3
- live
Für die Medienvermittlung ist kein Aufzeichnungs- oder Ausleitungsdienst konfiguriert.
- ORISO-Livekit/livekit.yamlGitHub
- live
Die ausgelieferte Konfiguration der Anrufanwendung enthält keine Telemetrie an Dritte.
- ORISO-Helm/templates/element-call/element-call-configmap.yamlGitHub
- live
Beim Verbindungsaufbau werden öffentliche STUN-Server eines US-Anbieters angefragt; dabei fließen Client-IP-Adressen in ein Drittland.
- ORISO-Helm/templates/matrix/matrix-configmaps.yaml:164–167GitHub
6.11 Sprachnachrichten
Die Plattform erlaubt das Versenden kurzer Sprachnachrichten (höchstens drei Minuten) in allen Beratungs-Chat-Formen. Die Funktion ist je Träger und je Chat-Typ — Einzelberatung, anonymer Live-Chat, Gruppen, Supervision — im Administrationsbereich abschaltbar; sie ist standardmäßig aktiviert und zusätzlich an die Freigabe des Medien-Uploads gekoppelt. Eine Abschaltung auf Ebene einzelner Beratungsstellen ist derzeit nicht vorgesehen.
Besonderes Risiko. Die menschliche Stimme ist ein identifizierendes, biometrienahes Merkmal. In einem pseudonymen Beratungssetting schwächt eine Sprachnachricht die Pseudonymität der ratsuchenden Person gegenüber der beratenden Person — nicht jedoch gegenüber Plattform- oder Serverbetreiber. Ratsuchende geben ihre Stimme freiwillig und aktiv preis (bewusste Aufnahme mit Vorschau- und Verwerfen-Möglichkeit); eine heimliche Erhebung findet nicht statt.
Schutzmaßnahmen. Sprachnachrichten werden ausschließlich Ende-zu-Ende-verschlüsselt übertragen: Die Audiodatei wird clientseitig mit einem einmaligen AES-256-Schlüssel verschlüsselt, bevor sie das Endgerät verlässt; der Schlüssel wird ausschließlich innerhalb der Megolm-verschlüsselten Chat-Nachricht transportiert. Der Server speichert nur nicht entschlüsselbares Chiffrat ohne Dateinamen und ohne Inhaltstyp; auch Aufnahmedauer und -zeitpunkt liegen ausschließlich im verschlüsselten Nachrichteninhalt. Betreiber und Dienstleister können Sprachnachrichten weder anhören noch inhaltlich auswerten. Auf dem Endgerät wird kein Audio dauerhaft gespeichert. Systembedingt verbleibende Metadaten beim Serverbetreiber sind: Raumzuordnung, pseudonyme Absenderkennung, Zeitstempel und Größe des Chiffrats — aus der Größe lässt sich die Aufnahmedauer grob schätzen.
Restrisiko und geplante Maßnahmen. Die Speicherdauer verschlüsselter Mediendateien auf dem Server ist derzeit unbegrenzt; eine automatische Löschfrist (Media-Retention) sowie die Umstellung auf authentifizierte Medien-Downloads sind als technische Härtungsmaßnahmen vorgesehen.
Belege aus dem Code — Abschnitt 6.11 2
- live
Sprachnachrichten sind je Träger und Chat-Typ abschaltbar, standardmäßig aktiv und an die Freigabe des Medien-Uploads gekoppelt.
- live
Die Aufnahmedauer ist auf 180 Sekunden begrenzt; die Dauer steckt im Dateinamen innerhalb des Chiffrats.
- ORISO-Frontend/src/components/messageSubmitInterface/messageSubmitInterfaceComponent.tsxGitHub
6.12 Medien-Uploads und Prüfung auf Schadsoftware
Die Plattform erlaubt Bild-Uploads in Chats — einschließlich des anonymen, registrierungsfreien Live-Chats — sowie in den redaktionellen Editoren für Rechtstexte. Für redaktionelle Bilder besteht eine serverseitige Formatvalidierung (Prüfung der Dateisignatur, zugelassen sind PNG, JPEG und WebP, kein SVG, Begrenzung auf 2 MB, authentifizierter Upload).
Für Chat-Medien existiert derzeit kein automatisierter Viren- oder Inhaltsscan. Als risikomindernde Übergangsmaßnahme werden Bilder anonymer Gäste im Live-Chat den Beratenden zunächst unkenntlich (unscharf) angezeigt und erst nach bewusster Einzelfreigabe durch die beratende Person dargestellt; ein Sperrvermerk kann von der absendenden Person nicht manipuliert werden. Diese Prüfung ist clientseitig durchgesetzt; die Datei selbst bleibt serverseitig abrufbar. Außerhalb des anonymen Live-Chats erfolgt keine Vorprüfung der Anzeige.
Die Zielarchitektur ist als Architekturentscheidung festgelegt (ADR „Media scanning via matrix-content-scanner, fail-closed"): ein vorgeschalteter Prüf-Proxy mit Virenscan und optionaler KI-gestützter Bildprüfung, der ungeprüfte oder beanstandete Dateien serverseitig unzugänglich hält. Die Implementierung liegt als geprüfter, standardmäßig deaktivierter Proof of Concept vor, ist jedoch nicht produktiv ausgerollt; die Inbetriebnahme wurde im Juli 2026 priorisierungsbedingt zurückgestellt. Ein Aktivierungstermin ist nicht festgelegt. Da die Ende-zu-Ende-Verschlüsselung seit der Architekturentscheidung dauerhaft aktiv ist, setzt der Betrieb des Prüf-Proxys zusätzlich die Umsetzung des Protokolls für verschlüsselte Medien voraus. Vor Aktivierung der KI-gestützten Bildprüfung ist der Abschluss einer Auftragsverarbeitungs- bzw. Unterauftragsvereinbarung mit Zusicherung der Nichtspeicherung erforderlich; der reine Virenscan ist davon unabhängig aktivierbar. Eine ebenfalls vorgesehene Bot-Abwehr am Eingang des anonymen Live-Chats ist gleichfalls nicht in Betrieb.
Restrisiko. Schadsoftware oder rechtswidrige Bildinhalte können technisch übertragen und abgerufen werden; die Exposition ist durch die Unschärfe- und Freigabemechanik sowie die Formatvalidierung nur teilweise begrenzt. Verschärfend wirkt, dass Medien-Downloads am Heimserver derzeit ohne Authentifizierung möglich sind: Wer eine Medienadresse kennt, kann den (verschlüsselten) Datenblock abrufen. Inhaltlich ist dies durch die Dateiverschlüsselung abgesichert; als Zusicherung „Zugriff nur für Berechtigte" ist es nicht tragfähig und daher als Härtungsmaßnahme geführt.
Belege aus dem Code — Abschnitt 6.12 4
- nicht ausgeliefert
Der fail-closed Prüf-Proxy ist als Proof of Concept gebaut, aber in keiner Umgebung ausgerollt.
- live
Bilder anonymer Gäste werden zunächst unscharf angezeigt; ein Sperrvermerk kann vom Absender nicht manipuliert werden.
- ORISO-Frontend/src/components/message/MessageAttachment.tsx:170–200GitHub
- live
Redaktionelle Bilder unterliegen einer Signaturprüfung (PNG/JPEG/WebP, kein SVG) und einem 2-MB-Limit.
- ORISO-TenantService/src/main/java/com/vi/tenantservice/api/service/TenantMediaService.javaGitHub
- live
Medien-Downloads am Heimserver erfordern kein Zugriffstoken.
- ORISO-Helm/templates/matrix/matrix-configmaps.yaml:146–152GitHub
6.13 Kollegiale Fallkoordination (Team-Besprechung) und Fallübergabe
(1) Team-Besprechung. Zur Koordination einer noch nicht angenommenen Beratungsanfrage steht den Berater:innen der zuständigen Beratungsstelle ein separater, technischer Besprechungsraum zur Verfügung (ADR-016). Der Raum ist ein eigenständiger Matrix-Raum; die ratsuchende Person ist zu keinem Zeitpunkt Mitglied dieses Raums, kann ihn nicht einsehen und nicht auffinden. Die Teilnahmeberechtigung ist deckungsgleich mit der Berechtigung, die Anfrage zu sehen: ausschließlich Berater:innen mit aktiver Zuordnung zur Beratungsstelle des Falls; ein Zugriff durch andere Beratungsstellen, den Träger oder den Plattformbetreiber über die Anwendung ist nicht vorgesehen (serverseitige Durchsetzung). Mit Annahme der Anfrage wird der Besprechungsraum automatisch und dauerhaft geschlossen; er bleibt für die Berater:innen der Beratungsstelle ausschließlich lesend erreichbar (technisch erzwungen über Matrix-Berechtigungsstufen). Anlage des Raums und Teilnahme der Berater:innen werden mit Zeitstempel protokolliert; Nachrichteninhalte werden nicht protokolliert. Ein Zustimmungs- oder Widerspruchsrecht der ratsuchenden Person besteht für die Team-Besprechung nicht; die Verarbeitung stützt sich insoweit nicht auf eine Einwilligung, sondern ist als interne fachliche Koordination ohne Offenlegung der Beratungsinhalte an zusätzliche Empfängerkreise ausgestaltet.
Ehrliche Grenzbenennung. In der Team-Besprechung wird über eine ratsuchende Person gesprochen, ohne dass diese davon Kenntnis erlangt; das Archiv bleibt dauerhaft lesbar. Damit entsteht ein Datenbestand über die betroffene Person außerhalb ihres Beratungsraums, der beim Auskunftsrecht zu berücksichtigen ist (Abschnitt 8.4) und für den eine Aufbewahrungsfrist festzulegen ist. Protokolliert werden derzeit ausschließlich Anlage und Teilnahme, nicht Lese- oder Archivzugriffe.
(2) Fallübergabe. Der Zugriff einer weiteren Beraterin oder eines weiteren Beraters auf einen bestehenden Beratungsfall — etwa bei Vertretung im Krankheitsfall, Urlaubsvertretung, kollegialer Beratung oder Ausscheiden — erfolgt ausschließlich über ein strukturiertes Übergabeverfahren. Antragsberechtigt sind nur Berater:innen derselben Beratungsstelle. Jeder Antrag erfordert die Angabe eines katalogisierten Grundes sowie einer Begründung. Je Grund ist festgelegt, ob die vorherige Zustimmung der ratsuchenden Person erforderlich ist. Ist die Zustimmung erforderlich, verbleibt der Antrag im Status „ausstehend"; die ratsuchende Person entscheidet selbst in der Anwendung über Annahme oder Ablehnung; erst danach wird der Zugriff gewährt oder verweigert. Ist keine Zustimmung erforderlich — Standardfall bei Krankheit, Urlaub, Notfall und Ausscheiden —, wird die ratsuchende Person unmittelbar nach der Übernahme durch eine Systemnachricht im Beratungsverlauf über die Übernahme und deren Grund informiert. Die bisherige Fachkraft bleibt Mitglied des Raums, sodass eine Rückübernahme möglich ist.
(3) Protokollierung. Jeder Übergabeantrag — einschließlich verweigerter Anträge — wird revisionsfähig gespeichert (antragstellende und bisherige Fachkraft, Grund, Ergebnis, Zustimmungserfordernis, maßgebliche Richtlinie, Zeitstempel). Beratungsinhalte sind nicht Bestandteil der Protokolldaten. Die Einsichtnahme in die Protokolle ist rollenbasiert beschränkt und mandanten- sowie beratungsstellenscharf gefiltert; Administratorkonten ohne Beratungsstellen-Zuordnung erhalten keinen Protokollzugriff (Fail-closed-Prinzip).
Restrisiko. Das Pflicht-Freitextfeld „Begründung" wird gespeichert und der Administration angezeigt; es kann im Einzelfall fallbezogene Inhalte enthalten. Solange keine Maskierung erfolgt, ist die Aussage „ohne Inhalte" nur mit dieser Einschränkung zutreffend. Als Maßnahmen sind ein Hinweis in der Eingabemaske („keine Fallinhalte in die Begründung") sowie die Maskierung des Feldes in den Administrationsprotokollen vorgesehen. Ein Grund aus dem Katalog („Fachkraft erkrankt") ist zugleich ein Gesundheitsdatum der beratenden Person und daher beschäftigtendatenschutzrechtlich zu würdigen.
(4) Technische Vertraulichkeit. Beide Raumtypen werden serverseitig als private, nicht auffindbare Matrix-Räume mit aktivierter Ende-zu-Ende-Verschlüsselung angelegt. Die maßgebliche Vertraulichkeitsgrenze gegenüber nicht fallführenden Berater:innen derselben Beratungsstelle ist jedoch nicht die Verschlüsselung, sondern die anwendungsseitige Zugriffskontrolle (Sichtbarkeits- und Berechtigungssteuerung, beratungsstellenscharfe Suche) in Verbindung mit dem protokollierten Übergabeverfahren; gegenüber Dritten außerhalb der Beratungsstelle besteht zusätzlich eine Trennung auf Ebene der Raum-Mitgliedschaft.
(5) Konfigurierbarkeit. Die Team-Besprechung ist je Mandant (Träger) durch die Plattformadministration aktivierbar bzw. deaktivierbar; zusätzlich besteht ein deployment-weiter Schalter. Der Grundkatalog der Fallübergabe einschließlich des Zustimmungserfordernisses je Grund ist administrativ konfigurierbar, derzeit jedoch plattformweit und nicht je Träger. Eine durchgängige Delegationskaskade bis auf die Ebene einzelner Beratungsstellen besteht für diese beiden Funktionen nicht; sie darf für sie nicht behauptet werden.
(6) Supervision — Abgrenzung. Die Supervision ist ein hiervon getrenntes drittes Werkzeug: Sie ist als begleitender Lesezugriff ausgestaltet und verfügt über ein eigenes Widerspruchsverfahren (Opt-out) für die ratsuchende Person. Zu Supervisionsvorgängen können Freitext-Notizen erfasst werden; für diese ist eine Aufbewahrungsfrist festzulegen.
Belege aus dem Code — Abschnitt 6.13 6
- live
Zugriff auf die Team-Besprechung haben ausschließlich Berater:innen der Beratungsstelle des Falls; die ratsuchende Person ist nie Mitglied.
- live
Mit Annahme der Anfrage wird der Besprechungsraum dauerhaft geschlossen und ist nur noch lesend erreichbar (Matrix-Berechtigungsstufe).
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/facade/TeamDiscussionFacade.javaGitHub
- live
Je Übergabegrund ist festgelegt, ob die Zustimmung der ratsuchenden Person erforderlich ist; sie entscheidet selbst in der Anwendung.
- live
Jeder Übergabeantrag — auch abgelehnte — wird mit Grund, Ergebnis, Richtlinie und Zeitstempel protokolliert; die Einsicht ist mandanten- und agenturscharf, fail-closed.
- live
Das Pflicht-Freitextfeld „Begründung" wird gespeichert und der Administration angezeigt; es kann Fallinhalte enthalten.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/model/CaseHandoverRequest.javaGitHub
- live
Der Grundkatalog ist plattformweit, nicht je Träger konfigurierbar; eine Delegationskaskade bis auf Beratungsstellenebene besteht für Team-Besprechung und Fallübergabe nicht.
6.14 In-App-Benachrichtigungen und E-Mail-Benachrichtigungen
In-App-Benachrichtigungen („Zeitstrahl"). Je Benachrichtigungsereignis wird serverseitig ein Datensatz gespeichert (mandantengetrennt): Empfänger-Pseudonym, Ereignistyp, Erstell- und Lesezeitpunkt, Sitzungsreferenz, ein anwendungsinterner Verweis sowie Anzeigetexte und strukturierte Metadaten.
Inhalte der Beratungskommunikation werden nicht gespeichert: Nachrichtentexte aus der Ende-zu-Ende-verschlüsselten Chat-Kommunikation erreichen die Benachrichtigungsverarbeitung konstruktionsbedingt nicht, da verschlüsselte Ereignisse keinen Nachrichtenkörper tragen; der konfigurierbare Vorschaumodus ist in allen Umgebungen fest auf „keine Vorschau" gesetzt, sodass auch clientseitig übermittelte Vorschautexte verworfen werden.
Gespeichert werden jedoch Kommunikationsmetadaten: wer wem wann in welcher Sitzung geschrieben hat, der Inhaltstyp der Nachricht, Anzeigenamen von Beratenden und bei neuen Anfragen die Themenkategorie der Beratung, die für sich genommen bereits einen Rückschluss auf den Beratungsanlass zulässt. Bei Fallübergaben fließt derzeit zusätzlich der von Beratenden verfasste Begründungs-Freitext in die Anzeigetexte ein und kann im Einzelfall Rückschlüsse auf Beratungsinhalte zulassen. Der Lesezeitpunkt wird sekundengenau je Benachrichtigung gespeichert und ermöglicht ein Nutzungs- und Anwesenheitsprofil.
Der Zugriff ist strikt auf den jeweiligen Empfänger beschränkt; ein administrativer Lesezugriff über die Schnittstelle besteht nicht. Betroffene können ihren Benachrichtigungsverlauf jederzeit selbst vollständig löschen. Eine automatische Aufbewahrungsfrist besteht derzeit nicht; die Datensätze werden beim Löschen des Kontos nicht mitgelöscht.
Geplante Abhilfemaßnahmen: (1) Abschluss der laufenden Umstellung auf rein clientseitig gerenderte Benachrichtigungstexte, wodurch die serverseitigen Klartext-Anzeigetexte einschließlich des Fallübergabe-Freitexts vollständig entfallen; (2) Einführung einer Regel-Aufbewahrungsfrist mit automatischem Löschlauf und Anbindung an den Konto-Löschworkflow; (3) Reduktion des Lesezeitstempels auf ein Gelesen-Kennzeichen; (4) Entfernung des Vorschaumodus aus dem Quellcode, damit eine bloße Konfigurationsänderung die Tabelle nicht in einen Inhaltsspeicher verwandeln kann.
E-Mail-Benachrichtigungen. Benachrichtigungen per E-Mail verlassen die Domäne der Ende-zu-Ende-Verschlüsselung. Versendet werden Einladungen, Passwort-Zurücksetzungen, Einmalcodes für die Zwei-Faktor-Authentisierung, Hinweise auf neue Anfragen sowie Meldungen zur Vertragsunterzeichnung. Chat- oder Beratungsinhalte sind nicht Bestandteil dieser Nachrichten; verifiziert ist, dass keine Nachrichtentexte versendet werden. Enthalten sind jedoch je nach Anlass die Postleitzahl der Anfrage, der Name der Beratungsstelle, der Name der beratenden Person sowie in einzelnen Fällen das Pseudonym der ratsuchenden Person. Bereits die Zustellung offenbart gegenüber der Mail-Infrastruktur das Bestehen einer Beratungsbeziehung. Der Versand erfolgt über mehrere Wege (Anwendungsdienste, Mandanten-Mailserver, Beratungstypdienst) mit verpflichtender Transportverschlüsselung (STARTTLS).
Restrisiko. Zugangsdaten der Mailserver werden nicht einheitlich geschützt: An einer Stelle liegen sie verschlüsselt vor, an einer weiteren nur dann, wenn ein Geheimnis gesetzt ist, und an einer dritten unverschlüsselt in einem Konfigurationsdatensatz. Die Vereinheitlichung (Verschlüsselung ruhender Daten, ausschließlich schreibender Zugriff über die Schnittstelle) ist eine erforderliche Maßnahme (siehe auch Abschnitt 6.16). Push-Benachrichtigungen an mobile Geräte über einen US-amerikanischen Dienst sind im Auslieferungsstand deaktiviert; sie enthalten konstruktionsbedingt keine Inhalte, würden aber Metadaten in ein Drittland übermitteln und wären vor Aktivierung gesondert zu bewerten.
Belege aus dem Code — Abschnitt 6.14 7
- live
Der Vorschaumodus für Benachrichtigungen steht in allen Umgebungen auf „keine Vorschau"; verschlüsselte Ereignisse tragen ohnehin keinen Nachrichtenkörper.
- live
Für Benachrichtigungen besteht keine Aufbewahrungsfrist; der Konto-Löschworkflow erfasst sie nicht.
- live
Der Lesezeitpunkt wird sekundengenau je Benachrichtigung gespeichert.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/model/EventNotification.java:60–94GitHub
- live
Bei Fallübergaben fließt der Begründungs-Freitext in den Anzeigetext der Benachrichtigung.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/service/CaseHandoverService.java:714–843GitHub
- live
E-Mail-Benachrichtigungen enthalten keine Chat- oder Beratungsinhalte, wohl aber Postleitzahl, Agenturname und teils das Pseudonym.
- live
Der Direktversand erzwingt Transportverschlüsselung (STARTTLS).
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/service/accountinvite/mail/JakartaInviteMailTransport.java:34–111GitHub
- standardmäßig aus
Push-Benachrichtigungen an mobile Geräte sind deaktiviert; sie enthielten keinen Inhalt, aber Metadaten an einen Drittlandempfänger.
- ORISO-UserService/src/main/resources/application.properties:155–157GitHub
6.15 Statistische Auswertung
Statistische Auswertungen erfolgen ausschließlich aggregiert und losgelöst von einzelnen Beratungsfällen. Im Administrationsbereich steht ein Statistik-Dashboard zur Verfügung, das Aggregatzahlen anzeigt (neue Beratungsanfragen, aktive Fälle, Themenverteilung, Anzahl Beratender, Gruppenchats — je Träger bzw. Beratungsstelle, tages-, wochen- und monatsweise); Einzelpersonen sind daraus nicht ablesbar. Zum Schutz vor Rückschlüssen aus kleinen Gruppen greift eine Kleinstzellen-Unterdrückung: Aggregate werden erst ab mindestens fünf beitragenden Beratenden ausgewiesen, andernfalls wird der Wert unterdrückt; die Prüfung ist fail-closed ausgelegt und in der Produktivumgebung erzwungen.
Für die Nachrichtenstatistik der Beratenden wird keine Klarkennung gespeichert: Die Zählung erfolgt unter einem kryptografischen Pseudonym (HMAC-SHA256 über die Beraterkennung mit serverseitig verwaltetem Geheimnis). Beratende können ausschließlich ihre eigenen Kennzahlen einsehen; eine personenbezogene Leistungsauswertung durch Dritte findet über die Anwendung nicht statt.
Ehrliche Grenzbenennung. Die Pseudonymisierung ist nicht vollständig wirksam: Neben dem Pseudonym wird die Kennung der auslösenden Beratungssitzung im Klartext geführt, sodass eine Re-Identifikation über eine Verknüpfung mit den Sitzungsdaten möglich bleibt. Eine Aufbewahrungsfrist besteht für diese Zähldaten nicht, und sie werden beim Löschen eines Beraterkontos nicht entfernt. Ferner besteht ein Einzelfall-Endpunkt für Sitzungsdaten einschließlich Postleitzahl, der technischen Dienstkonten vorbehalten ist. Schließlich kann die Anwendung Statistikereignisse an einen Nachrichtenbus veröffentlichen; das Registrierungsereignis enthielte Kontokennung, Alter, Geschlecht, Postleitzahl, Thema und Herkunftsverweis in einem Datensatz. Diese Veröffentlichung ist im Auslieferungsstand abgeschaltet, ein verarbeitender Empfänger ist in den geprüften Beständen nicht auffindbar, und eine Transportverschlüsselung des Nachrichtenbusses ist nicht konfiguriert. Vor Aktivierung sind Empfänger, Speicherort, Aufbewahrung und Löschpropagation zu klären und der Ereignisinhalt zu minimieren.
Belege aus dem Code — Abschnitt 6.15 4
- live
Aggregate werden erst ab mindestens fünf beitragenden Beratenden ausgewiesen; die Prüfung ist fail-closed und in der Produktivumgebung erzwungen.
- live
Die Nachrichtenstatistik der Beratenden nutzt ein HMAC-Pseudonym; daneben steht die Sitzungskennung im Klartext, eine Aufbewahrungsfrist besteht nicht.
- standardmäßig aus
Die Veröffentlichung von Statistikereignissen an den Nachrichtenbus ist abgeschaltet; ein Registrierungsereignis enthielte Kontokennung, Alter, Geschlecht, PLZ, Thema und Herkunftsverweis.
- live
Ein Einzelfall-Endpunkt liefert Sitzungsdaten einschließlich Postleitzahl und ist technischen Dienstkonten vorbehalten.
6.16 Mandantentrennung
Die Plattform ist mandantenfähig: Jeder Träger bildet einen Mandanten, dem Beratungsstellen, Beratende, Rechtstexte und Konfiguration zugeordnet sind. Die Trennung wird über eine Mandantenkennung an den Datensätzen und einen anwendungsseitigen Filter durchgesetzt; sie ist damit applikationsseitig, nicht datenbankseitig realisiert. Fachliche Datenbestände wie die Fallübergabe-Protokolle und die Benachrichtigungen tragen die Mandantenkennung und werden entsprechend gefiltert; administrative Auswertungen sind auf die Agenturen der aufrufenden Person beschränkt und verhalten sich fail-closed.
Risiko und Kompensation. Eine rein anwendungsseitige Trennung ist gegenüber Fehlkonfiguration und Programmierfehlern empfindlich; ein trägerübergreifender Sichtbarkeitsfehler ist in der Vergangenheit aufgetreten und behoben worden. Kompensierend wirken die konsequente Filterung an den Zugriffsschichten, das fail-closed-Verhalten administrativer Auswertungen sowie eine eingeschränkte Agentur-Administrationsrolle. Als Maßnahmen sind Regressionstests für die Mandantentrennung sowie eine Prüfung datenbankseitiger Trennung auszuweisen.
Offen auszuweisender Befund. Die Plattform-Administration kann die vollständigen Einstellungen jedes Mandanten abrufen. Darin enthalten sind derzeit auch Mailserver-Zugangsdaten des Trägers im Klartext, die zudem unverschlüsselt gespeichert werden; ebenso sind die Signaturdaten der Auftragsverarbeitungsvereinbarungen trägerübergreifend einsehbar. Erforderlich sind: ausschließlich schreibender Zugriff auf Geheimnisse über die Schnittstelle, deren Verschlüsselung im Ruhezustand sowie eine Trennung zwischen Betriebs- und Einsichtsrechten (Break-Glass-Zugriff mit Freigabe des Trägers, zeitlicher Befristung und Protokollierung). Bis zur Umsetzung ist der Kreis der Plattform-Administrator:innen eng zu halten, vertraglich zu binden und zu dokumentieren.
Belege aus dem Code — Abschnitt 6.16 3
- live
Die Mandantentrennung wird anwendungsseitig über einen Filter durchgesetzt, nicht datenbankseitig.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/model/EventNotification.java:34–43GitHub
- live
Die Plattform-Administration kann die Mailserver-Zugangsdaten jedes Trägers im Klartext abrufen; sie liegen auch unverschlüsselt in der Datenbank.
- ORISO-TenantService/src/main/java/com/vi/tenantservice/api/facade/TenantFacadeAuthorisationService.java:40–60GitHub
- ORISO-TenantService/src/main/java/com/vi/tenantservice/api/converter/TenantConverter.java:670–705GitHub
- ORISO-TenantService/src/main/java/com/vi/tenantservice/api/model/TenantEntity.java:95–109GitHub
- Live-Prüfung offen
Das globale Mailserver-Passwort wird nur dann verschlüsselt gespeichert, wenn ein Geheimnis gesetzt ist; andernfalls Klartext mit Warnhinweis.
- ORISO-ConsultingTypeService/src/main/java/.../api/service/SmtpPasswordEncryptionService.java:16–50GitHub
6.17 Betrieb, Observability und Telemetrie
Protokollierung der Dienste. Die Anwendungsdienste schreiben strukturierte Protokolle auf die Standardausgabe; eine Rotation oder Aufbewahrung findet in den Diensten selbst nicht statt, sie obliegt der Container-Plattform. Der Protokollkontext enthält keine Kontokennung, sondern eine Korrelationskennung. Gleichwohl gelangen an einzelnen Stellen personenbezogene Angaben in Protokolltexte: Kontokennungen, Benutzernamen im Klartext, in Einzelfällen vollständige E-Mail-Adressen sowie — auf Fehlersuchstufe — Inhalte von Zugriffstoken. Die Protokollstufe ist zur Laufzeit über einen freigegebenen Verwaltungsendpunkt veränderbar. Maßnahmen: Absicherung des Verwaltungsendpunkts, Entfernen der Datensatz-Ausgaben mit Namen und E-Mail-Adressen, Bereinigungsfilter für personenbezogene Angaben sowie eine ausdrückliche Aufbewahrungsfrist für den Protokollbestand.
Ablaufverfolgung und Metriken. Eine Anbindung an eine Beobachtungsplattform (SigNoz) ist vorbereitet; der Export ist im Auslieferungsstand standardmäßig und in der Produktivumgebung deaktiviert. In der Vorabumgebung werden ausschließlich Metriken exportiert, keine Ablaufverfolgungen. Vor einer Aktivierung ist zu prüfen, ob Ablaufverfolgungen Pfade mit Kennungen tragen; Aufbewahrung und Zugriffsschutz der Beobachtungsplattform sind festzulegen.
Fehlermeldungen aus dem Browser. Die Anwendung kann Fehlermeldungen aus dem Browser an den Server melden (Meldungstext, aufgerufene Adresse, Browserkennung, Aufrufkette, Korrelationskennung, jeweils längenbegrenzt). Diese Angaben können Personenbezug tragen und unterliegen der Protokoll-Aufbewahrung. Eine Übermittlung an externe Telemetriedienste findet aus dem Browser nicht statt.
Sicherung und Wiederherstellung. Für die Datenbank des Chat-Dienstes bestehen Sicherungs- und Wiederherstellungsverfahren mit einer Aufbewahrung von 30 Tagen für Vollsicherungen und sieben Tagen für die fortlaufende Protokollsicherung. Für die übrigen Kern-Datenbanken sind im Auslieferungsstand keine Sicherungsaufträge hinterlegt — eine Verfügbarkeitslücke im Sinne der Sicherheit der Verarbeitung nach § 26 KDG (Art. 32 DSGVO). Vor allem aber enthalten die Sicherungsskripte einen Pfad, der Datenbankauszüge in ein externes Quellcode-Verwaltungssystem eines US-amerikanischen Anbieters überträgt. Ob dieser Pfad aktiviert ist, ist vor Freigabe dieser DSFA verbindlich zu klären; bei Aktivierung liegt eine unzulässige Drittlandübermittlung mit praktisch unlöschbarer Historie vor. Ferner ist zu beachten, dass gelöschte Daten bis zum Ablauf der Sicherungsfrist in den Sicherungen fortbestehen.
Übersetzung von Rechtstexten. Für die Übersetzung der mandantenspezifischen Rechtstexte (Impressum, Datenschutzerklärung, Auftragsverarbeitungsvereinbarung) kann eine externe Sprachmodell-Schnittstelle genutzt werden. Übermittelt wird der vollständige Text einschließlich der darin enthaltenen Namen, Anschriften und E-Mail-Adressen der Verantwortlichen und Datenschutzbeauftragten. Die Anbieter haben ihren Sitz außerhalb des Geltungsbereichs; die Nutzung setzt eine Auftragsverarbeitungsvereinbarung sowie eine Prüfung der Drittlandübermittlung voraus. Beratungsinhalte werden zu keinem Zeitpunkt an Sprachmodell-Dienste übermittelt.
Betriebsseitige Härtungspunkte am Chat-Dienst. Im Auslieferungsstand sind die offene Registrierung ohne Verifikation aktiviert, die Ratenbegrenzungen praktisch aufgehoben, Medien ohne Authentifizierung abrufbar und weder für Nachrichten noch für Medien eine Aufbewahrungsfrist gesetzt. Diese Punkte widersprechen dem Grundsatz, dass Konten ausschließlich über die Anwendung entstehen, und sind vor Produktivbetrieb zu schließen.
Belege aus dem Code — Abschnitt 6.17 7
- live
Am Chat-Dienst sind offene Registrierung ohne Verifikation aktiviert und Ratenbegrenzungen praktisch aufgehoben.
- ORISO-Helm/templates/matrix/matrix-configmaps.yaml:154–211GitHub
- standardmäßig aus
Der Export von Ablaufverfolgungen und Metriken ist standardmäßig und in der Produktivumgebung deaktiviert; die Vorabumgebung exportiert nur Metriken.
- live
An einzelnen Stellen gelangen Benutzernamen, E-Mail-Adressen und Datensatz-Ausgaben in Protokolltexte; die Protokollstufe ist zur Laufzeit veränderbar.
- live
Fehlermeldungen aus dem Browser werden serverseitig protokolliert (Meldung, Adresse, Browserkennung, Aufrufkette).
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/adapters/web/controller/ErrorReportController.java:40–96GitHub
- Live-Prüfung offen
Die Sicherungsskripte des Chat-Dienstes enthalten einen Pfad, der Datenbankauszüge in ein externes Quellcode-Verwaltungssystem überträgt.
- live
Für die Kern-Datenbanken außerhalb des Chat-Dienstes sind keine Sicherungsaufträge hinterlegt.
- ORISO-Helm/charts/GitHub
- live
Redaktionelle Rechtstexte können zur Übersetzung an externe Sprachmodell-Schnittstellen übermittelt werden; Beratungsinhalte nicht.
6.18 Löschung und Aufbewahrung
Die Löschfristen je Datenkategorie sind im Löschkonzept (Anlage 2) zusammengeführt. Technisch bestehen folgende Verfahren:
- Kontolöschung durch die betroffene Person. Ratsuchende können ihr Konto selbst löschen. Die Löschung durchläuft ein Schutzfenster von 48 Stunden mit ausschließlich lesendem Zugriff und wird anschließend automatisiert vollzogen. Der Löschlauf entfernt in fester Reihenfolge das Identitätskonto, das Chat-Konto (mit ausdrücklichem Löschkennzeichen und Bereinigung der Räume), Sitzungen und deren Zusatzdaten, Themenzuordnungen, Supervisionszuordnungen, Fallübergabe-Anträge, Agenturzuordnungen, den Eintrag in der Pseudonym-Registrierung, mobile Gerätekennungen und schließlich den Kontodatensatz. Eine Aussetzung der Löschung ist für drei bis höchstens zwölf Monate möglich und wird mit Grund dokumentiert.
- Anonyme Konten. Deaktivierung nach 360 Minuten Inaktivität, Löschung nach 2 820 Minuten (47 Stunden), jeweils stündlich geprüft.
- Gruppenchats. Abgelaufene Gruppenchats werden minütlich geprüft und deaktiviert.
- Nur registrierte Konten ohne Beratung. Ein Löschlauf nach 30 Tagen ist implementiert, im Auslieferungsstand jedoch deaktiviert; bleibt er aus, verbleiben Konten mit hinterlegter E-Mail-Adresse unbegrenzt.
- Nachweisdaten. Signaturen zu Auftragsverarbeitungsvereinbarungen werden im Zustand „abgelehnt" nach einer konfigurierten Frist gelöscht, im Zustand „unterzeichnet" zu Nachweiszwecken aufbewahrt. Das Prüfprotokoll der Support-Zugriffe wird nach zwölf Monaten automatisiert gelöscht — die einzige im Bestand ausdrücklich dokumentierte Aufbewahrungsfrist.
- Grabstein-Datensatz. Nach der endgültigen Löschung verbleibt ein Verweisdatensatz, der die vollständige frühere Kontokennung sowie ein neutrales Anzeigekennzeichen enthält, damit Verweise in fortbestehenden Datensätzen aufgelöst werden können. Er ist unbefristet angelegt.
Ehrliche Lückenbenennung — was der Löschlauf derzeit nicht erfasst. Vom Konto-Löschlauf nicht berührt werden: die In-App-Benachrichtigungen, die serverseitig gespeicherten Nachrichtenentwürfe, die pseudonymisierte Nachrichtenstatistik der Beratenden, das Archiv der versendeten Einladungs-E-Mails, das Prüfprotokoll der Inaktivitätsbenachrichtigungen sowie eine aus der Migration verbliebene Zuordnungstabelle zwischen Person und Chat-Raum, die im Datenmodell der Anwendung nicht abgebildet ist und deshalb für alle Löschverfahren unsichtbar bleibt. Für keine dieser Kategorien besteht zudem eine zeitliche Aufbewahrungsgrenze. Hinzu kommt, dass am Chat-Dienst weder für Nachrichten noch für Mediendateien eine Aufbewahrungsfrist gesetzt ist und dass gelöschte Daten bis zum Ablauf der Sicherungsfristen in Sicherungen fortbestehen. Die Aussage einer „vollständigen" Löschung darf erst geführt werden, wenn diese Lücken geschlossen sind; bis dahin sind sie als Maßnahmen im Löschkonzept aufzunehmen. Diese Offenlegung ist bewusst gewählt: Eine DSFA, die eine unvollständige Löschung als vollständig beschreibt, verlöre ihren Zweck.
Belege aus dem Code — Abschnitt 6.18 10
- live
Der Konto-Löschlauf entfernt Identitätskonto, Chat-Konto (mit Löschkennzeichen und Raumbereinigung), Sitzungen, Zuordnungen und Kontodatensatz.
- live
Der Löschung geht ein Schutzfenster von 48 Stunden mit ausschließlich lesendem Zugriff voraus; eine Aussetzung ist für 3 bis 12 Monate möglich.
- live
Anonyme Konten werden nach 360 Minuten Inaktivität deaktiviert und nach 2820 Minuten gelöscht.
- ORISO-UserService/src/main/resources/application.properties:79–90GitHub
- standardmäßig aus
Der Löschlauf für Konten ohne Beratung nach 30 Tagen ist implementiert, aber deaktiviert.
- ORISO-UserService/src/main/resources/application.properties:92–95GitHub
- live
Nach der Löschung verbleibt ein Verweisdatensatz mit der vollständigen früheren Kontokennung, ohne Frist.
- live
Eine aus der Migration verbliebene Zuordnungstabelle zwischen Person und Chat-Raum existiert nur in den Migrationsskripten und ist für alle Löschverfahren unsichtbar.
- ORISO-UserService/src/main/resources/db/changelog/changeset/0074_remove_rocket_chat_room_ids/0074_changeSet.xml:14–58GitHub
- live
Nachrichtenentwürfe werden auch serverseitig im Klartext gespeichert und vom Löschlauf nicht erfasst.
- ORISO-UserService/src/main/java/de/caritas/cob/userservice/api/model/DraftMessage.javaGitHub
- live
Das Prüfprotokoll der Support-Zugriffe wird nach zwölf Monaten automatisiert gelöscht — die einzige ausdrücklich dokumentierte Aufbewahrungsfrist im Bestand.
- live
Gelöschte Daten bestehen bis zu 30 Tage in den Sicherungen des Chat-Dienstes fort (WAL 7 Tage).
- ORISO-Helm/templates/matrix/matrix-configmaps.yamlGitHub
- live
Am Chat-Dienst ist weder für Nachrichten noch für Mediendateien eine Aufbewahrungsfrist konfiguriert.
- ORISO-Helm/templates/matrix/matrix-configmaps.yaml:109–227GitHub
2 Schwellwertanalyse
Vor der Durchführung einer Datenschutz-Folgenabschätzung (nachfolgend „DSFA") ist zu prüfen, ob die Verarbeitungstätigkeit voraussichtlich ein hohes Risiko für die Rechte und …
7 Rechtsgrundlagen
Die Verarbeitung stützt sich je Verarbeitungsschritt auf unterschiedliche Erlaubnistatbestände. Die nachstehende Zuordnung nennt jeweils die Norm des Gesetzes über den …