Bedeutet die Virtualisierung eines Servers eine weitere Betriebssystemschicht zum Patchen und Aktualisieren, mehr Arbeit und ein höheres Risiko?

Ich habe eine Suche durchgeführt und nichts gefunden, was Probleme mit Patches und Systemaktualisierungen betrifft. Ich habe Richtlinien, die besagen, dass Server die erforderlichen Patches benötigen. Wenn ich einen VM-Host habe, ist das dann eine zusätzliche Ebene zum Patchen und Aktualisieren - auch mit Bare-Metal-Hypervisoren? Im Gegensatz zu einem Metall-Server? (dh mehr Arbeit und Prüfung und Dokumentation nach meinen Richtlinien).

Wie oft werden Typ 1 / Bare-Metal-Hypervisiere aktualisiert? Spielt das eine Rolle? Bringt die Tatsache, dass es sich um eine zusätzliche Softwareschicht handelt, mehr Komplexität und Risiken mit sich (Sicherheit und Zuverlässigkeit)? (zB 99% fehlerfreie Software x 99% fehlerfreie Software = 98% fehlerfreies System)?

(Meine praktischen Erfahrungen liegen mit VMWare Workstation und Server sowie VirtualBox vor.)

Ja, Produkte wie VMware sollten manchmal gepatcht werden ( die Updates sind kumulativ ), aber die Patches kommen seltener als bei einem Hauptbetriebssystem vor und der potenzielle Angriffsvektor ist geringer - Ihr Hypervisor sollte nicht öffentlich zugänglich sein .

Als Beispiel verwende ich VMware ESXi Version 5.0 (nicht 5.1) ...

ESXi 5.0 hat den folgenden Update-Zeitplan:

Zwischen 9/2011 und der Gegenwart wurden TEN- Updates für das ESXi 5.0-Produkt durchgeführt. Davon waren SIX sicherheitsgerichtete Updates, die in die Update-Pakete mit folgenden Beschreibungen eingearbeitet wurden:

"Sicherheitsanfälligkeit beim Analysieren von NFS-Datenverkehr in ESXi" - CVE-2012-2448 .

Diese Sicherheitslücken sind real, da sie manchmal allgemeine Linux-Sicherheitslücken widerspiegeln, aber ich denke, die meisten Organisationen sind nicht sehr anfällig für diese Risiken. Es ist jedoch Sache des Ingenieurs, dieses Risiko einzuschätzen. Möchten Ihre Benutzer massive Ausfallzeiten, um den folgenden Exploit zu beheben ?

"Das von ncpmount und mount.cifs verwendete Makro encode_name in misc / mntent_r.c in der GNU C-Bibliothek (auch bekannt als glibc oder libc6) 2.11.1 und früher verarbeitet Zeilenumbrüche in Mountpunktnamen nicht richtig, was lokale Benutzer erlaubt über eine gestaltete Mount-Anfrage einen Denial-of-Service (Mtab-Korruption) auslösen oder möglicherweise Mount-Optionen ändern und Privilegien erlangen. "

Vielleicht? Vielleicht nicht.

Ich führe den Update Manager von VMware aus , aktualisiere ihn jedoch nur, wenn ein Fehler vorliegt oder eine Funktionserweiterung erforderlich ist. Bei der Ausführung in einer Cluster-Konfiguration ist das Patchen ohne Ausfallzeiten für die ausgeführten VMs einfach. Wenn keine anderen zwingenden Gründe vorliegen, bemühe ich mich nur, vierteljährlich zu aktualisieren. Für einzelne Hosts ist ein vollständiger Neustart erforderlich, da die Patches als monolithische Images bereitgestellt werden.

Wenn ich ein VMware ESXi-Setup erbe oder auf einem System arbeite, das ich normalerweise nicht verwalte, werden häufig Hosts ausgeführt, auf denen noch nie VMware-Patches angewendet wurden. Das ist falsch!! Aber ich kann sehen, wie Administratoren diesen Fehler machen können, wenn die Systeme erst einmal laufen.

Dies ist eine ziemlich gute Frage, wenn Sie noch keine Erfahrung mit der Virtualisierung mit Bare-Metal-Hosts haben. Diese Vorgehensweise erfordert eine andere Denkweise als bei Hypervisoren, die als Dienst / Anwendung auf einem herkömmlichen Betriebssystem ausgeführt werden.

