Sichere Virtualisierung gemäß EU-Standard
Virtualisieren nach Kochbuch
Veröffentlicht in Ausgabe 02/2021 - SCHWERPUNKT
Die Europäische Agentur für Netzwerk- und Informationssicherheit (ENISA, European Network and Information Security Agency) hat bereits 2017 einen Leitfaden für Sicherheit von Virtualisierung [1] erlassen. Der rückt in vielen Ländern Europas aktuell in den Mittelpunkt des Interesses, weil er nach einer Übergangsfrist gerade gesetzlicher Mindeststandard wird.
Begriffsklärung "Best Practices"
Die allermeisten Admins haben wohl recht klare Vorstellungen davon, was mit "Best Practices" gemeint ist – doch dürfte die Meinung von Admin A mit der von Admin B nicht zwangsläufig übereinstimmen. Verbindliche Standards hinsichtlich der "Best Practices" finden sich in der aktuellen Gesetzgebung mit IT-Bezug relativ selten.
Was sehr gefährlich ist, weil diverse Dokumente wie die DSGVO den Begriff explizit verwenden oder ihn zumindest eindeutig umschreiben. Nach einem meldepflichtigen Einbruch im Sinne eben der DSGVO ist eine Standardfrage etwa, ob die Sicherung der Daten anhand etablierter Verfahren und gängiger Standards durchgeführt wird. Selbst wenn die Wörter "Best Practices" nicht explizit vorkommen, läuft es letztlich auf diese Floskel hinaus.
Die Europäische Agentur für Netzwerk- und Informationssicherheit (ENISA, European Network and Information Security Agency) hat bereits 2017 einen Leitfaden für Sicherheit von Virtualisierung [1] erlassen. Der rückt in vielen Ländern Europas aktuell in den Mittelpunkt des Interesses, weil er nach einer Übergangsfrist gerade gesetzlicher Mindeststandard wird.
Begriffsklärung "Best Practices"
Die allermeisten Admins haben wohl recht klare Vorstellungen davon, was mit "Best Practices" gemeint ist – doch dürfte die Meinung von Admin A mit der von Admin B nicht zwangsläufig übereinstimmen. Verbindliche Standards hinsichtlich der "Best Practices" finden sich in der aktuellen Gesetzgebung mit IT-Bezug relativ selten.
Was sehr gefährlich ist, weil diverse Dokumente wie die DSGVO den Begriff explizit verwenden oder ihn zumindest eindeutig umschreiben. Nach einem meldepflichtigen Einbruch im Sinne eben der DSGVO ist eine Standardfrage etwa, ob die Sicherung der Daten anhand etablierter Verfahren und gängiger Standards durchgeführt wird. Selbst wenn die Wörter "Best Practices" nicht explizit vorkommen, läuft es letztlich auf diese Floskel hinaus.
Was die Sache für Unternehmen nicht leichter macht. Denn ob Stellen wie Behörden und Gerichte im Falle eines Falles einen Schutzmechanismus als "etabliertes Verfahren" betrachten oder nicht, ist im Vorfeld nicht sicher vorhersagbar.
Hier kommen Dokumente wie der Compliance-Guide der ENISA ins Spiel. Die ENISA beschreibt in jenem zunächst Virtualisierung per se und geht auf moderne Ansätze wie Software-defined Networking ein. Danach zählt sie eine Reihe von Verfahren auf, die an Virtualisierung beteiligte Server gegen Angriffe härten und vor Eindringlingen schützen sollen. Aus eben diesem Grund sind verschiedene Staaten mittlerweile dazu übergegangen, den ENISA-Guide im Rahmen einer Verordnung zu einer Quasi-Vorschrift zu machen.
Österreich prescht vor
Exemplarisch sei die österreichische Regulierungsbehörde RTR genannt: Sie hat mit Wirkung vom 3. Juli 2020 die "TK-NSiV 2020" in Kraft gesetzt. Deren vollständiger Titel ist zwar ein schlimmes Wortungetüm, ihr Inhalt weiß aber durchaus zu überzeugen. Denn in ihr hält die RTR fest, welche Mindestanforderungen für den Betrieb digitaler Kommunikationsdienste gelten. De jure führt die neue Verordnung lediglich den schon bis dato existierenden Paragraphen 16a des Telekommunikationsgesetzes von 2003 aus. De facto nehmen die in der neuen Verordnung aufgeführten Punkte implizit Bezug auf den gesamten Inhalt der ENISA-Guidelines für Virtualisierung. In Österreich dürfte bei Rechtsstreitigkeiten in Zukunft also auch die Frage im Raum stehen, ob digitale Systeme entlang der Vorgaben des ENISA-Guides geschützt waren.
Das wiederum kann sich für ganze Firmen zur Entscheidung über Leben und Tod entwickeln. Denn die Macher der DSGVO waren beim Festlegen von Bußgeldern bekanntlich nicht zimperlich. Stehlen Ganoven Daten und stellt sich danach heraus, dass die in der ENISA-Anleitung vorgegebenen Richtlinien für sichere Virtualisierung nicht erfüllt waren, kann das für Firmen künftig empfindliche Strafen nach sich ziehen, die im Einzelfall den Fortbestand des Unternehmens gefährden können. Grund genug also, es so weit gar nicht erst kommen zu lassen.
Keine schwere Kost
Die gute Nachricht ist, dass der ENISA-Report nicht unbedingt schwere Kost ist. Freilich, als Gute-Nacht-Lektüre taugt das Dokument nicht. Panik ist angesichts der knappen 100 Seiten aber nicht angesagt. Denn weite Teile des Reports über "Sicherheitsaspekte der Virtualisierung" beschäftigen sich mit einer generellen Einführung in das Thema und einer exemplarischen Vorstellung verschiedener Virtualisierungskonzepte. Auf virtuelle Desktopinfrastrukturen geht der Guide dabei ebenso ein wie auf virtualisierte Netze (Software-defined Networking) oder Container.
Wer EU-Behörden grundsätzlich für lahm hält und ihnen die Fähigkeit abspricht, den Finger am Puls der Zeit zu haben, sieht sich hier klar eines Besseren belehrt. Denn bereits Anfang 2017 hatte die ENISA das Thema Docker groß auf dem Schirm.
In einem zweiten großen Themenkomplex widmet die ENISA sich der Frage, in welche Angriffsszenarien und Kategorien sich bestimmte Arten von Leaks und Schwachstellen klassifizieren lassen. Hier erfährt der versierte Leser aber nicht viel Neues, denn die ENISA folgt hier weitgehend den Empfehlungen anderer Behörden und Projekte wie CERT.
Von den genannten 100 Seiten entfallen letztlich nur knappe 15 Seiten auf Maßnahmen, die die ENISA für das Härten von Systemen empfiehlt. Die wiederum sind in zwei Teile unterteilt, nämlich in generelle Empfehlungen und solche, die sich auf bestimmte Virtualisierungsszenarien beziehen. Noch besser: Wer sich mit den Themen Sicherheit und Compliance regelmäßig beschäftigt, dürfte die meisten Vorgaben der ENISA nachvollziehen können und vermutlich bereits implementiert haben.
Grundsätzliche Thesen
Für den ausführenden Admin wirklich interessant werden die Dokumente de facto erst im Kapitel 3, wo es um grundsätzliche Herangehensweisen für die Sicherheit von Virtualisierung geht. Das Unterkapitel 3.1 umfasst generelle Empfehlungen und teilt sich wiederum in eine Beschreibung des physischen sowie des virtuellen Layers auf.
Die ENISA betont hier ganz bewusst, dass das Dokument sich auch auf virtuelle Infrastruktur jenseits einzelner VMs bezieht. Ganz prominent an erster Stelle findet sich etwa die Aufforderung zu echter Verschlüsselung innerhalb des gesamten Setups. Dass Verbindungen zur Außenwelt besser verschlüsselt sein sollten, sehen die allermeisten Admins mittlerweile ein. Interne SSL-Verschlüsselung findet sich hingegen deutlich seltener; sie ist oft der Ausgangspunkt heftiger Diskussionen. Gerade solche Umgebungen, die das Netz in "gut" und "böse" unterteilen, verzichten im vertrauten Teil des Netzes auf die Verschlüsselung von Verbindungen zwischen einzelnen Servern und Diensten.
Allerdings: Dass es die "guten" Netzwerk-segmente de facto nicht mehr gibt, haben diverse Angriffe in den letzten Jahren gezeigt – obgleich das ENISA-Dokument abgetrennte Netzwerkteilbereiche ebenfalls als Maßnahme vorsieht, wenn auch nur als einen Baustein von vielen. Interne Verschlüsselung ist mit wenig Aufwand und selbst verwalteten SSL-CAs günstig möglich und ein Feature, auf das Admins heute nicht mehr verzichten sollten.
Darüber hinaus enthalten die Tipps für den physischen Teil die Empfehlung, Nutzer wie Admins entsprechend zu schulen und Informationen jenen nur dort zugänglich zu machen, wo es faktisch notwendig ist. Und: Zutrittssysteme sollten nach dem ENISA-Standard unbedingt zentral verwaltet sein, statt auf lokale Fleckenteppiche zu setzen. Bis hierhin also wenige Überraschungen für Admins, die das Thema Security bisher nicht stiefmütterlich behandelt haben.
Der Host und die Gäste
Konkreter ins Detail geht die ENISA-Anleitung im Unterkapitel 3.1.2, das sich mit der Konfiguration der Hypervisoren und der Virtualisierung per se beschäftigt. Die erste und mithin dringendste Empfehlung lautet hier, sich Virtualisierung als Schichtensystem vorzustellen – und jeder Schicht exakt die Aufmerksamkeit in Sachen Sicherheit zukommen zu lassen, die sie verdient. Das betrifft beispielsweise den Hypervisor selbst: Ein Loch in diesem böte schlimmstenfalls die Möglichkeit, aus einer virtuellen Instanz auszubrechen und unerlaubten Zugriff auf andere virtuelle Systeme desselben Hosts zu erhalten.
Einerseits sind Admins deshalb angehalten, nur jene Dienste der Hypervisor-Software zu nutzen, die sie benötigen. Zusätzliche Services wie Clipboard- oder Filesharing-Dienste, die bei manchen Systemen wie VMware beiliegen, sind nach Möglichkeit zu deaktivieren. Dasselbe gilt für zwar eingebaute, aber nicht genutzte Hardware. Ferner sollten Features des Hypervisors im Hinblick auf seine eigene Sicherheit Verwendung finden, wann immer das geht. Darüber hinaus sollten aber andere Werkzeuge zum Einsatz kommen, die den Schutz erhöhen. Systeme für Mandatory Access Control (MAC) wie SELinux oder App-Armor können zur letzten Bastion eines Hosts werden, wenn der Hypervisor leckschlägt.
Monitoring ist wichtig
Eine zentrale Rolle nimmt den Autoren zufolge außerdem das Monitoring aller Systeme ein. Logisch, wird der eine oder andere Admin nun denken, gehört Monitoring doch ohnehin zu den Kardinalsaufgaben jedes Admins. Oftmals bezieht sich das Monitoring allerdings ausschließlich auf die korrekte Funktionalität von Diensten und weniger auf ihren Security-Kontext.
Ein paar Beispiele verdeutlichen das dramatisch: Startet ein Server etwa aus dem Nichts heraus neu, gehen die meisten Administratoren wohl intuitiv von einem Hardwarefehler aus. Denkbar wäre aber auch, dass ein Angreifer ein System neu gestartet hat, um bestimmte Sicherheitsmechanismen abzuschalten. Kritische Dateien wie die Konfiguration des Bootloaders gehören deshalb ebenfalls ins Monitoring.
Obendrein sollten die typischen Vitalwerte einer Virtualisierungsumgebung ständig unter Beobachtung stehen. Steigt in einer Umgebung ad hoc die Nutzung von CPU- oder RAM-Ressourcen oder explodiert der ein- oder ausgehende Traffic, ist das ein Indikator dafür, dass möglicherweise etwas nicht stimmt. Erinnert sei in diesem Kontext nochmals daran, dass Sicherheit im IT-Umfeld nicht nur bedeutet, die feindliche Übernahme von Systemen durch Gangster zu verhindern. Sie kann auch darin bestehen, Angriffe auf laufende virtualisierte Instanzen rechtzeitig zu erkennen und zu unterbinden, sodass andere Ressourcen gar nicht erst in Mitleidenschaft gezogen werden.
Die Inhalte des "General"-Kapitels enthalten darüber hinaus ein buntes Potpourri an Maßnahmen, die die meisten Admins allerdings ohnehin bereits befolgen dürften – etwa die Ermahnung, Zugang zu Informationen nur denen zu gewähren, die sie brauchen, sowie die Etablierung eines Security-Prozesses im Unternehmen, bei dem qualifizierte Experten die vorgeschlagenen Maßnahmen bewerten.
Vorsicht bei der Konfiguration
Ein eigenes Kapitel der ENISA-Empfehlungen widmet sich der Konfiguration der Hypervisoren, der Gastsysteme und der zusätzlich benötigten Software. So empfehlen die Autoren etwa den Einsatz einer speziellen Software, um die ausgerollten Konfigurationsdateien überall stets zu überwachen. Das kann ein Automatisierer sein, besser geeignet ist aber noch ein Werkzeug wie InSpec von Chef [2].
Änderungen an den Zugangsberechtigungen zur Konfiguration – etwa am Git-Verzeichnis, in dem die Konfiguration liegt – wollen die Autoren nachvollziehbar dokumentiert haben, was mittels zentraler Benutzerverwaltung in vielen Firmen ohnehin Standard ist. Wenn Konfigurationsdateien sich ändern, soll es zudem ein Monitoringsystem geben, das das bemerkt und bei ungewollten Modifikationen Alarm schlägt.
Betriebssysteme gehören gewartet
Auch das Kapitel "Betriebssysteme" fasst im Wesentlichen die gängigsten, am Markt etablierten Maßnahmen zusammen. Security-Updates der Hersteller gehören nachverfolgt und bei Verfügbarkeit installiert. Die Konfiguration von Betriebssystemen sollte zentral sichergestellt sein und nicht mittels manueller Änderungen auf den Systemen erfolgen. Sicherheitsmethoden der Hersteller zur Härtung virtueller Systeme sind zu nutzen und nicht etwa abzuschalten – vielleicht ein versteckter Gruß an jene Admins, die zunächst SELinux deaktivieren, bevor sie auf einem frisch installierten System etwas anderes tun.
Link-Codes
[1] ENISA-Guide für Sicherheit in virtuellen Umgebungen: https://www.enisa.europa.eu/publications/security-aspects-of-virtualization/
[2] InSpec von Chef: https://community.chef.io/tools/chef-inspec/
Das Kriterium "OS-09" ist besonders wichtig: Es legt fest, dass Admins sämtliche VMs auf einem System als kompromittiert betrachten sollten, falls der Hypervisor gehackt worden ist. Es hilft dann nur noch das Zurückrollen zu einem bekanntermaßen sicheren Zustand (known good state). Dieselben Regeln definieren die Autoren des Dokumentes zudem für Container, wenn auch etwas schwammig.
Kapitel zum Hypervisor am längsten
Wirklich ausgetobt haben die Autoren des ENISA-Papiers sich in ihrem Hypervisor-Kapitel, in dem sie Maßnahmen für den Hypervisor selbst empfehlen. Zum großen Teil wiederholen sich hier die zuvor bereits genannten Empfehlungen im Hinblick auf das Betriebssystem oder benötigte Software. Neue Faktoren gibt es hier aber auch: Die Autoren raten etwa dringend, auf übermäßiges Overcommitment von RAM zu verzichten, weil das DDoS-Attacken Tür und Tor öffnet und damit im Ernstfall einen weiteren Angriffsvektor aufmacht. Erfahrene Linux-Admins werden hier vermutlich die Nase rümpfen, hat sich doch das Mantra "Kein RAM-Overcommit" eigentlich längst etabliert. Die meisten Systeme dürften diesen Faktor also bereits strenger implementieren, als die ENISA vorschlägt.
Genau umgekehrt verhält es sich bei der ENISA-Empfehlung zum Overcommit bei virtuellen CPUs. Hier raten die Autoren dringend davon ab, mehr vCPUS zu verteilen, als die Server CPU-Kerne haben. Was gleich doppelt seltsam anmutet, weil hier einerseits Hyperthreading außen vor bleibt. Und andererseits gilt CPU-Overcommitment eigentlich als Standard, weil nicht jede gebuchte vCPU permanent zu 100 Prozent ausgelastet ist.
Denkbar wäre freilich, dass die Konzentration von vielen VMs auf einem System zu einer Angriffsmöglichkeit führt. Virtualisierungsmanager verhindern aber in aller Regel, dass alle VMs eines Kunden auf denselben Hypervisoren laufen. Das Angriffsszenario ist also nicht sonderlich naheliegend. Nachvollziehbar ist diese ENISA-Empfehlung insofern nur zum Teil.
Außerdem interessant aus Sicht des Admins ist noch das Kriterium HY-24: Gaben die vorherigen Kapitel in Sachen Benutzerverwaltung stets nur an, dass es eine "zentrale Verwaltung geben soll", schreibt der entsprechende Punkt im Hypervisor-Kapitel die Nutzung von LDAP, Active Directory oder ähnlichen Lösungen zwingend vor ("must").
Die weiteren Kapitel beschäftigen sich mit virtuellen Netzen und virtuellem Speicher, greifen im Wesentlichen aber die Argumente der vorherigen Kapitel auf und stellen sie in einen neuen Kontext.
Fazit
Große Überraschungen enthält das ENISA-Papier, das sich vieler Punkte aus den NIST-Vorgaben bedient, in Summe nicht. Lediglich die Regelungen zum CPU-Overcommit wirken im ersten Augenblick etwas praxisfern. Grundsätzlich gilt aber, dass die im ENISA-Dokument vorgeschlagenen Prozeduren eine solide Grundlage für ein Sicherheitskonzept in virtuellen Umgebungen darstellen.
Als der Weisheit letzter Schluss sollten sie freilich nicht gelten, weil sie wirklich nur das absolute Minimum beschreiben. Wer dieses Minimum bisher aber noch nicht erfüllt, findet im Dokument einen guten Leitfaden und eine Ermahnung zur selben Zeit.
(ln)