Netzwerksicherheit Nac: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Network Access Control, kurz NAC, entscheidet nicht nur darüber, ob ein Gerät ins Netz darf. In einer sauberen Sicherheitsarchitektur steuert NAC, unter welchen Bedingungen ein Gerät Zugang erhält, in welches Segment es einsortiert wird, welche Identität dabei verwendet wird und welche Reaktion bei Abweichungen erfolgt. Genau an diesem Punkt scheitern viele Umsetzungen: NAC wird als Einmalprojekt betrachtet, obwohl es in Wahrheit eine laufende Kontrollinstanz zwischen Identität, Endpunktzustand, Switch-Infrastruktur, WLAN, Verzeichnisdiensten und Richtlinien ist.

Im Kern beantwortet NAC vier Fragen. Wer verbindet sich? Was verbindet sich? Von wo aus erfolgt der Zugriff? In welchem Zustand befindet sich das System? Erst aus diesen Antworten entsteht eine belastbare Entscheidung. Ohne diese Logik bleibt Netzwerkzugang oft binär: Port aktiv oder Port gesperrt. Das reicht in modernen Umgebungen mit BYOD, IoT, Druckern, VoIP, OT-Komponenten, Gästen und hybriden Arbeitsmodellen nicht mehr aus.

NAC ist eng mit Sicherheitsarchitektur, Netzwerksicherheit Segmentierung und Netzwerksicherheit Zero Trust verbunden. Wer NAC isoliert einführt, ohne Segmentierungsmodell, Rollenmodell und Betriebsprozesse zu definieren, erzeugt meist nur neue Störungen. Wer NAC dagegen als Policy-Enforcement-Schicht versteht, kann Zugriffe dynamisch steuern und die Angriffsfläche deutlich reduzieren.

Technisch basiert NAC häufig auf 802.1X mit EAP über LAN oder WLAN, RADIUS als Entscheidungsinstanz und ergänzenden Verfahren wie MAC Authentication Bypass für Geräte, die kein 802.1X beherrschen. Dazu kommen Posture-Prüfungen, Profiling, Zertifikatsprüfung, dynamische VLAN-Zuweisung, Security Group Tags, ACL-Push oder Quarantäne-Netze. Die eigentliche Stärke entsteht nicht durch ein einzelnes Protokoll, sondern durch die Kombination aus Identitätsprüfung, Zustandsbewertung und kontrollierter Netzfreigabe.

Aus Sicht eines Pentests ist NAC nie nur eine Zugangskontrolle. Es ist ein Prüfpunkt für Fehlannahmen. Wenn ein Unternehmen behauptet, unbekannte Geräte hätten keinen Zugang, dann wird getestet, ob wirklich jeder Edge-Port kontrolliert ist, ob Fallback-Mechanismen zu offen sind, ob MAB zu großzügig arbeitet, ob Voice-VLANs missbraucht werden können oder ob sich über falsch konfigurierte Supplicants und Zertifikate doch ein produktiver Zugang erreichen lässt. Genau deshalb gehört NAC in jede ernsthafte Betrachtung von Netzwerksicherheit und Pentesting Netzwerk.

Ein belastbares NAC-Konzept reduziert nicht nur unautorisierte Zugriffe. Es verbessert auch Transparenz. Unbekannte Geräte, falsch konfigurierte Clients, veraltete Betriebssysteme, nicht verwaltete IoT-Systeme und Schatten-IT werden sichtbar. Diese Sichtbarkeit ist oft wertvoller als die reine Blockadefunktion, weil sie operative Schwächen offenlegt, die sonst erst im Incident auffallen.

Wer NAC sauber betreiben will, muss die Protokollkette verstehen. Am Access-Port sitzen drei Rollen: der Supplicant auf dem Endgerät, der Authenticator auf Switch oder Access Point und der Authentication Server, meist ein RADIUS-System. Der Authenticator transportiert EAP-Nachrichten zwischen Endgerät und RADIUS. Erst der RADIUS-Server trifft die eigentliche Policy-Entscheidung und liefert Attribute zurück, etwa VLAN, ACL, Session-Timeout oder Rolleninformationen.

