Maschinen-Identitäten: Die neue Challenge!

Die zunehmende Zahl von Machine Identities – auch als Non-Human Identities (NHIs) bezeichnet – bringt neue Aufgaben für IAM-Verantwortliche mit sich. Ihre Verwaltung ist nicht immer einfach, aber durchaus machbar. Mit den passenden Methoden und Werkzeugen lassen sich auch nicht-menschliche Identitäten zuverlässig steuern und kontrollieren. Wir werfen einen Blick hinein.

Klarheit schaffen!

Aber zunächst wollen wir noch die Relevanz klären. Denn sprechen wir von Identitäten stellt sich bei vielen ein klares Bild ein – von einem Menschen. Maschinen spielen keine Rolle, weil – so die Annahme – identitätslos. IAM-Experten wissen, dass das nicht der Wahrheit entspricht und Identitätsmanagement immer auch Machine Identity Management beinhalten sollte.

Und diese Gruppe an Identitäten wächst deutlich schneller als ihre menschlichen Pendants – schätzungsweise kann ein Faktor zwischen 5 und 80 als realistisch angenommen werden.

Die Fülle allein macht sie auf den ersten Blick schwer greifbar. Doch Hersteller und Anbieter haben die Notwendigkeit erkannt, NHIs ausreichend vor Angriffen zu schützen – mit findigen Tools, Technologien und Ansätzen.

Autorisierungs-Frameworks …

… wie AuthZEN, Open Policy Agent (OPA), XACML/ALFA oder Cedar ermöglichen eine feingranulare Zugriffskontrolle (Fine-Grained Access – FGA): Sie trennen die Autorisierungslogik einer Applikation vom eigentlichen Code, der die Business-Funktionen umsetzt, und ermöglichen die dynamische Durchsetzung von Richtlinien (Access Policies) auf der Grundlage von Attributen über den Benutzer (Attribute Based Access Control – ABAC), die Aktion, die Beziehungen zwischen Ressource und Akteur (Relationship Based Access Control – ReBAC) und dem Umgebungskontext (Context Based Access Control – CBAC). Ähnlich wie mit Single-Sign-On alles rund um Login/Logout aus der Anwendung ausgelagert wird, werden Zugriffsentscheidungen an externe Authorizer ausgelagert. Im Security-Model implementieren Authorizer den Policy Decision Point (PDP), während die Anwendung als Enforcement Point (PEP) die Entscheidung nur noch umsetzt.

Unsere umbrella.associates-Einschätzung: Dies erleichtert Definition, Pflege und Skalierung konsistenter Zugriffskontrollen über verschiedene Systeme hinweg. Wer heute eine neue Anwendung entwickelt sollte definitiv die Chance nutzen und auf externe Authorisierung setzen. Vielversprechende Standards wie OpenID AuthZEN ermöglichen Interoperabilität zwischen freien und kommerziellen Produkten und vielfältigen Möglichkeiten. Beim Refactoring existierender Anwendungen sollte das Prinzip „externe Authorisierung“ zumindest erwogen und genau geprüft werden – unter Security-Aspekten, aber auch auf Wirtschaftlichkeit.

Auch in anderen Produkten zum Schutz der Infrastruktur findet das Prinzip “external Authorization” zunehmend Einzug: Reverse-Proxies, Ingress- und API-Gateways, PAM- und Access-Control Produkten – sogar in KI-Komponenten wird an Implementierungen gearbeitet. Bei der Einkaufstour lohnt es sich genau hinzuschauen und Optionen zur Policy-Governance und Vereinheitlichung zu prüfen.

Kubernetes Secrets & Service Accounts …

… helfen dabei, sensible Informationen wie API-Keys, Berechtigungsnachweise und Zertifizierungen vom Anwendungscode und der Infrastrukturkonfiguration zu entkoppeln oder Maschinen-Identitäten mit dynamischen Token bereitzustellen. Allgemein sollte auf langlebige oder gar statische API-Keys verzichtet werden, da sie ähnliche Nachteile wie Kennwörter haben und in dynamischen Umgebungen schnell reagierenden Security-Prozessen im Weg stehen.

