Softwareentwicklung für sichere Systeme

Unikernel: Virtualisierung trifft Containerisierung

5. Oktober 2022, 8:00 Uhr | Von Ian Ferguson

Die Vorteile der Virtualisierung und der Containerisierung verbindet die Unikernel-Technik. Sie bietet ein hohes Maß an Sicherheit in Verbindung mit optimierter Leistung und geringem Speicherbedarf. Die Technik eignet sich speziell für unternehmenskritische Anwendungen.

Die Technik der Virtualisierung, bei der mehrere Betriebssysteme auf gemeinsam genutzter Hardware ausgeführt werden können, wird äußerst gut verstanden, wenngleich sie etwas ineffizient in der Nutzung der Ressourcen ist. Noch vor wenigen Jahrzehnten verwendete jeder virtuelle Maschinen (VM), um Infrastruktur zu betreiben und zu verwalten. In jüngster Zeit werden dafür Container mit Systemen wie Docker und Kubernetes eingesetzt.

Ursprünglich basierte das System der Virtualisierung auf der Implementierung einer Reihe von VMs. Jede VM muss ihre eigene Instanz eines Betriebssystems ausführen, was die Verantwortung verdoppelt. Auch ist es schwierig, eine solche Infrastruktur zu verwalten, da es mehrere Server gibt, die alle unabhängige virtuelle Maschinen sind.

Die Bereitstellung von Software in einem System mit virtuellen Maschinen kann auf zwei Arten erfolgen:

Das Build-System kann ein komplettes Image einer VM mit integrierter Software erstellen, und die VM wird neu gestartet, sobald das Update eintrifft.
Das Build-System erzeugt nur das Softwarebündel, das mithilfe einer Sammlung von Skripten auf die Server hochgeladen wird.

Beide Ansätze erfordern eine komplexe Einrichtung und führen letztendlich zu Inkonsistenzen zwischen VMs. Der Administrator hat jedoch für jeden Aspekt des Systems die vollständige Kontrolle über die Umgebung und kann sie entsprechend den spezifischen Anforderungen konfigurieren. Das Debugging ist relativ einfach, da man sich direkt mit einer VM verbinden kann.

Container versuchen, das gleiche Konzept wie virtuelle Maschinen zu erreichen, vermeiden aber doppelten Aufwand zwischen Maschinen. Anstatt ein komplettes Betriebssystem für eine Anwendung zu laden, können Docker-Container den Kernel des Host-Betriebssystems verwenden und gleichzeitig anwendungsspezifische Bibliotheken und Programme nachladen. Durch die Anpassung des Containers und seines Images ist es möglich, die spezifischen Bibliotheken und die Konfiguration, die Ihre Anwendung verwenden wird, fein abzustimmen. Dies führt zu Leistungssteigerungen, ohne dass der Overhead eines kompletten Betriebssystems anfällt.

Container lassen sich leicht auf Entwicklungsmaschinen ausführen. Auch der Bereitstellungsprozess selbst ist viel einfacher, da nur vorgefertigte Container in ein Container-Repository hochgeladen werden und die Produktionssysteme die aktualisierte Version abrufen können.

Der containerbasierte Ansatz hat aber auch seine Schattenseiten. Die Software muss für die Verwendung in Containern angepasst (containerisiert) werden, und das kann schwierig werden, insbesondere bei älteren Codebasen. Bei Containern gibt es viel mehr Konfigurationen für die Ressourcenzuweisung und Interop-Fähigkeiten, sodass sie leicht falsch konfiguriert werden können.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Unikernel – Vorteile und Grenzen

Der nächste logische Schritt in der Entwicklung von VMs zu Containern sind Unikernels, die versuchen, die Konzepte von Containern noch weiter zu entwickeln. Unikernels sind im Grunde genommen eine Reihe von vorgefertigten Binärbibliotheken. Unikernels übernehmen keine Ressourcenzuweisung. Der Hypervisor übernimmt die direkte Hardwareinteraktion. Alle anwendungsspezifischen Systemaufrufe werden so nah wie möglich an die Anwendung herangeführt. Dies wird im Hypervisor gehandhabt. Das Unikernel-Konzept zielt darauf ab, die Sicherheitsvorteile der Partitionierung auf VM-Ebene mit den Geschwindigkeits- und Platzvorteilen von Containern zu verbinden.

