QA006

Datenschutz:
Überprüfung der Anwendung hinsichtlich Datenschutz und Datensicherheit.

    Keine unnötigen Berechtigungen
    Keine sensiblen Logs
    Sichere Dateispeicherung
    Backup-Verhalten geprüft
    Datenschutz-Dokumentation erstellt
    usw.

docs/Datenschutz-Dokumentation.md

@@ -0,0 +1,212 @@
+# VulneraDoc – Datenschutz- und Datensicherheits-Dokumentation
+
+Stand: Datenschutz-Review QA-006 (Projektstand `dev-QA004` + Maßnahmen aus diesem Review)
+
+> **Hinweis:** Dieses Dokument beschreibt die *technische* Umsetzung des Datenschutzes in der App
+> (Datenflüsse, Speicherorte, Schutzmaßnahmen). Es ist keine Rechtsberatung. Die rechtliche
+> Bewertung (Rechtsgrundlage, Verzeichnis der Verarbeitungstätigkeiten, ggf. Datenschutz-
+> Folgenabschätzung, Auftragsverarbeitung, Einwilligungen) muss durch die verantwortliche Stelle
+> bzw. deren Datenschutzbeauftragte erfolgen. Die Abschnitte 9 und 10 liefern dafür die
+> technischen Eingangsdaten.
+
+---
+
+## 1. Zweck und Einordnung
+
+VulneraDoc ist eine **Offline-Android-App zur Wunddokumentation**. Pflegekräfte erfassen Patienten,
+dokumentieren Wunden (Checklisten, Freitext, Fotos, Unterschriften) und erzeugen daraus ein PDF,
+das sie öffnen oder teilen können.
+
+Verarbeitet werden **Gesundheitsdaten** (Wundbefunde, Wundfotos) und weitere personenbezogene Daten.
+Gesundheitsdaten zählen nach Art. 9 DSGVO zu den besonderen Kategorien personenbezogener Daten und
+verlangen ein erhöhtes Schutzniveau.
+
+**Grundprinzip der App:** Die Daten verlassen das Gerät **ausschließlich auf ausdrückliche
+Handlung des Nutzers** (PDF/Bilder öffnen oder teilen). Es gibt keinen Server, keine Cloud, kein
+Konto, keine Analyse- oder Absturzberichts-Dienste.
+
+---
+
+## 2. Verarbeitete Daten
+
+| Datenart | Felder / Inhalt | Speicherort (App-intern) |
+|---|---|---|
+| Patientenstammdaten | Vorname, Nachname, Geburtsdatum, Straße, PLZ, Ort, bis zu 3 Telefonnummern | Datenbank `wunddoku.db` |
+| Dokumentation | Erstelldatum, Checklisten-Zustände, Freitexte (Wundbefund, Maßnahmen) | Datenbank |
+| Wundfotos | Fotos aus Kamera bzw. Photo Picker | `files/photos/<Dokumentations-ID>/` |
+| Unterschriften | Name des Unterzeichners, Unterschrift als PNG | Datenbank + `files/signatures/<Dokumentations-ID>/` |
+| Wundversorger-Register | Name und Unterschrift der Pflegekraft (für Wiederverwendung) | Datenbank + `files/wound_carer_signatures/` |
+| PDF-Export | Vollständiger Bericht inkl. Stammdaten, Befund, Fotos, Unterschriften | `files/pdf/<Dokumentations-ID>/` |
+| Bildexport | Seiten des PDFs als JPEG (zum Teilen als Bilder) | `files/pdf_images/<Dokumentations-ID>/` |
+| Kameraaufnahme (temporär) | Foto bis zum Import in die Dokumentation | `cache/camera/` |
+
+Alle Speicherorte liegen im **privaten internen App-Speicher**. Es wird kein öffentlicher
+Speicher (Galerie, Downloads, SD-Karte) beschrieben.
+
+**Hinweis Dateiname:** Das PDF heißt `Erstelldatum_Vorname_Nachname_Geburtsdatum.pdf` und enthält
+damit personenbezogene Daten. Der Name wird beim Teilen/Öffnen an die gewählte Ziel-App übergeben
+(siehe Abschnitt 6, Restrisiko R4).
+
+---
+
+## 3. Berechtigungen
+
+Die App fordert **keine einzige Berechtigung** an.
+
+| Funktion | Technik | Berechtigung nötig? |
+|---|---|---|
+| Fotos auswählen | System-Photo-Picker | Nein |
+| Foto aufnehmen | System-Kamera-App über `ACTION_IMAGE_CAPTURE` (die App greift nicht selbst auf die Kamera zu) | Nein (`CAMERA` nicht deklariert) |
+| PDF speichern | Privater App-Speicher | Nein |
+| PDF öffnen/teilen | `FileProvider` + Android-Sharesheet | Nein |
+| Netzwerk | nicht vorhanden | `INTERNET` ist im Manifest **ausdrücklich entfernt** (`tools:node="remove"`) |
+
+Durchsetzung: Das Manifest entfernt `INTERNET` und `ACCESS_NETWORK_STATE` beim Zusammenführen mit
+Bibliotheks-Manifesten. Der Test `PrivacyConfigurationTest` prüft das fertig zusammengeführte
+Manifest auf dem Gerät.
+
+---
+
+## 4. Datenflüsse nach außen
+
+Daten verlassen das Gerät nur in diesen Fällen – jeweils durch eine bewusste Aktion des Nutzers:
+
+1. **PDF öffnen** – Übergabe der PDF per `content://`-URI mit *Lese*recht an die gewählte PDF-App.
+2. **PDF teilen / Bilder teilen** – Übergabe per Android-Sharesheet mit *Lese*recht, nur
+   `EXTRA_STREAM` (die Datei). Es wird **kein** Text, Betreff oder Empfänger mit Patientendaten
+   vorbelegt.
+3. **Fotoimport** – Fotos werden *in* die App kopiert (Photo Picker / Kamera); die Originale
+   verbleiben dort, wo sie der Nutzer gespeichert hat. Beim Import wird das Foto neu als JPEG
+   kodiert; Metadaten des Originals (z. B. GPS-Position) werden dadurch **nicht** übernommen.
+
+Nicht vorhanden: Netzwerkzugriff, Cloud-Backup, Geräte-zu-Geräte-Transfer, Analyse/Tracking,
+Absturzberichte, Werbung, Zwischenablage, Weitergabe an Dritte durch die App selbst.
+
+**Verantwortung nach dem Teilen:** Sobald eine PDF an eine andere App übergeben wurde, liegt der
+weitere Umgang außerhalb der Kontrolle von VulneraDoc (z. B. E-Mail-Programm, Messenger,
+Cloud-Speicher). Das ist organisatorisch zu regeln (Abschnitt 9).
+
+---
+
+## 5. Technische und organisatorische Schutzmaßnahmen in der App
+
+### 5.1 Speicherung
+- Ausschließlich privater interner Speicher (`filesDir`, `cacheDir`); kein `getExternalFilesDir`,
+  keine `MediaStore`-Nutzung, keine `MODE_WORLD_*`-Dateien.
+- Dateien sind für andere Apps nicht lesbar (Android-App-Sandbox, Dateirechte).
+- **Pfadsicherheit:** Datei-/Ordnernamen werden über `SafePaths` aufgelöst (kein `../`, keine
+  Pfadtrenner, keine Symlink-Ausbrüche).
+- **Atomares Schreiben der PDF:** Erst temporäre Datei, dann Umbenennen – kein halbfertiges PDF,
+  eine vorhandene PDF geht bei einem Fehler nicht verloren.
+
+### 5.2 Freigabe über FileProvider (Prinzip der minimalen Freigabe)
+Nur diese Ordner können nach außen gegeben werden:
+`files/pdf/`, `files/pdf_images/` (Exporte) und `cache/camera/` (Kameraaufnahme).
+**Nicht** freigegeben: Originalfotos (`photos/`), Unterschriften (`signatures/`), Datenbank,
+Wundversorger-Register. Der `FileProvider` ist nicht exportiert (`exported="false"`), Rechte werden
+nur pro Vorgang als Leserecht vergeben.
+
+### 5.3 Backup
+- `android:allowBackup="false"` – kein Cloud-/Auto-Backup.
+- `data_extraction_rules.xml` schließt für `cloud-backup` **und** `device-transfer` die Bereiche
+  `database`, `file` und `sharedpref` aus; es gibt kein `<include>`.
+- Folge: Beim Gerätewechsel oder nach Deinstallation sind die Daten **nicht** automatisch
+  wiederherstellbar. Das ist gewollt (Datenschutz), muss aber organisatorisch bekannt sein
+  (z. B. PDFs als Archiv in der Einrichtungsdokumentation ablegen).
+
+### 5.4 Oberfläche
+- `FLAG_SECURE` im Hauptfenster: keine Screenshots, keine Bildschirmaufnahme, keine Vorschau im
+  App-Wechsler.
+
+### 5.5 Protokollierung (Logs)
+- Es gibt keine Konsolenausgaben und keinen `printStackTrace`-Aufruf.
+- Es existiert genau ein Log-Aufruf (Fehler beim Fotoimport). Er schreibt **nur den Typ** der
+  Exception, nie die Fehlermeldung (diese kann Dateipfade oder URIs enthalten), nie Namen oder
+  Patientendaten.
+- Fehlermeldungen in der Oberfläche sind allgemein formuliert und enthalten keine Pfade oder
+  Exception-Texte.
+
+### 5.6 Löschkonzept
+| Auslöser | Was wird gelöscht |
+|---|---|
+| Dokumentation löschen | Datenbankzeilen (inkl. Checklisten, Foto- und Signatur-Einträge), Fotos, Signaturen **und** zugehörige PDF- und Bildexporte |
+| Einzelnes Foto / einzelne Signatur löschen | Datenbankzeile und Datei |
+| Patient löschen | Nur möglich, wenn keine Dokumentation mehr existiert |
+| Automatisch beim App-Start | PDF-/Bildexporte älter als **7 Tage**; liegengebliebene Kameraaufnahmen älter als **24 Stunden** |
+| Deinstallation der App | Alle App-Daten (Android entfernt den privaten Speicher) |
+
+Die automatisch gelöschten Exporte lassen sich jederzeit aus der Dokumentation neu erzeugen.
+Die Fristen stehen als Konstanten in `InternalExportedFilesCleaner` und können angepasst werden.
+
+### 5.7 Fehlerbehandlung als Datenschutz-/Integritätsmaßnahme
+Fehlerfälle (Speicher voll, defekte Bilder, PDF-Fehler) führen nicht zu Datenverlust oder zu
+verwaisten Dateien (siehe Tests aus QA-004): fehlgeschlagene Importe hinterlassen keine
+Halbdateien, Datenbank und Dateien bleiben konsistent, Autosave-Fehler werden dem Nutzer gemeldet.
+
+---
+
+## 6. Bekannte Restrisiken und Empfehlungen
+
+| Nr. | Restrisiko | Bewertung | Empfehlung |
+|---|---|---|---|
+| R1 | **Datenbank und Dateien sind nicht zusätzlich verschlüsselt** (nur Android-Sandbox + Gerätespeicher-Verschlüsselung). Auf gerooteten Geräten oder bei kompromittiertem Gerät sind Daten lesbar. | mittel | Gerät mit Bildschirmsperre und aktivierter Speicherverschlüsselung betreiben (Standard seit Android 10). Bei erhöhtem Schutzbedarf Datenbankverschlüsselung (z. B. SQLCipher mit Schlüssel im Android Keystore) einplanen. |
+| R2 | **Keine App-eigene Sperre** (PIN/Biometrie). Wer das entsperrte Gerät hat, sieht die Daten. | mittel | Gerätesperre verbindlich vorschreiben; optional App-Sperre mit `BiometricPrompt` einführen. |
+| R3 | **Tastatur-Lernfunktion/Autofill:** Eingaben (Namen, Befund-Freitexte) können von der Bildschirmtastatur oder einem Autofill-Dienst mitgelernt werden. | gering–mittel | Geräte-Richtlinie: nur vertrauenswürdige Tastatur, Personalisierung/Cloud-Funktionen der Tastatur deaktivieren. |
+| R4 | **Dateiname des PDFs enthält Name und Geburtsdatum** und ist in Ziel-Apps (Mailanhang, Messenger) sichtbar. | gering–mittel | Fachliche Entscheidung: neutralen Dateinamen (z. B. nur Dokumentations-ID/Datum) anbieten. |
+| R5 | **Weitergabe über andere Apps** liegt nach dem Teilen außerhalb der App-Kontrolle. | organisatorisch | Zulässige Übertragungswege festlegen (z. B. nur dienstliches Postfach/Messenger); Mitarbeiter schulen. |
+| R6 | **Release-Build ohne Code-Verkleinerung/Obfuskation** (`isMinifyEnabled = false`). | gering | Für die Veröffentlichung R8 aktivieren (bessere Härtung gegen Reverse Engineering; kein Ersatz für Datenschutzmaßnahmen). |
+| R7 | **Kein automatischer Abgleich/Backup**: Geräteverlust oder Defekt = Datenverlust. | Verfügbarkeit | Organisatorisches Archiv (z. B. PDFs in die Patientenakte der Einrichtung). |
+| R8 | **Kamera-App des Herstellers** speichert Aufnahmen evtl. zusätzlich in der Galerie/Cloud (bei `ACTION_IMAGE_CAPTURE` mit Ziel-URI normalerweise nicht, herstellerabhängig). | gering | Auf Testgeräten prüfen, ob Aufnahmen zusätzlich in der Galerie erscheinen. |
+
+---
+
+## 7. Automatisierte Datenschutz-Tests
+
+| Test | Art | Prüft |
+|---|---|---|
+| `PrivacySourceScanTest` | JVM | Keine Netzwerk-/Tracking-Bibliotheken, keine `println`/`printStackTrace`, Log-Aufrufe ohne Nachricht/Pfad/Personendaten, kein externer Speicher, keine Zwischenablage, keine Texte in Share-Intents, Manifest ohne Berechtigungen, `allowBackup=false`, nur eine exportierte Komponente, Backup-Regeln, FileProvider-Freigaben |
+| `SafePathsTest` | JVM | Schutz vor Path-Traversal |
+| `ExportedFilesCleanerTest` | JVM | Löschen der Exporte, Aufbewahrungsfristen, kein Löschen außerhalb der Exportordner |
+| `PrivacyConfigurationTest` | Gerät/Emulator | Zusammengeführtes Manifest (Berechtigungen, exportierte Komponenten), Backup, FileProvider-Freigaben, private Dateirechte, `FLAG_SECURE` |
+| `DocumentationDeletionPrivacyTest` | Gerät/Emulator | Löschen einer Dokumentation entfernt auch die Exporte |
+
+Diese Tests dienen als Regressionsschutz: Sie schlagen an, wenn künftig z. B. eine Berechtigung,
+eine Netzwerkbibliothek oder eine zu weite Freigabe hinzukommt.
+
+---
+
+## 8. Checkliste für Releases
+
+- [ ] Alle Tests grün (insbesondere die Datenschutz-Tests aus Abschnitt 7)
+- [ ] Merged Manifest geprüft (Android Studio → `AndroidManifest.xml` → Tab *Merged Manifest*): keine neuen Berechtigungen/exportierten Komponenten
+- [ ] Neue Abhängigkeiten auf Netzwerk-/Tracking-Funktionen geprüft
+- [ ] Neue Log-Ausgaben enthalten keine Patientendaten, Pfade, URIs oder Exception-Nachrichten
+- [ ] Neue Speicherorte liegen im privaten Speicher; neue Freigaben sind in `file_paths.xml` minimal
+- [ ] Neue Datenfelder sind in Abschnitt 2 dieses Dokuments ergänzt und im Löschkonzept berücksichtigt
+- [ ] Release-Build signiert, nicht debuggable
+
+---
+
+## 9. Organisatorische Hinweise (für die verantwortliche Stelle)
+
+Diese Punkte kann die App nicht technisch lösen:
+
+- **Rechtsgrundlage** der Verarbeitung (Behandlungsvertrag / Dokumentationspflicht, Art. 9 Abs. 2
+  lit. h DSGVO) und **Verzeichnis der Verarbeitungstätigkeiten** durch die verantwortliche Stelle
+- Prüfung, ob eine **Datenschutz-Folgenabschätzung** (Art. 35 DSGVO) erforderlich ist
+  (Gesundheitsdaten, ggf. in größerem Umfang)
+- **Geräterichtlinie:** Bildschirmsperre, Geräteverschlüsselung, Updates, ggf. MDM, Regelung
+  privater vs. dienstlicher Geräte
+- **Übertragungswege** für das Teilen von PDFs, Aufbewahrungs- und Löschfristen im Archiv
+- **Betroffenenrechte** (Auskunft, Berichtigung, Löschung): Löschung ist je Dokumentation in der
+  App möglich; Auskunft über den PDF-Export
+- Schulung der Anwender, Meldeweg bei Geräteverlust (Meldepflicht bei Datenpannen, Art. 33 DSGVO)
+
+## 10. Technische Eckdaten für Datenschutzdokumente
+
+- Verarbeitung ausschließlich lokal auf dem Gerät; keine Empfänger durch die App
+- Keine Auftragsverarbeiter durch die App (kein Server, keine Cloud, keine Analyse-/Crash-Dienste)
+- Keine Datenübermittlung in Drittländer durch die App
+- Keine Cookies, kein Tracking, keine Werbe-ID
+- Speicherdauer: bis zur Löschung durch den Nutzer; Exporte automatisch nach 7 Tagen
+- Zugriffsschutz: Android-App-Sandbox, Gerätesperre; `FLAG_SECURE`

