Sicherheit ist ein Lebenszyklus.

1 Sicherheitsziele

2 Architektur und Systemtrennung

Die öffentliche Website bleibt vom sensiblen Produktivstack getrennt. Webportal und API werden über definierte HTTPS-Endpunkte bereitgestellt; Datenbank und interne Dienste sind nicht allgemein aus dem Internet erreichbar. Produktiv-, Test- und Entwicklungsumgebungen werden getrennt behandelt.

Family-, ClubSport- und Institutionsfreigaben werden serverseitig als eigene Berechtigungsobjekte behandelt. Eine übermittelte user_id, device_id oder andere Objekt-ID ist kein Berechtigungsnachweis.

3 Identitäten und privilegierte Zugriffe

Privatkonten verwenden E-Mail-Verifikation als Standard. Für Fleeny-Administratoren, Mitarbeitende mit privilegierten Rechten und institutionelle Administrationsrollen ist starke Mehrfaktor-Authentifizierung vorgesehen, bevorzugt Passkeys oder Authenticator/TOTP. SMS dient höchstens als Fallback oder Recovery.

• individuelle statt geteilter Admin-Konten;
• Least Privilege und zeitlich begrenzte privilegierte Rechte;
• Joiner-Mover-Leaver-Prozess für Eintritt, Rollenwechsel und Austritt;
• risikogerechte Identitätsprüfung bei Recovery, E-Mail-/2FA-Änderungen und sensiblen Freigaben;
• private Mobilnummern von Mitarbeitenden sind keine Voraussetzung für Care-/Spitalrollen.

4 Verschlüsselung und Secrets

App, Webportal, APIs und Administration verwenden verschlüsselte Übertragung. Fleeny vermeidet eigene Kryptografie und setzt etablierte Verfahren und Bibliotheken ein. Secrets gehören nicht in Quellcode, mobile Apps, Container-Images, Tickets oder öffentliche Repositories und werden getrennt verwaltet und bei relevantem Risiko rotiert.

5 Web-, API- und iOS-Sicherheit

Web- und API-Sicherheit orientiert sich an etablierten OWASP-Anforderungen; die mobile App wird mit eigenen Mobile-Security-Anforderungen geprüft. Besondere Aufmerksamkeit erhalten Authentifizierung, Sitzungen, Objekt-/Mandantenautorisierung, Eingabevalidierung, Rate Limiting, Resource Consumption, sichere Fehlermeldungen und Dritt-API-Nutzung.

6 Band, BLE, Firmware und Home Hub

• Jedes Band erhält eine eindeutige technische Identität; eine Seriennummer allein ist kein Authentisierungsnachweis.
• Pairing wird aktiv durch eine berechtigte Person gestartet.
• Geräteindividuelle Schlüssel/Tokens werden gegenüber serienweit identischen Secrets bevorzugt.
• Nicht benötigte BLE-Services und Debug-/Herstellerschnittstellen werden in Serienumgebungen deaktiviert oder besonders geschützt.
• Firmware-Updates werden versioniert, autorisiert und mit Rollback-/Recovery-Überlegungen behandelt.
• Ein Home Hub wird genau einem Band beziehungsweise einer verwalteten Person zugewiesen und routet nur dieses Band.

7 Datenbank, Logs und Mandantentrennung

Gesundheitsdaten werden nicht unnötig in Logs kopiert. Datenbankzugriffe erfolgen nur aus definierten Diensten oder kontrollierten Administrationswegen. Rollen, Organisation, Person, Band/Hub und Datenkategorie werden serverseitig geprüft. Institutionelle Mandantentrennung wird als eigener Schutzbereich behandelt.

8 Schwachstellen, Patches und Dependencies

Server, Container, Apps, Firmware, Libraries und Build-Abhängigkeiten werden inventarisiert und risikobasiert auf bekannte Schwachstellen geprüft. Kritische Befunde können Releases blockieren. Ausnahmen benötigen Owner, Risiko, Frist und kompensierende Massnahmen.

9 Backup, Restore und Resilienz

Backups werden getrennt und geschützt geführt. Restore-Prozesse werden getestet; Wiederherstellung ist nicht mit dem blossen Vorhandensein eines Backups gleichzusetzen. Kapazität, Monitoring, Wiederanlauf und Abhängigkeiten von Strom, Netzwerk, App Store, Push und Drittanbietern werden in der Betriebsplanung berücksichtigt.

10 Incident Response

1. Incident erkennen und eindeutig erfassen.
2. Schweregrad, Scope sowie Daten- und Personenauswirkung bewerten.
3. Konten, Tokens, Schlüssel oder Dienste soweit nötig eindämmen.
4. Beweise sichern, ohne unnötige Gesundheitskopien zu erzeugen.
5. Ursache beheben und sichere Wiederherstellung durchführen.
6. Privacy/Legal bewertet Melde- und Informationspflichten.
7. Betroffene Nutzer/Institutionen erhalten abgestimmte Informationen.
8. Root Cause, Lessons Learned und Verbesserungsmassnahmen werden dokumentiert.

11 Secure Development und Release Gate

Neue Funktionen beginnen mit Schutzbedarf und Threat Model. Code Review, Branch Protection, Dependency-/Secret-/Container-Scans, getrennte Testumgebungen, Migrations-/Rollbackplan sowie versionsbezogene Release-Nachweise gehören zum Zielprozess. Gesundheitsdaten, neue Rollen, Geräte-/Hub-Funktionen und neue Claims lösen zusätzliche Privacy-/Security-/Compliance-Prüfungen aus.

12 Professionelle Nutzung

Professionelle Nutzung erfordert mehr als ein Privatkonto. Vor Freigabe eines institutionellen Modus werden Mandantentrennung, Organisationsrollen, Audit, Admin-MFA, Alarm-/Eskalationsprozesse, Supportbereitschaft, Verfügbarkeit und regulatorische Einordnung separat geprüft.