In Cloud- und Hybrid-Umgebungen sind technische Identitäten längst ein normaler Bestandteil des Betriebs. CI/CD-Pipelines benötigen Zugriff auf Repositories, Container-Registries, Deployment-Tools, Kubernetes-Cluster sowie Cloudressourcen. Dafür kommen Service Accounts, Tokens und Secrets zum Einsatz – häufig projektbezogen und ohne klar definierten Lebenszyklus.

Auch Plattformen bringen eigene Identitätsmodelle mit. Kubernetes nutzt Service Accounts, RBAC-Rollen, RoleBindings und ClusterRoleBindings. Clouddienste arbeiten mit IAM-Policies, Zugriffsschlüsseln, Shared Access Signatures und Workload-Identitäten. SaaS-Plattformen verwenden API-Tokens oder Integrationskonten. Dadurch entstehen zusätzliche Zugriffspfade neben dem zentralen IAM. Sie sind für den Betrieb notwendig, werden aber oft nicht so konsequent geprüft wie persönliche Benutzerkonten.

Hinzu kommen lokale Administratorkonten und Break-Glass-Accounts. Sie sollen Zugriff ermöglichen, wenn zentrale Identity Provider, SSO oder kritische Infrastrukturkomponenten ausfallen. Problematisch werden solche Konten, wenn sie dauerhaft aktiv bleiben, keinem Verantwortlichen zugeordnet sind oder nicht regelmäßig überprüft werden.

Vom Service Account zum Angriffspfad

Ein typisches Szenario findet sich in der Softwarebereitstellung. Eine Pipeline baut Container-Images, lädt sie in eine Registry und stößt Deployments in einem Kubernetes-Cluster an. Dafür nutzt sie einen Service Account mit einem Token, das als Secret in der Pipeline oder in einem externen Vault hinterlegt ist.

Das Risiko entsteht durch mehrere Faktoren gleichzeitig: fehlende Token-Rotation, Schreibrechte auf Registry- und Deployment-Ressourcen, zu weit gefasste RBAC-Berechtigungen und fehlende Kontrolle über die tatsächliche Nutzung. Wird ein Build-Runner kompromittiert oder ein Token offengelegt, entsteht daraus ein legitimer Zugriffspfad mit erheblichem Schadenspotenzial.

Ein Angreifer muss dafür kein persönliches Benutzerkonto übernehmen. Es genügt, eine technische Identität zu nutzen, die im System bereits als vertrauenswürdig gilt. Darüber lassen sich manipulierte Images in eine Registry laden oder Deployments mit verändertem Inhalt auslösen. Für API-Server oder die Orchestrierung wirkt der Vorgang zunächst wie ein regulärer Betriebsprozess.

Das Risiko liegt deshalb selten in einem einzelnen Konfigurationsfehler. Es entsteht durch die Kombination aus statischen Credentials, zu weit reichenden Berechtigungen, fehlender Verantwortlichkeit und einer unzureichenden Bewertung des Laufzeitverhaltens.

Typische Fehlkonfigurationen

In realen Umgebungen wiederholen sich häufig dieselben Fehlermuster. Besonders verbreitet sind überprivilegierte Accounts. Oft vergeben Administratoren Berechtigungen zu großzügig, weil granulare Rollenkonzepte fehlen oder im Betrieb als hinderlich wahrgenommen werden.

Ein zweites Muster sind statische Credentials. Tokens, Passwörter, SSH-Keys oder Cloud Access Keys bleiben über lange Zeit gültig. Gerade bei gewachsenen Automatisierungen ist oft unklar, welche Jobs oder Integrationen von einem bestimmten Secret abhängen. Die Rotation unterbleibt deshalb häufig aus Sorge vor Betriebsunterbrechungen.

Hinzu kommen fehlende Verantwortlichkeiten. Für technische Identitäten ist oft nicht dokumentiert, welchem Team sie gehören, wofür sie angelegt wurden und wann sie entfernt werden müssen. Auch lokale Administratorkonten und Notfallzugänge erhalten häufig nicht dieselben Schutzmaßnahmen wie zentrale Benutzerkonten, obwohl sie in Ausnahmesituationen weitreichende Eingriffe ermöglichen.

Ein weiteres Problem sind Altlasten. Ehemals benötigte Service Accounts, Integrationszugänge oder Partnerkonten bleiben bestehen, obwohl ihr ursprünglicher Zweck längst entfallen ist. Zwar existieren häufig Protokolle, auffällige Nutzungsmuster werden jedoch nicht systematisch ausgewertet.