Nach meiner Erfahrung ist es wahrscheinlich fair zu sagen, dass ESX und HyperV insgesamt weniger Patches benötigen als herkömmliche Betriebssysteme. Dies bedeutet nicht , dass sie überhaupt kein Patching benötigen oder dass das Anwenden einiger Patches ungeachtet der "Notwendigkeit" nicht vorteilhaft wäre. Dies bedeutet jedoch, dass Unterbrechungen Ihrer Dienste zum Patchen des Hosts seltener und weniger häufig sein sollten mehr unter Ihrer Kontrolle. Es besteht ein potenzielles Sicherheitsrisiko für die Hypervisor-Betriebssysteme wie für alle anderen Betriebssysteme, und Sie können das Risiko zwar minimieren (z. B. die Hypervisor-Verwaltung nur in einem isolierten VLAN verfügbar machen, das von einem gefährdeten Server aus logischerweise nicht erreichbar ist). Es wäre töricht, so zu tun, als gäbe es überhaupt kein Risiko.

Wenn Sie also beispielsweise 4 nicht-virtuelle Server haben und diese alle auf denselben einzelnen virtualisierten Host verschieben, dann erhöhen Sie das Ausmaß der Unterbrechungen, die durch die Notwendigkeit verursacht werden könnten, das Hostsystem zu patchen (oder damit umzugehen) ein Hardware-Problem, etc, für diese Angelegenheit).

Ich würde zwar vorschlagen, dass das Risiko relativ gering ist (ich spreche von dem Unterschied zwischen dem Patchen eines virtuellen Hosts und dem Patchen, das einen Neustart erfordert, den Sie ohnehin für ein eigenständiges System ausführen müssten ). Es gibt kein Entrinnen von der Tatsache, dass die Auswirkungen hoch sind.

Warum machen wir das dann?

Der eigentliche Vorteil der Virtualisierung besteht darin, dass Sie mehrere Hosts einrichten und die Hosts so konfigurieren können, dass sie zusammenarbeiten. So können Gäste von einem Host auf den anderen verschoben werden, falls ein Host ausfällt oder Sie Patches planen möchten die Host-Systeme.

Auf diese Weise habe ich es geschafft, 5 ESX-Hosts nacheinander ohne Unterbrechung auf die 40 darauf laufenden virtuellen Server zu patchen . Dies ist einfach eine Frage von Skaleneffekten - sobald Sie über genügend potenzielle virtuelle Gastmaschinen verfügen, lohnt es sich, ein derart komplexes Setup zu erstellen und es mit den Tools zu verwalten, die @ewwhite in seiner Antwort erwähnt, und die Amortisation bei der Reduzierung der Risiken Du machst dir Sorgen, dass es sehr schnell geht.

Ein virtueller Server erfordert dieselbe Wartung und dieselben Patches wie ein physischer Server. Bare-Metal-Hypervisoren benötigen Updates, um die Sicherheit zu gewährleisten, aber auch um Fehler zu beheben und die Leistung zu verbessern. Je mehr Server Sie haben, desto mehr Arbeit müssen Sie leisten, um sie auf dem neuesten Stand zu halten. Dabei spielt es keine Rolle, ob sie physisch oder virtuell sind.

Basierend auf den obigen Antworten scheint es so zu sein: Die Virtualisierung eines Servers hat die Sicherheit und Zuverlässigkeit komplexer und risikoreicher gemacht. Diese müssen jedoch gegen die Vorteile abgewogen werden, die sich aus der Reduzierung von Ausfallzeiten durch die Virtualisierung eines Servers ergeben.

Wenn in Ihrer Umgebung Prüfungen, Tests und Dokumentationen erforderlich sind, muss der Kosten-Nutzen der zusätzlichen Arbeitslast einer virtualisierten Umgebung mit der Anzahl der von Ihnen beschäftigten Server und Systemmitarbeiter in Rechnung gestellt werden. In unserer Umgebung haben wir nicht die Zeit, den Audit-Trail für eine virtualisierte Umgebung zu pflegen. In unseren Geschäftsprozessen können wir einige Ausfallzeiten in Kauf nehmen, aber es dürfen kein Audit-Trail und keine Dokumentation fehlen.