802.1X ist dabei nur der Rahmen. Die eigentliche Sicherheit hängt stark von der gewählten EAP-Methode ab. EAP-TLS mit Client-Zertifikaten ist in der Regel deutlich robuster als passwortbasierte Verfahren, weil keine wiederverwendbaren Zugangsdaten über unsichere Endgeräte verteilt werden müssen. PEAP oder EAP-TTLS können in bestimmten Umgebungen sinnvoll sein, bringen aber zusätzliche Risiken mit, wenn Zertifikatsprüfung auf Client-Seite unsauber umgesetzt wird oder Benutzer Anmeldedialoge unkritisch bestätigen.

MAC Authentication Bypass ist kein gleichwertiger Ersatz für 802.1X. MAB ist ein Kompromiss für Geräte ohne Supplicant, etwa Drucker, Scanner, Kameras, medizinische Geräte oder industrielle Komponenten. Die Identität basiert dann nur auf der MAC-Adresse, also auf einem Merkmal, das trivial zu fälschen ist. MAB darf deshalb nie als starke Authentisierung verstanden werden. Es ist bestenfalls ein Mechanismus zur Einordnung in ein restriktives Segment mit minimalen Rechten.

In der Praxis entsteht die Policy-Entscheidung aus mehreren Datenquellen:

• Identität des Benutzers oder Geräts, etwa Zertifikat, AD-Konto, Gerätegruppe oder registrierte MAC-Adresse
• Kontext des Zugriffs, etwa Switch-Port, SSID, Standort, Uhrzeit oder Gerätetyp
• Zustand des Endpunkts, etwa Patchlevel, EDR-Status, Verschlüsselung oder laufende Sicherheitsdienste

Genau hier liegt die Komplexität. Viele Umgebungen authentisieren zwar erfolgreich, treffen aber keine differenzierte Autorisierungsentscheidung. Dann landet fast jedes Gerät im gleichen VLAN, obwohl formal 802.1X aktiv ist. Das ist aus Verteidigungssicht schwach und aus Pentest-Sicht ein klassischer Befund: Authentisierung vorhanden, Segmentierung wirkungslos.

Ein weiterer kritischer Punkt ist die Reihenfolge von Methoden. Viele Switches sind so konfiguriert, dass zuerst 802.1X versucht wird und bei Fehlschlag automatisch MAB greift. Das ist grundsätzlich üblich, aber gefährlich, wenn MAB zu breite Rechte vergibt. Ein Angreifer kann dann bewusst ohne Supplicant auftreten oder den 802.1X-Prozess scheitern lassen, um in einen weniger streng kontrollierten MAB-Pfad zu fallen. Solche Fallbacks müssen restriktiv sein und idealerweise nur in isolierte Netze führen.

Auch RADIUS selbst ist ein kritischer Bestandteil. Shared Secrets, Quell-IP-Bindung, Redundanz, Logging und Zertifikatsmanagement sind keine Nebenthemen. Falsch gepflegte RADIUS-Clients, unvollständige Zertifikatsketten oder inkonsistente Policies zwischen Primär- und Sekundärservern führen zu schwer reproduzierbaren Fehlerbildern. Wer NAC produktiv betreibt, braucht deshalb dieselbe Sorgfalt wie bei Identity Security Authentication und Secure Configuration.

NAC entfaltet seinen Nutzen erst dann vollständig, wenn unterschiedliche Gerätetypen und Nutzungsszenarien sauber getrennt werden. Ein verwaltetes Firmen-Notebook mit Zertifikat, aktivem EDR und aktuellem Patchstand darf anders behandelt werden als ein privates Smartphone, ein Konferenzraum-Display oder eine IP-Kamera. Ohne diese Differenzierung bleibt das Netzwerk flach und lateral angreifbar.

Im klassischen Büro-LAN ist 802.1X auf Access-Ports der Standardansatz. Verwaltete Clients authentisieren sich per Zertifikat, erhalten ein produktives Benutzer- oder Geräteprofil und werden in passende Segmente eingeordnet. Unbekannte Systeme landen in einem Registrierungs- oder Quarantäne-Netz. Für Drucker und andere nicht supplicantfähige Geräte wird MAB genutzt, aber nur mit klar begrenzten Kommunikationspfaden. Diese Trennung muss mit Netzwerksicherheit Firewall und interner Filterung zusammenarbeiten, sonst bleibt sie kosmetisch.

