Hypervisor Auswahl

Hypervisor in OpenStack

Ob OpenStack in privaten Rechenzentren oder als Public Cloud Service eingesetzt wird, die zugrunde liegende Virtualisierungstechnologie bietet Enterprise-Level-Fähigkeiten im Bereich Skalierbarkeit, Ressourceneffizienz und Uptime. Während solche High-Level-Vorteile in der Regel über viele OpenStack-unterstützte Hypervisor-Technologien zur Verfügung stehen, gibt es erhebliche Unterschiede in der Sicherheitsarchitektur und Funktionen für jeden Hypervisor, insbesondere bei der Betrachtung der Sicherheitsbedrohungsvektoren, die für elastische OpenStack-Umgebungen einzigartig sind. Da sich die Applikationen auf Single :term:Infrastructure-as-a-Service (IaaS)“ Plattformen konzentrieren, wird die Instanz auf der Hypervisor-Ebene vorrangig. Die Forderung nach sicherer Isolation gilt für Handels-, Regierungs- und Militärgemeinschaften.

Innerhalb des OpenStack-Frameworks können Sie unter vielen Hypervisor-Plattformen und entsprechenden OpenStack-Plug-ins auswählen, um Ihre Cloud-Umgebung zu optimieren. Im Rahmen dieses Leitfadens werden Hypervisor-Selektionsüberlegungen hervorgehoben, da sie sich auf Sicherheitsmerkmale beziehen, die für die Sicherheit entscheidend sind. Diese Erwägungen sind jedoch nicht als eine umfassende Untersuchung der Vor- und Nachteile von bestimmten Hypervisoren zu verstehen. NIST bietet zusätzliche Hinweise in der Sonderveröffentlichung 800-125, „* Leitfaden für Sicherheit für vollständige Virtualisierungstechnologien *“.

Auswahlkriterium

Als Teil Ihres Hypervisor-Auswahlprozesses müssen Sie eine Reihe wichtiger Faktoren berücksichtigen, um Ihre Sicherheitsposition zu erhöhen. Im Einzelnen müssen Sie sich mit diesen Bereichen vertraut machen:

  • Teamkompetenz

  • Produkt- oder Projektreife

  • Gemeinsame Kriterien

  • Zertifizierungen und Bescheinigungen

  • Hardware-Sorgen

  • Hypervisor vs. Baremetal

  • Zusätzliche Sicherheitsmerkmale

Darüber hinaus sind die folgenden sicherheitsrelevanten Kriterien sehr ermutigt, bei der Auswahl eines Hypervisor für OpenStack-Implementierungen ausgewertet zu werden: * Hat der Hypervisor eine Common Criteria Zertifizierung unterzogen? Wenn ja, zu welchen Ebenen? * Ist die zugrunde liegende Kryptographie von einem Dritten zertifiziert?

Teamkompetenz

Wahrscheinlich ist der wichtigste Aspekt bei der Hypervisor-Auswahl das Fachwissen Ihrer Mitarbeiter bei der Verwaltung und Pflege einer bestimmten Hypervisor-Plattform. Je vertrauter Ihr Team mit einem gegebenen Produkt, seiner Konfiguration und seinen Exzentrizitäten ist, desto weniger Konfigurationsfehler. Darüber hinaus, mit Personal-Know-how verteilt über eine Organisation auf einem bestimmten Hypervisor erhöht die Verfügbarkeit Ihrer Systeme, ermöglicht die Trennung von Aufgaben und lindert Probleme für den Fall, dass ein Teammitglied nicht verfügbar ist.

Produkt- oder Projektreife

Die Reife eines gegebenen Hypervisor Produkts oder Projektes ist auch für Ihre Sicherheitsposition entscheidend. Die Produktreife hat eine Reihe von Effekten, sobald Sie Ihre Cloud eingesetzt haben:

  • Verfügbarkeit von Fachwissen

  • Aktive Entwickler- und User-Communities

  • Aktualität und Verfügbarkeit von Updates

  • Inzidenzreaktion

Einer der größten Indikatoren für eine Reife des Hypervisor ist die Größe und Lebendigkeit der Gemeinschaft, die sie umgibt. Da dies die Sicherheit betrifft, beeinflusst die Qualität der Community die Verfügbarkeit von Fachwissen, wenn Sie zusätzliche Cloud-Betreiber benötigen. Es ist auch ein Zeichen dafür, wie weit der Hypervisor eingesetzt wird, was wiederum zur Kampfbereitschaft von Referenzarchitekturen und Best Practices führt.

