{"id":5800,"date":"2026-10-22T18:04:53","date_gmt":"2026-10-22T16:04:53","guid":{"rendered":"https:\/\/wwwschutz.de\/blog\/?p=5800"},"modified":"2026-10-23T16:10:35","modified_gmt":"2026-10-23T14:10:35","slug":"connectwise-cloud-backup-lieferkettenangriff","status":"publish","type":"post","link":"https:\/\/wwwschutz.de\/blog\/connectwise-cloud-backup-lieferkettenangriff\/","title":{"rendered":"ConnectWise Cloud Backup: Angriff auf Microsoft-365-Tenants"},"content":{"rendered":"\n

Hacker nutzten ein Zugangsdatum der Backup-Anwendung eines Anbieters, um sich in Microsoft-365-Tenants anzumelden, und zwar ohne Benutzerkonto und ohne MFA-Abfrage. Belegt ist der Missbrauch der Anwendungsidentit\u00e4t. Offen sind die Ursache, der Umfang des Schadens und des Datenabflusses.<\/em><\/p>\n\n\n\n

Seit dem 15. Oktober 2026 besch\u00e4ftigt ein Vorfall rund um ConnectWise Cloud Backup viele IT-Abteilungen und IT-Dienstleister. Der Dienst, fr\u00fcher unter dem Namen SkyKick<\/strong> bekannt, wurde am 17. Oktober 2026 abgeschaltet und wird nach Angaben des Herstellers schrittweise wieder bereitgestellt. Die Lage entwickelt sich weiter. Beschrieben wird der Stand vom 22. Oktober 2026. Zahlen, Empfehlungen und Wiederherstellungsphasen k\u00f6nnen sich seitdem ge\u00e4ndert haben.<\/p>\n\n\n\n

Der Angriff auf ConnectWise Cloud Backup im \u00dcberblick<\/h2>\n\n\n\n

ConnectWise Cloud Backup ist ein Dienst zur Sicherung von Microsoft-365-Daten wie Postf\u00e4chern, Dateien und Teams-Inhalten. Er ging aus dem Produkt SkyKick hervor, das ConnectWise \u00fcbernommen hat. Eingerichtet wird ein solcher Dienst meist von einem IT-Dienstleister (englisch Managed Service Provider, kurz MSP) f\u00fcr dessen Kunden. Diese Einordnung ist eine allgemeine Beschreibung und keine belegte Statistik dar\u00fcber, wer den Dienst tats\u00e4chlich nutzt.<\/p>\n\n\n\n

Technisch funktioniert ein solcher Dienst als Anwendung, die sich mit einem Microsoft-365-Tenant verbindet. Ein Tenant ist die abgegrenzte Umgebung eines Unternehmens bei Microsoft, mit Benutzern, Postf\u00e4chern, Dateien und Einstellungen. Damit die Backup-Anwendung Daten lesen darf, erteilt ein Administrator bei der Einrichtung eine Einwilligung (englisch Consent). Danach ist die Anwendung im Tenant als Unternehmensanwendung (Enterprise Application) hinterlegt.<\/p>\n\n\n\n

Nach der Analyse der Sicherheitsfirma Huntress meldeten sich Angreifer mit der Identit\u00e4t genau dieser Anwendung in zahlreichen Kunden-Tenants an. Das Zugangsdatum, mit dem sich die Anwendung gegen\u00fcber Microsoft ausweist, geh\u00f6rte dem Hersteller und lag nicht bei den Kunden. Ob der Dienst selbst \u201egehackt\u201c wurde, ist nicht belegt. Belegt ist der Missbrauch der Anwendungsidentit\u00e4t. ConnectWise schaltete den Dienst am 17. Oktober 2026 ab. Es handelt sich um einen sogenannten Lieferkettenangriff, ein Begriff, der weiter unten erkl\u00e4rt wird.<\/p>\n\n\n\n

Quellen: Analyse von Huntress<\/a> und Mitteilungen im Trust Center von ConnectWise<\/a>.<\/p>\n\n\n\n

Zeitleiste: Von den ersten Versuchen bis zur Abschaltung<\/h2>\n\n\n\n

Die folgende \u00dcbersicht fasst die Ereignisse zusammen, die Huntress und ConnectWise \u00fcbereinstimmend oder jeweils f\u00fcr sich beschreiben. Uhrzeiten sind in UTC angegeben, alle Daten liegen im Jahr 2026.<\/p>\n\n\n\n

Datum<\/th>Ereignis<\/th>Quelle<\/th><\/tr><\/thead>
13. und 14. Oktober<\/td>Password-Spray (massenhaftes Ausprobieren h\u00e4ufiger Passw\u00f6rter) gegen vier Kanzlei-Tenants<\/td>Huntress<\/td><\/tr>
14. Oktober<\/td>Nach Angabe von ConnectWise Entdeckung des Vorfalls und Beginn der Untersuchung (Herstellerangabe)<\/td>ConnectWise Trust Center<\/td><\/tr>
15. Oktober, ab etwa 01:58 Uhr<\/td>In etwa 50 von Huntress beobachteten Tenants weisen sich Cloud-Management-Anwendungen von ConnectWise selbst Verzeichnisrollen zu, meist Exchange Administrator<\/td>Huntress<\/td><\/tr>
15. Oktober, etwa 06:13 bis 08:34 Uhr<\/td>Token-Abrufe der Angreifer-Adresse; unter den ersten rund 290 von Huntress gepr\u00fcften Tenants zeigten 17 eine solche Anmeldung<\/td>Huntress<\/td><\/tr>
16. Oktober<\/td>ConnectWise ver\u00f6ffentlicht um 17:47 Uhr die erste Mitteilung zu Zugriffsversuchen; Huntress z\u00e4hlt um 19:00 Uhr 162 best\u00e4tigte Tenants<\/td>ConnectWise, Huntress<\/td><\/tr>
17. Oktober, etwa 05:00 bis 07:00 Uhr<\/td>Cloud-Backup-Zugriff abgeschaltet, sieben Anwendungsidentit\u00e4ten deaktiviert, Zertifikate widerrufen<\/td>ConnectWise<\/td><\/tr>
19. Oktober<\/td>Alle Konten und Zugangsdaten der betroffenen Umgebung zur\u00fcckgesetzt<\/td>ConnectWise<\/td><\/tr>
21. und 22. Oktober<\/td>Wiederherstellung in Phasen, jeder Schritt mit Sicherheitspr\u00fcfung, ohne verl\u00e4sslichen Termin<\/td>ConnectWise<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Eine Einschr\u00e4nkung betrifft den Anfang. Huntress verkn\u00fcpft die Password-Spray-Versuche gegen die Kanzleien zeitlich mit dem sp\u00e4teren Missbrauch des Anbieter-Zugangsdatums. Ein urs\u00e4chlicher Zusammenhang ist damit nicht nachgewiesen. Es kann sich um dieselben Angreifer handeln, belegt ist das nicht.<\/p>\n\n\n\n

Auff\u00e4llig ist das Tempo. Huntress beschreibt die Abl\u00e4ufe als schnell und vermutet Automatisierung, best\u00e4tigt ist das nicht. F\u00fcr die Verteidigung hei\u00dft das: Ein einzelner Tenant sah nur einen Bruchteil des Geschehens, und zwischen erstem Zugriff und Rollenzuweisung lagen teils nur Minuten.<\/p>\n\n\n\n

Wie die Anmeldung ohne Benutzer und ohne MFA funktioniert<\/h2>\n\n\n\n

Im Alltag melden sich Menschen mit Benutzername, Passwort und einem zweiten Faktor an (Multi-Faktor-Authentifizierung, kurz MFA). Zus\u00e4tzlich bewertet Microsoft \u00fcber Conditional Access, also Zugriffsregeln, Faktoren wie Ger\u00e4t, Standort und Risiko. Beides ist auf Benutzeranmeldungen ausgelegt.<\/p>\n\n\n\n

Eine Backup-Anwendung arbeitet anders. Sie ist als Multi-Tenant-App angelegt, das hei\u00dft, dieselbe Anwendung ist in vielen fremden Tenants zugelassen. Jeder Kunde erteilt ihr einmal per Consent bestimmte Rechte. Sp\u00e4ter holt die Anwendung sich selbst Zugriffstoken, also zeitlich begrenzte digitale Berechtigungsnachweise, f\u00fcr Microsoft Graph, die zentrale Programmierschnittstelle von Microsoft 365. Dazu weist sie sich mit einem Zertifikat oder Geheimnis aus, einer sogenannten Client Assertion nach dem Standard OAuth. Dieses Zertifikat liegt im Tenant des Herstellers. Die Anmeldung gilt in Microsoft-Begriffen f\u00fcr einen Dienstprinzipal (Service Principal), das ist die Identit\u00e4t der Anwendung im jeweiligen Tenant.<\/p>\n\n\n\n

Wer dieses Zugangsdatum besitzt, kann sich in allen Tenants anmelden, in denen die Anwendung zugelassen ist. F\u00fcr Microsoft sieht das aus wie der legitime Dienst. Es gibt keinen Benutzer, der einen zweiten Faktor best\u00e4tigen k\u00f6nnte, und kein Ger\u00e4t, das gepr\u00fcft w\u00fcrde. Heise, BleepingComputer und Huntress beschreiben diesen Punkt \u00fcbereinstimmend: MFA hilft an dieser Stelle nicht. Ob und wie Microsoft Zugriffsregeln f\u00fcr solche Anwendungsidentit\u00e4ten anbietet, ist ein eigenes Thema und hier nicht gepr\u00fcft.<\/p>\n\n\n\n\n

\"Schema
Zwei Wege in einen Tenant: Anwendungslogin und Benutzeranmeldung im Vergleich.<\/figcaption><\/figure>\n\n\n\n\n

Als Lieferkettenangriff auf Microsoft 365 gilt ein Angriff, der nicht das eigentliche Ziel direkt angeht, sondern einen Dienstleister oder Softwareanbieter, dem das Ziel vertraut. Nach Angaben von BleepingComputer bezeichnet auch Microsoft den Vorfall als Supply-Chain-Angriff. Die Kunden hatten nicht zwingend etwas falsch gemacht. Sie hatten einer Anwendung vertraut, deren Zugangsdatum au\u00dferhalb ihrer Kontrolle lag.<\/p>\n\n\n\n

Ungekl\u00e4rt ist, wie die Angreifer an dieses Zugangsdatum gelangten. Heise, Huntress und BleepingComputer sprechen von vermutlich gestohlenen Anbieter-Zugangsdaten. Das ist eine Annahme, keine ver\u00f6ffentlichte Feststellung. Details zur Ausnutzung, etwa konkrete Abfragen, werden hier bewusst nicht beschrieben.<\/p>\n\n\n\n

Was zu den Zahlen belegt ist und was nicht<\/h2>\n\n\n\n

In den Berichten kursieren mehrere Zahlen, die auf den ersten Blick nicht zusammenpassen. Sie beschreiben Verschiedenes, teils zu unterschiedlichen Stichtagen.<\/p>\n\n\n\n\n

\"Vier
Die genannten Zahlen haben unterschiedliche Stichtage und Z\u00e4hlweisen.<\/figcaption><\/figure>\n\n\n\n\n
Zahl<\/th>Quelle und Stand<\/th>Bedeutung<\/th>Vorbehalt<\/th><\/tr><\/thead>
162<\/td>Huntress, 16. Oktober 2026, 19:00 Uhr UTC<\/td>Tenants mit best\u00e4tigten unbefugten Anmeldungen<\/td>Nur Tenants im Beobachtungsbereich von Huntress<\/td><\/tr>
173<\/td>Born City, nach Branchenberichten<\/td>Abweichende Zahl betroffener Tenants<\/td>Z\u00e4hlweise und Stichtag unklar, deshalb nicht \u00fcbernommen<\/td><\/tr>
fast 1.000<\/td>Huntress, 17. Oktober 2026<\/td>Tenants mit Anmeldeaktivit\u00e4t von der Angreifer-Adresse<\/td>Aktivit\u00e4t ist kein Datenabfluss; ein Teil scheiterte<\/td><\/tr>
\u00fcber 300<\/td>Huntress, 17. Oktober 2026<\/td>Davon erfolgreiche Anmeldungen<\/td>Erfolgreich hei\u00dft nicht, dass Daten gelesen wurden<\/td><\/tr>
\u00fcber 10.000<\/td>Huntress, 19. Oktober 2026<\/td>Tenants mit ConnectWise-Apps in der Auswertung<\/td>Pr\u00fcfmenge, keine Opferzahl<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Die tats\u00e4chliche Gesamtzahl ist ungesichert. Nach Angaben von heise hat ConnectWise keinen Zugriff auf Kundenumgebungen, und Huntress sieht nur die Tenants, die es selbst beobachtet. Die Unterscheidung zwischen 162 und 173 bleibt deshalb offen und wird hier als ungekl\u00e4rt gef\u00fchrt.<\/p>\n\n\n\n

Wichtig ist die Bedeutung der Begriffe. Eine Anmeldeaktivit\u00e4t ist nicht gleichbedeutend mit einem Datenabfluss, und eine erfolgreiche Anmeldung bedeutet nicht, dass Daten gelesen wurden. Huntress fand in den ausgewerteten Tenants keine Manipulation von Postf\u00e4chern, Dateien, Benutzern oder Richtlinien. Die Firma weist aber selbst darauf hin, dass lesende Zugriffe \u00fcber Microsoft Graph nicht protokolliert werden und das Bild daher unvollst\u00e4ndig ist. Nach Angaben von BleepingComputer fand die Firma Todyl in neun untersuchten Tenants ebenfalls nur Anmeldeaktivit\u00e4t. Diese Aussage stammt aus zweiter Hand.<\/p>\n\n\n\n

Eine zweite, gezielte Welle richtete sich laut Huntress gegen 16 Tenants in den Bereichen Politik, nationale Sicherheit, Handel und kritische Rohstoffe. Die Zugriffe scheiterten nach Darstellung von Huntress, und die meisten dieser Ziele nutzten keine ConnectWise-Produkte. F\u00fcr kleine und mittlere Unternehmen ist das eine Einordnung, kein Grund zur Sorge: Die Mehrzahl der Betroffenen geh\u00f6rt nicht zu solchen Zielgruppen.<\/p>\n\n\n\n

Auch inaktive Registrierungen sind ein Risiko<\/h2>\n\n\n\n

Nach den Angaben von heise konnte ein Zugriff bestehen, solange die Registrierung der Anwendung im Tenant vorhanden war. Es spielt dabei keine Rolle, ob der Dienst noch aktiv genutzt wird. Wer vor Jahren eine Backup-L\u00f6sung testete, den Anbieter wechselte oder einen Dienstleister mit der Einrichtung beauftragte, kann also eine Altlast im Tenant haben, ohne davon zu wissen.<\/p>\n\n\n\n

\u00c4ltere Tenants f\u00fchren die Anwendung eventuell noch unter dem fr\u00fcheren Namen \u201eSkyKick Cloud Manager\u201c, wie BleepingComputer berichtet. Au\u00dferdem wurden laut Huntress weitere ConnectWise-Anwendungen aus dem Bereich Cloud-Management missbraucht, die auf Exchange, Teams, SharePoint, Graph und das Partner Center zugreifen. Die Cloud-Backup-Anwendung hatte nach Angaben von Microsoft, wiedergegeben von BleepingComputer, vermutlich weitreichende Rechte wie Directory.ReadWrite.All. Das ist ein sehr umfassendes Verzeichnisrecht und ein Beispiel daf\u00fcr, wie viel Vertrauen bei einer Einwilligung einger\u00e4umt wird.<\/p>\n\n\n\n

Eine inaktive App-Registrierung ist ein offener Zugang, solange sie im Tenant steht.<\/p><\/blockquote><\/figure>\n\n\n\n

Der praktische Schluss ist eine regelm\u00e4\u00dfige Inventur. In der Verwaltung von Microsoft Entra ID, dem Verzeichnisdienst von Microsoft 365, sind die Unternehmensanwendungen und App-Registrierungen einsehbar. Dort sollten Eintr\u00e4ge ehemaliger Dienstleister und nicht mehr ben\u00f6tigter Dienste auffallen und nach Kl\u00e4rung entfernt werden. W\u00e4hrend eines laufenden Vorfalls gilt jedoch eine andere Reihenfolge: erst deaktivieren, nicht l\u00f6schen (siehe n\u00e4chster Abschnitt). Au\u00dferdem geh\u00f6rt in die Dokumentation, wer die Anwendung eingerichtet hat, ob Kunde, MSP oder ein Vorg\u00e4nger. Ohne diese Information bleibt oft unklar, wer \u00fcberhaupt zust\u00e4ndig ist.<\/p>\n\n\n\n

Was Admins jetzt pr\u00fcfen: Registrierung, Rollen, Secrets, Logs<\/h2>\n\n\n\n

Die folgenden Schritte geben die Empfehlungen von Huntress und ConnectWise in Alltagssprache wieder. Ma\u00dfgeblich bleibt der technische Leitfaden von ConnectWise<\/a>. Nach Angaben von heise dient dieser der Eind\u00e4mmung, nicht der vollst\u00e4ndigen Behebung. Anwendungs-Kennungen und IP-Adressen werden hier nicht abgetippt, weil Tippfehler bei Pr\u00fcfungen zu falschen Ergebnissen f\u00fchren. Sie sind in den genannten Prim\u00e4rquellen zu entnehmen.<\/p>\n\n\n\n

    \n
  1. Pr\u00fcfen, ob ConnectWise Cloud Backup, SkyKick und weitere ConnectWise-Anwendungen aus dem Cloud-Management im Tenant vorhanden sind. Die Kennungen werden aus dem Leitfaden von ConnectWise und der Analyse von Huntress \u00fcbernommen.<\/li>\n\n\n\n
  2. Betroffene Anwendungen deaktivieren statt l\u00f6schen. Huntress empfiehlt, die Option zur Anmeldung f\u00fcr Benutzer auf \u201eNein\u201c zu stellen, denn beim L\u00f6schen geht die Einwilligung verloren und der Dienst m\u00fcsste neu autorisiert werden. ConnectWise bittet Partner, die Verbindungen bis zu formellen Anweisungen deaktiviert zu lassen. Folge: Backups pausieren. Vorhandene Archive bleiben laut ConnectWise erhalten. Die L\u00fccke bei der Datensicherung sollte bewusst abgewogen und gegebenenfalls anders \u00fcberbr\u00fcckt werden.<\/li>\n\n\n\n
  3. Die Grenze des Deaktivierens kennen. Es stoppt neue Token-Anfragen, bereits ausgestellte Token k\u00f6nnen laut ConnectWise bis zu ihrem Ablauf g\u00fcltig bleiben. Nach Angaben von Todyl, wiedergegeben von BleepingComputer, beendet auch das Abmelden von Benutzersitzungen den anwendungsbasierten Zugriff nicht. Das ist eine Sekund\u00e4rangabe. Nach Huntress entfernt das Deaktivieren au\u00dferdem keine Zugangsdaten, die bereits hinzugef\u00fcgt wurden.<\/li>\n\n\n\n
  4. Secrets und Zertifikate aller Unternehmensanwendungen und App-Registrierungen auf unbekannte Eintr\u00e4ge pr\u00fcfen, besonders solche, die seit dem 13. Oktober 2026 hinzugekommen sind. Huntress beobachtete neue Secrets auf anderen Anwendungen mit G\u00fcltigkeit bis ins Jahr 2028.<\/li>\n\n\n\n
  5. Die Verzeichnisrollen der betroffenen Anwendungen pr\u00fcfen, vor allem Global Administrator, Exchange Administrator und Privileged Authentication Administrator. Nicht beabsichtigte Rollen entfernen. Postfachweiterleitungen und Posteingangsregeln geh\u00f6ren laut ConnectWise ebenfalls auf die Liste.<\/li>\n\n\n\n
  6. Protokolle lesen. In den Anmeldeprotokollen von Entra ID (Sign-in-Logs) ist der Reiter f\u00fcr Anmeldungen von Dienstprinzipalen zust\u00e4ndig, nicht der Standardreiter f\u00fcr Benutzeranmeldungen. Die Audit-Protokolle zeigen Rollen- und Credential-\u00c4nderungen. Der Zeitraum 15. bis 16. Oktober 2026 ist besonders relevant. Die IP-Adressen aus den Mitteilungen von Huntress und ConnectWise dienen als Pr\u00fcfhinweis, nicht als Beweis. Ein unauff\u00e4lliges Ergebnis schlie\u00dft einen Zugriff nach beiden Quellen nicht aus.<\/li>\n\n\n\n
  7. Protokolle sichern, bevor sie gel\u00f6scht werden (siehe n\u00e4chster Abschnitt).<\/li>\n<\/ol>\n\n\n\n

    Bei Unsicherheit empfiehlt sich der R\u00fcckgriff auf den IT-Dienstleister oder auf einen externen Incident-Response-Dienst. Eine Pr\u00fcfung von au\u00dfen, wie sie bei Websites m\u00f6glich ist, funktioniert f\u00fcr Tenant-Konfigurationen nicht. Die Einstellungen sind nur innerhalb des Tenants sichtbar.<\/p>\n\n\n\n

    Entra-Protokolle: 7 oder 30 Tage und dann weg<\/h2>\n\n\n\n

    Die wichtigste Frist ist keine rechtliche, sondern eine technische. Nach der Dokumentation von Microsoft Learn<\/a> (Stand der Seite: 25. M\u00e4rz 2026) werden Anmelde- und Audit-Protokolle in Entra ID Free sieben Tage aufbewahrt, mit den Lizenzen P1 und P2 drei\u00dfig Tage. \u00c4nderungen gelten nicht r\u00fcckwirkend, abgelaufene Daten sind nicht wiederherstellbar. L\u00e4ngere Aufbewahrung gelingt \u00fcber einen Export, etwa nach Azure Monitor, oder bei bestimmten Lizenzen \u00fcber Microsoft Purview Audit (Premium). Das Unified Audit Log von Microsoft 365 ist davon getrennt und hat eigene Aufbewahrungsfristen. Die Lizenzangaben sollten vor einer Entscheidung noch einmal gegen die aktuelle Microsoft-Seite gepr\u00fcft werden.<\/p>\n\n\n\n\n

    \"Zeitstrahl
    Angriffszeitraum und Aufbewahrungsfristen der Entra-Protokolle.<\/figcaption><\/figure>\n\n\n\n\n

    Die Folge ist unbequem. Der Angriff vom 15. Oktober 2026 liegt am 22. Oktober 2026 genau sieben Tage zur\u00fcck. In Tenants ohne Premium-Lizenz sind die Eintr\u00e4ge von damals deshalb bereits gel\u00f6scht oder stehen kurz davor. Mit P1 oder P2 bleibt Zeit bis etwa Mitte November. Deshalb gilt: Sicherungen der relevanten Protokolle jetzt anlegen, am besten als Export in den Rohdaten. Screenshots sind ein schwacher Ersatz, weil sie weder vollst\u00e4ndig noch pr\u00fcfbar sind.<\/p>\n\n\n\n

    Ungesichert ist, ob alle Aktionen der Angreifer \u00fcberhaupt protokolliert wurden. Heise berichtet, manche Aktionen seien eventuell nicht erfasst. Huntress betont, dass lesende Graph-Zugriffe keine Audit-Eintr\u00e4ge erzeugen. Fehlende Protokolle sind kein Entwarnungssignal, sondern selbst ein Befund. Wer die Lage sp\u00e4ter gegen\u00fcber Aufsicht oder Kunden erkl\u00e4ren muss, sollte genau diese L\u00fccke dokumentieren. Mittelfristig lohnt ein dauerhafter Export der Protokolle, bei dem Kosten und Lizenz abzuw\u00e4gen sind.<\/p>\n\n\n\n

    DSGVO: Wann Art. 33 und Art. 34 greifen<\/h2>\n\n\n\n

    Keine Rechtsberatung: Datenschutzbeauftragte und Rechtsberatung einbeziehen.<\/p>\n\n\n\n

    Eine Verletzung des Schutzes personenbezogener Daten muss nach Art. 33 an die Aufsichtsbeh\u00f6rde gemeldet werden, m\u00f6glichst binnen 72 Stunden, nachdem sie bekannt wurde. Das gilt nicht, wenn die Verletzung voraussichtlich nicht zu einem Risiko f\u00fcr die Rechte und Freiheiten der betroffenen Personen f\u00fchrt. Bei voraussichtlich hohem Risiko sind zus\u00e4tzlich die Betroffenen selbst zu benachrichtigen (Art. 34). Entscheidend ist also zweierlei: ob personenbezogene Daten betroffen sein k\u00f6nnen und ob Anhaltspunkte f\u00fcr einen Zugriff bestehen.<\/p>\n\n\n\n

    Blo\u00dfe Anmeldeaktivit\u00e4t im Protokoll ohne weitere Hinweise l\u00f6st keine automatische Meldung aus. Die Abw\u00e4gung und ihre Begr\u00fcndung sollten aber schriftlich festgehalten werden. Art. 33 Abs. 5 verlangt eine Dokumentation von Verletzungen, was auch den Fall einschlie\u00dft, dass nicht gemeldet wird. Anders liegt es bei Treffern: Eine erfolgreiche Anmeldung mit der Identit\u00e4t des Dienstes, unbekannte Rollen oder neue Secrets sind Anhaltspunkte, bei denen eine Meldung wahrscheinlich zu pr\u00fcfen ist.<\/p>\n\n\n\n

    Wann genau die Frist beginnt, h\u00e4ngt davon ab, wann der Verantwortliche \u201eKenntnis\u201c erlangt. Die Leitlinien 9\/2022 des Europ\u00e4ischen Datenschutzausschusses, abrufbar auf der Seite des EDSA<\/a>, behandeln diese Frage und den Begriff der hinreichenden Gewissheit. Im Zweifel ist dort nachzulesen, weil der Zeitpunkt \u00fcber die Rechtzeitigkeit der Meldung entscheiden kann. Zust\u00e4ndig ist die Aufsichtsbeh\u00f6rde des jeweiligen Landes. Wer sich fragt, ob eine Meldepflicht bei einer Datenpanne besteht, muss diese Pr\u00fcfung also auch ohne sicheren Datenabfluss vornehmen.<\/p>\n\n\n

    \n
    \n

    Muss ein Unternehmen den Vorfall der Datenschutzaufsicht melden, wenn ConnectWise Cloud Backup im Tenant registriert war?<\/h4>\n
    \n
    Nicht automatisch. Entscheidend ist, ob personenbezogene Daten betroffen sein k\u00f6nnen und ob es Hinweise auf einen Zugriff gibt, etwa erfolgreiche Anmeldungen der Dienst-Identit\u00e4t, unbekannte Rollen oder neue Secrets. Dann gilt grunds\u00e4tzlich die Meldung binnen 72 Stunden nach Kenntnis, es sei denn, ein Risiko f\u00fcr die Betroffenen ist unwahrscheinlich. Auch wenn nicht gemeldet wird, ist die Abw\u00e4gung zu dokumentieren. Der IT-Dienstleister muss den Verantwortlichen unverz\u00fcglich informieren.<\/div>\n <\/div>\n <\/div>\n\n <\/div>\n \n\n\n\n

    Eine Registrierung im Tenant allein ist also noch keine Verletzung. Sie verlangt aber eine Pr\u00fcfung, und diese Pr\u00fcfung ist ohne gesicherte Protokolle kaum m\u00f6glich. Damit schlie\u00dft sich der Kreis zum vorigen Abschnitt.<\/p>\n\n\n\n

    MSP und Auftragsverarbeitung: Wer muss wen informieren<\/h2>\n\n\n\n

    In einem typischen Szenario hat ein IT-Dienstleister die Backup-L\u00f6sung f\u00fcr den Kunden eingerichtet. Der Kunde ist dann Verantwortlicher im Sinne des Datenschutzrechts, der Dienstleister Auftragsverarbeiter, und der Backup-Anbieter gegebenenfalls Unterauftragsverarbeiter. Das ist ein \u00fcbliches Modell, aber keine Gewissheit, denn die Einordnung h\u00e4ngt vom Vertrag und der tats\u00e4chlichen Ausgestaltung ab.<\/p>\n\n\n\n

    Aus dem Gesetz folgt: Ein Auftragsverarbeiter meldet Verletzungen dem Verantwortlichen unverz\u00fcglich (Art. 33 Abs. 2) und unterst\u00fctzt ihn bei dessen Meldepflichten (Art. 28 Abs. 3 Buchstabe f). F\u00fcr die Meldung an die Aufsicht bleibt der Verantwortliche zust\u00e4ndig. Wie sich die Kenntnis des Auftragsverarbeiters auf die Frist des Verantwortlichen auswirkt, regeln die EDSA-Leitlinien. Sie sollten vor einer Entscheidung im Wortlaut gelesen werden.<\/p>\n\n\n\n

    F\u00fcr Kunden ergeben sich praktische Fragen. Hat der Dienstleister bereits informiert? Ist die Anwendung im Auftragsverarbeitungsvertrag oder in der Liste der Unterauftragnehmer genannt? Sind Meldewege und Fristen vertraglich geregelt? Wer diese Antworten nicht kennt, sollte sie jetzt einholen und die Anfrage dokumentieren.<\/p>\n\n\n\n

    F\u00fcr Dienstleister gilt die Empfehlung von ConnectWise: den eigenen Tenant und alle verwalteten Kunden-Tenants anhand des Leitfadens pr\u00fcfen, Kunden informieren und alles dokumentieren. ConnectWise betont nach Angaben von BleepingComputer, die Abschaltung des Dienstes sei kein Beleg f\u00fcr eine Kompromittierung einzelner Partner oder Kunden.<\/p>\n\n\n\n

    Die T\u00e4terfrage ist offen. ConnectWise nennt eine staatsnahe Gruppe unter Berufung auf Microsoft, eine unabh\u00e4ngige Best\u00e4tigung fehlt. F\u00fcr die Ma\u00dfnahmen spielt sie keine Rolle.<\/p>\n\n\n\n

    Was noch offen ist und was langfristig bleibt<\/h2>\n\n\n\n

    Offen sind derzeit mehrere Punkte:<\/p>\n\n\n\n