Virtuelle Netzwerksicherheit

Der physische Switch sieht nicht jeden Verkehr

Zwei VMs auf demselben Host können über einen virtuellen Switch kommunizieren, ohne dass ihre Frames den physischen Uplink erreichen. Eine Firewall oder ein Mirrorport außerhalb des Hosts sieht diesen Ost-West-Pfad dann nicht. Umgekehrt kann eine Regel am virtuellen Adapter keinen fehlerhaften Trunk oder ungeschützten Managementport im physischen Netz ersetzen. Virtuelle Netzwerksicherheit beginnt deshalb mit dem tatsächlichen Flow: Quelle, Ziel, Protokoll, Port, Richtung, Hypervisorpfad, Overlay und jeder Übergang in ein physisches Segment.

Durchsetzungspunkt — Die konkrete Komponente, die eine Regel auf einen bestimmten Verkehr anwendet, etwa VM-vNIC, Portgruppe, verteilte Firewall, Bridge, physische Firewall oder Gastbetriebssystem.

Segmentierung ist eine Vertrauensentscheidung

VLANs, Overlays und Portgruppen schaffen getrennte Broadcast- oder Routingbereiche, aber ihre Namen sind noch keine Sicherheitsgarantie. „Management“, „Storage“ und „Tenant“ sind erst dann Grenzen, wenn Pfade, Routing, Filterregeln, Administration und Tests diese Trennung tragen. Ein gemeinsamer Uplink kann mehrere Zonen sicher transportieren, sofern Tagging, erlaubte VLANs und Durchsetzungspunkte korrekt sind. Eine separate Netzwerkkarte kann trotzdem dieselbe Vertrauensdomäne bleiben, wenn alle Rollen breit darauf zugreifen dürfen. Physische Trennung und logische Kontrolle beantworten verschiedene Risiken.

Zone

Typische erlaubte Beziehungen

Management

Jump Host und Automation zu Hypervisor- und Management-APIs

Storage

Hostinitiator zu benannten Targets und erforderlichen Discovery-Diensten

Migration

Host zu Host auf dem freigegebenen Migrationspfad

Tenant

Anwendungsflows nach Dienstbedarf, nicht pauschal nach VLAN

Backup

Proxy oder Host zu Repository über einen getrennt kontrollierten Schutzpfad

Default Deny braucht einen vollständigen Dienstvertrag

Eine implizite oder explizite Abschlussregel „deny“ ist nur dann sicher betreibbar, wenn die erforderlichen Flows bekannt sind. Dazu gehören nicht nur Client zu Server, sondern DNS, Zeit, Identität, Zertifikatsprüfung, Monitoring, Backup und Verwaltung. Fehlt eine Abhängigkeit, wirkt die Policy zwar restriktiv, bricht aber den Dienst. Wird als Reaktion ein breites „allow any“ ergänzt, verschwindet die Segmentierung. Der bessere Ablauf erfasst den Dienstvertrag vor der Aktivierung und beobachtet verworfene Pakete in einem begrenzten Canary-Scope.

• Quelle und Ziel als stabile Gruppe oder Identität statt vergänglicher Einzel-IP.
• Protokoll und Zielport mit begründetem Dienstbedarf.
• Richtung aus Sicht des tatsächlichen Durchsetzungspunkts.
• Stateful oder stateless Semantik und Verhalten der Rückpakete.
• Owner, Ablaufdatum und Ticket für jede Ausnahme.
• Log- und Testsignal, das Treffer oder unerwartete Drops belegt.

Der Preis enger Regeln ist Pflege. Dynamische Plattformdienste, Failoverziele und neue Replikate verändern erlaubte Beziehungen. Deshalb werden Regeln möglichst an deklarative Gruppen und Serviceobjekte gebunden und gegen reale Platzierungswechsel getestet.

Hyper-V-ACLs hängen am virtuellen Adapter

Hyper-V Extended Port ACLs werden am virtuellen Netzwerkadapter angewendet. Microsoft dokumentiert Quelle, Ziel, Protokoll, Quell- und Zielport, Richtung, Aktion und -Weight. Höhere Gewichte werden vor niedrigeren verarbeitet. Die Richtung wird aus Sicht der VM gelesen: Inbound führt zur VM, Outbound von ihr weg. Diese Details sind Teil der Sicherheitssemantik. Eine korrekte Portnummer mit vertauschter Richtung schützt den beabsichtigten Flow nicht. Eine breite Allow-Regel mit höherem Gewicht kann eine spätere Deny-Regel vollständig überdecken.

