Programmerfahrungen: Lokale Adminrechte verwalten

[Blubmann1337]

Hallo zusammen,

ich habe ein größeres schon längst überfälliges Projekt in unserem Unternehmen gestartet, weil sich bisher keiner rangetraut hat und ich nicht vom Blubmann zum Buhmann werden möchte, weil sich ein Virus durchs interne Netz treibt.
Konkret geht es um die generelle Entfernung von lokalen Adminrechte (ja auch für den Chef, dem das natürlich eigentlich gar nicht schmeckt) für AD-Benutzer am PC. Ja hier gibt es unter den 70 Mitarbeitern noch einige, die lokale Adminrechte besitzen. Teilweise völlig grundlos, andere weil sie für Ihre Entwicklungsumgebung und Docker Adminrechte brauchen. Ich möchte dem ganzen jetzt aber aus gutem Grund einen Riegel davorschieben. Nun benötige ich etwas Schwarmwissen-/Erfahrung in Bezug auf Programme mit denen man lokale Adminrechte verwalten kann.
Grundsätzliche Anforderungen wären, dass ein Benutzer Adminrechte anfragen kann und wir als Admins darüber benachrichtigt werden, damit wir kontrollieren können, für was der Benutzer Adminrechte benötigt.
Gleichzeitig soll es die Möglichkeit geben eine Whitelist zu führen, um bestimmte Programme direkt zuzulassen wie z.B. die Entwicklungsumgebung oder so Sachen wie IP-Adresse im VMware-Adapter ändern, was bei den Entwicklern auch manchmal benötigt wird.
Ich habe mich mal umgeschaut und würde mal eine Demo von Beyondtrust Endpoint Management und AdminbyRequest anschauen, da die so auf den ersten Blick genau das erfüllen was ich benötige. Habt ihr noch andere Programme im Einsatz oder eines der beiden und könnt entsprechende Erfahrungen darüber berichten? Danke schon mal im voraus für eure Erfahrungen, Berichte und Hilfe.

 

[GutGilliganHyde]

Gruppenrichtlinien?!

 

[Blubmann1337]

Ist natürlich eine Möglichkeit, aber kann man da wirklich differenzieren? Also ist mir nicht bekannt, aber bin natürlich für Tipps offen. Ich kenne halt nur die Policy zu sagen, füge Benutzer oder Gruppe xy den lokalen Admins hinzu. Dann haben die aber generell Adminrechte.

 

[Masamune2]

Beyondtrust (ehemals Avecto) Privilege Management ist da schon mal ein sehr guter Ansatz. Einer meiner Kunden hat das im Einsatz und damit kannst du genau das umsetzen was du beschreibst.

 

[Ranayna]

Ich habe keine eigenen Erfahrungen mit soeiner Software, aber eine Frage dazu:
Man kann ja, bei Programmen die einen Dateidialog benutzen einfach andere Programme im gleichen Kontext wie das laufende Programm starten. Auch mit Adminrechten.

Szenario: Zwei getrennte Accounts auf dem Rechner, einer User, der andere Admin. Der User wird natuerlich fuers normale Arbeiten verwendet. UAC ist natuerlich an.
Jetzt starte ich beispielsweise Notepad als Admistrator, weil ich zB mein lokales Firewalllog unter System32 anschauen will (Der normale User kann das Standardverzeichnis fuer das Log nicht lesen).
Das loest natuerlich die UAC Abfrage mit Passworteingabe aus.

Aber, dann kann ich ueber File -> Open ja auch ueber das Kontextmenue Programme starten. Ohne weitere UAC Abgrage kann ich zB cmd.exe per Rechtsklick als Admin starten. Und damit dann natuerlich alles andere.

Koennen diese Programme das verhindern? Ist eine "Adminrechte-Whitelist" also ueberhaupt moeglich?

 

[Blubmann1337]

Oh das ist natürlich eine gute Frage. So spontan würde ich sagen, dass das nicht verhindert werden kann, da man ja schon Adminrechte besitzt und Windows dann nicht auf die Idee kommt dir den Dialog nochmal anzuzeigen. Aber ich werde das mal testen, wenn ich eine Demo habe.

 

[Darkblade08]

Du holst dir damit aber wieder das Gleiche Problem ins Haus. Was hindert den Mitarbeiter daran, mit dem zweiten Admin Konto andere Dinge zu tun, als ein Dateidialog oder nur ein spezifisches Programm zu öffnen.

Prinzipiell sollten eigentlich keine Konten Adminrechte besitzen. Man kann eigentlich mit Boardmitteln (sofern Enterprise zum Einsatz kommt), alles sauber trennen. GPOs wurden hier bereits genannt, dazu gehört dann auch ein saubere Rechteverwaltung inkl. Gruppen und etwas wie AppLocker.

 

[Masamune2]

Koennen diese Programme das verhindern?

Ja können sie sonst wären sie komplett nutzlos.

 

[Blubmann1337]

@Masamune2 stimme ich dir auch zu, wobei ich echt nicht weiß wie die das abfangen, wenn Windows selbst keine Meldung bringt. Aber mit einer Demo kann ich das genauer sagen.
@Darkblade08 Hast du Tipps, wenn mein Vorgänger der Meinung war, kein Enterprise zu benutzen? Ansonsten schaue ich mich da mal noch um, habe schnell mal gelesen, dass Applocker wohl auch mit Win10/11 Pro klappt

 

