Wir haben über 2.000 Service Accounts und niemand weiß, wem sie gehören – Die Multi-Cloud-IAM-Krise, die niemand zugeben will

„Wir haben über 2.000 Service Accounts und niemand weiß, wem sie gehören" — Die Multi-Cloud-IAM-Krise, die niemand zugeben will

Es gibt eine bestimmte Art von Panik, die nur in großen Cloud-Umgebungen auftritt.

Sie passiert nicht am ersten Tag. Nicht einmal im ersten Jahr.

Sie passiert etwa im dritten Jahr. Nach der dritten Übernahme. Nach dem fünften Kubernetes-Cluster. Nachdem jemand fragt: „Moment … wie viele Service Accounts haben wir eigentlich?"

In diesem Fall?

Über 2.000 Machine Identities über AWS, Azure und GCP hinweg.

Kein zentrales Inventar.

Keine konsistente Rotationsrichtlinie.

Ein Mix aus IAM-Rollen, Service Principals, Workload Identities und Kubernetes-Pod-Identities.

Das ist nicht nur „etwas unordentlich". Das ist eine Governance-Zeitbombe.

Und die Rahmenbedingungen sind brutal:

Automatisierte Discovery von Machine Identities
Rotation ohne App-Ausfallzeit
Least-Privilege-Empfehlungen basierend auf tatsächlicher Nutzung
CI/CD-Integration (Jenkins, GitHub Actions)
API-first-Architektur
Keine Agents
Keine Codeänderungen
Keine Sechs-Monate-Wissenschaftsprojekte

Außerdem: kein PAM für Menschen. Das ist Machine-Identity-Lifecycle im großen Maßstab.

Hier bleiben die meisten Unternehmen still stecken.

Schauen wir uns an, was tatsächlich realistisch ist.

Die erste harte Wahrheit: Es gibt keinen magischen Einheitsknopf

Sie haben es bereits in Ihren Evaluierungen gesehen.

CyberArk? Mächtig. Teuer. Fühlt sich an, als würde man mit einem Panzer zu einem Messerkampf antreten.

HashiCorp Vault? Solide. Aber jemand muss es betreiben. HA-Cluster. Storage-Backends. Secret-Engines. Policy-Drift. Das ist ein Team, kein Tool.

Cloud-native Secrets-Manager wie AWS Secrets Manager und Azure Key Vault? Funktional, aber fragmentiert. Am Ende verwalten Sie drei verschiedene Control Planes.

Und genau diese Fragmentierung hat Sie hierher gebracht.

Die Branche hat noch keinen sauberen, herstellerneutralen „Multi-Cloud-Machine-Identity-Governor" hervorgebracht, der null Betriebsaufwand erfordert.

Was tun Unternehmen also tatsächlich?

Sie lösen es nicht mit einem einzelnen Produkt.

Sie lösen es mit Architektur.

Das Muster, das leise gewinnt: Statische Credentials abschaffen

Schauen Sie sich das stärkste Signal in der Diskussion an:

Workload Identity + Federation für Cross-Cloud-Aufrufe. Keine Keys oder statischen Credentials speichern.

Das ist keine Produktempfehlung. Das ist eine Strategie.

Statt:

Langlebige Access Keys rotieren
Secret Sprawl nachverfolgen
Passwort-Lebenszyklus verwalten

Eliminieren sie das Problem vollständig.

In Kubernetes bedeutet das üblicherweise:

OIDC-Federation nutzen
Workloads dynamisch Rollen übernehmen lassen
Kurzlebige Tokens über Clouds hinweg austauschen

AWS unterstützt das mit IAM-Rollen für Service Accounts.

GCP unterstützt Workload Identity Federation.

Azure unterstützt föderierte Credentials für Service Principals.

Wenn Sie das korrekt verdrahten, speichern Pods keine Credentials.

Sie fordern sie an.

Sie laufen ab.

Sie erneuern sich automatisch.

Keine Rotations-Ausfallzeit. Kein Agent. Keine Codeänderungen, wenn Sie bereits SDK-Standard-Credential-Provider verwenden.

Deshalb skaliert dieser Ansatz.

Aber was ist mit Discovery?

Hier wird es real.

Sie haben kein zentrales Inventar.

Bevor Sie die Rotation optimieren, brauchen Sie Sichtbarkeit.

Unternehmen gehen das auf drei Hauptwegen an:

1. Cloud-natives Inventar + Aggregation

Identitätsdaten abrufen aus:

AWS IAM
Azure Entra ID
GCP IAM
Kubernetes API

In eine zentrale Datenplattform einspeisen (auch etwas so Einfaches wie geplante Exporte in ein Warehouse).

Nicht glamourös. Aber es liefert Ihnen:

Eine Liste von Machine Identities
Role Bindings
Zeitstempel der letzten Nutzung
Angehängte Policies

Darauf können Sie Least-Privilege-Empfehlungen aufbauen.

Ist es Plug-and-Play? Nein.

Ist es schneller als eine massive PAM-Plattform auszurollen? Ja.

2. Policy-as-Code + Drift-Monitoring

Unternehmen, die auf API-first-Modelle setzen, behandeln IAM wie Infrastruktur.

Terraform State + Cloud-Logs + Nutzungsmetriken = Map der effektiven Berechtigungen.

Von dort aus:

