Sicherheit bei AgendaPlus
Wie wir Ihre Klinik- und Patientendaten technisch und organisatorisch schützen. Für Entscheidungsträger und IT-Verantwortliche in Arztpraxen.
Zuletzt aktualisiert: Juli 2026 (basierend auf einem internen Security-Hardening-Audit vom 7. April 2026, ergänzt durch eine zweite Hardening-Welle im Mai 2026: Inbound-Webhook-Authentifizierung, Account-Sperre, gehashte Passwort-Reset-Tokens, TLS 1.2+ erzwungen mit HSTS-Preload-Eintragung; im Juli 2026 weiter gehärtet: strikte Schema-Validierung mit Feld-Allowlist und Body-Grössenlimit, fail-closed Mandantentrennung als zusätzliche Sicherungsebene, PII-redigiertes Echtzeit-Fehler-Monitoring; Mitte Juli 2026: phishing-resistente Passkeys (WebAuthn) als zusätzlicher zweiter Faktor für privilegierte Konten sowie durchgängige Audit-Protokollierung administrativer Aktionen).
1. Hosting und Datenstandort
Die gesamte Plattform läuft auf Servern der Hetzner Online GmbH in Deutschland — innerhalb der EU, als Grundlage unserer EU-Datenresidenz. Kein produktiver Datenverkehr verlässt die EU/EWR, ausser bei klar benannten Subprozessoren (siehe /dpa Anhang B). Das Frontend wird über Vercel in der Region Frankfurt ausgeliefert. Sämtlicher HTTP/HTTPS-Traffic läuft über einen CDN- und WAF-Layer (Cloudflare); die interne Server-Adresse ist nicht öffentlich erreichbar.
2. Netzwerk-Perimeter
• Der Backend-Server ist ausschliesslich über den CDN-/WAF-Layer ansprechbar. Direkter Zugriff unter Umgehung des WAF ist auf Firewall-Ebene blockiert. • Administrativer Zugang ist auf autorisierte IP-Adressen eingeschränkt; öffentlicher Administrator-Zugang ist unterbunden. • Interne Dienste (Datenbank, Cache, Worker) sind ausschliesslich lokal gebunden und nicht von aussen erreichbar. • Auf der WAF-Ebene aktiv: DDoS-Mitigation (HTTP-, TLS- und Netzwerk-Schicht), Erkennung kompromittierter Zugangsdaten beim Login, schemagetriebene Request-Validierung auf den sicherheitsrelevanten API-Endpunkten und Browser Integrity Check.
3. Verschlüsselung
• Transport: HTTPS durchgehend erzwungen, mit moderner TLS-Konfiguration (TLS 1.2 und 1.3, ältere Protokollversionen sind auf der CDN-Ebene deaktiviert). HSTS ist mit langfristiger max-age und includeSubDomains / preload aktiv; die Domain ist beim HSTS-Preload-Verzeichnis eingetragen. • At-Rest: Besonders schützenswerte Felder (Telefonnummern, klinische Notizen, Medikations-Angaben, Nachrichteninhalte) sind auf Applikationsebene verschlüsselt (AES-256-GCM, Envelope-Verfahren mit separatem Master-Key ausserhalb der Datenbank). Backups sind mit einem Off-Server-Schlüssel verschlüsselt. Ausgemusterte Datenträger werden vom Rechenzentrum nach ISO/IEC 21964 (Schutzklasse H4) physisch vernichtet. • Auch die lokale Praxis-Software-Anbindung (AgendaPlus Bridge) überträgt ausschliesslich TLS-verschlüsselt über denselben geschützten HTTPS-Perimeter — zwischen Praxis und Plattform existiert kein unverschlüsselter Kanal. • Patientendaten in der Task-Queue (Versand-Warteschlange) werden ebenfalls verschlüsselt transportiert — im Broker liegt kein Klartext. • Passwort-Geheimnisse werden mit Bcrypt gehasht. 2FA-Seeds werden verschlüsselt gespeichert. Session-Tokens werden serverseitig signiert. • Passwort-Reset-Tokens werden nur als SHA-256-Hash in der Datenbank gespeichert — der eigentliche Token verlässt nie den Reset-Link, den die Person erhält.
4. HTTP-Sicherheitsheader
Alle ausgelieferten Antworten setzen einen gehärteten Header-Satz: • Eine strikte Content-Security-Policy, die nur vertrauenswürdige Herkünfte zulässt. • Langfristiges HSTS mit includeSubDomains und preload. • X-Frame-Options: DENY (Schutz vor Clickjacking). • X-Content-Type-Options: nosniff. • Restriktive Permissions-Policy — Kamera, Mikrofon, Standort und Zahlungsmittel sind auf sämtlichen Seiten deaktiviert. • Referrer-Policy: strict-origin-when-cross-origin. • Cache-Control: no-store auf allen API-Routen.
5. Authentifizierung und Zugriffskontrolle
• Zwei-Faktor-Authentifizierung (TOTP) ist für alle Superadmin- und Klinikadmin-Konten zwingend erforderlich — nicht optional, nicht umgehbar. • Für privilegierte Konten stehen zusätzlich phishing-resistente Passkeys (WebAuthn/FIDO2, an Gerät und Domain gebunden) als starker zweiter Faktor zur Verfügung. • Authentifizierung erfolgt ausschliesslich über serverseitig signierte Bearer-Tokens. Sessions sind auf maximal 10 Stunden begrenzt und werden zusätzlich beim Schliessen des Browsers automatisch beendet, sodass am nächsten Morgen eine erneute Anmeldung erforderlich ist. • Login-Endpunkte sind strikt rate-limitiert (pro echter Endkunden-IP, nicht pro CDN-Egress); Versuche mit bekannt kompromittierten Passwörtern werden bereits auf der WAF-Ebene blockiert. • Pro Konto: nach wiederholten fehlgeschlagenen Anmeldeversuchen wird das Konto vorübergehend automatisch gesperrt. • Passwörter werden nie im Klartext gespeichert oder übertragen. Mindestanforderungen an Länge und Komplexität werden durchgesetzt. • Rollenbasierte Zugriffskontrolle auf Klinik-, Mitarbeiter- und Patientenebene. Ein Mitarbeiter einer Klinik kann keine Daten einer anderen Klinik sehen.
6. API-Härtung
• Öffentliche API-Dokumentations-Endpunkte (Swagger UI, ReDoc, OpenAPI-Spezifikation) sind in Produktion deaktiviert — die API-Struktur ist nicht öffentlich erkundbar. • Anfragen an sicherheitsrelevante Endpunkte werden schemabasiert validiert und nicht-konforme Requests verworfen, bevor sie den Origin-Server erreichen. • Rate-Limiting auf Endpunkten mit Missbrauchsrisiko. • Konfigurationsgeheimnisse werden ausschliesslich serverseitig gehalten; sie werden nicht in den Browser ausgeliefert.
7. Audit und Nachvollziehbarkeit
Jede sicherheits- oder datenschutzrelevante Aktion wird protokolliert: Anmeldungen, Patientendatensatz-Änderungen, Einladungen, Einstellungsänderungen, administrative Impersonationen. Das Audit-Log umfasst Zeitstempel, handelnde Person, IP-Adresse, User-Agent und Metadaten. Aufbewahrung: 12 Monate (gesetzliches Minimum nach Art. 4 DSV), danach automatische Löschung (siehe Datenschutzerklärung). Jede Einwilligungsvergabe oder -rücknahme durch Patientinnen und Patienten wird separat in einem unveränderlichen Consent-Log festgehalten (Aufbewahrung: solange die Einwilligung gültig ist und genutzt wird; die 3-Jahres-Frist gemäss nDSG Art. 6 beginnt erst mit einem beendenden Ereignis — Widerruf oder Löschung der Praxis). Der Eintrag enthält keine Vor- oder Nachnamen — er ist an die interne UUID und die PMS-interne Patientennummer der Praxis gebunden. Die einwilligende Telefonnummer wird bewusst als Nachweis aufbewahrt, wer zugestimmt hat (die Minimalidentität der Einwilligung); zusätzlich wird sie als SHA-256-Hash für den Abgleich hinterlegt. Name, Behandlungsart und operative Daten werden hingegen mit dem Patienten-Lebenszyklus gelöscht (Datenminimierung, nDSG Art. 6).
8. Datensicherung und Wiederherstellung
• Kontinuierliche Datenbank-Sicherung mit Point-in-Time-Recovery: jede Änderung wird laufend gesichert (Wiederherstellungspunkt ca. 1 Minute), zusätzlich wöchentliche Voll- und tägliche Differenz-Backups. • Backup-Speicherung in einem Schweizer Rechenzentrum (Infomaniak, Genf) — bewusst bei einem anderen Anbieter als das Server-Hosting, damit Server und Sicherung nie gleichzeitig ausfallen. • Backups werden bereits auf unserem Server AES-256-verschlüsselt; der Speicheranbieter erhält ausschliesslich unlesbaren Ciphertext. Der Schlüssel verbleibt allein bei uns. • Wiederherstellungsverfahren werden vierteljährlich getestet (dokumentierte Restore-Übung). • Die Aufbewahrungsdauer von Backups ist so kurz wie nötig (ca. 4–5 Wochen rollierend), um Datenschutz (kurze Aufbewahrung) und Recovery (ausreichendes Zeitfenster) zu balancieren.
9. Reduzierung des Datenabflusses (Data Minimisation)
Die Plattform ist so konfiguriert, dass ein Datenabfluss nach aussen standardmässig nicht stattfindet, wo er nicht notwendig ist: • Fehlerreports (Sentry) werden ohne PII übertragen: sendDefaultPii ist deaktiviert, ein zusätzlicher Scrubber entfernt E-Mail, Telefonnummer, Namen und Nachrichteninhalte vor dem Versand. • Tracking-Skripte (Google Analytics, Google Ads, Meta Pixel) werden erst nach ausdrücklicher Cookie-Einwilligung geladen. • Unser primärer SMS-Anbieter (SMSup) ist so konfiguriert, dass versandte Nachrichten auf seinen Servern nach spätestens 3 Tagen automatisch gelöscht werden. • Die AgendaPlus Bridge (lokale Praxis-Software-Anbindung) folgt demselben Prinzip: Die Daten werden direkt auf dem Praxis-Rechner gefiltert, übertragen werden nur die für die jeweilige Funktion erforderlichen Felder (z. B. Patienten-Nr. und Telefonnummer) — und nur auf ausdrückliche Aktion des Praxisteams. Ein Auslesen oder Kopieren des gesamten Praxis-Systems findet nicht statt (Verhältnismässigkeit, revDSG Art. 8). • Die Bridge-Zugangsdaten sind serverseitig auf eine minimale Liste von Endpunkten beschränkt (Scoped Token) — selbst ein kompromittiertes Bridge-Gerät hätte keinen Zugriff auf den übrigen Datenbestand.
10. Mandanten- und Umgebungstrennung
Daten verschiedener Kliniken werden innerhalb derselben Datenbank über eine strikte clinic_id-Trennung getrennt. Jede Abfrage auf Klinikdaten wird serverseitig auf die authentifizierte Klinik gefiltert. Zusätzlich greift eine automatische, fail-closed Absicherung: Wird ein Klinik-Filter versehentlich ausgelassen, liefert die Abfrage null Datensätze statt fremder Daten. Als dritte Ebene erzwingt die Datenbank selbst die Mandantentrennung (Postgres Row-Level Security auf allen klinik-eigenen Tabellen): Die Anwendung verbindet sich ohne Datenbank-Sonderrechte, und Zeilen einer fremden Klinik werden bereits auf Datenbankebene zurückgehalten — selbst eine fehlerhafte Abfrage der Anwendungsschicht (etwa der SQL-Injection-Klasse) könnte keine mandantenfremden Daten lesen. Ein clinic_admin einer Praxis kann technisch keine Daten einer anderen Praxis abrufen. Superadmin-Zugriffe auf Klinikdaten („Impersonation") werden im Audit-Log gesondert protokolliert. Produktion, Staging und Entwicklung laufen auf getrennten Umgebungen mit getrennten Datenbanken und getrennten Zugängen. Produktive Patientendaten werden nicht in Test- oder Staging-Umgebungen kopiert.
11. Sicherheits-Monitoring
Die Verfügbarkeit der Plattform wird rund um die Uhr durch einen unabhängigen externen Monitoring-Dienst (UptimeRobot) überwacht: Frontend (Website), Backend und der öffentliche API-Health-Endpunkt werden im 5-Minuten-Intervall geprüft; bei einem Ausfall wird der Betrieb sofort per E-Mail und Push-Benachrichtigung auf dem Mobiltelefon alarmiert. Die öffentliche Status-Seite nutzt denselben unabhängigen Dienst zusätzlich als Rückfall-Quelle — sie zeigt den Zustand der Plattform auch dann korrekt an, wenn das Backend selbst betroffen ist. Ein automatisierter Systembericht läuft täglich und meldet dem Betrieb den Zustand der Plattform: Verfügbarkeit der Dienste und der öffentlichen Endpunkte, Zustand aller Produktionskomponenten (inklusive unbemerkter Neustarts), Datenbank-Erreichbarkeit, Fehlerprotokolle der letzten 24 Stunden sowie fehlgeschlagene Nachrichtenzustellungen. Er ergänzt die ereignisgesteuerten Fehlerbenachrichtigungen um eine proaktive Kontrolle — auch stille Ausfälle, die keine Fehlermeldung erzeugen, werden so am nächsten Morgen sichtbar. Der Bericht enthält ausschliesslich Kennzahlen und um Personendaten bereinigte Protokollzeilen. Zusätzlich werden wöchentlich WAF-Security-Analytics, Request-Validation-Logs, Frontend-Firewall-Logs und Backend-Server-Logs auf Auffälligkeiten überprüft. Firewall-Allowlists und zulässige CDN-IP-Bereiche werden quartalsweise aktualisiert.
12. Reaktion auf Sicherheitsvorfälle
Bei einer bestätigten Datenschutzverletzung wird die betroffene Klinik unverzüglich — in der Regel innerhalb von 72 Stunden nach Kenntnisnahme — per E-Mail über die Art der Verletzung, betroffene Datenkategorien und ergriffene Massnahmen informiert (siehe DPA § 9). Die Meldepflicht der Klinik gegenüber dem EDÖB und den betroffenen Personen bleibt davon unberührt. AgendaPlus unterstützt die Klinik aktiv bei der Erfüllung dieser Pflichten.
13. Regelmässige Überprüfung
Sicherheitskontrollen werden im Rahmen der Weiterentwicklung der Plattform überprüft. Dependency-Scans auf bekannte Schwachstellen laufen automatisch; kritische Patches werden zeitnah eingespielt. Jede Code-Änderung durchläuft vor der Auslieferung ein gestuftes Test- und Sicherheits-Gate (automatisierte Test-Suite gegen eine isolierte Testdatenbank, statische Sicherheitsanalysen, bei sicherheitsrelevanten Änderungen zusätzliche Prüfungen in einer Staging-Umgebung). Neue Funktionen werden mit begleitenden Tests ausgeliefert. Externe Penetrationstests oder formelle Audits werden beauftragt, wenn dies durch Plattform-Skalierung oder konkrete Klinikanforderungen gerechtfertigt ist.
14. Datenportabilität und Vertragsende
Führendes System für die Patientendokumentation bleibt das Praxisverwaltungssystem (PMS) der Klinik: Sämtliche Patienten- und Termindaten stammen aus diesem System, AgendaPlus hält keine Patientendokumentation, über die die Klinik nicht bereits selbst verfügt. Eine Rückgabe der Daten bei Vertragsende ist deshalb nicht vorgesehen. Während der Vertragslaufzeit können Administratorinnen und Administratoren die zu einer Patientin/einem Patienten gespeicherten Daten jederzeit als maschinenlesbare Datei (JSON) aus dem Dashboard exportieren — etwa für Auskunfts- und Herausgabebegehren nach Art. 25/28 revDSG. Jeder Export wird im Audit-Log protokolliert. Nach Beendigung des Abonnements werden sämtliche personenbezogenen Daten der Klinik innerhalb von 30 Tagen unwiderruflich gelöscht — vorbehaltlich gesetzlicher Aufbewahrungspflichten (Einwilligungsnachweise: 3 Jahre, Audit-Logs: 12 Monate). Details regelt der Auftragsbearbeitungsvertrag unter /dpa, § 11.
15. OWASP ASVS v5 Level 1 — Selbst-Attestierung
AgendaPlus wird gegen den OWASP Application Security Verification Standard (ASVS) v5 Level 1 entwickelt — den offenen, international anerkannten Mindeststandard für Anwendungssicherheit. Aktueller Stand der Abdeckung (Selbst-Attestierung, geprüft 2026-07-28): • V6 Authentifizierung — vollständig erfüllt (verpflichtende 2FA; phishing-resistente Passkeys für privilegierte Konten) • V8 Autorisierung — vollständig erfüllt (dreistufige Mandantentrennung: Endpunkt-Filterung, automatischer fail-closed ORM-Guard, Postgres Row-Level Security auf Datenbankebene) • V9 Selbsterhaltende Tokens (Self-Contained Tokens) — vollständig erfüllt: jti, iat, verpflichtendes exp, fest vorgegebener Signaturalgorithmus (der Token bestimmt das Prüfverfahren nicht — „alg: none" und Algorithmus-Verwechslung sind dadurch ausgeschlossen), Token-Typ-Bindung (Personal / Superadmin / Bridge, letztere auf eine Endpunkt-Allowlist beschränkt), serverseitige Revocation-Liste, 10 h TTL • V11 Kryptografie — vollständig erfüllt (zusätzlich Feldverschlüsselung besonders schützenswerter Inhalte at rest, AES-256-GCM im Envelope-Verfahren; Schlüssel getrennt von der Datenbank) • V12 Kommunikation — vollständig erfüllt (HTTPS-only, HSTS-Preload, moderne TLS-Konfiguration) • V13 Konfiguration — vollständig erfüllt • V14 Datenschutz — vollständig erfüllt (keine personenbezogenen Daten in URLs; serverseitige Exchange-Code-Muster für sensible Übergaben) • V15 Sicheres Coding — vollständig erfüllt (Eingabesanitisation, keine XSS-Senken in der Public Surface; statisches XSS-Audit am 2026-05-27 ohne ausnutzbare Befunde) • V16 Logging & Monitoring — vollständig erfüllt (Audit-Log inkl. Lesezugriffen und Datenexporten, täglich in ein vom System getrenntes Archiv gespiegelt; Consent-Log; redigierte Logs) Eine Kontrolle ist als nicht anwendbar dokumentiert: V7 (Session Management) zielt auf cookie-basierte Sessions. AgendaPlus nutzt stattdessen das von ASVS v5 explizit anerkannte Self-Contained-Token-Muster (Kapitel V9). Diese architektonische Entscheidung ist intern in einem Risiko-Akzeptanz-Memo dokumentiert und wird quartalsweise überprüft. Letzter interner XSS-Audit: 2026-05-27 — keine ausnutzbaren Befunde. Letztes Pentest-Closure: 2026-05-26 (14 von 15 Befunden geschlossen, 1 dokumentierte Residual-Risiko). Externe formelle Verifikation kann bei konkretem Bedarf einer Klinik beauftragt werden.
Meldung von Sicherheitslücken (Responsible Disclosure)
Wir sind Sicherheitsforscherinnen und -forschern gegenüber aufgeschlossen. Wenn Sie eine potenzielle Schwachstelle gefunden haben: • Melden Sie sie bitte per E-Mail an — nicht öffentlich. • Beschreiben Sie Ursache, Schritte zur Reproduktion und — falls möglich — eine verantwortliche Minderung. • Nutzen Sie keine automatisierten Scans, die echte Patientendaten betreffen könnten, und unterlassen Sie das Exfiltrieren oder Modifizieren von Daten. • Wir reagieren in der Regel innerhalb von 5 Werktagen mit einer ersten Einschätzung. Eine maschinenlesbare Version dieser Richtlinie finden Sie unter /.well-known/security.txt (RFC 9116).
Fragen oder Meldung einer Sicherheitslücke: