Darf ein internes Skript wirklich in die Produktion?

Ein internes Skript entsteht oft aus einem praktischen Problem. Jemand muss Logdateien bereinigen, Benutzerlisten abgleichen, einen Export vorbereiten oder einen wiederkehrenden Handgriff im Betrieb beschleunigen. Genau diese Nähe zum Alltag macht Skripte nützlich. Sie macht sie aber auch riskant, sobald ein Hilfsmittel still in produktive Abläufe hineinwächst und plötzlich Daten verändert, Berechtigungen nutzt oder Entscheidungen vorbereitet, ohne je wie Software behandelt worden zu sein.

Der Zweck entscheidet über die Freigabe

Der erste Prüfpunkt ist der Zweck. Ein Skript, das nur eine Liste ausliest, ist anders zu bewerten als ein Skript, das Benutzer sperrt, Daten löscht, Berechtigungen ändert oder Tickets automatisch schließt. Die Freigabe muss deshalb zuerst klären, was das Skript tun darf und was ausdrücklich nicht. Ohne diese Grenze entsteht ein gefährlicher Graubereich. Dann wird aus einem schnellen Helfer ein produktiver Mechanismus, dessen Reichweite niemand sauber beschrieben hat.

Danach folgt die Herkunftsfrage. Wer hat das Skript geschrieben, wo liegt die aktuelle Version, wer darf es ändern und wie wird verhindert, dass eine private Kopie produktiv weiterläuft? Solche Fragen wirken klein, sind aber im Störungsfall zentral. Wenn nach einem fehlerhaften Lauf niemand sicher sagen kann, welche Datei ausgeführt wurde, fehlt der Betriebsspur genau der Nachweis, den Service Management, Security und Revision brauchen.

Produktive Skripte brauchen eigene Rechte

Auch Zugangsdaten gehören früh auf den Tisch. Ein Skript sollte nicht mit persönlichen Adminrechten laufen, nur weil es beim ersten Test bequem war. Produktive Automatisierung braucht ein eigenes technisches Konto, passende Rechte, Protokollierung und eine klare Aussage, wer diese Rechte regelmäßig prüft. Das Prinzip der geringsten Berechtigung ist hier kein abstrakter Sicherheitsbegriff. Es verhindert, dass ein kleiner Automationsfehler mehr Systeme berührt, als für die Aufgabe nötig ist.

Ein weiterer Prüfpunkt ist der Fehlerfall. Was passiert, wenn eine API nicht antwortet, eine Liste leer ist, ein Dateiformat anders aussieht oder ein Befehl nur halb erfolgreich war? Gute Skripte brechen dann sichtbar ab, schreiben ein Protokoll und verändern keine Daten auf Verdacht. Schwache Skripte machen weiter, überspringen Fehler oder liefern eine Erfolgsmeldung, obwohl nur ein Teil der Arbeit erledigt wurde. Für den Service Desk wird das später zum Problem, weil Tickets und Nutzerfragen aus einer technischen Unklarheit entstehen.

Vier Nachweise reichen oft für den Anfang

Vor dem produktiven Einsatz braucht das Skript deshalb mindestens vier Nachweise. Erstens eine kurze Beschreibung von Zweck, Auslöser, Datenquellen und Zielsystemen. Zweitens einen Testlauf mit ungefährlichen Daten oder in einer getrennten Umgebung. Drittens eine Freigabe durch die Rolle, die den fachlichen Effekt verantwortet. Viertens eine Rückfallmöglichkeit, also ein Backup, ein Änderungsprotokoll oder einen klaren Weg, fehlerhafte Änderungen einzugrenzen. Diese Nachweise müssen nicht schwergewichtig sein. Sie müssen aber auffindbar sein.

Besonders heikel sind Skripte, die im Laufe der Zeit vererbt werden. Ein Mitarbeiter wechselt die Rolle, ein Dienstleister geht, ein Projekt endet, aber der Job läuft weiter. Dann fehlt oft die Person, die ursprüngliche Annahmen erklären kann. Deshalb sollte jedes produktive Skript einen Owner, einen Ablageort, einen Ausführungsplan und ein Ablaufdatum für die nächste Überprüfung haben. Wer keinen Owner findet, hat bereits ein Signal, dass das Skript nicht sauber produktionsreif ist.

Vererbte Automatisierung wird schnell zum Risiko

Für ITSM-Teams ist die richtige Frage daher nicht, ob interne Skripte erlaubt sind. Ohne kleine Automatisierungen wird Betrieb langsam und fehleranfällig. Die bessere Frage lautet, ab wann ein Skript nicht mehr private Arbeitshilfe ist, sondern Teil der produktiven Lieferkette. Spätestens dann gelten dieselben Grundregeln wie bei anderen Änderungen: Zweck klären, Risiko einschätzen, Rechte begrenzen, Test nachweisen, Lauf protokollieren und Verantwortung sichtbar machen.

So entsteht kein Bürokratieprojekt, sondern ein Schutz gegen stille Produktionsrisiken. Ein Skript darf in die Produktion, wenn seine Wirkung verstanden, seine Herkunft nachvollziehbar, sein Fehlerverhalten geprüft und seine Verantwortung geklärt ist. Fehlt einer dieser Punkte, ist nicht das Skript selbst das Problem. Das Problem ist der blinde Fleck im Betrieb.

Quellen und Stand

• CISA, Secure by Design, abgerufen am 11.07.2026: Secure by Design
• NIST, Secure Software Development Framework, abgerufen am 11.07.2026: Secure Software Development Framework
• OWASP, Secure Coding Practices Quick Reference Guide, abgerufen am 11.07.2026: Secure Coding Practices Quick Reference Guide
• SLSA, Supply-chain Levels for Software Artifacts, abgerufen am 11.07.2026: SLSA Specification