IAM in Zeiten von KI: Kontrolle durch Technik, nicht durch Vertrauen

Für Bertram Dorn, Principal in the Office of the CISO bei AWS, steht fest, dass die Anforderungen an Identity and Access Management in den nächsten Jahren deutlich zunehmen werden – vor allem getrieben durch den Aufstieg von agentenbasierter KI. Der zweite Teil des Interviews beleuchtet die Rolle des Zero-Trust-Modells im modernen IAM, die Entwicklung von Föderation und Multi-Cloud-Umgebungen und die zukünftige Entwicklung des IAM.

Foto: Bertram Dorn

Herr Dorn, welche Rolle spielt das Zero-Trust-Modell im modernen IAM?

Zero Trust heißt ganz simpel: Ich vertraue niemandem – auch nicht, wenn er schon „im System“ ist. Nur weil jemand sich im gleichen Netzwerksegment befindet, darf er noch lange nicht auf meine Anwendung zugreifen. Jede Aktion wird individuell geprüft – basierend auf mehreren Merkmalen. Das können Zertifikate sein, Geräteinformationen, Standort oder Zeitfenster. Im Idealfall kombiniert man mehrere dieser Faktoren zu einer vertrauenswürdigen Entscheidung. Zero Trust lässt sich auf alle Ebenen übertragen – vom Netzwerkzugang bis zur API-Sicherheit. Bei AWS etwa wird jeder einzelne API-Call individuell signiert und geprüft – das ist Zero Trust in Reinform. Und auch physische Zugänge sollten nicht pauschal durch räumliche Präsenz erlaubt werden. Es geht darum, Vertrauen granular und dynamisch aufzubauen – nicht blind zu gewähren.

Wie sehen Sie die Entwicklung in Richtung Föderation und Multi-Cloud-Umgebungen?

Föderation, also das gegenseitige Vertrauen zwischen verschiedenen Identitätssystemen, ist essenziell, besonders in hybriden und Multi-Cloud-Umgebungen. Fast alle mobilen Apps, die wir heute nutzen, basieren auf solchen Föderationsmodellen etwa, wenn ein Nutzer sich mit seinem Google- oder Apple-Konto bei einer Drittanbieter-App oder -Website anmeldet.

Der große Vorteil: ein einziger Login verschafft Zugriff auf viele Systeme. Gleichzeitig steigen damit aber auch die Anforderungen an Sicherheit und Schlüsselmanagement. Tokens, die zu lange gültig sind, lassen sich kaum mehr zurückrufen – man müsste dann Blacklists führen und diese bei jeder Anfrage prüfen. Deshalb ist es wichtig, dass Tokens nur kurze Laufzeiten haben und dass die zugrunde liegenden Signaturschlüssel professionell geschützt werden.

Welche technologischen Standards haben sich hier etabliert?

Auf Infrastrukturebene haben sich signaturbasierte Verfahren wie SIGv4 durchgesetzt – jeder API-Call wird einzeln abgesichert. Auf Anwendungsebene dominieren Standards wie OAuth2, OpenID Connect / Java Web Tokens. Diese ermöglichen Föderation, rollenbasierte Kontrolle und zeitlich begrenzte Autorisierung – sind aber technisch komplex und fehleranfällig, wenn man sie nicht sauber implementiert. Das ist eine Aufgabe, die man besser nicht selbst übernimmt, sondern bewährten Anbietern überlässt.

Wie wird sich das Identity Management in Zukunft weiterentwickeln – etwa im Hinblick auf KI?

Bei agentenbasierter KI sprechen wir nicht mehr nur von Systemen, die Daten analysieren oder Inhalte zusammenfassen, sondern von digitalen Agenten, die im Auftrag von Menschen aktiv handeln. Ein Beispiel: Ich tippe „Flug nach Thessaloniki buchen“, der Agent versteht die Anfrage, prüft Optionen und führt die Buchung samt Kreditkartenzahlung eigenständig durch. Damit stellen sich völlig neue Fragen an das IAM: Wie autorisiere ich so einen Agenten? Welche Rechte bekommt er – und wie lange? Was darf er tun, was nicht? Und wie stelle ich sicher, dass er auch wirklich nur das ausführt, wofür er freigeschaltet wurde? 

