20.4 Compliance-Prüfungen im Unternehmen automatisieren

Compliance-Prüfungen im Unternehmen zu automatisieren bedeutet, technische Standards, Sicherheitsvorgaben und betriebliche Richtlinien im Netzwerk nicht mehr nur punktuell oder manuell zu kontrollieren, sondern systematisch, wiederholbar und möglichst objektiv zu überprüfen. Genau das ist in modernen Infrastrukturen besonders wichtig, weil Netzwerke aus vielen Geräten, Standorten, Rollen und Konfigurationsvarianten bestehen. Selbst wenn ein Team sehr sorgfältig arbeitet, entstehen mit der Zeit fast immer Abweichungen: ein Router hat noch alte NTP-Server eingetragen, auf einem Switch fehlt ein Login-Banner, ein Uplink transportiert mehr VLANs als vorgesehen, ein Gerät läuft auf einer nicht freigegebenen Softwareversion oder ein Access-Port weicht vom Sicherheitsstandard ab. Solche Unterschiede sind nicht automatisch dramatisch, sie zeigen aber, dass der tatsächliche Ist-Zustand vom gewünschten Soll-Zustand abweicht. Genau hier setzt automatisierte Compliance-Prüfung an. Für Network Engineers ist sie kein abstraktes Audit-Thema, sondern ein sehr praktisches Werkzeug, um Konfigurationsqualität, Sicherheitsniveau und Standardisierung im laufenden Betrieb transparent zu machen.

Was Compliance im Netzwerkumfeld überhaupt bedeutet

Compliance ist mehr als nur ein Audit-Begriff

Im Unternehmensumfeld wird der Begriff Compliance oft mit rechtlichen Vorgaben, Revision oder externen Prüfungen verbunden. Im Netzwerkbetrieb ist damit meist etwas sehr Konkretes gemeint: Geräte und Konfigurationen sollen definierten technischen Standards entsprechen. Diese Standards können aus Sicherheitsvorgaben, Architekturentscheidungen, Betriebsrichtlinien oder regulatorischen Anforderungen stammen.

• Nur bestimmte NTP-Server sind erlaubt.
• Syslog muss an festgelegte Ziele gesendet werden.
• SSH ist vorgeschrieben, Telnet verboten.
• Ungenutzte Ports müssen deaktiviert sein.
• Trunk-Ports dürfen nur definierte VLANs transportieren.
• Bestimmte Softwarestände sind verpflichtend oder verboten.

Compliance im Netzwerk bedeutet also: Ist das Gerät so konfiguriert und betrieben, wie es laut Unternehmensstandard vorgesehen ist?

Der Soll-Zustand muss klar beschrieben sein

Automatisierte Compliance-Prüfung ist nur dann sinnvoll, wenn der Soll-Zustand sauber definiert wurde. Ohne klare Standards kann ein Skript zwar Daten sammeln, aber nicht belastbar entscheiden, ob etwas korrekt oder fehlerhaft ist.

• Welche Konfigurationszeilen sind verpflichtend?
• Welche Werte sind zulässig?
• Welche Portprofile gelten für welche Rollen?
• Welche Plattformen dürfen welche Softwarestände nutzen?
• Welche Abweichungen sind tolerierbar, welche nicht?

Genau deshalb beginnt gute Compliance-Automatisierung nicht mit Python oder Ansible, sondern mit einem klaren technischen Regelwerk.

Warum manuelle Compliance-Prüfungen im Unternehmen an Grenzen stoßen

Manuelle Kontrollen sind zeitaufwendig und uneinheitlich

In kleinen Umgebungen ist es noch möglich, einzelne Geräte manuell zu prüfen. Ein Engineer verbindet sich auf Router und Switches, liest Konfigurationen aus und vergleicht sie mit einem Standarddokument. In Unternehmensnetzen mit vielen Geräten, Standorten und wiederkehrenden Changes ist das jedoch kaum dauerhaft belastbar.

• Prüfungen dauern lange.
• Nur ein Teil der Geräte wird tatsächlich kontrolliert.
• Die Tiefe der Prüfung hängt von Zeit und Erfahrung ab.
• Ergebnisse sind schwer vergleichbar.
• Zwischen zwei Prüfzeitpunkten entstehen neue Abweichungen.

Automatisierung hilft hier nicht nur aus Effizienzgründen, sondern vor allem, weil sie eine konsistentere und regelmäßige Kontrolle ermöglicht.

Drift bleibt ohne regelmäßige Prüfung oft unbemerkt

Ein typisches Problem im Netzwerkbetrieb ist Konfigurationsdrift. Gemeint ist damit die schleichende Abweichung vom definierten Standard. Diese Drift entsteht nicht immer durch grobe Fehler. Oft sind es kleine, nachvollziehbare Einzeländerungen, die sich über Monate summieren.