Darüber hinaus hat die Qualität der Community, da sie einen Open-Source-Hypervisor wie KVM oder Xen umgibt, einen direkten Einfluss auf die Aktualität von Bugfixes und Sicherheitsupdates. Bei der Untersuchung von kommerziellen und Open-Source-Hypervisoren, müssen Sie in ihre Release-und Support-Zyklen sowie den Zeitraum zwischen der Ankündigung eines Bugs oder Sicherheitsproblem und ein Patch oder Antwort beachten. Schließlich variieren die unterstützten Fähigkeiten der OpenStack-Compute je nach dem gewählten Hypervisor. Siehe die OpenStack Hypervisor Support Matrix für OpenStack Compute Feature Unterstützung durch Hypervisor.

Zertifizierungen und Bescheinigungen

Eine weitere Überlegung bei der Auswahl eines Hypervisor ist die Verfügbarkeit von verschiedenen formalen Zertifizierungen und Bescheinigungen. Während es sich nicht um Anforderungen an Ihre spezifische Organisation handelt, sprechen diese Zertifizierungen und Bescheinigungen über die Reife, die Produktionsbereitschaft und die Gründlichkeit der Prüfung einer bestimmten Hypervisor-Plattform.

Gemeinsame Kriterien

Common Criteria ist ein international standardisierter Software-Evaluierungsprozess, der von Regierungen und kommerziellen Unternehmen genutzt wird, um Software-Technologien zu validieren, wie beworben. Im Regierungssektor beauftragt NSTISSP Nr. 11, dass US-Regierungsbehörden nur Software bescheinigen, die Common Criteria zertifiziert wurde, eine Politik, die seit Juli 2002 stattfindet.

Bemerkung

OpenStack wurde keiner Common Criteria Zertifizierung unterzogen, aber viele der verfügbaren Hypervisoren haben eine.

Neben der Validierung von Technologie-Fähigkeiten bewertet das Common Criteria-Verfahren, wie Technologien entwickelt werden.

  • Wie wird das Quellcode-Management durchgeführt?

  • Wie haben Benutzer Zugriff auf Build-Systeme?

  • Ist die Technik vor der Verteilung kryptographisch unterzeichnet?

Der KVM-Hypervisor wurde durch die US-Regierung und kommerzielle Distributionen zertifiziert. Diese wurden validiert, um die Laufzeitumgebung von virtuellen Maschinen voneinander zu trennen, so dass die Basistechnologie die Instanzisolation erzwungen wird. Neben der Isolierung der virtuellen Maschine wurde KVM Common Criteria zertifiziert nach …:

"...provide system-inherent separation mechanisms to the resources of virtual
machines. This separation ensures that large software component used for
virtualizing and simulating devices executing for each virtual machine
cannot interfere with each other. Using the SELinux multi-category
mechanism, the virtualization and simulation software instances are
isolated. The virtual machine management framework configures SELinux
multi-category settings transparently to the administrator."

Während viele Hypervisor-Anbieter wie Red Hat, Microsoft und VMware eine Common Criteria Certification erreicht haben, deren zugrunde liegendes zertifiziertes Feature-Set unterschiedlich ist, empfehlen wir die Bewertung von Lieferantenansprüchen, um sicherzustellen, dass sie die folgenden Anforderungen minimal erfüllen:

Identifizierung und Authentifizierung

Identifizierung und Authentifizierung mit Pluggable Authentication Modules (PAM) basierend auf Benutzerpasswörtern. Die Qualität der verwendeten Passwörter kann durch Konfigurationsoptionen erzwungen werden.

Audit

Das System bietet die Möglichkeit, eine Vielzahl von Ereignissen zu auditieren, einschließlich einzelner Systemaufrufe und Ereignisse, die von vertrauenswürdigen Prozessen generiert werden. Auditdaten werden in regulären Dateien im ASCII-Format gesammelt. Das System bietet ein Programm für die Suche nach den Audit-Datensätzen. Der Systemadministrator kann eine Regelbasis definieren, um die Überwachung auf die von ihnen interessierten Ereignisse zu beschränken. Dazu gehört auch die Möglichkeit, die Auditierung auf bestimmte Ereignisse, bestimmte Benutzer, bestimmte Objekte oder eine Kombination aus all dem zu beschränken. Audit-Datensätze können an einen Remote-Audit-Daemon übertragen werden.

Diskretionäre Zugangskontrolle

