Blogbeitrag, wie Sie One Identity Safeguard und One Identity Manager verkuppeln

Warum die wirksamen Berechtigungen im IAM-System unsichtbar bleiben

In unseren IAM-Projekten haben wir regelmäßig mit Prüfer/-innen der internen Revision zu tun. Insbesondere während der ersten Projektschritte ereilen uns immer wieder die Fragen 

  • Woran erkenne ich denn jetzt im IAM-System, ob Herr Meier auf das Share XYZ Zugriff hat? 
  • Was sind aktuell seine wirksamen Berechtigungen? 

Die korrekten Antworten darauf „gar nicht, weiß nicht“ erstaunen meist ein wenig. Dabei handelt es sich um einen klassischen Fall von Erwartungsmanagement: Was erwartet eine Organisation von der Einführung eines IAM-Systems (schließlich ist das Projekt vielleicht komplex oder teuer - oder sogar beides)? Was ist das fertige System tatsächlich zu leisten imstande?

Role-Based Access Control

Viele IAM-Systeme auf dem Markt orientieren sich an dem schon etwas älteren NIST-Standard „Role-Based Access Control“ (RBAC), wenn es um die Betrachtung der Berechtigungen einer Organisation und der sinnvollen, handhabbaren Modellierung und Neuordnung geht. Der RBAC-Ansatz geht davon aus, dass ein Mitarbeiter eines Unternehmens in einem IT-System, auf das er Zugriff benötigt, grundsätzlich dort auch einen Account und Zuordnungen von Berechtigungen braucht. Zur Abstrahierung empfiehlt der RBAC-Standard, diese Berechtigungen schon im IT-System zu bündeln und zusammenzufassen. Die meisten heutigen IT-Systeme beherrschen dies und erlauben es, konkrete Einzelrechte auf Ressourcen (z.B. Shares, Drucker, Transaktionen) in Gruppen zu bündeln. Diese „Gruppen“ heißen oft auch genauso und stellen ein zentrales Berechtigungsobjekt im RBAC-Standard dar.

Nun geht der RBAC-Standard noch einen Schritt weiter und proklamiert ein weiteres Berechtigungsobjekt „Rolle“, das außerhalb der betrachteten IT-Systeme in einem Verwaltungswerkzeug wie dem IAM-System lebt. Diese Rollen haben folgende Eigenschaften:

  • Ihnen werden im IAM-System Gruppen aus IT-Systemen zugeordnet.
  • Es können einer einzelnen Rolle Gruppen aus mehreren IT-Systemen zugeordnet werden.
  • Es können Rollen ineinander verschachtelt werden, bspw. um verschiedene logische Rollen-Ebenen im IAM-System zu etablieren (typisch: Applikationsrollen, Fachrollen, Funktionsrollen).
  • Rollen können Meta-Informationen tragen, die in Gruppen nicht gepflegt werden könnten, bspw. Daten zur Funktionstrennung (Segregation of Duties, SoD), Eigentümern, Genehmigungsstufen, umfangreichen, redaktionell erfassten Beschreibungen.
  • Rollen werden Mitarbeitern zugeordnet und das IAM-System stellt sicher, dass die Gruppen der Rolle dem/den Account(s) des Mitarbeiters in den betrachteten IT-Systemen daraufhin ebenfalls zugeordnet werden. Wir sprechen in diesem Fall davon, dass im IAM-System die Gruppen der Accounts „unter Rollenkontrolle gestellt werden“.

Auf diese Weise entsteht eine Berechtigungs-Vererbungs-Hierarchie über mehrere Ebenen. 

Berechtigungs-Management in Windows

Blogbeitrag, wie Sie One Identity Safeguard und One Identity Manager verkuppeln
Berechtigungshierarchie von Mitarbeiter über Active Directoy bis zur ACL. Der Pfeil bedeutet „erbt Berechtigungen von“, z.B. „Mitarbeiter erbt Berechtigungen von App-Rolle C“

Um es konkret zu machen, schauen wir uns die mögliche Struktur am Beispiel des IT-Systems „Windows“ an, das Teil einer Microsoft-Active-Directory-basierten Domain ist.

