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.
This commit is contained in:
NOrtmann1
2026-10-15 17:40:35 +02:00
parent 742ef39f05
commit 58430a0903
18 changed files with 1207 additions and 11 deletions
+212
View File
@@ -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`