wladimir1804 - stock.adobe.com

Wo Identity Governance wirklich hingehört

Beim Thema Identity Governance ist es ratsam, zunächst zu prüfen, inwieweit die Voraussetzungen für eine umfassende Governance überhaupt gegeben sind und von wo diese ausgehen sollte.

Moderne IT-Ökosysteme sind hoch komplexe Gebilde. Die Digitalisierung hat die Zahl von Geräten, Benutzern und Daten in die Höhe getrieben, einschließlich von Multi-Cloud- und Remote-Umgebungen. Identity Governance and Administration (IGA) verspricht eine effiziente Verwaltung von Benutzeridentitäten und -zugriffen und somit mehr Transparenz und Kontrolle. Bei IGA geht es um Aufgabentrennung, Rollenverwaltung, Protokollierung, Analyse und Berichterstellung, kombiniert mit Identity Management.

Benutzer, Konten, Rollen, digitale Identitäten – und ihre Rolle im Governance-Konzept

Auch wenn es überraschend klingt: Für Firmen und Kunden sind die Begriffe „Benutzer/User“ und „Identität/Identity“ innerhalb des Identity-und-Access-Managements (IAM) und der Identity Governance und Administration (IGA) längst nicht so trennscharf abgegrenzt, wie man glauben möchte. Selbst unter Beratern herrscht zuweilen Verwirrung. Ohne eine klare Begriffsdefinition lässt sich allerdings kaum bestimmen, von wo die Governance ausgehen sollte. Gelegentlich tragen sogar die Produktnamen der Anbieter selbst dazu bei, die Grenzen zwischen Identity Management und Rollenverwaltung zu verwischen.

Ein Governance-Konzept sollte zwingend bei der Identität und nicht beim Benutzer beginnen. Dazu muss man zunächst den Unterschied zwischen Benutzer und Identität klären. Das geht nur, wenn man die typischen Akteure in einem modernen Unternehmensgebilde kennt. Die Zahl der digitalen Identitäten wächst exponentiell. Immer mehr Akteure brauchen Zugriff auf interne und externe Systeme und müssen innerhalb der Sicherheitsarchitektur berücksichtigt und verwaltet werden.

Das sind zum einen Menschen, also die eigene Belegschaft sowie eine Reihe von externen Dritten wie Berater, Partner, Lieferanten und weitere mehr. Dazu kommen Maschinen wie etwa Roboter und Dienste.

Die Governance allerdings sollte immer auf der Ebene der Menschen und der Identitäten angesiedelt sein. Hartnäckig hält sich die Meinung, dass interne Mitarbeiter vertrauenswürdiger sind als externe. Die Governance ist deshalb für Interne oft weniger streng geregelt als für Externe. Untersuchungen haben aber gezeigt, dass IT-Mitarbeiter, speziell Ingenieure, signifikant häufiger angegriffen werden als andere Mitarbeitende. Es ist also nicht der Beschäftigungsstatus einer Identität, der für einen Angreifer relevant ist, sondern vielmehr das eigentliche Tätigkeitsfeld im Unternehmen.

In diesem Zusammenhang sprechen wir von Menschen, Benutzern, Persona sowie von Maschinen, Identitäten und Konten. Als wäre die Zahl der Begriffe und ihre mangelnde Trennschärfe nicht schon genug, werden sie in verschiedenen Firmen unterschiedlich gebraucht. Dazu kommen nicht selten eigene Begriffsprägungen bis auf Abteilungsebene. Für eine umfassende Identity Governance braucht man jedoch eine einheitliche begriffliche Basis, bei dem ein und dasselbe Objekt einheitlich benannt und beschrieben wird.

Das klassische Identitätsmodell – Persona versus Rolle

