Bildquelle: extern
Ein Cloud-Projekt ist schnell abgeschlossen, wenn Anwendung, Datenbank oder Automatisierung produktiv laufen. Für den Betrieb beginnt dann aber eine zweite Aufgabe: Wer prüft, welche Rechte aus der Projektphase noch aktiv sind?
Cloud-Rechte sind Berechtigungen in Plattformen wie Amazon Web Services, Microsoft Azure oder Google Cloud. Sie legen fest, wer Ressourcen anlegen, Daten lesen, Systeme verändern oder Abrechnungen beeinflussen darf. Für ITSM-Generalisten ist daran nicht nur die Sicherheit wichtig. Entscheidend ist, ob aus temporären Projektzugängen dauerhafte Betriebsrisiken werden.
Projektende und Betriebsstart sind nicht derselbe Moment
In der Einführung einer Cloud-Lösung entstehen oft zusätzliche Rollen, Gruppen, technische Konten und Ausnahmerechte. Ein Integrator braucht Zugriff, ein Fachbereich testet Daten, ein Entwicklungsteam schaltet Protokolle frei, ein Administrator hilft beim Go-live. Diese Rechte sind in der Projektphase erklärbar. Nach dem Übergang in den Betrieb müssen sie aber erneut bewertet werden.
Der kritische Punkt liegt im Zuständigkeitswechsel. Das Projektteam denkt in Meilensteinen, der Betrieb denkt in dauerhaften Verantwortlichkeiten. Wenn dieser Wechsel nur über eine Abnahme oder ein Übergabeprotokoll läuft, bleiben Berechtigungen leicht außerhalb der normalen Kontrolle. Niemand fühlt sich zuständig, weil die Rechte einmal notwendig waren und danach nicht mehr auffallen.
Zu breite Rechte wirken erst spät wie ein Problem
Ein überflüssiger Cloud-Zugang verursacht selten sofort einen sichtbaren Ausfall. Genau deshalb ist er gefährlich. Er kann Datenzugriff ermöglichen, Kosten auslösen, Sicherheitsregeln verändern oder produktive Ressourcen löschen, ohne dass der Service Desk den Zusammenhang sofort erkennt. Das Risiko wächst leise, während die Anwendung nach außen stabil wirkt.
Cloud-Anbieter empfehlen deshalb das Prinzip der geringsten Rechte. Ein Nutzer, eine Gruppe oder ein Dienstkonto soll nur die Berechtigungen haben, die für die aktuelle Aufgabe wirklich nötig sind. Für den Betrieb heißt das: Projektrollen dürfen nicht automatisch zu Dauerrollen werden. Jede Ausnahme braucht einen Besitzer, ein Ablaufdatum oder eine bewusste Überführung in den Regelbetrieb.
Technische Konten brauchen denselben Blick wie Menschen
Bei Berechtigungsprüfungen wird oft zuerst an persönliche Konten gedacht. In Cloud-Umgebungen sind technische Konten aber mindestens genauso wichtig. Automatisierungen, Schnittstellen, Deployment-Pipelines, Monitoring-Werkzeuge und externe Dienstleister arbeiten häufig mit eigenen Identitäten. Diese Konten haben manchmal sehr weitreichende Rechte, weil sie während der Einführung schnell funktionieren mussten.
Nach Projektende sollte deshalb geprüft werden, welche technischen Konten weiter gebraucht werden, welche Schlüssel oder Geheimnisse rotieren müssen und ob eine Rolle zu allgemein formuliert ist. Ein Konto mit Schreibrechten auf viele Ressourcen kann für die Einführung praktisch gewesen sein. Im Betrieb sollte es meistens enger gefasst, protokolliert und einem klaren Service Owner zugeordnet werden.
Access Reviews gehören in den Betriebsprozess
Eine einmalige Bereinigung nach dem Go-live reicht nicht aus. Cloud-Landschaften ändern sich schnell. Neue Ressourcen, neue Teams, neue Dienstleister und neue Automatisierungen verschieben laufend die Berechtigungsbasis. Deshalb braucht der Betrieb einen festen Prüfpunkt, der nicht vom Gedächtnis einzelner Projektmitarbeiter abhängt.
Ein brauchbarer Access Review beantwortet einfache Fragen. Welche Rechte wurden seit Projektstart vergeben? Welche davon sind heute noch notwendig? Wer bestätigt die Notwendigkeit? Welche Rechte sind privilegiert? Welche Konten wurden lange nicht genutzt? Welche externen Zugriffe laufen noch? Welche Änderungen wurden seit dem letzten Review vorgenommen? Diese Fragen gehören in den Cloud-Betrieb, nicht in eine vergessene Projektablage.
Die Übergabe braucht eine Rechtebilanz
Für ITSM-Teams ist die Rechtebilanz ein praktisches Übergabeartefakt. Sie muss nicht jedes technische Detail erklären, aber sie muss die betrieblich wichtigen Punkte sichtbar machen. Dazu gehören Administratorrollen, Schreibrechte auf produktive Ressourcen, Zugriffe auf Protokolle und Backups, externe Dienstleister, technische Konten, Schlüsselrotation und offene Ausnahmen.
Diese Bilanz hilft auch dem Service Desk. Wenn später ein Vorfall, eine Kostenabweichung oder eine ungewöhnliche Änderung auftaucht, ist schneller klar, welche Identitäten überhaupt handeln konnten. Ohne diese Übersicht beginnt die Suche oft bei der Anwendung, obwohl der eigentliche Hebel in einer alten Cloud-Rolle liegt.
Ein Ablaufdatum verhindert dauerhafte Ausnahmen
Temporäre Rechte sollten nicht nur in einer Mail oder einem Ticket erwähnt werden. Sie brauchen ein sichtbares Ablaufdatum und einen technischen oder organisatorischen Wiedervorlagepunkt. Sonst wird aus einer Ausnahme ein stiller Standard. Besonders bei externen Beratern, Testzugängen, Migrationsrollen und produktionsnahen Administrationsrechten ist dieser Punkt entscheidend.
Der beste Zeitpunkt für diese Regel ist nicht erst der Audit. Sie sollte schon beim Erteilen der Rechte gelten. Wer eine Ausnahme genehmigt, legt zugleich fest, wer sie prüft und wann sie endet. So wird Berechtigungsmanagement vom Nachräumen zur Betriebsroutine.
Cloud-Betrieb braucht klare Eigentümer für Rechte
Am Ende ist die entscheidende Frage nicht, ob die Cloud-Plattform eine Berechtigung technisch anzeigen kann. Die entscheidende Frage lautet, wer im Betrieb dafür verantwortlich ist. Ohne Eigentümer werden alte Rechte nicht geschlossen, technische Konten nicht geprüft und Ausnahmen nicht erklärt.
ITSM-Teams sollten Cloud-Projekte deshalb erst dann als sauber übergeben betrachten, wenn die Rechtebilanz steht. Das schützt nicht nur vor Sicherheitsrisiken, sondern auch vor Kosten, Kontrollverlust und unnötigen Eskalationen. Ein produktiver Dienst ist erst dann wirklich im Betrieb angekommen, wenn seine Zugänge genauso bewusst gesteuert werden wie seine Verfügbarkeit.
Quellen und Einordnung: AWS IAM Best Practices, Microsoft Entra Access Reviews, Google Cloud IAM Sicherheitsgrundlagen, CIS Control 6 zu Access Control Management. Stand der Quellenprüfung: 14.07.2026. Bildquelle: Pexels, Foto-ID 5699456.
