Proxmox VE hat sich in deutschen Rechenzentren als ernstzunehmende Alternative zu proprietären Hypervisoren etabliert. Kostenfrei, quelloffen, mit klarer Roadmap. Doch sobald IT-Entscheider:innen den Namen Proxmox im gleichen Satz wie IT-Grundschutz nennen, tauchen Fragen auf: Reicht Open Source für ein Audit? Was verlangt das BSI von einer Virtualisierungsplattform? Und wo hört die Eigenverantwortung auf, wo beginnt die eines Dienstleisters? Im Folgenden werfen wir einen Blick auf diese Fragen, auf den zuständigen BSI-Baustein und die Praxis im Rechenzentrumsbetrieb.

Wann IT-Grundschutz für Proxmox-Umgebungen relevant wird

Durch Virtualisierung werden Risiken gebündelt. Fällt ein Host aus oder wird er kompromittiert, ist nicht eine, sondern zehn oder zwanzig virtuelle Maschinen betroffen. Aus diesem Grund hat das BSI der Virtualisierung einen eigenständigen Baustein im IT-Grundschutz-Kompendium gewidmet.

Eine Pflicht zur Anwendung des IT-Grundschutzes ergibt sich daraus nicht automatisch. Verbindlich ist das Rahmenwerk vor allem für Bundesbehörden, für Betreiber kritischer Infrastrukturen und häufig vertraglich für Auftragnehmer der öffentlichen Hand. Für alle anderen Unternehmen ist es ein anerkannter, freiwilliger Maßstab – aber ein zunehmend gefragter.

Die NIS2-Richtlinie schreibt zwar nicht explizit die BSI-Methodik vor, deckt sich in der Substanz jedoch weitgehend mit den Anforderungen aus SYS.1.5: Wer diesen Baustein umsetzt, ist auch für NIS2 gut aufgestellt. Ob Sie IT-Grundschutz formal zertifizieren lassen oder als Orientierungsrahmen für ein sauberes ISMS nach BSI-Standard nutzen, ist am Ende eine Frage Ihrer eigenen Ausgangslage – nicht der eingesetzten Virtualisierungslösung.

Der BSI-Baustein SYS.1.5 – das gilt für Proxmox konkret

Der maßgebliche Baustein heißt SYS.1.5 Virtualisierung. Er ist technologieneutral formuliert, lässt sich aber unmittelbar auf Proxmox übertragen. Die zentralen Anforderungen im Überblick:

• Trennung von Administrations- und Produktivnetz. Die Proxmox-Weboberfläche und die Cluster-Kommunikation gehören in ein eigenes, abgeschottetes Management-Netz – nicht ins gleiche VLAN wie die virtuellen Maschinen.
• Rollen- und Berechtigungskonzept. Nicht jede Person braucht Root-Zugriff auf den Node. Proxmox bringt mit seinem rollenbasierten Zugriffsmodell (RBAC) die technische Grundlage mit, das Konzept dahinter muss aber dokumentiert sein.
• Protokollierung und Nachvollziehbarkeit. Wer hat wann welche VM gestartet, migriert oder gelöscht? Ohne zentrales Logging bleibt diese Frage unbeantwortet.
• Verschlüsselung von Daten und Datenträgern. Betrifft sowohl die Storage-Ebene als auch Backups.
• Regelmäßige Aktualisierung und Patch-Management. Ein Hypervisor mit veralteten Paketen ist ein offenes Scheunentor.

Ergänzt wird SYS.1.5 durch den Baustein CON.3 Datensicherungskonzept. Er fordert unter anderem die bekannte 3-2-1-Regel und regelmäßige Wiederherstellungstests. Viele Unternehmen entdecken erst im Ernstfall, dass es hier noch Lücken gibt.

Fünf Stellschrauben für den IT-Grundschutz-konformen Proxmox-Betrieb

Die gute Nachricht: Proxmox bringt für die meisten dieser Anforderungen bereits das nötige Werkzeug mit. Die Umsetzung liegt bei Ihnen.

