macOS als Gast und im Host

Ich möchte macOS High Sierra als Gast mit macOS auf dem Host installieren, möchte aber wissen, welche Virtualisierungssoftware entweder VirtualBox oder VMware die besten Sicherheitsoptionen zwischen Gast und Host bietet.

Zum Beispiel möchte ich mehrere VMs mit ihrem eigenen festplattenverschlüsselten (Filevault) Boot-/Firmware-Passwort oder einem anderen Gastmechanismus so erstellen, dass der Host bei Ausfall der VM nur die VM löschen kann, aber keine andere Weg könnte den Inhalt der Festplatte neben wahrscheinlich Brute-Force es von der Host-Konsole sehen.

Der Zugriff auf die Gast-VM kann über VNC/Remote-Desktop/ssh erfolgen, sie befinden sich jedoch in einer gemeinsam genutzten Umgebung (Rack mit mehreren Mac-Minis), in der zumindest bei Ausfall von VMs zusätzliche Sicherheit erforderlich ist, da ein UP-Vorgang sehr einfach sein könnte der HOST an die Konsole anhängen.

Ich bin mir nicht sicher, was Sie hier fragen.... Sowohl VB als auch VMware ermöglichen es Ihnen, Ihre VMs zu verschlüsseln. macOS ermöglicht es Ihnen, das Dateisystem der Festplatte (in diesem Fall virtuell) zu verschlüsseln, von der es gebootet wird. VB ist ziemlich gut darin, nur zuzulassen, dass die VMs des Benutzers nur vom Benutzer gestartet werden (kann nicht mit VMware sprechen; ich benutze es nicht genug). Allerdings sehe ich auch keinen Vorteil darin, ein GUI-zentriertes Betriebssystem als Gast auf einem GUI-zentrierten Betriebssystem in einer gemeinsam genutzten (gehosteten) Umgebung zu verwenden. Was genau hast du vor?
Grundsätzlich möchte ich verhindern, dass die Administratoren, die den Host verwalten, eine VM starten und Inhalte daraus extrahieren. Ich weiß, dass sie sie starten könnten und sich fragen, ob es neben den Gasteinstellungen eine Passwortabfrage oder etwas gibt, um dies besser zu sichern
Dies könnte eine gute Lektüre sein: virtualbox.org/manual/ch13.html
Es ist nicht ganz klar, was Ihr tatsächliches Bedrohungsmodell ist, aber ich habe die Nebenfragen herausgeschnitten und die Hauptfrage direkt beantwortet. Fühlen Sie sich frei, eine Folgefrage zu stellen, indem Sie hier und @ me in Kommentaren zu meiner Antwort verlinken, wenn Sie Hilfe bei der Bearbeitung / Verlinkung wünschen.

Antworten (2)

Dies wäre mit beiden vorgeschlagenen VM-Software trivial.

Erstellen Sie ein verschlüsseltes Sparse-Disk-Image, das groß genug ist, um den Gastspeicher aufzunehmen, und erstellen Sie dann Ihre VM, sobald Sie das sichere Disk-Image gemountet haben.

Durch die Kontrolle der Verschlüsselungs-Passphrase dieses Stores können andere Administratoren den Container nur löschen, nicht mounten und lesen.

Daran habe ich nicht gedacht, scheint aber eine gute Lösung zu sein :-)
Was ist der Hauptunterschied zwischen der Verwendung eines Sparse-Datenträgers oder eines Datenträgerabbilds mit Lese-/Schreibzugriff, die beide funktionieren könnten?
@nbari Das wäre eine gute Frage für sich. Mal sehen, ob jemand danach gefragt hat. was TM betrifft - null Unterschied.

Ich stimme der Antwort von @bmike zu und wollte oben einen Kommentar abgeben, aber ich habe nicht genügend Reputationspunkte.

Mein Setup ist:

  • APFS-Dateisystem auf dem Host.
  • Verschlüsseltes .sparsebundle-Image für jede Gast-VM.
  • TimeMachine (und/oder Arq oder ein anderer Sicherungsmechanismus), der so konfiguriert ist, dass nur das nicht gemountete Sparse-Bundle gesichert wird.

Sie möchten Sparse-Bundles, weil sie tatsächlich aus kleinen 8-MB-Datenbändern bestehen und nicht aus einer riesigen einzelnen Datei für das gesamte Disk-Image. Dies bedeutet, dass die Sicherung viel weniger dauert, da nur die geänderten Bänder gesichert werden, anstatt bei jeder Ausführung der Sicherung das gesamte Disk-Image zu sichern.

Sie möchten APFS, weil Sie damit schnell Snapshots und sogar Klone erstellen können, ohne zusätzlichen Speicherplatz zu belegen (bis sich die Dinge ändern).

Sie möchten vermeiden, die gemounteten Sparse-Bundles zu sichern, da Sie sonst den gesamten oben besprochenen Vorteil verlieren, dass die VM in winzige verschlüsselte Bänder aufgeteilt ist.