Digitale Identität im Netzwerk Identity- und Access-Management (IAM) im Fokus

Anbieter zum Thema

Ping Identity Ltd.

Ping Identity Inc.

WatchGuard Technologies GmbH

Impossible Cloud GmbH

Zadara Ltd.

IT-Infrastrukturen wachsen und werden immer heterogener. Zudem wachsen neben On-Premises-Lösungen und ausgefeilten Cloud-First-Strategien auch verstärkt hybride Umgebungen. Dabei liegen Daten in der Cloud und Anwendungen laufen On-Premises oder umgekehrt. Problematisch dabei ist allerdings die digitale Identität.

Vor dem Hintergrund verschwimmender Grenzen zwischen On-Premises-, Cloud- und Hybrid-Szenarien tauchen immer mehr Fragen etwa nach den Grenzen des Netzwerks oder den Geräten auf, die sich sich mit Anwendungen verbinden. Auch die Frage, wer welche Aktivitäten ausführt, muss gestellt werden.

All das sind Fragen 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.

Credentials wie Username und Passwort

Menschen handeln in ihren digitalen Umgebungen auf viele verschiedene Arten, um Ziele zu erreichen: eine VPN-Verbindung starten, um remote zu arbeiten, oder einen Kunden-Account öffnen, um online zu shoppen. Das gelingt dem Anwender selbst nicht allein – also helfen dabei andere digitale Identitäten wie Smartphones, Tablets oder VPN-Server. 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 zum Beispiel 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 eine TAN zu öffnen oder den angestoßenen Prozess überhaupt weiterzuführen, ist ein schwer kopierbarer, personenbezogener Faktor in den Access-Prozess eingebunden.

Identity-Provider generieren Access-Tokens

Beim Menschen gewährleisten also beispielsweise Iris-Scan, Gesichtserkennung, Fingerabdruck oder Spracherkennung eine personenbezogene Sicherheit. Doch was sind vergleichbare Patterns, wenn es um Netzwerkgeräte, Maschinen oder Algorithmen 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.

Identifizierte Anwender machen Netzwerk-Komponenten 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 etwa zu APIs oder zu Webverbindungen – 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:46646940)