Unsere umbrella.associates-Einschätzung: Der Einsatz nativer Kubernetes-Mechanismen für Secrets und Service Accounts ist ein wichtiger Schritt, um Sicherheitsrisiken durch “Hardcoded Credentials” zu vermeiden und Maschinen-Identitäten sauber zu verwalten. Allerdings bieten die Standardfunktionen nur begrenzte Verschlüsselung und Rotationsmechanismen. Für produktive Umgebungen mit höheren Sicherheitsanforderungen lohnt es sich daher, zusätzliche Secret Management-Lösungen (z. B. HashiCorp Vault, External Secrets Operator zu integrieren.

Token-Schutz: PKCE und DPoP …

… sind Erweiterungen des OAuth2-Standards, die den Schutz von Autorisierungscodes und Tokens deutlich erhöhen.

• PKCE (Proof Key for Code Exchange) wurde ursprünglich für Mobile Apps entwickelt und verhindert, dass ein Angreifer Autorisierungscodes, die im Redirect-Flow abgefangen wurden, missbrauchen kann. Es sorgt dafür, dass nur der Client, der den Code angefordert hat, diesen auch einlösen kann.
• DPoP (Demonstrating Proof of Possession) ergänzt dies, indem Access Tokens an ein konkretes Client-Device gebunden werden. Selbst wenn ein Token abgegriffen würde, könnte es nicht von einem anderen Gerät oder Angreifer genutzt werden.

Gemeinsam gestalten PKCE und DPoP das weit verbreitete OAuth2-Verfahren deutlich robuster, indem sie zwei zentrale Angriffspunkte schließen: den Diebstahl von Autorisierungscodes und die Wiederverwendung abgefangener Tokens.

Unsere umbrella.associates-Einschätzung: Der Einsatz von PKCE ist heute Best Practice und sollte bei allen neuen OAuth-Implementierungen verpflichtend sein. DPoP ist zwar noch weniger verbreitet, gewinnt aber gerade für API- und Mobile-Szenarien an Bedeutung. Unternehmen profitieren hier vor allem dann, wenn Anwendungen sensible Daten oder kritische Transaktionen absichern müssen. Bestehende OAuth-Setups sollten überprüft werden – eine Nachrüstung ist meist mit überschaubarem Aufwand möglich und erhöht die Sicherheit signifikant.

Security-Events teilen …

… mit dem OpenID Shared Signals Framework (SSF) wird der kontinuierliche Austausch über Änderungen an Zugriffs- und IdM-Informationen zwischen Anwendungen und Security-Komponenten (wie SSO-IdPs, API-Gateways, Authorizern und dem IdM-Framework) ermöglicht. Dadurch basieren Security-Entscheidungen nicht mehr auf veralteten Login-Daten, sondern aufgrund aktueller Sicherheits- und Kontextbedingungen. Mit dem Continuous Access Evaluation Protocol (CAEP) werden Statusänderungen wie Login/Logout, MFA, Session-Revocation oder Geräte-Compliance in Echtzeit als Security Event Token zwischen vertrauten Komponenten geteilt und Zugriffe dynamisch angepasst.

Das RISC (Risk Incident Sharing and Coordination) hilft dabei Kontoübernahmen durch Credential Stuffing zu verhindern. Hierbei werden Warnungen zu kompromittierten Daten oder verdächtigen Aktivitäten ausgetauscht und so verbundene Konten geschützt.

Während CAEP & RISC die notwendigen Echtzeitsignale zur feingranularen Risikobewertung lieferen, schafft AuthZEN den Rahmen um diese als Kontext in dynamischen Zugriffsentscheidungen zu verwenden.

Unsere umbrella.associates-Einschätzung: SSF und AuthZEN sind insbesondere für NHI relevant, da diese permanent im Hintergrund agieren, dauerhaft laufen, häufig weitreichende Berechtigungen besitzen, deutlich schneller agieren — und immer mehr werden. Werden hier Kontexte oder Berechtigungen nicht kontinuierlich geprüft, entsteht ein hohes Risiko durch kompromittierte API-Keys.

CAEP und RISC ermöglichen eine höhere Automatisierung in der Abwehr: CAEP sorgt für unmittelbare Durchsetzung von Sicherheitsrichtlinien bei Maschinen- und Nutzeridentitäten, RISC ermöglicht eine schnelle, standardisierte Koordination bei Vorfällen über Unternehmens- oder Providergrenzen hinweg. Das reduziert die Reaktionszeiten massiv und verhindert Eskalationen.

Alle genannten Standards sind Schlüsselkomponenten, um Zero-Trust-Ansätze praktisch umzusetzen und Services widerstandsfähiger gegen Identitätsmissbrauch zu machen. Zeitgemäße Security-Produkte sollten diese auf ihrer Roadmap haben, um mittelfristig Anschluss im Security-Ökosystem zu finden und Context Based Access Control mit Echtzeitdaten zu versorgen.

Vaults und Secret Manager …

… sind Tools zur Verwaltung von Geheimnissen. In Cloud-Umgebungen übernehmen dies meist die nativen Dienste wie AWS Secret Manager, Google Cloud Secret Manager oder der Azure Key Vault. Darüber hinaus gibt es plattformunabhängige Lösungen wie HashiCorp Vault, CyberArk Conjur oder das Open-Source-Projekt OpenBao, die auch in hybriden oder Multi-Cloud-Umgebungen eingesetzt werden können.

Sie bieten jeweils unterschiedlich zugeschnittene, sichere, zentralisierte Möglichkeiten zur Speicherung und Kontrolle des Zugriffs auf vertrauliche Informationen wie Anmeldeinformationen/Credentials, API-Keys und auch Zertifikate (x.509v3). Damit helfen sie Unternehmen, sich von fest kodierten Passwörtern und anderen Credentials zu lösen und erleichtern die Verwaltung dieser Geheimnisse in einer Vielzahl von Umgebungen.

Unsere umbrella.associates-Einschätzung: Secret Manager und Vaults sind inzwischen Best Practice und sollten in jeder produktiven Umgebung eingesetzt werden. Sie reduzieren das Risiko kompromittierter Zugangsdaten erheblich, sind aber kein Allheilmittel. Insbesondere in hochdynamischen Cloud- oder Container-Umgebungen stoßen sie an Grenzen, da die Verwaltung statischer Secrets komplex bleibt. Aber Achtung: Ohne solide Planung kommt man hier durch die explodierende Anzahl der Endpunkte schnell von einigen hundert Euro in etliche tausend Euro pro Monat an Lizenzgebühren.

SPIFFE und Service Meshes …

… gehen über die Verwaltung bestehender statischere Geheimnisse hinaus und widmen sich den dynamischen Workload-Identitäten. Secure Production Identity Framework for Everyone (SPIFFE) ist dabei ein relativ neuer universeller Identitätsstandard für Workloads. Er stellt kryptografisch überprüfbare Identitätsinformationen aus und ermöglicht es Workloads, sich über Clouds oder Rechenzentren hinweg sicher gegenseitig zu authentifizieren. SPIFFE macht im Idealfall hartkodierte Geheimnisse komplett überflüssig und vereinfacht die Umsetzung von Zero-Trust-Architekturen durch die Automatisierung von Identitätsbereitstellung und -rotation. Im Grunde werden hier “hochsichere Wegwerf-Identitäten” verteilt und verwaltet. Durch diese “Einmal-Identitäten” werden Prozesse auf einen zeitlich stark eingeschränkten Security-Context limitiert und so das Schadenspotential durch z.B. ge-leakte Accesstoken gesenkt.

Service Meshes (Istio, Linkerd, Teleport) sichern und verwalten die Kommunikation zwischen Diensten und automatisieren die Erkennung, Authentifizierung und Durchsetzung von Richtlinien (Access Policies). Sie betten Identität, Authentifizierung und Autorisierung direkt in den Netzwerkverkehr ein, sodass nur vertrauenswürdige Workloads miteinander interagieren können und verbessern dadurch Transparenz und Kontrolle in komplexen Systemen.

Unsere umbrella.associates-Einschätzung: SPIFFE und Service Meshes sind besonders interessant für Organisationen mit komplexen, stark verteilten Cloud- oder Container-Infrastrukturen. Sie bieten langfristig einen eleganten Weg, Secrets-Management durch dynamische Identitäten zu ersetzen. Der Reifegrad ist aber noch nicht in allen Branchen hoch; für bestehende Systeme ist der Umstieg aufwendig. Lohnend sind sie daher vor allem bei neuen Projekten, die von Beginn an auf Zero Trust setzen wollen.

Token-Austausch …

… ist die Möglichkeit, einen Satz von Berechtigungsnachweisen gegen einen anderen mit genau den richtigen Berechtigungen für eine bestimmte Aufgabe zu tauschen. OAuth 2.0 Token Exchange erlaubt es Anwendungen, Token auszutauschen und eine ursprüngliche Identität oder einen Geltungsbereich in eine neue, eng begrenzte Berechtigung umzuwandeln, die auf nachgeschaltete Systeme zugeschnitten ist. Das Risiko wird minimiert, indem nur die erforderlichen Berechtigungen zum richtigen Zeitpunkt erteilt werden – die Sicherheitslage bleibt selbst in komplexen Cloud-Umgebungen flexibel und jederzeit unter enger Kontrolle.

Unsere umbrella.associates-Einschätzung: Token-Austausch ist eine wirkungsvolle Maßnahme, um das Risiko von Privilege Escalations zu reduzieren. Er sollte insbesondere in Multi-Cloud- und API-lastigen Umgebungen eingesetzt werden, wo Identitäten oft durch viele Systeme “wandern”. Für Legacy-Architekturen ist die Integration jedoch meist komplex und ein Umstieg sollte, sofern er sich lohnt, gut vorbereitet werden. Generell sollte Token Exchange mittlerweile als Best-Practice angesehen werden und bietet sich somit bei neuen Projekten oder größeren Re-Designs an, wo eine feingranulare Rechtevergabe von Anfang an eingeplant werden kann.

Workload-Identitätsmanager …

… beispielsweise Astrix, Clutch, Entro, Oasis, Token Security oder Natoma verwalten Legacy- und statische Identitäten, indem sie Konten, statische Schlüssel und verschiedene Berechtigungsnachweise aufspüren. Sie verfolgen die Eigentümerschaft, unterstützen den Identitäts-Lebenszyklus, helfen bei der Rotation von Anmeldedaten und setzen Sicherheitsrichtlinien für diese Konstrukte durch.

Unsere umbrella.associates-Einschätzung: Haben Unternehmen noch viele statische Credentials im Einsatz, sollten sie diese Tools einsetzen – etwa in Legacy-Systemen oder in historisch gewachsenen Multi-Cloud-Umgebungen. Sie schaffen Transparenz und reduzieren Schatten-IT-Risiken erheblich. Langfristig sollten Unternehmen jedoch darauf hinarbeiten, statische Secrets durch dynamische Identitäten (zum Beispiel SPIFFE) oder Token Exchange zu ersetzen.

IAM für Mensch und Maschine

IAM muss mehr regeln als die Identitäten von menschlichen Benutzern – so viel ist klar. Doch was den optimalen Schutz für Ihre Maschinen-Identitäten bietet, lässt sich nicht pauschal beantworten. Die Optionen sind vielfältig, aber der Schutz muss maßgeschneidert sein. Andernfalls bleibt die Gefahr, etwas übersehen zu haben. IAM ist also immer individuell umzusetzen – für Benutzer und Maschinen!

Maschinen-Identitäten spielen in Ihrem Unternehmen eine Rolle? Dann lassen Sie uns über deren optimalen Schutz sprechen.

Jetzt Termin vereinbaren