Compliance as Code: Wie ich die KBV-IT-Sicherheit einer Praxis nachts automatisch prüfe

Vor ein paar Monaten habe ich für eine Praxis-Gründung eine über 70-seitige IT-Sicherheitsdokumentation nach der KBV-Richtlinie gebaut. Schön versioniert in Git, drei PDF-Varianten, barrierefrei, das volle Programm.

Und dann ist mir abends auf der Couch was aufgefallen, das mir die ganze Arbeit ein bisschen vermiest hat: Ein PDF in einem Git-Repo ist immer noch nur ein PDF.

Das Problem mit Dokumentation: Sie wird sofort alt

Ein Sicherheitsdokument beschreibt einen Soll-Zustand. „Alle Geräte sind verschlüsselt.” „Backups laufen täglich.” „Das Zertifikat ist gültig.” Klingt gut. Aber die Realität driftet ab dem Moment, in dem du auf Speichern drückst.

Ein neues iPad kommt in die Praxis und niemand denkt an die Verschlüsselung. Ein Backup läuft drei Wochen lang ins Leere, weil das NAS nach einem Update offline ist. Ein Zertifikat läuft ab und keiner merkt’s, bis die Patienten eine Warnung im Browser sehen.

Mein schönes PDF behauptet die ganze Zeit fröhlich, alles sei in Ordnung. Genau diese Lücke zwischen aufgeschrieben und tatsächlich so ist das, was bei einem Audit weh tut – und schlimmer noch, was echte Sicherheit kostet.

Ein Compliance-Dokument, das niemand gegen die Realität prüft, ist eine Behauptung. Mehr nicht.

Also habe ich weitergemacht. Und vermutlich wieder over-engineered – aber diesmal mit gutem Gewissen.

Die Idee: Die Realität soll sich bei mir melden, nicht umgekehrt

Der Plan war simpel. Statt einmal im Jahr panisch alles zu kontrollieren, soll ein kleiner Roboter jede Nacht nachschauen, ob die Praxis-IT noch so aussieht, wie ich sie aufgeschrieben habe. Und wenn nicht, soll er sich bei mir melden – nicht ich bei ihm.

Die Doku liegt eh schon als Code in Git. Warum dann nicht auch die Prüfung?

Der nächtliche Robo-Auditor

Das Herzstück ist ein GitHub-Actions-Workflow, der um drei Uhr morgens loslegt, wenn niemand arbeitet:

name: Nightly Compliance Check
on:
  schedule:
    - cron: '0 3 * * *'   # der digitale Nachtwächter

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - name: Geräte-Compliance aus dem MDM lesen (Verschlüsselung, OS, Sperre)
        run: python scripts/check_devices.py

      - name: Domain & Mail prüfen (TLS, DMARC/SPF/DKIM)
        run: python scripts/check_domain.py

      - name: Backups prüfen (Alter, Konsistenz, Restore-Test)
        run: python scripts/check_backups.py

Jeder Lauf schreibt einen kleinen Report ins Repo. Das Schöne daran: Git führt damit ganz nebenbei ein manipulationssicheres Logbuch. Jeder Check, jede Abweichung, jeder Zeitstempel ist nachvollziehbar. Wenn ein Prüfer fragt „Woher wissen Sie, dass das im März lief?”, drücke ich keinen Knopf und hoffe – ich zeige die Git-History.

Was da nachts wirklich geprüft wird

Die spannende Frage ist natürlich nicht das wie, sondern das was. Drei Bereiche, und bei jedem habe ich aus Erfahrung gelernt, was tatsächlich schiefgeht:

Geräte. Die Praxis hat ein MDM für Macs und mobile Geräte, und das ist der ehrlichste Weg: Das MDM kennt den Compliance-Status jedes verwalteten Geräts, also frage ich nicht jedes Gerät einzeln ab, sondern lese die MDM-Daten aus. Ist FileVault auf den Macs aktiv und der Wiederherstellungsschlüssel sicher hinterlegt? Haben die iPads einen Code gesetzt, der die hardwareseitige Data Protection scharf schaltet? Läuft überall das aktuelle OS oder hängt da noch ein iPad zwei Versionen hinterher? Ist die automatische Bildschirmsperre aktiv? Und – fast am wichtigsten – taucht nur Hardware auf, die ich kenne? Das unscheinbarste Risiko ist das Privat-Tablet, das „nur kurz” mitbenutzt wird.

Domain und E-Mail. Läuft das TLS-Zertifikat bald ab? Sind DMARC, SPF und DKIM noch sauber gesetzt, damit niemand im Namen der Praxis Phishing-Mails verschickt? E-Mail-Spoofing ist im Gesundheitswesen ein echtes Thema, und der Check kostet mich praktisch nichts.