Dabei gehen wir von einer schützenwerten Ressource aus: Hier ein geteilter Ordner (Share) auf einem Fileserver. Dieser geteilte Ordner wird geschützt durch Einzelrechte in der sogenannten „Access Control List“ (ACL). Diese ACL besteht aus einer Liste von Berechtigungsobjekten mit ihren konkreten Berechtigungen auf den Share, also bspw. „Gruppe ABC hat Vollzugriff auf den Share“, „Gruppe DEF hat Nur-Lese-Berechtigung“. Die genannten Gruppen können dabei Gruppen auf dem Server selbst (Server-lokale Gruppen) oder im Active Directory definiert sein. In Windows-Umgebungen findet man häufig Gruppen-in-Gruppen-Verschachtelungen derart, dass bestimmte Gruppen in den ACLs der Ressourcen genutzt werden („Ressource-Gruppen“), die in anderen Gruppen verschachtelt sind, in denen die Admins die Mitgliedschaften von Accounts pflegen („User-Gruppen“). Es ergibt sich auf dem Weg von der ACL in Windows zum Mitarbeiter-Objekt im IAM-System eine Hierarchie von Berechtigungsobjekten, die sich über acht Ebenen erstreckt (Abbildung rechts).

Die konkrete Ausgestaltung dieser Hierarchie ist fallspezifisch und oft Ergebnis der Vorlieben der Windows- oder Active-Directory-Administratoren. In einem IAM-Einführungsprojekt muss der gesamte Berechtigungs-Vererbungspfad vom Einzelrecht (Ebene 8) zum Mitarbeiter (Ebene 1) untersucht werden, um die Eingangsfrage „Was hat Herr Meier denn jetzt für Berechtigungen?“ beantworten zu können.

Hier ist wichtig zu wissen, dass das RBAC-Modell sich auf die Ebenen 1 bis 5 bezieht: Per RBAC modellieren wir im IAM-System die Beziehungen zwischen Mitarbeiter und den Applikations- oder Fachrollen bis hin zu den Gruppen, die dem Account des Mitarbeiters direkt zugeordnet sind. Alle höheren Ebenen sind für ein IAM-System, das das RBAC-Modell unterstützt, unsichtbar.

Zurück zur ersten der beiden Eingangsfragen: Woran erkenne ich denn jetzt im IAM-System, ob Herr Meier auf das Share XYZ Zugriff hat? Die Antwort war: „gar nicht“, und jetzt wird auch klar, warum. Ob Herr Meier tatsächlich Zugriff auf ein Share hat, also, ob er über die diversen Rollen- und Gruppen-Ebene hinweg unmittelbar oder mittelbar in einer ACL eines Shares berechtigt ist, kann man in einem RBAC-System nicht sehen, denn es hält nicht alle dafür nötigen Daten vor.

Wirksamkeit von Berechtigungen

Bisher haben wir uns mit einer statischen Sicht auf die Berechtigungshierarchie befasst, die dazu führt, dass ein Mitarbeiter Berechtigungen auf eine Ressource hat. Diese statische Sicht beinhaltet nur die Aussage, dass der Mitarbeiter aufgrund seiner Berechtigungsstruktur potenziell Zugriff hat. Ob er den Zugriff tatsächlich genutzt hat, ob also die Berechtigungsstruktur wirksam ist, entscheidet sich zur Laufzeit. Hier tritt ein wesentlicher Unterschied zweier Systeme zutage:

  1. Das Berechtigungsmanagement-System, bestehend aus IAM-System, Active-Directory, den Gruppen-in-Gruppen-Verschachtelungen und den Access Control Lists auf den Ressourcen, legt die potenziellen Berechtigungen fest (statische Sicht)
  2. Das Zugriffskontrollsystem prüft zur Laufzeit, ob ein konkreter Zugriffsversuch zulässig ist oder nicht. Erst durch diese Instanz wird eine Berechtigung wirksam.