Warum klassisches IAM an Grenzen stößt

Klassische IAM-Prozesse sind vor allem für personengebundene Identitäten ausgelegt. Technische Identitäten folgen diesem Modell nicht. Sie entstehen im Rahmen von Deployments, Integrationen, Automatisierung oder Plattformbetrieb. Sie sind an Workloads, Pods oder Services gebunden und verändern ihr Verhalten mit der Umgebung.

Ein Service Account kann zunächst nur Build-Prozesse ausführen und später zusätzlich Deployments oder API-Zugriffe übernehmen, ohne dass dieser Wandel in einem klassischen Benutzerlebenszyklus sichtbar wird. Deshalb reicht es nicht aus, lediglich zu prüfen, ob ein Zugriff grundsätzlich erlaubt ist. Zweck, Rechte, Laufzeit und tatsächliche Nutzung müssen weiterhin zusammenpassen.

Kontrolle beginnt mit Transparenz

Am Anfang steht eine vollständige Bestandsaufnahme. Unternehmen müssen sichtbar machen, welche technischen und lokalen Identitäten existieren. Dazu gehören Service Accounts, API-Tokens, Secrets, lokale Administratorkonten, Break-Glass-Zugänge und Workload-Identitäten.

Darauf aufbauend sollten Unternehmen unterschiedliche Regeln für Vergabe, Nutzung, Rotation und Prüfung definieren. Jede technische Identität sollte einem Verantwortlichen zugeordnet sein und einem klar definierten Zweck dienen.

Besonders wirksam ist die Reduktion statischer Credentials. Langlebige Secrets sollten, wo möglich, durch kurzlebige Tokens, automatisierte Rotation oder Workload-Identitäten ersetzt werden. Kubernetes zeigt diesen Wandel deutlich: Moderne Tokens werden über TokenRequest erzeugt, an konkrete Objekte gebunden und laufen nach einer definierten Zeit ab.

Ebenso wichtig ist eine konsequente Begrenzung der Berechtigungen. Service Accounts und lokale Konten sollten nur die Rechte erhalten, die für ihren konkreten Zweck erforderlich sind. In Kubernetes bedeutet das unter anderem, Service Accounts über RBAC und Namespaces möglichst eng einzuschränken.

Sensible Ressourcen wie Secrets oder ConfigMaps sollten nur ausgewählten Service Accounts zugänglich sein. Wiederholte API-Anfragen mit dem Statuscode 403 Forbidden können auf Aufklärungsversuche oder eine laufende Kompromittierung hindeuten. Solche Signale sollten nicht nur protokolliert, sondern auch aktiv ausgewertet werden. KI-gestützte Observability kann dabei helfen, API-Aufrufe, User Agents, Pod-Kontext und betroffene Ressourcen zusammenzuführen und ungewöhnliche Muster schneller zu erkennen.

Laufzeitverhalten kontinuierlich bewerten

Kontrolle endet nicht bei Inventar und Rechtevergabe. Entscheidend bleibt die laufende Bewertung der tatsächlichen Nutzung. Auffällig sind beispielsweise Zugriffe zu ungewöhnlichen Zeiten, neue Zielsysteme, zusätzliche API-Aktionen oder ungewohnte Registry-Zugriffe.

Eine belastbare Bewertung erfordert die Verbindung von Logs, Berechtigungen, Laufzeitkontext und betroffenen Ressourcen. Ein Log-Eintrag zeigt lediglich, dass etwas passiert ist. Erst der Kontext zeigt, ob dieses Verhalten erwartbar war. KI-gestützte Observability kann dabei helfen, Telemetrie, Audit Logs und Deployment-Metadaten automatisch zu korrelieren.

Fazit

Technische und lokale Zugänge sind ein normaler Bestandteil moderner IT-Umgebungen. Sie lassen sich nicht vermeiden, müssen aber sichtbar, zuordenbar und kontrollierbar sein – mit restriktiven Berechtigungen, kurzlebigen Zugangsdaten und einer kontinuierlichen Bewertung der tatsächlichen Nutzung. Sicherheit entsteht nicht durch zusätzliche Konten, sondern durch Kontrolle über Zweck, Berechtigungen und Kontext jeder technischen Identität. (ln)

Über den Autor: Bojan Magusic ist Director of Product Management bei Dynatrace.