Hyper-V-Cluster; Workgroup oder Domain oder welchen Tod will man sterben?

[Marco31 37]

Hallo Leute,

 

ich schon wieder, sorry dass ich hier das Forum gerade mit meine Fragen bombardiere  Aber ich muss hier Entscheidungen treffen mit denen ich dann vermutlich einige Jahre leben muss, daher ist jede Hilfe wertvoll.

 

In dem Thread hier (https://www.mcseboard.de/topic/231670-frage-2-hyper-v-hosts-an-einem-san/) waren ja schon einige Stimmen pro und contra Hyper-V-Cluster in der Workgroup zu lesen. Leider hat sich jetzt durch Veeam B&R ein weiteres unschönes Problem ergeben; um einen Hyper-V-Workgroup-Cluster zu sichern, muss man auf den Hyper-V-Hosts entweder die Remote-UAC ausschalten oder für die Verbindung von Veeam zum Cluster DEN Administrator-Account auf den Hyper-V-Hosts nutzen. Eigentlich mal wieder zwei Dinge die man NICHT tun sollte... 

Jetzt stellt sich für mich die Frage welche Kröte ich schlucke; die oben genannten Fakten des Workgroup-Clusters oder packe ich den Cluster in meine Domain, wo ich alle Admin-Konten in den Protected Users habe (bis auf den einen, dessen PW liegt im Tresor), aber auch alle anderen Nachteile der Domänenmitgliedschaft habe; und eben auch die Vorteile der Verwaltbarkeit.

Leider ist Netzwerksegmentierung und damit ein Management-VLAN aus Gründen (noch) nicht möglich, daher ist das derzeit keine Option die die Sicherheit erhöhen würde.

Ich erwarte hier natürlich nicht "die Lösung" des Problems, letztendlich muss ich das ja selbst entscheiden. Ich würde aber gerne mal verschiedene Meinungen dazu hören, schadet ja nie...

 

bearbeitet vor 1 Stunde von Marco31
Link

[NorbertFe 2.274]

Fragen wir doch mal, was du dir vom Workgroup Cluster versprichst. Meiner Erfahrung nach, dürfte das in vielen Umgebungen nicht zwingend zu mehr Sicherheit sondern zu mehr Umgehungslösungen führen. Die Diskussion dazu im anderen Thread führte ja offenbar zu deiner Testumgebung. Evtl. nochmal zurück an den Anfang?

[Marco31 37]

Ja,  da liegst du schon richtig. Es war auf jeden Fall der Gedanke, die Sicherheit damit etwas zu verbessern. Leider sind da halt dann die oben genannten Dinge, die das ganze dann wieder ins Gegenteil verdrehen... Ich hätte kein Problem mit zurück auf Anfang, dafür habe ich das ganze ja erstmal eher als Test aufgesetzt. Zurzeit habe ich ehrlich gesagt eher nicht die Einschätzung, dass der Hyper-V-Cluster in der Workgroup unter den oben genannten Voraussetzungen eine große Verbesserung der Sicherheit darstellt im Gegensatz zur Domänenmitgliedschaft.

[testperson 1.856]

Hi,

 

vor 14 Minuten schrieb Marco31:

Leider ist Netzwerksegmentierung und damit ein Management-VLAN aus Gründen (noch) nicht möglich, daher ist das derzeit keine Option die die Sicherheit erhöhen würde.

ich würde - losgelöst von Workgroup / Domain - ASAP "Gründe" beseitigen.

 

vor 15 Minuten schrieb Marco31:

Leider hat sich jetzt durch Veeam B&R ein weiteres unschönes Problem ergeben; um einen Hyper-V-Workgroup-Cluster zu sichern, muss man auf den Hyper-V-Hosts entweder die Remote-UAC ausschalten oder für die Verbindung von Veeam zum Cluster DEN Administrator-Account auf den Hyper-V-Hosts nutzen.

Die Frage wäre, ob man den Admin Approval Mode nicht generell auch für den Built-In Admin aktiviert (User Account Control Admin Approval Mode for the Built-in Administrator account - Windows 10 | Microsoft Learn).

 

Gruß

Jan

[NilsK 3.043]

Moin,

 

wenn du schon auf der Ebene nachdenkst und argumentierst - was sinnvoll ist -, dann solltest du in Betracht ziehen, einen separaten Infrastruktur-Forest für deine Host-Umgebung einzurichten. Dort hast du dann die Vorteile der Domänenverwaltung und kannst die Domäne getrennt von deiner Produktionsdomäne absichern. Sollte es dort dann ein Problem geben, ist der andere Forest nicht automatisch mit korrumpiert.

 

Ich stimme aber auch Jan zu - das Niveau, das du erreichen willst, ist mit den "Gründen", die du nebulös anführst, nicht vereinbar. An die wirst du auch ran müssen. 

 

Gruß, Nils

 

bearbeitet vor 57 Minuten von NilsK

[Marco31 37]

vor 15 Minuten schrieb NilsK:

Moin,

 

wenn du schon auf der Ebene nachdenkst und argumentierst - was sinnvoll ist -, dann solltest du in Betracht ziehen, einen separaten Infrastruktur-Forest für deine Host-Umgebung einzurichten. Dort hast du dann die Vorteile der Domänenverwaltung und kannst die Domäne getrennt von deiner Produktionsdomäne absichern. Sollte es dort dann ein Problem geben, ist der andere Forest nicht automatisch mit korrumpiert.

 

Ich stimme aber auch Jan zu - das Niveau, das du erreichen willst, ist mit den "Gründen", die du nebulös anführst nicht vereinbar. An die wirst du auch ran müssen. 

 

Gruß, Nils

 

Die "Gründe" sind einfach; wir hängen an einem Rechenzentrum das die Firewall und das damit verbundene Routing kontrolliert. Da komme ich nicht dran. Leider reicht auch mein Know-How nicht aus, um z.B. einfach mal noch ne zweite Firewall "davor" zu setzen im Produktivnetz. Und Hilfe darf man da leider nicht erwarten, da ist Personal dünn gesät und gutes erst recht... Ich muss also erstmal mit dem klar kommen was ich habe und was ich beeinflussen kann.

 

[testperson 1.856]

An der Stelle könnte man darüber nachdenken, an den Hyper-V Hosts - losgelöst ob Domain / Workgroup - per Windows Firewall eine Deny In- / Outbound Regel zu erstellen, die eben die IP Range(s) der Workloads / restlichen Systeme abdeckt. Auf den restlichen Systemen wird das Ruleset dann einfach "umgekehrt" implementiert.

 

Zwischen Hyper-V Hosts und Veeam Server bzw. ggfs. zwischen Veema Server und Workloads müsstest du dann etwas granularer rangehen. Bzw. auch wenn die Hosts in der Domain sind.

bearbeitet vor 44 Minuten von testperson

[Marco31 37]

Klingt schon mal nach ner Idee... Also auf den Hyper-V-Hosts Deny für alle IP-Adressen der Hosts und Clients, abgesehen vom Backup-Server und dem Backup-Proxy... Aber würde ich damit dann nicht nur das Management-Netz der Hyper-V-Hosts beschränken, sondern auch das VM-Netz? Das wäre natürlich dann ziemlich b***d 

Wäre natürlich auch recht Wartungsintensiv in Sachen neue Hosts/Clients, je nach IP Range.