• Ein Hotfix wird nur auf einem Gerät gesetzt.
• Ein neuer Standard wird auf einige Geräte ausgerollt, aber nicht auf alle.
• Ein manueller Eingriff wird nicht in die Standardlogik zurückgeführt.
• Ein älteres Gerät bleibt auf einem früheren Konfigurationsstand.

Ohne automatisierte Prüfungen bleibt diese Drift häufig lange unsichtbar. Genau das macht Compliance-Automatisierung so wertvoll.

Welche Arten von Compliance-Regeln es im Netzwerk gibt

Konfigurationsbezogene Regeln

Die häufigste Form der Netzwerk-Compliance betrifft Konfigurationsinhalte. Dabei wird geprüft, ob bestimmte Konfigurationsblöcke vorhanden, fehlend oder korrekt ausgeprägt sind.

• NTP-Server korrekt konfiguriert
• Syslog-Ziele vorhanden
• SSH aktiv, Telnet deaktiviert
• Login-Banner gesetzt
• SNMP-Community oder SNMPv3-Parameter gemäß Standard
• Unused-Ports administrativ heruntergefahren

Diese Regeln sind besonders gut automatisierbar, weil sie sich oft direkt aus der Konfiguration oder aus Show-Befehlen ableiten lassen.

Versions- und Plattformregeln

Ein weiterer wichtiger Bereich betrifft Software- und Plattformstände. Unternehmen definieren oft freigegebene Versionen oder verbotene Releases, etwa wegen Bugs, Sicherheitslücken oder Supportvorgaben.

• Nur definierte IOS- oder NX-OS-Versionen sind zugelassen.
• Geräte mit bekannten Schwachstellen müssen identifiziert werden.
• Bestimmte Hardwaregenerationen sind nicht mehr freigegeben.

Typische Informationsquellen dafür sind:

show version
show inventory

Gerade diese Form der Prüfung ist für Lebenszyklus- und Security-Management besonders relevant.

Interface- und VLAN-bezogene Regeln

Auch Interface-Standards lassen sich sehr gut als Compliance-Regeln formulieren. Gerade auf Access-Switches ist dieser Bereich wichtig, weil dort viele Ports mit ähnlicher Aufgabe existieren.

• Access-Ports müssen PortFast aktiviert haben.
• BPDU Guard ist auf Benutzerports verpflichtend.
• Unused-Ports müssen deaktiviert sein.
• Trunks dürfen nur bestimmte VLANs transportieren.
• Voice-VLANs müssen an bestimmten Portprofilen vorhanden sein.

Typische Prüfquellen können sein:

show running-config
show interfaces status
show interfaces description
show vlan brief

Hier zeigt sich besonders deutlich, wie Standardisierung und Compliance eng zusammenhängen.

Wie automatisierte Compliance-Prüfung technisch funktioniert

Daten sammeln, Regeln anwenden, Abweichungen bewerten

Der technische Kern automatisierter Compliance-Prüfung besteht aus drei Schritten: Zuerst werden Daten aus dem Netzwerk gesammelt, dann werden diese Daten gegen definierte Regeln geprüft, und schließlich werden Abweichungen dokumentiert oder gemeldet.

• Geräteinformationen und Konfigurationen abrufen
• Relevante Abschnitte oder Werte extrahieren
• Mit dem Soll-Zustand vergleichen
• Ergebnisse als compliant oder non-compliant markieren

Dieser Ablauf klingt einfach, ist aber genau deshalb so stark, weil er systematisch und wiederholbar wird.

Die Datenerfassung kann über mehrere Wege erfolgen

Wie die Daten gesammelt werden, hängt von Plattform, Reifegrad und Werkzeuglandschaft ab. Für viele Netzwerke ist SSH mit Show-Befehlen ein realistischer Einstieg. In moderneren Umgebungen kommen APIs, RESTCONF, NETCONF oder Controller-Schnittstellen hinzu.

• SSH und CLI-Auswertung
• REST-APIs von Plattformen oder Controllern
• NETCONF oder RESTCONF für strukturierte Daten
• SNMP für bestimmte Status- und Inventarwerte

Für den Einstieg in Unternehmensumgebungen ist CLI-basierte Prüfung oft ausreichend, solange klar ist, dass strukturierte Schnittstellen langfristig robuster sein können.

Ein einfaches Beispiel für Compliance-Checks

Prüfung auf NTP- und Syslog-Standard

Ein sehr typischer Unternehmensstandard ist, dass alle Router und Switches bestimmte NTP- und Syslog-Ziele konfiguriert haben müssen. Diese Vorgabe lässt sich sehr gut automatisiert prüfen.

