Bildquelle: Pexels / Foto-ID 3184292 / https://www.pexels.com/photo/3184292/ / CC0-Lizenz
Ein Projekt endet selten in dem Moment, in dem die letzte technische Aufgabe erledigt ist. In vielen Cloud-Umgebungen bleiben Rollen, Servicekonten, Gruppenmitgliedschaften und externe Zugänge noch offen. Die praktische Frage lautet deshalb nicht nur, wer die Ressource löscht. Die Frage lautet: Wer prüft Cloud-Zugänge, wenn ein Projekt endet?
Für ITSM-Teams ist das ein typisches Übergabethema. Während der Projektphase sind schnelle Freigaben oft sinnvoll, weil Teams bauen, testen und anpassen müssen. Nach der Abnahme ändert sich der Zweck. Was vorher Arbeitsfähigkeit war, kann im Regelbetrieb ein unnötiger Fremdzugang, eine unklare Admin-Rolle oder ein Servicekonto ohne Besitzer werden.
Cloud Governance beschreibt dafür keine einzelne magische Kontrolle. Microsoft ordnet Governance als laufende Disziplin ein, die Richtlinien, Verantwortlichkeiten und Betriebssteuerung verbindet. Identity Governance ergänzt diese Sicht, weil Zugriffe nicht dauerhaft nach Projektlogik weiterleben sollen. Auch AWS und Google beschreiben für Identitäten und Servicekonten klare Prinzipien: Rechte begrenzen, privilegierte Zugänge kontrollieren, langfristige Zugangsschlüssel vermeiden und Servicekonten sauber verwalten.
Der Projektabschluss braucht eine Rechtefrage
Viele Abschlusslisten fragen nach Dokumentation, Kostenstelle, Betriebshandbuch und offener Rechnung. Das ist wichtig, reicht aber nicht. Eine Cloud-Ressource kann sauber dokumentiert sein und trotzdem alte Zugänge behalten. Dann weiß der Betrieb zwar, dass der Dienst existiert, aber nicht, wer noch mit Projektrechten hineinwirkt.
Die bessere Abschlussfrage lautet: Welche Zugänge braucht der Dienst im Regelbetrieb wirklich noch? Daraus entstehen drei einfache Prüfgruppen. Erstens menschliche Benutzer und externe Dienstleister. Zweitens technische Identitäten wie Servicekonten, App-Registrierungen, Schlüssel und Tokens. Drittens Gruppen und Rollen, die indirekt Berechtigungen vergeben. Gerade diese dritte Ebene wird leicht übersehen, weil niemand mehr den einzelnen Projektnamen im Portal sieht.
Ein interner Link zur Betriebsrealität ist die Frage nach verwaisten Cloud-Ressourcen mit Besitzer und Löschfreigabe. Ohne Owner kann auch die Rechteprüfung nicht sauber entschieden werden. Ebenso hilft der Blick auf Cloud-Rechte nach Projektende, wenn Rollen nicht nur technisch, sondern organisatorisch bewertet werden müssen. Für die Zuordnung zum laufenden Betrieb ist außerdem relevant, welche Daten in der CMDB als Servicefragen gepflegt werden.
Owner, Dienst und Ablauf müssen zusammenstehen
Eine Rechteprüfung scheitert selten an fehlender Technik allein. Sie scheitert häufiger daran, dass drei Listen nicht zusammenpassen. Die Projektliste kennt Personen. Das Cloud-Portal kennt Rollen. Der Betrieb kennt Services. Wenn diese Sichten getrennt bleiben, wird aus einer einfachen Prüfung ein Suchspiel.
Darum sollte der Projektabschluss einen kleinen Ablaufplan enthalten. Der Service Owner bestätigt, welche Cloud-Ressourcen in den Regelbetrieb gehen. Der technische Owner bestätigt, welche Admin- und Betriebskonten nötig bleiben. Der Sicherheits- oder Governance-Ansprechpartner prüft, ob externe und privilegierte Zugänge noch begründet sind. Erst danach wird entschieden, was gelöscht, entzogen, reduziert oder befristet verlängert wird.
Wichtig ist die Reihenfolge. Wer zuerst löscht, riskiert einen Ausfall. Wer gar nicht entscheidet, riskiert offene Rechte. Der Ablaufplan verhindert beides. Er zwingt Teams nicht zu einer großen Auditübung, sondern zu einer klaren Entscheidung pro Zugang: bleibt, wird reduziert, bekommt ein Ablaufdatum oder wird entfernt.
Servicekonten brauchen mehr Aufmerksamkeit als Namenslisten
Menschliche Projektmitglieder sind vergleichsweise leicht zu erkennen. Schwieriger sind technische Identitäten. Ein Servicekonto kann nach einem Projekt weiter Daten übertragen, Deployments auslösen, Backups schreiben oder Monitoringinformationen lesen. Wenn niemand mehr den Zweck kennt, wird jede spätere Änderung riskant. Der Betrieb traut sich dann nicht zu löschen und lässt den Zugang bestehen.
Deshalb gehört zu jedem technischen Zugang eine kurze Betriebsnotiz. Welcher Dienst nutzt ihn? Welche Mindestrolle ist nötig? Wo liegt der Nachweis zur Freigabe? Wer reagiert, wenn der Schlüssel rotiert oder der Zugang gesperrt wird? Diese vier Punkte machen aus einem anonymen Konto eine betreibbare Identität.
Für den Service Desk ist das kein Detail aus der Cloud-Konsole. Wenn nach Projektende eine Störung entsteht, muss klar sein, ob ein Zugriff bewusst aktiv ist oder nur vergessen wurde. Ohne diese Antwort bleibt jede Sperrung eine Mutprobe.
Ein kleiner Check vor der Abnahme reicht oft
- Hat jede produktive Cloud-Ressource einen Service Owner und einen technischen Owner?
- Sind externe Projektkonten aus produktiven Rollen entfernt oder ausdrücklich befristet?
- Gibt es für Servicekonten einen Zweck, eine Mindestrolle und einen Verantwortlichen?
- Wurden dauerhaft hohe Rechte auf kleinere Betriebsrollen reduziert?
- Steht im Ticket, welche Zugänge entfernt, behalten oder mit Ablaufdatum versehen wurden?
- Kann der Betrieb die Entscheidung später ohne Projektteam nachvollziehen?
So wird der Projektabschluss kein zusätzlicher Papierprozess. Er wird zur Übergabe der tatsächlichen Verantwortung. Cloud-Zugänge sind dann nicht mehr nur eine technische Berechtigung, sondern ein prüfbarer Teil des Regelbetriebs.
Quellen und Einordnung: Microsoft Cloud Adoption Framework Governance, Microsoft Entra Identity Governance, AWS IAM Best Practices, Google Cloud Best Practices für Servicekonten. Stand der Quellenprüfung: 26.08.2026. Bildquelle: Pexels / Foto-ID 3184292 / https://www.pexels.com/photo/3184292/ / CC0-Lizenz