Auch im IT-System „Windows“ ist es wichtig, zwischen der Datenhaltung und der Zugriffskontrolle zu unterscheiden: das Active Directory ist eine Windows-Komponente, aber es ist nicht das Zugriffskontrollsystem. Vielmehr hält es die Berechtigungsdaten vor, die das Windows-Zugriffskontrollsystem zur Ausübung der Zugriffskontrolle benötigt. Wenn ich also im Active Directory manuell oder über ein IAM-System Berechtigungsstrukturen verwalten kann, sagt mir das noch nicht viel über deren Wirksamkeit. Folgende Fallstricke könnte es zwischen den Ebenen 5 und 8 in unserem Modell geben:

  • Eine Gruppe ist nicht unmittelbar oder (über Verschachtelungen) in der ACL einer Ressource genutzt. Ergebnis: Gruppenmitgliedschaft des Accounts ohne jegliche Wirkung
  • Überlappung mehrere Gruppen in den Einzelrechten der ACLs. Ergebnis: der Entzug einer Gruppenmitgliedschaft entzieht dem Account nicht die potenzielle Berechtigung auf die Ressource, da es für sie noch einen anderen Pfad in der Berechtigungshierarchie gibt

Darüber hinaus gibt es noch einen vor allem bei Entzügen problematischen Effekt, der sich aus einem Caching-Mechanismus in Windows ergibt, der gerne vergessen wird: das Access Token.

Das Access Token wird beim Login eines Accounts an einer Windows-Arbeitsstation vom Login-Manager ermittelt und fortan bei jeder Authentifikations- oder Autorisierungsanfrage eines anderen Windows-Rechners (bspw. eines File-Servers) vorgezeigt. Im Access Token stehen alle Berechtigungen des Accounts zum Zeitpunkt des Entstehens des Tokens, die sich aus dem Active Directory ermitteln lassen, darunter alle direkten Gruppenmitgliedschaften. Insbesondere stehen im Access Token nicht

  • Mittelbare Gruppenmitgliedschaften, die sich durch Gruppen-Verschachtelungen innerhalb des Active Directories ergeben
  • Mittelbare Gruppenmitgliedschaften in Server-lokalen Gruppen
  • Berechtigungen in ACLs mittelbarer oder unmittelbarer Art auf den (allen) Windows-Servern und -Arbeitsstationen der Domäne

Ändern sich also Berechtigungsstrukturen im Active Directory, bspw. durch Hinzufügen von Gruppenmitgliedschaften zum Account, durch Entzug von Gruppenmitgliedschaften oder durch Änderungen an der Gruppenverschachtelung, so hat dies erst zeitverzögerte Auswirkungen auf das Access Token: erst beim nächsten Login wird es neu berechnet.

Wenden wir uns der zweiten der beiden Eingangsfragen zu: Was sind aktuell seine (Herrn Meiers) wirksamen Berechtigungen? Die aktuell wirksamen Berechtigungen eines Windows-Accounts stehen entweder direkt im Access Token oder werden von ihm abgeleitet, z.B. in dem ein File-Server das Access Token liest und sein Zugriffskontrollsystem dem Account nachfolgend einen Zugriff auf eine Ressource gewährt oder verwehrt.  Kann ich das im IAM-System sehen? Antwort: nein.

Abhilfen

IAM-Systeme, die mehr können

Die Administrationstiefe, die ein IAM-System erreicht, ist nicht immer auf das RBAC-Modell beschränkt. Mitunter gibt es auch innerhalb eines IAM-Systems unterschiedlich tief angebundene Standard-Systeme. So erreicht beispielsweise die Garancy IAM Suite unseres Software-Partners Beta Systems für Windows und einige Mainframe-Security-Systeme folgende Administrationstiefen:

Standard-Zielsystem-Anbindung Erreichbare Ebene Zielsystem-Bezeichnung
Windows Connect 7 Gruppe (server-lokal)
SAP Connect 6 Sammelrolle (Ebene 5), Rolle (Ebene 6)
RACF Connect  8 Datasets, Generic Datasets
TopSecret Connect 8 Datasets, Generic Datasets
ACF2 Connect 8 Datasets, Generic Datasets
Alle anderen 5  

 

Dies erlaubt zumindest die Sichtbarkeit, Auswertbarkeit und Änderungsverfolgung (Logging) der statischen Berechtigungsstrukturen innerhalb des IAM-Systems, teilweise auch in den Rezertifizierungsprozessen. Unverändert nicht sichtbar sind die sich ergebenden und tatsächlich genutzten Berechtigungen.

File Analysis and User and Entity Behavior Analytics (UEBA)