Ein gewünschter Soll-Zustand könnte sein:

ntp server 10.10.10.10
ntp server 10.10.10.11
logging host 10.20.20.20
logging host 10.20.20.21

Die Prüfung könnte dann anhand der Running-Config oder gezielter CLI-Auszüge erfolgen:

show running-config | include ntp
show running-config | include logging

Das Ergebnis der Automatisierung wäre nicht einfach nur „Konfiguration gelesen“, sondern eine klare Bewertung:

• Gerät entspricht dem Standard
• NTP-Server 2 fehlt
• Syslog-Ziel 2 fehlt
• Beide Standards unvollständig

Schon dieses einfache Muster zeigt den praktischen Nutzen sehr deutlich.

Prüfung auf SSH statt Telnet

Ein zweites klassisches Beispiel ist die Kontrolle sicherer Managementzugänge. Unternehmen definieren häufig, dass SSH erlaubt, Telnet aber nicht zugelassen ist.

Typische Prüfbasis:

show running-config | section line vty
show ip ssh

Zu prüfen wären unter anderem:

• Ist transport input ssh gesetzt?
• Wird Telnet ausgeschlossen?
• Ist SSH generell aktiviert?

Auch solche Regeln lassen sich sehr gut automatisiert bewerten.

Mit welchen Werkzeugen Compliance-Checks umgesetzt werden können

Python für flexible Einzelprüfungen

Python ist besonders nützlich, wenn Prüfregeln individuell formuliert oder mit vorhandenen Datenmodellen verbunden werden sollen. Es eignet sich sehr gut für kleine bis mittlere Compliance-Projekte, vor allem wenn SSH oder APIs genutzt werden.

• Geräteinventar aus YAML oder JSON laden
• Show-Befehle per SSH absetzen
• Antworten analysieren
• Ergebnisse in Dateien, CSV oder JSON speichern

Gerade für Lab- oder Pilotprojekte ist das oft der sinnvollste Einstieg.

Ansible für standardisierte Prüfroutinen

Wenn im Unternehmen bereits Ansible genutzt wird, lassen sich viele Compliance-Prüfungen auch damit sehr gut umsetzen. Besonders geeignet ist Ansible dort, wo Geräte bereits inventarisiert sind und Regeln auf definierte Gruppen angewendet werden sollen.

• Gerätegruppen nach Rolle prüfen
• Standardisierte CLI-Kommandos ausführen
• Ergebnisse zentral sammeln
• Abweichungen reproduzierbar reporten

Die Stärke liegt hier vor allem in der Standardisierung und Wiederholbarkeit über viele Geräte hinweg.

Controller und APIs für strukturierte Umgebungen

In controllerbasierten oder modellgetriebenen Umgebungen können Compliance-Prüfungen direkt auf strukturierte Zustands- und Konfigurationsdaten zugreifen. Das reduziert die Notwendigkeit, freie CLI-Texte zu interpretieren.

• REST-APIs liefern Geräte- und Zustandsdaten
• RESTCONF oder NETCONF ermöglichen modellorientierte Prüfungen
• Controller stellen zentrale Sicht auf Gerätezustände bereit

Der organisatorische Reifegrad muss dafür allerdings meist höher sein als bei einfachen SSH-Skripten.

Wie man Compliance-Regeln sinnvoll formuliert

Technisch eindeutig und maschinenprüfbar

Eine gute Compliance-Regel muss so formuliert sein, dass ein Mensch und ein Skript sie gleich verstehen können. Vage Aussagen wie „Ports sollen sicher konfiguriert sein“ helfen wenig. Besser sind konkrete, technische Soll-Beschreibungen.

• Alle Benutzerports müssen spanning-tree portfast enthalten.
• Alle unused-Ports müssen administrativ heruntergefahren sein.
• Alle Router müssen beide definierten NTP-Server eingetragen haben.
• Telnet darf auf VTY-Linien nicht erlaubt sein.

Je präziser die Regel, desto robuster lässt sie sich automatisieren.

Regeln nach Kritikalität priorisieren

Nicht jede Abweichung ist gleich kritisch. Für Unternehmen ist es sinnvoll, Compliance-Regeln zu priorisieren. So lassen sich Berichte besser bewerten und Teams fokussieren sich zuerst auf die wichtigsten Verstöße.

• Kritisch: unsichere Managementzugänge, fehlende AAA-Standards
• Hoch: fehlende Syslog- oder NTP-Konfiguration
• Mittel: fehlende Beschreibungen auf Uplinks
• Niedrig: leichte Abweichungen in Namenskonventionen

Diese Priorisierung macht aus einer bloßen Prüfliste ein brauchbares Steuerungsinstrument.

