Netzzugangskontrolle: Mission Impossible oder notwendiges Übel?

Kommentieren Drucken

Das Sicherheitsniveau des Intranet ist in vielen Fällen durch den Anschluss einer nicht mehr überschaubaren heterogenen Endgerätelandschaft und durch unterschiedlichste Vertraulichkeitsstufen der Nutzer (interne Mitarbeiter, Fremdfirmen, Besucher und Gäste) erheblich gesunken. Es gibt durchaus Unternehmen, die inzwischen das Intranet als unsicheres Netz auf demselben Niveau wie das Internet klassifizieren. Bring Your Own Device (BYOD) leistet hierzu natürlich außerdem einen entsprechend erheblichen Beitrag.

Eine typische Maßnahme der Informationssicherheit ist in vielen Fällen der Aufbau einer Netzzugangskontrolle (Network Access Control, NAC), die Spreu von Weizen trennen und den verschiedenen Gruppen (Mandanten) einen authentisierungsabhängigen und ggf. eingeschränkten Netzzugang bereitstellen soll. Die eingesetzten Techniken sind hierzu meist eine port-basierte Zugangskontrolle auf den Access Switches unter Verwendung des Standards IEEE 802.1X in Kombination mit MAC-Adress-Authentisierung und Browser-basierter Authentisierung über ein Captive Portal. Es werden aber genauso proprietäre NAC-Appliances eingesetzt.

Was im WLAN seit Jahren bewährt und erfolgreich ist, kann allerdings im kabelbasierten LAN schnell zum Alptraum werden. Die Gründe liegen primär in „ungeschickten“ Freiheitsgraden und Problembereichen von IEEE 802.1X in der Fassung von 2004 (welche derzeit noch am häufigsten verwendet wird), was insbesondere bei Switches zu sehr unterschiedlichen Realisierungen der Hersteller geführt hat. Außerdem ist die Implementierung von IEEE 802.1X und darauf aufbauender Authentisierungsmethoden, wie z.B. zertifikatsbasierte Authentisierung, gerade für Spezialgeräte, z.B. Thin Clients, Drucker und Desktop IP-Telefone
– sofern überhaupt verfügbar – leider nicht selten nur von unzureichendem Leistungsumfang oder schlechter Qualität.

Ein tragfähiges NAC-Konzept muss nicht nur mit vielen Spezialfällen geeignet umgehen, sondern NAC auch in diversen IT-Prozessen, wie z.B. Beschaffung (von Endgeräten und Switches), Configuration Management, Change Management und Incident Management verankern. Es darf nicht unterschätzt werden, dass NAC in Planung, Implementierung und Betrieb eine Herkulesaufgabe sein kann.

Eine typische Betriebsaufgabe ist der Umgang mit Nutzern, denen ein Netzzugang verwehrt wird (z.B. bedingt durch ein abgelaufenes Zertifikat) und die sich nun beim User Helpdesk (UHD) melden. Hier ist es entscheidend, dass der UHD schnell das Fehlerbild einordnen und entsprechend handeln kann. Ein NAC-Managementsystem, das für den UHD die aktuelle Authentisierungslage aufbereitet und z.B. per Mouse-Click einem Nutzer, der wie eben beschrieben ein NAC-Problem hat, einen temporären Zugang gewähren kann (damit in Ruhe nach dem Fehler gesucht werden kann, ohne die Arbeitsfähigkeit des Nutzers einzuschränken), hat auf dem Markt allerdings immer noch Seltenheitswert.

Eine weitere Maßnahme gegen ein unsicheres Intranet ist der Schutz kritischer zentraler Ressourcen (Rechenzentrum) vor unberechtigten oder schadenstiftenden Zugriffen aus dem Intranet. Dabei werden üblicherweise dieselben Sicherheitsmechanismen, die aus dem Perimeterbereich bekannt sind, eingesetzt. Neben dieser netzbasierten Trennung der zentralen Ressourcen von den Clients wird verstärkt über Server-based Computing ggf. in Verbindung mit einer Virtual Desktop Infrastructure (VDI), die zentral Clients als VMs bereitstellt, nachgedacht. Was letztendlich bleibt sind Thin Clients bzw. Clients, die eigentlich nur noch einen Browser benötigen, um zentrale Dienste zu nutzen. Cloud Computing verstärkt diesen Trend.

Hier könnte man sofort berechtigterweise insistieren und NAC in Frage stellen, wenn die zentralen Ressourcen sowieso mit Firewalls und Co. geschützt werden. Wenn beispielsweise ausschließlich ein Zugriff per Thin Client, d.h. über ICA oder RDP, auf einen zentralen Terminal Server bzw. eine zentrale VDI erfolgen würden, ist NAC auf Ebene des Campus-Netzes doch eigentlich nicht mehr erforderlich.

So schön sich das Argument anhört, so fragwürdig ist es leider in vielen Fällen: Was ist mit verbleidenden eigenen Fat Clients, Netzwerkdruckern (speziell Multifunktionsdruckern), IP-Telefonen und anderen Geräten? Wenn diese Geräte vor einem schadenstiftenden Zugriff durch ein Fremdgerät auf Ebene des Campus-Netzes geschützt werden sollen, sind wir wieder am Anfang der Überlegungen.

Ob wir es wollen oder nicht, wir werden auch längerfristig das Thema NAC nicht los. Stellen wir uns also besser darauf ein…

zugeordnete Kategorien: IT-Sicherheit, LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.