Ihre ITSM-Plattform könnte das Einfallstor für einen Cyberangriff sein

Ihre ITSM-Plattform enthält personenbezogene Daten und ist mit Systemen im gesamten Unternehmen verbunden. Das macht sie zu einem Ziel, das ebenso geschützt werden sollte wie jedes andere geschäftskritische System. Eine aktuelle ServiceNow-API-Offenlegung ist ein guter Anlass, zwei Fragen zu stellen: Wer kontrolliert die Sicherheitsgrenze um Ihre Servicedaten, und wie weit kann ein einzelner Konfigurationsfehler reichen? Die Antworten hängen weniger vom Anbieter ab als von der Architektur.

Anfang Juni teilte ServiceNow seinen Kunden mit, dass ein Softwarefehler einige ihrer Daten über das Internet erreichbar gemacht hatte. Das Problem lag an einem einzelnen API-Endpunkt, der ohne Authentifizierung eingerichtet war, sodass Anfragen an ihn ohne Passwort oder Anmeldedaten möglich waren. ServiceNow hat die betroffenen Instanzen am 5. Juni gepatcht und die Endpunkt-Konfiguration so geändert, dass der Zugriff auf authentifizierte Benutzer beschränkt ist.

Öffentlichen Berichten zufolge war der betroffene Endpunkt /api/now/related_list_edit/create, der standardmäßig so konfiguriert war, dass er keine Authentifizierung erforderte. Sicherheitsteams, die nachforschten, fanden Anfragen an diesen Endpunkt von einer bestimmten IP-Adresse, was ihnen einen konkreten Anhaltspunkt für den Abgleich mit ihren Protokollen gab. ServiceNow erklärte, es habe ungewöhnliche Aktivitäten beobachtet und bei einem Teil der Kunden Hinweise auf erfolgreiche Abfragen von Instanztabellen festgestellt, und habe diese Kunden direkt benachrichtigt.

Ein wichtiges Detail sollte präzise benannt werden. ServiceNow hat inzwischen erklärt, dass es die Aktivität eher Sicherheitsforschern im Rahmen von Bug-Bounty-Arbeit zuschreibt als böswilligen Angreifern, und dass die Forscher angegeben hätten, keine Daten verwendet oder gespeichert zu haben. Es handelt sich also nicht um einen bestätigten Fall gestohlener Kundendaten. Was es eindeutig ist: ein nicht authentifizierter Endpunkt, der dem Internet ausgesetzt war – und der Berichten zufolge bereits im April erstmals gemeldet wurde, bevor die Meldung geschlossen wurde. Die Offenlegung bestand eine Weile, bevor sie behoben wurde.

Das ist der Teil, bei dem es sich lohnt zu verweilen, denn er gilt unabhängig davon, wer die Tür offen vorgefunden hat.

Warum das mehr bedeutet als ein einzelner Fehler

Eine ITSM-Plattform ist längst nicht mehr nur ein Ticketsystem. Sie enthält personenbezogene Daten, sie ist mit HR- und IT-Systemen verbunden, und sie steuert über eine wachsende Zahl von Integrationen automatisierte Workflows im gesamten Unternehmen. Schon Support-Tickets enthalten regelmäßig Passwörter, Schlüssel und Anmeldedaten. Das macht die Plattform zu einem hochwertigen Ziel, und es bedeutet, dass die Plattform als geschäftskritisches System mit der entsprechenden regulatorischen Compliance und Sicherheitslage geführt werden muss.

Sobald personenbezogene Daten im ITSM-Tool liegen, fallen diese Daten unter die DSGVO. Eine schwache oder ungemanagte API ist in diesem Kontext kein nebensächliches technisches Detail. Sie ist eine Offenlegung regulierter Daten – mit den Meldepflichten und dem Risiko, die damit einhergehen.

Die ehrliche Version der Lehre: ServiceNow ist eine leistungsfähige Plattform, die von Tausenden großen Organisationen genutzt wird, und Konfigurationsfehler können jedem Anbieter passieren. Die Frage für einen Käufer ist nicht, ob ein Anbieter jemals einen Fehler haben wird. Sie lautet, wie die Architektur den Schadensradius begrenzt, wenn einer auftritt, und wie viel Kontrolle der Kunde über seine eigene Zugriffsgrenze hat.

Wo die Architektur das Bild verändert