Die meisten IT-Systeme, darunter auch Windows, erlauben das Protokollieren von Änderungen an der statischen Berechtigungsstruktur. Dies gilt selbstverständlich auch für IAM-Systeme. Wie gut und einfach die Auswertung der Protokolle gelingt, ist sehr stark vom IT-System abhängig. Bei Windows landen die Änderungslogs, falls sie aktiviert sind, im Event-Log der Domain Controller, allerdings in recht technischer Form.

Darüber hinaus ist es bei vielen IT-Systemen möglich, gewährte oder verwehrte Zugriffsversuche auf Ressourcen zu protokollieren.  Bei Windows landen diese Zugriffs-Logs, falls sie aktiviert sind, im Event-Log des Servers, auf dem die Ressource abgelegt ist. Auch diese Protokolle sind technischer Natur, und sie sind über die Server verteilt und nicht an einer zentralen Stelle gesammelt.

Für die Überwachung (Ebenen 4 bis 8)

  • der Zugriffsrechte auf Ressourcen
  • der tatsächlich unternommenen Zugriffsversuche auf eine Ressource

gibt es in der IT-Security eine eigene Disziplin „File Analysis and User and Entity Behavior Analytics“ (FA & UEBA) mit einem eigenen, großen, nicht auf Windows beschränkten Software-Katalog (Varonis, Garancy Data Access Governance, Saviynt Cloud PAM, …). Das ist ein eigenes Einführungsprojekt.

Auch die Disziplin „Privileged Access Management“ (PAM) spielt hier eine Rolle, aber aus einem anderen Blickwinkel (Account- statt Ressourcen-Sicht). Das ist ebenfalls ein eigenes Einführungsprojekt.

SIEM?

Security Information and Event Management stellt Konzepte und Lösungen für die Echtzeitanalyse von Sicherheitsalarmen bereit. SIEM-Systeme sind spezialisiert auf die Analyse und Korrelation von Sicherheitsalarmen aus einer großen Anzahl verschiedener Quellen.

Damit ein SIEM-System gut funktioniert, bedarf es geeigneter Quellen, die es in Echtzeit auf sicherheitskritische Vorgänge monitoren kann. Insoweit ist ein SIEM-System kein Ersatz für IAM- oder UEBA-Systeme, sondern stark darauf angewiesen, von diesen Systemen mit Daten befüttert zu werden.

Fazit

Die Einführung eines IAM-Systems ist nicht die alleinige Lösung für die Erwartungen der IT-Governance- und Revisionsabteilungen von Unternehmen. IAM-Systeme haben eine dedizierte Reichweite und insbesondere die weit verbreiteten Systeme auf Basis des RBAC-Modells (Role-Based Access Control) bringen eine klar abgegrenzte Administrationstiefe und die inhärente Beschränkung auf statische Berechtigungsdaten mit. Es ist also bei Einführungsprojekten ein klares Erwartungsmanagement erforderlich: selbst, wenn das IAM-Projekt groß, komplex und teuer sein sollte, entsteht daraus nicht die eierlegende Security-Wollmilchsau, die fortan alle möglichen und unmöglichen Fragstellungen zur IT-Security einer Organisation beantworten kann.

Sollten Organisationen also lieber gleich auf die Einführung eines IAM-Systems verzichten und ausschließlich auf technischer Ebene Berechtigungen verwalten und Security-Events monitoren? Natürlich nicht. Die Möglichkeiten,

  • das Berechtigungsmanagement aus der Business-Sicht zu betrachten,
  • Automationen einzuführen,
  • Administratoren zu entlasten und
  • die Verantwortung für Zugriffsrechte in Fachabteilungen zu übertragen, die selbst viel besser wissen, wer was warum sehen oder nicht sehen darf

liefert uns nur ein IAM-System zuverlässig und auf erprobte Art und Weise. Dennoch muss auch der Unterbau unter einem IAM-System, wie in diesem Artikel dargestellt, betrachtet und mit Maßnahmen und Lösungen begleitet werden. Dies ist allerdings weit weniger komplex als die althergebrachte Methode, den Administratoren von IT-Systemen den kompletten technischen und fachlichen Durchblick abzuverlangen und ihnen umfassende Verantwortung aufzuerlegen.

Disclaimer