docs/QA-006-Review-Befunde.md

@@ -0,0 +1,50 @@
+# QA-006 – Datenschutz-Review: Befunde und Maßnahmen
+
+Geprüft wurde der Projektstand `dev-QA004` (Manifest, Backup-Regeln, FileProvider, Quelltext,
+Abhängigkeiten, Speicher-, Lösch- und Exportabläufe). Die App wurde **nicht** auf einem Gerät
+dynamisch untersucht (kein Netzwerk-Mitschnitt, kein Test der Hersteller-Kamera-App).
+
+## Bereits gut umgesetzt (keine Änderung nötig)
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| Berechtigungen | Keine deklariert; Photo Picker und System-Kamera-App statt eigener Kamera-/Speicherzugriffe |
+| Netzwerk | Kein Netzwerkcode, keine Netzwerk-/Tracking-Bibliotheken |
+| Backup | `allowBackup=false` und `data_extraction_rules` (Cloud-Backup + Geräte-Transfer) schließen alles aus |
+| Speicherort | Nur privater interner Speicher, kein öffentlicher/externer Speicher |
+| Bildschirm | `FLAG_SECURE` (keine Screenshots, keine App-Wechsler-Vorschau) |
+| Komponenten | Nur `MainActivity` exportiert; `FileProvider` nicht exportiert |
+| Share-Intents | Nur Datei (`EXTRA_STREAM`), kein Text/Betreff mit Patientendaten |
+| Datenbank | Keine destruktive Migration (kein stiller Datenverlust bei Updates) |
+| Metadaten in Fotos | Beim Import neu kodiert → GPS/EXIF des Originals wird nicht übernommen |
+| Fehlermeldungen in der UI | Ohne Pfade/Exception-Texte |
+
+## Befunde und umgesetzte Maßnahmen
+
+| Nr. | Befund | Schwere | Maßnahme | Datei(en) |
+|---|---|---|---|---|
+| B1 | **Log beim Fotoimport schrieb `e.message`.** Bei Dateifehlern enthält die Meldung häufig Pfad bzw. Bild-URI – entgegen dem Kommentar im Code. | mittel | Es wird nur noch der Exception-Typ geloggt. | `DocumentationEditViewModel.kt` |
+| B2 | **PDF- und Bildexporte blieben nach dem Löschen einer Dokumentation im Speicher** (enthalten Name, Geburtsdatum, Anschrift, Befund, Fotos). | hoch | Löschen der Dokumentation entfernt jetzt auch `pdf/<id>/` und `pdf_images/<id>/`. | `ExportedFilesCleaner.kt` (neu), `DocumentationRepository.kt`, `AppContainer.kt` |
+| B3 | **Exporte hatten keine Aufbewahrungsfrist.** Alte PDFs lagen unbegrenzt im App-Speicher. | mittel | Beim App-Start werden Exporte älter als 7 Tage gelöscht (jederzeit neu erzeugbar). | `ExportedFilesCleaner.kt`, `WunddokuApplication.kt` |
+| B4 | **Kameraaufnahmen konnten im Cache liegen bleiben**, wenn die App zwischen Aufnahme und Import beendet wurde. | gering–mittel | Aufnahmen älter als 24 h werden beim App-Start gelöscht (Frist bewusst lang, damit eine noch ausstehende Aufnahme nach einem Neustart importierbar bleibt). | `ExportedFilesCleaner.kt` |
+| B5 | **FileProvider gab `photos/` und `signatures/` frei**, obwohl nie darüber geteilt wird. | gering (Prinzip der minimalen Freigabe) | Freigaben auf `pdf/`, `pdf_images/`, `cache/camera/` reduziert. | `file_paths.xml` |
+| B6 | **`INTERNET` konnte über eine künftige Bibliothek unbemerkt ins Manifest gelangen.** | gering (Vorsorge) | `INTERNET` und `ACCESS_NETWORK_STATE` werden beim Manifest-Merge explizit entfernt. | `AndroidManifest.xml` |
+| B7 | **Pfadauflösung ohne Traversal-Schutz** (`File(dir, name)`). Namen stammen aus der eigenen DB (UUIDs), daher kein akutes Risiko. | gering (Defense-in-Depth) | `SafePaths.resolveChild` in Foto-/Signatur-Speicher und Cleaner. | `SafePaths.kt` (neu), `PhotoStorage.kt`, `SignatureStorage.kt` |
+
+## Offene Punkte (bewusst NICHT geändert – Produktentscheidung nötig)
+
+| Nr. | Thema | Empfehlung |
+|---|---|---|
+| O1 | Datenbank/Dateien nicht zusätzlich verschlüsselt (Restrisiko R1) | Bei erhöhtem Schutzbedarf SQLCipher + Android Keystore; sonst Geräteverschlüsselung + Sperre vorschreiben |
+| O2 | Keine App-Sperre (PIN/Biometrie) (R2) | `BiometricPrompt` beim Start/Wiederöffnen erwägen |
+| O3 | PDF-Dateiname enthält Name + Geburtsdatum (R4) | Neutralen Dateinamen als Option; würde `PdfFileNameGenerator` und dessen Tests ändern |
+| O4 | Tastatur-Lernfunktion/Autofill (R3) | Geräterichtlinie; in Compose nur eingeschränkt steuerbar |
+| O5 | `isMinifyEnabled = false` (R6) | R8 vor Veröffentlichung aktivieren und Release-Build testen |
+| O6 | Dynamische Prüfung auf echten Geräten (Netzwerkmitschnitt, Hersteller-Kamera, Galerie-Kopien) | Vor Produktivbetrieb einmal durchführen |
+
+## Wichtig zu den Änderungen B2/B3
+
+B2 und B3 ändern das Verhalten: Exportierte PDFs verschwinden nach 7 Tagen und beim Löschen der
+Dokumentation. Wenn die App PDFs länger vorhalten soll, `DEFAULT_EXPORT_MAX_AGE_MILLIS` in
+`InternalExportedFilesCleaner` erhöhen. Bereits **geteilte** Kopien in anderen Apps sind davon
+natürlich nicht betroffen.