Proxmox VE · M4

Installation & Ersteinrichtung

Vom ISO-Image zum abgesicherten, einsatzbereiten Host

🎧 Block 1: Installation & Netzwerk-Grundkonfiguration

Installationsablauf

Von ISO-Boot bis einsatzbereitem Host vergehen in der Praxis oft nur 10–15 Minuten – der Assistent übernimmt Partitionierung, Storage-Layout und Basis-Netzwerk in einem Rutsch.

ISO von proxmox.com/downloads herunterladen und auf einen USB-Stick schreiben – unter Windows z. B. mit Rufus (DD-Modus wählen, nicht ISO-Modus, sonst startet der Stick nicht richtig), unter Linux/macOS reicht dd if=proxmox-ve.iso of=/dev/sdX bs=4M status=progress oder das grafische balenaEtcher
Zum Ausprobieren ohne echte Hardware: Proxmox VE lässt sich auch als verschachtelte VM in einer bestehenden Virtualisierungsumgebung installieren (z. B. in VirtualBox, VMware Workstation oder sogar in einer anderen Proxmox-VM mit aktivierter Nested Virtualization, siehe Modul 1) – ideal für ein risikofreies Testlabor, bevor echte Server angefasst werden
Installation per ISO, geführter Assistent für Storage-Layout (ZFS, LVM oder ext4) und Netzwerk
Boot-Modus UEFI empfohlen, dafür läuft jede VM standardmäßig mit OVMF (UEFI-Firmware für Gäste) – Voraussetzung u. a. für Windows-11-Gäste mit TPM
Nach der Installation: Web-GUI sofort unter https://<IP>:8006 erreichbar, kein Zusatzschritt nötig
Hostname und IP-Adresse vorab festlegen – nachträgliches Ändern ist möglich, aber im Cluster-Verbund unnötig fehleranfällig

Netzwerk-Grundkonfiguration

Zwei NICs werden zu einem Bond gebündelt, eine VLAN-aware Bridge liegt darauf, VMs hängen mit unterschiedlichen VLAN-Tags daran

Bridge (vmbr0): virtueller Switch, an den VMs und Container angeschlossen werden – Standard-Baustein jeder Proxmox-Installation
Bond: bündelt mehrere physische NICs für Redundanz und/oder mehr Bandbreite – gängige Modi sind Active-Backup (einfach, ausfallsicher) und LACP (mehr Durchsatz, braucht passenden Switch)
VLAN: eine VLAN-aware Bridge trennt Management-, Server- und Gast-Netz auf derselben Verkabelung – jede VM bekommt einfach ein Tag zugewiesen
Praxis-Empfehlung: Management-Zugriff (Web-GUI, Corosync) auf ein eigenes VLAN legen, getrennt vom Produktiv-/Gastnetz

Repositories richtig einstellen

Ohne Subscription bleibt das Enterprise-Repository deaktiviert, das No-Subscription-Repository wird aktiviert und liefert reguläre Updates

Frisch installiert ist standardmäßig das Enterprise-Repository aktiv – ohne gültige Subscription liefert das nur Fehlermeldungen bei Updates, weil der Zugriff serverseitig auf zahlende Abos beschränkt ist.

No-Subscription-Repository aktivieren, wenn keine Subscription vorliegt – Einstellung über die Web-GUI (Node → Updates → Repositories) oder direkt in /etc/apt/sources.list.d/
Enterprise-Repository deaktivieren, um störende Fehlermeldungen bei apt update zu vermeiden
Mit Subscription: Enterprise-Repository für getestete, besonders stabile Updates nutzen – Pakete durchlaufen hier eine zusätzliche Testphase, bevor sie auch im No-Subscription-Kanal landen
Ohne Subscription ist Proxmox VE trotzdem voll funktionsfähig – der Unterschied liegt ausschließlich bei Update-Kanal und Herstellersupport, nicht bei Features (siehe Modul 11)

🎧 Block 2: Härtung, Zeitsync, Zertifikate & Benutzerverwaltung

Post-Install-Härtung

SSH-Zugriff von Passwort auf Schlüssel umstellen, Root-Login per SSH-Passwort deaktivieren – Konfiguration in /etc/ssh/sshd_config (PasswordAuthentication no, PermitRootLogin prohibit-password)
Integrierte Firewall für Management-Zugriffe (Web-GUI-Port 8006, SSH) auf bekannte Quell-IPs einschränken – Proxmox bringt eine eigene, cluster- und node-weite Firewall mit, die sich über die Web-GUI konfigurieren lässt
Nur benötigte Repositories und Pakete installiert lassen – kleinere Angriffsfläche, weniger Update-Aufwand
Automatische Sicherheitsupdates (unattended-upgrades) zumindest für kritische Patches erwägen – Abwägung zwischen Sicherheit und Kontrolle über den Update-Zeitpunkt, gerade im Cluster mit Rolling-Reboot-Strategie (Modul 5)
Fail2ban oder die integrierte Proxmox-Firewall-Regel gegen Brute-Force auf die Web-GUI-Anmeldung ergänzen – Standard-Login-Versuche über das Internet sind keine Seltenheit, sobald Port 8006 erreichbar ist

DSGVO & NIS2: Compliance als Plattform-Kriterium

Acht Compliance-Anforderungen aus DSGVO und NIS2, jeweils mit der passenden Proxmox-VE-Funktion und dem vertiefenden Modul

