Das Passwort war nie das einzige Problem: Klassisches PAM vs. modernes PAM

Teil 1 von 3 unserer Reihe Rethinking Privileged Access.

Die Diskussion über Privileged Access Management (PAM) drehte sich ursprünglich um eine Frage: Wie schützen wir das Passwort? Es in einen Tresor legen. Es rotieren. Es in Sitzungen einspeisen, sodass es niemand jemals sieht. Es hinter Genehmigungen und MFA sperren, damit nur die richtige Person es abrufen kann. Klassisches PAM ist eine der ausgereiftesten und am weitesten verbreiteten Antworten auf diese Frage.

Das Passwortproblem zu lösen ist wichtig, aber bei Weitem nicht das einzige. Zero Trust, Zero Standing Privilege und Just-in-Time-Zugriff haben sich weiterentwickelt, seit das klassische PAM konzipiert wurde, doch das klassische PAM hat nicht Schritt gehalten.

Hier trennen sich die Wege von klassischem PAM und modernem PAM mit Netwrix Privilege Secure (NPS). Klassisches PAM war hervorragend in dem, wofür es gebaut wurde, doch moderne Angriffe zu stoppen erfordert ein Werkzeug, das für etwas anderes gebaut ist.

Klassisches PAM: Das Passwort schützen

Klassisches PAM geht von einer Annahme aus: Privilegierte Konten existieren dauerhaft, und Ihre Aufgabe ist es, sie so gut wie möglich zu schützen. Ist ein Konto heute Mitglied in Domain Admins, ist es morgen, nächste Woche und nächstes Jahr immer noch Mitglied, unabhängig davon, ob jemand dieses Recht nutzt. Klassisches PAM fungiert als disziplinierter Wächter vor diesem dauerhaften Recht.

In der Praxis sieht diese Kontrolle so aus:

• Ein Benutzer braucht Zugriff auf ein privilegiertes Konto. Zuerst benötigt er die richtigen Berechtigungen innerhalb des PAM-Tools selbst, etwa durch Rollenzuweisungen oder Zugriff auf den Ordner, der das Geheimnis enthält.
• Je nach Richtlinie muss er möglicherweise MFA bestehen, bevor es weitergeht.
• Er beantragt den Zugriff auf das Geheimnis (einen Check-out), was die Genehmigung durch einen oder mehrere benannte Genehmiger erfordern kann.
• Nach der Genehmigung sieht der Benutzer das Passwort in der Regel nie. Das Tool startet eine RDP- oder SSH-Sitzung und fügt die Anmeldedaten direkt darin ein.
• Der Check-out hat ein Zeitlimit. Wenn der Benutzer fertig ist oder die Zeit abläuft, checkt das Tool das Geheimnis wieder ein.
• Nach dem Check-in rotiert das Tool das Passwort, sodass selbst eine während der Nutzung offengelegte Anmeldedaten nicht mehr gültig ist.

Dieses Modell beseitigt die Offenlegung von Anmeldedaten, schafft einen sauberen Prüfpfad und erzwingt Genehmigungen, bevor jemand ein sensibles Konto anfasst. Doch so straff der Ablauf auch ist, das zugrunde liegende Konto bleibt zwischen den Sitzungen ein Domain Admin (oder lokaler Administrator bzw. sudo-Benutzer). Das Privileg ist dauerhaft. Nur der Zugriff auf das Passwort ist temporär. Ein Administrator kann auch außerhalb des Tools ein Passwort für eine „schnelle“ Aufgabe abgreifen und damit alle diese Kontrollen umgehen.

Klassisches PAM hat außerdem eine harte Grenze in Active Directory. Es liest Gruppenmitgliedschaften, um zu entscheiden, wer auf Geheimnisse zugreifen darf, erstellt, löscht oder ändert jedoch keine AD-Gruppen. Die Gruppenmitgliedschaft und das damit verbundene dauerhafte Recht liegen vollständig außerhalb seiner Kontrolle.

Teil 2 dieser Reihe behandelt Angriffe, die den Passwortzugriff umgehen oder ihn gar nicht benötigen, und erklärt, warum Just-in-Time und Zero Standing Privilege so wirkungsvoll sind.

Wenn Anbieter klassischen PAMs von „Just-in-Time“ oder „Zero Standing Privilege“ sprechen, meinen sie den Zugriff auf das Passwort, nicht das Recht auf dem Konto. Sie werden Ihnen auch sagen, dass echtes Just-in-Time ein separates Produkt für die Verwaltung von Endpoint-Berechtigungen erfordert. Dieses Produkt steuert lokale Administratorrechte auf Mitarbeiter-Rechnern. Es ist eine Form von Just-in-Time, deckt aber nicht die Konten ab, die Ihre kritische Infrastruktur tragen, und genau das ist die Aufgabe von PAM. Netwrix bietet in dieser Kategorie ebenfalls ein Produkt an: Netwrix PolicyPak.

Modernes PAM: Netwrix Privilege Secure beseitigt dauerhafte Privilegien

Netwrix Privilege Secure geht von einer anderen Prämisse aus. Anstatt zu fragen „Wie schützen wir ein mächtiges Konto?“, fragt es: „Warum muss ein mächtiges Konto die ganze Zeit mächtig sein?“

NPS stellt die Sitzung und die Activities in den Mittelpunkt. Diese laufen vor, während und nach der Sitzung ab, um Berechtigungen genau dann zu gewähren, wenn sie benötigt werden, und sie wieder zu entziehen, sobald sie nicht mehr gebraucht werden. NPS unterstützt drei Kontoansätze, die diesen Lebenszyklus jeweils unterschiedlich handhaben.

1. Anforderer-Konten

