Bildquelle: extern
Cloud-Zugänge verschwinden selten von allein. Wenn ein Projekt endet, bleiben Rollen, Schlüssel, Dienstkonten und Ausnahmen oft länger bestehen als die Menschen, die sie eingerichtet haben.
Für ITSM-Generalisten ist das kein Randthema der Cloud-Administration. Ein unklarer Zugang kann später bestimmen, wer eine produktive Umgebung verändert, welche Kosten weiterlaufen, welche Daten erreichbar bleiben und ob ein Sicherheitsvorfall überhaupt sauber eingegrenzt werden kann. Gerade deshalb gehört die Frage nach dem Besitzer eines Cloud-Zugangs in den Betriebsprozess, nicht nur in ein einmaliges Projektprotokoll.
Ein Cloud-Zugang ist mehr als ein Login
In Cloud-Umgebungen steckt Berechtigung nicht nur in persönlichen Benutzerkonten. Rollen, API-Schlüssel, Service Principals, Dienstkonten, Gruppenmitgliedschaften und automatisierte Deployments können ebenfalls Zugriff auslösen. Für den Alltag ist das praktisch, weil Teams nicht jeden Schritt manuell freigeben müssen. Für den späteren Betrieb wird es riskant, wenn niemand mehr sagen kann, warum dieser Zugriff noch existiert.
AWS empfiehlt in seinen IAM-Best-Practices, langfristige Zugriffsschlüssel zu vermeiden, Berechtigungen nach dem Prinzip der geringsten Rechte zu vergeben und nicht mehr benötigte Identitäten zu entfernen. Microsoft betont für Azure-Identitäten ebenfalls klare Zugriffskontrolle, Mehrfaktor-Authentisierung und regelmäßige Überprüfung. Google Cloud weist in seinen IAM-Empfehlungen darauf hin, Berechtigungen gezielt zu vergeben und Service Accounts kontrolliert zu nutzen. Die Grundrichtung ist bei allen gleich: Zugriff braucht Zweck, Begrenzung und Pflege.
Projektende ist ein gefährlicher Betriebswechsel
Während eines Projekts ist oft klar, wer handeln darf. Es gibt einen technischen Lead, eine Umgebung, eine Deadline und einen sichtbaren Zweck. Nach dem Go-live verändert sich die Lage. Das Projektteam löst sich auf, externe Dienstleister wechseln, Testumgebungen werden vergessen und Übergabedokumente werden nicht immer nachgeführt. Genau in diesem Moment wird aus einem legitimen Zugang ein Betriebsrisiko.
Der Fehler liegt selten in böser Absicht. Häufig fehlt nur ein verbindlicher Rückbauschritt. Ein Konto bleibt aktiv, weil eine Pipeline sonst nicht läuft. Ein Schlüssel bleibt gespeichert, weil niemand den Eigentümer findet. Eine Ausnahme bleibt in der Sicherheitsgruppe, weil sie beim Go-live geholfen hat. Monate später kann derselbe Zugang Kosten erzeugen, Daten freilegen oder einen Angriffspfad offenhalten.
ITSM braucht eine sichtbare Besitzfrage
Die wichtigste Frage lautet nicht zuerst, ob ein Zugang technisch funktioniert. Sie lautet: Wer besitzt ihn im Betrieb? Ein Besitzer ist nicht nur der Mensch, der ihn angelegt hat. Gemeint ist eine Rolle oder Stelle, die Zweck, Risiko, Laufzeit, Prüfung und Entfernung verantwortet. Ohne diese Zuordnung wird jeder Review mühsam, weil niemand entscheiden will, ob der Zugriff noch gebraucht wird.
Deshalb sollte jeder produktionsnahe Cloud-Zugang mindestens vier Angaben haben: fachlicher Zweck, technischer Umfang, verantwortliche Rolle und nächster Prüftermin. Besonders wichtig ist ein Ablaufdatum für projektbezogene Ausnahmen. Wenn ein Zugang wirklich dauerhaft gebraucht wird, muss er in den normalen Betrieb überführt werden. Wenn er nur für Migration, Test oder Einführung nötig war, muss sein Ende geplant sein.
Der Service Desk sieht die Folgen oft zuerst
Verwaiste Cloud-Zugänge fallen nicht immer im Security-Dashboard auf. Manchmal melden Fachbereiche unerklärliche Kosten. Manchmal scheitert eine Änderung, weil ein altes Dienstkonto noch in einer Automatisierung steckt. Manchmal sieht der Service Desk in einer Störung nur, dass niemand sicher weiß, welche Identität gerade produktive Ressourcen verändert hat. Dann wird aus Berechtigungsverwaltung ein Incident-Problem.
Ein guter Betriebsprozess verbindet deshalb Identity and Access Management, Change Management, Configuration Management und Kostenkontrolle. Neue Cloud-Zugänge sollten nicht nur genehmigt, sondern später wiedergefunden werden. Änderungen an Rollen und Schlüsseln sollten im Ticket sichtbar sein. Kritische Dienstkonten sollten einem Service, einer Anwendung oder einer Plattformverantwortung zugeordnet sein, nicht nur einem ehemaligen Projektnamen.
Reviews müssen konkrete Entscheidungen erzwingen
Ein Berechtigungsreview hilft wenig, wenn er nur eine lange Liste erzeugt. Er muss zu Entscheidungen führen. Bleibt der Zugang bestehen, wird er eingeschränkt, wird er umbenannt, wird er einem neuen Besitzer zugeordnet oder wird er entfernt? Ohne diese Entscheidungslogik verschiebt der Review das Problem nur in die nächste Runde.
Praktisch ist ein kleiner Ablauf: Cloud-Zugänge ohne eindeutigen Besitzer werden markiert. Projektbezogene Zugänge ohne aktuelle Begründung bekommen eine kurze Frist. Produktive Dienstkonten werden auf Anwendung, Service und verantwortliche Rolle abgebildet. Langfristige Schlüssel werden durch kurzlebige Verfahren ersetzt, wo das technisch möglich ist. Ausnahmen werden dokumentiert und nicht still weitervererbt.
Prüffragen für Cloud Operations und ITSM
- Welche Cloud-Rollen, Schlüssel und Dienstkonten stammen noch aus abgeschlossenen Projekten?
- Ist zu jedem produktionsnahen Zugang ein aktueller Besitzer erkennbar?
- Gibt es ein Ablaufdatum für projektbezogene Ausnahmen?
- Welche Zugänge haben weitreichende Rechte, obwohl ihr Zweck unklar ist?
- Wer entscheidet im Betrieb über Entfernen, Einschränken oder Überführen?
- Wird jede Änderung an kritischen Cloud-Zugängen im Ticket oder Change sichtbar?
Cloud-Betrieb wird nicht nur durch neue Plattformfunktionen stabiler. Er wird stabiler, wenn alte Zugänge einen klaren Lebenszyklus haben. Wer nach Projektende Besitzer, Zweck und Ablauf prüft, reduziert Angriffsflächen, unnötige Kosten und spätere Störungen. Der entscheidende Fortschritt ist oft unspektakulär: Jeder Zugang bekommt jemanden, der ihn wirklich verantwortet.
Quellen und Einordnung: AWS IAM Best Practices, Microsoft Azure Identity Management Best Practices, Google Cloud IAM Best Practices. Bildquelle: Pexels, Foto-ID 3205735. Stand der Quellenprüfung: 02.07.2026.