vSphere-L2-Sicherheit hat drei verschiedene Schalter

vSphere unterscheidet Promiscuous Mode, MAC Address Changes und Forged Transmits. Promiscuous Mode kann einer VM Verkehr zustellen, der nicht an ihre konfigurierte MAC-Adresse gerichtet ist. MAC Address Changes betrifft die effektive Adresse für eingehenden Verkehr; Forged Transmits kontrolliert ausgehende Frames mit abweichender Quell-MAC. Broadcom empfiehlt für normale Produktionsportgruppen üblicherweise Reject. Bestimmte virtuelle Appliances, Cluster-VIPs oder Netzwerkerweiterungen können eine Ausnahme benötigen. Dann wird genau der benötigte Schalter auf der kleinsten passenden Portgruppe oder am Port freigegeben, nicht pauschal auf dem gesamten Distributed Switch.

Schalter

Welche Fähigkeit er erweitert

Promiscuous Mode

Empfang von beobachtetem Verkehr unabhängig von der Ziel-MAC

MAC Address Changes

Eingehende Zustellung an eine vom Gast geänderte effektive MAC

Forged Transmits

Senden mit einer Quell-MAC, die von der initialen MAC abweicht

Die drei Optionen sind keine Synonyme. Eine Störung durch VIP-Failover rechtfertigt nicht automatisch Promiscuous Mode. Der Betreiber ermittelt zuerst, welche Richtung und welche MAC-Abweichung die Anwendung wirklich nutzt, testet die engste Ausnahme und dokumentiert deren Sicherheitswirkung.

Verteilte Firewalls verschieben die Grenze zur Workload

Eine verteilte Firewall kann Regeln nahe an den VM-vNICs durchsetzen und dadurch lokale Ost-West-Flows kontrollieren. Das ist ihr großer Vorteil und zugleich eine Diagnosefalle: Der physische Perimeter sieht einen Drop möglicherweise nie. Bei NSX gehören Quellgruppe, Zielgruppe, Dienst, Aktion, Applied To, Reihenfolge und Realisierungsstatus zur Regel. Broadcom beschreibt die Verarbeitung top-down; eine frühere breite Regel kann eine spätere spezifische Regel überdecken. Eine im Manager veröffentlichte Policy muss außerdem auf den betroffenen Hosts und Ports realisiert sein.

Die Identität einer Workload darf dabei nicht unbemerkt auf einem frei änderbaren Namen beruhen. Gruppen können aus Tags, Betriebssystemattributen, VM-Pfaden oder statischen Mitgliedschaften gebildet werden; jede Quelle hat eine andere Vertrauensgrenze. Darf ein Tenant selbst das Tag setzen, das Zugang zum Datenbanknetz gewährt, kontrolliert er faktisch einen Teil der Firewall. Wird eine IP-Adresse als Identität verwendet, können DHCP, Wiederherstellung oder Neuvergabe den Bezug verschieben. Ein tragfähiges Modell dokumentiert deshalb, wer Gruppenmerkmale schreibt, wie schnell Änderungen realisiert werden und wie verwaiste Mitgliedschaften entfernt werden. Bei Provisionierung wird die erwartete Gruppe vor dem ersten produktiven Netzwerkstart geprüft. Bei Decommission wird nicht nur die VM gelöscht, sondern auch ihre statische Policybindung. Für besonders kritische Flows kann eine Kombination aus orchestrierter Gruppenmitgliedschaft, Gastidentität und Anwendungsauthentisierung nötig sein. Mikrosegmentierung ersetzt keine Ende-zu-Ende-Authentisierung; sie begrenzt erreichbare Pfade. Der Preis dynamischer Regeln ist, dass Inventar- und Taggingfehler unmittelbar den Datenpfad ändern können. Darum gehören Änderungen dieser Metadaten in Auditlog, Driftkontrolle und denselben Freigabeprozess wie sichtbare Firewallregeln.

Proxmox trennt Cluster-, Host- und Gastregeln

Die integrierte Proxmox-VE-Firewall kann Regeln für Datacenter, Node sowie VM oder Container verwalten und wiederverwendbare Security Groups nutzen. Standard-IP-Sets wie ipfilter-net* können die zulässigen Quelladressen eines virtuellen Interfaces begrenzen. Die wirksame Policy entsteht aus mehreren Ebenen, Interfacebindung, Richtung und Aktivierungszustand. Eine korrekte Regel in einer Datei hilft nicht, wenn die Firewall an der relevanten Ebene deaktiviert oder das falsche virtuelle Interface adressiert ist.

