Bildquelle: extern
Beim Go-live verschwinden Testzugänge selten von allein. Ein API-Schlüssel im Skript, ein Übergabetoken im Chat oder ein Testkonto im Fremdsystem wirkt nach der Abnahme wie ein Rest aus der Projektphase. Für den Betrieb kann genau dieser Rest zur offenen Nebenroute werden.
Ein API-Schlüssel ist ein technischer Zugang, mit dem Systeme automatisch miteinander sprechen. Er ersetzt nicht den Menschen am Login-Fenster, sondern erlaubt einem Programm, Daten abzurufen, Tickets zu schreiben oder Änderungen auszulösen. Für ITSM-Generalisten ist deshalb entscheidend: Solche Schlüssel gehören wie echte Zugänge in Inventar, Zuständigkeit, Ablaufdatum und Entzug.
Der Go-live beendet nicht automatisch die Testphase
Vor einem Start entstehen oft zusätzliche Zugänge. Entwickler brauchen einen schnellen Schlüssel für die Schnittstelle. Der Dienstleister bekommt ein Testkonto, um einen Import zu prüfen. Ein Automationsskript nutzt ein Token, damit die letzte Datenmigration nicht am Berechtigungskonzept scheitert. In der Projektlogik ist das nachvollziehbar. In der Betriebslogik wird es gefährlich, wenn niemand diese Hilfswege wieder schließt.
Das Risiko entsteht nicht nur durch böse Absicht. Häufig reicht schon Unklarheit. Ein Schlüssel liegt in einer alten Konfigurationsdatei, wird bei einem Repository-Wechsel mitkopiert oder bleibt in einem Monitoring-Job aktiv. Monate später weiß niemand mehr, wer ihn angelegt hat, wofür er gilt und ob er noch gebraucht wird. Genau dann wird aus einem kleinen Übergaberest ein Sicherheits- und Verantwortungsproblem.
Testschlüssel brauchen einen Besitzer
Ein technischer Zugang ohne Besitzer ist im Servicebetrieb schwer zu steuern. Wenn ein Alarm auf ungewöhnliche Nutzung hinweist, braucht der Service Desk eine schnelle Antwort: Gehört dieser Schlüssel zu einem produktiven Ablauf? Ist er Teil eines Lieferantenprozesses? Darf er Daten lesen oder Änderungen schreiben? Wer entscheidet, ob er sofort gesperrt werden kann?
Diese Fragen gehören nicht erst in den Sicherheitsvorfall. Sie gehören in die Abnahme. Jeder Testschlüssel sollte mindestens einen fachlichen Zweck, einen technischen Speicherort, einen verantwortlichen Owner, eine erlaubte Nutzung, ein Ablaufdatum und einen Entzugsweg haben. Fehlt einer dieser Punkte, ist der Zugang nicht betriebsreif.
Geheimnisse gehören nicht in Projektablagen
Die OWASP-Empfehlungen zur Geheimnisverwaltung betonen einen einfachen Grundsatz: Passwörter, Tokens und Schlüssel sollen nicht hart in Code, Tickets, Dokumenten oder Chatverläufen stehen. Sie brauchen dafür vorgesehene Speicher, Zugriffsbeschränkungen und Rotation. Für den Alltag bedeutet das: Ein Schlüssel, der während der Einführung schnell irgendwo abgelegt wurde, muss vor dem Start in den richtigen Verwaltungsweg oder weg.
Gerade in ITSM-Umgebungen ist diese Übersetzung wichtig. Der Service Desk muss keine Kryptografie im Detail verstehen, aber er muss erkennen können, dass ein technischer Schlüssel ein Zugang ist. Er sollte deshalb im Berechtigungsprozess ähnlich behandelt werden wie ein Benutzerkonto mit besonderer Wirkung.
Rotation ist kein reiner Security-Termin
Schlüsselrotation heißt, einen alten Schlüssel durch einen neuen zu ersetzen und den alten danach ungültig zu machen. Das klingt nach Spezialaufgabe der Sicherheitsabteilung, ist aber auch ein Betriebsprozess. Wenn ein Schlüssel in einem produktiven Ablauf steckt, kann eine unkoordinierte Sperre eine Schnittstelle stoppen. Wenn er nicht rotiert wird, bleibt ein alter Projektzugang vielleicht unnötig lange nutzbar.
Deshalb braucht Rotation einen kleinen, aber klaren Ablauf. Vor dem Go-live wird geprüft, welche Schlüssel aus Test, Migration und Lieferantenunterstützung existieren. Danach wird entschieden, welche davon produktiv neu erstellt werden, welche sofort auslaufen und welche nur mit dokumentierter Ausnahme weiterleben dürfen. Der Service Desk braucht die Information, welcher Ausfall sichtbar würde, falls ein Schlüssel gesperrt wird.
Die Abnahme muss aktive Reste suchen
Ein guter Prüfpunkt lautet nicht nur: Funktioniert der Service? Die bessere Frage lautet: Welche Hilfszugänge haben das Funktionieren ermöglicht und sind nach dem Start noch offen? Diese Suche kann pragmatisch bleiben. Projektordner, Deployment-Skripte, Schnittstellenlisten, Lieferantenübergaben, Testkonten, Automationsjobs und Dokumentationen werden auf aktive Schlüssel und Tokens geprüft.
Für jeden Fund sollte es eine Entscheidung geben. Löschen, neu als produktiven Zugang anlegen, befristet behalten oder als Ausnahme eskalieren. Eine Liste ohne Entscheidung hilft wenig. Erst wenn der Entzug oder die produktive Übernahme dokumentiert ist, ist der Punkt betrieblich sauber.
Lieferanten brauchen dieselbe Regel
Bei externen Dienstleistern ist die Gefahr besonders groß. Ein Anbieter erhält während der Einführung temporäre Zugänge, damit die Zusammenarbeit schnell läuft. Nach dem Start wandert die Verantwortung in den Regelbetrieb, aber die Übergangszugänge bleiben technisch erreichbar. Hier muss der Vertrag nicht jedes Detail lösen. Wichtig ist ein gemeinsamer Betriebsnachweis: Welche Schlüssel nutzt der Anbieter noch, wer verwaltet sie, wann werden sie rotiert und wie wird der Entzug bestätigt?
Dieser Nachweis schützt beide Seiten. Der Auftraggeber kann ungewöhnliche Nutzung besser einordnen. Der Anbieter bekommt klare Grenzen und muss nicht auf alte Hilfswege zurückgreifen. Und im Störungsfall lässt sich schneller entscheiden, ob ein Zugang gesperrt werden darf oder zuerst eine produktive Abhängigkeit umgebaut werden muss.
Ein kleiner Prüfpunkt verhindert große Sucharbeit
Testschlüssel sind kein Randdetail für Spezialisten. Sie sind technische Türen in produktive Abläufe. Wer sie nach dem Go-live unkontrolliert offen lässt, erschwert Vorfallbearbeitung, Audit, Lieferantensteuerung und sicheren Betrieb. Wer sie vor dem Start aktiv sucht, dokumentiert und schließt, nimmt dem ersten Sicherheitsverdacht viel Hektik.
Der praktische Maßstab ist einfach: Kein Schlüssel ohne Besitzer, Zweck, Speicherort, Ablaufdatum und Entzugsweg. Wenn diese fünf Informationen fehlen, ist der Zugang nicht fertig übergeben. Erst dann wird aus dem Projektrest ein kontrollierter Betriebsbaustein oder er verschwindet rechtzeitig aus dem System.
Quellen und Einordnung: OWASP Secrets Management Cheat Sheet, NIST SP 800-63B Digital Identity Guidelines, CISA Secure by Design. Stand der Quellenprüfung: 08.07.2026. Bildquelle: Pexels, Foto-ID 5380642.
