Orthanc führt keinen Zugriffsnachweis - was das für DSGVO und KRITIS heißt
Ein Verdacht steht im Raum: Jemand aus dem Haus hat sich die Aufnahmen einer prominenten Patientin angesehen, ohne an ihrer Behandlung beteiligt zu sein. Die Frage der Geschäftsführung an die IT ist einfach. Wer hat wann auf diese Studie zugegriffen?
Wenn die Bilder in einem Orthanc-Archiv liegen, lautet die ehrliche Antwort: Das lässt sich aus Orthanc nicht beantworten. Nicht, weil die Logs falsch konfiguriert wären, sondern weil Orthanc diese Information bei keiner Einstellung erfasst.
Was wir gemessen haben
Wir haben das gegen eine echte Instanz geprüft, nicht gegen die Dokumentation: Der Container wurde gestoppt und mit derselben Datenbank und demselben Storage vorübergehend neu gestartet, um die Log-Stufe frei zu variieren, danach zurückgetauscht.
Mit Standard-Verbosity erzeugen Anfragen gegen
/system,
/patients oder
/studies keine
einzige Log-Zeile - authentifiziert wie unauthentifiziert. Nur Start- und
Stop-Meldungen.
Mit --verbose
sieht ein protokollierter Zugriff vollständig so aus:
I0823 05:28:40.037495 HTTP-1 ElapsedTimer.cpp:102] (http) GET /patients
I0823 05:28:40.043815 HTTP-1 ElapsedTimer.cpp:107] (http) GET /patients (elapsed: 6324 us)Methode, Pfad, Timing. Kein Benutzername, keine IP-Adresse, keine Authentifizierungsinformation - und zwar identisch, unabhängig davon, ob die Anfrage mit korrekten Zugangsdaten, mit falschen oder ganz ohne kam.
Eine Falle am Rande, die Zeit kosten kann: Die JSON-Konfigurationsschlüssel
Verbose und
HttpVerbose
existieren nicht und werden von Orthanc stillschweigend ignoriert. Wer sie in die
Konfiguration schreibt, bekommt keine Fehlermeldung - und auch keine ausführlicheren
Logs.
Das ist kein Defekt, sondern eine Eigenschaft
Orthanc ist ein DICOM-Server, kein Auditsystem, und gibt auch nicht vor, eines zu sein. Die Zuordnung eines Zugriffs zu einer Person gehört üblicherweise in die Anwendungsschicht darüber - in das RIS, den Viewer, das KIS. Das ist eine vertretbare Arbeitsteilung.
Der Haken liegt darin, wie diese Schicht in der Praxis angebunden ist. Sitzt ein RIS mit eigener Nutzerverwaltung vor Orthanc und spricht über einen einzigen, gemeinsamen Service-Account mit ihm - ein völlig normales Integrationsmuster -, dann erreicht die Identität der Person, die den Befund tatsächlich geöffnet hat, Orthanc nie. Aus Orthancs Sicht war es immer derselbe Zugriff.
Daraus folgt eine Konsequenz, die oft übersehen wird: Nachträgliches Log-Shipping repariert das nicht. Logs nach Loki, Elasticsearch oder ein SIEM zu schaufeln, macht vorhandene Zeilen auffindbar. Es holt keine Identität zurück, die nie protokolliert wurde. Wer die Lücke schließen will, braucht entweder einen vorgeschalteten Reverse-Proxy, der die Authentifizierung selbst durchführt und protokolliert, oder ein echtes Audit-Log über Orthancs Plugin-Schnittstelle - und selbst der Proxy hilft nicht gegen das Service-Account-Problem eine Ebene höher.
Was die DSGVO an dieser Stelle verlangt
Zuerst die Trennung, die diesen Abschnitt trägt: Die DSGVO schreibt nirgends wörtlich vor, dass ein Bildarchiv ein Zugriffsprotokoll führen muss. Was sie vorschreibt, sind Pflichten, die sich ohne ein solches Protokoll schwer erfüllen lassen.
Drei davon werden hier konkret:
| Norm | Was dort steht | Wo es hier klemmt |
|---|---|---|
| Art. 5 Abs. 2 | Rechenschaftspflicht: der Verantwortliche „muss dessen Einhaltung nachweisen können" | Nachweisen, dass nur Befugte zugegriffen haben, ohne zu wissen, wer zugegriffen hat |
| Art. 5 Abs. 1 lit. f | Integrität und Vertraulichkeit, Schutz vor „unbefugter oder unrechtmäßiger Verarbeitung" | Unbefugte Verarbeitung bleibt unbemerkt, wenn sie technisch aussieht wie befugte |
| Art. 33 Abs. 3 lit. a | Die Meldung nennt „soweit möglich" Kategorien und ungefähre Zahl der betroffenen Personen | Der Umfang eines Vorfalls ist nicht bestimmbar - die 72-Stunden-Frist läuft trotzdem |
Der dritte Punkt ist aus unserer Sicht der schärfste. Nach einem Vorfall ist nicht die Frage, ob etwas passiert ist, sondern wie viel. Ohne Zugriffsprotokoll bleibt nur der Rückschluss vom gesamten Datenbestand: Wer nicht eingrenzen kann, welche Datensätze berührt wurden, muss im Zweifel vom größtmöglichen Umfang ausgehen. Aus einem eng begrenzten Vorfall wird so eine Meldung über den gesamten Bestand - und gegebenenfalls eine Benachrichtigung aller betroffenen Personen nach Art. 34.
Quelle: Verordnung (EU) 2016/679 (DSGVO), Art. 5, 33 und 34. Abgerufen am 21. September 2026 unter eur-lex.europa.eu.
Was KRITIS verlangt - und was sich 2025 daran geändert hat
Hier zuerst ein Hinweis, der viele ältere Fundstellen im Netz betrifft, unsere eigenen internen Notizen zu diesem Thema eingeschlossen: Die Systematik rund um § 8a BSIG gilt nicht mehr. Das NIS-2-Umsetzungsgesetz ist am 6. Dezember 2025 ohne Übergangsfrist in Kraft getreten und hat das BSI-Gesetz neu gefasst. Wer heute noch gegen „§ 8a" und einen Zweijahresrhythmus plant, plant gegen aufgehobenes Recht.
Betroffen sind Krankenhäuser, die den Schwellenwert der BSI-Kritisverordnung erreichen - für die stationäre medizinische Versorgung sind das 30.000 vollstationäre Fälle im Jahr. Betreiber kritischer Anlagen gelten dabei stets als besonders wichtige Einrichtungen und tragen damit den vollen Pflichtenkatalog.
| Norm | Pflicht | Frist / Turnus |
|---|---|---|
| § 30 Abs. 2 Nr. 9 | Konzepte für Personalsicherheit, Zugriffskontrolle und Anlagenverwaltung | laufend |
| § 39 | Nachweis der Umsetzung gegenüber dem BSI, per Sicherheitsaudit, Prüfung oder Zertifizierung | alle drei Jahre |
| § 32 | Meldung erheblicher Sicherheitsvorfälle an das BSI | 24 h Erstmeldung, 72 h Folgemeldung, 1 Monat Abschlussmeldung |
Und jetzt der Teil, den wir bewusst nicht zuspitzen: § 30 Abs. 2 Nr. 9 nennt Zugriffskontrolle, nicht Protokollierung. Das Gesetz verlangt an dieser Stelle also wörtlich kein Audit-Log. Wer etwas anderes behauptet, liest mehr in den Text hinein, als darin steht.
Wirksam wird die Lücke eine Ebene weiter, bei § 39: Nachgewiesen wird nicht die Absicht, sondern die Umsetzung, und zwar durch ein Audit. Eine Zugriffskontrolle, deren Wirksamkeit sich nicht belegen lässt, weil niemand protokolliert, ob sie greift, ist ein Konzept ohne Nachweis. Ob ein Prüfer das beanstandet, entscheidet der Prüfer - aber es ist absehbar die Frage, die er stellt.
Quelle: BSI-Gesetz in der Fassung des NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes, in Kraft seit 6. Dezember 2025, §§ 30, 32 und 39. Abgerufen am 21. September 2026 unter gesetze-im-internet.de. Schwellenwert nach BSI-Kritisverordnung, Anhang 5.
Eine Verwechslung, die uns selbst passiert ist
Fast jedes Open-Source-Projekt und jeder Hersteller hat heute eine
SECURITY.md mit
einer Kontaktadresse für Sicherheitsmeldungen. Wir auch. In einem internen Gespräch
ist uns genau das durcheinandergeraten, deshalb steht es hier: Diese Adresse
hat mit Ihrer KRITIS-Meldepflicht nichts zu tun.
Die beiden Wege laufen in entgegengesetzte Richtungen. Die Sicherheitsadresse eines Herstellers ist der Weg zu ihm: Ein Forscher oder Anwender meldet eine Schwachstelle im Produkt. Die Meldepflicht nach § 32 BSIG läuft von Ihnen als Betreiber an das BSI, über dessen eigenes Meldeportal, innerhalb von 24 Stunden. Ihren Lieferanten zu informieren ist sinnvoll und oft vertraglich geschuldet - es erfüllt Ihre gesetzliche Meldepflicht nicht und lässt die Frist weiterlaufen.
Was Sie prüfen sollten
Der Befund oben gilt für Orthanc, aber die Prüfung gilt für jedes Bildarchiv und jedes Subsystem, das Patientendaten hält. Drei Fragen, die sich an einem Nachmittag beantworten lassen:
- Führt die Schicht, die Ihre Nutzer authentifiziert, überhaupt ein Zugriffsprotokoll? Nicht ein Fehlerprotokoll, nicht ein Anmeldeprotokoll - ein Protokoll darüber, wer welchen Datensatz geöffnet hat. Lassen Sie es sich zeigen, statt es sich zusichern zu lassen.
- Steht darin die Person oder ein Service-Account? Das ist die Frage, an der die meisten Ketten reißen. Öffnen Sie testweise einen Datensatz mit einem benannten Benutzerkonto und sehen Sie nach, welcher Name im Protokoll des dahinterliegenden Systems landet.
- Wie weit reicht die Aufbewahrung zurück? Ein Zugriffsprotokoll, das nach sieben oder dreißig Tagen rotiert, hilft bei einem Vorfall nicht, der ein Vierteljahr zurückliegt. Die Aufbewahrungsdauer ist dabei selbst abwägungsbedürftig - ein Zugriffsprotokoll ist seinerseits eine Verarbeitung personenbezogener Daten Ihrer Beschäftigten.
Wenn eine dieser Fragen keine belegbare Antwort hat, ist das kein Grund zur Panik. Es ist ein Punkt für die Risikoanalyse, der dort besser aufgehoben ist als in einem Auditbericht oder in einer Meldung unter Zeitdruck.
Wie wir selbst damit umgegangen sind
Dieser Befund ist bei uns nicht theoretisch entstanden. Orthanc war fünf Tage lang Bestandteil von Linumed Base, und diese Messung war einer der Gründe, es wieder zu entfernen statt den fehlenden Zugriffsnachweis selbst nachzubauen. Die vollständige Geschichte inklusive der verworfenen Alternativen steht in unserem Post-mortem und, mit allen Messwerten, in ADR 0011. Wer Orthanc trotzdem betreiben möchte - eine völlig legitime Entscheidung -, findet unsere Empfehlungen dazu in docs/operations/orthanc-recommendation.md.
Die Messungen in diesem Beitrag stammen vom 23. August 2026 und beziehen sich auf die zu diesem Zeitpunkt eingesetzte Orthanc-Version. Ob eine spätere Version das Verhalten ändert, prüfen Sie bitte gegen Ihre eigene Instanz - so, wie wir es oben beschrieben haben.