Jump Hosts für Admins
Grüßt euch Admins,
hat jemand von euch Erfahrung bezüglich Jump-Hosts sammeln können?
Ich habe folgende Optionen sammeln können:
1. Auf dem Lokalen Rechner werden die Admin Tools installiert und zusätzlich wird lokal eine VM installiert und dort wird der "Office-User" zur Ticket / Mail Bearbeitung etc. verwendet. (Die VM sollte nicht die Admin-VM sein, da es einfacher ist darauf Zugriff zu erhalten als andersherum -> Auf den physikalischen Client)
2. Es wird auf dem VMWare Cluster für 2 Admins jeweils eine VM installiert, da bei mehr gleichzeitigen Zugriffen ein TS benötigt wird
3. Es wird direkt eine eigene Citrix Umgebung für die Admins aufgebaut
4. Ich denke die Management Tools auf dem Office Rechner zu installieren und dann "run_as" zu verwenden ist Sicherheitsproblem mit Kerberos nicht zeitgemäß?
Gibt es eventuell noch eine weitere schöne Lösung und was haltet Ihr von einer eigenen Hardware (VMWare Host) für die Jump-Hosts?)
Danke für eure Rückmeldung und Hilfe!
hat jemand von euch Erfahrung bezüglich Jump-Hosts sammeln können?
Ich habe folgende Optionen sammeln können:
1. Auf dem Lokalen Rechner werden die Admin Tools installiert und zusätzlich wird lokal eine VM installiert und dort wird der "Office-User" zur Ticket / Mail Bearbeitung etc. verwendet. (Die VM sollte nicht die Admin-VM sein, da es einfacher ist darauf Zugriff zu erhalten als andersherum -> Auf den physikalischen Client)
2. Es wird auf dem VMWare Cluster für 2 Admins jeweils eine VM installiert, da bei mehr gleichzeitigen Zugriffen ein TS benötigt wird
3. Es wird direkt eine eigene Citrix Umgebung für die Admins aufgebaut
4. Ich denke die Management Tools auf dem Office Rechner zu installieren und dann "run_as" zu verwenden ist Sicherheitsproblem mit Kerberos nicht zeitgemäß?
Gibt es eventuell noch eine weitere schöne Lösung und was haltet Ihr von einer eigenen Hardware (VMWare Host) für die Jump-Hosts?)
Danke für eure Rückmeldung und Hilfe!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7955282497
Url: https://administrator.de/contentid/7955282497
Ausgedruckt am: 13.11.2024 um 09:11 Uhr
10 Kommentare
Neuester Kommentar
ein eigenes VLAN für "Admins\Jumphosts" machen. Nur von diesem aus darf man in wichtige andere Netze bzw Remotemanagement nutzen. Eingehend ist das Netz isoliert. RDP ist nur für die entspechenden User offen, sollte die Firewall das können.
In diesem Netz hat dann jeder seine Jumphost-VM. Nur auf dieser darf sich der entsprechende adminuser anmelden.
Da ist dann auch alles installiert was der User so braucht. Diese VM hat optimalerweise kein Internet
In diesem Netz hat dann jeder seine Jumphost-VM. Nur auf dieser darf sich der entsprechende adminuser anmelden.
Da ist dann auch alles installiert was der User so braucht. Diese VM hat optimalerweise kein Internet
Ich bin eher für eine PAW (Privileged Access Workstation) mit Verwaltungstools ohne Internetzugang in einem isolierten Verwaltungsnetz mit NAC Überwachung. Ich habe das Thema Jumphosts in der letzte heise-Security Schulung angesprochen. Jumphosts sind auf jeden Fall eine Sicherheitssteigerung, können dennoch (mit Aufwand) kompromitiert werden. In Zukunft werden wir nicht mehr viel per Remote machen können, was die Administration angeht.
Moin,
wir nutzen ein dediziertes VLAN, mit einer dedizierten Firewall. Die Jump Hosts selber sind nicht virtualisiert sondern jeweils auf Server-Hardware direkt installiert. Wir haben separate Jump Hosts für die Windows/Linux/Netzwerk-Welt.
Der Zugang zu den Server in dem genannten VLAN ist ausschließlich mit einer IP Whitelist möglich. Zudem sind die Anmeldungen personalisiert und mit MFA entsprechend abgesichert.
Die Aktualisierungen der Umgebung erfolgt manuell, keine AutoUpdate und Internetanbindung.
Gruß,
Dani
wir nutzen ein dediziertes VLAN, mit einer dedizierten Firewall. Die Jump Hosts selber sind nicht virtualisiert sondern jeweils auf Server-Hardware direkt installiert. Wir haben separate Jump Hosts für die Windows/Linux/Netzwerk-Welt.
Der Zugang zu den Server in dem genannten VLAN ist ausschließlich mit einer IP Whitelist möglich. Zudem sind die Anmeldungen personalisiert und mit MFA entsprechend abgesichert.
Die Aktualisierungen der Umgebung erfolgt manuell, keine AutoUpdate und Internetanbindung.
Gruß,
Dani
Hallo Dani,
Könntest Du erläutern, wieso? Das erscheint mir doch sehr Ressourcen verschwendend, so eine Servermaschine nur als "Admin-PC" zu nutzen. Oder? Was ist der Vorteil gegenüber einer VM?
cu,
ipzipzap
Zitat von @Dani:
Die Jump Hosts selber sind nicht virtualisiert sondern jeweils auf Server-Hardware direkt installiert.
Die Jump Hosts selber sind nicht virtualisiert sondern jeweils auf Server-Hardware direkt installiert.
Könntest Du erläutern, wieso? Das erscheint mir doch sehr Ressourcen verschwendend, so eine Servermaschine nur als "Admin-PC" zu nutzen. Oder? Was ist der Vorteil gegenüber einer VM?
cu,
ipzipzap
@ipzipzap
Gruß,
Dani
Könntest Du erläutern, wieso?
Was nicht da ist, kann auch nicht angegriffen bzw. für einen Angriff genutzt werden. Unabhängig davon wäre das für uns ein enormer Kostenfaktor für die zusätzlichen Lizenzen, Wartung, etc. Denn wir haben solch eine Zone nicht nur einmal sondern x Mal. Da musst du 2-3 Mal überlegen, ob die Vorteile die Nachteile überwiegen oder nicht.Was ist der Vorteil gegenüber einer VM?
Es ist bei uns ein Performance Thema. Wir reden hier nicht von 5, 10 oder 30 Personen pro Host, sondern von weit aus mehr!Ich nehme an, dass er eine Kompromittierung der VMWARE-Umgebung vermeiden will. So zu sagen als Ausbruchschutz.
So ist es.Gruß,
Dani
Zitat von @Dani:
Was ist der Vorteil gegenüber einer VM?
Es ist bei uns ein Performance Thema. Wir reden hier nicht von 5, 10 oder 30 Personen pro Host, sondern von weit aus mehr!OK, ich nahm an, Ihr habt einen Server pro Admin. Das las sich so nicht raus
Wie fertigt ihr denn die Multiuser ab bzw. mit welcher Umgebung arbeitet ihr da?
cu
Ich würde auch hier mal einwerfen das es eben ggf. zum Konzept passen muss... Der o.g. Linux-Server erlaubt zB. nur ne Key-Auth und logischerweise kein Root-Login -> da grad für ssh-portforwardings normale Userrechte reichen (theoretisch könnte man auch nen komplett shell-loses login machen - ich nutze halt auch die standard-debugging tools vom jumpserver bei der fehlersuche). Natürlich sollte so ein Server nich einfach irgendwo im Internet stehen sondern bestenfalls nur via VPN erreichbar sein (wenn DAS weg ist dann is es eh der Router/netzwerk und die Probleme sind schon eingegrenzt).
Damit ist die Angriffsfläche schon ziemlich limitiert... Natürlich gibt es Umgebungen bei denen das so sicherlich auch wg. Audit/Compliance-Regeln nicht machbar wäre, ich würde aber behaupten für die meisten Umfelder ist es kein Problem...
Natürlich gibt es wie bei jedem Konzept auch da keine Garantie - wenn ich dann aber lese von wegen "wird man zukünftig wenig remote machen" würde ich behaupten das die Risiken durch ungeschützte End-Systeme weil man als Admin einfach nicht mehr hinterher kommt deutlich höher sind ... Und es ist ja schön wenn man dann zwar 1000 Tools zB. für Updates hat aber für jeden Kram erstmal los läuft und am Ende keine Zeit hat um die Tools zu nutzen...
Damit ist die Angriffsfläche schon ziemlich limitiert... Natürlich gibt es Umgebungen bei denen das so sicherlich auch wg. Audit/Compliance-Regeln nicht machbar wäre, ich würde aber behaupten für die meisten Umfelder ist es kein Problem...
Natürlich gibt es wie bei jedem Konzept auch da keine Garantie - wenn ich dann aber lese von wegen "wird man zukünftig wenig remote machen" würde ich behaupten das die Risiken durch ungeschützte End-Systeme weil man als Admin einfach nicht mehr hinterher kommt deutlich höher sind ... Und es ist ja schön wenn man dann zwar 1000 Tools zB. für Updates hat aber für jeden Kram erstmal los läuft und am Ende keine Zeit hat um die Tools zu nutzen...