Betrachten wir zunächst das klassische Identitätsmodell. Hier fungiert die Identität als höchster Objekt-Level, den man einer Person zuordnen kann. Sie kann mehrere Identitäten, eine plurale Identität oder auch eine oder mehrere Unternehmensidentitäten auf sich vereinen. Etwa, wenn verschiedene Verträge zugrunde liegen oder jemand interner Mitarbeiter in einem und externer Dritter in einem anderen Unternehmen ist. Dazu kommen soziale Identitäten wie etwa in LinkedIn, Facebook, Twitter und so weiter. Auch wenn sich soziale Identitäten als solche nicht kontrollieren lassen, sollte man sie innerhalb der Sicherheitsstrategie berücksichtigen. Ein vielfach zitiertes Beispiel ist TikTok. Die Betreiber der chinesischen Video-App-Plattform mussten einräumen, dass chinesische, brasilianische, kanadische, israelische sowie US-amerikanische Mitarbeiter Zugriff auf die Daten von Nutzern in der EU haben. Die vielfach in solchen Netzwerken preisgegebenen persönlichen Informationen werden dann an anderer Stelle für soziale Angriffe auf Unternehmensidentitäten genutzt.

Lösungen für das Privileged Access Management, Analysen des Benutzerverhaltens und Password Vaults dienen dazu, dieses Risiko für Unternehmensidentitäten zu senken. Fehlermeldungen werden an die Governance-Lösungen zurückgespielt und gefährdete Konten geschlossen. Auch wenn es wie eine Binsenweisheit klingt: Die Identität ist der neue Perimeter. Es reicht nicht aus, sich beim Thema Identitätssicherheit auf Unternehmensidentitäten zu beschränken. Ein und dieselbe Person verfügt über unterschiedliche Unternehmensidentitäten, die eng zueinander in Beziehung stehen. Dazu kommen weitere soziale Identitäten, die sich mittels diverser Angriffstechniken mit Unternehmensidentitäten in Verbindung bringen lassen.

Ein anderer Begriff, den es von dem der Rolle zu unterscheiden gilt, ist der der Persona. Von seiner ursprünglichen Verwendung ausgehend, bezeichnet Persona inzwischen unterschiedliche Konzepte in verschiedenen Bereichen. In der IT beziehungsweise der IT Security versteht man unter Persona eine archetypische Beschreibung von Usern, die deren Ziel(vorgaben) verkörpert – eine digitale Erweiterung des Individuums. Ein Begriff, der sich vor allem dann als nützlich erweist, wenn man Bedrohungspotenziale, Schwachstellen und mögliche Risikobereiche identifizieren will. Nicht zu verwechseln ist der Begriff der Persona mit dem in der IT üblicheren Begriff der Rolle. Damit wird typischerweise eine Gruppe von Individuen bezeichnet, welche dieselbe Funktion ausüben. Titel und Stellenbeschreibungen sind ein gutes Beispiel. Aber ein Sicherheitsbeauftragter oder ein Systemadministrator hat nicht zwingend dieselbe Persona. Es gibt auch innerhalb ein und derselben Persona Unterschiede – etwa, wenn jemand die Sicherheitsvorgaben sehr eng auslegt oder aufgrund seiner Erfahrung eher weiter.

Das klassische Identitätsmodell – Benutzer und Zugriffsberechtigungen

Die nächste Ebene im klassischen Modell ist die der User, respektive der Accounts. Dies sind die Objekte, die den Zugriff auf bestimmte IT-Systeme und Anwendungen innerhalb eines Unternehmens gewähren. Anders gesagt repräsentieren ein Benutzer, ein Benutzerkonto oder ein Account das Recht, auf ein IT-System zuzugreifen. Ist diese Zugriffsberechtigung erteilt, können weitere vergeben werden, die es gestatten, innerhalb dieses speziellen IT-Systems bestimmte Dinge zu tun.

Genau an diesem Punkt beginnt für die meisten die Verwirrung. Gerade in Microsoft-lastigen Umgebungen entwickelt sich alles rund um das Active-Directory-Benutzerkonto herum. Das führt dazu, dass es fälschlich deckungsgleich mit der Identität verstanden und verwendet wird. Vergleichbares gilt für Organisationen, die sich auf LDAP-Systeme stützen.

Cengiz Tuztas, One Identity

„Begriffe wie Identität, Benutzer, Konto, Recht, Rolle, Persona und so weiter sollten mit Beginn eines IAM-Programmes klar definiert sein.“

Cengiz Tuztas, One Identity

