SPAN oder nicht SPAN – das ist hier die Frage

Seit sich Network Acces Control (NAC) von einem "nice to have"-Feature zu einem echten Gewinn für große und kleine Netzwerke entwickelt hat, wird immer öfter die Frage gestellt: "Wie schwer ist es, NAC einzuführen?” Die Antwort ist einfach – es kommt ganz darauf an was man mit NAC erreichen möchte. [...]

Wie bei den meisten Netzwerk-zentralisierten Lösungen führen viele Wege nach Rom. Dabei ist es gleich, ob es darum geht, den Datenstrom zu überwachen, TRAPS aus der Netzwerkinfrastruktur zu nutzen – oder eine Kombination aus beidem. Entscheidend für die Art der Implementierung ist immer das übergeordnete Ziel. Das Hauptaugenmerk liegt bei allen NAC-Lösungen auf dem Aspekt der Transparenz. Die Wahrheit bleibt immer gleich – etwas das nicht sichtbar ist, kann auch nicht kontrolliert werden. Unweigerlich folgt hierauf die Frage: Wie erreicht man eine Transparenz mit der kontrolliert werden kann, wie diese Geräte einen ordnungsgemäßen Zugang zum Netzwerk erlangen?

Hierfür gibt es mehrere Möglichkeiten: einerseits via SPAN- (oder Spiegel)-Ports und/oder andererseits via SNMP-Traps. Beide Ansätze funktionieren gut, haben jedoch ihre jeweiligen Vor- und Nachteile. Welchen man schlussendlich wählt, hängt davon ab, was man mit seiner NAC-Lösung genau erreichen möchte. Beide Lösungen sind out-of-band. Diese Tatsache ist entscheidend für die reibungslose Bereitstellung einer NAC-Plattform, damit diese nicht zum Flaschenhals oder zur alleinigen Fehlerquelle wird, man aber trotzdem Entscheidungen direkt am Zugangsknoten (Point of Access) treffen kann. Außerdem erfordert eine out-of-band Option keine Neukonfiguration des Netzwerks.

Bevor man hier tiefer in die Materie einsteigt, ist es wichtig sich zu vergegenwärtigen, dass viele NAC-Architekturen auf den Informationen beruhen, die sie vom Netzwerk erhalten. Durch das Lesen der CAM- und ARP-Tabellen werden Informationen empfangen, überprüft und deren Genauigkeit verifiziert. Diese Aktualisierungen werden jedoch nicht in Echtzeit vorgenommen, sondern erfolgen in vorbestimmten Intervallen. Setzt man die Intervallzeit zu hoch an, können Verzögerungen auftreten bevor ein Gerät Zugriff erhält. Wird sie dagegen zu niedrig angesetzt, kann das Netzwerk durch zu viel unnötigen Traffic sehr voll und unüberschaubar werden.

SPIEGLEIN, SPIEGLEIN … IM NETZ
Mit Hilfe eines SPAN- (oder Spiegel)-Ports an einem strategisch guten Netzwerkpunkt (zum Beispiel dem Network-Core) ist es möglich, alle Geräte die an das Netzwerk angeschlossen sind in Echtzeit zu sehen. Es können auch sofort zusätzliche Informationen aufgerufen werden, wie etwa das Betriebssystem, offene Ports usw. Wenn der Port in einen Authentifizierungs-Server integriert ist, werden die User-Informationen ebenfalls bestückt. Dieser Aufbau ermöglicht ein Maß an Transparenz, für das sich die meisten IT-Manager sehr glücklich schätzen würden. Der Einsatz eines SPAN-Ports kann der IT auch ermöglichen, noch einige zusätzliche Funktionen zu nutzen, wie zum Beispiel Threat Management oder eine Virtual Firewall.

Die perfekte Lösung gibt es allerdings nicht. Viele Switches sind begrenzt in der Anzahl der Ports, die als SPAN konfiguriert werden können. Dieses Problem kann durch den Einsatz eines TAP (einer Monitoring-Appliance) gelöst werden, da es mehr Switches unterbringen kann um Informationen direkt in die NAC-Appliance zu liefern. Ist das Netzwerk geographisch verteilt, gilt es bei der ausschließlichen Verwendung von SPAN-Ports noch eine weitere Herausforderung zu meistern – an jedem Standort ist ein Gerät erforderlich, damit alle Funktionen voll genutzt werden können. Eine denkbare Lösung wäre der Kauf von verschiedenen Geräten unterschiedlicher Größe, angepasst auf die jeweiligen Bedürfnisse, kombiniert mit einer Management-Appliance, die für gewöhnlich in der Unternehmenszentrale installiert wird. So werden zentralisierte Konfiguration und Management ermöglicht, zusammen mit einem einheitlichen, transparenten Überblick aus der Vogelperspektive über das gesamte Netzwerk.