Marco31 33 Geschrieben 9. März 2021 Melden Geschrieben 9. März 2021 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? Zitieren
Gulp 275 Geschrieben 9. März 2021 Melden Geschrieben 9. März 2021 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 1 Zitieren
Marco31 33 Geschrieben 9. März 2021 Autor Melden Geschrieben 9. März 2021 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 Zitieren
NilsK 2.982 Geschrieben 9. März 2021 Melden Geschrieben 9. März 2021 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 2 Zitieren
daabm 1.391 Geschrieben 9. März 2021 Melden Geschrieben 9. März 2021 "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 1 Zitieren
Marco31 33 Geschrieben 10. März 2021 Autor Melden Geschrieben 10. März 2021 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. Zitieren
Sunny61 819 Geschrieben 10. März 2021 Melden Geschrieben 10. März 2021 Oder Du hast 2 Rechner am Tisch, einer für die Admin-Aufgaben, der andere für das normale Geschäft. Über einen KVM kannst Du von einem zum anderen springen. Zitieren
mwiederkehr 390 Geschrieben 10. März 2021 Melden Geschrieben 10. März 2021 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. Zitieren
daabm 1.391 Geschrieben 11. März 2021 Melden Geschrieben 11. März 2021 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. Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.