Der Netzplan, dem man im Störfall trauen kann

Drei Ebenen: physisch, logisch, Betrieb

Die Trennung in Ebenen hilft, Inhalte dem richtigen Werkzeug und der richtigen Person zuzuordnen. Die physische Ebene beantwortet die Frage, wo etwas steht und womit es verbunden ist. Die logische Ebene beschreibt, wie Verkehr fließt und welche Netze sich sehen. Die betriebliche Ebene hält fest, wie das Netz verwaltet wird und unter welchen Bedingungen.

Der IT-Grundschutz trennt ähnlich. NET.1.1.A2 verlangt eine vollständige Dokumentation mit Netzplan, Ist-Aufnahme samt Netzperformance und allen Änderungen und fordert ausdrücklich, die logische Struktur mit Subnetzen, Zonierung und Segmentierung zu dokumentieren. NET.1.2.A12 ergänzt die Dokumentation der Management-Infrastruktur, also welche Komponenten mit welchen Werkzeugen verwaltet werden.

Die erste Bestandsaufnahme: vom Gerät in die Dokumentation

Wer neu anfängt oder einen alten Bestand ablöst, beginnt nicht mit dem Zeichnen, sondern mit dem Einsammeln. Die Geräte wissen über sich selbst mehr als jede Liste: Modell, Seriennummer, Softwarestand, Interfaces mit Beschreibung und Status, VLANs und über CDP oder LLDP auch ihre direkten Nachbarn. Aus diesen Daten entsteht in wenigen Tagen ein Grundbestand, der genauer ist als ein über Jahre gepflegtes Diagramm.

Der Grundschutz verlangt in NET.1.1.A2 ausdrücklich eine initiale Ist-Aufnahme einschließlich der Netzperformance. Halte deshalb neben dem Bestand auch fest, wie stark die Uplinks und WAN-Leitungen zum Zeitpunkt der Aufnahme ausgelastet sind und welche Fehlerzähler auffallen. Diese Werte sind später die Vergleichsbasis, wenn jemand meldet, das Netz sei langsamer geworden.

Passive Komponenten wie Patchfelder und Dosen lassen sich nicht abfragen. Für sie brauchst du eine Begehung, am besten Raum für Raum mit Fotos der Beschriftung. Plane diese Arbeit als eigenes Vorhaben und nicht nebenbei, denn eine halb erfasste Verkabelung verleitet zu falschen Schlüssen. Wo die Zeit fehlt, beginne mit den Verbindungen zwischen aktiven Komponenten und ergänze die Endgeräteverkabelung schrittweise bei Umzügen und Störungen.

show version | include uptime|Software|Model|System serial
show inventory
show interfaces description
show vlan brief
show cdp neighbors detail
show lldp neighbors detail
show ip interface brief
show etherchannel summary

Pflichtinhalte und was niemand braucht

Die Pflichtinhalte ergeben sich aus den Fragen, die im Betrieb gestellt werden, und aus den Anforderungen von Prüfungen. Alles, was diese Fragen nicht beantwortet, kostet Pflegeaufwand ohne Gegenwert. Weniger, dafür aktuell, schlägt vollständig, aber veraltet.

Ein Inhalt gehört ausdrücklich nicht in die Dokumentation: Kennwörter und Schlüssel. Sie gehören in einen Passwortmanager mit Rollen und Protokoll. Der Grundschutz verlangt in NET.3.1.A9, Betriebsdokumentationen vor unbefugtem Zugriff zu schützen, und eine Doku mit Kennwörtern ist ein Angriffsziel.

• Pflicht: ein Übersichtsplan je Standort und ein Gesamtplan mit Standortverbindungen und Übergängen ins Internet

• Pflicht: Liste aller aktiven Komponenten mit Modell, Seriennummer, Softwarestand, Standort und Management-Adresse

• Pflicht: VLANs und Subnetze mit Zweck, Gateway und zugehöriger Zone

• Pflicht: Verbindungen zwischen aktiven Komponenten mit Ports, damit Uplinks und Redundanzen erkennbar sind

• Pflicht: Leitungen und Verträge mit Provider, Leitungs-ID, Bandbreite, Laufzeit und Störungsnummer

• Pflicht: gesicherte Konfigurationen mit Datum und Änderungshistorie

• Verzichtbar: Screenshots von Konfigurationen, die das Backup ohnehin genauer enthält

• Verzichtbar: handgezeichnete Pläne bis auf jeden Access Port, die bei jedem Umzug veralten

• Tabu: Kennwörter, Pre-Shared Keys und Community-Strings im Klartext

Source of Truth statt vieler Listen

Eine Source of Truth ist die eine Stelle, an der der gewollte Zustand des Netzes steht. NetBox ist dafür im Netzwerkbereich verbreitet: Die Dokumentation beschreibt es als Werkzeug für die Modellierung und Dokumentation von Netzen, mit Datenmodellen für Standorte, Racks, Geräte, Interfaces, Kabel, Prefixe, IP-Adressen, VLANs und Leitungen. Über eine REST-API lesen andere Systeme diese Daten, statt eigene Kopien zu führen.

