Adminhost, Jump-Server, PAW, oder SAW

[michelo82 12]

Hallo zusammen,
Microsoft selbst empfiehlt ja die Nutzung dedizierter Maschinen für die administrative Verwaltung.
https://docs.microsoft.com/de-de/windows-server/identity/securing-privileged-access/privileged-access-workstations

Dazu existieren verschiedene Begrifflichkeiten um die Verwirrung komplett zu machen.

 

Wir haben uns für die Variante Admin-Host bzw. Jump-Host entschieden.
Jeder Admin hat seine eigene Server 2019 VM, die nicht Mitglied der Domäne ist, auf einem ESX.
Die VM wurde mit den Microsoft Security Baseline gehärtet.

 

Darin sind einige Tools und ein RDP-Manager. Auf diese Maschine wird per VMWware-Konsole zugegriffen.

 

Mich würde interessieren, wie ihr das umgesetzt habt bzw. damit arbeitet?
Spricht etwas dafür- bzw. dagegen, dass ein Adminhost nicht Mitglied der Domäne ist?

 

MfG

bleibt gesund!

bearbeitet 3. Dezember 2020 von michelo82

[Dukel 461]

VMWare Konsole? D.h. wenn Admin 1 auf dieser Maschine ist kann Admin 2 genau so verbinden und sieht, was Admin 1 macht.

[michelo82 12]

Ja, warum nicht?

[Dukel 461]

Weil dann jeder, der auf die VMWare Umgebung Zugriff hat auch in die sichere AD Umgebung Zugriff bekommen kann.

Was spricht gegen eigene Maschinen, Jump Hosts oder VM's in der Domäne mit RDP?

[NilsK 2.982]

Moin,

 

ist die ESX-Umgebung dieselbe, auf der auch die produktiven Maschinen laufen? Streng genommen wäre auch das eine Vermischung der Sicherheitsbereiche. Es gibt immer mal wieder Bugs im Hypervisor (egal welcher), die einen Übergriff aus der VM auf die Host-Ebene erlauben.

 

Das heißt nicht, dass dieser Aufbau ausscheidet. Das Risiko wäre aber zu bewerten und zu dokumentieren.

 

Gruß, Nils

 

bearbeitet 3. Dezember 2020 von NilsK

[michelo82 12]

Diejenigen die auf die Adminmaschinen Zugriff haben, haben ebenso Zugriff auf die VMWare Umgebung - es ist der gleiche Personenkreis. Wir vertrauen uns.

Wird das Passwort bei RDP zwischengespeichert? Das spricht dann dagegen. Da bin ich mir aber gerade nicht sicher.

 

Ich habe bis jetzt noch nichts nachteiliges festgestellt, wenn die VM kein Domänenmitglied ist. Sinn war, dass die Maschine so immer autark betrieben werden kann, auch wenn die Domäne nicht verfügbar wäre (Disaster).

 

EDIT:

vor 6 Minuten schrieb NilsK:

ist die ESX-Umgebung dieselbe, auf der auch die produktiven Maschinen laufen?

Vorläufig ja. Da wir nicht die (zeitlichen) Ressourcen haben einen weiteren Host bereitzustellen. Aber das zu ändern, habe ich bereits im Hinterkopf.

 

Wenn man es ganz genau nimmt müsste ja nach dem PAW/SAW Prinzip, ein separater physicher Admin-PC in einem abgesperrten Raum stehen. Das ist nur im Alltag garnicht umzusetzen.

 

Ein dedizierte Admin-VM um überhaupt erstmal eine Trennung zur Office-Workstation zu schaffen, war ein wichtiger Schritt.

bearbeitet 3. Dezember 2020 von michelo82

[Dukel 461]

Mit den gespeicherten Credentials (dafür macht man das ganze ja) lässt sich mit diversen Mitteln umgehen. Da gab es vor einiger Zeit auch einen guten iX Artikel darüber.

Es muss kein Physischer PC im abgesperrten Raum sein, es gibt andere Möglichkeiten, die ich vorhin sozusagen augezählt habe.

 

Für DR kann man Lokale User nutzen. Man sollte ein DR Konzept nicht mit einem Security Konzept mischen. Es können die gleichen Dinge genutzt werden, aber müssen nicht.

 

Ohne Domäne sind die Clients halt nicht gemanaged.

 

https://epaper.heise.de/download/archiv/c8adeb8cabfb/ix.16.12.044-050.pdf

https://epaper.heise.de/download/archiv/c8aded56c803/ix.16.12.052-057.pdf

bearbeitet 3. Dezember 2020 von Dukel

[michelo82 12]

Ja richtig das DR-Konzept sollte da nicht vermischt werden. Aber stimmt, ein lokaler User könnte sich dennoch anmelden, auch bei einem Domänen-Mitglied.

Die Workstations haben kein Win10 Enterprise BS um Credentials Guard zu nutzen - das kann aber wiedderum auf den Adminhost, da es ein Server BS ist, genutzt werden.

bearbeitet 3. Dezember 2020 von michelo82

[Dukel 461]

Mich würde der geteilte Zugriff via VMWare Konsole stören und eher via RDP (und entsprechende Maßnahmen treffen, dass die Credentials nicht gespeichert werden) auf die Maschine. Mit Domain Join können die Settings per Richtlinie zentral gesteuert werden.

[michelo82 12]

Das wäre eine wichtige Maßnahme die Credentials zu schützen. Danke für die Links - die funktionieren aber leider nicht.

[Dukel 461]

Kein iX Abo?

 

Dann die iX 12/2016 nachbestellen.

[NorbertFe 2.175]

vor 43 Minuten schrieb michelo82:

Diejenigen die auf die Adminmaschinen Zugriff haben, haben ebenso Zugriff auf die VMWare Umgebung - es ist der gleiche Personenkreis. Wir vertrauen uns.

Das widerspricht aber etwas der Anforderung. Also entweder man trennt, oder man trennt nicht (und das betrifft genauso Out Of Band Zugriffe). Dann muss man aber auch deutlich weniger Aufwand betreiben. Ich bin dann bei Nils' Aussage, dass sowas die Forummöglichkeiten etwas überschreitet. ;)

bearbeitet 3. Dezember 2020 von NorbertFe

[michelo82 12]

vor 3 Stunden schrieb Dukel:

Kein iX Abo?

 

Dann die iX 12/2016 nachbestellen.

Doch. Nur führen die Links nicht dahin. Aber ich suche mal die 12/2016.

 

[NilsK 2.982]

Moin,

 

Dass ihr einander vertraut, ist prima, aber darum geht es ja gerade nicht. Es geht um Angreifer.

 

Und was man "müsste", hängt entscheidend von den Umständen des einzelnen Unternehmens ab. Das ist das, was ich mit Planung meine.

 

Gruß, Nils