Genau hier kommt das Design der Plattform ins Spiel. In einem geteilten, mandantenübergreifenden SaaS-Modell kann ein einzelner falsch konfigurierter Endpunkt viele Kunden gleichzeitig betreffen, weil die Zugriffsgrenze vom Anbieter betrieben und verantwortet wird. Wenn auf Plattformebene etwas falsch eingestellt ist, bleibt die Offenlegung nicht auf eine Organisation beschränkt.

ITSM360 läuft vollständig innerhalb des eigenen Microsoft-365-Mandanten jedes Kunden. APIs werden über Microsoft-Entra-App-Registrierungen erreicht, wobei der Zugriff pro Kunde mit dessen eigener Client-ID und eigenem Client-Secret geregelt wird. Das ist eine Eins-zu-eins-Authentifizierungsgrenze statt einer geteilten. Eine Konfiguration im Mandanten eines Kunden erzeugt keine Offenlegung über eine geteilte Plattform hinweg, weil es keine geteilte Plattform gibt, die vor den Daten aller sitzt. Jeder Mandant ist seine eigene Grenze, kontrolliert vom Kunden.

Es bedeutet auch, dass die Zugriffskontrollen keine separate Schicht sind, die der ITSM-Anbieter aufbauen, absichern und patchen muss. Es sind dieselben Microsoft-Identitäts- und Sicherheitskontrollen, die die Organisation bereits über den Rest ihrer Umgebung betreibt: Entra, bedingter Zugriff, Audit-Protokollierung im Mandanten und das umfassendere Microsoft-Sicherheits- und Compliance-Framework. Für ein Sicherheitsteam ist die zu prüfende Oberfläche eine, die es bereits zu steuern weiß, statt einer separaten Anbieterumgebung mit eigenen Regeln.

Was das einem Sicherheits- oder Compliance-Team bietet

• Eine kundenspezifische Zugriffsgrenze. Endpunkte werden gegen die eigenen Client-Anmeldedaten jedes Mandanten authentifiziert, sodass ein Problem auf einen einzelnen Mandanten beschränkt bleibt statt auf eine geteilte Plattform.
• Daten, die im Mandanten bleiben. Servicedaten werden nicht in eine externe SaaS-Umgebung kopiert, was sie innerhalb des eigenen DSGVO- und Datenresidenz-Perimeters der Organisation hält.
• Governance über bereits vorhandene Werkzeuge. Zugriff, Protokollierung und bedingter Zugriff laufen über Microsoft Entra und die bestehenden Sicherheitskontrollen des Mandanten, nicht über ein parallel zu überwachendes System.

Das Fazit für alle, die ihr ITSM überprüfen

Wenn Sie eine ITSM-Plattform betreiben, sind die praktischen Schritte aus diesem Vorfall dieselben, die Sicherheitsteams ohnehin schon ergreifen: API-Zugriffsprotokolle prüfen, bestätigen, dass Endpunkte, die Geschäftsdaten verarbeiten, eine Authentifizierung erfordern, und Konfigurationsbefunde mit demselben Ernst behandeln wie Softwareschwachstellen. Nichts davon ist auf einen einzigen Anbieter beschränkt.

Die längerfristige Frage ist struktureller Natur. Da ITSM immer mehr regulierte Daten enthält und mit immer mehr Systemen verbunden ist, wird die Zugriffsgrenze darum herum Teil Ihrer Compliance-Lage. Es lohnt sich zu fragen, wer diese Grenze kontrolliert, wie weit ein einzelner Fehler reichen kann und ob die Sicherheit der Plattform etwas ist, das Sie selbst steuern, oder etwas, das Sie aus der geteilten Umgebung eines Anbieters erben. Das sind berechtigte Fragen für jede Evaluierung – auch für unsere.

So bleiben Ihre Servicedaten mit ITSM360 in Ihrem eigenen Mandanten

Ein kurzer Rundgang durch die Architektur, das Authentifizierungsmodell pro Mandant und wie es zu den Microsoft-Sicherheits- und Compliance-Kontrollen passt, die Sie bereits betreiben.

Quellen

• TechCrunch, „ServiceNow tells customers a bug left some of their data exposed to the internet" (10. Juni 2026)
• SecurityWeek, „ServiceNow Patches Vulnerability Exploited Against Some Customers" (10. Juni 2026)
• Grip Security, „ServiceNow Breach: 5 Key Things Security Teams Need to Know" (10. Juni 2026)