Der Vollständigkeit halber seien folgende Klarstellungen erlaubt, die im Artikel großzügig übergangen wurden:

  • IAM-Systeme haben ein eigenes Zugriffskontrollsystem, sind also nicht nur mit der Datenhaltung von Berechtigungsdaten befasst. Sie sind aber kein Zugriffskontrollsystem für alle angeschlossenen IT-Systeme, sondern lediglich für sich selbst.
  • Auch innerhalb des Active Directories gibt es Ressourcen, die man mit ACLs schützen kann, so dass das AD strenggenommen nicht nur ein Datenhaltungssystem ist.
  • Anstelle des RBAC-Modells unterstützen manche IAM-Systeme auch die Vergabe von Berechtigungen auf Basis von Regeln oder Attributen (Attribute-Based Access Control). Die Einschränkungen bzgl. der Administrationstiefe bleiben vergleichbar. 

 

Zero Trust – Ein neues Zeitalter der Cyber Security
Blog 24.08.20

Ein neues Zeitalter der Cyber Security

Cyber Security hat in den vergangenen Monaten und Jahren einen ganz neuen Status erlangt: Ein Zeitalter des „Zero Trust“ ist angebrochen und mit ihm hat sich Blick auf Sicherheitsbedrohungen drastisch verändert.

Das Thema IT-Security immer weiter in den Fokus
Blog 07.01.21

Warum der Überwacher überwacht werden muss

Nach dem SolarWinds Hack rückt das Thema IT-Security immer weiter in den Fokus. In unserem Blogbeitrag beschreiben wir alles zum SolarWinds-Hack, deren Folgen und was wir daraus lernen können.

Blogbeitrag, was bedeutet Zero Trust bedeutet
Blog 30.09.20

Zero Trust – oder lassen Sie jeden rein?

In unserem Blogbeitrag möchten wir uns mit ein paar grundlegen Fragen zu Zero Trust beschäftigen: Was bedeutet Zero Trust eigentlich? Was ist das Prinzip dahinter? Was ist der Nutzen? All dies und mehr klären wir in unserem Artikel.

Blog Spoofing Fishing Teaser
Blog 21.10.20

Spoofing und Phishing

Heutzutage gilt es mehr denn je, sich effektiv vor Daten- und Identitätsdiebstahl zu schützen. In dem Kontext fallen häufig Begriffe wie „Spoofing“ und „Phishing“ . Wir erklären Ihnen, was es damit auf sich hat!

Blogbeitrag zu GARANCY IAM Suite Version 3
Blog 20.10.20

GARANCY IAM Suite – Das bietet Version 3

Die GARANCY IAM Suite ist für viele Professionals im Identity Access Management (IAM) das Tool der Wahl. Wir geben Ihnen einen Überblick zu den Neuerungen der dritten Version des Beta Systems Produkt.

Webcast

Webcast: "Expedition zum Identity Management"

Gemeinsam mit tollen Speakern und einer spannenden Agenda möchten wir Ihnen das Thema "Einführung eines Identity Managements" näher bringen. Dazu zeigen wir Ihnen, wie tatsächliche Expeditionen (beispielsweise im Himalaya) geplant und durchgeführt werden, wie ein Unternehmen - übertragen auf IAM - auf diesem Weg agiert und wie die TIMETOACT in Kooperation mit Savyint Sie begleitet.

Sep 30
GARANCY ist ein IAM Produkt mit vielfältigen Möglichkeiten
Blog 09.09.20

GARANCY – vielfältigen IAM-Möglichkeiten

Die GARANCY IAM Suite stellt eine dynamische Lösung zur Verfügung, um Datendiebstählen vorzubeugen.

Blogbeitrag, zu was eigentlich „Single-Sign-On“ (SSO) ist
Blog 14.10.20

Was ist eigentlich „Single-Sign-On“ (SSO)?

Diese Frage beantworten wir unserem Blogbeitrag. Erfahren Sie außerdem, welche Geschichte sich hinter Single-SIgn-On verbirgt.

Blogbeitrag, wie das optimale IAM Tool gefunden werden kann
Blog 20.07.20

So finden Sie das optimale IAM-Tool für sich!

Fragen Sie sich auch, wie Sie ein geeignetes IAM-Tool finden können, das zu Ihren Anforderungen und Vorstellungen passt?

