Automatisierung im Netzwerk: Zero-Touch, NAC und KI
Smart geschaltet
Veröffentlicht in Ausgabe 03/2026 - SCHWERPUNKT
Netzwerke transportieren Daten zwischen Endpunkten. Switches, Router, Firewalls und Loadbalancer bilden dafür die physische und logische Infrastruktur. Moderne Konzepte wie SDN, SD-WAN und NFV abstrahieren viele Funktionen, aber der Kern bleibt gleich: Pakete sollen zuverlässig, vorhersehbar und kontrolliert von A nach B gelangen. Netzwerkautomatisierung erzeugt hierbei wiederholbare Abläufe. Statt Konfigurationsschritte immer wieder manuell auszuführen, formulieren NetOps-Teams Prozesse in Python-Skripten, Ansible-Playbooks oder in den Policies eines Controllers wie Cisco Catalyst Center, ISE oder Aruba ClearPass. So bleibt das Verhalten im Netz reproduzierbar, lässt sich einfach überprüfen und bei Bedarf wieder auf den vorherigen Stand bringen.
Manuelle Konfiguration mit Risiken
Solange jemand die Konfiguration auf jedem Gerät einzeln ändert, wächst die Streuung. Ein Switch erhält eine leicht andere Access Control List (ACL), ein anderer ein abweichendes Management-VLAN, ein dritter behält ein altes Image. Diese Unterschiede fallen im Alltag zunächst kaum auf, sie summieren sich aber. Die Folgen reichen von subtilen Performanceproblemen bis zu klaren Instabilitäten, wenn Spanning-Tree-Varianten, MTU-Werte oder Routingparameter nicht mehr zusammenpassen.
Gleichzeitig verlangen digitale Geschäftsprozesse kurze Durchlaufzeiten. Applikationen kommen hinzu, Segmente entstehen, Rollen ändern sich. Die mittlere Zeit bis zur Behebung einer Störung (MTTR) steigt, weil niemand mehr sicher weiß, welcher Port, welcher Switch und welche ACL wirklich "Standard" sind. Automatisierung hilft NetOps-Teams, Managementaufgaben zu standardisieren und bewährte Vorgaben konsequent umzusetzen. Sie legen eine Baseline einmal fest und spielen sie auf alle relevanten Systeme. Sie definieren Portprofile, VLAN-Zuweisungen und Rollenregeln als wiederverwendbare Muster und setzen diese gezielt ein. So entstehen weniger Varianten, und Fehlkonfigurationen treten deutlich seltener auf.
Netzwerke transportieren Daten zwischen Endpunkten. Switches, Router, Firewalls und Loadbalancer bilden dafür die physische und logische Infrastruktur. Moderne Konzepte wie SDN, SD-WAN und NFV abstrahieren viele Funktionen, aber der Kern bleibt gleich: Pakete sollen zuverlässig, vorhersehbar und kontrolliert von A nach B gelangen. Netzwerkautomatisierung erzeugt hierbei wiederholbare Abläufe. Statt Konfigurationsschritte immer wieder manuell auszuführen, formulieren NetOps-Teams Prozesse in Python-Skripten, Ansible-Playbooks oder in den Policies eines Controllers wie Cisco Catalyst Center, ISE oder Aruba ClearPass. So bleibt das Verhalten im Netz reproduzierbar, lässt sich einfach überprüfen und bei Bedarf wieder auf den vorherigen Stand bringen.
Manuelle Konfiguration mit Risiken
Solange jemand die Konfiguration auf jedem Gerät einzeln ändert, wächst die Streuung. Ein Switch erhält eine leicht andere Access Control List (ACL), ein anderer ein abweichendes Management-VLAN, ein dritter behält ein altes Image. Diese Unterschiede fallen im Alltag zunächst kaum auf, sie summieren sich aber. Die Folgen reichen von subtilen Performanceproblemen bis zu klaren Instabilitäten, wenn Spanning-Tree-Varianten, MTU-Werte oder Routingparameter nicht mehr zusammenpassen.
Gleichzeitig verlangen digitale Geschäftsprozesse kurze Durchlaufzeiten. Applikationen kommen hinzu, Segmente entstehen, Rollen ändern sich. Die mittlere Zeit bis zur Behebung einer Störung (MTTR) steigt, weil niemand mehr sicher weiß, welcher Port, welcher Switch und welche ACL wirklich "Standard" sind. Automatisierung hilft NetOps-Teams, Managementaufgaben zu standardisieren und bewährte Vorgaben konsequent umzusetzen. Sie legen eine Baseline einmal fest und spielen sie auf alle relevanten Systeme. Sie definieren Portprofile, VLAN-Zuweisungen und Rollenregeln als wiederverwendbare Muster und setzen diese gezielt ein. So entstehen weniger Varianten, und Fehlkonfigurationen treten deutlich seltener auf.
Loadbalancing, Failover und dynamische Anpassung
Die gleichen Prinzipien gelten für Lastverteilung und Failover. Anwendungen benötigen eine gleichmäßige Verteilung auf Server und Standorte, damit Performance und Kosten im Rahmen bleiben. Bei manueller Regelung fallen überlastete Knoten in der Regel erst auf, wenn Nutzer Beschwerden melden.
Automatisierte Mechanismen lösen diese Bremse. Monitoring- und Orchestrierungswerkzeuge erfassen Last und Zustand und passen Verteilung und Failover-Regeln laufend an. Ein Loadbalancer nimmt defekte Instanzen automatisch aus dem Pool, verschiebt Sessions und liefert Statusdaten an das Monitoring. Routen und Policies greifen nach einem zuvor definierten Plan und entstehen nicht erst im Notfall unter Zeitdruck. So sinkt die MTTR. Das Netz verhält sich stabiler, weil klare Reaktionspfade an die Stelle spontaner Eingriffe treten.
SDN und Intent-based Networking
Software-defined Networking (SDN) liefert die Architektur für automatisierte Netze. Ein Controller übernimmt die Steuerung, die Geräte leiten den Traffic. Der Controller hält Inventar, Topologie und Basisparameter. Er erzeugt Konfigurationen aus Modellen und spielt sie auf Switches, Router und Firewalls. Er sammelt Telemetrie und erkennt Abweichungen. IT-Verantwortliche steuern Konfigurationen damit programmatisch, statt auf jedem Gerät im CLI zu arbeiten.
Intent-based Networking sitzt eine Ebene darüber. Es beschreibt nicht mehr einzelne Befehle, sondern das gewünschte Verhalten im Netz. Ein Intent legt zum Beispiel fest, welche Rolle welche Applikation erreichen darf, welche Zonen strikt getrennt bleiben und welche Dienste standortübergreifend verfügbar sein sollen. Der Controller übersetzt diese Vorgaben in VLANs, VRFs, ACLs oder tagbasierte Regeln und prüft fortlaufend, ob der Ist-Zustand dazu passt. Konfigurationsarbeit orientiert sich damit an Zielen, nicht an Befehlsketten.
NAC als Bindeglied
Damit Policies im Sinne des Intents präzise greifen, braucht das Netz einen Kontext. Ein Access-Switch sieht zunächst nur Port und MAC-Adresse. Für eine sinnvolle Entscheidung reicht das nicht. Network Access Control (NAC) ergänzt diese Sicht um Identität, Gerätetyp und optional den Sicherheitszustand. Systeme wie Cisco ISE oder Aruba ClearPass authentisieren Benutzer und Geräte. Sie werten Zertifikate und Verzeichnisinformationen aus und nutzen Profiling, um Gerätetypen zu erkennen. Aus diesen Merkmalen leiten sie eine Rolle ab. Diese Rolle setzt das NAC-System in konkrete Maßnahmen um: VLAN-Zuweisung, dynamische ACL oder Security-Tag. Der Switch übernimmt die Vorgaben direkt am Port.
Hier greifen SDN/IBN und NAC ineinander. Zero-Touch-Provisioning sorgt dafür, dass ein Access-Switch mit einer sauberen Baseline, den benötigten VLANs und den passenden Portprofilen startet. NAC entscheidet anschließend für jeden Client, welche Rolle an diesem Port gilt. Policy-Deployment nimmt diese Rolle auf, erzeugt daraus die passenden Regeln und verteilt sie über den Controller oder über APIs im Netz. Netzwerkautomatisierung bleibt damit nicht bei Infrastrukturkonfiguration stehen. Sie umfasst auch Identität, Zugriff und Segmentierung und verbindet SDN/IBN und NAC zu einem durchgängigen Steuerungsmodell.
Provisionierung mit Cisco Catalyst Center
Cisco Catalyst Center (früher DNA Center) übernimmt im Cisco-Umfeld die Controller-Rolle im Campusnetz und verbindet Standortmodell, Inventar, Provisionierung und Assurance zu einer Plattform. IT-Teams starten typischerweise im Designbereich. Dort bildet das Netzwerkteam die reale Struktur ab, legt Standorte, Gebäude und Etagen an und hinterlegt IP-Bereiche für Access und Management. Zentrale Parameter wie DNS-Server, NTP, Syslog-Ziele und AAA-Server landen nicht in einer separaten Dokumentation, sondern direkt im Controller. Jede spätere Provisionierung greift auf genau diese Informationen zu.
Im Inventar sammelt Catalyst Center alle Geräte. Bestehende Switches kommen über Discoveries hinein, neue Geräte melden sich über Zero-Touch-Verfahren. Ein neuer Switch erhält meist per DHCP seine Managementadresse und die Information, wie er den Controller erreicht. Nach dieser ersten Verbindung erscheint er im Inventar als unprovisioniertes Gerät. Ab diesem Moment setzt die automatische Bereitstellung ein. Das Netzwerkteam ordnet den Switch einem Standort zu und weist ihm eine Rolle wie "Access-Switch Büro" zu. Catalyst Center kennt damit Kontext, Parameter und Aufgabe des Geräts. Die Plattform lädt bei Bedarf das freigegebene Image, spielt die Baseline-Konfiguration ein und weist die vorgesehenen Portprofile zu.
Templates bilden den Kern der Konfiguration. Ein Template bündelt etwa alle AAA-Einstellungen, ein anderes kümmert sich um Logging und Zeitdienste, ein drittes definiert Interface-Defaults und Beschreibungen. Variablen greifen Standortdaten, IP-Bereiche oder Geräteeigenschaften aus der Catalyst-Center-Datenbank ab. Wenn das Netzwerkteam die Syslog-Konfiguration anpassen möchte, ändert es das betreffende Template und stößt einen Deployment-Lauf an. Catalyst Center erzeugt daraus die gerätespezifische Konfiguration und schreibt sie auf alle betroffenen Switches.
Portprofile vereinfachen den Alltag an der Access-Schicht zusätzlich. Ein Profil "Büroclient" enthält zum Beispiel Access-VLAN, Voice-VLAN, Portfast, QoS-Parameter und ein Namensschema für die Beschreibung. Administratoren weisen einem Port dieses Profil zu, Catalyst Center generiert die Befehle und spielt sie auf. Der resultierende Port bleibt auf allen Switches identisch, unabhängig davon, wer ihn anlegt.
Assurance liefert die Rückkopplung. Catalyst Center zeigt für jeden Provisionierungslauf, welche Schritte erfolgreich liefen und wo ein Gerät Befehle abgelehnt hat. Die Plattform markiert Abweichungen von der Baseline, weist auf Switches mit veralteten Images hin und zeigt typische Clientprobleme wie Authentisierungsfehler, hohe Fehlerraten oder Auffälligkeiten an bestimmten Access-Switches. NetOps-Teams sehen damit nicht nur, dass eine Konfiguration verteilt wurde, sondern auch, ob sie vollständig angekommen ist.
NAC mit Cisco ISE und Aruba ClearPass automatisieren
Network Access Control übernimmt in automatisierten Netzen die Rolle des Entscheidungsträgers für Zugriffe. Cisco ISE und Aruba ClearPass setzen diesen Ansatz mit unterschiedlichen Schwerpunkten um, verfolgen aber eine ähnliche Logik. Cisco ISE verbindet Authentisierung, Autorisierung, Profiling und Kontextaustausch. Access-Switches und WLAN-Controller schicken RADIUS-Anfragen an ISE.
Die Plattform prüft Benutzerkonten gegen Verzeichnisdienste, wertet Zertifikate aus, bezieht optional Posture-Daten ein und klassifiziert Geräte über Profiling-Regeln. Aus dieser Kombination entsteht ein Autorisierungsergebnis. Dieses legt fest, welche Rolle ein Client erhält. ISE weist ein VLAN zu, lädt eine ACL auf den Switch oder vergibt einen Security Group Tag. Der Switch setzt diese Vorgabe direkt auf dem Port um. Ein und derselbe Port kann damit unterschiedliche Rollen vergeben, je nachdem, welches Gerät sich anmeldet.
Automation entsteht, sobald andere Systeme Informationen liefern und ISE diese verarbeitet. Über die REST-Schnittstelle füttert beispielsweise ein Asset- oder MDM-System Endpoint-Gruppen. Ein EDR-System meldet kompromittierte Geräte und markiert sie als "Quarantäne". ISE löst daraufhin einen Change of Authorization aus. Der Switch authentisiert hierbei den Client neu, und ISE weist eine restriktive Rolle zu. Das IT-Team muss keinen Port mehr manuell sperren.
Aruba ClearPass arbeitet mit einem ähnlichen Baukasten. Der Policy Manager nimmt Authentisierungen entgegen, führt sie gegen LDAP oder Active Directory aus und verknüpft sie mit MDM- oder Asset-Informationen. ClearPass erkennt Gerätetypen mit umfangreichen Profiling-Funktionen. DHCP-Optionen, HTTP-Header oder Verkehrsmuster liefern Hinweise auf Drucker, VoIP-Telefone oder IoT-Geräte. Die Plattform ordnet diesen Endpunkten Rollen zu und setzt Enforcement-Profile um. Diese Profile steuern VLANs, ACLs oder Controller-Rollen.
Ein praktikabler Einstieg in die NAC-Automatisierung beginnt selten mit dem kompletten Netz. Sinnvoll ist ein Pilotbereich mit überschaubarer Teilnehmerzahl, etwa eine Etage oder ein Gebäudeteil. Dort definieren Sie ein Rollenmodell. Zum Beispiel: "Mitarbeitergerät verwaltet", "Mitarbeitergerät privat", "Drucker", "IoT", "Gast". Für jede Rolle entsteht eine klare Beschreibung, welche Ziele der Client erreichen darf. ISE oder ClearPass setzt diese Beschreibung in VLANs und ACLs um.
Wichtig bleibt die Planung von Ausnahmen und Fallback-Verhalten. Nicht jeder Drucker akzeptiert strenge 802.1X-Profile. Manche Anwendungen reagieren empfindlich auf neue Segmentgrenzen. Ein realistischer Plan arbeitet aus diesem Grund mit Übergangsrollen und einer Monitoringphase. In der Zeit wertet das NAC-System die Zugriffe aus, ohne sie sofort hart zu blockieren. Erst wenn die Muster klar sind und das Rollenmodell steht, kann die Durchsetzung erfolgen – ohne unnötige Ausfallrisiken.
Sieben Bausteine für Netze im Autopilot-Modus
1. Saubere Baselines statt individueller Gerätekonfigurationen: Automatisierung beginnt nicht mit Skripten, sondern mit Klarheit. Definieren Sie eine verbindliche Baseline für Images, Managementzugänge, Logging, Zeitdienste und Security-Standards. Erst wenn alle Geräte von derselben Ausgangsbasis starten, entfalten Controller, Templates und Zero-Touch-Verfahren ihren Nutzen.2. Zero-Touch-Provisioning für Hardwarewechsel und Rollouts: Neue Switches oder Ersatzgeräte sollten ohne manuelle CLI-Eingriffe produktiv gehen. DHCP, Plug-and-Play und ein zentraler Controller übernehmen Initialkonfiguration, Image-Download und Rollenzuweisung. Das reduziert Fehler und beschleunigt Rollouts – gerade bei Störungen oder größeren Erweiterungen.3. Intent statt Befehle definieren: Beschreiben Sie, was das Netz leisten soll, nicht wie einzelne Geräte es umsetzen. Intent-based Networking übersetzt fachliche Ziele in VLANs, VRFs, ACLs oder Tags und prüft kontinuierlich die Abweichung vom Sollzustand. Das entlastet NetOps-Teams von Detailarbeit und schafft nachvollziehbare Regeln.4. NAC als Entscheidungsinstanz für Zugriffe nutzen: Network Access Control liefert den Kontext, den Switches allein nicht haben. Identität, Gerätetyp und Sicherheitszustand bestimmen die Rolle eines Endpunkts. VLANs, dACLs oder Security-Tags entstehen dynamisch. So bleibt die Zugriffskontrolle konsistent, auch wenn sich Geräte, Nutzer oder Standorte ändern.5. Policies über APIs und Git steuern: VLANs, ACLs und Rollen profitieren von denselben Prinzipien wie Softwarecode. Pflegen Sie Policies versioniert, mit Review-Prozessen und automatisierten Tests. APIs schreiben die freigegebenen Änderungen in Controller oder Geräte. Das erhöht Transparenz und verhindert unkontrolliertes Regelwachstum.6. Assurance und KI für schnelle Ursachenanalyse einsetzen: Telemetrie, Monitoring und KI-gestützte Auswertung verkürzen die Fehlersuche deutlich. Systeme erkennen Anomalien früh, korrelieren Symptome und schlagen Ursachen vor. Das senkt die MTTR nicht nur technisch, sondern auch organisatorisch, weil Diskussionen über Zuständigkeiten abnehmen.7. Automatisierung mit klarer Verantwortung kombinieren: Autopilot heißt nicht Autonomie ohne Kontrolle. Rollenmodelle, NAC-Policies und KI-Empfehlungen brauchen fachliche Ownership. Klären Sie, wer Regeln definiert, wer sie freigibt und wer Automatismen scharf schaltet. Nur dann skaliert Automatisierung, ohne neue Risiken zu schaffen.
VLAN- und ACL-Einstellungen per API
Controller und NAC-Systeme bringen viel Automatisierung mit, aber sie decken nicht jede Anforderung ab. Viele Abläufe lassen sich erst dann optimal integrieren, wenn VLAN- und ACL-Änderungen über APIs laufen.
Ein häufiges Szenario startet im Change- oder Request-System. Ein Fachbereich benötigt ein neues Segment für ein Projekt. Der Antrag beschreibt die benötigten Applikationen und grob die Kommunikationswege. Das Ticketsystem ruft daraufhin das IP-Adressmanagement-System (IPAM) auf, reserviert ein Netz, vermerkt es in der Dokumentation und ruft schließlich das API des Controllers auf. Dieser legt ein neues VLAN mit Name, ID und Subnetz an und ordnet es einer bestehenden Virtual-Routing-and-Forwarding-Instanz (VRF) zu. Parallel erzeugt er Standard-ACLs oder Security-Policies, die dieses Segment in die Gesamtsegmentierung einbinden.
Viele Betreiber behandeln Policies zusätzlich wie Quellcode. ACLs, Rollen und Segmentregeln liegen in Konfigurationsdateien in einem Git-Repository. Eine Änderung durchläuft denselben Weg wie ein Software-Commit. Jemand passt eine Policy-Datei an, erzeugt eine Merge-Anfrage, eine andere Person prüft die Änderung, und automatisierte Tests kontrollieren Syntax und grundlegende Konsistenz. Erst danach schreibt eine Pipeline die Konfiguration über das API in den Controller.
In heterogenen Umgebungen läuft dieser Weg nicht immer über einen zentralen Controller. Einige Betreiber sprechen direkt mit den Geräten über NETCONF, RESTCONF oder proprietäre REST-APIs. Eine Orchestrierungsschicht liest das zentrale Modell, übersetzt es in gerätespezifische Kommandos und verteilt sie. Entscheidend ist auch hier, dass die fachliche Beschreibung unabhängig von der Hardware bleibt.
Gerade bei ACLs zeigt sich der Nutzen. Regelwerke wachsen seit Jahren und enthalten viele Einträge, die niemand mehr klar zuordnet. API-basierte Pflege erlaubt eine eindeutige Kennzeichnung jeder Regel, inklusive fachlicher Beschreibung und Ticketreferenz. Logauswertungen und Telemetrie zeigen, welche Regeln noch Traffic sehen. Auf dieser Basis können Sie alte Einträge kontrolliert entfernen, statt sie aus Vorsicht stehenzulassen.
Vorteile KI-gestützter Netze
Automatisierung senkt im Netzwerkbetrieb vor allem Durchlaufzeiten und Fehlerrisiko. Neue Access-Switches gehen deutlich schneller live, weil IT-Teams sie nicht mehr einzeln per CLI einrichten. Ein Tausch nach einem Defekt läuft meist so ab: Techniker stecken den Ersatz ein, Cisco Catalyst Center erkennt das Gerät, ordnet es einem Standort zu, weist das hinterlegte Profil zu und rollt Baseline und Portprofile aus. Viele Fehler, die früher in der Hektik eines Vor-Ort-Einsatzes entstanden, verschwinden, weil niemand mehr "mal eben" manuell nachkonfiguriert.
Parallel liefern KI-Funktionen spürbare Veränderungen. Cisco Catalyst Center bringt mit Cisco AI Network Analytics eine ML-Schicht in die Assurance. Die Plattform wertet Telemetriedaten über Wochen hinweg aus, lernt das Normalverhalten der eigenen Umgebung und erkennt Abweichungen frühzeitig. Sie zeigt KI-basiert Anomalien, Trends und betroffene Clients oder Access Points und unterstützt NetOps-Teams mit Ursachenanalysen und konkreten Vorschlägen für Gegenmaßnahmen. So sinkt die MTTR nicht nur, weil die Konfiguration schneller ausgerollt wird, sondern auch, weil die Fehlersuche zielgerichteter läuft.
Die NAC-Automatisierung verkürzt die Reaktion auf Sicherheitsereignisse. Erkennt ein Security Operations Center (SOC) über ein EDR-System einen kompromittierten Host, reicht ein Eintrag oder ein Tag im Security-Stack. Cisco ISE nimmt diese Information über pxGrid oder eine REST-Integration auf und setzt den Client in eine restriktive Rolle, oft inklusive Quarantäne-VLAN oder dACL. Der Rechner erreicht vielleicht noch einen Cleanup-Server, aber nicht mehr produktive Systeme. NetOps-Teams müssen keine Ports suchen und keine ACLs "im Flug" anpassen, die Automatisierung setzt den Beschluss um.
Provisionierungen, Policy-Deployments, NAC-Entscheidungen und KI-basierte Hinweise landen in Logs, Reports und Tickets. IT-Verantwortliche können jederzeit nachweisen, wann ein Gerät welche Rolle erhalten hat, wann ein VLAN entstanden ist oder wann eine ACL-Regel hinzugekommen ist. KI-gestützte Assurance fasst dabei viele Einzelsignale zu Issues zusammen und dokumentiert Gründe und empfohlene Schritte. Das erleichtert Audits und reduziert Diskussionen mit Revision oder Informationssicherheit, weil Entscheidungen und deren technische Umsetzung sich schnell nachvollziehen lassen.
Grenzen automatisierter Netze
Automatisierung und KI lösen nicht jede Baustelle, sie verschieben manche Themen. Ein Punkt betrifft die Bindung an Ökosysteme. Wer stark auf einen Hersteller-Stack setzt, profitiert von durchgängigen Workflows, nimmt aber auch einen Lock-in in Kauf. Cisco Catalyst Center, Catalyst-Switches und ISE greifen sehr eng ineinander, vergleichbare Kombinationen gibt es bei anderen Anbietern. Diese Entscheidung erfordert eine bewusste Abwägung zwischen Funktionsumfang, Komfort und strategischer Unabhängigkeit.
Die Migration in bestehende Netze bleibt aufwendig. Historisch gewachsene VLAN-Landschaften, lokale ACL-Sammlungen und schlecht dokumentierte Sonderwege passen selten in ein sauberes Rollen- und Segmentierungsmodell. Bevor Zero-Touch-Provisioning, NAC-Automation, KI-gestützte Assurance und API-Pipelines ihr Potenzial entfalten, müssen NetOps-Teams oft aufräumen: Inventar konsolidieren, Baselines vereinheitlichen, Legacy-Konfigurationen zurückbauen. Erst danach greifen Automatismen und KI-Auswertungen wirklich konsistent.
Mit KI-Funktionen kommen zusätzliche Fragen hinzu. Cisco AI Network Analytics nutzt Telemetriedaten in einer Cloudplattform, um Baselines zu berechnen, Anomalien zu erkennen und Peer-Vergleiche zu ermöglichen. Das bringt bessere Erkennung, wirft aber dennoch Themen wie Datenschutz, Datenexport und Modelltransparenz auf. Administratoren müssen klären, welche Daten das Haus verlassen dürfen, wie sie Pseudonymisierung umsetzen und wie sie mit KI-Empfehlungen umgehen, die sich nicht sofort erklären lassen.
Zudem steigen die Anforderungen an die IT-Verantwortlichen. Netzwerkexperten müssen klassische Themen wie Routing, Switching und 802.1X beherrschen und zusätzlich mit APIs, Templates, Git und KI-gestützten Dashboards arbeiten. Sie interpretieren KI-betriebene Issues, prüfen vorgeschlagene Remediation-Steps und entscheiden, welche Automatik sie scharf schalten. Die Rolle wandelt sich vom CLI-Spezialisten zum Architekten für Betriebsmodelle und Datenflüsse.
Dazu kommt der Ownership-Aspekt. NAC-Policies berühren Identitätsmanagement, Endpoint-Management und Security. Segmentierung greift in die Anwendungsarchitektur und Fachbereiche ein. Controller, AIOps-Funktionen und Automatisierungstools liegen oft beim Netzwerkteam. Ohne abgestimmte Zuständigkeiten besteht die Gefahr, dass niemand das Gesamtbild verantwortet und dass Automatismen falsche oder veraltete Regeln sehr effizient ausrollen.
Fazit
Netzwerktechnik rückt immer stärker in die Rolle einer Plattform. Darauf aufbauend lässt sich Automatisierung schrittweise vertiefen, beispielsweise durch Zero-Touch-Provisioning, NAC-gesteuerte Zugriffe, API-basierte Policy-Workflows und KI-gestützte Analysefunktionen. Gleichzeitig bleiben offene Punkte auf dem Tisch, zum Beispiel der Umgang mit Telemetriedaten, die Abhängigkeit von Herstellern und die Frage, wer automatisierte Eingriffe fachlich verantwortet. Gelingt hier eine geeignete Balance, entsteht aus vielen einzelnen Gerätekonfigurationen eine Infrastruktur, die Stabilität bietet, aber trotzdem schnell genug bleibt, um neue Anwendungen und Geschäftsmodelle mit wenig Reibungsverlusten aufzunehmen.
(dr)