Clusterweite Konfiguration verbessert Konsistenz, ersetzt aber nicht die Prüfung des Laufzeitpfads. Bridges, VLAN-Awareness, physische Trunks und Gastfirewalls bleiben eigene Grenzen.

Management, Storage und Migration brauchen eigene Schutzpfade

Managementzugänge kontrollieren Hypervisor, virtuelle Netze und oft auch die Sicherheitsregeln selbst. Sie dürfen deshalb nicht wie ein gewöhnlicher Tenant-Dienst behandelt werden. Ein Jump Host, starke Administration, eng begrenzte APIs und ein unabhängiger Konsolenzugang reduzieren die Wirkung kompromittierter Workloads. Storage- und Migrationsnetze tragen hochprivilegierte Datenpfade: Wer dort Verkehr einspeisen oder abhören kann, greift möglicherweise auf VM-Inhalte oder laufenden Zustand zu. Segmentierung, Verschlüsselung nach Plattformfähigkeit und explizite Host-zu-Host- beziehungsweise Host-zu-Target-Beziehungen bilden den Vertrag.

Pfad

Primäre Schutzfrage

Management

Wer darf Konfiguration und Lebenszyklus der Plattform ändern?

Storage

Welche Hosts erreichen welche Targets über welche Initiatoridentität?

Migration

Welche Hosts dürfen Laufzeit- oder Speicherdaten austauschen?

Backup

Kann Produktion Sicherungen oder Aufbewahrung unkontrolliert verändern?

Tenant

Welche fachlich benötigten Ost-West- und Nord-Süd-Flows sind erlaubt?

Monitoring und Port Mirroring haben einen eigenen Blast Radius

Promiscuous Mode oder Port Mirroring werden oft für Diagnose und Intrusion Detection angefordert. Eine zu breite Konfiguration kann einer Analyse-VM Verkehr vieler Workloads zuführen und damit Vertraulichkeit, Kapazität und Tenantgrenzen berühren. Der Capture-Scope folgt der Frage: bestimmter vNIC, Port, VLAN, Flow oder kurzes Zeitfenster. Die Ziel-VM erhält nur die nötige Sicht, steht in einer geschützten Zone und besitzt einen Owner sowie ein Ablaufdatum. Nach der Analyse wird die Ausnahme entfernt und der Normalzustand verifiziert.

• Zweck und Incident- oder Change-ID dokumentieren.
• Quelle und Ziel des Mirrors so eng wie technisch möglich wählen.
• Aufbewahrung und Zugriff auf Paketdaten festlegen.
• Bandbreitenwirkung auf virtuelle und physische Pfade beobachten.
• Ablaufzeit automatisiert oder im Runbook kontrollieren.
• Nach Entfernung den tatsächlichen Policyzustand erneut auslesen.

Ein fehlendes Paket im Mitschnitt beweist nur, dass es diesen Messpunkt nicht erreichte. Deshalb wird der Capture-Ort zusammen mit der virtuellen Topologie dokumentiert; sonst führt eine technisch korrekte Aufnahme zu einer falschen Schlussfolgerung.

Policy-Änderungen brauchen Canary, Gegenprobe und Rückweg

Eine Firewallregel kann den eigenen Verwaltungszugang, HA-Kommunikation oder den gesamten Tenant-Scope unterbrechen. Vor dem Change werden aktueller Zustand und Regelreihenfolge exportiert, ein unabhängiger Managementzugang bestätigt und betroffene Flows benannt. Der erste Rollout trifft eine kleine Gruppe oder einzelne VM. Erlaubter Verkehr wird positiv getestet; mindestens ein verbotener Verkehr liefert die negative Gegenprobe. Nur die positive Probe beweist nicht, dass die Regel enger geworden ist. Drops, Regelhits und Dienstsynthetik bleiben während eines ausreichenden Beobachtungsfensters sichtbar.

Migration und Failover müssen die Sicherheitssemantik behalten

