Files
VulneraDoc/docs/Datenschutz-Dokumentation.md
NOrtmann1 58430a0903 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.
2026-10-15 17:40:35 +02:00

213 lines
13 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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`