Discretionary Access Control (DAC) beschränkt den Zugriff auf Dateisystemobjekte auf ACL, die die Standard-UNIX-Berechtigungen für Benutzer, Gruppen und andere enthalten. Zugriffskontrollmechanismen schützen auch IPC-Objekte vor unbefugtem Zugriff. Das System enthält das ext4-Dateisystem, das POSIX-ACLs unterstützt. Dies ermöglicht die Definition von Zugriffsrechten auf Dateien innerhalb dieser Art von Dateisystem bis hin zur Granularität eines einzelnen Benutzers.

Mandatory Access Control

Mandatory Access Control (MAC) beschränkt den Zugriff auf Objekte auf der Grundlage von Etiketten, die Themen und Objekten zugeordnet sind. Sensitivitätsetiketten werden automatisch an Prozesse und Objekte angehängt. Die mit diesen Etiketten erzwungene Zutrittskontrollpolitik ergibt sich aus dem Bell-LaPadula model. SELinux-Kategorien sind an virtuelle Maschinen und deren Ressourcen angehängt. Die mit diesen Kategorien erzwungene Zugriffskontrollrichtlinie gewährt virtuellen Maschinen Zugriff auf Ressourcen, wenn die Kategorie der virtuellen Maschine mit der Kategorie der zugegriffenen Ressource identisch ist. Der TOE implementiert nicht hierarchische Kategorien, um den Zugriff auf virtuelle Maschinen zu kontrollieren.

Role-Based Access Control

Role-Based Access Control (RBAC) ermöglicht die Trennung von Rollen, um die Notwendigkeit eines leistungsstarken Systemadministrators zu vermeiden.

Object Reuse

Dateisystemobjekte, Speicher und IPC-Objekte werden gelöscht, bevor sie von einem Prozess, der zu einem anderen Benutzer gehört, wiederverwendet werden können.

Security Management

Die Verwaltung der sicherheitskritischen Parameter des Systems erfolgt durch administrative Benutzer. Ein Satz von Befehlen, die Root-Berechtigungen erfordern (oder bestimmte Rollen, wenn RBAC verwendet wird) werden für die Systemverwaltung verwendet. Sicherheitsparameter werden in bestimmten Dateien gespeichert, die durch die Zugriffssteuerungsmechanismen des Systems gegen unbefugten Zugriff durch Benutzer geschützt sind, die keine Administratorbenutzer sind.

Secure Communication

Das System unterstützt die Definition von vertrauenswürdigen Kanälen mit SSH. Die passwortbasierte Authentifizierung wird unterstützt. Für diese Protokolle wird in der ausgewerteten Konfiguration nur eine eingeschränkte Anzahl von Chiffre-Suiten unterstützt.

Storage Encryption

Das System unterstützt verschlüsselte Blockgeräte, um die Vertraulichkeit der Speicherung über dm_crypt zur Verfügung zu stellen.

TSF Protection

Während des Betriebs werden die Kernel-Software und die Daten durch die Hardware-Speicherschutzmechanismen geschützt. Die Speicher- und Prozessmanagementkomponenten des Kernels sorgen dafür, dass ein Benutzerprozess nicht auf Kernspeicher oder Speicherplatz zu anderen Prozessen zugreifen kann. Nicht-Kernel-TSF-Software und Daten werden durch DAC- und Prozessisolationsmechanismen geschützt. In der ausgewerteten Konfiguration besitzt die reservierte Benutzer-ID root die Verzeichnisse und Dateien, die die TSF-Konfiguration definieren. Im Allgemeinen sind Dateien und Verzeichnisse, die interne TSF-Daten enthalten, wie Konfigurationsdateien und Batch-Job-Warteschlangen, auch vor dem Lesen durch DAC-Berechtigungen geschützt. Das System und die Hardware- und Firmwarekomponenten müssen physisch vor unbefugtem Zugriff geschützt werden. Der Systemkernel vermittelt den Zugriff auf die Hardware-Mechanismen selbst, außer dem Programm sichtbare CPU-Befehlsfunktionen. Darüber hinaus sind Mechanismen zum Schutz gegen Stapelüberlaufangriffe vorgesehen.

Kryptographie-Standards

Mehrere Kryptographiealgorithmen stehen in OpenStack zur Identifikation und Autorisierung, Datenübertragung und zum Schutz von Daten zur Verfügung. Bei der Auswahl eines Hypervisor empfehlen wir folgende Algorithmen und Implementierungsstandards:

Algorithmus

Schlüssellänge

Sinn und Zweck der Sache

Sicherheitsfunktion

Implementierungsstandard

AES

128, 192 oder 256 Bits

Verschlüsselung/Entschlüsselung

Geschützte Datenübertragung, Schutz für Daten

RFC 4253

TDES

168 Bits

