Es ist entscheidend, IAM strategisch zu denken

Aus der Sicht von Bertram Dorn, Principal in the Office of the CISO bei AWS, ist IAM das Fundament moderner IT und wird zum zentralen Steuerungselement. Der erste Teil des Expert Interviews über Risiken, häufige Stolpersteine und Benutzerfreundlichkeit beim Identity and Access Management und über die Analogie zur Esterházy-Schnitte.

Foto: Bertram Dorn

Für Bertram Dorn ist Identity and Access Management keine technische Nebensache. Der Prinicipal in the Office of the CISO bei AWS nimmt es vielmehr zunehmend als zentrales Steuerungselement wahr – Insbesondere in der Cloud, wo alles virtualisiert und vernetzt ist: „Bei Amazon Web Services etwa ist IAM der einzige Service, mit dem wirklich alle Kunden laufend interagieren – direkt oder indirekt. Wenn man sich heute ein IT-System ohne Identity and Access Management vorstellen will, dann muss man schon weit zurückgehen – vielleicht 20, 30 Jahre – in eine Zeit, in der Abteilungen sich noch einen gemeinsamen PC geteilt haben, auf dem man ohne Anmeldung Dokumente verfasst hat. Selbst damals war das Thema Identität in irgendeiner Form schon präsent – etwa über Disketten, die man im eigenen Schreibtisch verwahrt hat.“

Heute sieht der AWS-Experte praktisch kein System mehr, das nicht eine Form von IAM benötigt: „Das gilt sogar für den privaten Streamingdienst daheim: Auch wenn ich mich nicht jedes Mal aktiv anmelde, habe ich das doch irgendwann zumindest einmal getan – das System weiß also, wer ich bin. “ Umso entscheidender ist es für ihn, IAM nicht nur operativ zu denken, sondern strategisch.

Herr Dorn, warum sollte Identity and Access Management heute als strategischer Bestandteil jeder IT-Architektur verstanden werden?

Die realen Sicherheitsvorfälle zeigen: Die überwiegende Mehrheit der Angriffe erfolgt über IAM-Schwachstellen, zum Beispiel bei Fehlkonfigurationen im IAM durch Nutzer. Das heißt: Es ist der Dreh- und Angelpunkt für Kontrolle, Vertrauen und letztlich Sicherheit. Wer dort sauber aufsetzt, reduziert sein Risiko massiv. Wenn hier irgendwo etwas schiefgeht, dann liegt das Problem in den meisten Fällen in der Weise, wie das IAM-System genutzt wird.

Was macht IAM aus technischer Sicht so anspruchsvoll?

IAM ist kein Monolith, sondern ein Schichtmodell – am besten veranschaulicht das der Vergleich mit der Esterházy-Schnitte: Jede Schicht steht für eine Ebene, auf der Identitäten verwaltet werden müssen. Ganz unten liegt das Betriebssystem oder sogar das Hardwaremanagement, darüber folgen Anwendungen, Infrastrukturverwaltung und föderierte Identitäten über verschiedene Systeme hinweg. Jede dieser Ebenen bringt eigene Regeln, Verfahren und Risiken mit sich. Und durch moderne IT-Architekturen wie Infrastructure-as-a-Service oder Platform-as-a-Service entstehen zusätzliche Schichten – etwa die Verwaltung der Cloud-Infrastruktur, die der Endnutzer gar nicht sieht, die aber IAM-seitig abgesichert sein muss. Die Herausforderung dabei ist: Der Bezug zu einer Person oder Maschine ist zwar immer das Ziel – aber wie man das technisch umsetzt, unterscheidet sich je nach Schicht deutlich.

Auf Betriebssystemebene gelten andere Mechanismen als in Anwendungen oder Cloud-Infrastrukturen, wo etwa temporäre Rollen oder signierte API-Aufrufe ins Spiel kommen. Viele dieser Ebenen greifen ineinander, was die Abstimmung und Konsistenz der Berechtigungen komplex macht. IAM braucht deshalb nicht nur technische Lösungen, sondern auch ein klares, durchgängiges Konzept.

Was sind in der Praxis die größten Stolpersteine bei der Implementierung von IAM-Systemen?

Einer der häufigsten Fehler ist der Glaube, Username und Passwort seien ausreichend. Zwar machen viele Unternehmen hier inzwischen mehr, zum Beispiel durch Zwei-Faktor-Verfahren oder den Einsatz von Hardware-Keys wie Yubikeys, aber nach wie vor sehen wir, dass unsichere Passwörter oder zu viele komplexe Regeln zu Stress führen und das wiederum neue Risiken eröffnet. Da werden Listen geschrieben, Passwörter unter Tastaturen geklebt oder in unsicheren Tools gespeichert – und das wiederum führt zu neuen Sicherheitsrisiken. Ein weiterer großer Fehler liegt auf der Autorisierungsseite: zu weit gefasste Rechte. Wenn ein Account pauschal „alles darf“, wird es gefährlich. Bei AWS sprechen wir etwa von Policies mit einem „Sternchen“ – also: Zugriff auf alles, überall, jederzeit. Das mag bequem sein, ist aber eine Einladung für Angreifer.

Wie lassen sich diese Risiken konkret vermeiden?

Erstens: Vermeiden Sie statische Zugangsdaten, wo immer es geht. Long-Lived Access Keys, die über Monate oder Jahre gültig sind, gehören zu den größten Sicherheitsrisiken überhaupt. Sie werden regelmäßig in Quellcode-Repositories – etwa auf GitHub – hochgeladen oder auf alten Datenträgern vergessen. Deshalb lautet die Devise: Was man nicht hat, kann man nicht verlieren. Arbeiten Sie stattdessen mit temporären Zugriffstokens, die nur für wenige Stunden gültig sind – am besten automatisch generiert über eine Rolle, die gezielt für eine Aufgabe vergeben wird. Zweitens: Setzen Sie auf rollenbasierte Zugriffskontrolle. Nutzer melden sich an und erhalten zunächst keine Rechte – erst durch das Wechseln oder temporäre Zuweisen von Rollen wird Zugriff ermöglicht. Und drittens: Kombinieren Sie Authentifizierungsfaktoren – etwa einen Yubikey als physisches Element mit einem PIN. Das verbindet etwas, das man hat, mit etwas, das man weiß – ein etablierter Sicherheitsansatz.

Wie schafft man es, trotz dieser Sicherheitsmaßnahmen benutzerfreundlich zu bleiben?

Man muss IAM so gestalten, dass sich der Nutzer in der Umgebung wohlfühlt. Denn sonst sucht er sich Abkürzungen. Wer sich durch Sicherheit blockiert fühlt, umgeht sie – und genau da beginnt das Problem.

Entwickler etwa brauchen geschützte, aber flexible Testumgebungen. Die sollten zwar keine sensiblen Kundendaten enthalten, aber dennoch so konzipiert sein, dass der Source Code als wertvolles Asset geschützt bleibt. Auch im Alltag sollten Authentisierungsverfahren flüssig funktionieren. Yubikeys oder Passkeys, kombiniert mit kurzen PINs, sind ein gutes Beispiel dafür: hohe Sicherheit bei gleichzeitig geringem Friktionspotenzial. Entscheidend ist, dass die eingesetzten Methoden zur Unternehmenskultur passen. Es gibt keine One-size-fits-all-Lösung, aber sehr wohl Best Practices.

it&d business Redaktion

Der zweite Teil des Interviews wird die Rolle des Zero-Trust-Modells im modernen IAM, die Bedeutung von Föderation und Multi-Cloud-Umgebungen und die zukünftige Entwicklung des IAM beleuchten ...