Unternehmen verlassen sich häufig auf die zentrale Verfügbarkeit und Verbreitung von Active Directory. Drittanwendungen zentralisieren und vereinfachen die Benutzerverwaltung über Active Directory. Das führt dazu, dass diese Benutzerkonten fälschlich als Identitäten betrachtet werden. Das indes greift zu kurz. Ein AD-Konto ist lediglich ein Konto, das den Zugang zu einem AD-System, einem lokalen Rechner oder den angebundenen Anwendungen erlaubt. Die Identität einer Person besteht nicht allein aus diesem AD-Konto, sie verfügt möglicherweise über weitere Konten oder Berechtigungen in anderen Systemen. Einen Benutzer sollte man nie nur als singuläres Objekt betrachten, sondern immer mit einer Identität verknüpfen oder ihm eine solche zuweisen. Die Governance sollte dementsprechend von der Identität ausgehen, während die Identität ihrerseits mit einer Person verknüpft ist. Ein User, gleich welcher Art, wird immer von einer realen Person genutzt/gesteuert, unabhängig davon, ob es sich um einen User, eine Maschine oder ein Maschinenkonto handelt. Letztendlich ist immer eine Person für eine Maschine verantwortlich, und eine reale Person fordert erweiterte Zugriffsberechtigungen auch für Maschinenkonten an. Eine Person, die im Übrigen mehrere Maschinen- oder Benutzerkonten verwalten kann. Wenn man die Governance beim Benutzer ansiedelt, erhält man nur einen Ausschnitt dessen, was möglich ist. Die Funktionen und Fähigkeiten der Person werden nie vollständig erfasst.

Betrachten wir das Bild insgesamt, dann verfügen Identitäten über Berechtigungen, die sie benutzen, um in den IT-Systemen eines Unternehmens zu agieren. Die erste Berechtigung, die man braucht, um auf ein IT-System zuzugreifen, ist das Benutzerkonto. Danach erhalten die Benutzer weitere Berechtigungen, um bestimmte Aufgaben zu erfüllen. Folglich gehören Identity Governance oder Governance of Rights auf die Ebene der Identität. Dies gilt analog für Maschinenidentitäten. Die haben zwar meist eine Eins-zu-Eins-Beziehung zu den Benutzern im IT-System, aber aus Gründen der Konsistenz ist es sinnvoll, sie separat abzubilden.

Nimmt man alle Arten von Identitäten innerhalb einer Unternehmensumgebung zusammen, sind diese letztlich immer an eine Person geknüpft, unter Umständen mit einer Haupt- und mehreren Unteridentitäten. Die Governance sollte nicht nur von der Identität ausgehen, sondern zwingend auf der obersten Identitätsebene angesiedelt sein.

Fazit

Begriffe wie Identität, Benutzer, Konto, Recht, Rolle, Persona und so weiter sollten mit Beginn eines IAM-Programmes klar definiert sein. Unter anderem, um ein Verständnis vom Begriff der Identität über Organisationen, soziale Identitäten und Unternehmensidentitäten sowie die IAM-Systeme hinweg zu ermöglichen. In modernen IAM-Programmen setzen Firmen Lösungen für das Access Management, die Identity Governance und das Privilege Management ein. Wer den aktuellen Herausforderungen und Bedrohungen erfolgreich begegnen will, der muss die Governance auf der Identitätsebene im Unternehmen ansiedeln. Warum? Weil sich hier das Risiko klassifizieren lässt, man regelmäßig eine Neuzertifizierung der Berechtigungen durchführen und eine Analyse des Benutzerverhaltens verarbeiten kann. Dazu kommen zusätzliche Maßnahmen wie Zero Trust und Privileged Access Governance.

Eine fragmentierte Systemlandschaft (aufgrund der Interaktion unterschiedlicher Tools und Systeme) oder eine auf der falschen Ebene angesetzt Governance sind nicht mehr zeitgemäß. Empfehlenswert sind eine einheitliche Identitätssicherheitsstrategie und eine Plattform, die diesen Ansatz unterstützt.

Über den Autor:
Cengiz Tuztas ist EMEA Presales Manager bei One Identity.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.

Erfahren Sie mehr über Identity and Access Management (IAM)

ComputerWeekly.de
Close