"Es gibt Dienste, die public sein müssen, weil das der Zweck des Servers ist, also kann alles public sein" Komisches Argument.
Nein, ich denke, wir reden aneinander vorbei, denn du hast den Sinn meiner Aussage nicht verstanden...
Natürlich gibt es Dienste, die für public geschaffen sind, keine Frage... Nur wenn man mit der gleichen Argumentation rangeht, wie du sie getätigt hast, dann muss man folgerichtig auch bei allen anderen Diensten beim Thema Sicherheit so Argumentieren. Und da gehört eine VPN Lösung ebenso dazu. Denn diese macht nix anderes, als einen Dienst im INet bereit zu stellen. Und du als Betreiber musst dich zwingend darauf verlassen können, dass diese Lösung mehr oder weniger sicher ist.
Scheinbar bist du dir nach den Argumenten sicher, dass die VPN Lösung dies sein muss, beim VMware WebClient hingegen nicht. Und das ist Messen mit zweierlei Maß. Bei einer Lösung zweifelst du, bei der anderen bist du dir hingegen sicher. Dennoch kennst du in beiden Lösungen NULL! Codezeilen. Also reine Bauchgefühlargumentation ohne trivialen Hintergrund.
Ein VPN hat ja wohl wesentlicher weniger Code und Angriffsfläche als dieses massive Konglomerat an Diensten, die ein ESXi so rumschleppt.
Dein Argument besteht also im Wesentlichen aus "Schultern zucken, bringt eh alles nix, lassen wirs gleich offen". Und dann wundert man sich über die andauernden Meldungen über Datenklau, die bösen Hacker sind schuld und die Strafen müssen erhöht werden, statt die Spaßadmins einfach mal ihren Job machen.
Der erste Part ist quatsch... Es hat nix mit der Anzahl der Codezeilen zu tun. Ein hochkomplexes Programm kann weitaus sicherer sein, als ein nur wenige Codezeilen enthaltenes Anderes, wo aber ein fataler Bug/Sicherheitslücke reinprogrammiert wurde. Auch wenn natürlich mit steigender Anzahl an Codezeilen das Risiko potentiell höher wird, heist das aber lange nicht, das dies pauschal unsicherer ist. Im Gegenteil, es hängt massiv davon ab, wie sich der Programmierer darauf versteht. -> und wie die Software mit Sicherheitspatches bedient wird.
Zum anderen, woher interpretierst du das bitte?
Ich sagte: "Und wenn, dann schleift man sowas über einen FrontEnd Server, der in ner DMZ steht und optimalerweise auch nix weiter macht, sondern nur den WebClient bereit stellt."
Die Begriffe sollten dir denke ich geläufig sein, wenn du dich in der Lage siehst, dies und jenes als Sicher/Unsicher einzuschätzen
Von "lassen wirs gleich offen" kann also nicht die Rede sein...
In unserem Fall würde eine Webveröffentlichung wenn dann über ein TMG Server laufen. Gegen diesen muss man sich via Useraccount/PW authentifizieren. Das läuft über https und ist somit vollverschlüsselt -> erst dann bekommt man seine WebClient Session, diese läuft auf dem WebClient Serverdienst, der auf ner Kiste stehend in der DMZ tuckert und wo man sich erneut gegen den SSO Dienst vom VCenter authentifizieren muss (wobei noch nicht 100% klar ist, ob man das ggf. weiterreichen kann)
Das gleiche Verfahren nutzt man beispielsweise bei der Webveröffentlichung von Sharepoint, Exchange OWA oder weis der Teufel welchen anderen Sachen... Dort gibts den gleichen Aufbau von Access Gateway (TMG/UAG), FrontEnd Server (möglicherweise in der DMZ) und BackEnd Server intern im LAN.
Die einzige Angriffsfläche, die hier besteht, ist die Infiltrierung des TMG/UAG Servers bzw. anderen Lösungen, die als reverse Proxy bzw. SSL Gateway fungieren. Nur sind diese Server exakt für diesen Einsatz geschaffen... -> somit kannst du auch mit den selben Sicherheitsanforderungen an diese rantreten, wie sie deine VPN Lösung von dir bekommt.
So und jetzt nochmal die Frage, was für triviale Gründe kannst du aufzeigen, die den Einsatz des WebClients via public Access, https gesichert, gegen TMG Authentifiziert, als unsicher abtun würden!?
Aber was heißt das nun genau? Ist doch klar dass keine Funktionen einer virtuellen Maschine ausgeführt werden, wenn diese heruntergefahren ist.
Sollte man nun bevor man eine VM verschiebt den Host in den Wartungsmodus setzen? Oder dient der Wartungsmodus lediglich um ESXi zu aktualisieren?
Ne, anders... Die VM(s) laufen ja optimalerweise weiter. Denn man verwendet die ESXi Server ja idR in einem Clusterverbund. Somit werden die VMs schön von Host zu Host geschoben...
Musst du nun Wartungsarbeiten an einem Host durchführen (beispielsweise das Einspielen von Patches, Ändern von irgendwelchen Einstellungen oder auch beispielsweise das Erweitern des Hosts mit Hardware oder Software), versetzt du den Host in den Wartungsmodus.
Im Wartungsmodus werden die Clusterdienste beendet und vorher alle laufenden VMs auf andere Hosts im Cluster migriert. -> die VMs laufen somit alle samt weiter, wärend dieser eine Host eben nur noch die Basisfunktionalitäten ausführt. -> und man kann ihn danach so verändern, wie man es wünscht.
Zum anderen, nein... Wenn du eine VM verschiebst, muss der Host nicht in den Wartungsmodus. Was auch gar nicht gehen würde. Denn wenn du den Wartungsmodus in einem Clusterverbund aktivierst, werden automatisch alle VMs verschoben, die dieser Host bereit stellt.