Ungenutzte Aktionen identifizieren
Überprivilegierte Rollen erkennen
Automatisch Pull Requests mit reduzierten Policies öffnen

Es ist nicht vollständig autonom, aber es skaliert besser als manuelle Reviews.

Und es passt zu Ihrer Anforderung „API-first".

3. Identity-Graph-Tools (aufkommende Kategorie)

Es gibt eine neuere Klasse von Tools, die Identity Graphs über Clouds hinweg aufbauen.

Sie nehmen auf:

Rollenzuweisungen
Trust Policies
Federation-Beziehungen
Nutzungstelemetrie

Und zeigen dann:

Übermäßige Berechtigungen
Fehlkonfigurierte Cross-Cloud-Trusts
Ruhende Service Accounts

Diese sind leichtgewichtiger als vollständige PAM-Suiten und oft agentless.

Der Kompromiss? Sie sind in erster Linie Governance-Sichtbarkeitstools. Lifecycle-Automatisierung kommt manchmal erst an zweiter Stelle.

Warum sich Vault schwer anfühlt (und warum es manchmal trotzdem gewinnt)

Vault wird oft als „Betriebsaufwand" abgetan.

Und das ist es auch.

Aber der Grund, warum manche Unternehmen es trotzdem wählen, ist nicht die Secrets-Speicherung.

Es sind dynamische Credentials.

Vault kann:

Kurzlebige Datenbank-Credentials generieren
Temporäre Cloud-Access-Tokens ausstellen
TTL- und Erneuerungsrichtlinien durchsetzen

Wenn Sie bereit sind, es richtig zu betreiben, wird es zu einem Machine-Identity-Broker.

Aber das ist ein Commitment. Wenn Sie kein Personal dafür haben, wird es wehtun.

Das ist die eigentliche Trennlinie.

Nicht Features. Personelle Kapazität.

Die CI/CD-Integrations-Realität

Sie brauchen Jenkins- und GitHub-Actions-Integration.

Die meisten Unternehmen lösen das, indem sie:

OIDC-Federation von GitHub Actions in Cloud-Rollen nutzen
Jenkins dynamisch Cloud-Rollen übernehmen lassen
Statische CI-Credentials vollständig entfernen

Das reduziert:

Risiko von Credential-Leaks
Manuelle Rotationszyklen
Pipeline-Secret-Sprawl

Und es passt zu Ihrer Vorgabe „keine Codeänderungen".

Denn moderne SDKs unterstützen bereits umgebungsbasierte Token-Injection.

Was Unternehmen 2026 tatsächlich einsetzen

Hier die ehrliche Antwort:

Sie kombinieren:

Workload Identity Federation überall dort, wo möglich
Kurzlebige Credentials statt Rotation
Zentralisiertes Identity-Inventar-Reporting
Policy-Analytics-Tooling
Minimale Secret-Manager nur dort, wo Federation nicht möglich ist

Sie vereinheitlichen nicht alles unter einer Mega-Plattform.

Sie standardisieren Muster.

Die Verschiebung ist nicht „welcher Anbieter".

Sie lautet: „Wie eliminieren wir statische Machine Credentials?"

Was Sie wahrscheinlich nicht tun sollten

Nicht:

Versuchen, alle Secrets in sechs Monaten in einem Vault zu zentralisieren
Anwendungen zwingen, Authentifizierungsmuster zu ändern
Agents auf 2.000 Workloads ausrollen
Versuchen, jede IAM-Policy manuell richtig zu dimensionieren

So explodieren Zeitpläne.

Ihre Rahmenbedingungen sind klar.

Das Design muss sie also respektieren.

Wenn das meine Umgebung wäre

Bei über 2.000 Service Accounts über drei Clouds hinweg würde ich priorisieren:

Phase 1 (90 Tage):

Machine Identities über Clouds hinweg inventarisieren
Workload Identity Federation für neue Workloads aktivieren
Neue statische Credentials aus CI/CD entfernen

Phase 2 (nächste 90 Tage):

Langlebige Keys wo möglich durch föderierte Tokens ersetzen
Nutzungsbasiertes Policy-Trimming einführen
Dashboards für Identity-Ownership bauen

Phase 3:

Bewerten, ob eine leichtgewichtige Identity-Governance-Plattform Mehrwert bringt

Fällt Ihnen auf, was fehlt?

Ein massives Plattform-Rollout.

Denn Ihr eigentlicher Feind ist nicht fehlendes Tooling.

Es ist Wildwuchs.

Das unbequeme Fazit

Multi-Cloud-Machine-Identity-Governance ist kein Produktproblem.

Es ist ein Architekturproblem.

Unternehmen, die hier gewinnen:

Hören auf, Secrets zu rotieren, und fangen an, sie zu eliminieren
Hören auf, manuell zu zentralisieren, und fangen an, automatisch zu föderieren
Hören auf, in „alles in einen Vault" zu denken, und fangen an, in „Trust Exchange" zu denken

Die Zukunft ist nicht besseres Passwort-Rotieren.

Es sind weniger Passwörter.

Und die Teams, die das früh verinnerlichen?

Das sind diejenigen, die nicht mehr um 3 Uhr morgens aufwachen und sich fragen, welcher vergessene Service Account noch Admin-Zugriff auf Produktion hat.

Newsletter abonnieren