[Misdemeanor]

Bei uns in der Firma sind die meisten Mitarbeiter "Quasi-Admins".

Auf deren Geräten ist ein Zusatzprogramm Make Me Admin installiert, welches nach Eingabe von Benutzernamen und Passwort deren Account für zehn Minuten temporär in die Administratoren-Gruppe hebt. Nach diesen zehn Minuten wird man also wieder Ottonormalbenutzer ...

Alleine die Aufforderung, dass man etwas eingeben muss, ist ein sichtbares Kennzeichen dafür, wenn höhere Rechte angefragt werden, spätestens da sollte also auch zumindest einigen der unbedarften Usern klar sein, dass diese Anfrage nicht ohne Grund kommt, bzw. wenn sie ohne deren Zutun sogar aufpoppen sollte, etwas nicht in Ordnung ist.

Ich finde es gut so und kann damit gut leben. Vielleicht ist es auch etwas für Dich und Deine Benutzer.

 

[Blubmann1337]

@Misdemeanor danke für den Vorschlag. Das habe ich mir bereits auch angeschaut, bin mir aber noch nicht sicher, ob das ideal ist. Diese ekelhaften Entwicklungsumgebungen wollen spätestens bei kompilieren irgendwelche Adminrechte und dann steigt mir irgendwann jemand aufs Dach. Auch habe ich tatsächlich recht wenig Vertrauen in unsere Entwickler und deren Umgang mit dem Admin und dessen Auswirkungen. Manche sind lernresistent und würden auch bei Virus.exe sich als Admin hochstufen. Da fällt mir gerade ein, dass natürlich auch alles irgendwie protokolliert werden sollte, wer wann weshalb Adminrechte braucht oder gebraucht hat.

 

[BFF]

Entwickler und deren PC gehören in ein abgeschottetes Netz ohne Zugang zu Produktiv.

Was die fabrizieren und produktiv getestet werden soll wird durch Admin ausgebracht.

Ja ich weiss. Kostet extra Technik.

 

[Blubmann1337]

@BFF da muss ich dann erstmal prüfen wie man das alles auseinander gezogen bekommt. Aber grundsätzlich keine schlechte Idee. Hast du das selbst irgendwo umgesetzt? Trennung mit Firewall? Oder in ein eigenes VLAN packen?

 

[BFF]

Die Entwickler hier haben ein komplett eigenens Netz. War einfach weil eigenes Gebaeude.
Sowie ein eigener Zugang zum Internet.

Per VLAN aber auch schon realisiert damals als die Netzwerkstruktur nix Anderes her gegeben hat.

 

[Misdemeanor]

Einen Tod muss man sterben.

Auch proklamiert mein Arbeitgeber und die entsprechende Fachabteilung als Nonplusultra-Sicherheitskonzept sog. "AD-Tiering". Das will ich nicht schlechtreden oder lächerlich machen, weil ich das so ausdrücke - ich halte es für sinnvoll. Aber auch hier ist die Akzeptanz einer solchen Lösung das eigentliche Problem.

Will sagen: es gibt weitaus mehr als die Überlegung, seine Benutzern Administrator-Berechtigungen zu gewähren, es geht auch darum, dass wenn sie kompromittiert werden, es mehr als ein Netz und mehr als einen doppelten Boden gibt, über welche sich die Gefahr gar nicht erst ausbreitet.

Grundsätzlich gilt: Firewall, eigene VLANs, Abschottung, somit eine logische und/oder physische Trennung sind immer eine gute Idee, solange jeder noch auf alles das Zugriff bekommt, auf das man Zugriff bekommen muss. Und damit meine ich keine über das Internet erreichbare Freigabe über Port 3389.

 

[scooter010]

Sauber ist es nur, wenn es mehrere Domänen gibt.

In einer Produktivdomäne dürfen Nutzer keine Adminrechte haben, egal ob lokal oder via AD.
Ein Angreifer mit lokalem Armin kann sich relativ einfach die Dom-Admin Privilegien holen. Gibt genügend tools, die mit lokalen Adminrechten darauf warten, dass sich irgendwann mal ein domadmin an der Kiste anmeldet (lokal oder Domäne) und dessen Ticket abgreifen kann, wenn es nicht eh schon herum liegt, von einer vergangenen Anmeldung. Mit dem Ticket ist man dann DomAdmin und kann sich am DC als Armin authentifizieren. Domäne kompromittiert.

Wie bereits vorgeschlagen: Alle Nutzer einer Domäne sind nur User. Adminrechner selbst nicht Mitglied der Domäne bzw. es werden dedizierte DomMngt Kisten genutzt, welche aber auch nicht in der Domäne sind.

Im normalen Alltag sind auch Admins, die Berichte/Konzepte schreiben und Dinge auswerten auch nur User.

Und wenn die Entwickler keine domänenabhängigen Tools schreiben, dann braucht es dort auch keine Domäne.

 

[crashbandicot]

In einer Produktivdomäne dürfen Nutzer keine Adminrechte haben, egal ob lokal oder via AD.

Dürfen schon, man muss die einzelnen Ebenen / Tiers nur voneinander trennen. Stichwort ESAE (Enhanced Security Admin Environment).