Illustration Absmeier foto magnific ki

Hacker sind höchst einfallsreich, wenn es darum geht, sich Zugang zu internen Unternehmenssystemen zu verschaffen. Aktuell richten sie dabei ihr Augenmerk auf nicht-menschliche Cloud-Identitäten. Theus Hossmann*, CTO bei Ontinue gibt eine Übersicht über die aktuelle Gefahrenlage und nennt fünf Schutzmaßnahmen.

Management Summary

Machine Identities rücken ins Visier: Weil Unternehmen Benutzerkonten stärker absichern, konzentrieren sich Angreifer zunehmend auf Service Principals und andere nicht-menschliche Cloud-Identitäten.
Automatisierung verschärft das Risiko: Secret-Scanning-Tools durchsuchen Code, Repositories und CI/CD-Artefakte nach Zugangsdaten, prüfen deren Gültigkeit und verkürzen so die Zeit bis zum Missbrauch.
Secrets gehören aus dem Code: Unternehmen sollten hartcodierte Client IDs und Client Secrets durch Secret Vaults oder Managed Identities ersetzen.
Transparenz und Kontrolle sind Pflicht: Service Principals brauchen konsequentes Monitoring, minimale Berechtigungen sowie eine laufende Überwachung von OAuth- und Microsoft-Graph-Aktivitäten.
Entwicklungsprozesse müssen mitziehen: Nur abgesicherte CI/CD-Pipelines, Entwicklungsumgebungen und Deployment-Prozesse verhindern, dass sensible Zugangsdaten zum direkten Einfallstor werden.

Da viele Unternehmen große Mühen auf sich nehmen, um User Accounts vor Fremdzugriff zu schützen, fokussieren sich Hacker vermehrt auf nicht-menschliche Cloud-Identitäten, sogenannte Service Principals. Dafür verwenden Angreifer spezialisierte Secret-Scanning-Tools wie TruffleHog, um große Mengen an Quellcode, Git-Repositories, Konfigurationsdateien, CI/CD-Artefakten und Clouds systematisch nach exponierten Zugangsdaten zu durchsuchen.

Sie identifizieren aber nicht nur potenzielle Secrets anhand von Signaturen und Entropie-Analysen, sondern validieren Fundstellen aktiv gegen die jeweiligen Zielsysteme. Im Kontext von Cloud-Umgebungen erkennen diese Tools so offengelegte Client IDs und Client Secrets aus Microsoft Entra ID automatisiert und testen sie unmittelbar gegen OAuth-Authentifizierungsendpunkte. Gültige Anmeldedaten ermöglichen anschließend die Ausstellung legitimer Access Tokens, den Zugriff auf Cloud-Ressourcen sowie die Ausnutzung von Diensten und Berechtigungen.

Durch diese Automatisierung verkürzt sich die Zeitspanne zwischen der Offenlegung eines Secrets und dessen missbräuchlicher Nutzung erheblich. Die Folge: Service Principals werden zunehmend zu einem attraktiven Ziel für identitätsbasierte Angriffe. Ontinue, der Experte für Managed Extended Detection and Response (MXDR), nennt fünf Sicherheitsmaßnahmen, mit denen Unternehmen ihre Cloud-Identitäten schützen.

Maßnahme #1: Keine hartcodierten Secrets speichern

Häufig beginnt die Kompromittierung von Service Principals mit dem Speichern von Zugangsdaten im Klartext. Hacker finden Client IDs und Client Secrets von Microsoft Entra ID oft direkt in Konfigurationsdateien, Deployment-Skripten, CI/CD-Artefakten oder geklonten Repositories, die Unternehmen durch Unachtsamkeiten veröffentlichen – im Falle von Repositories etwa auf GitHub. Daher sollten Unternehmen keine Secrets fest in ihren Code-Basen speichern. Stattdessen empfiehlt sich der Einsatz von Secret Vaults, also speziell gesicherten Systemen für die zentrale Speicherung von Secrets, oder Managed Identities. Letztere sind von Cloud-Plattformen bereitgestellte Identitäten, mit denen sich Workloads gegenüber Cloud-Services authentifizieren können, ohne dass Entwickler Zugangsdaten wie Passwörter oder API-Schlüssel im Code hinterlegen müssen.

Maßnahme #2: Monitoring und Einschränkung von Service Principals

Da Hacker bei kompromittierten Service Principals reguläre OAuth-Authentifizierungsverfahren und gültige Zugangsdaten nutzen, wirkt deren Handeln oft wie legitime Cloud-Nutzung. Um solche Vorfälle zu erkennen, sollten Organisationen die Authentifizierung von Service Principals gezielt monitoren und auf ungewöhnliche Anmeldemuster oder verdächtige Zugriffe achten. Gleichzeitig sollten sie die in der Regel weitreichenden Berechtigungen von Service Principals massiv einschränken und ihnen nur so viel Freiraum lassen, wie sie für die Erfüllung ihrer Aufgaben benötigen.