Bild 1 verdeutlicht den Unterschied zwischen den verschiedenen Ansätzen. Für sichere Systeme sollte ein Typ-1-Hypervisor – ohne zugrunde liegendes Hilfssystem – verwendet werden, der direkt auf der Hardware läuft und virtuelle Maschinen lädt. Hypervisors, die sich auf ein zugrunde liegendes »Host-Betriebssystem« stützen, stellen eine Schwachstelle in den Systemen dar.

Unikernels haben sogar weniger Overhead als Container und sind schlanker, was die Leistung potenziell verbessern kann. Außerdem wird die Sicherheit durch den Verzicht auf einen Kernel mit mehreren Benutzern und mehreren Adressräumen drastisch verbessert.

Vergleich eines Betriebssystems mit einem Unikernel

Im Vergleich zu einem Betriebssystem weisen Unikernel erhebliche Sicherheitsvorteile auf. Es gibt aber auch Nachteile.

Ein wichtiger Vorteil ist, dass Unikernels im Gegensatz zu Betriebssystemen im Benutzer- und nicht im Kernelmodus laufen. Auf hohem Niveau ist der Kernelmodus im Allgemeinen für die niedrigsten und vertrauenswürdigsten Funktionen des Betriebssystems reserviert.

Abstürze im Kernelmodus sind katastrophal; sie führen zum Stillstand des gesamten Systems. Im Benutzermodus hat der ausführende Code keine Möglichkeit, direkt auf Hardware oder Referenzspeicher zuzugreifen. Dies ist der Hauptgrund warum aktuell die Verwendung von Unikerneln in Erwägung gezogen wird. Es vergeht kaum eine Woche, in der nicht über einen Cyberangriff auf kritische Infrastrukturen, ein Unternehmen oder ein Bundesunternehmen berichtet wird. Das Betriebssystem ist eine Schwachstelle.

Einer der wichtigsten Nachteile von Unikernel ist, dass sie nur einen Prozess und einen Benutzer haben. Das Hinzufügen eines Prozessmanagements ist mit erheblichem Aufwand verbunden. Es muss eine Möglichkeit geben, einen Prozess zu starten/stoppen/inspizieren, die Kommunikation zwischen den Prozessen sicherzustellen usw. Mehrere Benutzer erfordern Autorisierung und Authentifizierung, Ressourcenisolierung usw. Diese sind bei einer Einzelanwendung nicht erforderlich.

Das bedeutet jedoch, dass bestimmte Anwendungen kaum als Unikernel implementiert werden können. So wäre beispielsweise im Bereich Luft- und Raumfahrt und Verteidigung, der einen Schwerpunkt beim Unternehmen Lynx bildet, die Verwendung von Bibliotheken für die ARCINC-Spezifizierung (Avionics Application Software Standard Interface) 653 (Spezifikation für Raum- und Zeitaufteilung) eine große Herausforderung.

Zwei Wege bieten sich an, um damit umzugehen:

Implementierung mehrerer Einzelprozessanwendungen.
Der Einsatz von Betriebssystemen neben Unikerneln. Dabei ist sicherzustellen, dass die Systeme so aufgebaut sind, dass die Auswirkungen des Eindringens einer Betriebssysteminstanz abgeschwächt werden.

Es gibt jedoch eine Reihe von Problemen im Zusammenhang mit Unikernels, die ihre Anwendung bisher eingeschränkt haben. Dazu gehören:

Debugging. Da auf einem Unikernel kein Betriebssystem läuft, funktioniert der Ansatz nicht, sich direkt mit der Shell zu verbinden und diese zu untersuchen.
Die Erstellung von Unikernel-Images ist kompliziert und erfordert fundierte Kenntnisse auf diesem Gebiet.
Aktuelle Anwendungsframeworks müssen angepasst und eine Dokumentation zur Verwendung in Unikerneln erstellt werden.
Das Fehlen eines sicherheitszertifizierbaren/zertifizierten Unikernels für unternehmenskritische Anwendungen.