Im WLAN ist NAC oft leichter durchsetzbar, weil zentrale Controller, SSIDs und Captive-Portale bereits vorhanden sind. Trotzdem entstehen auch dort Fehler. Häufig wird ein Gäste-WLAN sauber getrennt, während interne SSIDs zu breit freigeschaltet sind. Oder BYOD-Geräte erhalten nach einer simplen Web-Registrierung zu viele Rechte. Ein robustes Modell trennt mindestens verwaltete Unternehmensgeräte, Gäste, private Geräte und Spezialgeräte. Die Entscheidung sollte nicht nur an der SSID hängen, sondern an Identität und Gerätezustand.

IoT und OT sind die schwierigsten Bereiche. Viele Geräte unterstützen kein 802.1X, haben keine saubere Zertifikatsverwaltung und kommunizieren mit proprietären Protokollen. Genau deshalb ist NAC dort besonders wertvoll. Nicht als perfekte Authentisierung, sondern als Kontrollpunkt zur Klassifizierung und Isolation. Eine Kamera braucht keinen Zugriff auf Dateiserver, ein Badge-Reader keinen Zugang zu Office-Netzen und ein Laborgerät keine freie Ost-West-Kommunikation. In solchen Umgebungen ist NAC eng mit Netzwerksicherheit Monitoring und Netzwerksicherheit Ids verzahnt, weil Profilabweichungen schnell erkannt werden müssen.

Hybride Umgebungen bringen zusätzliche Komplexität. Ein Gerät kann im Büro per kabelgebundenem 802.1X, unterwegs per VPN und zu Hause über ein anderes Vertrauensmodell arbeiten. NAC ersetzt diese anderen Kontrollen nicht, sondern ergänzt sie. Wer ein Gerät im LAN streng prüft, darf dieselbe Identität nicht über Remote-Zugänge unkontrolliert behandeln. Konsistenz zwischen LAN, WLAN, VPN und Endpoint-Status ist entscheidend.

Ein praxistaugliches Einsatzmodell trennt mindestens folgende Klassen:

• verwaltete Unternehmensgeräte mit starker Authentisierung und produktivem Zugriff
• nicht verwaltete oder unbekannte Geräte mit Registrierung, Quarantäne oder stark eingeschränktem Zugang
• Spezialgeräte wie Drucker, VoIP, IoT oder OT mit minimalen, zweckgebundenen Kommunikationsrechten

Wer diese Klassen nicht sauber definiert, baut NAC auf Sand. Dann werden Ausnahmen zur Regel, Helpdesk-Tickets explodieren und Administratoren öffnen aus Zeitdruck immer größere Freigaben. Genau an dieser Stelle kippt ein eigentlich sinnvolles Sicherheitsprojekt in operative Unsicherheit.

Die meisten NAC-Probleme entstehen nicht durch fehlende Produkte, sondern durch falsche Annahmen. Ein typischer Fehler ist die Gleichsetzung von erfolgreicher Authentisierung mit sicherem Zugang. Wenn jedes authentisierte Gerät im gleichen produktiven VLAN landet, ist die Kontrolle schwach. Ein kompromittiertes Notebook kann sich dann trotz 802.1X seitlich bewegen. NAC ohne nachgelagerte Segmentierung ist nur eine halbe Maßnahme.

Sehr häufig sind auch zu großzügige Fallback-Regeln. Wenn ein Port bei 802.1X-Fehler automatisch in ein offenes VLAN fällt, ist die Schutzwirkung praktisch aufgehoben. Dasselbe gilt für MAB-Policies, die unbekannte MAC-Adressen in Netze mit DNS, DHCP, Proxy und breitem internen Routing lassen. Ein Angreifer braucht dann oft nur eine gefälschte MAC-Adresse oder ein Gerät ohne Supplicant, um einen verwertbaren Einstieg zu erhalten.

Ein weiterer Klassiker ist unvollständige Port-Abdeckung. Unternehmen aktivieren NAC auf den meisten Büroports, vergessen aber Besprechungsräume, Druckerbereiche, Lager, Produktionshallen, Testlabore oder temporäre Switches. Aus Angreifersicht sind genau diese Zonen interessant. Ein einzelner unkontrollierter Port reicht, um die gesamte Annahme von Zugangskontrolle zu unterlaufen.

