Privileged Access Workstation (PAW) – der Varianten-Vergleich

Eine Privileged Access Workstation (PAW) bietet dem Administrator eine sichere Arbeitsstation an, von der die administrativen Tasks ausgeführt werden können. Was sollte eine solche PAW-Station erfüllen und wie unterscheiden sich die PAW-Varianten? Einen Überblick bietet dieser Artikel.

Die Idee einer PAW-Lösung ist, dass Daily Business Aktivitäten wie Mails beantworten etc. von den administrativen Tätigkeiten getrennt werden. Damit Credential Theft Attacks wie Pass-the-Hash, Pass-the-Ticket und weitere Bedrohungen keine Angriffsfläche finden. Je nach dem vor welchen Angriffsmethoden man sich schützen will, sieht die eigene PAW-Lösung entsprechend anders aus. Unten sind die am häufigsten anzutreffenden PAW-Lösungen kurz beschrieben und verglichen.

In einem geschützten Netzwerk wird ein/e Terminal Server (TS) / Virtual Desktop Infrastruktur (VDI) extra für die administrativen Tasks installiert. Microsoft schlägt sogar die Variante vor, dass die PAW als virtuelle Maschine auf der normalen Workstation ausgeführt werden kann. Diesen zweiten Ansatz von MS habe ich jedoch noch nie in grösseren Unternehmen erlebt. Meist wird wie anfangs beschrieben auf eine TS- / VDI-Umgebung gesetzt. Dabei verbinden sich die Administratoren per RDP auf die PAW und können von dort aus die administrativen Tätigkeiten ausführen. Mit der entsprechenden Netzwerksegmentierung werden diese Rechner zusätzlich durch Firewalls / Proxy eingeschränkt oder ganz vom Internet getrennt. Diese Variante wird oft gewählt, da keine weiteren spezifischen Anforderungen an die PAW-Lösung gestellt werden.

Weitere Infos hier: docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations

Die Administratoren besitzen zwei Notebooks. Eines wird für die Daily Business Aktivitäten verwendet. Das zweite Gerät wird nur für die administrativen Tasks genutzt. Dadurch trennt man die beiden Aktivitäten komplett. Somit hat ein allfälliger Keylogger auf der normalen Workstation keine Chance, administrative Credentials auszuspähen. Der grosse Nachteil ist, dass die Administratoren im Pikett-Fall zusätzlich das PAW Notebook mitschleppen müssen.

Diese Variante nimmt die Idee von Variante 2 auf, eine physisch getrennte Umgebung für die administrativen Tasks zu haben. Dabei wird auf der normalen Workstation eine Software installiert, die es ermöglicht, eine Micro-VM-Hardware isoliert auszuführen, über die RDP-, HTTPS- und ICA-Verbindungen möglich sind. Die Administratoren können beispielsweise von der normalen Workstation aus eine RDP Session aufbauen, die jedoch in der Micro VM Hardware isoliert ausgeführt wird. Somit können Key- und Screenlogger keine Daten von der RDP Session aufzeichnen. Die Administratoren werden sich freuen, dass sie kein zweites Notebook mitschleppen müssen und trotzdem die Hardwareisolation für die administrativen Tasks haben.

Hier melden sich die Administratoren über 2FA mit ihrem Standard Account bei einer Access Console an, die auf ihrer normalen Workstation installiert ist. Die Access Console verbindet sich dann auf die PRA Appliance, welche in einem abgesicherten Netzwerk steht. In der Access Console können die Administratoren ihre gewünschten Zielsysteme für die Verwaltung auswählen. Nach der Auswahl wird man direkt auf dem Zielsystem mit seinen administrativen Credentials eingeloggt, ohne dass der Admin diese kennt. Dies ist möglich, da die PRA einen integrierten Passwortspeicher hat und Credential Injection machen kann. Nach Beendigung der Session werden die genutzten Credentials vom administrativen Account automatisch rotiert (gewechselt), so dass Pass-the-Hash Attacken danach nicht mehr möglich sind. Da die PRA Appliance Session Proxy ist, kann diese alle administrativen RDP, SSH und Web Sessions aufzeichnen und protokollieren. Approval Workflows sind beim Zugriff auf sensitive Systeme möglich. Diese Lösung wird meist für den Zugang von externen Administratoren verwendet. Denn der Zugriff auf die PRA kann auch über den Browser ohne Access Konsole erfolgen.

Weitere Infos hier: www.tec-bite.ch/remote-access-methoden-fuer-admins-im-vergleich-be-an-it-superhero-or-use-pra/

Hierbei handelt es sich wie bei Variante 4 um ein PAW-Lösung mit Passwort Management und Session Management, jedoch für interne Administratoren. Der grosse Unterschied liegt darin, dass die Lösung automatisiert neue Systeme und Accounts aufnehmen und verwalten kann. Was vor allem bei grösseren Umgebungen eine Anforderung ist. Der Administrator braucht keine sogenannte Access Console mehr. Er kann die RDP- und SSH-Verbindung über das Web-UI des Password Safes (PS) starten oder wie gewohnt seine RDP-Verbindungen von seinem RDP Manager starten. Dabei wird die RDP-Verbindung immer zum PS gestartet. Die PS startet anschliessend die RDP Session zum Zielserver und kann durch Credential Injection direkt die administrativen Credentials einfügen. Der Administrator besitzt wie bei Variante 4 nie seine Credentials, da nach Beendigung der RDP Session die administrativen Credentials direkt rotiert werden. Wer die Vorteile von Variante 3 Protected App und dem Password Safe haben möchte, kann auch beide Lösungen miteinander kombinieren.

Weitere Infos hier: www.tec-bite.ch/die-achilles-sehne-der-it-passwortspeicher-vs-password-management/

Damit man nicht den Wald vor lauter Bäumen nicht mehr sieht, ist unten eine Feature-Tabelle der vorgestellten Varianten aufgeführt. Die aufwendigeren Modelle von Microsoft mit separatem Active Directory wie Enhanced Security Administrative Environment (ESAE) sind hier nicht aufgeführt, da es hier mehr um PAW als um Identity Protection geht.