Wenn Atlassian Data Center angegriffen wird: Der Notfallplan für Arztpraxen
Inhaltsverzeichnis
Veröffentlicht: 07. Oktober 2026 · Lesezeit: ca. 17 Minuten
Rund 4.000 Confluence-Instanzen weltweit waren Anfang 2024 öffentlich exponiert und angreifbar – ohne dass ihre Betreiber es wussten. Diese Zahl, ermittelt von Greenbone im Februar 2024, klingt abstrakt. Sie wird konkret, sobald man bedenkt: Wer Confluence oder Jira in einer Arztpraxis oder einem MVZ betreibt und dabei auf Self-Hosted Data Center setzt, trägt die Patch-Verantwortung vollständig selbst. Atlassian schiebt keine Updates automatisch ein – anders als bei der Cloud-Variante. Und während im Hintergrund eine Sicherheitslücke offen steht, läuft die Sprechstunde weiter, werden Befunde dokumentiert, eArztbriefe versendet, ePA-Einträge vorgenommen. Der Moment, in dem jemand diese Lücke aktiv ausnutzt, kommt selten dann, wenn die IT-Betreuung gerade erreichbar ist.
Die Atlassian Sicherheitslücke Incident Response ist für Arztpraxen kein theoretisches IT-Thema – sie ist eine operative Frage: Was passiert mit dem Praxisverwaltungssystem, mit dem KIM-Dienst, mit der Telematikinfrastruktur, wenn ein Angreifer über eine bekannte Schwachstelle ins Netz eindringt? CVE-2023-22515 erhielt einen CVSS-Score von 10.0 und wurde aktiv von der APT-Gruppe Storm-0062 ausgenutzt, bevor ein Patch verfügbar war. Das BSI stufte die Lage als maximal kritisch ein.
Für Arztpraxen kommt erschwerend hinzu, dass Patientendaten nach Art. 9 DSGVO als besondere Kategorie personenbezogener Daten gelten – ein Datenleck ist damit kein bloßer Compliance-Verstoß, sondern ein meldepflichtiges Ereignis mit unmittelbaren Konsequenzen. Die KBV-IT-Sicherheitsrichtlinie nach § 75b SGB V macht klare Vorgaben, die im Ernstfall dokumentiert und eingehalten sein müssen.
Dieser Artikel gibt Ihnen eine strukturierte Checkliste an die Hand: Was müssen Sie organisatorisch und technisch vorbereitet haben, bevor ein Angriff passiert? Was tun Sie in den ersten 60 Minuten, wenn er passiert? Und wo liegen die typischen Stolperfallen, die selbst gut aufgestellte Praxen zu spät erkennen?
| Kennzahl | Wert | Quelle |
|---|---|---|
| CVSS-Score CVE-2023-22515 (Confluence) | 10,0 – maximal kritisch; aktive Ausnutzung durch APT Storm-0062 bereits vor Patch-Verfügbarkeit | BSI Cybersicherheitswarnung 2023 |
| Exponierte Confluence-Instanzen weltweit (Feb. 2024) | ca. 4.000 öffentlich angreifbar | Greenbone / CISA 2024 |
| Neue Sicherheitslücken täglich (Jahr 2023) | Ø 78 pro Tag – ca. 14 % mehr als im Vorjahr | BSI Lagebericht 2024 |
| Deutsche KMU bereits Opfer eines Cyberangriffs | 53 % (Erhebung HDI Cyberstudie 2024) | BSI Cybersicherheitslage |
Was wirklich auf dem Spiel steht – bevor Sie die Checkliste öffnen
Viele Praxen betreiben Atlassian-Tools – Confluence für interne Dokumentation, Jira für Aufgabenverwaltung – ohne zu wissen, ob ihre Instanz auf einem aktuellen Stand ist. Das ist kein Vorwurf, sondern eine strukturelle Realität: Wer täglich Sprechstunden abhält, Befunde auswertet und Überweisungen koordiniert, hat selten Zeit für eine systematische Schwachstellen-Überwachung. Und genau das wissen Angreifer.
Was bei einem erfolgreichen Angriff auf Atlassian Data Center in einer Arztpraxis auf dem Spiel steht, geht weit über den Ausfall eines Tools hinaus. Confluence-Instanzen enthalten oft interne Behandlungsstandards, Zugangsdaten zu weiteren Systemen, Netzwerkpläne oder – in schlecht konfigurierten Umgebungen – direkte Verknüpfungen zum Praxisverwaltungssystem. Ein Angreifer, der sich dort festsetzt, kann sich lateral durch das Netz bewegen: hin zum PVS, zur Telematikinfrastruktur, zum KIM-Dienst.
Patientendaten als besonders schützenswerte Kategorie nach Art. 9 DSGVO machen jeden Vorfall meldepflichtig – gegenüber der zuständigen Datenschutzbehörde, in der Regel innerhalb von 72 Stunden. Die KBV-IT-Sicherheitsrichtlinie (§ 75b SGB V) verpflichtet Vertragsärzte zusätzlich zu einem dokumentierten Sicherheitskonzept. Wer im Ernstfall beides nicht vorzeigen kann, riskiert nicht nur Bußgelder, sondern auch den Entzug der TI-Zulassung.
Die Atlassian Sicherheitslücke Incident Response ist deshalb für Arztpraxen keine IT-Aufgabe zweiter Ordnung – sie berührt den Kern des Praxisbetriebs. Als ISO/IEC 27001 zertifiziertes IT-Systemhaus – TTG GmbH erleben wir regelmäßig, dass Praxen weder einen dokumentierten Reaktionsplan noch eine aktuelle Systemübersicht vorhalten, wenn ein Vorfall eintritt. Diese Checkliste soll das ändern – konkret und ohne Umwege.
- Prüfen Sie, ob Ihre Atlassian-Instanz (Confluence, Jira, Bitbucket) selbst gehostet oder als Cloud-Dienst betrieben wird – die Patch-Verantwortung unterscheidet sich grundlegend.
- Klären Sie, welche Daten in Ihrer Confluence-Instanz gespeichert sind – speziell ob Zugangsdaten, Netzwerkpläne oder PVS-Konfigurationen dort liegen.
- Vergewissern Sie sich, ob Ihre Atlassian-Instanz von außen erreichbar ist – ein einfacher Shodan-Aufruf oder ein externer Portscan zeigt es binnen Minuten.
- Notieren Sie, wer in Ihrer Praxis oder Ihrem MVZ für IT-Vorfälle verantwortlich ist und unter welcher Nummer diese Person erreichbar ist.
Prüfpunkt 1 und 2: Wer ist zuständig – und was ist schriftlich geregelt?
Der erste und häufig unterschätzte Prüfpunkt betrifft keine Software, sondern eine Frage: Wer entscheidet in Ihrer Praxis, wenn ein IT-Vorfall eintritt? In vielen Praxen lautet die ehrliche Antwort: „Das klären wir dann.“ Das ist der teuerste Satz, den Sie in einem Notfall sagen können – weil wertvolle Zeit verstreicht, bevor überhaupt jemand handelt.
Prüfpunkt 1: Meldekette dokumentiert? Eine Meldekette muss nicht komplex sein. Sie braucht vier Elemente: Wer stellt einen Vorfall fest? Wen informiert diese Person zuerst? Wer entscheidet über Isolationsmaßnahmen? Und wer meldet ggf. an die Datenschutzbehörde? Das reicht als Einstieg. Wichtig ist, dass diese vier Rollen schriftlich festgelegt und allen Beteiligten bekannt sind – nicht nur dem Praxisinhaber.
Prüfpunkt 2: Cloud oder Self-Hosted – und wer patcht? Dieser Punkt ist für die Atlassian Sicherheitslücke Incident Response entscheidend, wird aber selten explizit geregelt. Bei Atlassian Cloud (atlassian.net) liefert Atlassian Sicherheitsupdates automatisch aus – Sie müssen in der Regel nicht aktiv werden. Bei Data Center oder Server liegt die Patch-Verantwortung vollständig bei Ihrem Team oder Ihrem IT-Dienstleister. Das muss intern schriftlich geregelt sein: Wer erhält Atlassian Security Bulletins? Wer entscheidet, wann ein Patch eingespielt wird?
| Betriebsmodell | Patch-Verantwortung | Handlungsbedarf bei kritischer Lücke |
|---|---|---|
| Atlassian Cloud (atlassian.net) | Atlassian | Meist keine eigene Aktion nötig – Status im Admin-Dashboard prüfen |
| Data Center (Self-Hosted) | Eigenes Team / IT-Dienstleister | Sofortiges Patch-Management erforderlich; CVSS ≥ 9 = binnen 24 h |
| Server (End-of-Life seit Feb. 2024) | Keine Updates mehr von Atlassian | Migration auf Cloud oder Data Center dringend erforderlich |
Definieren Sie intern eine Triage-Regel: CVSS-Score ≥ 9 bedeutet Patch binnen 24 Stunden – auch wenn das bedeutet, eine Wartung außerhalb der Sprechzeiten anzusetzen. CVSS 7–8,9 erlaubt 7 Tage. Alles darunter folgt dem regulären Wartungsfenster. Diese Regel ist kein bürokratischer Zusatz, sondern der Schutz vor dem Szenario, das das BSI – IT-Grundschutz für Unternehmen explizit beschreibt: Schwachstellen bleiben offen, weil intern unklar ist, wer zuständig ist.
Nutzen Sie die IT-Sicherheitslösungen der TTG GmbH, um diese Strukturen aufzubauen, bevor ein Vorfall eintritt – nicht danach.
- Legen Sie schriftlich fest, wer in Ihrer Praxis für IT-Vorfälle erster Ansprechpartner ist.
- Klären Sie mit Ihrem IT-Dienstleister, ob Atlassian Security Bulletins aktiv überwacht werden.
- Dokumentieren Sie, ob Sie Cloud oder Self-Hosted betreiben – und hinterlegen Sie diese Information an zentraler Stelle.
- Richten Sie, falls noch nicht vorhanden, einen RSS- oder E-Mail-Alert für Atlassian Security Bulletins ein.
Prüfpunkt 3 und 4: Systeme absichern und exponierte Zugänge schließen
Technische Mindestanforderungen klingen nach Spezialisten-Domäne – dabei sind zwei der wirksamsten Maßnahmen ohne Expertenwissen prüfbar. Prüfpunkt 3 und 4 gehen direkt in die Tiefe, denn hier entscheidet sich, ob ein Angreifer überhaupt einen Fuß in die Tür bekommt.
Prüfpunkt 3: Externe Erreichbarkeit Ihrer Atlassian-Instanz. Confluence, Jira, Bitbucket und Bamboo sollten niemals ohne zusätzliche Absicherung direkt aus dem Internet erreichbar sein. Die rund 4.000 exponierten Instanzen, die Greenbone im Februar 2024 identifizierte, waren genau das: direkt ansprechbar, ohne VPN-Zwischenschicht, ohne IP-Whitelisting. Prüfen Sie mit einem Shodan-Aufruf (suche: „Confluence“ + Ihre IP-Range) oder beauftragen Sie Ihren IT-Dienstleister mit einem externen Portscan. Wenn Ihre Instanz von außen erreichbar ist und Sie keinen zwingenden Grund dafür haben, schließen Sie diesen Zugang sofort.
Konkrete Maßnahmen für Data-Center-Betrieb:
- VPN als Pflichttor vor alle Atlassian-Zugänge schalten – kein direkter HTTPS-Zugriff aus dem Internet.
- IP-Whitelisting auf Firewall-Ebene konfigurieren: nur bekannte IP-Ranges (Praxisstandorte, Home-Office) erhalten Zugriff.
- HTTP Strict Transport Security (HSTS) und aktuelle TLS-Konfiguration (TLS 1.2 mindestens, TLS 1.3 bevorzugt) sicherstellen.
- Confluence-Systemprotokolle auf ungewöhnliche Admin-Konto-Erstellungen und Path-Traversal-Muster prüfen – dies ist der typische Angriffsweg bei CVE-2023-22515.
Prüfpunkt 4: Patch-Stand und Versionsmanagement. Für die Atlassian Sicherheitslücke Incident Response gilt: Ein Patch allein reicht nicht, wenn danach nicht aktiv auf Kompromittierung geprüft wird. Nach dem Einspielen eines kritischen Updates müssen Web-Server-Logs und Applikations-Logs auf Anzeichen einer vorherigen Ausnutzung gesichtet werden. Atlassian Data Center schreibt Ereignisse standardmäßig nach confluence-home/logs/atlassian-confluence.log – dort finden sich verdächtige POST-Requests auf /setup/setupadministrator.action, die auf eine Ausnutzung von CVE-2023-22515 hindeuten.
Die Sichere IT-Infrastruktur für KMU – TTG GmbH umfasst genau diese Schicht: nicht nur das Einspielen von Updates, sondern die anschließende Verifikation, ob ein System vor dem Patch bereits kompromittiert wurde. Für Arztpraxen ist das besonders relevant, weil ein unentdeckt kompromittiertes System weiter auf die TI-Infrastruktur zugreifen kann.
- Prüfen Sie nach jedem kritischen Patch Ihre Applikationslogs auf Anzeichen vorheriger Ausnutzung.
- Rotieren Sie nach einem bestätigten oder wahrscheinlichen Exploit-Zeitfenster alle Zugangsdaten, API-Tokens und Service-Account-Passwörter für betroffene Systeme.
- Stellen Sie sicher, dass Atlassian Data Center auf einer unterstützten Long-Term-Support-Version läuft – prüfen Sie die Atlassian End-of-Life-Richtlinie regelmäßig.
Prüfpunkt 5 und 6: Datenschutz und Zugriffsrechte unter Kontrolle halten
In Arztpraxen und MVZ trifft die Atlassian Sicherheitslücke Incident Response auf eine besondere Datenschutzlage: Patientendaten sind nach Art. 9 DSGVO eine besonders schützenswerte Kategorie. Das bedeutet, dass ein Sicherheitsvorfall mit Zugriff auf diese Daten nicht nur technisch, sondern rechtlich unmittelbar relevant ist. Die Meldepflicht an die zuständige Aufsichtsbehörde greift binnen 72 Stunden – unabhängig davon, ob der Schaden bereits eingetreten ist oder nur wahrscheinlich ist.
Prüfpunkt 5: Benutzerrechte in Atlassian nach dem Least-Privilege-Prinzip. Viele Confluence-Instanzen wachsen organisch: Jeder, der irgendwann einmal Zugang brauchte, hat ihn – und behält ihn. In Arztpraxen sind das häufig ehemalige Mitarbeiter, externe Dienstleister oder Auszubildende. Prüfen Sie, wer in Ihrer Instanz über Admin-Rechte verfügt, und reduzieren Sie diese konsequent. Confluence Data Center erlaubt granulare Rollen: Global-Admin, Confluence-Admin, Space-Admin, User. Nicht jeder braucht Global-Admin-Rechte.
- Exportieren Sie die vollständige Benutzerliste aus Confluence (Admin → User Management → Users) und gleichen Sie sie mit dem aktuellen Personalbestand ab.
- Deaktivieren Sie alle Konten ehemaliger Mitarbeiter und externer Dienstleister sofort – nicht erst beim nächsten Wartungsfenster.
- Aktivieren Sie Two-Factor Authentication (2FA) für alle Admin-Konten; in Confluence Data Center ab Version 8.x über externe Identity-Provider (Okta, Azure AD / Entra ID) oder atlassian-eigene 2FA-Apps.
- Überprüfen Sie, ob LDAP/Active-Directory-Synchronisation aktiv ist – und ob ausgeschiedene Mitarbeiter dort auch deaktiviert wurden.
Prüfpunkt 6: Datenschutz-Dokumentation aktuell halten. Die KBV-IT-Sicherheitsrichtlinie nach § 75b SGB V verlangt unter anderem eine aktuelle Dokumentation der eingesetzten IT-Systeme und ihrer Schutzmaßnahmen. Wenn Confluence Teil Ihrer Praxis-IT ist, muss das dort verzeichnet sein – einschließlich der gespeicherten Datenkategorien und der Zugriffsberechtigten. Ein Incident ohne diese Dokumentation macht die Schadensbegrenzung erheblich schwerer.
Nutzen Sie die IT-Dienstleistungen der TTG GmbH, um Ihre Systemdokumentation auf den Stand der KBV-Vorgaben zu bringen – das ist keine einmalige Aufgabe, sondern ein laufender Prozess, der sich in der Praxis bewährt hat.
- Prüfen Sie, ob Ihre Confluence-Instanz im Verzeichnis der Verarbeitungstätigkeiten (VVT) nach Art. 30 DSGVO erfasst ist.
- Stellen Sie sicher, dass Ihr Datenschutzbeauftragter über die eingesetzten Atlassian-Tools informiert ist.
- Halten Sie die Kontaktdaten der zuständigen Aufsichtsbehörde griffbereit – im Notfall bleibt für die Meldung wenig Zeit.
Prüfpunkt 7 und 8: Monitoring, Logs und Dokumentation dauerhaft sichern
Wer einen Sicherheitsvorfall nachträglich rekonstruieren muss, ist auf Logs angewiesen. Das klingt selbstverständlich – ist es aber nicht. In der Praxis fehlen entweder die Logs selbst (weil Rotation zu kurz eingestellt ist), oder sie liegen auf dem kompromittierten System und sind damit für den Angreifer zugänglich oder von ihm manipulierbar.
Prüfpunkt 7: Logarchivierung unabhängig vom Produktivsystem. Atlassian Confluence Data Center erzeugt standardmäßig Applikationslogs, Access-Logs und Audit-Logs. Für eine belastbare Atlassian Sicherheitslücke Incident Response müssen diese Logs zentral und unveränderlich gespeichert werden – nicht auf demselben Server, der möglicherweise kompromittiert ist. Konkret heißt das:
- Richten Sie ein zentrales Log-Management ein (z. B. Graylog, Elastic Stack / ELK, oder ein SIEM wie Microsoft Sentinel) und leiten Sie Confluence-Logs dorthin weiter.
- Stellen Sie die Log-Aufbewahrungsdauer auf mindestens 90 Tage ein – bei medizinischen Einrichtungen empfehlen wir 180 Tage, um DSGVO-Untersuchungen ausreichend abdecken zu können.
- Aktivieren Sie das Confluence Audit Log (Admin → Audit Log → Einstellungen) und stellen Sie sicher, dass Admin-Aktionen, Anmeldeereignisse und Berechtigungsänderungen lückenlos erfasst werden.
- Prüfen Sie, ob Ihr Hosting-Anbieter oder Ihre eigene Infrastruktur Logs automatisch rotiert und dabei kritische Daten verliert.
Prüfpunkt 8: Notfallplan testen. Ein dokumentierter Incident-Response-Plan, der nie geprobt wurde, ist ein Dokument – kein Plan. Für Arztpraxen empfehlen wir einen jährlichen Tischübung (Tabletop Exercise): 90 Minuten, ein fiktives Angriffsszenario, alle Beteiligten am Tisch. Kein technisches Wissen nötig – es geht darum zu prüfen, ob die Meldekette funktioniert, ob jeder seine Rolle kennt und ob die Kontaktdaten stimmen. Das lässt sich außerhalb der Sprechzeiten oder in Praxisferien durchführen und kostet kaum Ressourcen.
Beachten Sie dabei: Migration und größere Konfigurationsänderungen an Atlassian-Systemen sollten grundsätzlich außerhalb der Sprechzeiten eingeplant werden. Der BSI Lagebericht Cybersicherheit beschreibt explizit, dass IT-Dienstleister und deren Kunden zunehmend gezielt über Collaboration-Tools wie Confluence angegriffen werden – ein geübter Reaktionsplan ist der entscheidende Unterschied zwischen einer kontrollierten Reaktion und dem Chaos.
Besuchen Sie die Seite Über TTG GmbH – Ihr regionaler IT-Partner, um mehr über unsere Herangehensweise an strukturierte IT-Sicherheit zu erfahren.
Was tun, wenn ein Prüfpunkt nicht erfüllt ist? Priorisierung nach Risiko
Nicht jede Praxis kann alle acht Prüfpunkte gleichzeitig angehen. Das ist realistisch, kein Versagen. Entscheidend ist die richtige Reihenfolge. Externe Erreichbarkeit schließen hat Vorrang vor der Optimierung der Log-Aufbewahrung. Meldekette dokumentieren hat Vorrang vor der Tabletop-Übung. Diese Priorisierung gilt besonders für die Atlassian Sicherheitslücke Incident Response, weil aktive Angriffe nicht warten.
Typisch ist folgende Konstellation, die wir in Duderstadt und Umgebung bei mehreren Arztpraxen beobachten: Confluence wurde vor Jahren für die interne Dokumentation eingeführt – Behandlungsstandards, Hygienepläne, Gerätedokumentation. Das System läuft auf einem lokalen Server, ist über eine Port-Weiterleitung im Router von außen erreichbar, und der letzte Update-Stand ist unklar. Der PVS-Hersteller hat für die aktuelle Serverversion noch keine Freigabe erteilt, also wurde auch das Betriebssystem nicht aktualisiert. Ergebnis: mehrere Sicherheitslücken gleichzeitig, gegenseitig blockierende Update-Abhängigkeiten – und keine dokumentierte Reaktionskette.
Das ist kein Einzelfall, sondern ein Strukturproblem: Der PVS-Hersteller gibt neue Betriebssystemversionen erst verzögert frei – die Herstellerfreigabe ist in der Praxis der eigentliche Taktgeber, nicht die eigene IT. Das muss in Ihrem Notfallplan explizit berücksichtigt sein: Welche Systeme dürfen ohne Herstellerfreigabe aktualisiert werden? Welche nicht? Und was tun Sie in der Zwischenzeit, wenn eine kritische Lücke bekannt wird?
Die TTG GmbH begleitet Praxen bei der Atlassian Sicherheitslücke Incident Response mit über 25 Jahren Erfahrung in der IT-Betreuung medizinischer Einrichtungen. Wir helfen dabei, diese Priorisierung zu treffen – ohne den Praxisbetrieb zu unterbrechen. Einen ersten Überblick zu Prioritäten und Maßnahmen gibt auch das BSI-Angebot für Unternehmen und Organisationen.
- Schließen Sie zuerst externe Zugänge – das reduziert die Angriffsfläche sofort, ohne Herstellerfreigabe zu benötigen.
- Dokumentieren Sie danach Ihre Meldekette auf einer Seite – das dauert weniger als zwei Stunden.
- Sprechen Sie mit Ihrem PVS-Hersteller explizit ab, welche Betriebssystem-Updates freigegeben sind – und halten Sie diesen Status schriftlich fest.
- Planen Sie die Tabletop-Übung für die nächsten Praxisferien – das ist der realistischste Zeitpunkt ohne Sprechstundendruck.
Jetzt unverbindlich Kontakt aufnehmen – wir analysieren gemeinsam, welche Prüfpunkte bei Ihnen dringend sind und welche warten können.
Was sofort, was in 30 Tagen, was dauerhaft: eine ehrliche Zeitleiste
Die Atlassian Sicherheitslücke Incident Response lässt sich nicht in einer Woche lösen – aber einige Maßnahmen wirken sofort, andere brauchen einen strukturierten Zeitplan. Hier ist eine klare Zeitleiste, die sich in der Praxis bewährt hat.
Sofort (heute, maximal 24 Stunden):
- Prüfen Sie, ob Ihre Atlassian-Instanz von außen erreichbar ist – und schließen Sie diesen Zugang, sofern er nicht zwingend nötig ist.
- Prüfen Sie den Versions- und Patch-Stand Ihrer Confluence/Jira/Bitbucket-Installation und gleichen Sie ihn mit den aktuellen Atlassian Security Bulletins ab.
- Kontrollieren Sie die Admin-Konten Ihrer Atlassian-Instanz auf unbekannte oder nicht mehr aktive Einträge.
Innerhalb von 30 Tagen:
- Meldekette schriftlich dokumentieren und allen Beteiligten kommunizieren – eine Seite reicht.
- Logarchivierung einrichten: Atlassian Audit Log aktivieren, zentrale Weiterleitung an ein Log-Management-System konfigurieren.
- Benutzerrechte nach Least-Privilege-Prinzip überarbeiten – Benutzerliste exportieren, mit aktuellem Personal abgleichen, inaktive Konten deaktivieren.
- Two-Factor Authentication für alle Admin-Konten aktivieren.
- Abklärung mit PVS-Hersteller: Welche Server- und Betriebssystem-Versionen sind aktuell freigegeben?
Langfristig (laufend, mindestens jährlich):
- Atlassian Security Bulletins aktiv abonnieren und eine interne Triage-Regel leben: CVSS ≥ 9 = 24 h, CVSS 7–8,9 = 7 Tage, darunter = reguläres Wartungsfenster.
- Jährliche Tabletop-Übung durchführen – Meldekette, Isolationsroutine, Eskalationskontakt testen.
- Kontakt zu einem externen Incident-Response-Dienstleister schriftlich fixieren, bevor ein Notfall eintritt – im Ernstfall ist keine Zeit für Anbietersuche.
- Systemdokumentation nach KBV-IT-Sicherheitsrichtlinie (§ 75b SGB V) aktuell halten – mindestens nach jedem größeren Update oder Personalwechsel prüfen.
Aktuell ist zu beachten: Auch andere Systeme, die in Praxen häufig im Einsatz sind, erhalten kritische Sicherheitsupdates. So hat Microsoft kürzlich ein nachträgliches Exchange-Update veröffentlicht, das eine Rechteausweitungslücke schließt – Praxen mit eigenem Exchange-Server sollten diesen Exchange-Patch von Microsoft laut heise Security umgehend einspielen. Das zeigt: Patch-Management ist keine Atlassian-spezifische Aufgabe, sondern ein strukturelles Thema für die gesamte Praxis-IT.
Typische Stolperfallen bei der Umsetzung – und wie Sie sie vermeiden
Die Atlassian Sicherheitslücke Incident Response scheitert in der Praxis selten an fehlendem Wissen – sondern an Fehlern, die im Nachhinein vermeidbar gewesen wären. Hier sind die häufigsten davon.
Stolperfalle 1: „Wir haben gepatcht – fertig.“ Patchen allein reicht nicht. Wer eine kritische Lücke schließt, ohne vorher zu prüfen, ob sie bereits ausgenutzt wurde, betreibt ein möglicherweise kompromittiertes System weiter. Nach jedem kritischen Atlassian-Patch müssen die Applikationslogs auf Anzeichen vorheriger Ausnutzung geprüft werden – speziell auf POST-Requests gegen bekannte Exploit-Endpunkte und auf unerwartet angelegte Admin-Konten.
Stolperfalle 2: Passwörter und Tokens nicht rotiert. Nach einem bestätigten oder wahrscheinlichen Exploit-Zeitfenster müssen alle Zugangsdaten, API-Tokens und Service-Account-Passwörter für betroffene Systeme erneuert werden. Das wird in der Praxis regelmäßig vergessen – mit der Folge, dass ein Angreifer, der vor dem Patch Credentials abgegriffen hat, weiterhin Zugang behält.
Stolperfalle 3: KIM und TI als „nicht betroffen“ eingestuft. Der KIM-Dienst und der Telematikinfrastruktur-Konnektor laufen technisch getrennt von Confluence – aber sie teilen sich das Praxisnetz. Ein kompromittierter Confluence-Server kann als Sprungbrett genutzt werden, um laterale Bewegungen im Netz durchzuführen und von dort auf TI-Komponenten zuzugreifen. Segmentieren Sie Ihr Netz so, dass ein Confluence-Server keinen direkten Zugriff auf den TI-Konnektor hat.
Stolperfalle 4: Notfallplan ohne externen Eskalationskontakt. Viele Praxen erstellen einen Incident-Response-Plan, vergessen aber, einen externen IT-Dienstleister als Eskalationskontakt schriftlich zu fixieren. Im Ernstfall – wenn das interne IT-Wissen nicht ausreicht oder die eigene Infrastruktur betroffen ist – brauchen Sie jemanden, den Sie anrufen können. Dieser Kontakt muss vor dem Vorfall vereinbart sein, nicht danach.
Stolperfalle 5: Atlassian Server-Instanzen weiter betreiben. Der Support für Atlassian Server (nicht Data Center) endete im Februar 2024. Seitdem gibt es keine Sicherheitsupdates mehr für diesen Betriebsmodus. Wer noch eine Server-Instanz betreibt, setzt seine Praxis einer wachsenden Zahl ungepatchter Schwachstellen aus – ohne Aussicht auf Abhilfe durch den Hersteller.
- Prüfen Sie nach jedem kritischen Patch aktiv die Logs auf Kompromittierungshinweise – nicht erst bei auffälligem Verhalten.
- Rotieren Sie Credentials und API-Tokens nach jedem bestätigten Exploit-Zeitfenster vollständig.
- Segmentieren Sie Ihr Netz: Confluence-Server ohne direkte Route zum TI-Konnektor.
- Fixieren Sie mindestens einen externen IR-Dienstleister schriftlich als Eskalationskontakt.
- Migrieren Sie von Atlassian Server auf Data Center oder Cloud – sofort, nicht irgendwann.
Ihre Checkliste: So starten Sie jetzt
- Prüfen Sie, ob Ihre Atlassian-Instanz (Confluence, Jira, Bitbucket) von außen erreichbar ist – und schließen Sie diesen Zugang ohne VPN-Zwischenschicht sofort.
- Prüfen Sie den aktuellen Versions- und Patch-Stand Ihrer Atlassian Data Center-Installation und gleichen Sie ihn mit den aktuellen Security Bulletins ab (CVSS ≥ 9 = Patch binnen 24 h).
- Dokumentieren Sie Ihre Meldekette auf einer Seite: Wer stellt fest, wer entscheidet, wer meldet? – und teilen Sie dieses Dokument mit allen Beteiligten.
- Exportieren Sie die vollständige Benutzerliste aus Ihrer Atlassian-Instanz, gleichen Sie sie mit dem aktuellen Personalbestand ab und deaktivieren Sie inaktive Konten.
- Aktivieren Sie Two-Factor Authentication für alle Admin-Konten in Confluence und Jira.
- Aktivieren Sie das Confluence Audit Log und richten Sie eine zentrale Log-Weiterleitung an ein vom Produktivsystem getrenntes Log-Management-System ein.
- Klären Sie mit Ihrem PVS-Hersteller, welche Betriebssystem- und Server-Versionen aktuell freigegeben sind – und halten Sie das schriftlich fest.
- Fixieren Sie mindestens einen externen Incident-Response-Dienstleister als schriftlichen Eskalationskontakt – vor dem nächsten Vorfall, nicht danach.
Häufig gestellte Fragen
Wir nutzen Atlassian Cloud – müssen wir bei einer kritischen Lücke selbst aktiv werden?
Bei Atlassian Cloud (atlassian.net) übernimmt Atlassian das Patch-Management automatisch. Sie müssen in der Regel nicht selbst aktiv werden. Empfehlenswert ist es trotzdem, den Status im Atlassian Admin-Dashboard zu prüfen und Atlassian-Statusmeldungen zu abonnieren. Die Incident-Response-Pflicht entfällt dadurch nicht vollständig: Ihre eigenen Zugangsdaten, Benutzerrechte und Integrationen zu anderen Systemen müssen Sie weiterhin selbst kontrollieren.
Unser PVS-Hersteller hat die aktuelle Betriebssystemversion noch nicht freigegeben – dürfen wir trotzdem patchen?
Das ist eine der schwierigsten Abwägungen in der Praxis-IT: Ohne Herstellerfreigabe riskieren Sie Inkompatibilitäten im Praxisverwaltungssystem, mit ungepatchtem System riskieren Sie eine Sicherheitslücke. Unsere Empfehlung: Sprechen Sie Ihren PVS-Hersteller sofort an, sobald eine kritische Schwachstelle bekannt wird, und fordern Sie eine Stellungnahme zur Freigabe ein. In der Zwischenzeit sind kompensatorische Maßnahmen wie Netzsegmentierung und geschlossene externe Zugänge der wichtigste Schutz.
Was müssen wir im Fall eines Angriffs an die Datenschutzbehörde melden?
Wenn Patientendaten betroffen sind oder ein Zugriff nicht ausgeschlossen werden kann, greift die Meldepflicht nach Art. 33 DSGVO: Sie haben 72 Stunden Zeit, den Vorfall der zuständigen Aufsichtsbehörde zu melden. Die Meldung muss Art des Vorfalls, betroffene Datenkategorien, ungefähre Anzahl betroffener Personen und ergriffene Maßnahmen enthalten. Bereiten Sie dieses Dokument als Vorlage vor – im Ernstfall bleibt keine Zeit für eine Erstfassung.
Wie aufwändig ist ein Incident-Response-Plan für eine kleine Praxis mit drei Ärzten?
Deutlich weniger aufwändig als vermutet. Für eine kleine Praxis reichen vier dokumentierte Kernelemente: Meldekette (wer informiert wen?), Isolationsroutine (wie wird ein System vom Netz getrennt?), Logarchivierung (welche Logs werden wie lange aufbewahrt?) und ein externer Eskalationskontakt. Das lässt sich an einem Nachmittag erarbeiten – außerhalb der Sprechzeiten oder in Praxisferien. Die TTG GmbH unterstützt dabei mit einer strukturierten Vorlage.
Gilt die KBV-IT-Sicherheitsrichtlinie auch für unser MVZ, das kein eigenes Atlassian-System betreibt?
Ja. Die KBV-IT-Sicherheitsrichtlinie nach § 75b SGB V gilt für alle Vertragsärzte und damit auch für MVZ, unabhängig davon, welche konkreten Systeme betrieben werden. Sie umfasst unter anderem Anforderungen an Zugriffsschutz, Datensicherung, Protokollierung und das Verhalten bei Sicherheitsvorfällen. Auch wenn kein Atlassian-System im Einsatz ist, müssen Telematikinfrastruktur, KIM-Dienst und PVS den dort beschriebenen Mindestanforderungen entsprechen.
Martin Trappe ist Geschäftsführer der TTG Daten- und Bürosysteme GmbH in Dingelstädt. Mit über 25 Jahren Erfahrung im IT-Mittelstand betreut er kleine und mittelständische Unternehmen in Nordthüringen, Eichsfeld und Südniedersachsen. Die TTG GmbH ist ISO/IEC 27001 zertifiziert – dem höchsten Standard für Informationssicherheit.
Kontakt aufnehmen · Über TTG GmbH
Wissen Sie heute, wen Sie in Ihrer Praxis in den ersten 60 Minuten nach einem Cyberangriff anrufen würden – und ob diese Person erreichbar ist?
Ihre IT-Sicherheit jetzt stärken
Schützen Sie Ihr Unternehmen vor Cyberangriffen und Datenverlust. Die TTG GmbH berät KMU in Nordthüringen und Eichsfeld – ISO/IEC 27001 zertifiziert, persönlich vor Ort.
