IT Security März/April

IT SECURITY | 33
direkt erstellt und verwaltet werden.
Damalige Ansätze für das Identity &
Access Management begrenzten sich
darauf, existierende Benutzer mit Rechten
zu finden, die dem Bedarf eines neu
eingestellten Mitarbeiters nahe kamen,
diesen Benutzer zu kopieren, umzubenennen
und diese Änderungen halbwegs
automatisch in die angeschlossenen
Systeme zu übertragen. Komplex,
fehleranfällig und vor allem dazu neigend,
viel zu viele Rechte zu vergeben.
Gepaart mit der ebenfalls lokalen Entscheidung,
was der Benutzer denn nun
in der Anwendung tun soll (lokale Access
Matrix im System), war an zentrale
Kontrolle und Governance kaum zu
denken. Ein Audit einer solchen Landschaft
setzte tiefe Kenntnisse der Applikationen
und ihrer Berechtigungsmodelle
voraus; der Aufwand war astronomisch
und Audits konnten nur in kleinen
Stichproben erfolgen.
Dann kam der Verzeichnisdienst
Eine deutliche Verbesserung (aus administrativer
Sicht und auch für die Anwender)
ergab sich durch die Verbreitung
von Verzeichnisdiensten, und der Verbindung
von Applikationen mit den Verzeichnisdiensten.
In den Applikationen
musste nicht mehr unbedingt eine Tabelle
der Anwender mit ihren Passworten
hinterlegt sein, denn der Vorgang der
Identifikation und Authentisierung konnte
an den Verzeichnisdienst, etwa das
Active Directory, ausgelagert werden.
Microsoft hat hierfür das Kerberos Protokoll
adaptiert, dass noch heute den
Zugriff auf Applikationen durch die Mitgliedschaft
in (Sicherheits-)Gruppen
steuert, und dem Anwender eine einfache
Art des Single Sign-Ons ermöglicht,
da er nunmehr seine AD-Anmeldung
per Kerberos-Token mit den Anwendungen
teilt. In diesen Zeitraum fällt auch
die Adaption des in den frühen 1990er
Jahren vom US-Verteidigungsministerium
entwickelten „Role
Based Access Control“
(RBAC). Anhand dieses Modells
wurde in einer – oftmals hierarchisch
ausgelegten – Struktur ein Set an
abstrakten Rechte-Bündeln so zugeschnitten,
dass den zugeordneten Personen
genau der Zugriff auf Applikationen
verfügbar wurde, den sie für ihre
jeweilige Aufgabe im Unternehmen
brauchten. Teilweise konnte dies sogar
bis auf die Berechtigungen in Anwendungen
verfeinert werden, wie die in
SAP oftmals genutzten „Profile“ zeigen.
Dies wurde oftmals mit Ansätzen des
„least privilege“ kombiniert und konnte
– im Idealfall – sogar zur Abgrenzung
toxischer Kombinationen über „segregation
of duty“ genutzt werden. Eine
Vielzahl (gescheiterter) RBAC-Projekte
hat jedoch gezeigt, dass eine rein auf
Rollen basierende Zuweisung von Rechten
in der Praxis nicht funktioniert, da
der Abdeckungsgrad der jeweiligen
Rollen je Position einen Zielkonflikt zwischen
„need to do“ und „least privilege“
hervorruft. Man will schließlich
nicht 1.000 Rollen für 1.000 Mitarbeiter
haben – folglich sind Kompromisse
mit Einzelberechtigungen, Projektberechtigungen
und administrativen Sonderrechten
in „just in time“ oder „on-demand“
Modi erforderlich.
Rechte: Verwaltung vs. Zugriff
User1
User2
Manager
DIE KERNIDEEN RUND
UM DYNAMISCHERE
VERWALTUNG VON
ZUGRIFFSRECHTEN KÖN-
NEN IN NAHEZU JEDEM
AUF DEVOPS AUSGELEGTEN
IT-BETRIEB SINNVOLLE
ANWENDUNG FINDEN.
Sebastian Rohr, CSO, umbrella.associates
GmbH, www.umbrella.associates/de
oder RBAC vs xBAC
Spätestens an der Stelle mit „on-demand“
wird deutlich, dass man den wenig
zeitkritischen Verwaltungsakt
der Zuordnung
einer (eher statischen)
Rolle zum Anwender von
dessen versuchten Zugriff zur Laufzeit
(dynamisch) unterscheiden muss. Die
unabhängige IDpro Organisation hat in
ihrem (lesenswerten) Book of Knowledge
dazu die Unterscheidung zwischen
„Admin Time“ (zeit-unkritischer Verwaltungsakt)
und „Runtime“ (zeitkritischer
Zugriff) für die Berechtigungen eines An-
Access
Management
AD groups
App1
App2
App3
www.it-daily.net | März/April 2023