Eine VM, drei Zeugen
Der Hypervisor sieht die virtuelle Maschine, der Netzwerk-Scan sieht sie, der Software-Scan auch. Wer das nicht zusammenführt, hat sie dreimal im Inventar und eine Asset-Zahl, die von der Anzahl der Scanner abhängt statt von der Anzahl der Maschinen.
Eine virtuelle Maschine wird in einer gut ausgestatteten Umgebung von mehreren Seiten gesehen. Der Virtualisierungs-Connector liest sie aus der Hypervisor-API. Der Netzwerk-Scan findet sie, weil sie eine IP hat und antwortet. Der Software-Scan meldet sie, weil ein Agent darauf läuft. Drei Quellen, dieselbe Maschine.
Wer das nicht zusammenführt, hat sie dreimal im Inventar. Und ab da stimmt nichts mehr.
Warum Doppel-Einträge teurer sind, als sie aussehen
Ein doppeltes Asset ist nicht nur eine Zeile zu viel. Der Schutzbedarf wird an einem der Datensätze gepflegt, die Risikoanalyse hängt am zweiten, und die Schwachstelle aus dem Scan landet am dritten. Jede einzelne Pflege ist korrekt, das Gesamtbild ist es nicht. Am Ende steht eine Asset-Zahl im Bericht, die niemand verteidigen kann, weil sie von der Anzahl der eingesetzten Scanner abhängt statt von der Anzahl der Maschinen.
Woran dieselbe Maschine wiedererkannt wird
Deshalb konvergiert jede gefundene VM mit dem Netzwerk- und dem Software-Scan zu einem einzigen IT-System. Der Abgleich läuft über Seriennummer beziehungsweise BIOS-UUID, MAC-Adresse und Hostname.
Drei Merkmale und nicht eines, weil jedes für sich Lücken hat. Der Hostname ändert sich beim Umbenennen und wird in Testumgebungen gern mehrfach vergeben. Die MAC-Adresse ist zuverlässiger, kann aber nach einem Klon in zwei Maschinen gleichzeitig auftauchen. Die Hardware-Kennung ist am stabilsten, wird aber nicht von jeder Quelle geliefert. Erst zusammen tragen sie.
Das Ergebnis ist unspektakulär und genau deshalb richtig: Es entstehen keine Doppel-Einträge, und die VM bekommt denselben GRC-Kontext wie jedes andere Asset. Schutzbedarf, Risiken, Software, Schwachstellen. Kein Sonderweg für virtuelle Maschinen.
Was der Connector sonst noch anlegt
- Cluster als DCIM-Cluster, stabil wiedererkannt über die Hypervisor-eigene ID, nicht über den Namen.
- Hypervisor-Hosts als IT-System mit Plattform, Hersteller und Management-IP. Steht der Host zusätzlich im Rack, wird er mit dem DCIM-Gerät verknüpft.
- Virtuelle Maschinen mit vCPUs, RAM, Disk und Status, verknüpft mit Cluster und Host.
- VM-Netzwerkkarten mit MAC-Adresse. Sie sind die Grundlage für die Konvergenz oben.
Erkannt werden VMware vCenter und ESXi, Microsoft Hyper-V und Proxmox VE, jeweils über den isidaten-Agenten.
Dasselbe Prinzip eine Ebene tiefer
Der Connector läuft ausschließlich auf dem Cluster-Leader, wie alle Data-Hub-Connectoren. Ohne diese Einschränkung würden mehrere Agenten dieselbe Hypervisor-API abfragen und dieselben Daten mehrfach einliefern. Die Vermeidung von Doppelungen beginnt also nicht erst beim Abgleich, sondern schon bei der Frage, wer überhaupt fragen darf.
Eine harte Kante gibt es: Die Virtualisierungs-Funktionen setzen einen Agenten ab Version 1.40.0 voraus. Ältere Agenten kennen den Scan-Typ nicht und melden „Unknown scan type". Wer die Meldung sieht, braucht kein Ticket, sondern ein Agent-Update.
Mehr auf der Modulseite zur Virtualisierung.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.