Internes Arbeitsdokument. Dieses Dokument ist eine Zuarbeit zur Datenschutz-Folgenabschätzung und kein freigegebenes Ergebnis. Es kann Zwischenstände, offene Fragen und Formulierungen enthalten, die so nicht in die DSFA übernommen werden. Lokale Dateipfade des Autors wurden vor der Veröffentlichung entfernt.
Stand: 2026-08-14 · Basis: ORISO-UserService (pre-dev, HEAD 7471b852), ORISO-Admin, ORISO-Frontend, ORISO-Helm, ADR-002/-008/-016, GitHub OpenResilienceInitiative.
Alle Pfade relativ zu [lokaler Pfad entfernt].
| # | Claim (Kurzform) | Verdikt | Kernbeleg |
|---|---|---|---|
| C1 | Side-Room-Zugriff nur Beratungsstelle des Falls, „~8 Berater und der Klient" | PARTIAL | Berater-Scoping TRUE: ORISO-UserService/.../facade/TeamDiscussionFacade.java:163–176 (requireEligibleConsultant: nur consultant_agency-Mitglieder der Agency des Falls, sonst 403). Klient-Teil FALSE: Der Ratsuchende ist nie Mitglied des Side-Rooms — harte Designregel (TeamDiscussionFacade.java:30–37, ADR-016 §1: „team coordination never happens in the client's room"; eingeladen werden ausschließlich Berater, :224–253). Kein Träger-weiter Zugriff: korrekt, es gibt keinen Träger-Pfad; Endpoint ist CONSULTANT_DEFAULT-only (SecurityConfig.java:299–301). „~8" ist keine technische Grenze, sondern typische Teamgröße. |
| C2 | Ratsuchende können zustimmen/unterbinden (policy-abhängig) | PARTIAL | Case Handover: TRUE. Pro Grund client_consent_required (model/CaseHandoverReasonPolicy.java:33–34); wenn gesetzt → Status PENDING_CLIENT_CONSENT, Klient entscheidet selbst via POST .../client-consent (CaseHandoverService.java:331–334, 368–412; Endpoint USER_DEFAULT: SecurityConfig.java:257–261; Klient-UI ORISO-Frontend/src/components/caseHandover/CaseHandoverClientCards.tsx). Default verlangt Consent nur bei COUNSELLOR_ASKED_FOR_ADVICE (CaseHandoverService.java:128 vs. :139,150,161,172 = false). Admin kann Consent-Pflicht pro Grund umkonfigurieren. Supervision: TRUE als Opt-out (SessionSupervisorFacade.java:418–443, Endpoint .../supervision/opt-out, SecurityConfig.java:259–261). Team-Besprechung: FALSE / NICHT GEBAUT — kein Consent, kein Opt-out, keine Sichtbarkeit für den Klienten (nirgends im Facade/Controller/FE vorhanden; bewusstes Design). |
| C3 | Alles wird geloggt, ohne Inhalte preiszugeben | PARTIAL | Case Handover: weitgehend TRUE. Jede Anfrage — auch abgelehnte — erzeugt eine Audit-Zeile case_handover_request mit reason_code, status, audit_outcome, policy_authority, client_consent_required, Zeitstempeln (Tabelle: db/changelog/changeset/0057_case_handover_request/case-handover-request.sql:1–31; Entity CaseHandoverRequest.java:86–87; Ablehnungspfad CaseHandoverService.java:671–696). Outcome-Vokabular: ACTIVE_OWNER, ACCESS_GRANTED, ACCESS_DENIED, PENDING_CLIENT_CONSENT, CLIENT_CONSENT_DECLINED, ALREADY_ANSWERED, NOT_REQUESTED (CaseHandoverService.java:55–61). Admin-Einsicht agency-scoped und fail-closed (CaseHandoverLogsService.java:33–109, Zeilen 40–49: Admin ohne Agency-Zuordnung sieht nichts). Notification-Events case.handover.granted/consent.requested/consent.declined (CaseHandoverService.java:714–835). Aber: (a) das Pflicht-Freitextfeld explanation wird gespeichert und Admins angezeigt — kann fallbezogene Inhalte enthalten; (b) Team-Besprechung wird nur strukturell geloggt (Raum-Anlage + Teilnehmer-Joins: 0070_team_discussion/migrate.sql, team_discussion_participant.join_date; TeamDiscussionFacade.java:255–266), Lesezugriffe/Archivzugriffe erzeugen keinen Audit-Eintrag; (c) forwarded_by_user_id / „DPA 0019_audit_fields" existieren im aktuellen Code nicht (0 Treffer in UserService + ORISO-Database; vermutlich Alt-System Caritas 1.0 — nicht in die DSFA übernehmen). Nachrichteninhalte werden nirgends geloggt (korrekt). |
| C4 | Berater sehen es nicht „einfach so"; Join-Mechanik + read-only-Archiv | PARTIAL (TRUE mit wesentlicher Präzisierung) | Side-Room: Mitglied wird nur, wer das Panel öffnet; jeder Berater der Fall-Agency kann jederzeit beitreten (TeamDiscussionFacade.java:64–96); Anlage nur auf offener, unzugewiesener Anfrage (:178–188); bei Annahme harter Abschluss: ARCHIVED + Matrix events_default-PowerLevel 50 → niemand kann mehr posten, Lesen bleibt für Agency-Berater möglich (:44, 273–302; ADR-016 §2–3). Klienten-1:1-Raum (Kontext für Handover): seit #905 sind alle Berater der Abteilung stille Matrix-Mitglieder des Klientenraums (Kommentar CaseHandoverService.java:870–873; ADR-002 §1). Der Schutz „sieht es nicht einfach so" ist dort ein anwendungsseitiger Vorhang (FE-Hiding, department-scoped Search, auditierter Handover als Reveal-Zeremonie), keine kryptografische oder Matrix-Membership-Trennung innerhalb der Beratungsstelle (ADR-002: „the curtain is access-control / UX, not cryptographic"). Außerhalb der Beratungsstelle greift echte Membership-Trennung. |
| C5 | „Nicht E2EE, aber zugriffskontrolliert" | PARTIAL — so nicht übernehmen | Beide Raumtypen werden bei aktiver Konfiguration mit Megolm-E2EE angelegt: MatrixRoomClient.java:53–67, 100–111 (m.room.encryption, m.megolm.v1.aes-sha2, preset=private_chat, visibility=private); Flag: MatrixSynapseService.java:864–869 → matrix.encryptionEnabled (application.properties:342), Helm-Default true (ORISO-Helm/templates/userservice/userservice-configmap-env.yaml:142). „Nicht E2EE" ist also technisch falsch. Richtig ist: Transport-/Inhaltverschlüsselung per Megolm ist an, die Vertraulichkeitsgrenze ist aber bewusst Zugriffskontrolle, nicht Kryptografie — Schlüssel fließen an alle stillen Mitglieder (ADR-002), und der Server kann per Synapse-Admin-Impersonation Nutzertokens ausstellen (MatrixSynapseService.java:443–449, ENDPOINT_ADMIN_LOGIN_AS_USER), d. h. kein hartes E2EE-Versprechen gegenüber dem Betreiber. |
| C6 | Krankheitsfall: COUNSELLOR_IS_ILL, Vertretungs-Einsicht | TRUE | Default-Grund COUNSELLOR_IS_ILL mit client_consent_required=false (CaseHandoverService.java:156–166; Seed 0057/.../case-handover-request.sql). Ablauf: Berater derselben Beratungsstelle stellt requestAccess mit Grund + Pflicht-Begründung (:304–366) → sofort GRANTED + Audit-Zeile → Matrix-Raum-Join des Vertreters (:848–902) → Fall wird umgehängt (session.setConsultant) → Klient erhält In-Chat-Systemnachricht mit Grundtext („Deine bisherige Berater:in ist leider erkrankt …", 4 Sprachen, :100–109, 756–789) + Notification-Event; Alt-Berater wird benachrichtigt und bleibt Raum-Mitglied (Rückkehr/Reclaim, :898–901). Consent-Pflicht für diesen Grund ist per Admin nachschärfbar. |
| C7 | Zu-/abschaltbar per Permission-Kaskade Plattform→Träger→Beratungsstelle, gilt für TB und CH | PARTIAL — für diese zwei Features FALSE | Die Kaskade existiert (ADR-013; Admin#297-Follow-up geschlossen via Admin PR#664 + AgencyService PR#231: allowedPermissionToggles/enforcedPermissionToggles, SuperAdmin-/Tenant-/Agency-Ebene, ORISO-Admin/src/types/TenantAdminControls.ts:1–12, AgencyPermissionsSettings.tsx:21–52) — deckt aber weder Team-Besprechung noch Case Handover ab: PermissionToggleVisibility.ts enthält keines der beiden Features. TB: nur Tenant-Toggle featureTeamDiscussionEnabled (OtherFunctionsSettings/index.tsx:74–79) + Deploy-Property-Fallback (TeamDiscussionFeatureGate.java:25–48) — keine Beratungsstellen-Stufe. CH: Reason-Policies sind plattform-global (Tabelle ohne tenant_id, 0057-SQL; Admin-Kommentar „Policies are platform-scoped — tenant-level overrides are a backend follow-up", CaseHandoverCard/index.tsx:21–24). Zusätzlich: offener Bug Admin#655 (Policy-Speichern scheitert mit Deserialisierungsfehler auf Pre-Dev) und Befund: SecurityConfig.java:400–403 lässt auch TENANT_ADMIN/SINGLE_TENANT_ADMIN die globale Policy-Tabelle schreiben → potenzieller Cross-Träger-Effekt. |
| Gap | Betrifft | Konkret |
|---|---|---|
| G1 | C7 | Kaskade deckt TB/CH nicht ab. Entweder DSFA-Text abschwächen („Plattform-Property + Träger-Toggle" für TB; „plattformweite Grund-Policies" für CH) oder Feature bauen: teamDiscussion/caseHandover in PermissionToggleVisibility + Agency-Settings + Backend-Gate (TeamDiscussionFeatureGate um Agency-Stufe erweitern; CH-Policies mandantenfähig machen — im Admin-Code bereits als „backend follow-up" markiert). |
| G2 | C7 | Admin#655 offen: Reason-Policy-Speichern schlägt fehl (JSON-Deserialisierung). Solange nicht gemergt, ist die behauptete Konfigurierbarkeit auf Pre-Dev faktisch defekt. |
| G3 | C7/Sicherheit | SecurityConfig.java:400–403: TENANT_ADMIN darf die globale case_handover_reason_policy schreiben. Entweder auf Plattform-Admin einschränken oder Tabelle mandantenfähig machen, bevor die DSFA „Träger kann konfigurieren" sagt. |
| G4 | C3 | explanation (Pflicht-Freitext) landet im Admin-Log. Für die Aussage „ohne Inhalte": UI-Hinweis „keine Fallinhalte in die Begründung" ergänzen oder Feld im Admin-Log maskieren; mindestens als Restrisiko in der DSFA ausweisen. |
| G5 | C3 | Kein Lese-/Archivzugriffs-Audit für die Team-Besprechung (nur Anlage + Joins). Wenn die DSFA „alles wird geloggt" sagen soll: Zugriffs-Events ergänzen; sonst Formulierung auf „Anlage und Teilnahme werden protokolliert" begrenzen. |
| G6 | C5 | Formulierung ersetzen (s. Textbaustein). „Nicht E2EE" ist falsch; „E2EE schützt vor dem Betreiber" wäre ebenfalls falsch. |
| G7 | C3 | „forwarded_by_user_id" / „DPA 0019_audit_fields" aus allen DSFA-Entwürfen streichen — existiert im ORISO-Code nicht (Alt-System-Artefakt). |
Verarbeitungstätigkeit: Kollegiale Fallkoordination (Team-Besprechung) und Fallübergabe (Case Handover)
(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 Plattformbetreiber über die Anwendung ist nicht vorgesehen (serverseitige Durchsetzung, HTTP 403). 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 [Anm.: Rechtsgrundlagen-Einordnung durch DSB].
(2) Fallübergabe. Der Zugriff einer weiteren Beraterin / eines weiteren Beraters auf einen bestehenden Beratungsfall (z. B. Vertretung im Krankheitsfall, Urlaubsvertretung, kollegiale Beratung, 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. Der Grundkatalog ist administrativ konfigurierbar; 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, Ausscheiden), wird die ratsuchende Person unmittelbar nach der Übernahme durch eine Systemnachricht im Beratungsverlauf über die Übernahme und deren Grund informiert.
(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 beratungsstellen-scharf gefiltert; Administratorkonten ohne Beratungsstellen-Zuordnung erhalten keinen Protokollzugriff (Fail-closed-Prinzip).
(4) Technische Vertraulichkeit. Beide Raumtypen werden serverseitig als private, nicht auffindbare Matrix-Räume mit aktivierter Ende-zu-Ende-Verschlüsselung (Megolm) 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, beratungsstellen-scharfe Suche) in Verbindung mit dem protokollierten Übergabeverfahren; gegenüber Dritten außerhalb der Beratungsstelle besteht zusätzlich eine Trennung auf Ebene der Raum-Mitgliedschaft. Der Plattformbetrieb verfügt über administrative Serverfunktionen; ein kryptografischer Ausschluss des Betreibers wird nicht zugesichert [Anm.: verweist auf TOM-Kapitel Betreiberzugriff/Neusta].
(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 Zustimmungserfordernis je Grund ist administrativ konfigurierbar. [Nicht behaupten, solange G1–G3 offen: eine durchgängige Delegationskaskade bis auf Ebene einzelner Beratungsstellen besteht für diese beiden Funktionen derzeit nicht.]
SupervisionReason/SupervisionConsent, Opt-out-Endpoint) — in der DSFA sauber von Case Handover trennen (drei Werkzeuge: Team-Besprechung vor Annahme, Supervision als Lese-Begleitung, Handover als Übernahme; so auch ADR-016 §2).case_handover_request.tenant_id + Hibernate-Tenant-Filter (CaseHandoverRequest.java:34–39) trennen die Audit-Daten mandantenscharf — positiv erwähnenswert.