Cloud-Prüfliste für Berufsgeheimnisträger

Sie haben bereits eine Anwendung oder einen Prototyp? Über die §203 Managed Cloud können Sie den technischen Scope unverbindlich einordnen lassen.

Eine Cloud-Prüfung für Berufsgeheimnisträger sollte nicht mit einer Providerliste beginnen, sondern mit der tatsächlichen Verarbeitung. Welche Information gelangt über welchen Nutzerweg in welche Komponente, wer kann darauf zugreifen und wie verlässt sie das System wieder? Erst wenn diese Fragen beantwortet sind, lassen sich Infrastruktur und Betriebsmodell sinnvoll auswählen.

Diese Prüfliste ist für technische und organisatorische Vorentscheidungen gedacht. Sie ersetzt keine rechtliche Bewertung des konkreten Einsatzes.

1. Zweck, Daten und Nutzer abgrenzen

Beschreiben Sie zuerst den fachlichen Einsatz in wenigen Sätzen:

• Welche Aufgabe löst die Anwendung?
• Welche Berufsgruppen und Mitarbeitenden nutzen sie?
• Welche Daten werden eingegeben, hochgeladen, erzeugt oder importiert?
• Sind Mandanten-, Patienten-, Gesundheits-, Steuer- oder Verfahrensdaten betroffen?
• Gibt es Daten, die trotz gleichem System nicht als Berufsgeheimnis behandelt werden müssen?
• Welche Ergebnisse werden exportiert, versendet oder in Drittsysteme geschrieben?

Die Antwort bestimmt die weitere Architektur. Eine Terminverwaltung ohne fachliche Inhalte, ein Dokumentenportal und eine KI-gestützte Aktenanalyse können für dieselbe Organisation völlig unterschiedliche Schutzbedarfe haben.

2. Die vollständige Systemgrenze zeichnen

Eine moderne Anwendung besteht selten nur aus Webserver und Datenbank. Erfassen Sie mindestens:

Markieren Sie für jede Verbindung, ob Inhaltsdaten, Metadaten, Zugangsdaten oder nur technische Zustandswerte übertragen werden. Auch Protokolle können Namen, E-Mail-Adressen, Dokumenttitel oder vollständige Requests enthalten.

3. Beteiligte Dienstleister und Personen erfassen

Die technische Architektur und die Dienstleisterkette müssen dasselbe Bild ergeben. Relevant sind nicht nur Rechnungssteller, sondern alle Parteien, die im vorgesehenen Betrieb mitwirken oder Zugriffsmöglichkeiten erhalten können.

Prüffragen:

• Wer stellt Infrastruktur, Plattform und Anwendung bereit?
• Wer übernimmt Administration, Support und Bereitschaft?
• Welche Unterauftragnehmer werden eingesetzt?
• Welche Personen oder Rollen können auf Produktion, Backups und Schlüssel zugreifen?
• Wie werden zusätzliche Mitwirkende eingebunden und Änderungen bekannt gegeben?
• Wie wird der Zugriff nach Rollenwechsel oder Vertragsende entzogen?

§ 203 Absatz 3 und 4 StGB sind für die Einbindung mitwirkender Personen zentral. Welche Vereinbarungen im Einzelfall notwendig sind, sollte rechtlich geprüft werden.

4. Administrative Zugriffe begrenzen

Ein Administrator benötigt nicht automatisch dauerhaften Zugang zu allen Daten. Ein geeignetes Modell trennt Rollen und Zugriffspfade:

• persönliche statt geteilter Administrationskonten
• MFA für Management-, Cloud- und Repository-Zugänge
• getrennte Rollen für Infrastruktur, Anwendung und Datenbank
• zeitlich oder anlassbezogen freigegebene Wartungszugriffe
• private Managementpfade statt öffentlich erreichbarer Oberflächen
• Protokollierung sicherheitsrelevanter Änderungen
• kontrollierter Umgang mit Break-Glass-Zugängen

Ob und wie Sitzungen aufgezeichnet werden dürfen, ist gesondert zu bewerten. Auditierbarkeit darf nicht durch unnötige Inhaltsprotokollierung neue Risiken schaffen.

