Bildquelle: Pexels / https://www.pexels.com/photo/close-up-of-man-holding-access-card-over-reader-13657375/
Kurz gesagt Zugriffsrechte wirken im Alltag oft harmlos, solange niemand über sie stolpert. Genau darin liegt das Risiko. Ein Konto, eine alte Gruppenmitgliedschaft oder eine vergessene Ausnahme kann Monate später noch produktive Systeme berühren, obwohl die Rolle längst gewechselt hat. Für ITSM-Teams ist das kein reines Sicherheitsthema, sondern eine Frage von sauberem Betrieb, Zuständigkeit und nachvollziehbaren Änderungen.
Der Servicebetrieb sieht Zugriffe meist erst dann deutlich, wenn etwas nicht funktioniert. Ein neuer Mitarbeiter kommt nicht in ein Fachsystem, ein Dienstleister wartet auf Freigaben oder ein Ticket hängt zwischen HR, Fachbereich und IT. Die andere Seite ist leiser. Rechte bleiben bestehen, obwohl eine Person den Aufgabenbereich verlassen hat. Diese stillen Altlasten erzeugen selten sofort ein Ticket, aber sie vergrößern jeden späteren Vorfall.
Zugriffsverwaltung bedeutet, Konten und Berechtigungen über ihren gesamten Lebenszyklus zu steuern. Dazu gehören Anlage, Rollenwechsel, regelmäßige Prüfung und Entzug. Standards wie NIST SP 800-53 behandeln Account Management als Kontrollbereich, weil nicht nur die Anmeldung zählt, sondern auch Zuständigkeit, Genehmigung, Überwachung und rechtzeitige Deaktivierung.
Ein Rollenwechsel ist ein Betriebsereignis
Onboarding bekommt Aufmerksamkeit, weil neue Arbeit sichtbar blockiert ist. Offboarding bekommt Aufmerksamkeit, weil Austritte organisatorisch klar markiert sind. Dazwischen liegt der gefährlichere Alltag. Menschen wechseln Teams, Projekte, Standorte oder Dienstleisterrollen. Systeme ändern sich, aber die alten Gruppen bleiben oft stehen, weil niemand den Wechsel als Betriebsereignis behandelt.
Für IT Service Management ist dieser Punkt wichtig. Ein Rollenwechsel ist nicht nur eine Personalnotiz. Er verändert, wer auf welche Daten, Werkzeuge und Abläufe zugreifen darf. Deshalb gehört er in dieselbe Logik wie Änderungen an Services. Es braucht einen Auslöser, einen Verantwortlichen, eine Prüfung und einen Abschlussnachweis.
NIST macht Konten zu einer Führungsaufgabe
NIST SP 800-53 beschreibt beim Kontrollbereich AC-2, dass Organisationen Konten identifizieren, autorisieren, verwalten, überwachen und bei Bedarf deaktivieren sollen. Für Nicht-Spezialisten ist daran vor allem die Grundidee wichtig. Ein Konto ist kein technisches Detail, das nach der Erstellung von selbst sauber bleibt. Es ist ein laufender Betriebsgegenstand mit Besitzer, Zweck und Ablauf.
Diese Sicht verschiebt die Verantwortung. Die IT kann Konten technisch anlegen und entfernen. Sie kann aber nicht allein wissen, ob eine Fachrolle noch stimmt, ob ein Projektzugang weiter benötigt wird oder ob eine Ausnahme wirklich verlängert werden darf. Fachbereiche, Service Owner, HR und IT müssen deshalb an einem prüfbaren Ablauf hängen.
Zero Trust beginnt bei gepflegten Rollen
CISA beschreibt im Zero Trust Maturity Model Identität als zentralen Baustein. Die einfache Übersetzung lautet, dass Vertrauen nicht dauerhaft aus einem Netzstandort oder einer alten Freigabe entstehen soll. Zugriff muss zum aktuellen Kontext passen. Genau dafür braucht der Betrieb aktuelle Rollen, klare Gruppen und eine Prüfung, die nicht erst nach einem Sicherheitsvorfall beginnt.
Microsofts Überblick zur Identity Governance betont ebenfalls Lebenszyklusprozesse, Zugriffsprüfungen und privilegierte Zugriffe. Für ITSM-Generalisten steckt darin ein praktischer Auftrag. Berechtigungen dürfen nicht nur beim Start einer Tätigkeit funktionieren. Sie müssen auch beim Rollenwechsel schrumpfen, bei Projektende verschwinden und bei kritischen Rechten regelmäßig begründet werden.
Der Service Desk braucht bessere Signale
Der Service Desk kann Zugriffsprobleme nur gut bearbeiten, wenn er die richtige Lage sieht. Ein Ticket mit der Bitte um neuen Zugriff reicht nicht aus, wenn unklar bleibt, welche alte Rolle dafür wegfällt. Sonst entsteht ein Stapel aus Ergänzungen. Der Mitarbeiter bekommt neue Rechte, aber die alten bleiben im Hintergrund bestehen.
Besser ist ein Tickettyp, der Rollenwechsel ausdrücklich abbildet. Er fragt nicht nur nach dem neuen Zielsystem, sondern auch nach bisherigen Gruppen, Projektzugängen, Sonderrechten und befristeten Ausnahmen. So wird aus einer reinen Freigabe ein sauberer Übergang. Der Service Desk muss dafür nicht jede Fachentscheidung treffen, aber er braucht Felder, Zuständigkeiten und Eskalationswege.
Alte Rechte verstecken sich in Ausnahmen
Die schwierigsten Berechtigungen sind oft nicht die Standardrollen. Sie liegen in Sonderfällen. Ein Krisenzugang wurde für eine Migration geöffnet. Ein Dienstleister bekam temporär mehr Rechte. Ein Fachanwender durfte für einen Test direkt auf Daten zugreifen. Solche Ausnahmen sind im Moment nachvollziehbar. Sie werden riskant, sobald Ende, Zweck und Besitzer fehlen.
Ein guter Betriebsprozess behandelt Ausnahmen wie geliehene Werkzeuge. Sie haben einen Grund, eine Laufzeit und eine Rückgabe. Ohne Ablaufdatum muss eine Ausnahme regelmäßig neu bestätigt werden. Ohne Besitzer muss sie beendet werden. Ohne dokumentierten Zweck darf sie nicht dauerhaft weiterleben.
Praktische Prüffragen für den nächsten Rechtecheck
- Welche Konten haben keinen erkennbaren Besitzer mehr?
- Welche Gruppenrechte passen nicht mehr zur aktuellen Rolle?
- Welche privilegierten Zugänge wurden seit dem letzten Review nicht begründet?
- Welche Projekt- oder Dienstleisterrechte haben kein Enddatum?
- Welche Tickets vergeben neue Rechte, ohne alte Rechte abzufragen?
- Welche Service Owner bestätigen Berechtigungen wirklich fachlich?
Diese Fragen sind bewusst bodenständig. Sie verlangen keine perfekte Sicherheitsarchitektur am ersten Tag. Sie schaffen aber eine gemeinsame Sprache zwischen Service Desk, Identity-Team, Fachbereich und Management. Genau das fehlt häufig, wenn Zugriffsverwaltung nur als Admin-Aufgabe behandelt wird.
Die beste Kontrolle ist ein sichtbarer Lebenszyklus
Ein Rechteprozess muss nicht groß wirken, um wirksam zu sein. Er braucht eindeutige Ereignisse. Eintritt, Rollenwechsel, Projektstart, Projektende, längere Abwesenheit, Dienstleisterwechsel und Austritt. Zu jedem Ereignis gehört die Frage, welche Zugriffe hinzukommen, welche wegfallen und wer die Entscheidung bestätigt.
Danach braucht es einen einfachen Nachweis. Wurde der Entzug erledigt? Wurde die Ausnahme verlängert oder beendet? Wurde der Service Owner informiert? Wurde ein privilegiertes Konto überprüft? Diese Nachweise helfen nicht nur der Revision. Sie helfen auch im Störfall, weil schneller klar wird, wer was durfte und warum.
Fazit
Alte Zugriffsrechte sind kein Randproblem der Sicherheitsabteilung. Sie sind eine Betriebsaltlast, die aus unsauberen Übergaben, fehlenden Rollenwechseln und vergessenen Ausnahmen entsteht. Wer Konten als laufenden Servicebestandteil behandelt, senkt Risiko, entlastet den Service Desk und macht Änderungen nachvollziehbarer. Der wichtigste Schritt ist dabei nicht ein neues Werkzeug, sondern ein sichtbarer Lebenszyklus für jede Berechtigung.