Reine Lerninhalte, keine Rechtsberatung: ob und in welchem Umfang NIS2 für das eigene Unternehmen gilt, hängt von Sektor, Größe und Umsatz ab (grobe Richtschnur: ab 50 Mitarbeitenden bzw. 10 Mio. € Jahresumsatz in bestimmten Sektoren) – im Zweifel spezialisierte Rechtsberatung hinzuziehen. Die DSGVO gilt dagegen unabhängig von der Unternehmensgröße für praktisch jedes Unternehmen, das personenbezogene Daten verarbeitet.

DSGVO-Relevanz: Self-hosted-Betrieb im eigenen Haus gibt volle Kontrolle über den Serverstandort und den Zugriff auf personenbezogene Daten – ein Kriterium, das bei Cloud-Angeboten außerhalb der EU oft zusätzliche Vertragskonstrukte (Standardvertragsklauseln, Auftragsverarbeitung) nötig macht
NIS2 (in Kraft seit Oktober 2024 EU-weit, deutsche Umsetzung über das NIS2UmsuCG) erweitert den Kreis betroffener Unternehmen deutlich über klassische kritische Infrastruktur hinaus – u. a. Risikomanagement-Maßnahmen, Meldepflichten bei Sicherheitsvorfällen und Nachweise zur Business Continuity gehören zu den Kernpflichten
Viele NIS2-Anforderungen sind ohnehin gute Praxis, unabhängig von der Rechtslage: Netzwerksegmentierung (Modul 6), konsequentes Patch-Management (Modul 5), Zugriffskontrolle mit Rollen und 2FA (dieses Modul) und ein funktionierendes Backup-/Recovery-Konzept (Modul 13) zahlen gleichzeitig auf Compliance und auf ganz praktische Betriebssicherheit ein
Ein handfester Vorteil gegenüber geschlossenen Appliances: die Proxmox-Konfiguration liegt als lesbare Textdateien unter /etc/pve vor (siehe Modul 1) – das erleichtert Nachweise und Audits erheblich, weil sich der tatsächliche Systemzustand jederzeit direkt einsehen und dokumentieren lässt, statt einer Blackbox vertrauen zu müssen

🎧 Block 3: DSGVO & NIS2 für den KMU-Betrieb

Zeitsynchronisation

Im Cluster ist eine korrekte Uhrzeit kein Detail: Corosync, Zertifikate und Log-Auswertung reagieren empfindlich auf Zeitdrift zwischen Nodes.

NTP-Dienst auf allen Nodes gegen dieselbe Zeitquelle synchronisieren – Proxmox bringt standardmäßig chrony oder systemd-timesyncd mit, je nach Version
Vor dem Cluster-Aufbau prüfen – nachträgliche Zeitsprünge können Corosync destabilisieren, da der Cluster-Kommunikationsprotokoll-Stack (Totem) auf enge Zeitfenster angewiesen ist
Interne NTP-Quelle (z. B. die Firewall oder ein dedizierter Zeitserver im eigenen Netz) ist meist zuverlässiger und schneller als ein öffentlicher NTP-Pool über das Internet
Zeitzone einheitlich auf allen Nodes setzen (meist UTC oder eine feste lokale Zeitzone) – uneinheitliche Zeitzonen erschweren später die Log-Korrelation zwischen Nodes

Zertifikate für die Web-GUI

Standardmäßig ein selbstsigniertes Zertifikat – Browser-Warnung, aber verschlüsselt, für den ersten Zugriff direkt nach der Installation ausreichend
ACME-Integration (z. B. Let's Encrypt) für ein vertrauenswürdiges Zertifikat ohne manuellen Aufwand, inklusive automatischer Erneuerung alle 90 Tage – Einrichtung unter Datacenter → ACME
Wichtig bei mehreren Nodes: Zertifikat pro Node-Hostname einrichten – die Datacenter-Ansicht kann das zentral für den ganzen Cluster anstoßen, jeder Node braucht aber sein eigenes, auf seinen Hostnamen ausgestelltes Zertifikat
Ohne öffentlich erreichbare Domain: ACME per DNS-Challenge nutzen, statt den Port 8006 ins Internet zu öffnen – unterstützt eine lange Liste an DNS-Providern über entsprechende Plugins
Alternative für rein interne Umgebungen: eigene interne Zertifizierungsstelle (CA) nutzen und deren Root-Zertifikat einmalig auf den Verwaltungsrechnern als vertrauenswürdig hinterlegen

Benutzerverwaltung & das Wichtigste

Realms Lokale Proxmox-Nutzer oder Anbindung an bestehendes AD/LDAP für zentrale Konten – kein Parallel-Nutzerverzeichnis pflegen

Rollen & ACLs Feingranular je Pfad vergeben (z. B. nur eine VM verwalten) statt pauschaler Admin-Rechte für alle

Zwei-Faktor-Authentifizierung für die Web-GUI aktivieren, gerade für administrative Konten – unterstützt TOTP-Apps (z. B. Authy, Google Authenticator) und WebAuthn/Hardware-Keys
Getrennte Konten statt geteiltem root-Zugang – jeder Admin bekommt sein eigenes Konto mit passender Rolle, das erleichtert später die Nachvollziehbarkeit im Audit-Log
Merke: Repository-Wahl, Zeitsync, Härtung und Benutzerverwaltung gehören vor den Cluster-Aufbau, nicht danach – Nachrüsten im laufenden Cluster ist deutlich aufwendiger, weil Änderungen dann auf allen Nodes koordiniert nachgezogen werden müssen

Tastenkürzel