Eine VM kann auf dem Zielhost erreichbar sein und dennoch unter einer anderen Policy laufen. Standard-Switches können hostlokal konfiguriert sein; verteilte Steuerungen können eine Verzögerung oder Realisierungslücke haben; physische Trunks können andere VLANs erlauben. Vor einer Migration werden daher Portgruppenname und wirksame Eigenschaften verglichen: VLAN, L2-Sicherheitsoptionen, Firewallbindung, Gruppenmitgliedschaft, Uplinkpfad und Zielhostzustand. Broadcom dokumentiert, dass abweichende Security Policies zwischen Quell- und Zielnetz sogar einen vMotion-Precheck verhindern können. Der Check schützt Konsistenz, aber nicht jede externe Grenze.

Prüfung

Warum der Name nicht reicht

Portgruppe

gleiches Label kann auf Standard-Switches andere Einstellungen tragen

L2-Security

Promiscuous, MAC Changes und Forged Transmits verändern den Framevertrag

DFW-Realisierung

Managerzustand und Hostdurchsetzung können auseinanderliegen

Physischer Trunk

der Zieluplink muss VLAN und MTU tatsächlich führen

Negative Probe

Erreichbarkeit allein erkennt eine zu breite Zielpolicy nicht

Nach der Migration wird außerdem die effektive Regelbasis gesichert. Der zentrale Controller kann den gewünschten Zustand anzeigen, während ein Zielhost noch einen älteren Stand verarbeitet oder eine Erweiterung nicht geladen ist. Der Nachweis kombiniert Controllerrevision, Host- beziehungsweise Portstatus, Regelhit und Verhaltenstest. Ein positives Ergebnis allein reicht weiterhin nicht: Ein erlaubter HTTPS-Flow kann funktionieren, weil die beabsichtigte enge Regel greift oder weil eine frühere breite Allow-Regel alles durchlässt. Erst ein verbotener Kontrollflow unterscheidet diese Zustände. Für HA-Ereignisse werden diese Prüfungen automatisiert oder regelmäßig geprobt, weil ein Ausfall kein langes manuelles Policy-Audit erlaubt. Kann ein Host die Sicherheitskomponente nicht realisieren, muss die Admission-Entscheidung festlegen, ob sensible VMs dort starten dürfen. Verfügbarkeit und Sicherheit werden damit explizit gegeneinander abgewogen. Ein pauschales Fail-open maximiert Startwahrscheinlichkeit, kann aber die Tenantgrenze aufheben; Fail-closed schützt die Grenze, kann den Dienst ausfallen lassen. Die gewählte Semantik gehört in den Servicevertrag und wird bei einem simulierten Controller- oder Hostausfall getestet.

Die sichere Entscheidung verbindet Flow und Eigentümer

Der Ablauf beginnt mit einem konkreten Kommunikationsbedarf. Quelle, Ziel, Richtung und Dienst werden an der tatsächlichen virtuellen Topologie verfolgt. Danach wird der engste Durchsetzungspunkt gewählt, der auch nach Migration und HA wirksam bleibt. Regelreihenfolge, Gruppenmitgliedschaft und Aktivierungszustand werden als Teil der Policy behandelt. Ein Canary prüft erlaubte und verbotene Flows sowie die Dienstwirkung. Ausnahmen erhalten Owner und Ablaufdatum. Driftkontrollen vergleichen nicht nur Konfigurationsdateien, sondern den auf Hosts realisierten Zustand.

Der Preis der engen Grenze ist Koordination zwischen Plattform-, Netzwerk-, Sicherheits- und Anwendungsteam. Diese Arbeit lässt sich nicht durch ein pauschales Allow ersetzen. Ein klarer Flowvertrag macht sie kleiner: Jede Seite weiß, welche Zusage sie trägt und welche Evidenz sie nach einem Change liefern muss.

Der dauerhafte Nachweis besteht aus Policyrevision, Zuordnung der geschützten Objekte, erfolgreicher positiver Probe und erfolgreicher negativer Probe. Zusätzlich wird festgehalten, auf welchen Hosts und virtuellen Ports der Zustand geprüft wurde. Das ist besonders bei gemischten Clustern wichtig: Ein einzelner sauberer Canary beweist noch keine Parität aller Zielhosts. Stichproben folgen deshalb Fehlerdomänen und Konfigurationsvarianten statt einer zufälligen VM-Liste. Wird eine Abweichung gefunden, stoppt der Rollout an dieser Grenze; sie wird nicht durch eine vorübergehende globale Ausnahme verdeckt. So bleibt die Sicherheitszusage auch während Wartung und Störung messbar.