1. Netzwerksegmentierung konsequent durchziehen. Separates VLAN für die Cluster-Kommunikation (Corosync), eigenes Netz für Management-Zugriffe, Firewall-Regeln auf Node- und VM-Ebene über die integrierte Proxmox-Firewall.
2. Zugriffe granular vergeben. RBAC nutzen, Zwei-Faktor-Authentifizierung für alle administrativen Konten aktivieren, Service-Accounts von persönlichen Konten trennen.
3. Verschlüsselung durchgängig denken. ZFS-Verschlüsselung für Storage-Pools, verschlüsselte Backups über Proxmox Backup Server, TLS für sämtliche Managementverbindungen.
4. Monitoring und Protokollierung zentralisieren. Syslog-Weiterleitung an ein zentrales SIEM oder zumindest an einen dedizierten Log-Server – lokale Logs allein reichen für ein Audit nicht aus.
5. Patch-Zyklen verbindlich festlegen. Ob über das kostenfreie No-Subscription-Repository oder das stabilere Enterprise-Repository: Entscheidend ist ein dokumentierter, wiederkehrender Prozess, kein Ad-hoc-Update nach Bauchgefühl.

Keine dieser Maßnahmen ist für sich genommen kompliziert. Die Herausforderung liegt in der Konsequenz – und darin, sie über den gesamten Lebenszyklus der Infrastruktur aufrechtzuerhalten.

Open Source und Compliance – kein Widerspruch, wenn der Betrieb stimmt

Ein Einwand taucht in Gesprächen mit Compliance-Verantwortlichen immer wieder auf: Kann eine Open-Source-Lösung überhaupt grundschutzkonform betrieben werden? Die Antwort ist ein klares Ja. Das BSI bewertet nicht die Lizenz, sondern die umgesetzten Maßnahmen. Proxmox VE steht unter der AGPLv3, ist quelloffen einsehbar und läuft ohne Lizenzkosten – ein Vorteil bei der Nachvollziehbarkeit, kein Nachteil bei der Sicherheit.

Der eigentliche Unterschied zu proprietären Hypervisoren liegt woanders: Support und Enterprise-Repository sind bei Proxmox optionale, kostenpflichtige Bausteine. Wer produktiv arbeitet und Wert auf getestete, stabile Updates legt, sollte diese Option nicht als Kür, sondern als Teil des Patch-Managements betrachten.

Eigenbetrieb oder Managed Service – was für Ihre Compliance-Anforderungen spricht

Wer trägt die Verantwortung für Segmentierung, Patch-Zyklen, Backup-Tests und Audit-Dokumentation? Diese Frage entscheidet oft darüber, ob Proxmox intern oder als Managed Service betrieben wird.

Im Eigenbetrieb liegt die volle Kontrolle bei Ihrem Team – und damit auch der volle Aufwand. Rollenkonzepte pflegen, Firewall-Regeln aktuell halten, Backup-Tests protokollieren, all das bindet Kapazität, die in kleineren IT-Abteilungen oft fehlt.

Ein Managed Private Cloud-Ansatz auf Proxmox-Basis verlagert diesen Betriebsaufwand an einen spezialisierten Anbieter. Wichtig für die eigene Auditvorbereitung: Eine IT-Grundschutz- oder ISO-27001-Zertifizierung des Anbieters bezieht sich in der Regel auf den Rechenzentrumsbetrieb, die Netzanbindung und definierte Cloud-Services, aber nicht automatisch auf jede einzelne Plattformkomponente.

Klären Sie vor Vertragsabschluss, welcher Geltungsbereich konkret zertifiziert ist und welche Maßnahmen innerhalb Ihrer virtuellen Umgebung weiterhin in Ihrer eigenen Verantwortung liegen. Ein Beispiel für ein Managed-Private-Cloud-Modell auf Proxmox-Basis finden Sie bei plusserver.

Welcher Weg der richtige ist, hängt von vorhandenem Know-how, Auditpflichten und der Frage ab, wie viel operative Verantwortung Sie selbst tragen möchten. Unser Ratgeber führt Sie durch beide Szenarien und zeigt, welche Anforderungen aus SYS.1.5 und CON.3 in der Praxis am meisten Aufwand verursachen – und wie sich dieser reduzieren lässt.