Verschlüsselung/Entschlüsselung

Geschützte Datenübertragung

RFC 4253

RSA

1024, 2048 oder 3072 Bits

Authentifizierung, Schlüsselaustausch

Identifizierung und Authentifizierung, geschützte Datenübertragung

US NIST FIPS PUB 186-3

DSA

L=1024, N=160 Bits

Authentifizierung, Schlüsselaustausch

Identifizierung und Authentifizierung, geschützte Datenübertragung

US NIST FIPS PUB 186-3

Serpent

128, 192 oder 256 Bits

Verschlüsselung/Entschlüsselung

Schutz der Daten in Ruhezustand

http://www.cl.cam.ac.uk/~rja14/Papiere/serpent.pdf

Twofish

128, 192 oder 256 bit

Verschlüsselung/Entschlüsselung

Schutz der Daten in Ruhezustand

https://www.schneier.com/paper-twofish-paper.html

SHA-1

Message Digest

Schutz der Daten in Ruhezustand, geschützte Datenübertragung

US NIST FIPS PUB 180-3

SHA-2 (224, 256, 384 oder 512 Bits)

Message Digest

Schutz für Daten in Ruhezustand, Identifikation und Authentifizierung

US NIST FIPS PUB 180-3

FIPS 140-2

In den Vereinigten Staaten zertifiziert das Nationale Institut für Wissenschaft und Technologie (NIST) kryptographische Algorithmen durch einen Prozess, der das Cryptographic Module Validation Program bekannt ist. NIST bescheinigt Algorithmen zur Konformität mit dem Federal Information Processing Standard 140-2 (FIPS 140-2), die …:

"... Products validated as conforming to FIPS 140-2 are accepted by the Federal
agencies of both countries [United States and Canada] for the protection of
sensitive information (United States) or Designated Information (Canada).
The goal of the CMVP is to promote the use of validated cryptographic
modules and provide Federal agencies with a security metric to use in
procuring equipment containing validated cryptographic modules."

Bei der Bewertung von Basis-Hypervisor-Technologien ist zu prüfen, ob der Hypervisor gegen FIPS 140-2 zertifiziert wurde. Nicht nur die Konformität gegen die FIPS 140-2, die pro US-Regierungspolitik beauftragt ist, zeigt die formale Zertifizierung an, dass eine gegebene Implementierung eines kryptographischen Algorithmus auf Übereinstimmung mit der Modulspezifikation, den kryptographischen Modulhäfen und den Schnittstellen überprüft wurde; Rollen, Dienste und Authentifizierung; endliches Statusmodell; physische Sicherheit; Betriebsumfeld; kryptographisches Schlüsselmanagement; elektromagnetische Störung/elektromagnetische Verträglichkeit (EMI/EMV); Selbsttests; Designversicherung; und Abschwächung anderer Angriffe.

Hardware-Sorgen

Wenn Sie eine Hypervisor-Plattform auswerten, sollten Sie die Supportfähigkeit der Hardware berücksichtigen, auf der der Hypervisor ausgeführt wird. Darüber hinaus betrachten die zusätzlichen Funktionen in der Hardware und wie diese Features von dem Hypervisor unterstützt werden, die Sie als Teil der OpenStack-Bereitstellung gewählt haben. Zu diesem Zweck haben Hypervisoren jeweils eigene Hardware-Kompatibilitätslisten (HCLs). Bei der Auswahl kompatibler Hardware ist es wichtig, im Voraus zu wissen, welche hardwarebasierten Virtualisierungstechnologien aus Sicherheitsgründen wichtig sind.

Beschreibung

Technologie

Erläuterung

I/O MMU

VT-d / AMD-Vi

Erforderlich zum Schutz von PCI-Passthrough

Intel Trusted Execution Technology

Intel TXT / SEM

Erforderlich für dynamische Bescheinigungsleistungen

PCI-SIG I/O-Virtualisierung

SR-IOV, MR-IOV, ATS

Erforderlich für eine sichere Freigabe von PCI Express Geräten

Netzwerkvirtualisierung

VT-c

Verbessert die Leistung von Netzwerk-I/O auf Hypervisoren

Hypervisor gegen Bare Metal

Es ist wichtig, den Unterschied zwischen der Verwendung von Linux-Containern (LXC) oder Bare-Metal-Systemen im Vergleich zu einem Hypervisor wie KVM zu erkennen. Im Einzelnen basiert der Schwerpunkt dieses Sicherheitsleitfadens weitgehend auf einer Hypervisor- und Virtualisierungsplattform. Wenn jedoch Ihre Implementierung die Verwendung einer Baremetal- oder LXC-Umgebung erfordert, müssen Sie auf die besonderen Unterschiede in Bezug auf den Einsatz dieser Umgebung achten.