Blogbeitrag, wie Sie One Identity Safeguard und One Identity Manager verkuppeln
Blog 24.11.20

So verheiraten Sie One Identity Safeguard & -Manager

Sie haben zwei Produkte des gleichen Herstellers bei einem Kunden implementiert, aber die beiden Akteure vertragen sich noch nicht so richtig. In unserem Blogbeitrag zeigen wir, wie Sie One Identity Safeguard und One Identity Manager verkuppeln.

Passwörter Geschichte
Blog 14.05.21

Kleine Geschichte des Passworts

Passwörter gibt es schon länger als sie vielleicht denken. Im ersten Blogbeitrag der Serie „Passwörter – Vergangenheit, Gegenwart und Zukunft“ nehmen wir Sie mit auf eine Reise zu den Ursprüngen des Passworts.

Teaserbild Expertenbericht Berechtigungsmanagement IAM
Blog 27.11.24

Sicheres Berechtigungsmanagement leicht gemacht!

Ein modernes IAM-System vereinfacht das Berechtigungsmanagement und schützt vor ungewolltem Zugriff. Erfahren Sie, wie Sie mit automatisierten Prozessen IT-Sicherheit und Compliance steigern.

Blogbeitrag zu Pam, warum das jeder kennen sollte
Blog 06.07.20

Darum sollte PAM für Sie kein unbekanntes Wort sein!

Sicherlich haben Sie schon einmal mitbekommen, dass Unternehmen Ziel von Hackerangriffen geworden sind. Sind Sie sicher, dass Ihnen nicht das Gleiche passiert?

Teaserbild Expertenbericht IAM zu FINMA Rundschreiben
Blog 23.10.23

IAM für Banken & Finanzinstitute in der Schweiz

Verlieren Sie keine Zeit: ✓Compliance ✓Sicherheit ✓Effizienz ✓Vertrauen! Jetzt handeln und mit der Einführung einer IAM-Software die Anforderungen des FINMA Rundschreiben 2023/1 erfüllen. ✅ Mehr dazu in unserem Blog.

Teaserbild Referenz IAM Kritikalität
Blog 07.03.23

Kritikalität im IAM

Jede Person im Unternehmen, mit Zugriff auf ein IT-System, stellt ein mögliches Sicherheitsrisiko dar. Ein Leitfaden für die Bewertung und Handhabung von kritischen Zugriffen gibt es in unserem aktuellen Blogbeitrag.

Bild zum Blogbeitrag IAM im Bankwesen
Blog 26.08.21

Identity Management für Banken: Anforderungen & Vorteile

Grossbanken gehören zu den ersten Unternehmen, welche ein Identity and Access Management (IAM) System eingeführt haben. Gemeinsam mit dem IAM Thema haben sie sich in einer Lernkurve entwickelt und die heutige Methodik geprägt.

Titelbild zum Expertenbericht IAM im Spital - Gesundheitswesen
Blog 08.03.21

Wieviel IAM braucht ein Krankenhaus?

Das Patientendatenschutzgesetzes vom Oktober 2020 verpflichtet faktisch alle Krankenhäuser, auch saubere Identity- und Accessmanagement Prozesse zu etablieren. Mehr dazu im Blog.

Bild zum Expertenbericht Customer IAM
Blog 30.06.21

Customer IAM - die praktische Einordnung ins IAM

Wie sieht das CIAM von der konkret, praktischen Seiten aus? Was ist dabei zu berücksichtigen und vor welche Herausforderungen steht man dabei? Wir beleuchten das Thema basierend auf konkreten Erfahrungen.

Bild zum Expertenbericht über PAM Systeme
Blog 27.04.21

PAM Systeme im Vergleich

PAM Systeme dienen grundsätzlich dazu Privilegierte Systeme zu verwalten und berechtigten Nutzern Zugriff zu gewähren. Dafür werden die Zugangsberechtigungen zu diesen Systemen im PAM System selbst vorgehalten und sind dem Benutzer in der Regel nicht bekannt.

Titelbild zum Expertenbericht IAM im Spital - Gesundheitswesen
Blog 23.06.20

Brauchen wir ein "Patient-IAM"?

Die Dynamik einer Pandemie kollidiert mit der Schwerfälligkeit der Institutionen bei der Einführung Elektronischer Patientenakten.