Jump to content

Administrative und "normale" Arbeit trennen


Recommended Posts

Hallo Forengemeinde,

bisher mache ich meine Administrativen Tätigkeiten und meine "normalen" Nicht-IT-Arbeiten an einem Rechner. Als normaler Benutzer, administrative Tätigkeiten dann per RDP oder ""ausführen als". Da das ganze ja Sicherheitstechnisch kein Idealzustand ist, hatte ich mir überlegt für meine Administrativen Tätigkeiten auf meinem Rechner eine VM aufzusetzen mittels HyperV.

Wäre das sinnvoll oder was spricht sicherheitstechnisch dagegen?

Link to post

Die Trennung von "normalem" und "Admin" Benutzer ist doch schon ein nicht unerheblicher Sicherheitsgewinn (jedenfalls solange der normale User kein lokaler Admin ist). Man kann durchaus eine VM oder Jumpstation her nehmen, verlagert aber doch die Rechte nur woanders hin, letztlich sicherer muss das dann noch lange nicht sein.

 

Es kommt wie Nils immer so schön sagt auf die Anforderungen an, die man an ein solches Sicherheitsmodell hat, auch an die Gegebenheiten, Personal und das Budget des Unternehmens. Das fasst man in ein schönes Konzept, testet das mal aus, verbessert hier und da und setzt es dann um. Da ist dann noch der Geltungsbereich ganz interressant, soll es für alle User oder nur einen Teil geben, welche anderen Sicherheitsmaßnahmen gibt es (getrennte Netzperimeter, Firewalls, Zugriffskonzepte etc) us usw usw, Kann schnell ein richtig großes Projekt werden .....

 

Grüsse

 

Gulp

 

 

  • Thanks 1
Link to post

Also ich bin hier der einzige Admin, das Netzwerk ist doch recht überschaubar (30 Clients, 2 VMWare Hosts, physischer Backup-Server und DC), Firewall, Proxy und co. liegen im Rechenzentrum.

Geht also eher um einen (meinen) User :-)

Link to post

Moin,

 

vielen Dank für die Blumen. :-)

 

Ich stimme Gulp zu, die eigentliche Kontentrennung ist schon mal der wesentliche Schritt. Gleichzeitig ist die Überlegung, auch den Rechner zu "separieren", sinnvoll. So bestünde, wenn man es richtig macht, noch eine weitere Hürde für "irgendwas", das sich auf dem Office-Rechner einnistet, auf die administrativen Zugriffe überzugreifen. 

 

Da allerdings, und da kommt Gulps Argumentation wieder ins Spiel, sollte man abwägen. Der Aufwand lohnt sich nur, wenn man die administrative Maschine/VM wirklich "sauber" hält - und wenn man umgekehrt wirklich keine Anmeldung mehr mit dem Admin-Konto auf dem Office-Rechner durchführt. Bequemlichkeit und "mal eben" verbieten sich dann. Weiß man, dass man das nicht durchhält, dann ist es nicht nur sinnlos, sondern erhöht sogar die Gefahr, weil man sich in falscher Sicherheit wiegt.

 

Gruß, Nils

 

  • Like 2
Link to post

"Sauberer" macht man's andersrum: Die Admin-Maschine ist das Blech, und die Work-Maschine ist eine VM auf dem Blech.

 

Das Risiko geht ja von der Work-Maschine aus, und wenn die der VM-Host ist, kommt ein Schädling recht einfach in die Admin-VM rein oder schafft es, Logon-Credentials abzufangen (die tippst Du ja auf dem Blech = Work-Maschine ein). Ist die Work-Maschine ein VM, muß der Schädling daraus erst mal ausbrechen...

 

Das ist auch die preiswerte Alternative zur dedizierten Admin-Workstation, die Microsoft in ESAE empfiehlt. Dazu kommen noch Policies, die dem Work-User die Anmeldung an der Admin-Maschine verweigern und andersrum. https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html verdeutlicht das grundsätzliche Prinzip, wie man so was sehr einfach und extrem flexibel umsetzen kann. Und idealerweise wird das ergänzt durch Applocker/SRP/xyz, so daß auf der Admin-Workstation nichts gestartet werden kann, was für die Administration nicht benötigt wird.

 

Und ja, da bin ich bei @Gulp, das kann einen Rattenschwanz hinterherziehen :-)

  • Like 1
Link to post

Ja, da hast du wohl recht. Problem ist halt dass ein Großteil meiner Arbeit eher nicht mit administrativen Konten erfolgt, da läuft halt viel mit Office, Outlook, DMS etc außerhalb des Arbeitsbereiches "Administration". Das wäre so in der Konstellation schon ne ziemliche Arbeitsbremse... Aber ok, muss ich mal schauen.

Link to post

Ein Rechner in einem anderen Netzwerk ist schon mal ein guter Schritt. Klar könnte ein Angreifer die RDP-Zugangsdaten abgreifen, wenn der Rechner kompromittiert ist, aber in der Praxis scheint das bei "Massen-Malware" nicht implementiert zu sein. Die entsprechenden API-Aufrufe machen die Schadsoftware vielleicht zu verdächtig.

 

Zusätzliche Sicherheit gewinnt man, wenn man den RDP-Client als anderen Benutzer startet. Dann kann ein Keylogger, welcher unter dem normalen Benutzer läuft, keine Tastatureingaben abfangen.

 

In die andere Richtung erhöht es die Sicherheit, wenn man den Browser unter einem anderen Benutzer laufen lässt. Also Office und Arbeitssoftware unter dem normalen Benutzer und den Browser für die Treibersuche und die Zeitungslektüre unter einem anderen. Vereinfachen lässt sich das mit dem Feature "Windows Defender Application Guard", welches den Edge in einer Sandbox laufen lässt.

Link to post
Am 10.3.2021 um 13:27 schrieb mwiederkehr:

Zusätzliche Sicherheit gewinnt man, wenn man den RDP-Client als anderen Benutzer startet. Dann kann ein Keylogger, welcher unter dem normalen Benutzer läuft, keine Tastatureingaben abfangen.

Das stimmt nur, solange keine PrivEsc möglich war - und genau das ist eine der häufigsten Sicherheitslücken. Bin ich SYSTEM, kann ich alles mitlesen. Deshalb ja auch "Admin-Workstation auf Blech, Arbeits-Workstation als VM" und nicht anders herum.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...