Problematisch ist auch unsauberes Zertifikatsmanagement. Wenn Clients Serverzertifikate nicht korrekt validieren, können Benutzer gefälschte Authentisierungsserver akzeptieren. Das betrifft vor allem passwortbasierte EAP-Verfahren. In solchen Fällen wird aus NAC selbst ein Angriffsvektor für Credential Harvesting. Wer Zertifikate einsetzt, muss CA-Vertrauen, Ablaufdaten, Sperrlisten und automatische Erneuerung sauber betreiben. Das ist eng verwandt mit Verschluesselung Zertifikate und Verschluesselung Pki.

Auch Profiling wird oft überschätzt. Hersteller werben damit, Gerätetypen anhand von DHCP, LLDP, HTTP User-Agent oder anderen Merkmalen zu erkennen. Das ist nützlich, aber nicht vertrauenswürdig genug für weitreichende Freigaben. Profiling ist eine Hilfsfunktion, keine starke Identität. Wenn ein Gerät allein aufgrund eines erkannten Druckerprofils Zugriff auf Druckserver und Managementnetze erhält, ist Missbrauch naheliegend.

Weitere reale Schwächen sind fehlende Reauthentisierung, inkonsistente Policies zwischen Switch-Generationen, lokale Notfallkonten auf Netzwerkgeräten, ungeschützte Voice-VLANs und mangelnde Abstimmung mit Endpoint-Teams. Besonders kritisch wird es, wenn NAC-Entscheidungen nicht protokolliert oder nicht zentral ausgewertet werden. Dann bleibt unklar, warum ein Gerät Zugang erhielt, warum es umklassifiziert wurde oder warum ein Port in einen offenen Zustand fiel. Ohne belastbare Logs ist weder Betrieb noch Incident Response sauber möglich. Dafür sind Netzwerksicherheit Logauswertung und Security Monitoring Siem unverzichtbar.

Ein Pentest deckt solche Fehler oft schneller auf als interne Audits, weil nicht nur Konfigurationen gelesen, sondern reale Umgehungsversuche durchgeführt werden. Dazu gehören Tests mit unbekannten Geräten, MAC-Spoofing, Missbrauch von Voice-VLANs, Analyse von offenen Fallback-Netzen, Prüfung von Zertifikatsvalidierung und Bewertung der tatsächlichen Erreichbarkeit nach erfolgreicher oder fehlgeschlagener Authentisierung.

Aus Angreifersicht ist NAC kein unüberwindbares Hindernis, sondern ein System mit klaren Prüfpfaden, Fallbacks und Betriebsfehlern. Die erste Frage lautet immer: Ist der Port wirklich kontrolliert? Danach: Welche Methode wird verwendet? Gibt es MAB? Gibt es ein Voice-VLAN? Wie reagiert der Port bei Authentisierungsfehlern? Welche Netzdienste sind vor erfolgreicher Authentisierung erreichbar?

Ein klassischer Ansatz ist MAC-Spoofing gegen MAB-Umgebungen. Wenn bekannte Geräte-MACs aus passivem Mitschnitt, Inventarsystemen oder physischen Labels gewonnen werden können, lässt sich oft ein ähnliches Zugriffsprofil erreichen. Das ist kein theoretisches Problem, sondern in vielen Netzen praktisch möglich, wenn MAB-Geräte nicht zusätzlich über Port-Security, DHCP-Snooping, dynamische ACLs oder restriktive Segmente abgesichert sind.

Ein weiterer Angriffsweg ist der Missbrauch von Voice-VLANs. Manche Switch-Ports erlauben Telefonie-Geräten ein separates VLAN und lassen dahinter noch einen PC zu. Wenn die Erkennung zu großzügig ist oder LLDP/CDP-basierte Annahmen missbraucht werden können, entsteht ein alternativer Zugangspfad. In Assessments zeigt sich regelmäßig, dass Voice-Netze intern deutlich mehr erreichen dürfen als vorgesehen.

Passwortbasierte 802.1X-Methoden eröffnen zusätzliche Risiken. Wenn Clients das RADIUS-Serverzertifikat nicht strikt prüfen, kann ein Rogue-Authenticator oder Evil-Twin-Szenario Anmeldedaten abgreifen. Das ist besonders relevant im WLAN, aber auch im kabelgebundenen Umfeld mit manipulierten Access-Komponenten oder Testumgebungen. Solche Szenarien überschneiden sich mit Netzwerksicherheit Mitm und Netzwerksicherheit Spoofing.

