Der Bericht von PingCAP datiert den Widerruf und lässt Owner, Alter und Rotationshistorie der Zugangsdaten aus, deshalb lohnt es sich, die Durchführungsverordnung 2024/2690 gegen das eigene Register zu lesen.
Der Bericht von PingCAP datiert den Widerruf und lässt Owner, Alter und Rotationshistorie der Zugangsdaten aus, deshalb lohnt es sich, die Durchführungsverordnung 2024/2690 gegen das eigene Register zu lesen.
PingCAP begann am 7. Oktober 2026, gestohlene Zugangsdaten von Service-Accounts zu deaktivieren, löschte bis zum 10. Oktober weitere davon und meldete alle identifizierten per 14. Oktober als ungültig. Ich finde, im Eintrag einer Service-Identität sollte stehen, bevor ein solcher Ablauf beginnt, wer für die Identität einsteht, warum es sie gibt und was sie beenden würde. Das Konto einer Person bekommt vieles davon aus dem Arbeitsverhältnis. Ein Token bekommt es nur, wenn jemand es bewusst aufschreibt.
Ein Hinweis zur deutschen Fassung dieses Beitrags: Zitate aus der Durchführungsverordnung (EU) 2024/2690 folgen der amtlichen deutschen Fassung. Zitate aus dem Bericht von PingCAP und aus der ENISA-Guidance sind meine Übersetzungen aus dem Englischen; massgeblich ist das jeweils verlinkte englische Original.
Der Bericht von PingCAP vom 19. Oktober sagt, eine unbefugte Partei habe „gestohlene Zugangsdaten von Service-Accounts verwendet, um auf bestimmte interne Systeme von PingCAP zuzugreifen, Daten zu kopieren und Quellcode zu beschaffen“. Das genannte Zeitfenster reicht vom 9. September bis zum 7. Oktober 2026, also 28 Tage. Diese 28 Tage messen die gemeldete Nutzung. Der 9. September wird nicht als Datum des Diebstahls genannt.
| Datum (2026) | Was der Bericht sagt |
|---|---|
| Gestohlene Zugangsdaten von Service-Accounts in Gebrauch |
| „erhielt Kenntnis von dem Vorfall“ und „begann noch am selben Tag, die betroffenen Zugangsdaten zu deaktivieren“; ab diesem Datum „deaktivierte oder widerrief die meisten betroffenen Konten und Zugangsdaten“ |
| Bis 10. Okt. | „löschte weitere kompromittierte Zugangsdaten und entfernte übermässige Berechtigungen zwischen Cloud-Projekten“; zusätzliches Logging für Zugriffe auf Cloud-Speicher aktiviert, „in einem betroffenen Projekt“ |
| Externe Firma meldet vier Schwachstellen, alle bis 14. Oktober behoben; der Bericht stellt keine Verbindung zu den Zugangsdaten her |
| „alle identifizierten kompromittierten Zugangsdaten wurden ungültig gemacht, und die identifizierten unbefugten Zugriffswege wurden blockiert“ |
| Stichtag für die weiterhin laufenden Arbeiten, einschliesslich der kundenspezifischen Auswirkungen |
Eine externe Firma prüfte die Produktivsysteme von PingCAP und „fand keine Hinweise darauf, dass der Angreifer in den geprüften Systemen Befehle ausführte oder dauerhaften Zugriff aufrechterhielt“. PingCAP ergänzt, dies „ändert nichts an der Offenlegung von Daten“. Zu den exportierten Datensätzen gehörten Benutzernamen und E-Mail-Adressen, Text und Fehlermeldungen aus dem SQL-Editor, Kundenkontakte und die Abrechnungskonfiguration. Das bedeute, so PingCAP, „nicht, dass bei jedem Kunden jede Kategorie von Informationen offengelegt wurde“. Eine exportierte Tabelle „enthielt verschlüsselte API-Key-Werte von TiDB Cloud“. Der eine Wert im Besitz der Ermittler, den die externe Firma testete, „konnte nicht direkt als API-Key verwendet werden“, und ob weitere brauchbare Zugangsdaten offengelegt wurden, ist als offen aufgeführt. Per 19. Oktober erklärte PingCAP, betroffene Kunden zu benachrichtigen, „sobald wir die kundenspezifischen Auswirkungen festgestellt haben“. Per 3. November zeigte die Seite keinen späteren Stand.
Der Bericht sagt nicht:
Der Bericht zeigt also nicht, dass diesen Zugangsdaten ein Owner oder ein Leaver-Prozess fehlte. Der Vorfall ist der Anlass für diese Lektüre, und die Lektüre muss ohne diese Fakten bestehen.
Der Bericht sagt „service account credentials“ und nie „token“. Ich verwende „Token“ für die allgemeine Klasse von Zugangsdaten, die Sie vielleicht selbst halten: ein Geheimnis, das an ein System ausgegeben wird, damit es sich ohne anwesende Person authentifizieren kann. Welche Form die Zugangsdaten von PingCAP hatten, weiss ich nicht.
Die Durchführungsverordnung (EU) 2024/2690 legt technische und methodische Anforderungen für die Massnahmen nach Artikel 21(2) der NIS-2-Richtlinie, (EU) 2022/2555, fest. Ihr Anhang behandelt beide Arten von Identität zunächst gleich. Punkt 11.5.1 lautet: „Die betreffenden Einrichtungen verwalten den gesamten Lebenszyklus der Identitäten (Kennungen) der Netz- und Informationssysteme und ihrer Nutzer.“ Punkt 11.5.4 lautet: „Die betreffenden Einrichtungen überprüfen regelmäßig die Kennungen der Netz- und Informationssysteme und ihrer Nutzer und deaktivieren sie unverzüglich, falls sie nicht mehr benötigt werden.“
Getrennt werden die beiden Arten in Punkt 11.5.2:
b) die Nutzerkennung mit einer einzigen Person verknüpfen; >c) die Überwachung der Kennungen der Netz- und Informationssysteme sicherstellen;
Die Identität eines Nutzers führt auf einen einzigen Menschen zurück. Die Identität eines Systems führt auf Überwachung zurück, und Punkt (c) sagt nicht mehr als das. Wo die deutsche Fassung in 11.5.2(c) von Überwachung spricht, steht in der englischen oversight. Dasselbe deutsche Wort steht in der Überschrift von Punkt 3.2, „Überwachung und Protokollierung“, die englisch „Monitoring and logging“ lautet; die englische Fassung hält die beiden Begriffe also auseinander.
Die ENISA-Guidance zur Umsetzung (Juni 2025, Version 1.0) füllt einen Teil der Lücke. Sie empfiehlt für nicht-menschliche Identitäten eine „angemessen getrennte Genehmigung und unabhängige laufende Überwachung“ (S. 139). Ausserdem nennt sie für jede Art von Identität die Mindestfelder eines Inventareintrags (S. 138). Lesen Sie diesen Block als den Wechsel vom Eintrag einer Person zum Eintrag einer Service-Identität:
- person's name- username- start/stop dates+ department owner+ review date+ purpose level of privileges
Beide Listen sind Mindestangaben, also hindert nichts ein Team daran, einem Service-Eintrag ein Enddatum hinzuzufügen. Nach meiner Lesart benennt „department owner“ eine Abteilung, keine Person. Eine Abteilung kann nicht kündigen, was das Feld sauber hält. Sie kann bei der Überprüfung aber auch keine Frage beantworten.
Das Folgende ist meine Lesart, in keinem der beiden Texte steht es so. Nach Punkt 11.2.2(b) müssen die Einrichtungen sicherstellen, „dass die Zugangs- und Zugriffsrechte bei Beendigung oder Änderung des Beschäftigungsverhältnisses entsprechend geändert werden“. Diese Klausel betrifft Zugangs- und Zugriffsrechte, und auch für Nutzer ist 11.5.4 die Klausel zur Deaktivierung. Punkt 11.2.2(b) gibt dem Zugang einer Person trotzdem einen Anstoss von ausserhalb des Registers. Keiner der beiden Texte gibt einer Service-Identität einen entsprechenden Anstoss dafür, dass ihre eigene Arbeit endet. ENISA kommt dem stellenweise nahe, etwa mit einem Passwortwechsel „bei Beendigung oder Änderung des Beschäftigungsverhältnisses, wenn ein Nutzer Passwörter für Identitäten kennt, die aktiv bleiben (z. B. gemeinsam genutzte Identitäten)“ (S. 142), der ein Geheimnis ändert, während die Identität bestehen bleibt, und mit dem Rat, dass Dienstleister bei der Stilllegung die „Deaktivierung von Benutzer- und Service-Accounts“ berücksichtigen (S. 71), der nur den Ausstieg aus einer Lieferantenbeziehung abdeckt. Ansonsten beendet eine Service-Identität die Entscheidung „nicht mehr benötigt“ aus 11.5.4 oder ENISAs Beispiel, ruhende Identitäten „nach einer vorab festgelegten Anzahl von Tagen der Inaktivität, soweit unterstützt“ zu entfernen (S. 140). Die Überprüfung setzt ENISA „mindestens vierteljährlich“ an, bei Kleinstunternehmen jährlich.
Ich glaube nicht, dass ein Überprüfungsdatum ein Leaver-Ereignis ersetzt. Ein Leaver-Ereignis tritt ein, ob jemand ins Register schaut oder nicht, während ein Überprüfungsdatum eine Identität nur beendet, wenn jemand dieses Datum erreicht und entscheidet, dass die Identität nicht mehr benötigt wird. Deshalb muss die Verantwortung für eine Service-Identität bewusst zugewiesen werden. Ich vermute, die meisten ISMS haben das für ihre Tokens nicht getan. Eine Umfrage habe ich dafür nicht, nehmen Sie es also als Test für Ihr eigenes Register.
Nach Punkt 11.6.2(c) müssen die Einrichtungen „die Änderung von Authentifizierungsdaten zu Beginn, sodann in vorab festgelegten Zeitabständen und immer dann verlangen, wenn der Verdacht besteht, dass die Authentifizierungsdaten beeinträchtigt wurden“. Das ist eine Regel über Zugangsdaten (im Wortlaut der Verordnung: Authentifizierungsdaten), während es in 11.5 um Identitäten geht. Werden Zugangsdaten geändert, bleibt die Identität bestehen.
„Wenn der Verdacht besteht“ ist der Auslöser, an dem sich die Zeitleiste messen lässt. PingCAP erhielt am 7. Oktober Kenntnis und begann noch am selben Tag, Zugangsdaten zu deaktivieren. Wie es dazu kam, sagt der Bericht nicht, also zeigt nichts, wann zuerst ein Verdacht hätte entstehen können. Der Auslöser greift, sobald jemand etwas vermutet, und für die Tage davor hat er nichts zu bieten.
„In vorab festgelegten Zeitabständen“ braucht keinen Verdacht, darin liegt der Wert. Gegen gestohlene Zugangsdaten hilft das nur, wenn eine Änderung in das Nutzungsfenster fällt und der alte Wert danach nicht mehr funktioniert. Bei einem Intervall unter 28 Tagen fällt sicher eine Änderung in ein 28-tägiges Fenster. Bei einem längeren kann das so sein oder nicht, je nachdem, wann die letzte Änderung war. Punkt 11.6.2(c) nennt keine Länge, die Verordnung überlässt diese Wahl also der Einrichtung. Auch ENISAs Guidance zu diesem Punkt (S. 142-143) nennt keine, und sie ist auf Passwörter und Nutzer ausgerichtet.
Rotation setzt ausserdem voraus, dass sich der Diebstahl nicht wiederholt. Wenn das, was den alten Wert offengelegt hat, auch den neuen offenlegt, bringt das Intervall wenig. Der Bericht sagt nicht, wie diese Zugangsdaten gestohlen wurden, also kann ich nicht sagen, welcher Fall hier vorliegt. Unter den Arbeiten, die per 19. Oktober weiterlaufen, führt er „Expand credential rotation“ auf, also die Rotation von Zugangsdaten auszuweiten. „Expand“ deutet vielleicht darauf hin, dass es schon eine Rotation gab, aber der Bericht sagt das nicht, und ich behandle die Vorgeschichte als unbekannt.
Ein Inventar hält fest, wer für Zugangsdaten einsteht. Es sagt nichts darüber, wie sie genutzt werden. Ein Token mit benanntem Owner, frischer Überprüfung und klarem Zweck sieht im Register am ersten Tag der unbefugten Nutzung genauso aus wie am achtundzwanzigsten.
PingCAPs eigene Liste von Massnahmen weist in dieselbe Richtung. Hier steht jede Zeile, die ich zuordnen kann, neben dem Punkt des Anhangs, an dem ich sie messe. Das Deaktivieren und Löschen von Zugangsdaten habe ich weggelassen, weil das zur Reaktion auf den Vorfall gehört, auch wenn 11.5.4 ebenfalls von Deaktivierung spricht. Ebenfalls weggelassen habe ich „Zugriffskontrollen“ und „Code- und Secret-Scanning“, weil der Bericht zu wenig Details nennt, um sie einzuordnen.
| Zeile im Bericht | Punkt im Anhang | Anmerkung |
|---|---|---|
| „entfernte übermässige Berechtigungen zwischen Cloud-Projekten“ (bis 10. Okt.) | 11.2.2(a), „des Grundsatzes der Nutzungsnotwendigkeit (Need-to-use)“, zusammen mit Need-to-know und Aufgabentrennung | Begrenzt, was gestohlene Zugangsdaten erreichen |
| „zusätzliches Logging für Zugriffe auf Cloud-Speicher“ (10. Okt.) | 3.2.3(c), „Zugriffe auf Systeme und Anwendungen“ | Nur ein betroffenes Projekt |
| „Audit-Logging“ (laufend) | 3.2.3(c) und (d), „authentifizierungsbezogene Ereignisse“ | Die Liste steht unter dem Vorbehalt „Soweit angemessen“ |
| „Warnungen bei ungewöhnlichen Zugriffen und grossen Datenexporten“ (laufend) | 3.2.4, Protokolle, die „regelmäßig auf ungewöhnliche oder unerwünschte Trends überprüft“ werden, dazu Alarmschwellen | Der Bericht sagt nicht, ob es schon vorher Warnungen gab |
| „Rotation von Zugangsdaten“ (laufend) | 11.6.2(c) | Aktueller Stand unbekannt |
| Vier Schwachstellen (bis 14. Okt. behoben) | Keiner dieser Punkte | Der Bericht stellt keine Verbindung zu den Zugangsdaten her |
| Diebstahlsmethode, Alter der Zugangsdaten, Owner, Inventar | Keiner | Der Bericht schweigt dazu |
Wo die deutsche Fassung von 11.2.2(a) von Nutzungsnotwendigkeit spricht, steht in der englischen least privilege; im Folgenden heisst dieser Grundsatz Least Privilege.
Keine Zeile fällt auf 11.5. Ownership beantwortet, wessen Aufgabe Zugangsdaten sind. Least Privilege begrenzt, was gestohlene Zugangsdaten erreichen können, und in Logs und Alarmen könnte Missbrauch sichtbar werden. Ein Register, das das Erste leistet, kann die Berechtigungsstufe eines Tokens festhalten, aber es begrenzt sie nicht und achtet nicht auf Missbrauch.
Ich weiss nicht, ob ein besserer Eintrag die 28 Tage verkürzt hätte oder die Zeit zwischen dem 7. und dem 14. Oktober. Der Bericht sagt, dass alle identifizierten Zugangsdaten per 14. Oktober ungültig waren, nicht, wann die letzten ungültig wurden, und ich werde nicht raten. Falls Sie auf die Feststellung gehofft haben, dass fehlende Ownership diesen Vorfall verursacht hat: Der Bericht kann sie nicht stützen.
Ich verwende die Verordnung als Massstab für Ihr ISMS. Art. 1 wendet sie auf aufgelistete „betreffende Einrichtungen“ an, von DNS-Diensteanbietern bis zu Vertrauensdiensteanbietern. Anbieter von Cloud-Computing-Diensten stehen auf dieser Liste, und PingCAP verkauft eine Cloud-Datenbank. Nichts, was ich zitiert habe, sagt, dass PingCAP in den Anwendungsbereich fällt, und die territorialen Regeln habe ich nicht geprüft. Ich stelle weder fest, dass PingCAP erfasst ist, noch, dass es irgendeinen Punkt verfehlt hätte. Wenn Ihre Organisation keiner der aufgelisteten Arten angehört, ist sie keine betreffende Einrichtung nach Art. 1. ENISAs Felder haben noch weniger Gewicht. Die Guidance sagt über sich selbst: „Dieses Dokument ist nicht rechtsverbindlich und hat lediglich beratenden Charakter“ (S. 3). Ob etwas davon Sie bindet, ist eine Frage für Ihre Rechtsberatung.
Um daraus etwas zu lernen, müssen Sie nicht das ganze Register durchgehen. Eine echte Service-Identität genügt. Prüfen Sie sie gegen die vier Felder der ENISA und beantworten Sie dann die Frage, die diese Felder offenlassen: Was würde sie beenden?
In devguard gehört ein Organisations-Token der Organisation statt einer Person und trägt nur den Zugriff, den Sie beim Erstellen wählen; Owner, Zweck und Überprüfungsdatum bleiben in Ihren eigenen Aufzeichnungen: Organisations-Tokens.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird, ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird, ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.