Die teuerste Sicherheitsentscheidung einer Gesundheits-App fällt oft vor dem ersten Audit: Wer darf sensible Daten im Betrieb sehen, und wer kann diesen Zugriff später wieder entziehen? Für einen CTO ist deshalb „Build oder Buy“ die falsche erste Frage. Meine Position: Kaufen Sie austauschbare Infrastruktur, aber behalten Sie Kontrolle über Identitäten, Datenflüsse und Löschung im eigenen Team – auch wenn das den Start verzögert.
Ein fertiges SDK spart Entwicklungszeit und verteilt Daten an Stellen, die niemand eingeplant hat
Ein Crash-Bericht erscheint harmlos, bis ein Nutzer seine Symptome in ein Freitextfeld schreibt und genau dieser Text in einer Fehlermeldung landet. Bei Sentry oder Firebase Crashlytics entsteht das Risiko nicht erst durch einen Angriff: Schon eine Stacktrace-Ergänzung, ein Breadcrumb oder eine automatisch erfasste Anfrage kann sensible Inhalte an einen weiteren Empfänger übertragen. Für Gesundheitsdaten ist das besonders folgenreich, weil ihre Verarbeitung nach Art. 9 DSGVO grundsätzlich untersagt ist und eine passende Ausnahme sowie weitere Voraussetzungen erfordert.
Ich würde deshalb kein Monitoring-SDK mit Standardeinstellungen in Produktion nehmen, weil ein späteres Abschalten bereits übertragene Daten und angelegte Zugriffsrechte nicht zurückholt. Vor der Integration sollte das Team ein reales Fehlerereignis mit synthetischen Patientendaten auslösen und im ausgehenden Netzwerkverkehr, im Anbieter-Dashboard und in Exporten nach genau diesen Werten suchen. Ein grünes Datenschutzdokument ersetzt diesen Test nicht, weil es den tatsächlichen Inhalt einer Fehlermeldung nicht kennt.
Das gleiche Problem betrifft Produktanalysen. „Termin geöffnet“ kann ein vertretbares Ereignis sein; „Termin für Onkologie geöffnet“ offenbart bereits mehr. Eine Positivliste für Ereignisse ist deshalb belastbarer als eine Liste verbotener Feldnamen: Neue Entwickler können sonst unbeabsichtigt ein neues sensibles Feld protokollieren. Dieser ausführbare Python-Ausschnitt lässt nur zwei festgelegte Ereignisse durch und verwirft sämtliche zusätzlichen Eigenschaften:
import json
ALLOWED = {"app_opened", "appointment_opened"}
def emit(event, properties):
if event not in ALLOWED:
raise ValueError("Ereignis nicht freigegeben")
safe = {"event": event, "schema": 1}
print(json.dumps(safe, ensure_ascii=False))
emit("appointment_opened", {"diagnose": "synthetischer Testwert"})
Im Beispiel ist „diagnose“ bewusst nicht Teil der Ausgabe; das lässt sich unmittelbar durch Ausführen des Codes prüfen. Die Versionszahl 1 im Schema ist hier ein zu pflegender Vertragswert, keine Sicherheitsgarantie: Ändert sich die Bedeutung eines Ereignisses, muss auch seine Freigabe erneut geprüft werden. In einer echten App gehören vergleichbare Regeln an die Stelle, an der Ereignisse erzeugt werden, und zusätzlich vor den Export. Sonst umgeht ein zweiter SDK-Aufruf die Positivliste.
OpenTelemetry erleichtert die Trennung von Instrumentierung und Export, beseitigt aber keine sensiblen Attribute von selbst; das Team muss sie vor dem Export ausdrücklich ausschließen. OWASP MASVS 2.1.0 bietet für mobile Sicherheitsprüfungen einen konkreten Maßstab, doch ein bestandener Check beweist nicht, dass ein Analytics-Ereignis datensparsam ist. Die relevante Messgröße lautet daher nicht „SDK installiert“, sondern: Welche personenbezogenen Werte verlassen das Gerät bei einem absichtlich provozierten Fehler?
Build gewinnt bei Kontrollpunkten; Buy gewinnt bei austauschbaren Bausteinen
Die zwei Optionen heißen hier eigene Kernarchitektur mit zugekauften Diensten und gekaufte Komplettplattform. Die eigene Kernarchitektur gewinnt, wenn die App Daten aus mehreren Quellen verknüpft, individuelle Einwilligungen abbildet oder einen Anbieterwechsel ohne Datenverlust ermöglichen muss; sie kostet erfahrene Sicherheitsentwicklung, Bereitschaftsdienst und langfristige Pflege. Die Komplettplattform gewinnt, wenn Anforderungen und Datenflüsse eng begrenzt sind und der Anbieter Export, Löschung und Prüfunterlagen nachweisbar beherrscht; sie kostet weniger anfängliche Entwicklung, aber Abhängigkeit von dessen Berechtigungsmodell, Roadmap und Störungsbehebung.
Entscheidend ist, was „gekauft“ tatsächlich umfasst. Ein Anbieter kann TLS 1.3 für die Übertragung und eine verschlüsselte Datenbank anbieten, während eigene Support-Mitarbeiter dennoch Klartext im Administrationsbereich lesen können. Verschlüsselung beantwortet die Frage nach Zugriff nicht, weil der Dienst zur Verarbeitung entschlüsseln muss. Fordern Sie deshalb eine Vorführung mit einem konkreten Testdatensatz: Wer kann ihn über Support-Oberfläche, Backup, Suchindex und Protokolle finden? Lassen sich diese Zugriffe einem Nutzer und einem Zweck zuordnen?
Ich halte den Beitrag Gesundheits-App-Entwicklung: Compliance, Wartung und Support für einen nützlichen Ausgangspunkt, würde aber die Entscheidung über Support-Zugriffe vor die Auswahl der Wartungsprozesse ziehen. Der Grund ist technisch: Eine vertragliche Reaktionszeit hilft wenig, wenn die einzige Diagnosemöglichkeit des Anbieters ein dauerhaftes Leserecht auf Patientendaten ist. Ein zeitlich begrenzter, genehmigter Zugriff mit protokolliertem Anlass verursacht mehr Reibung bei Störungen, begrenzt aber den Kreis möglicher Einsichten.
Setzen Sie für eine solche Freigabe beispielsweise 15 Minuten als zunächst zu justierenden Ablaufwert an, statt einen unbefristeten Support-Account einzurichten. Der Wert ist keine Norm; er muss anhand echter Störungsfälle angepasst werden, weil ein zu kurzes Fenster zu wiederholten Freigaben und ein zu langes zu unnötiger Exposition führt. Verlangen Sie außerdem einen vollständigen Export im vereinbarten Format und testen Sie dessen Import in eine leere Umgebung. FHIR R4 kann beim Austausch klinischer Ressourcen helfen, garantiert aber keine Übertragbarkeit aller app-spezifischen Zustände, weil Berechtigungen, Einwilligungshistorie und Support-Vermerke häufig außerhalb dieser Ressourcen liegen.
Eine sichere Anmeldung löst weder das Geräte- noch das Löschproblem
OAuth 2.0 mit Authorization Code und PKCE nach RFC 7636 ist für mobile Clients eine sinnvolle Grundlage, weil ein abgefangener Autorisierungscode ohne den passenden Verifier schwerer einzulösen ist. OpenID Connect Core 1.0 ergänzt eine definierte Identitätsschicht. Beides beantwortet jedoch nicht, was nach der Anmeldung auf dem Gerät verbleibt: Vorschaubilder im App-Switcher, Dateien im Cache und Inhalte in Push-Nachrichten können Daten preisgeben, obwohl der Anmeldefluss korrekt umgesetzt wurde.
Für lokale Speicherung muss die Entscheidung vom Schadensfall ausgehen. SQLCipher 4 kann eine SQLite-Datenbank verschlüsseln, schützt aber nicht vor jedem Zugriff auf ein bereits entsperrtes Gerät, weil die App während der Nutzung Klartext benötigt. Apple Keychain und Android Keystore eignen sich zur Verwaltung von Schlüsseln beziehungsweise Zugangsdaten; sie sind kein Ersatz für eine festgelegte Cache-Lebensdauer. Als Startwert zur Abstimmung würde ich lokal gespeicherte medizinische Freitexte nach 24 Stunden ohne erneute Nutzung entfernen, sofern die konkrete Offline-Funktion das zulässt. Diese Frist ist eine Produktentscheidung, keine aus einer Norm abgeleitete Pflicht.
Das Gegenargument ist real: Weniger lokale Daten verschlechtern die Nutzung bei schlechter Verbindung und können Support-Anfragen erhöhen. Wer deshalb Offline-Speicherung kauft, sollte nicht nur nach „Verschlüsselung auf dem Gerät“ fragen, sondern eine abgelaufene Sitzung, einen Geräteverlust und eine Kontolöschung vorführen lassen. Bleiben Daten nach dem Logout lesbar, ist die behauptete Zugriffstrennung für diesen Fall widerlegt. Bleiben sie nach der Kontolöschung in einem wiederherstellbaren Backup, braucht das Team eine begründete Aufbewahrungsregel und einen dokumentierten Löschpfad statt einer pauschalen Zusage.
Auch Push-Mitteilungen verdienen eine harte Grenze. „Ihr Befund ist verfügbar“ verrät weniger als ein Befundtext, kann in einem bestimmten Kontext aber ebenfalls Rückschlüsse zulassen, weil Sperrbildschirm und geteilte Geräte nicht unter Kontrolle der App stehen. Die datensparsame Voreinstellung sollte deshalb nur auf eine neue Nachricht in der App hinweisen; zusätzliche Details gehören hinter die Anmeldung. Testen Sie diese Einstellung auf iOS und Android mit gesperrtem Bildschirm, statt allein die Darstellung innerhalb der App zu prüfen.
Ein Vertrag ohne überprüften Ausstieg verschiebt das Sicherheitsrisiko nur
Art. 28 DSGVO macht einen Auftragsverarbeitungsvertrag für eine entsprechende Verarbeitung erforderlich, doch dessen Unterschrift belegt noch keinen funktionierenden Export oder eine wirksame Löschung. Art. 32 verlangt geeignete technische und organisatorische Maßnahmen; welche geeignet sind, hängt vom konkreten Risiko ab. ISO/IEC 27001:2022 kann Hinweise auf ein Informationssicherheits-Managementsystem liefern, ersetzt aber keinen Test der Funktionen, die Ihre App vom Anbieter benötigt.
Ich würde den Beitrag Gesundheits-Apps: Entwicklung, Wartung, Support und Compliance um eine praktisch überprüfbare Ausstiegsklausel ergänzen, weil die Wartbarkeit einer Gesundheits-App auch davon abhängt, ob ihr Betrieb ohne den bisherigen Anbieter fortgesetzt werden kann. Lassen Sie vor Vertragsabschluss einen Export mit synthetischen Konten erzeugen. Prüfen Sie, ob Daten, Zeitstempel, Einwilligungsstände und Löschkennzeichen im Zielsystem dieselbe Bedeutung behalten. Ein CSV-Download ist kein ausreichender Ausstieg, wenn etwa der Widerruf einer Einwilligung nur als interner Statuscode des Anbieters vorliegt.
Vereinbaren Sie für sicherheitsrelevante Vorfälle eine Meldefrist, die Ihrem Team eigene Prüfzeit lässt. Die DSGVO nennt für die Meldung bestimmter Verletzungen an die Aufsichtsbehörde grundsätzlich 72 Stunden ab Bekanntwerden, soweit eine Meldepflicht besteht; das ist eine gesetzliche Frist unter Voraussetzungen und keine Zusage, dass ein Anbieter so lange mit seiner ersten Nachricht warten darf. Eine vertraglich kürzere Erstinformation kostet den Anbieter Bereitschaft und Ihr Team möglicherweise mehr Fehlalarme, ermöglicht aber eine rechtzeitige Risikobewertung.
Ebenso sollte der Vertrag Änderungen an Unterauftragnehmern, Speicherorten und Diagnosewerkzeugen sichtbar machen, weil sich dadurch der reale Datenfluss ändern kann, ohne dass die App neu veröffentlicht wird. Prüfen Sie die Aussage mit einem festen Rhythmus: Als zu erprobenden Prüfzyklus können Sie 30 Tage für den Abgleich von Anbieteränderungen, Berechtigungen und Exporttests wählen. Wird dieser Rhythmus im Betrieb nicht eingehalten, ist eine kürzere Liste kritischer Kontrollen mit klarer Verantwortung wertvoller als ein umfangreicher Kalender, den niemand ausführt.
Die erste Entscheidung gehört in einen Test, nicht in eine Beschaffungsvorlage
Erstellen Sie als Erstes ein synthetisches Patientenkonto und verfolgen Sie einen einzigen sensiblen Freitext vom Gerät bis zu Logs, Support-Oberfläche, Backup und Export. Geben Sie Build- und Buy-Kandidaten denselben Test und lassen Sie jede Fundstelle sowie jeden Zugriff dokumentieren. Erst danach verhandeln Sie Funktionen und Preis: Der Test zeigt, welche Kontrolle Ihr Team behalten muss und welche es guten Gewissens einkaufen kann.
