Theater gegen Overprivilege: PAM Edition – Theorie

Vorhang auf

Es gibt manche Dinge, die mich immer wieder stören – so frage ich mich oft, wo die ganzen API Rechte gerechtfertigt sein sollen, die von Applikationen gefordert werden.
Und mit dem Privileged Access Management Stück habe ich doch einige Zeit verbracht – aber ich greife vorweg, lernen wir doch erst mal unsere Akteure für das heutige Schauspiel rund um übermäßige Rechte kennen.

Das Monster – Overprivilege

Man kennt es vielleicht als Buzzword-Gegenstück zu Least Privilege. Oder es wird einem vom Sicherheitsbeauftragten / der Security Abteilung als Argument für eine Identity Governance Lösung an die Wand gemalt.

In den systemnahen IT-Teams kennt man es aber eher als die erste Anfrage, die ein Mitadministrator oder Entwickler stellt – es braucht natürlich jeder root, dbowner und lokalen Administrator. Denn in erster Linie steht meistens im Vordergrund, etwas zum laufen zu bringen, nicht ob man vielleicht über das Ziel hinausschießt.

So schleichen sich oftmals mehr und mehr Rechte ein, die man gar nicht braucht, sondern nur dazu einladen missbraucht zu werden.

Die Festung – Entra ID

Entra ID ist die Mauer um nicht nur unsere Office 365-Daten sondern auch um immer mehr angebundene Applikationen – inzwischen oftmals mächtiger als Active Directory früher war. Entsprechend wollen wir sicherstellen, dass diejenigen die hinter den Mauern sind wirklich nur genau dort Zutritt haben, wo wir es erwarten bzw. wollen.

Die Torwärter – (PAM) Entwickler

Wir sind also davon abhängig, dass die Software, die gebaut wird, sehr genau darauf achtet was benötigt wird. Entwickler (und auch Admins) machen sich oft nicht gedanken, ob es vielleicht Lösungen mit weniger Rechten gibt, oder ob die angeforderten Rechte missbraucht werden könnten. Im Worst Case bietet Microsoft selbst nur Suboptimale Rechte an, so dass es gar nicht besser geht.

Es gleicht also fast einem Wunder, wenn es mal nichts gibt worüber man sich beschweren kann 😉

Das Einfallstor – Kennwortrotation

Zur Erinnerung: wir konzentrieren uns gerade auf Overprivilege, PAM Lösungen sind in der Regel ein sehr gutes Tor
Ich werde hier aber auch nicht versuchen ein PAM-System zu verkaufen, dazu gibt es genug Hersteller, die ihre PAM-Lösungen anpreisen

Stellen wir uns vor, es wird eine Privileged Access Management Lösung eingesetzt. Damit erschwert man böswilligen Akteuren das Leben, aber meistens auch regulären Admins. Es gibt also immer zwei motivierte Gruppen, die gerne ohne PAM arbeiten würden. Ein Teil davon diese Beipässe zu schließen ist es, dass idealerweise nach jedem Login die Kennwörter der Konten rotiert werden.

Es gibt auch mehr als genug andere Stellen an denen man vielleicht nur ein Kennwort zurücksetzen will, hier können wir aber konkrete Beispiele betrachten.

Wir gehen also weiter mit dem gewünschten Ergebnis, dass unser System Kennwörter rotieren kann – sonst nichts – und sehen uns die Dokumentationen von den drei mir bekanntesten Herstellern an. Dabei werden wir recht schnell feststellen, dass wir uns oft mehr in die Festung holen als wir wollen…

Der Angriff

Ich gehe davon aus, dass die PAM-Lösung nicht auch Herr über den Account Lifecycle ist – also keine Benutzerkonten erstellt werden oder Rechte zugewiesen werden.
Sonst wird die Betrachtung komplexer als ich mich traue in einen Blog Post zu packen.
Ist Ihre PAM-Lösung auch ein Identity-Governance-System, bitte dieses Kapitel mit einer großen Prise Salz genießen

Wer gute Artikel von Beratern oder Admins findet, wie man es in der Praxis machen sollte, gerne an mich weiterleiten – dass Hersteller oft nicht am besten mit ihrem Produkt umgehen ist bekannt

____	CyberArk	BeyondTrust
Geforderte Berechtigungen	Service Account User Admin Password Admin Global Admin	Application Permissions UserAuthenticationMethod.ReadWrite.All Domain.Read.All Group.Read.All User.Read.All Entra ID: Helpdesk administrator "Für Service Account Verwaltung" Entra ID: Privileged Authentication Administrator Directory.AccessAsUser.All
Überberechtigungen	Das eigene Kennwort ändern (nicht nur wiederherstellen) benötigt Admin Rechte im System	UserAuthenticationMethod.ReadWrite.All kann nicht für Kennwortwechsel genutzt werden – mir ist nicht ganz klar wofür der Scope genutzt werden soll
Sonstiges	Es ist angeblich nur für Global Admins ein Systeminterner Global Admin Account notwendig, in Realität muss aber schon für Mitglieder einer Role Assignable Group ein Privileged Authentication Administrator ran	Änderungen bei Benutzern in Role Assignable Groups und mit Admin Rechten werden fehlschlagen, wenn nicht zufällig Service Accounts im Einsatz sind