Was gute automatisierte Compliance-Prüfungen auszeichnet

Sie bewerten, statt nur Daten zu sammeln

Ein häufiger Fehler besteht darin, viele Show-Befehle zu sammeln, ohne daraus eine klare Aussage abzuleiten. Echte Compliance-Automatisierung geht einen Schritt weiter: Sie bewertet den Zustand gegen definierte Regeln.

• Nicht nur: Konfiguration gelesen
• Sondern: Standard eingehalten oder verletzt

Genau diese Bewertung ist der eigentliche Mehrwert. Erst dadurch entstehen nutzbare Ergebnisse für Betrieb, Security und Audits.

Sie sind regelmäßig und wiederholbar

Ein einmaliger Check kann hilfreich sein, ist aber noch keine belastbare Compliance-Praxis. Der eigentliche Wert entsteht durch regelmäßige Ausführung und vergleichbare Ergebnisse.

• Tägliche oder wöchentliche Prüfungen
• Prüfung vor und nach Standardchanges
• Vergleich von Drift über die Zeit
• Nachvollziehbare Historie von Abweichungen

Selbst wenn die erste Umsetzung noch einfach ist, sollte diese Wiederholbarkeit von Anfang an mitgedacht werden.

Typische Herausforderungen und Fehlerquellen

Fehlende oder inkonsistente Standards

Viele Compliance-Projekte scheitern nicht an Python oder Ansible, sondern daran, dass der Soll-Zustand im Unternehmen nie klar genug definiert wurde. Dann entsteht Streit darüber, ob ein Gerät wirklich abweicht oder nur historisch anders aufgebaut ist.

• Regeln sind nicht eindeutig dokumentiert.
• Alt- und Neusysteme folgen unterschiedlichen Standards.
• Rollenmodelle sind unklar.
• Standards existieren informell, aber nicht technisch belastbar.

Deshalb ist Standardisierung immer die Grundlage für belastbare Compliance-Automatisierung.

Nur Symptome reporten, aber keine Einordnung liefern

Wenn ein Report hunderte Abweichungen listet, aber keine Priorisierung oder Gruppierung enthält, sinkt sein praktischer Wert stark. Teams brauchen nicht nur Daten, sondern Orientierung.

• Welche Verstöße sind kritisch?
• Welche Geräte oder Standorte sind besonders auffällig?
• Welche Abweichungen beruhen auf bekannten Ausnahmen?

Gute Compliance-Prüfungen liefern deshalb nicht nur Rohfunde, sondern eine nutzbare Struktur.

Keine Rückkopplung in Standardisierung und Change-Prozesse

Ein weiterer typischer Fehler besteht darin, Compliance-Ergebnisse nur zu sammeln, aber nicht in operative Prozesse zurückzuführen. Dann wächst die Liste der Verstöße, ohne dass das Netzwerk wirklich besser wird.

Compliance-Automatisierung ist dann besonders wirksam, wenn sie mit Standardpflege, Templates, Change-Management und Verantwortlichkeiten verbunden wird.

Best Practices für automatisierte Compliance-Prüfungen im Unternehmen

• Compliance-Regeln zuerst fachlich und technisch klar definieren, bevor sie automatisiert werden.
• Mit wenigen, klaren Standards wie NTP, Syslog, SSH oder Interface-Profilen beginnen.
• Regeln so formulieren, dass sie maschinenprüfbar und eindeutig sind.
• CLI-basierte Prüfungen als pragmatischen Einstieg nutzen, aber strukturierte Schnittstellen langfristig im Blick behalten.
• Ergebnisse nicht nur sammeln, sondern klar als compliant oder non-compliant bewerten.
• Abweichungen nach Kritikalität und Gerätetyp priorisieren.
• Compliance-Prüfungen regelmäßig wiederholen statt nur einmalig durchführen.
• Inventardaten, Gerätegruppen und Rollen sauber pflegen, damit Prüfungen korrekt adressieren.
• Reports so strukturieren, dass Betriebsteams konkrete Maßnahmen ableiten können.
• Compliance-Automatisierung mit Standardisierung, Templates und Change-Prozessen verzahnen.

Compliance-Prüfungen im Unternehmen zu automatisieren bedeutet damit weit mehr, als nur Konfigurationszeilen zu durchsuchen. Es geht darum, den tatsächlichen Netzwerkzustand systematisch gegen definierte Standards zu bewerten und aus dieser Bewertung eine belastbare betriebliche Steuerung zu machen. Gerade in gewachsenen Umgebungen hilft dieser Ansatz dabei, Drift sichtbar zu machen, Sicherheitsvorgaben konsequenter einzuhalten und Standardisierung nicht nur auf dem Papier, sondern im realen Netzwerkbetrieb durchzusetzen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.