5. Anwendung und Software-Lieferkette prüfen

Der Server kann sauber konfiguriert sein, während die Anwendung selbst ungeklärte Abhängigkeiten enthält. Vor dem Go-live gehören deshalb in die Prüfung:

• Repository, Eigentum und reproduzierbarer Build
• verwendete Pakete, Container und Images
• bekannte Schwachstellen und Updateweg
• Secrets in Code, Build-Logs oder Frontend-Bundles
• Telemetrie, Analytics und Fehlertracking
• externe Skripte, Fonts, CDNs und APIs
• Rollen- und Berechtigungsmodell der Anwendung
• Mandantentrennung und Zugriffstests

Bei KI-generierter Software ist diese Prüfung besonders wichtig, weil ein funktionierender Prototyp noch keine Aussage über Security, Datenmodell oder Wartbarkeit trifft. Mehr dazu im Leitfaden KI-generierte Software betreiben.

6. Backup und Wiederherstellung als eigene Datenwege behandeln

Backups sind keine rein technische Nebensache. Sie vervielfältigen den Datenbestand und verlängern dessen Lebensdauer. Die Prüfliste sollte daher festhalten:

• welche Komponenten gesichert werden
• wo primäre und zusätzliche Kopien liegen
• wie Daten vor unbefugter Veränderung oder Löschung geschützt werden
• wer Schlüssel und Wiederherstellungszugänge kontrolliert
• welche Aufbewahrungs- und Löschfristen gelten
• wie oft Restore-Tests stattfinden
• wie ein vollständiger Wiederanlauf dokumentiert wird

Eine erfolgreiche Sicherung ist noch kein nachgewiesener Restore. Datenbank, Dateien, Secrets und Anwendungsversion müssen gemeinsam wiederherstellbar sein.

7. Betrieb und Änderungen festlegen

Der produktive Zustand bleibt nicht stehen. Klären Sie vorab:

• Wer bewertet und installiert Sicherheitsupdates?
• Wie werden Änderungen getestet und freigegeben?
• Welche Ereignisse lösen einen Alarm aus?
• Wer reagiert innerhalb welcher Zeiten?
• Wie werden Incidents dokumentiert und kommuniziert?
• Welche Abhängigkeiten werden regelmäßig überprüft?
• Wie sieht der Exit bei Dienstleister- oder Plattformwechsel aus?

Die Maßnahmen müssen zur Kritikalität passen. Ein internes Werkzeug mit planbaren Wartungsfenstern benötigt ein anderes Service Level als ein dauerhaft verfügbares Mandantenportal.

8. Ergebnis als Entscheidungsblatt festhalten

Am Ende sollte kein unscharfes Etikett wie „deutsche Cloud“ stehen, sondern ein nachvollziehbares Zielbild:

1. Anwendung und zulässige Datenarten
2. System- und Datenflussdiagramm
3. beteiligte Dienstleister und Rollen
4. Betriebsorte und externe Verbindungen
5. administrative Zugriffspfade
6. Backup-, Restore- und Löschkonzept
7. Update-, Monitoring- und Incident-Prozess
8. offene rechtliche und technische Entscheidungen

Dieses Blatt eignet sich als Grundlage für die interne Freigabe, eine externe rechtliche Prüfung und ein konkretes technisches Angebot.

Passende WZ-IT-Angebote

• Die §203 Managed Cloud verbindet isolierte Infrastruktur, deutsche Anbieter, die vereinbarte §203-Vertragskette und Managed- oder Co-Managed-Betrieb.
• Der AI Code & Production Readiness Audit prüft eine bestehende oder KI-generierte Anwendung vor Go-live, Migration oder Betriebsübernahme.
• Managed Open Source deckt Auswahl, Installation, Integration und laufenden Betrieb von Open-Source-Anwendungen auch unabhängig von §203 ab.

Quellen

• § 203 StGB - Verletzung von Privatgeheimnissen
• DSGVO Artikel 28 - Auftragsverarbeiter
• DSGVO Artikel 32 - Sicherheit der Verarbeitung
• BSI IT-Grundschutz-Baustein OPS.2.2 Cloud-Nutzung