Das Ergebnis: Wir haben jetzt neue Service Konten in unserer Umgebung mit Global Admin Rechten (Privileged Authentication Admin kann auch Global Admin vergeben), nur um Passwörter zu verwalten. Diese Applikationen können jetzt also vollen Zugriff auf unsere M365 Umgebung ausüben – Endgeräte, Daten, Logins an Entra ID Enterprise Applikationen, etc.

Autsch!

Zur Verteidigung der PAM-Hersteller, Entra ID ist nur ein Authentifizierungsanbieter unter anderen wie SSH, AD, Okta, etc., die angebunden werden können – es gibt also mehr als genug Bereiche an denen gearbeitet wird. Trotzdem finde ich die Umsetzung für große sicherheitsfokussierte Firmen doch sehr unangenehm. Und wirklich einfach macht es ihnen Microsoft auch nicht.

Mitschuld des Burgherren

Von Microsoft bekommen wir keine Werkzeuge, nur spezifische Authentifierungsmthoden zu verwalten. Wenn wir also z.B. eine Applikation haben, die nur User Onboarding nur Temporary Access Pässe generieren können soll, kann sie auch gleichzeitig MFA Methoden verwalten…
Stand Januar 2024

Suchen wir in den API Rechten nach AuthenticationMethod finden wir nur Folgendes:

Ein UserAuthenticationMethod.ReadWrite.Passwords Scope wäre wirklich sehr hilfreich…

Die Gegenwehr

Ich habe relativ schnell die Idee verworfen, Administrative Units als Einschränkung zu nutzen – die notwendigen Rollen sind nicht verfügbar. Es würde auch generell keinen Sinn machen einen Global Admin nur auf bestimmte Benutzer einzuschränken, wenn er dann eh die Tenant-Einstellungen einfach überschreiben könnte.

Wer genau mitgelesen hat erinnert sich, dass ich drei große PAM Lösungen betrachten wollte.
Bei Delinea habe ich keinen dedizierten Entra ID Passwortmanager gefunden. Ich hatte anhand des Ergebnisses bei den anderen Anbietern überlegt, das schon als Plus zu werten, aber ich denke ein "Did not Qualify" trifft es eher. Warum habe ich sie aber nicht aus dem Thema gestrichen?

Für Delinea müsste man einen eigenen Passwort Connector für Entra ID bauen – und das würde ich, wenn es die Möglichkeit gibt, bei den anderen beiden auch Vorschlagen. So stellt sich die Frage – was würde ich tun, um nicht dieses Global Admin Monster in meiner Burg zu haben?

Nun, wie schon in meinem passwortzentrischen Blogpost angesprochen – ein Benutzer kann immer sein eigenes Kennwort ändern, wenn er sich authentifizieren kann und das alte kennt – Wenn wir also zu einem Benutzer das Kennwort im Vault haben, ist der changePassword Endpunkt für uns verfügbar. Rein Theoretisch müssen wir also gar keine Admin Rechte vergeben!

Jetzt müssten wir also nur noch eine Lösung finden, dass die PAM Lösung von Anfang an das Kennwort der Benutzer kennt die wir mit ihr verwalten wollen.
Nachteil wäre, dass leider keine automatische Korrektur möglich wäre, wenn ein Kennwort von dem in der PAM Lösung gespeicherten abweicht (reconciliation) – dort müsste also wieder ein Admin tätig werden. Für mich wäre das ein akzeptabler tradeoff, weil das nicht oft vorkommen sollte.

Ist automatische reconciliation Pflicht wäre eine Azure Function, die nichts anderes tut als Kennwörter zu rotieren, eine Alternative.
Mit Entra ID Authentifizierung natürlich, damit nur berechtigte Identitäten ein neues Kennwort abrufen können. Dann wäre die Azure Function zwar overpriviliged, aber es kann über Bindung an eine Managed Identity eine viel striktere Trennung zwischen Applikation und Recht geschaffen werden – zusätzlich wäre die Identity idealerweise in der Hand von jemandem, der sowieso die selben hochprivilegierte Rechte hat, statt dass sie jemand neuem zur verfügung gestellt werden.

Review

Wer jetzt im zweiten Akt schon einen Proof of Concept erwartet hat den muss ich enttäuschen – der Praktische Part wird ein separater Post.

Wir haben aber schon mal festgestellt, dass auch sicherheitsnahe Applikationen wie PAM-Lösungen nicht optimal Konzepte wie Least Privilege einhalten, aber es gibt trotzdem noch Optionen die wir ausloten könnten. Hoffentlich habe ich inspiriert, in Zukunft näher auf die Rechte zu schauen die man vergibt, und ich freue mich auf Rückmeldung zu Lösungen oder Ideen!

Ich werde keine Kommentare moderieren und möchte Ihre E-Mail-Adresse nicht; bitte beteiligen Sie sich an der Diskussion über meinen Zugehörigen LinkedIn Post.

Wenn sie an den Dingen interessiert sind die ich tue folgen sie mir auf LinkedIn.