Network Access Control (NAC) autorisiert ein Endgerät und gewährt durch Policies Zugriff auf Ressourcen - auf der Basis der Authentisierung der Identität des Benutzers und/oder des Geräts. Zum Tragen kommen hier auch die Konfiguration des Geräts im Hinblick auf sicherheitsrelevante Parameter (die Compliance mit den entsprechenden Vorgaben) sowie weitere Parameter wie Ort und Zeitpunkt des Anschlusses an die Infrastruktur. Zur Umsetzung gibt es mehrere Ansätze, die es bei einer NAC-Einführung zu erwägen gilt.
Der Ermittlung der Network-Access-relevanten Parameter dient ein so genanntes Pre-Connect
Assessment, also eine Untersuchung vor den Anschluss des Geräts an die Infrastruktur. Zudem sollte
später eine Überprüfung im laufenden Betrieb (ein Post-Connect Assessment) erfolgen. Ein Prozess
zur Wiederherstellung der Compliance, also zu so genannten Remediation, muss technisch und auch
organisatorisch ein fester Bestandteil eines NAC-Projekts sein.
Diese Möglichkeiten erzeugen ein breites Feld von Anwendungen für diese Technik. Daher muss sich
der Anwender im Klaren sein, welche Ziele er mit der Einführung von NAC erreichen will. Dies wird
auch relevant, wenn es um die Auswahl einer NAC-Lösung geht: Hier unterscheiden sich die Hersteller
nämlich erheblich. Diese Unterschiede sollen im Folgenden näher erläutert werden.
Viele Anwender wollen zunächst einmal nur wissen, wer und was überhaupt an ihrer Infrastruktur
angeschlossen ist. Die Geräteerkennung und -verfolgung (Asset Discovery, Tracking) sind Funktionen,
die einige NAC-Lösungen automatisch mitliefern – hier besteht in der Detailtiefe und den
Möglichkeiten, auf diese Daten zuzugreifen, ein großer Unterschied zwischen den Anbietern.
Typischerweise sind diese Funktionen auch notwendig, um abschätzen zu können, was passiert, wenn
man eine NAC-Lösung "scharf" schaltet. Darauf aufbauend nutzen Unternehmen oft eine Trennung von
Gästen (Consultants, Entwicklungspartnern etc.) und eigenen Mitarbeitern mit hausintern gemanagten
Desktops und Laptops sowie weiteren Geräten wie VoIP-Telefonen (Voice over IP), Überwachungskameras
und sonstigen Facility-Managementgeräten.
Ein weiterer Anwendungsbereich ist die Überprüfung der Endgeräte-Compliance. Die Technik zur
Überprüfung (Pre-Connect Assessment) war in der Vergangenheit im Fokus der Standardisierung und
auch des Wettbewerbs auf der Marketing-Seite – so zum Beispiel bei der Auseinandersetzung
Microsofts mit der Trusted Computing Group (TCG). Da Microsoft TCG-Unterstützung angekündigt hat,
fährt NAC hier auf ruhigeres Fahrwasser zu. Jedoch sind viele Softwarehersteller dabei, auch eigene
Lösungen am Markt zu platzieren.
Um Lösungsanbieter besser vergleichen zu können, ist nach der Definition der eigenen Ziele und
Prioritäten eine Analyse der NAC-Funkti-onen bei den Anbietern sinnvoll. Man kann folgende grobe
Einteilung vornehmen (Bild 1):
Detect: Wie verlässlich erkennt die Lösung neue Endgeräte im Netz und an
welchem Punkt in der Infrastruktur (je näher am Access, desto besser)?
Authenticate: Wie erfolgt eine Authentifizierung? Welche Methoden sind
verfügbar und sind bei den vorhandenen Gerätetypen und Nutzergruppen sinnvoll einzusetzen?
Assess: Auf welche Art und Weise überprüft die Lösung die Geräte? Sind diese
Methoden skalierbar und für die vorhande Endgeräteinfrastruktur geeignet?
Authorize and Enforce: Wie granular und wo erfolgt das Policy Enforcement
(Durchsetzung der Richtlinien)? Wie leicht lässt sich dieses umgehen?
Remediate: Welche Optionen zur Remediation gibt es? Ist automatische
Remediation möglich? Welche Kommunikationsmöglichkeiten mit dem Nutzer bietet die Lösung?
Monitor and Contain: Welche Möglichkeiten zur fortlaufenden Überprüfung der
Endgeräte und des Endgeräteverhaltens bietet die Lösung (Post-Connect Assessment)? Gibt es die
Möglichkeit, auf dieser Basis wiederum eine Änderungen der Policy und einen Remediation-Prozess
einzuleiten?
Üblicherweise wird der Punkt "Detection" durch das Erkennen einer neuer MAC- oder IP-Adresse
realisiert, bei VPN-Geräten durch den Aufbau eines Tunnels, bei DHCP-basierten Systemen (Dynamic
Host Configuration Protocol) durch einen DHCP-Request eines neuen Endgeräts. Danach erfolgt bei den
meisten Lösungen die Authentifizierung.
Hier ist, wie im nächsten Schritt, dem Assessment, hohe Flexibilität gefragt: Die
Diversifikation der Endgeräte nimmt durch die Konvergenzprojekte zu IP als Protokoll für jeglichen
Datenaustausch immer stärker zu. Damit ist die IT-Abteilung gefordert, auch die passenden Verfahren
für die jeweiligen Gerätetypen und Nutzerklassen zu unterstützen.
Ein automatisches Anbieten aller Optionen ist mehr als sinnvoll, damit keinerlei zusätzliche
Konfigurationsarbeiten bei Umzügen etc. auftreten. Falls ein Endgerät sich mehrfach authentifiziert
(zum Beispiel zuerst via MAC-Adresse, dann via 802.1X), dann muss ein internes Precedence-Verfahren
vorhanden sein, das die richtige Konfiguration (Autorisierung und Assessment) anwendet.
Will ein Unternehmen eine Authentifizierung einführen, stellt sich zunächst die Frage nach der
Art und Weise des Verfahrens. Hier ist man stark vom verwendeten Endsystem abhängig:
802.1X ist die präferierte Lösung für eigene PCs und Laptops, in Zukunft
teilweise auch für IP Phones,
MAC-Adresse für Drucker, IP Phones und andere Maschinen am Netz
(Sicherheitskameras, Produktionssteuerungen, Sensoren etc.),
Webportal zur Registrierung in verschiedenen Varianten (einfach, mit Passwort,
mit Sponsor) für Gäste, Consultants, Servicetechniker etc. sowie
Default-Eigenschaften zum Beispiel für TFTP/Bootp, damit Diskless-Stationen
booten.
Neue Authentifizierungsoptionen wie Kerberos Snooping kommen hinzu, um eine schnelle
NAC-Projektumsetzung zu realisieren, ohne auf den Rollout von 802.1X warten zu müssen und doch
dorthin migrieren zu können. Die danach anwendete Policy/Autorisierung muss dann natürlich pro
Endgerät und pro Port gelten – bei Switches zumindest zwei Geräte wie VoIP Phone und PC, besser
vier bis acht (für Mini-Switch, Unterstützung von Fiber to the Office sowie für
Virtual-Machine-Lösungen). Bei Appliances geht es teilweise um Hunderte bis Tausende von Geräten
pro Port. Dies trifft dann zu, wenn WLAN-Switches oder VPN-Gateways mit NAC-Inline-Appliances
erweitert werden.
Ein weiteres Augenmerk sollte auf die Art der Policies gelegt werden – einfache VLAN-Policies
erlauben keine echte Kontrolle: Was passiert, wenn jemand einen unautorisierten DHCP-Server an das
VLAN anschließt und sich mit passenden Credentials anmeldet? Wie unterscheidet man bei einem
Softphone zwischen VoIP und Daten? Wie ist eine Wurmausbreitung innerhalb eines VLANs zu stoppen?
Die Antwort liegt in Policies, die neben VLAN-Zuweisung auch Access-Listen und Rate Limiting/Class
of Service bis auf Layer 4 umsetzen und innerhalb eines VLANs greifen.
Man kann hier generell agentenbasierte und agentenlose Assessment-Optionen unterscheiden.
Innerhalb der Optionen wiederum ist eine Unterteilung wie folgt möglich:
Agentenbasiert – permanenter Agent, der meist noch weitere Funktionen
realisieren kann. Hier findet man Microsoft NAP (Network Access Protection) und die TNC-Lösung
(Trusted Network Connect) der TCG, aber auch viele andere, die aus Personal-Firewall-,
Host-Intrusion-Prevention- und Antivirenprodukten hervorgegangen sind.
Agentenbasiert – temporärer (Dissolving) Agent, der entweder als Applet
geladen wird oder sich bis zum nächsten Reboot als Programm installiert.
Agentenlos – durch einen Vulnerability-Assessment-(VA-)Scanner. Hier gibt es
eine Reihe von Produkten auf dem Markt. Die NAC-Lösung sollte verschiedene VA-Scanner integrieren
können.
Agentenlos – durch vorhandene Interfaces wie Windows Management
Instrumentation (WMI) und andere Schnittstellen, die auch von VA-Scannern genutzt werden.
Agentenlos – im Post-Connect-Bereich mit der Möglichkeit, das Verhalten des
Endsystems via Intrusion-Detection-Techniken auf der Basis von Signaturen und Anomalien des von
einem Endgerät ausgehenden Verkehrs zu überwachen.
Je nach Gerätetyp wird man sicherlich mit unterschiedlichen Assessment-Optionen arbeiten
müssen.
Das Enforcement kann auf verschiedene Weisen und an unterschiedlichsten Punkten in der
Infrastruktur erfolgen. Neben dem Assessment-Verfahren bietet es eine zweite zentrale
Herausforderung bei der Auswahl der NAC-Lösung. Konzeptionell sitzt der Policy-Enforcement-Punkt
zwischen dem Endgerät und den zu schützenden Ressourcen. Je näher er am Endgerät liegt, desto
größer ist der Schutz für die Ressourcen und desto kleiner die Auswirkungen bei Problemen wie
Wurmausbreitungen, Denial-of-Service-Angriffen etc.
Für den Policy Enforcement Point stehen mehrere Optionen zur Verfügung. Bei der DHCP-basierten
Variante ist die Steuerung für den Zugang durch eine selektive Vergabe von IP-Adressen durch den
DHCP-Server realisiert: Dieser vergibt je nach Assessment und Authenfizierungsergebnis eine andere
IP-Adresse.
Dieser Ansatz ist einfach zu implementieren, aber er arbeitet mit einer statischen, selbst
vergebenen Adresse und bietet damit keine echte Zugangskontrolle. Er ist vielmehr eine
Managementerweiterung als eine Sicherheitslösung.
Die zweite Variante funktioniert auf IPSec-Basis. Insbesondere Microsofts NAP-Lösung bietet dies
neben einer 802.1X-basierten Implementierung als Option an. Für den Remote-Access-Bereich ist dies
sinnvoll – der Enforcement Point ist dann das VPN-Gateway, jedoch wird teilweise auch die Nutzung
im LAN mittels IPSec-Policies auf den Endgeräten diskutiert oder empfohlen. Dies funktioniert
offensichtlich nur in einer reine Microsoft-Umgebung. Da die Vielfalt der Endgeräte immer mehr
zunimmt, kann das nur eine punktuelle Lösung sein.
Die optimale Lösung für NAC im LAN ist die Implementierung von Access-Switches, die eine
entsprechende Authentifizierung via 802.1X und eine Zuordnung von Policies unterstützen
(Switch-basierter Ansatz oder "True Out-of-Band Appliance"). Insbesondere in einer heterogenen
Umgebung mit Nicht-802.1X-Endgeräten und mehreren Geräten pro Switch-Port sind hier mehrere der
oben beschriebenen Authentifizierungsoptionen notwendig. Dies gilt auch für Migrationen und ist bei
der Verwendung von FTTO ein entscheidender Faktor. Meist kommt eine zusätzliche
Out-of-Band-Appliance hinzu. Sie versorgt als intelligenter Radius-Proxy die Switches mit
Policy-Zuweisungen für das jeweilige Endgerät, übernimmt Assessment-Aufgaben oder leitet Anfragen
für Authentifizierung und Assessment entsprechend um und sorgt für die finale Entscheidung zur
Autorisierung des Endgeräts. Richtig implementiert, findet sich hier dann eine komplette
Inventardatenbank der Endgeräte im Netzwerk inklusive Historie von Endgerätesstatus/-konfiguration
und des Orts/Zeitpunkts des Anschlusses an das Netz.
Um eine NAC Lösung schneller zu implementieren und dennoch ein hohes Maß an Sicherheit zu
erreichen, legen Unternehmen heute das Augenmerk verstärkt auf einen Appliance-basierten Ansatz.
Die Appliances stellen dabei oft eine Übergangslösung zu einer Switch-basierten NAC-Lösung dar. Die
Access-Switches lassen sich zunächst weiter nutzen, auch wenn sie Authentifizierung und
Policy-Verfahren nicht oder nur rudimentär unterstützen. In sehr heterogenen Umgebungen mit relativ
alten Switches ist dies eine sehr gute Option. Bei der Auswahl des Lösungsanbieters sollte das
Projektteam analysieren, inwieweit der Anbieter ohne Aufwand auf eine Switch-basierte Lösung
migrieren kann.
Zum Einsatz kommen In-Band- oder Out-of-Band-Appliances. Optimalerweise auf ASICs aufsetzend,
sind In-Band-Appliances eine Erweiterung einer Switch-basierten Lösung mit der Unterstützung von
mehreren hundert bis mehreren tausend Geräten pro Port, die mit unterschiedlichsten
Authentifizierungsverfahren und Policies arbeitet.
Eine Implementierung im Distribution Layer eines Netzwerkdesigns ist der optimale Ort für eine
In-Band-Appliance, die auch hinter einem WLAN-Switch oder VPN-Konzentrator installiert werden kann.
Die Appliance lässt sich oft aber auch schon transparent als Aggregationspunkt einsetzen.
Oft kommen hier als Erweiterung der Authentifizierungsmethoden eines Access-Switches Techniken
wie Kerberos, Reverse DNS Look-ups und Radius Snooping zum Einsatz, um eine NAC-Lösung schneller
und effizienter umzusetzen. Typische In-Band-Appliances unterstützen zwischen 1000 und 2000
Endgeräten.
Im Gegensatz zu den In-Band-Appliances stehen die Out-of-Band-Appliances für den normalen
Verkehr nicht im Datenpfad – jedoch bei der Authentifizierung, im Assessment-Prozess und auch im
Quarantänefall. Damit sind sie allerdings auch leichter angreifbar.
Dieser Ansatz erscheint zunächst sehr attraktiv, er hat aber auch seine Tücken – insbesondere
bei der Erkennung neuer Endsysteme, der Rekonfiguration der Access-Switches im Assessment- und
Quarantänefall sowie bezüglich der Granularität bei Assessment und Quarantäne.
Manche Anbieter fokussieren ausschließlich auf das Post-Connect Assessment und arbeiten dann mit
Maßnahmen wie Arp Cache Poisoning gegen unautorisierte Endsysteme, was bei eingeschalteten Personal
Firewalls meist nicht funktioniert. Die Erkennung erfolgt oft durch SNMP Traps für neue MACs oder
durch das regelmäßige Polling von Source-Address-Tabellen oder Router-ARP-Caches in den
Netzkomponenten.
Die Quarantänefunktion und die initiale Isolierung neuer Geräte am Netz geht oft mit massiven
VLAN-Konfigurationsänderungen am Access-Switch einher. Und auch die Unterscheidung der Policies von
PCs und VoIP-Telefonen am gleichen Port ist oft schwierig oder gar unmöglich.
Ein Enforcement durch den Agent auf dem Gerät des Nutzers bietet sehr präzise Möglichkeiten zur
Steuerung im Quarantänefall. Es gibt heute schon eine Reihe von Herstellern aus den Segmenten
Personal Firewall und Host Intrusion Prevention, die sich seit längerem dieser Thematik widmen.
Diese Lösungen sind oft mit netzwerkbasierten Lösungen (Switch/Appliance) kombinierbar. Der
Nachteil ist, dass der Agent erst einmal zu installieren ist (sofern technisch und organisatorisch
überhaupt möglich), dann zu warten und zu betreiben ist. Falls der Agent kompromittiert wurde, ist
die Sicherheit durch das Enforcement ebenfalls dahin.
Ein weiterer Faktor bei der NAC-Lösungsauswahl sollte die Offenheit eines Anbieters für die
Integration anderer Security-Anbieter zum Beispiel für das Endgeräte-Assessment sein, außerdem die
Möglichkeit, von einer punktuellen auf eine infrastrukturweite Lösung zu migrieren, die oft das
Ziel eines Unternehmens ist.
Vor einer NAC-Einführung muss ein Unternehmen zunächst ermitteln, welche Ziele es damit
verfolgt. Dies erfordert eine enge Verzahnung der Server-, Desktop-, Netzwerk- und der
Security-Abteilung, gegebenenfalls unter Einbezug der Corporate Governance. Erst wenn dies geklärt
ist, sollte man sich an die theoretische und dann auch an die praktische Evaluierung der Systeme
wagen. Dies sollte in die Entwicklung eines Betriebsmodells münden, die alle auftretenden
Ereignisse erfasst und auf einem Workflow beruht. Erst dann steht der erfolgreichen NAC-Einführung
nichts mehr im Wege.