Dies ist das Konto, mit dem sich ein Benutzer bereits an seinem Computer und seiner E-Mail anmeldet, ohne separates privilegiertes Konto. Beim Start einer Sitzung gewährt eine Activity die Berechtigung spontan, etwa indem der Benutzer zu Domain Admins oder einer anderen privilegierten AD-Gruppe hinzugefügt wird. Da es das eigene Konto des Benutzers ist, wird das Passwort nicht im Tresor abgelegt, und der Benutzer gibt es während der Sitzung selbst ein. Wenn die Sitzung endet, entfernt NPS automatisch die zu Beginn gewährte Berechtigung.

Dies ist oft die bequemste der drei Varianten, bietet aber den geringsten Schutz der Anmeldedaten, da das Passwort weder rotiert noch eingefügt wird. Trotzdem beseitigt es dauerhafte Privilegien, weil das Konto erhöhte Rechte nur für die Dauer der Sitzung hat.

2. Verwaltete Konten

Dies ist das nächste Gegenstück zur Funktionsweise klassischen PAMs. Beim Start einer Sitzung rotiert NPS das Passwort des Kontos und aktiviert das Konto. Activities gewähren die Berechtigung für diese Sitzung, etwa indem das Konto zu Domain Admins, zu lokalen Administratoren oder einer sudo-Gruppe hinzugefügt wird. Das Passwort wird in die Sitzung eingefügt, sodass der Benutzer es nie sieht.

Der Unterschied zeigt sich am Ende: NPS rotiert das Passwort erneut und legt es im Tresor ab, nimmt die gewährte Berechtigung zurück und deaktiviert das Konto. Das Konto existiert weiterhin, hat aber zwischen den Sitzungen keine Berechtigungen und kann sich nicht authentifizieren. Ein gestohlenes Passwort ist für einen Angreifer dadurch wertlos.

3. Ephemere Konten

Dieses Modell geht einen Schritt weiter: Zu Beginn jeder Sitzung wird ein brandneues Konto erstellt. Während der Sitzung verhält es sich wie ein verwaltetes Konto: Die Berechtigung wird gewährt und das Passwort eingefügt. Wenn die Sitzung endet, löscht NPS das Konto vollständig und lässt nichts zurück, was angegriffen werden könnte.

Über die Berechtigung hinaus: Was Activities sonst noch können

Das Gewähren und Entziehen von Gruppenmitgliedschaften ist die Hauptfunktion, doch Activities schließen auch Angriffspfade, die standardmäßige Zugriffsmodelle typischerweise offen lassen:

• Bereinigung von Kerberos-Tickets. Wenn eine RDP-Sitzung endet, kann NPS Kerberos-Tickets von der Ressource entfernen und so einen Pfad für seitliche Bewegung abschneiden, der kein Konto-Passwort erfordert.
• RDP aktivieren/deaktivieren. Die meisten Windows-Server lassen RDP standardmäßig laufen. NPS kann RDP nur zu Beginn einer Sitzung aktivieren und direkt danach wieder deaktivieren, wodurch eine große, ständig verfügbare Angriffsfläche entfällt.
• Schutzmodus. NPS kann Windows- oder Linux-Ressourcen auf nicht genehmigte lokale Konten prüfen. Ein böswilliger Insider, der Ihr PAM-Tool korrekt verwendet, könnte unbemerkt lokale Administratoren für eine spätere, unautorisierte Nutzung anlegen.
• DC-Replikationssynchronisierung. Eine Berechtigungsänderung auf einem Domänencontroller wird nicht immer sofort an den DC weitergegeben, der die Authentifizierung der Sitzung übernimmt. NPS kann eine gezielte Synchronisierung erzwingen, damit die gewährte Berechtigung sofort verfügbar ist, statt auf die normalen AD-Replikationszeiten zu warten.

Gegenüberstellung

Klassisches PAM hat das Anmeldedatenrisiko verringert. Modernes PAM entfernt das Ziel.

Das Check-out/Check-in-Modell des klassischen PAMs ist eine ausgereifte, bewährte Methode, um die Offenlegung von Anmeldedaten zu reduzieren und privilegierten Zugriff nachvollziehbar zu machen. Für viele Organisationen war es ein großer Fortschritt gegenüber unverwalteten, gemeinsam genutzten Passwörtern.

Netwrix Privilege Secure ist für die Angriffe von heute konzipiert. Es betrachtet dauerhafte Berechtigungen selbst zusammen mit dem Passwort, das sie schützt, als die zu beseitigende Angriffsfläche. Ob es sich um das eigene Konto eines Benutzers handelt, das nur für die Dauer einer Sitzung erhöht wird, um ein verwaltetes Konto, das zwischen den Nutzungen wertlos ist, oder um ein ephemeres Konto, das verschwindet, wenn die Arbeit erledigt ist: Die Logik ist dieselbe. Wenn keine Berechtigung bereitliegt, die auf Verwendung wartet, gibt es nichts, was ein Angreifer stehlen könnte.

Als Nächstes in dieser Reihe

Das Beseitigen dauerhafter Berechtigungen unterbricht weit mehr als den Check-out/Check-in-Ablauf, für dessen Absicherung klassisches PAM gebaut wurde. Teil 2, Jenseits des Tresors: Wie NPS mehr als nur Passwortangriffe verhindert, beleuchtet die breitere Angriffsfläche für Anmeldedaten in Windows und Active Directory (NTLM-Hashes, Kerberos-Tickets, Kerberoasting, zwischengespeicherte Domänenanmeldedaten und mehr) und zeigt, welche davon das Sitzungsmodell von NPS schließt und welche nicht.

Danach behandelt Teil 3, wie Bring Your Own Vault Ihnen diese Schutzmechanismen auf Sitzungsebene über den bereits vorhandenen Tresor ermöglicht, ohne eine Rip-and-Replace-Migration.