Drei dedizierte Server und ein Public-Cloud-Cluster kommunizieren „privat“ über vRack. Niemand filtert den Datenverkehr zwischen der Datenbank und den Backups; Die Überwachung sieht nur das öffentliche Internet. Eine Kompromittierung einer virtuellen Anwendungsmaschine wird zu einer freien seitlichen Bewegung – einer blinden Zone, die durch implizites Vertrauen entsteht. Das vRack löst ein Verkabelungsproblem, kein Governance-Problem: Ohne Segmentierung haben Sie das Risiko nur innerhalb des OVHcloud-Perimeters verschoben.
Das OVHcloud vRack löst private Konnektivität zwischen Diensten auf. Es löst nicht die Flow-Governance – das ist Ihre Architektur.
vRack: Was es kann und was nicht
| Kapazität | vRack | Sich selbst hinzufügen |
|---|---|---|
| Privates L2-Netzwerk mit mehreren Diensten | Ja | — |
| Internet-Isolation | Standardmäßig Ja | Freiwillige Offenlegung über öffentliches IP |
| Inter-VM-Filterung | Nicht-natives Ende | Firewalls, NFTables, Sicherheitsgruppen |
| Ost-West-Erkennung | Nein | Probe, Protokolle, Zero-Trust-Zugriff |
| Produkt-/Administratorsegmentierung | Nein | Logische VLANs, Checklisten |
Empfohlenes Zonenmodell
Definieren Sie vier Zonen vor dem ersten Anhang. Frontzone: Load Balancer oder Reverse-Proxy mit kontrollierter öffentlicher IP-Adresse. Anwendungszone: virtuelle Maschinen ohne öffentliche Route, nur von vorne erreichbar.
Datenbereich: Datenbanken, privater Objektspeicher; strenge Checklisten nur aus dem Anwendungsbereich. Verwaltungsgebiet: Bastion, kontinuierliche Integration; Protokollierter Zugriff, keine allgemeine Navigation.
Dokumentieren Sie eine Flussmatrix: Quelle, Ziel, Hafen, geschäftliche Begründung. Überprüfen Sie es bei jedem neuen vRack-Anhang.
Überwachung ohne tote Winkel
Sammeln Sie zonenübergreifende Firewall-Protokolle (Ablehnungen und Genehmigungen). Überwachen Sie die regionenübergreifende vRack-Latenz, wenn Sie über mehrere Rechenzentren verfügen. Konfigurieren Sie Warnungen für neue IP-Adressen oder offene Ports im vRack. Führen Sie ein Inventar der angeschlossenen Dienste – das vRack wächst stillschweigend mit jedem Projekt.
Testen Sie ein vierteljährliches Mapping: Ist alles, was angehängt ist, noch notwendig?
Häufige Fehler
Ein flaches vRack, das Produktion, Vorproduktion und Backup vereint. Eine Pivot-Maschine mit öffentlicher IP-Adresse und vollem Zugriff auf das vRack. Ein undokumentierter interner DNS, der Abhängigkeiten verbirgt. Das Fehlen einer maschinenübergreifenden Verschlüsselung sensibler Daten – vRack ist keine Verschlüsselung.
Informationen zum Administratorzugriff finden Sie unter VPN oder Bastion.
Vierteljährlicher Rückblick: Was Sie mitnehmen sollten
Listen Sie vierteljährlich die mit dem vRack verbundenen Dienste auf und entfernen Sie diejenigen, die nicht mehr benötigt werden. Eine vergessene Testumgebung, die mit demselben privaten Netzwerk wie die Produktion verbunden ist, wird zum Dreh- und Angelpunkt von Kompromissen. Dokumentieren Sie außerdem zonenübergreifende Firewallregeln und stellen Sie sicher, dass keine „temporären“ Regeln zum Debuggen offen bleiben. Ein gut gestaltetes vRack reduziert die dem Internet ausgesetzte Fläche; Es ersetzt keine Updates, die Verwaltung von Geheimnissen oder die Absicherung einzelner Maschinen – es ist eine Netzwerkschicht und kein Ersatz für Anwendungssicherheit.
Der Gipfel: Privat bedeutet nicht sicher
Entscheide dich und gehe ohne blinden Fleck voran
Zeichnen Sie das Zonendiagramm vor der ersten vRack-Anbindung und wenden Sie vom ersten Tag an minimale Checklisten an. Machen Sie die Ost-West-Überwachung zu einem nicht verhandelbaren Bestandteil Ihres Budgets und Ihres Runbooks, planen Sie eine vierteljährliche Überprüfung der angeschlossenen Dienste und dokumentieren Sie die Flussmatrix für jede neue Umgebung. Vergleichen Sie Architekturen über unsere Ratgeber und das OVHcloud-Blatt – das vRack verbindet sich, Sie filtern und Sie protokollieren. Ohne regelmäßige Überprüfung wächst das private Netzwerk, bis es so undurchsichtig wird wie das Internet – mit weniger Sichtbarkeit als Standardtools.
Häufig gestellte Fragen
Was ist das OVHcloud vRack?
Privates Layer-2-Netzwerk zwischen berechtigten OVHcloud-Diensten (dedizierte, angeschlossene Public Cloud, NAS), standardmäßig vom öffentlichen Internet isoliert, erweiterbar über eine oder mehrere Regionen.
Ersetzt vRack eine Firewall?
Nein: vRack isoliert den Datenverkehr vom öffentlichen Netzwerk. Die Feinfilterung zwischen virtuellen Maschinen muss weiterhin über Firewall, NFTables oder Sicherheitsgruppen konfiguriert werden.
Welcher Fehler erzeugt eine blinde Zone?
Ein flaches vRack ohne Checklisten oder Protokolle oder eine kompromittierte Pivot-Maschine mit vollständigem privaten Netzwerkzugriff und einer öffentlichen IP-Adresse.
Public Cloud und vRack zusammen?
Ja, über private Schnittstellen – planen Sie IP-Adressierung, regionsübergreifendes Routing und Latenz und dokumentieren Sie, welche Cloud-Projekte an das vRack angeschlossen sind.
Das vRack stellt eine private Verbindung her; Sie entscheiden, wer mit wem reden darf – sonst ist es ein kameraloser Flur. Planen Sie mit dem Sicherheits- und Betriebsteam eine halbjährliche Überprüfung der Ablaufmatrix, um veraltete Anhänge zu entfernen.