Nur authentifizieren reicht nicht Identity- und Access-Management (IAM) im Fokus

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Arvato Systems

Keeper Security EMEA Ltd.

Ping Identity Inc.

Ping Identity Ltd.

IT-Infrastrukturen wachsen und werden immer heterogener. Zudem wachsen zwischen On-Premises-Lösungen und ausgefeilten Cloud-First-Strategien auch mehr und mehr hybride Umgebungen. Hier liegen Daten in der Cloud und Anwendungen laufen On-Premises oder umgekehrt – oder beides. Ein Problem begleitet alle drei Szenarien: wer auch immer im Netzwerk aktiv ist, muss zweifelsfrei identifiziert werden – aber wie?

Vor dem Hintergrund verschwimmender Grenzen zwischen On-Premises-, Cloud- und Hybrid-Szenarien entstehen mehr und mehr Fragen, wie „wo sind eigentlich die Grenzen des Netzwerks?“, „welche Geräte verbinden sich mit welchen Anwendungen?“ und „wer führt Aktivitäten eigentlich aus?“

All das sind Fragen im Bereich der digitalen Identität – und eines gleich zu Beginn: Obwohl nicht nur menschliche Individuen im Netzwerk Identitäten darstellen, sondern auch Geräte, Anwendungen, Websites und Co., ist es kein Fehler, hier beim Menschen anzufangen. Wer einen Software-Stack rund um das Thema Identity- und Access-Management (IAM) betrachtet, sollte also ruhig die Perspektive einnehmen, für die eine IAM-Plattform im Grunde auch steht: nämlich für die (keineswegs banale) Frage, wer was wann und warum tut.

Username und Passwort sind im Grunde völlig beliebige „Credentials“

Menschen handeln in ihren digitalen Umgebungen auf viele verschiedene Arten, um Ziele zu erreichen: eine VPN-Verbindung starten, um remote zu arbeiten, einen Kunden-Account öffnen, um online zu shoppen, und so weiter. Das gelingt dem Anwender selbst nicht allein – also helfen dabei andere digitale Identitäten: Smartphones, Tablets, VPN-Server etc. Damit diese richtig funktionieren und das tun, was der Anwender tatsächlich will, müssen die Identitäten einander „kennen“, sich vertrauen und zweifelsfrei miteinander interagieren können. Geht es beispielsweise um Anwendungen, die sensible Daten transportieren, Zahlungen abwickeln oder Ähnliches, ist es enorm wichtig, dass nur der identifizierte Anwender selbst handeln kann – und nicht eine Person, die sich als dieser Anwender ausgibt.

„Kennt“ ein System also einen Anwender nicht wirklich, sondern nur mehr oder weniger beliebige „Credentials“ wie Username und Passwort, stehen Tür und Tor offen für Identitätsklau – mit all seinen unabsehbaren Folgen. Datenverlust steht hier ebenso im Raum wie das Blockieren von Diensten, das Einschleusen von Malware und letztlich die Beschädigung der Reputation und des Kundenvertrauens.

Das Authentifizieren digitaler Aktivitäten durch aktive Eingaben wie Usernamen und Co. ist kein Identifizieren im wörtlichen Sinn. Es wird nur Zugang gewährt aufgrund einer Eingabe – die aber jeder vornehmen könnte, der diese Zugangsdaten kennt. Kommen dazu die klassischen „Multi-Faktoren“ der Authentifizierung, bewegt sich der Prozess schon eher in Richtung Identifikation. Zwar ist eine Zwei-Faktor-Authentifizierung (2FA), die außer den Zugangsdaten z.B. auch eine TAN auf einem weiteren Endgerät oder einen physischen Token abfragt, im Grunde noch immer nicht wirklich personenbezogen. Verlangt das Endgerät aber einen Fingerabdruck, um die TAN zu öffnen oder den angestoßenen Prozess überhaupt weiterzuführen, ist ein schwer kopierbarer, personenbezogener Faktor in den Access-Prozess eingebunden.

Zuerst wird der Identity-Provider angesteuert, dann ein Access-Token generiert

Doch wo beim Menschen Iris-Scan, Gesichtserkennung, Fingerabdruck, Voice-Recognition und Co. personenbezogene Sicherheit gewährleisten: was sind vergleichbare Patterns, wenn es um Netzwerkgeräte, Maschinen, Algorithmen und Co. geht? Allein die IP-Adresse und eventuell typisches Verbindungsverhalten scheinen eine relativ dünne Basis zu sein, um echte Identifizierung zu gewährleisten, die der eines menschlichen Anwenders entspricht.

Tatsächlich lässt sich eine sehr hilfreiche Verbindung herstellen zwischen menschlichen Personen, den Geräten, die sie nutzen, und beispielsweise den Diensten, die sie aufrufen. Dreh- und Angelpunkt ist dabei ein Identity-Provider, den menschliche Anwender über ihre Geräte ansteuern. Dieser handelt wie ein Agent, und das anfragende Gerät erhält einen Access-Token. Dadurch gibt es einen Directory-Zugang für das Individuum – ein Access-Manager gibt auf entsprechende Policies acht, und weitere Access-Tokens sind daraufhin an diesen Kontext gebunden.

Der identifizierte Anwender macht die Netzwerk-Komponente erst funktionsfähig

Zur Illustration: Wer sich zum Beispiel einen Restaurant-Herd mit IoT-Connection ansieht, stellt fest: Der Herd selbst kennt natürlich nicht die Muster und Kennzeichen des einzelnen, individuellen Kochs, der gerade am Gerät steht. Identifiziert sich der Koch jedoch über einen Identity-Provider, erhält er Access-Tokens, um den Herd überhaupt in Betrieb nehmen zu können. Das Gerät nimmt also seine Funktionsfähigkeit erst dann auf, wenn der Nutzer identifiziert ist.

Das muss (und soll) gar nicht das im Netzwerk verortete Gerät allein leisten. Der Herd wird zum Individuum innerhalb des Directorys erst aufgrund der Inbetriebnahme durch eine zweifelsfrei identifizierte Person. In deren Namen und Auftrag hat das Gerät dann verschiedenen Zugangsrechte zu APIs, zu Webverbindungen und so weiter – je nachdem, was dem einzelnen User zugeteilt ist; und zwar nicht nur rollen- sondern identitätsbasiert.

Über den Autor

Pascal Jacober ist Sales Manager DACH bei Ping Identity.

(ID:46640034)