Auch operative Fehler sind ausnutzbar. Wenn Helpdesk oder Netzwerkteam Ports manuell aufmachen, um Störungen schnell zu beheben, entstehen temporäre Ausnahmen, die oft dauerhaft bleiben. Wenn Quarantäne-Netze Zugriff auf interne Registrierungsdienste, Softwareverteilung oder Managementschnittstellen haben, lohnt sich die Prüfung, ob diese Systeme weitergehende Pivot-Möglichkeiten bieten. Ein Quarantäne-Netz ist nur dann sicher, wenn es wirklich minimal ist.

Typische Angreiferfragen in NAC-Tests sind:

• Lässt sich ein produktiver Zugang über MAB, Voice-VLAN oder offenen Fallback erreichen?
• Kann ein unbekanntes Gerät interne Dienste wie DNS, LDAP, Proxy, Update-Server oder Managementsysteme kontaktieren?
• Führen Fehlkonfigurationen bei Zertifikaten, Reauthentisierung oder Port-Rollen zu verwertbaren Seiteneffekten?

Wichtig ist dabei die realistische Bewertung. Nicht jede Umgehung bedeutet vollständigen Netzkompromiss. Aber jede Umgehung zeigt, dass die behauptete Kontrollwirkung geringer ist als angenommen. Genau deshalb sollte NAC immer zusammen mit Netzwerksicherheit Analyse, Netzwerksicherheit Angriffe und einer sauberen Segmentprüfung bewertet werden.

Ein NAC-Projekt scheitert selten an der Technik allein. Es scheitert an schlechten Workflows. Wer NAC ohne Inventar, ohne Geräteklassen, ohne Zertifikatsprozess und ohne abgestimmte Ausnahmebehandlung einführt, erzeugt Chaos. Der richtige Weg beginnt nicht mit flächendeckender Erzwingung, sondern mit Sichtbarkeit. Zuerst wird beobachtet, welche Geräte an welchen Ports erscheinen, welche Authentisierungsmethoden möglich sind und welche Altlasten im Netz existieren.

Danach folgt eine kontrollierte Einführungsphase. Typisch ist ein Monitor-Mode oder Low-Impact-Mode, in dem Authentisierungsereignisse gesammelt werden, ohne sofort hart zu blockieren. So lassen sich unbekannte Gerätetypen, fehlerhafte Supplicant-Konfigurationen und problematische Spezialsysteme identifizieren. Erst wenn diese Basis sauber ist, sollte Enforcement aktiviert werden. Dieser schrittweise Ansatz ist ein Kernpunkt von Best Practices und Netzwerksicherheit Best Practices.

Ausnahmebehandlung muss formalisiert sein. Ein Gerät ohne 802.1X-Unterstützung darf nicht einfach per Zuruf in ein produktives VLAN geschaltet werden. Es braucht einen dokumentierten Prozess: Eigentümer, Zweck, Kommunikationsbedarf, Laufzeit der Ausnahme, technische Kompensation und regelmäßige Überprüfung. Ohne diese Disziplin wird NAC innerhalb weniger Monate durch Sonderfälle ausgehöhlt.

Ebenso wichtig ist die Zusammenarbeit zwischen Netzwerk, Endpoint, Identity und Helpdesk. Wenn Zertifikate ablaufen, EDR-Agenten fehlschlagen oder Betriebssystemupdates den Supplicant beeinflussen, landet das Problem oft zuerst beim Benutzer. Der Support muss erkennen können, ob ein Gerät an der Authentisierung, an der Autorisierung oder an der Posture-Prüfung scheitert. Dafür reichen generische Fehlermeldungen nicht aus.

Ein sauberer Betriebsworkflow umfasst mindestens Inventarisierung, Policy-Pflege, Zertifikatslebenszyklus, Ausnahmeprozess, Monitoring, Incident-Handling und Rezertifizierung. Besonders wichtig ist die Rezertifizierung von MAB-Geräten. Drucker, Kameras und Spezialgeräte bleiben sonst jahrelang mit alten Freigaben im Netz, obwohl sie längst ersetzt oder umgezogen wurden.

