Password Vaulting reicht nicht aus… Schützen Sie den Zugriff auf privilegierte Benutzerkonten mit Centrify’s Least Privilege Verfahren

Centrify’s Infrastructure Privilege Management Lösung (auch als Centrify Privilege Service, CPS) bekannt, ermöglicht es Anwendern schon seit längerem, remote und sicher auf privilegierte Benutzerkonten auf Servern oder Netzwerk Devices zuzugreifen. Dabei authentifiziert sicher der Benutzer zunächst gegen das Benutzerportal seines Unternehmens, das er von überall her in der Welt via Internet erreichen kann. Die Authentifizierung kann auf unterschiedliche Arten geschehen, meist wird dies als Active Directory Authentifizierung und zusätzlichen Credentials einer Multi-Faktor Authentifizierung realisiert.

Im Portal findet der Benutzer je nach seinen Berechtigungen (hier wurde RBAC realisiert) entsprechende Icons, die ihn zu den jeweiligen Serversessions führen. Dabei wird dann ein neues Browserfenster geöffnet und der Benutzer eingeloggt, ohne daß er die lokalen Credentials des privilegierten Accounts zu sehen bekommt. Bei diesem „vaulting-basierten“ Ansatz werden die Credentials des privilegierten Accounts zusammen mit den notwendigen Daten zum Serverzugriff (z.B. IP Adresse oder Hostname) verschlüsselt in der Datenbank des Privilege Services abgelegt.

Dieser sehr gebräuchliche Ansatz kann aber durch Centrify’s Least Privilege Modell grundsätzlich verbessert werden: Das entscheidende Problem beim Vaulting, also der ausschließlichen Benutzung eines Passwort Tresors, ist die Konzentration aller privilegierten Berechtigungen an einer einzigen Stelle, nämlich im Passworttresor. Zusätzlich funktioniert das Vaulting meist so, daß eine für die Erledigung der angedachten Aufgaben notwendige privilegierte ID ausgecheckt wird und dann die ganze Session unter dieser ID läuft, auch wenn das eigentlich nicht notwendig wäre.

Centrify stellt dem einen „Least Privilege“ Ansatz entgegen, der dem Benutzer die gleiche Funktionalität und Handling bietet, die Session als „privilegierter“ Benutzer aber auf das einschränkt, was der Benutzer tatsächlich mit erweiterten Rechten tun muß, beispielsweise das Stoppen oder Starten von Diensten auf einer Windows Maschine. Es ist zwar notwendig, dafür als Administrator zu arbeiten, aber es ist nicht notwendig, den Benutzer in eine „unbeschränkte“ Administrator Session einzuloggen und dort alles, was er tut, mit Adminrechten tun zu lassen.

Zudem lässt die Lösung zu, den Benutzer zur nochmaligen Authentifizierung (z.B. AD Credentials und/oder Multi-Faktor Authentifizierung) aufzufordern, sobald er vom normalen Benutzer zum Administrator wird, um bspw. eine Konfigurationsaufgabe zu erledigen.

Hier ein Beispiel: Der Benutzer soll auf einer Windows Maschine die Firewall Administration übernehmen. Unser Benutzer soll nur diese administrative Berechtigung auf der genannten Maschine besitzen.

Centrify stellt Kunden einen Service zur Verfügung, der wahlweise in der Cloud (MS Azure Public Cloud, AWS) oder on premise verfügbar ist. Der Anwender kommuniziert mit einem webbasierten Portal, das ihn je nach Konfiguration zur Authentifizierung bspw. gegen ein lokales AD und optional zusätzlich, abhängig von diversen situationsbedingten Faktoren, zur Multi-Faktor Authentifizierung auffordert.

Dies gewährleistet eine sichere Authentifizierung des Benutzers. Nun ist sichergestellt, daß jeder weitere Schritt des Benutzers diesem auch zugeordnet werden kann. Im Portal findet der Benutzer abhängig von seinen Zugriffsberechtigungen (diese können bspw. über AD Gruppen definiert werden, aber auch im Privilege Management selbst) Icons, die ihn beim Anklicken in eine Serversession führen. Selbstredend wäre hier ein Icon möglich, das den Benutzer z.B. direkt als „root“ in eine Linuxmaschine einloggt, aber dies ist nicht der Ansatz, der hier beschrieben werden soll.

Stattdessen findet der Benutzer Icons, die ihm grundsätzlich Zugriff auf die Maschine gewährleisten, ihn aber dort mit seinem eigenen AD Account einloggen. Dies macht Centrify durch die bekannte Server Suite Lösung möglich, die auch Nicht-Windows Systeme zu Computerobjekten im AD macht und so einen dedizierten Zugriff auf ein solches System unter einem Domain Account ermöglicht. Hiermit ist auch ein erweiterter Schutz der Systeme durch das Errichten von Zonen möglich. Im Endeffekt lässt sich granular einstellen, welcher Benutzer Zugriff auf welches System in der erweiterten Domäne hat.

Klickt der Benutzer auf ein Server Icon – siehe Screenshot unten – so öffnet sich entweder ein Browserfenster oder ein RDP/SSH Client und fordert zur Authentifizierung gegen das AD auf. Der Benutzer wird als „er selbst“ in die Session eingeloggt, nicht als privilegierter Benutzer.

In der jeweiligen Session (in unserem Beispiel Windows, es könnte aber auch Unix oder Linux sein) arbeitet der Benutzer grundsätzlich unter seiner eigenen ID, nur für administrative Tätigkeiten, zu denen er berechtigt ist, wechselt er zu einer administrativen ID (die er aber nicht kennen muß und die in vielen Fällen auch nicht der Administrator oder root sein muß).

Er findet in diesem Fall im Kontextmenü den Eintrag „Run with Privilege“, der ihn im einfachsten Fall ohne Aufforderung zur Eingabe der Admin Credentials direkt zur administrativen Aufgabe führt – in unserem Beispiel die Firewall Konfiguration. Dabei findet im Hintergrund über die Centrify Lösung ein Abgleich des AD authentifizierten Benutzers mit einem Regelwerk statt, das granular definiert, auf welchem Server oder welcher Workstation der Benutzer genau welche Aufgabe mit einer bereits vordefinierten administrativen ID verrichten darf.

Dieses Szenario kann nun mit Centrify noch weiter abgesichert werden. Zwar ist der Benutzer ja schon einmal authentifiziert worden, nämlich beim Login in sein Portal, aber die Ausführung eines Befehls, das Starten einer Applikation unter einer privilegierten ID kann noch einmal für eine AD Authentifizierung des Benutzers und/oder eine Multi-Faktor Authentifizierung genutzt werden. Im unwahrscheinlichen Fall, daß eine andere Person mit dem Portal eines bereits authentifizierten Benutzers arbeitet, kann damit ein Arbeiten mit Privilegien in einer Remote Session unterbunden werden.

Selbstverständlich ist es auch möglich, die Sessions zu Revisionszwecken aufzuzeichnen. Es ist sowohl ein Mitschnitt der kompletten Session des Benutzers möglich – also inklusive des Teils, der als normaler Benutzer durchgeführt wurde – oder lediglich der Mitschnitt der Teile, die mit privilegierten Rechten durchgeführt wurden. Auch das Monitoring der gerade laufenden Session ist möglich sowie das Beenden der Session durch einen Supervisor.

Das beschriebene kombinierte Verfahren aus Passworttresor, Authentifizierung der Benutzer bspw. über das AD plus Multi-Faktor Authentifizierung beim Login und bei der „Privilege Elevation“ machen das Centrify Verfahren wesentlich sicherer als ein reines „Vaulting“ Verfahren.