Agenten brauchen kontextbezogene, temporäre Rechte ähnlich wie ein Mitarbeiter, der nur für eine bestimmte Aufgabe Zugriff erhält. Gleichzeitig muss jeder Zugriff nachvollziehbar und im besten Fall reversibel bleiben.

Denn eins ist klar: Auch wenn der Agent für mich handelt, darf er keine „Freilaufrechte“ bekommen. Er ist letztlich eine digitale Erweiterung meiner Identität – und sollte auch so behandelt werden.

Kann die Regulierung hier überhaupt noch Schritt halten?

Die technologische Entwicklung rund um generative und agentenbasierte KI ist extrem schnell. Regulierungsprozesse sind das in der Regel nicht. Aber: Es gibt Lichtblicke. Die EU etwa war beim Thema KI-Governance vergleichsweise früh dran – und nimmt weltweit eine Vorreiterrolle ein. Auch wir bei AWS beschäftigen uns schon seit langer Zeit sehr intensiv mit genau diesen Fragen. Etwa im Office of the CISO, wo ich tätig bin. Dort diskutieren wir Design-Patterns, mit denen sich Agenten sicher in bestehende IAM-Strukturen integrieren lassen – etwa über föderierte Identitätspools. Damit lassen sich Rechte gezielt, zeitlich begrenzt und aufgabenspezifisch vergeben. Und das alles auf Basis von Technologien, die sich bewährt haben – wie SIGv4, temporäre Tokens oder rollenbasierte Zugriffskontrolle. Kurz gesagt: Wir stellen sicher, dass die bestehenden IAM-Werkzeuge auch in einer Welt mit Agentic AI greifen. Wichtig ist dabei vor allem eines: Kontrolle durch Technik – nicht durch Vertrauen. Denn nur so bleibt IAM auch in Zukunft sicher.

Welche Rolle spielt AWS konkret bei der Absicherung von Identitäten – von der ersten Authentifizierung bis zur feingranularen Zugriffskontrolle über Dienste hinweg?

Bei AWS ist Identity and Access Management kein nachträgliches Sicherheitsfeature, sondern von Beginn an integraler Bestandteil der Architektur.

Jeder einzelne API-Call wird über das signaturbasierte Verfahren SIGv4 individuell authentisiert und autorisiert. Einen zentralen Signaturschlüssel gibt es bewusst nicht – denn auch hier gilt wieder: Was man nicht hat, kann man auch nicht verlieren. Auf Anwendungsebene setzen wir mit Cognito auf offene Standards wie OAuth2 und OpenID Connect. Jeder Kundenpool erhält dabei einen eigenen, geschützten Signaturschlüssel. Diese Trennung erhöht die Sicherheit erheblich und verhindert, dass ein einzelner Vorfall Auswirkungen auf andere Umgebungen hat. Auch auf Betriebssystemebene haben wir vorgesorgt: Über den AWS Systems Manager lassen sich Zugriffe IAM-basiert steuern – ohne dass man sich direkt am Betriebssystem anmelden muss. Ergänzend liefern Tools wie der Access Analyzer eine Übersicht über vorhandene Berechtigungen und helfen dabei, Fehlkonfigurationen frühzeitig zu erkennen. Und mit CloudTrail sowie GuardDuty bieten wir umfassendes Logging und Anomalieerkennung, etwa wenn ein Zugriff aus einem ungewöhnlichen Land erfolgt. AWS investiert seit Jahrzehnten massiv in IAM – und zwar in allen Schichten unserer „Esterházy-Schnitte“, von der Infrastruktur bis zur Anwendung. Denn wir wissen: Identität ist der Schlüssel zur Sicherheit.

it&d business Redaktion

Zum ersten Teil des Interviews über Risiken, häufige Stolpersteine und Benutzerfreundlichkeit beim IAM und über die Analogie zur Esterházy-Schnitte ...