Diagramme und Listen werden zum Ergebnis statt zur Quelle. Ein Netzplan, der aus den Kabeldaten erzeugt wird, ist so aktuell wie die Daten. Monitoring, Automatisierung und Firewall-Management lesen Geräte und Adressen aus der Source of Truth; Ansible bringt dafür ein Inventory-Plugin für NetBox mit. Wichtig ist die Richtung: In NetBox steht der gewollte Zustand, die Geräte liefern den tatsächlichen, und ein regelmäßiger Abgleich zeigt die Abweichungen.

plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.firma.example
validate_certs: true
config_context: false
group_by:
  - sites
  - device_roles
device_query_filters:
  - status: active
  - has_primary_ip: 'true'
# Token nicht hier eintragen, sondern als Umgebungsvariable NETBOX_TOKEN setzen

Pflege an den Change-Prozess koppeln

Dokumentation veraltet nicht durch Faulheit, sondern weil ihre Pflege an keiner Stelle im Ablauf vorkommt. Die wirksamste Maßnahme ist deshalb organisatorisch: Jeder Change am Netz enthält ein Feld für die betroffenen Dokumentationsteile, und der Change wird erst geschlossen, wenn sie aktualisiert sind. Der Grundschutz verlangt in NET.1.1.A2, dass alle durchgeführten Änderungen in der Dokumentation enthalten sind.

Noch besser ist, wenn die Reihenfolge sich umkehrt: Erst wird der gewollte Zustand in der Source of Truth eingetragen, dann wird er auf das Gerät gebracht, im Idealfall automatisiert. Dann kann die Dokumentation gar nicht hinter dem Netz zurückbleiben. Für Notfalländerungen gilt eine Frist zur Nachdokumentation, etwa der nächste Arbeitstag.

Der automatische Abgleich ist die Kontrolle dafür, dass der Ablauf funktioniert. Ein nächtlicher Job liest von jedem Gerät Seriennummer, Softwarestand, Interfaces mit Status und die LLDP-Nachbarn und vergleicht sie mit den Einträgen in der Source of Truth. Jede Abweichung ist entweder eine undokumentierte Änderung oder ein Fehler in der Dokumentation, und beides gehört geklärt. Für das Netzmanagement verlangt der Grundschutz in NET.1.2.A17 einen regelmäßigen Soll-Ist-Vergleich, und der Bericht des Abgleichs liefert dafür einen Teil der Belege.

• Die Change-Vorlage bekommt das Feld „betroffene Dokumentation“.

• Das Review des Changes prüft auch, ob die Dokumentation aktualisiert wurde.

• Notfall-Changes landen in einer festen Liste und werden am nächsten Arbeitstag nachdokumentiert.

• Ein automatischer Abgleich zwischen Source of Truth und Gerätedaten läuft wöchentlich und schickt einen Bericht an das Team.

Config-Backups und Versionierung

Die Konfiguration eines Geräts ist der genaueste Teil der Dokumentation, weil sie den tatsächlichen Zustand zeigt. Der Grundschutz verlangt in NET.3.1.A8, die Konfigurationsdateien von Routern und Switches regelmäßig zu sichern und so abzulegen, dass sie im Notfall erreichbar sind. NET.1.2.A24 empfiehlt, Konfigurationsdaten zentral, in einer Versionsverwaltung und in der Datensicherung vorzuhalten.

Auf Cisco IOS XE kann das Gerät selbst Archivstände anlegen. Laut Cisco muss dafür zuerst ein Pfad gesetzt sein, die Zahl der Stände liegt zwischen 1 und 14, und time-period legt das Intervall in Minuten fest. Das ersetzt keine zentrale Sicherung, ist aber die Grundlage für configure replace mit automatischem Rückweg. Zentral sichern Werkzeuge wie Ansible die Konfigurationen in ein Git-Repository; jede Änderung ist dann als Diff mit Datum sichtbar. Weil Konfigurationen Hashes und Schlüssel enthalten, braucht das Repository eine Zugriffsbeschränkung.

configure terminal
archive
 path flash:konfig
 maximum 14
 time-period 1440
end

! Archivstand sofort anlegen und Stände anzeigen
archive config
show archive

Audit-Sicht: was der Prüfer sehen will

Ein Prüfer, ob im Grundschutz-Audit, bei ISO 27001 oder in der Jahresabschlussprüfung, fragt nicht nach der Schönheit der Pläne, sondern nach Belegen. Er will sehen, dass ein aktueller Netzplan existiert, dass die logische Struktur mit Zonen und Segmenten dokumentiert ist, dass Änderungen nachvollziehbar sind und dass Konfigurationen gesichert und wiederherstellbar sind. Das Datum des letzten Stands ist dabei so wichtig wie der Inhalt.

Für Einrichtungen, die unter das BSI-Gesetz fallen, kommt § 30 BSIG hinzu: Die Einhaltung der Risikomanagementmaßnahmen ist zu dokumentieren. Zu den Maßnahmen gehören unter anderem Backup-Management und Konzepte für die Verwaltung von IKT-Systemen. Die Netzdokumentation ist dafür kein eigener Nachweis, aber eine Grundlage, auf die sich viele Nachweise stützen. Eine eigene Pflicht zu einer bestimmten Form der Netzdokumentation lässt sich daraus nicht ableiten.