Stellen Sie sicher, dass Ihre Endbenutzer, dass der Knoten vor der Wiederherstellung ordnungsgemäß von ihren Daten saniert wurde. Darüber hinaus müssen Sie vor der Wiederverwendung eines Knotens versichern, dass die Hardware nicht manipuliert oder anderweitig beeinträchtigt wurde.

Bemerkung

Während OpenStack ein Bare-Metal-Projekt hat, geht eine Diskussion über die besonderen Sicherheitsimplikationen des Bare-Metal-Dienstes über den Rahmen dieses Buches hinaus.

Aufgrund der zeitlichen Einschränkungen des Buchsprints entschied sich das Team, KVM als Hypervisor in unseren Beispielimplementierungen und Architekturen zu nutzen.

Bemerkung

Es gibt einen OpenStack-Sicherheitshinweis, der sich auf die Verwendung von LXC in Compute bezieht <https://bugs.launchpad.net/ossn/+bug/1098582>`_.

Hypervisor Speicheroptimierung

Viele Hypervisoren nutzen Speicheroptimierungstechniken, um Speicher auf virtuelle Gastsystemen überzubelegen. Dies ist eine nützliche Funktion, mit der Sie sehr dichte Rechencluster einsetzen können. Eine Möglichkeit, dies zu erreichen, ist durch De-Duplizierung oder Freigabe von Speicherseiten. Wenn zwei virtuelle Maschinen identische Daten im Speicher haben, gibt es Vorteile, um sie auf denselben Speicher zu verweisen.

Typischerweise wird dies durch Copy-On-Write (COW)-Mechanismen erreicht. Diese Mechanismen haben sich als anfällig für Side-Channel-Angriffe, wo eine VM etwas über den Zustand eines anderen erfahren kann und ist nicht geeignet für Multi-Tenant-Umgebungen, wo nicht alle Tenant vertraut sind oder das gleiche Maß an Vertrauen teilen.

KVM Kernel Samepage Merging

Einleitung in den Linux-Kernel in Version 2.6.32, Kernel Samepage Merging (KSM) konsolidiert identische Speicherseiten zwischen Linux-Prozessen. Da jeder Gast VM unter dem KVM-Hypervisor in seinem eigenen Prozess läuft, kann KSM verwendet werden, um den Speicherverbrauch zwischen VMs zu optimieren.

XEN Transparent Page Sharing

XenServer 5.6 enthält eine Speicher-Overcommitment-Funktion mit dem Namen Transparent Page Sharing (TPS). TPS scannt Speicher in 4 KB Chunks für alle Duplikate. Wenn gefunden, verwirft der Xen Virtual Machine Monitor (VMM) eines der Duplikate und zeichnet die Referenz des zweiten auf.

Sicherheitsüberlegungen zur Speicheroptimierung

Traditionell sind Speicher-Deduplizierungssysteme anfällig für Seitenkanalangriffe. Sowohl KSM als auch TPS haben gezeigt, dass sie anfällig für irgendeine Form von Angriff sind. In akademischen Studien konnten Angreifer Softwarepakete und Versionen, die auf benachbarten virtuellen Maschinen laufen, sowie Software-Downloads und andere sensible Informationen identifizieren, indem sie die Speicherzugriffszeiten auf den Angreifer VM analysierten.

Wenn eine Cloud-Implementierung eine starke Trennung der Tenant erfordert, wie es bei öffentlichen Clouds und einigen privaten Clouds der Fall ist, sollten die Deployer TPS- und KSM-Speicheroptimierungen deaktivieren.

Zusätzliche Sicherheitsmerkmale

Eine andere Sache zu suchen bei der Auswahl einer Hypervisor-Plattform ist die Verfügbarkeit von bestimmten Sicherheits-Features. Besonders Merkmale. Zum Beispiel Xen Server XSM oder Xen Security Modules, sVirt, Intel TXT oder AppArmor.

Die folgende Tabelle ruft diese Funktionen durch gängige Hypervisor-Plattformen auf.

XSM

sVirt

TXT

AppArmor

cgroups

MAC-Policy

KVM

X

X

X

X

X

Xen

X

X

ESXi

X

Hyper-V.

Bemerkung

Die in dieser Tabelle enthaltenen Funktionen gelten möglicherweise nicht für alle Hypervisoren oder direkt zwischen Hypervisoren.

Literaturverzeichnis