Auch Fail-Open- und Fail-Close-Entscheidungen müssen bewusst getroffen werden. In hochkritischen Bereichen kann Fail-Close sinnvoll sein, in produktionsnahen Umgebungen kann ein unkontrollierter Ausfall aber größere Schäden verursachen als ein temporär offener Port. Diese Entscheidung ist kein rein technisches Detail, sondern Teil der Risikoabwägung zwischen Verfuegbarkeit und Zugangskontrolle. Wer das nicht vorab definiert, trifft die Entscheidung erst im Störfall unter Druck.

Viele NAC-Einführungen setzen große Hoffnungen auf Posture Checks. Die Idee ist attraktiv: Nur Geräte mit aktuellem Patchstand, aktivem Schutzagenten, eingeschalteter Festplattenverschlüsselung und konformer Konfiguration erhalten produktiven Zugang. In der Praxis ist das sinnvoll, aber nur dann, wenn die Prüfkriterien belastbar, aktuell und technisch sauber integrierbar sind.

Ein häufiger Fehler ist die Verwechslung von Signal und Sicherheit. Wenn ein Agent meldet, dass Antivirus aktiv ist, bedeutet das nicht automatisch, dass das System vertrauenswürdig ist. Ein kompromittiertes Gerät kann konform erscheinen. Ebenso kann ein legitimes Gerät wegen eines Agentenfehlers als nicht konform eingestuft werden. Posture ist daher ein Risikosignal, keine absolute Wahrheit.

Besonders problematisch wird es, wenn Posture-Prüfungen zu komplex werden. Dann hängen Netzfreigaben von vielen externen Systemen ab: MDM, EDR, Patch-Management, Verzeichnisdienst, Zertifikatsdienst, Compliance-Engine. Fällt eines dieser Systeme aus oder liefert inkonsistente Daten, blockiert plötzlich der Netzwerkzugang. Deshalb muss jede Posture-Policy auf ihre operative Robustheit geprüft werden. Wenige belastbare Kriterien sind oft besser als viele fragile.

In verwalteten Unternehmensumgebungen sind sinnvolle Kriterien etwa Gerätebesitz, gültiges Maschinenzertifikat, aktiver EDR, Mindest-Betriebssystemversion und Verschlüsselungsstatus. Bei BYOD oder Gastgeräten sind solche Prüfungen oft nur eingeschränkt möglich oder datenschutzrechtlich heikel. Dort ist Segmentierung meist wirksamer als tiefe Zustandsprüfung.

Aus Verteidigungssicht sollte Posture immer mit anderen Kontrollen kombiniert werden: restriktive Rollen, Mikrosegmentierung, Logging und Anomalieerkennung. Ein Gerät, das formal konform ist, aber plötzlich ungewöhnliche Verbindungen aufbaut, darf nicht allein wegen eines grünen Posture-Status als vertrauenswürdig gelten. Diese Kombination ist eng mit Endpoint Security Edr, Network Detection Response und Anomaly Detection verbunden.

Aus Pentest-Sicht lohnt sich die Frage, ob Posture nur beim Verbindungsaufbau geprüft wird oder kontinuierlich. Wenn ein Gerät nach erfolgreicher Authentisierung seinen Zustand verschlechtert, etwa durch Deaktivierung von Schutzkomponenten, muss klar sein, ob NAC reauthentisiert, umklassifiziert oder nur protokolliert. Viele Umgebungen prüfen nur initial und verlieren danach die Kontrolle. Das ist besonders kritisch bei langen Sessions und seltenen Reauthentisierungsintervallen.

NAC ohne sauberes Monitoring ist blind. Es reicht nicht zu wissen, dass Authentisierung grundsätzlich funktioniert. Entscheidend ist, welche Geräte wann wo erschienen sind, welche Methode verwendet wurde, welche Policy gegriffen hat, welche Attribute zurückgegeben wurden und ob es Abweichungen gab. Diese Daten sind nicht nur für den Betrieb wichtig, sondern auch für Forensik und Incident Response.

Ein gutes NAC-Logging beantwortet konkrete Fragen: Hat sich ein Gerät erstmals an einem ungewöhnlichen Standort verbunden? Wurde eine bekannte MAC-Adresse plötzlich an einem anderen Port gesehen? Scheitern Zertifikatsprüfungen gehäuft? Gibt es viele MAB-Fallbacks auf Ports, die eigentlich 802.1X-only sein sollten? Werden Quarantäne-Netze auffällig stark genutzt? Solche Muster sind operative Frühwarnsignale.