Backups. Ist das letzte TimeMachine-Backup jünger als 24 Stunden? Ist es verschlüsselt? Ist das NAS überhaupt erreichbar? „Wir machen Backups” ist der Satz, den ich am häufigsten höre und am seltensten verifiziert sehe.

Der Paranoid Mode

Hier wird’s dann ehrlich gesagt ein bisschen übertrieben – aber die Bausteine kosten kaum etwas und schlafen ruhiger lässt es mich allemal.

Have I Been Pwned. Einmal pro Woche fragt ein Skript die HIBP-API ab, ob eine Praxis-Adresse in einem neuen Datenleck aufgetaucht ist. Dann weiß ich es, bevor es jemand anders ausnutzt.

Canary Tokens. Das sind digitale Stolperdrähte – unscheinbare Dateien mit Namen wie Patientenliste_2026.xlsx, die nirgends verlinkt sind und die niemand öffnen sollte. Wenn doch jemand draufklickt, bekomme ich sofort eine Nachricht. Ein Angreifer, der sich durchs Netz wühlt, verrät sich damit selbst.

Backup-Restore-Test. Ein Backup, das man nie zurückgespielt hat, ist ein Glaubensbekenntnis, kein Backup. Also stellt ein Skript regelmäßig zufällige Dateien wieder her und vergleicht die Hashes. Die DSGVO will diese Wiederherstellbarkeit ohnehin – jetzt passiert sie von allein.

Website-Integrität. Ein täglicher Check, ob die Praxis-Website noch so konfiguriert ist, wie ich sie eingerichtet habe. Security-Header, Weiterleitungen, Inhalte. Wenn sich etwas ändert, das ich nicht geändert habe, erfahre ich es sofort.

Was ich bewusst nicht automatisiere

Damit das hier nicht nach Hochglanzbroschüre klingt: Vieles geht eben nicht per Skript. Ob Mitarbeitende ihren Bildschirm beim Rausgehen wirklich sperren, ob die Schulung verstanden wurde, ob jemand im Stress doch den verdächtigen Anhang öffnet – das bekomme ich mit keinem Cronjob in den Griff. Der Mensch bleibt die spannendste Schwachstelle, und kein Dashboard der Welt ersetzt eine Praxis, die Sicherheit ernst nimmt.

Und ja: Das ganze Setup einmal aufzubauen war mehr Arbeit als ein Word-Dokument zu tippen. Deutlich mehr. Wer eine einzelne Praxis absichern will und nie wieder etwas damit zu tun haben möchte, ist mit dem Papierordner vielleicht schneller fertig.

Lohnt sich das?

Für mich: ja. Aber aus einem Grund, den ich vorher unterschätzt habe.

Es geht nicht um den Audit. Es geht darum, dass die Maßnahmen tatsächlich gelebt werden, ohne dass jemand jeden Morgen dran denken muss. Ein abgelaufenes Zertifikat, ein totes Backup, ein fremdes Gerät im Netz – das sind keine Audit-Probleme, das sind echte Risiken für echte Patientendaten. Und die fallen jetzt auf, während sie noch klein sind.

Es ist ein bisschen wie bei meiner Telenot-Bridge: Wenn man Technik einmal richtig einsetzt, wird aus einer lästigen Pflicht etwas, das einfach im Hintergrund läuft und funktioniert.

Die Vorlage, auf der das alles aufsetzt, gibt’s übrigens kostenlos auf GitHub – sie ist der Startpunkt, der Robo-Auditor ist die Kür.

Die Automatisierung baue ich gerade weiter aus. Wer das spannend findet, eigene Ideen hat oder mir sagen will, wo ich over-engineered habe: LinkedIn oder E-Mail.

Häufige Fragen

Was bedeutet Continuous Compliance?

Continuous Compliance heißt, dass Sicherheits- und Compliance-Anforderungen nicht einmalig dokumentiert, sondern laufend automatisiert überprüft werden. Statt eines statischen PDFs prüfen Skripte regelmäßig, ob die Realität noch der Dokumentation entspricht – etwa Verschlüsselung, Backups oder Zertifikate.

Kann man die KBV IT-Sicherheitsrichtlinie automatisieren?

Die Dokumentation selbst bleibt Pflicht, aber die Überwachung der Maßnahmen lässt sich weitgehend automatisieren. Mit Skripten und einem Scheduler (z.B. GitHub Actions) lassen sich Geräteverschlüsselung, Backup-Status, Zertifikate und E-Mail-Sicherheit täglich prüfen und revisionssicher protokollieren.

Welche Werkzeuge braucht man für automatisierte Praxis-IT-Sicherheit?

Ein Git-Repository für die Dokumentation und Logs, einen Scheduler wie GitHub Actions oder einen Cronjob, ein paar Python-Skripte für die Checks sowie optional ein MDM für die Geräte. Für die Früherkennung helfen Dienste wie Have I Been Pwned und Canary Tokens.