{"id":49181,"date":"2026-08-17T01:37:35","date_gmt":"2026-08-16T23:37:35","guid":{"rendered":"https:\/\/overcentral.com\/de\/?p=49181"},"modified":"2026-08-17T01:37:35","modified_gmt":"2026-08-16T23:37:35","slug":"proxmox-ve-9-zugriffskontrolle","status":"publish","type":"post","link":"https:\/\/overcentral.com\/de\/proxmox-ve-9-zugriffskontrolle\/","title":{"rendered":"Proxmox VE 9: Realms, ACLs und Firewall sichern den Zugriff"},"content":{"rendered":"

Nach der Absicherung der Boot-Kette und der Management-Daemons r\u00fcckt beim sicheren Betrieb von Proxmox VE 9<\/a> der Zugriffsschutz in den Vordergrund. Authentifizierungs-Realms, ein pfadbasiertes Rollenmodell, die integrierte Firewall und das SDN-Forwarding bestimmen, wer welche Ressource erreicht und welcher Verkehr im Cluster zul\u00e4ssig bleibt. Dieser zweite Teil der H\u00e4rtungsreihe zeigt die konkreten Befehle, Konfigurationsdateien und Werte f\u00fcr eine produktionsreife Zugriffskontrolle.<\/p>\n

Authentifizierungs-Realms: Wer darf sich anmelden?<\/h2>\n

Proxmox VE f\u00fchrt alle Benutzerkonten clusterweit in der Datei \/etc\/pve\/user.cfg<\/strong>. Jeder Anmeldung ist ein Realm zugeordnet, der die Authentifizierungsquelle definiert. Standardm\u00e4\u00dfig existiert der Realm pam<\/strong>, der die lokalen Linux-Benutzer des Hosts verwendet, sowie der Realm pve<\/strong> f\u00fcr interne Proxmox-Benutzer. F\u00fcr Produktionsumgebungen ist es essenziell, die voreingestellten Konten wie root@pam<\/strong> zu \u00fcberwachen und nach M\u00f6glichkeit durch dedizierte Administratorkonten mit individuellen Realms zu ersetzen.<\/p>\n

Die Einrichtung eines LDAP- oder Active-Directory-Realms erfolgt \u00fcber das Webinterface oder die Kommandozeile. Ein Beispiel f\u00fcr die Integration eines Active-Directory-Realms mit dem Namen ad-prod<\/strong> lautet:<\/p>\n

pveum realm add ad-prod –type ad –domain ad.company.local –server-url ldaps:\/\/dc1.ad.company.local –default 0<\/strong><\/p>\n

Nach dem Hinzuf\u00fcgen k\u00f6nnen Sie Benutzer aus diesem Realm importieren und ihnen Rollen zuweisen. Wichtig: Jeder Realm sollte nur vertrauensw\u00fcrdige Quellen enthalten. Deaktivieren Sie ungenutzte Realms wie den Standard-pam<\/strong>-Realm, wenn Sie keine lokalen Linux-Anmeldungen mehr zulassen m\u00f6chten. Dies verhindert, dass ein Angreifer \u00fcber ein kompromittiertes lokales Konto auf den Cluster zugreift.<\/p>\n

Das pfadbasierte Rollenmodell: Wer darf was?<\/h3>\n

Das Berechtigungsmodell von Proxmox VE verteilt Rollen entlang einer Baumstruktur aus Pfaden. Jeder Benutzer oder jede Gruppe erh\u00e4lt auf einem bestimmten Pfad eine Rolle, die wiederum eine Liste von Berechtigungen enth\u00e4lt. Der Pfad kann den gesamten Cluster (\/<\/strong>), einen bestimmten Node (\/nodes\/node1<\/strong>), einen Storage (\/storage\/local<\/strong>) oder eine VM (\/vms\/100<\/strong>) umfassen.<\/p>\n

Die wichtigsten vordefinierten Rollen sind Administrator<\/strong> (alle Rechte auf dem Pfad), PVEAdmin<\/strong> (au\u00dfer Benutzerverwaltung) und PVEVMUser<\/strong> (nur VM-Operationen). F\u00fcr eine feingranulare Steuerung k\u00f6nnen Sie eigene Rollen definieren, zum Beispiel eine ReadOnly<\/strong>-Rolle, die nur Leseberechtigungen f\u00fcr die Cluster-\u00dcbersicht gew\u00e4hrt.<\/p>\n

Die Zuweisung einer Rolle an einen Benutzer erfolgt mit pveum acl modify<\/strong>. Ein typisches Beispiel, um einem Benutzer operator@ad-prod<\/strong> die Rolle PVEVMUser<\/strong> auf dem Pfad \/vms<\/strong> zu geben:<\/p>\n

pveum acl modify \/vms –user operator@ad-prod –role PVEVMUser<\/strong><\/p>\n

Diese pfadbasierte Struktur erlaubt es, Administratoren auf bestimmte Nodes zu beschr\u00e4nken oder einzelnen Entwicklern nur Zugriff auf ihre eigenen VMs zu gew\u00e4hren. Pr\u00fcfen Sie regelm\u00e4\u00dfig die ACLs mit pveum acl list<\/strong> und entfernen Sie veraltete oder zu weitreichende Berechtigungen.<\/p>\n

Direkte Antwort f\u00fcr ein Featured Snippet: Wie funktioniert die Firewall von Proxmox VE 9?<\/h2>\n

Die Firewall von Proxmox VE 9<\/a> arbeitet auf drei Ebenen: Cluster-Ebene (Regeln f\u00fcr alle Nodes), Node-Ebene (Regeln pro Host) und VM-Ebene (Regeln f\u00fcr jede virtuelle Maschine). Sie verwendet iptables\/nftables im Hintergrund, wird aber \u00fcber die Proxmox-Konfiguration gesteuert. Die Regeln werden in den Dateien \/etc\/pve\/firewall\/cluster.fw<\/strong>, \/etc\/pve\/nodes\/[node]\/host.fw<\/strong> und \/etc\/pve\/firewall\/[vmid].fw<\/strong> abgelegt. Standardm\u00e4\u00dfig ist die Firewall deaktiviert; sie muss f\u00fcr jede Schicht explizit eingeschaltet werden.<\/p>\n

Konfiguration der Firewall auf Cluster-Ebene<\/h3>\n

Die Cluster-Firewall definiert globale Regeln, die auf allen Nodes gelten. Aktivieren Sie sie mit:<\/p>\n

pve-firewall set –enable 1<\/strong><\/p>\n

Anschlie\u00dfend legen Sie Standardpolicies fest, zum Beispiel: eingehender Verkehr standardm\u00e4\u00dfig ablehnen, ausgehender Verkehr erlauben. Einrichten von Ausnahmeregeln f\u00fcr den Management-Zugriff (SSH, HTTPS) und die Cluster-Kommunikation (Port 22, 8006, 5900-5999, 60000-60050).<\/p>\n

Ein Beispiel f\u00fcr eine Regel, die SSH nur von einem bestimmten Verwaltungsnetz erlaubt:<\/p>\n

pve-firewall rule add –direction in –action accept –source 10.0.0.0\/24 –dest 192.168.1.0\/24 –proto tcp –dport 22<\/strong><\/p>\n

Analog konfigurieren Sie Node-spezifische Regeln in der host.fw<\/strong> und VM-spezifische Regeln in der jeweiligen VM-ID.fw<\/strong>. Die VM-Firewall erlaubt die Isolation von virtuellen Maschinen, ohne dass der gesamte Host davon betroffen ist.<\/p>\n

SDN-Forwarding und Netzgrenzen<\/h2>\n

Das Software-Defined Networking (SDN) in Proxmox VE 9 erlaubt die Definition virtueller Netze (VNets), die \u00fcber Bridges, VLANs oder VXLANs verbunden werden. Jedes VNet kann mit einer eigenen Firewall-Policy versehen werden, was eine Mikrosegmentierung erm\u00f6glicht. Die Konfiguration erfolgt im Webinterface unter Datacenter<\/strong> \u2192 SDN<\/strong>.<\/p>\n

Praktische Anwendung: Ein VNet f\u00fcr Datenbank-VMs, das nur von den Applikations-VNs erreichbar ist, w\u00e4hrend der Zugriff aus anderen Netzen blockiert bleibt. Die SDN-Firewall wird \u00fcber die gleichen Mechanismus wie die Host-Firewall gesteuert, jedoch bezogen auf das VNet. Die Regeln greifen direkt auf dem virtuellen Switch.<\/p>\n

Diese Kombination aus Realm-basierter Authentifizierung, pfadbasierten ACLs, mehrschichtiger Firewall und SDN-Isolation schafft ein gestaffeltes Sicherheitsmodell. Fehlt auch nur eine dieser Komponenten, bleibt die Absicherung l\u00fcckenhaft. Ein Angreifer, der sich \u00fcber einen schwachen Realm authentifiziert, kann nur durch enge ACLs und restriktive Firewall-Regeln am weiteren Vordringen gehindert werden.<\/p>\n

Die Praxis zeigt: Viele Administratoren verlassen sich auf die Authentifizierung allein und vernachl\u00e4ssigen die Netzwerksicherheit. In Produktionsclustern sollte daher jede dieser Schichten konfiguriert und regelm\u00e4\u00dfig auf ihre Wirksamkeit \u00fcberpr\u00fcft werden. Die Automatisierung \u00fcber API-Calls oder Ansible-Manifeste erleichtert die Konsistenz \u00fcber mehrere Cluster hinweg. Mit Proxmox VE 9 steht ein Werkzeugkasten zur Verf\u00fcgung, der bei korrekter Anwendung einem Enterprise-Hypervisor in nichts nachsteht.<\/p>\n","protected":false},"excerpt":{"rendered":"

Nach der Absicherung der Boot-Kette und der Management-Daemons r\u00fcckt beim sicheren Betrieb von Proxmox VE 9 der Zugriffsschutz in den Vordergrund. Authentifizierungs-Realms, ein pfadbasiertes Rollenmodell, die integrierte Firewall und das SDN-Forwarding bestimmen, wer welche Ressource erreicht und welcher Verkehr im Cluster zul\u00e4ssig bleibt. Dieser zweite Teil der H\u00e4rtungsreihe zeigt die konkreten Befehle, Konfigurationsdateien und Werte […]<\/p>\n","protected":false},"author":5,"featured_media":49184,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/raw.githubusercontent.com\/medeiroslima\/overcentral-images\/main\/images\/ocie_1786923464249.jpg","fifu_image_alt":"Proxmox VE 9: Realms, ACLs und Firewall sichern den Zugriff","footnotes":""},"categories":[6671],"tags":[],"class_list":["post-49181","post","type-post","status-publish","format-standard","has-post-thumbnail","category-scherheit"],"fifu_image_url":"https:\/\/raw.githubusercontent.com\/medeiroslima\/overcentral-images\/main\/images\/ocie_1786923464249.jpg","fifu_image_alt":"Proxmox VE 9: Realms, ACLs und Firewall sichern den Zugriff","_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/49181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=49181"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/49181\/revisions"}],"predecessor-version":[{"id":49183,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/49181\/revisions\/49183"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media\/49184"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=49181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=49181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=49181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}