Die Protokolle sollten in ein zentrales Monitoring oder SIEM fließen und mit Switch-Logs, DHCP, DNS, Endpoint-Telemetrie und Verzeichnisereignissen korreliert werden. Erst dadurch entsteht ein verwertbares Lagebild. Wenn etwa ein Gerät per MAB in ein IoT-Segment eingeordnet wird, kurz darauf aber Verbindungen zu Domain Controllern oder Admin-Ports aufbaut, ist das ein klarer Alarm. Ohne Korrelation bleibt es oft unentdeckt.

Besonders wertvoll ist NAC in der Incident Response, wenn unklare Gerätebewegungen rekonstruiert werden müssen. Ein kompromittiertes Notebook, das an mehreren Standorten auftauchte, ein fremdes Gerät im Konferenzraum oder eine missbrauchte Drucker-MAC lassen sich über NAC-Daten zeitlich und räumlich besser einordnen. Diese Informationen ergänzen Forensik Netzwerk, Forensik Log Analyse und Defense Incident Response.

Wichtig ist außerdem die Qualität der Alarme. Zu viele generische Meldungen führen dazu, dass echte Abweichungen untergehen. Sinnvoll sind Use Cases wie neue MAC an sensiblem Port, wiederholte 802.1X-Fehlschläge mit anschließendem MAB-Erfolg, Gerätewechsel an fest zugeordneten Ports, ungewöhnliche Rollenwechsel oder Authentisierung außerhalb definierter Betriebszeiten. Solche Signale sind deutlich wertvoller als bloße Erfolgs- und Fehlerraten.

Auch Retention spielt eine Rolle. NAC-Daten werden oft zu kurz aufbewahrt, obwohl Vorfälle erst Wochen später auffallen. Wer historische Port-, Rollen- und Authentisierungsdaten nicht mehr hat, verliert wichtige Spuren. Gerade in größeren Umgebungen sollte NAC-Telemetrie als sicherheitsrelevante Datenquelle behandelt werden, nicht als bloßes Betriebslog.

Eine belastbare NAC-Bewertung besteht nicht aus einem Blick auf die Herstellerkonsole. Entscheidend ist die reale Wirkung an echten Ports und in echten Nutzungsszenarien. Deshalb beginnt ein Assessment mit Scope und Annahmen: Welche Porttypen existieren? Welche Authentisierungsmethoden sind vorgesehen? Welche Gerätetypen sind erlaubt? Welche Segmente sollen erreichbar sein? Welche Ausnahmen gibt es?

Danach folgt die technische Verifikation. An repräsentativen Ports werden unterschiedliche Gerätetypen getestet: verwalteter Client, unbekanntes Notebook, Gerät ohne Supplicant, Gerät mit manipulierten MAC-Adressen, gegebenenfalls VoIP-ähnliche Hardware oder Testadapter. Ziel ist nicht nur festzustellen, ob Zugang möglich ist, sondern welche Qualität dieser Zugang hat. Ein Quarantäne-Netz mit internem DNS, Proxy und breitem Routing ist aus Angreifersicht oft bereits ein brauchbarer Startpunkt.

Wichtig ist die Kombination aus Konfigurationssicht und Verhaltenstest. Switch-Konfigurationen, RADIUS-Policies, Zertifikatsprofile und Ausnahmeobjekte müssen mit dem tatsächlichen Verhalten übereinstimmen. In vielen Umgebungen zeigt die Policy etwas anderes als die Realität, weil Altregeln, lokale Overrides oder inkonsistente Firmwarestände dazwischenfunken.

Ein praxisnaher Prüfablauf umfasst typischerweise Portauswahl, Baseline-Messung, Authentisierungstests, Fallback-Analyse, Segmentprüfung, Erreichbarkeitstests, Log-Korrelation und Bewertung der Betriebsprozesse. Gerade die Prozessseite wird oft unterschätzt. Wenn Ausnahmen informell vergeben werden oder niemand erklären kann, warum ein Gerät eine bestimmte Rolle erhielt, ist das ein Sicherheitsproblem, auch wenn die Technik auf dem Papier korrekt aussieht.

