\nUnd mit dem Privileged Access Management<\/strong> St\u00fcck habe ich doch einige Zeit verbracht – aber ich greife vorweg, lernen wir doch erst mal unsere Akteure f\u00fcr das heutige Schauspiel rund um \u00fcberm\u00e4\u00dfige Rechte kennen.<\/p>\n
Das Monster – Overprivilege<\/h3>\n
Man kennt es vielleicht als Buzzword-Gegenst\u00fcck zu Least Privilege. Oder es wird einem vom Sicherheitsbeauftragten \/ der Security Abteilung als Argument f\u00fcr eine Identity Governance L\u00f6sung an die Wand gemalt.<\/p>\n
In den systemnahen IT-Teams kennt man es aber eher als die erste Anfrage, die ein Mitadministrator oder Entwickler stellt – es braucht nat\u00fcrlich jeder root, dbowner und lokalen Administrator. Denn in erster Linie steht meistens im Vordergrund, etwas zum laufen zu bringen, nicht ob man vielleicht \u00fcber das Ziel hinausschie\u00dft. <\/p>\n
So schleichen sich oftmals mehr und mehr Rechte ein, die man gar nicht braucht, sondern nur dazu einladen miss<\/strong>braucht zu werden.<\/p>\n Entra ID ist die Mauer um nicht nur unsere Office 365-Daten sondern auch um immer mehr angebundene Applikationen – inzwischen oftmals m\u00e4chtiger als Active Directory fr\u00fcher war. Entsprechend wollen wir sicherstellen, dass diejenigen die hinter den Mauern sind wirklich nur genau dort Zutritt haben, wo wir es erwarten bzw. wollen.<\/p>\n Wir sind also davon abh\u00e4ngig, dass die Software, die gebaut wird, sehr<\/em> genau darauf achtet was ben\u00f6tigt wird. Entwickler (und auch Admins) machen sich oft nicht gedanken, ob es vielleicht L\u00f6sungen mit weniger Rechten gibt, oder ob die angeforderten Rechte missbraucht werden k\u00f6nnten. Im Worst Case bietet Microsoft selbst<\/strong> nur Suboptimale Rechte an, so dass es gar nicht besser geht. <\/p>\n Es gleicht also fast einem Wunder, wenn es mal nichts gibt wor\u00fcber man sich beschweren kann \ud83d\ude09<\/p>\n Zur Erinnerung: wir konzentrieren uns gerade auf Overprivilege, PAM L\u00f6sungen sind in der Regel ein sehr gutes Tor<\/em> Stellen wir uns vor, es wird eine Privileged Access Management L\u00f6sung eingesetzt. Damit erschwert man b\u00f6swilligen Akteuren das Leben, aber meistens auch regul\u00e4ren Admins. Es gibt also immer zwei motivierte Gruppen, die gerne ohne PAM arbeiten w\u00fcrden. Ein Teil davon diese Beip\u00e4sse zu schlie\u00dfen ist es, dass idealerweise nach jedem Login die Kennw\u00f6rter der Konten rotiert werden.<\/p>\n Es gibt auch mehr als genug andere Stellen an denen man vielleicht nur ein Kennwort zur\u00fccksetzen will, hier k\u00f6nnen wir aber konkrete Beispiele betrachten.<\/p>\n Wir gehen also weiter mit dem gew\u00fcnschten Ergebnis, dass unser System Kennw\u00f6rter rotieren kann – sonst nichts<\/strong> – 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…<\/p>\n Ich gehe davon aus, dass die PAM-L\u00f6sung nicht auch Herr \u00fcber den Account Lifecycle ist – also keine Benutzerkonten erstellt werden oder Rechte zugewiesen werden. 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<\/p>\n<\/blockquote>\nDie Festung – Entra ID<\/h3>\n
Die Torw\u00e4rter – (PAM) Entwickler<\/h3>\n
<\/p>\nDas Einfallstor – Kennwortrotation<\/h3>\n
\n
\nIch werde hier aber auch nicht versuchen ein PAM-System zu verkaufen, dazu gibt es genug Hersteller<\/a>, die ihre PAM<\/a>-L\u00f6sungen anpreisen<\/a><\/em><\/p>\n<\/blockquote>\n
<\/p>\nDer Angriff<\/h2>\n
\nSonst wird die Betrachtung komplexer als ich mich traue in einen Blog Post zu packen.
\nIst Ihre PAM-L\u00f6sung auch ein Identity-Governance-System, bitte dieses Kapitel mit einer gro\u00dfen Prise Salz genie\u00dfen<\/em><\/p>\n
<\/p>\n\n
<\/p>\n
![\"AuthMethodsPermissions\"](\"https:\/\/sparrow365.de\/wp-content\/uploads\/2023\/12\/image.png\")
<\/p>\n