Maßnahme #3: OAuth und Microsoft-Graph-Aktivitäten auditieren

Nach erfolgreicher Authentifizierung können Angreifer legitime Access Tokens beziehen und diese für den Zugriff auf Microsoft Graph APIs sowie Daten in SharePoint, Exchange oder OneDrive verwenden. Da diese Aktivitäten auf regulären Authentifizierungsmechanismen beruhen, bleiben sie häufig unauffällig. Eine gezielte Prüfung und Überwachung von OAuth- und Microsoft-Graph-Aktivitäten sind daher unbedingt nötig, um missbräuchliche Nutzung besser sichtbar zu machen.

Maßnahme #4: Transparenz über nicht-menschliche Identitäten herstellen

Ein zentrales und wiederkehrendes Problem besteht darin, dass Unternehmen selten eine hohe Visibilität über ihre nicht-menschlichen Identitäten haben. Das wirkt sich auch auf die Governance aus, die so deutlich hinter der für Benutzerkonten hinterherhinkt. Gleichzeitig übernehmen Service Principals wichtige Aufgaben in Cloud-Anwendungen und Automatisierungsprozessen. Unternehmen sollten daher möglichst vollständige Transparenz über Service Principals und andere nicht-menschliche Identitäten herstellen, um Risiken, Berechtigungen und potenzielle Missbrauchsszenarien besser bewerten zu können.

Maßnahme #5: CI/CD-Pipelines und Entwicklungsumgebungen absichern

Unsichere CI/CD-Pipelines, gemeinsam genutzte Entwicklungsumgebungen und Deployment-Prozesse sind die typischen Orte, an denen sensible Zugangsdaten offenliegen. Da Hacker heute automatisiert nach solchen Informationen suchen und deren Gültigkeit unmittelbar überprüfen können, kommt der Absicherung dieser Teile des IT-Ökosystems eine besondere Bedeutung zu.

»Maschinelle Identitäten oder Machine Identities sind längst zu einem Teil des Angriffsvektors geworden«, betont Theus Hossmann, Chief Technology Officer bei Ontinue. »Während die meisten Unternehmen ihre Sicherheitsmaßnahmen auf Benutzerkonten und Endpunkte konzentrieren, geraten Service Principals oft aus dem Blickfeld. Hacker wissen das natürlich und nutzen sie daher zunehmend, um einen direkten Weg in die Systeme von Unternehmen zu erhalten. Daher ist es heute umso wichtiger, den Schutz auf diese nicht-menschlichen Accounts auszuweiten.«

Theus Hossmann, Chief Technology Officer bei Ontinue (Quelle: Ontinue)

*Theus Hossmann, CTO bei Ontinue.

Theus Hossmann ist Chief Technology Officer (CTO) bei Ontinue, einem globalen Anbieter für AI‑gestützte MXDR‑ und Cybersecurity‑Services. Er prägt dort die technologische Ausrichtung des Unternehmens, insbesondere in den Bereichen AI‑Agents, Security Automation, Decision‑Throughput und moderne SOC‑Architekturen. Seine Beiträge zur Weiterentwicklung von „agentic“ Security‑Systemen machen ihn zu einer der prägenden Stimmen im europäischen Cybersecurity‑Technologiesektor.

Hossmann verfügt über mehr als 15 Jahre Erfahrung in Data Science, Machine Learning und Security Engineering. Vor seiner CTO‑Rolle leitete er bei Ontinue den Bereich Data Science. Zuvor war er bei Open Systems tätig und gründete als Chief Data Scientist das Unternehmen sqooba, das datengetriebene Produkte für verschiedene Industrien entwickelte. Frühere Stationen umfassen leitende Analytics‑Rollen bei Swisscom sowie Forschungsarbeit als Senior Researcher an der ETH Zürich, wo er auch seinen PhD in Computer Systems Networking & Telecommunications erwarb.

Er ist bekannt für seine klaren Analysen zu AI‑Automatisierung, SOC‑Modernisierung und der Rolle von organisationalem Wissen in KI‑Systemen. Seine Linkedin‑Beiträge werden in der internationalen Security‑Community breit rezipiert und gelten als Orientierung für CISOs, Engineering‑Teams und AI‑Security‑Strategen.

FAQ: Was Unternehmen beim Schutz von Machine Identities beachten müssen

Was sind Machine Identities und warum sind sie für Unternehmen sicherheitskritisch?

Machine Identities sind digitale Identitäten für Anwendungen, Dienste, Skripte, Container und Automatisierungsprozesse. In Microsoft Entra ID gehören dazu insbesondere Anwendungen, Service Principals und Managed Identities. Für Unternehmen sind sie sicherheitskritisch, weil sie häufig unbeaufsichtigt arbeiten, auf sensible Cloud-Ressourcen zugreifen und bei zu weitreichenden Berechtigungen einen direkten Angriffsweg eröffnen.

