5
Verwaltung via Powershell im Internen Netzwerk Ja oder Nein?
Hallo zusammen!
Aus Sicherheitstechnischen Gründen sollte man ja möglichst viele Windows Interne Remoteverwaltungstools deaktivieren da diese ein Sicherheitsrisiko darstellen. Z.B. auch WindowsPowershell
Andererseits ist dies aber auch extrem mühsam, da man als Admin ja eig. möglichst viel RemoteVerwalten will bzw. über mehrere Geräte hinweg Befehle ausführen will.
Heutiges Beispiel:
Ich würde gerne via Powershell auf den Systemen den Internet Explorer deaktivieren (Ja bei uns nutzen den noch einige User).
Dies könnte ich via Powershell: dism /online /Disable-Feature /FeatureName:Internet-Explorer-Optional-amd64
Da aber WinRM momentan deaktiviert ist, geht das nicht.
Wie handhabt Ihr diese Balance zwischen einfacher Verwaltung und Sicherheit?
Oder sehe ich den Wald vor lauter Bäumen momentan nicht?
Grüsse
KMUlife
Aus Sicherheitstechnischen Gründen sollte man ja möglichst viele Windows Interne Remoteverwaltungstools deaktivieren da diese ein Sicherheitsrisiko darstellen. Z.B. auch WindowsPowershell
Andererseits ist dies aber auch extrem mühsam, da man als Admin ja eig. möglichst viel RemoteVerwalten will bzw. über mehrere Geräte hinweg Befehle ausführen will.
Heutiges Beispiel:
Ich würde gerne via Powershell auf den Systemen den Internet Explorer deaktivieren (Ja bei uns nutzen den noch einige User).
Dies könnte ich via Powershell: dism /online /Disable-Feature /FeatureName:Internet-Explorer-Optional-amd64
Da aber WinRM momentan deaktiviert ist, geht das nicht.
Wie handhabt Ihr diese Balance zwischen einfacher Verwaltung und Sicherheit?
Oder sehe ich den Wald vor lauter Bäumen momentan nicht?
Grüsse
KMUlife
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 502154
Url: https://administrator.de/contentid/502154
Ausgedruckt am: 27.11.2024 um 03:11 Uhr
5 Kommentare
Neuester Kommentar
Angriffsfläche reduzieren ist immer gut. Was man intern zur Verwaltung nutzt obligt dem Admin. Da gibt es ja diverse Spielarten. Entsprechend abgesichert ist aber auch PS Remoting eine sichere Sache.
Ich würde gerne via Powershell auf den Systemen den Internet Explorer deaktivieren (Ja bei uns nutzen den noch einige User).
Dies könnte ich via Powershell: dism /online /Disable-Feature /FeatureName:Internet-Explorer-Optional-amd64
Das geht auch ohne Powershell z.B. direkt über psexec oder remote wmi, oder Start-Skript/Aufgabenplanung usw.Dies könnte ich via Powershell: dism /online /Disable-Feature /FeatureName:Internet-Explorer-Optional-amd64
Danke für deine Anwort!
Mit PSexec läuft das ja astrein....
Aber dann frage ich mich halt schon was der Sinn davon ist powershell einzuschränken wenn mit anderen Diensten genauso Veränderungen am System gemacht werden können per Remoteconnection.
Wie handhabst du das denn?
Grüsse
KMUlife
Mit PSexec läuft das ja astrein....
Aber dann frage ich mich halt schon was der Sinn davon ist powershell einzuschränken wenn mit anderen Diensten genauso Veränderungen am System gemacht werden können per Remoteconnection.
Wie handhabst du das denn?
Grüsse
KMUlife
Zitat von @KMUlife:
Aber dann frage ich mich halt schon was der Sinn davon ist powershell einzuschränken wenn mit anderen Diensten genauso Veränderungen am System gemacht werden können per Remoteconnection.
Jeder hat andere Anforderungen und Sicherheitsanforderungen, genauso vielfältig sind halt auch die Optionen zur Remote-Verwaltung.Aber dann frage ich mich halt schon was der Sinn davon ist powershell einzuschränken wenn mit anderen Diensten genauso Veränderungen am System gemacht werden können per Remoteconnection.
Wie handhabst du das denn?
Ich würde die Sachen nicht totschalten, denn fast alle Aktionen von remote erfordern
A Adminrechte auf dem Remote-PC
B Ports, die nur zu administrativen Workstations geöffnet werden (wenn man es richtig macht)
Somit ist ein drittes Hindernis gar nicht mehr nötig, denn es kann eh nicht missbraucht werden.
A Adminrechte auf dem Remote-PC
B Ports, die nur zu administrativen Workstations geöffnet werden (wenn man es richtig macht)
Somit ist ein drittes Hindernis gar nicht mehr nötig, denn es kann eh nicht missbraucht werden.
Gerade in kleinen Umgebungen benötigt ein Admin sehr viele Rechte. Aber sein Büro PC wird auch für den Alltag verwendet. Da ist die Gefahr, dass er sich selbst etwas einfängt. Deswegen haben wir eine eigene VM nur fürs administrieren aller Server und Clients. Die Firewalls der Server und Clients erlauben Remote Kommandos nur von dieser VM aus. Die VM akzeptiert wiederum nur Remote Desktop Zugriffe.
Das hat auch den Vorteil, dass bestimmte Einstellungen wie z.B. die Installation des Report Tools nur einmal gemacht werden muss. Trotzdem kann man von überall administrieren. Aber ein Admin ist auch ein User z.B. auf seinem Büro-PC. Deswegen delegieren wir die Rechte nicht zu dem Usernamen (z.B. Mueller), sondern delegieren sie auf eigene Admin Konten, wie z.B. mueller-admin, womit der Uswr sich bei dieser VM anmeldet. Das sollte als Spagat zwischen Sicherheit und Bequemlichkeit der beste Kompromiss sein.
Das hat auch den Vorteil, dass bestimmte Einstellungen wie z.B. die Installation des Report Tools nur einmal gemacht werden muss. Trotzdem kann man von überall administrieren. Aber ein Admin ist auch ein User z.B. auf seinem Büro-PC. Deswegen delegieren wir die Rechte nicht zu dem Usernamen (z.B. Mueller), sondern delegieren sie auf eigene Admin Konten, wie z.B. mueller-admin, womit der Uswr sich bei dieser VM anmeldet. Das sollte als Spagat zwischen Sicherheit und Bequemlichkeit der beste Kompromiss sein.