Hilfreiche Werkzeuge sind Paketmitschnitt, Switch-Port-Debugging, RADIUS-Logs, Zertifikatsanalyse und gezielte Erreichbarkeitstests. Für die Netzsicht können Netzwerksicherheit Wireshark, Netzwerksicherheit Paketanalyse und Netzwerksicherheit Nmap sinnvoll sein, immer innerhalb des freigegebenen Prüfrahmens. Entscheidend ist nicht die Toolliste, sondern die Fähigkeit, Authentisierung, Autorisierung und tatsächliche Kommunikationsmöglichkeiten zusammenzuführen.

Ein guter Bericht trennt klar zwischen Designmängeln, Konfigurationsfehlern und Betriebsdefiziten. Ein Designmangel wäre etwa MAB für kritische Geräte ohne zusätzliche Isolation. Ein Konfigurationsfehler wäre ein offener Fallback-Port. Ein Betriebsdefizit wäre fehlende Rezertifizierung von Ausnahmen. Diese Trennung hilft, Maßnahmen realistisch zu priorisieren und nicht nur Symptome zu behandeln.

Beispielhafte Prüffragen:
1. Erhält ein unbekanntes Gerät überhaupt Layer-3-Konnektivität?
2. Greift bei 802.1X-Fehlern ein restriktiver oder ein produktiver Fallback?
3. Sind MAB-Geräte auf exakt definierte Ziele begrenzt?
4. Werden Rollenwechsel und Fehlversuche zentral protokolliert?
5. Ist die Segmentierung nach erfolgreicher Authentisierung tatsächlich wirksam?

Robustes NAC beginnt mit einem einfachen Grundsatz: starke Identität für verwaltete Geräte, minimale Rechte für alles andere. In der Praxis bedeutet das bevorzugt zertifikatsbasiertes 802.1X für Unternehmensgeräte, restriktives MAB nur für unvermeidbare Sonderfälle und konsequente Segmentierung hinter der Authentisierung. Wer diesen Grundsatz aufweicht, verliert die Sicherheitswirkung schnell.

Ebenso wichtig ist die vollständige Abdeckung. Ein teilweise geschütztes Netz ist aus Angreifersicht oft nur ein Netz mit klar markierten Umgehungspunkten. Deshalb müssen Access-Ports, Besprechungsräume, Lager, Außenstellen, Testbereiche und temporäre Installationen in dasselbe Kontrollmodell einbezogen werden. Ausnahmen dürfen sichtbar und zeitlich begrenzt sein.

Technisch sollten EAP-TLS, saubere PKI-Prozesse, strikte Serverzertifikatsprüfung, kurze und sinnvolle Reauthentisierungsintervalle, restriktive Quarantäne-Netze und zentrale Log-Korrelation zum Standard gehören. MAB-Geräte brauchen eine eigene Governance: Eigentümer, Zweck, Kommunikationsmatrix, Rezertifizierung und Monitoring auf Abweichungen. Gerade bei IoT und OT ist das entscheidend.

Auch die Verbindung zu anderen Sicherheitsdomänen muss stimmen. NAC ist kein Ersatz für interne Firewalls, keine Alternative zu Endpoint-Schutz und keine alleinige Antwort auf laterale Bewegung. Es ist eine Kontrollschicht innerhalb von Defense In Depth. Erst zusammen mit Endpoint Security Hardening, Netzwerksicherheit Schutz und Vulnerability Management entsteht ein belastbares Gesamtbild.

Besonders wirksam sind folgende Maßnahmen in Kombination: starke Geräteidentität, rollenbasierte Autorisierung, Mikrosegmentierung, restriktive Fallbacks, kontinuierliches Monitoring und regelmäßige technische Überprüfung. Unternehmen, die NAC einmal einführen und dann jahrelang nicht mehr hinterfragen, verlieren schleichend die Kontrolle. Neue Gerätetypen, neue Standorte, neue Helpdesk-Ausnahmen und geänderte Geschäftsprozesse verändern die Realität schneller als die ursprüngliche Policy.

Wer NAC ernsthaft betreibt, behandelt es deshalb wie ein lebendes System: mit klaren Verantwortlichkeiten, messbaren Kontrollen, regelmäßigen Reviews und realistischen Tests. Dann wird aus einer oft unbeliebten Zugangshürde eine wirksame Sicherheitsinstanz, die unautorisierte Geräte bremst, Schatten-IT sichtbar macht und laterale Bewegung deutlich erschwert.