Welche Mindestanforderungen sollte eine Machine-Identity-Strategie erfüllen?

Unternehmen benötigen ein vollständiges Inventar aller Machine Identities, einen eindeutig zugeordneten fachlichen und technischen Owner, dokumentierte Zwecke und Abhängigkeiten sowie verbindliche Lebenszyklen. Hinzu kommen Least-Privilege-Berechtigungen, sichere Authentifizierung, zentrale Protokollierung, regelmäßige Rezertifizierung und die konsequente Stilllegung nicht mehr benötigter Identitäten.

Wie sollten Unternehmen Secrets in Code und CI/CD-Pipelines behandeln?

Secrets dürfen weder im Quellcode noch in Konfigurationsdateien, Logs, Repositories oder Build-Artefakten gespeichert werden. Unternehmen sollten Secret-Scanning in Entwicklungs- und Deployment-Prozesse integrieren, gefundene Zugangsdaten sofort als kompromittiert behandeln und widerrufen sowie verbleibende Secrets zentral in einem Vault verwalten und automatisiert rotieren.

Wann sind Managed Identities oder föderierte Identitäten die bessere Wahl?

Managed Identities sind für Azure-Workloads die bevorzugte Option, wenn der Zielservice Microsoft-Entra-Authentifizierung unterstützt: Azure verwaltet die Zugangsdaten und verhindert, dass Entwickler Secrets im Code hinterlegen. Für externe Workloads, etwa CI/CD-Systeme oder Multi-Cloud-Szenarien, eignet sich Workload Identity Federation, weil sie den Zugriff ohne dauerhaft gespeicherte Secrets ermöglicht.

Welche Berechtigungen sollten Service Principals erhalten?

Service Principals sollten ausschließlich die Rollen, API-Berechtigungen und Ressourcenzugriffe erhalten, die ihre konkrete Aufgabe erfordert. Unternehmen sollten breit angelegte Verzeichnis- und Microsoft-Graph-Rechte vermeiden, Berechtigungen möglichst eng auf Ressourcen und Aktionen begrenzen und privilegierte Zuweisungen regelmäßig überprüfen.

Welche Aktivitäten müssen Security-Teams überwachen?

Security-Teams sollten Anmeldungen von Service Principals, Token-Ausstellungen, OAuth-Zustimmungen, Microsoft-Graph-Aufrufe, Änderungen an Zugangsdaten und Rollen sowie Zugriffe auf sensible Cloud-Dienste überwachen. Warnsignale sind unter anderem neue Herkunftsorte, ungewöhnliche Zeiten, unerwartete Ressourcen, stark veränderte Zugriffsmuster und wiederholte fehlgeschlagene Authentifizierungen.

Wie lässt sich Machine-Identity-Governance organisatorisch verankern?

Eine belastbare Governance verbindet IAM, Cloud-Plattform, DevSecOps, SOC und Anwendungsverantwortliche. Verbindliche Richtlinien sollten festlegen, wer Identitäten anlegen darf, welche Authentifizierungsverfahren zulässig sind, wie Owner dokumentiert werden, wann Berechtigungen rezertifiziert werden und wie schnell verwaiste oder kompromittierte Identitäten gesperrt werden müssen.

Welche Kennzahlen zeigen, ob die Schutzmaßnahmen wirksam sind?

Geeignete Kennzahlen sind der Anteil inventarisierter Identitäten mit Owner, der Anteil secretloser Authentifizierungen, die Zahl überprivilegierter oder ungenutzter Service Principals, die Abdeckung durch Logging und Alarmierung, die Zeit bis zum Widerruf exponierter Secrets sowie die fristgerechte Durchführung von Access Reviews.

Wie beginnen Unternehmen pragmatisch mit der Umsetzung?

Der sinnvollste Einstieg ist ein risikobasierter 90-Tage-Plan: Zuerst erfassen Unternehmen alle Machine Identities und identifizieren privilegierte oder unbekannte Konten. Danach entfernen sie hartcodierte Secrets, reduzieren Berechtigungen und aktivieren Monitoring. Abschließend etablieren sie Owner, Rezertifizierungszyklen, Richtlinien und automatisierte Kontrollen für neue Identitäten.

1147 Artikel zu „Identity KI“

News | IT-Security | Künstliche Intelligenz | Produktmeldung

Saviynt stellt Identity-Plattform für KI-Agenten vor

25. April 2026

Neue Lösung ermöglicht Steuerung autonomer KI-Agenten über den gesamten Lebenszyklus – von der Erkennung bis zur Laufzeitkontrolle. Saviynt, Anbieter einer Identity-Security-Plattform, hat heute seine Lösung Saviynt Identity Security for AI vorgestellt. Die Lösung unterstützt Unternehmen dabei, autonome KI-Agenten vergleichbar mit menschlichen und maschinellen Identitäten zu verwalten: mit durchgehender Sichtbarkeit, Lifecycle-Governance und kontextbasierter Zugriffskontrolle in…