Der Rundumschlag: Pauschale Verschlüsselung in WAN/MAN/LAN

Kommentieren Drucken

Wenn Daten mit hohem (oder sogar sehr hohem) Schutzbedarf hinsichtlich Vertraulichkeit bzw. Integrität in Netzen übertragen werden sollen, hat die Informationssicherheit schon immer zunächst unterschieden, ob es sich hier um ein Netz in einem vertrauenswürdigen Bereich handelt oder nicht. Im letzteren Fall fordert die Informationssicherheit unabhängig vom Typ des Netzes reflexartig fast immer den Einsatz von Verschlüsselung.

Als Konsequenz sind bei entsprechendem Schutzbedarf Daten zu verschlüsseln, sobald sie z.B. das geschützte LAN und das Rechenzentrum einer Unternehmung verlassen. Dies gilt dann nicht nur im WAN (z.B. MPLS), sondern sogar auch bei der Verbindung zwischen Standorten / Rechenzentren per Dark Fiber bzw. Dense Wavelength Division Multiplexing (DWDM). Hier genügt bereits die Machbarkeit eines Lauschangriffs, auch wenn er bei DWDM mit erheblichem Aufwand verbunden ist(Fußnote 1).

Sofern nur eine Hub-and-Spoke-Kommunikation vorliegt, kann man sich im klass-ischen WAN noch mit einem eigenbetriebenen IPsec VPN oder mit proprietären Kryptoboxen behelfen. Spätestens bei VoIP und UC wäre aber oft ein vollvermaschtes VPN notwendig, was für IPsec eine quadratische Komplexität für den Aufbau der Security Associations oder den Einsatz trickreicher Mechanismen (z.B. Gruppenschlüssel gemäß RFC3547) nach sich zieht. Hier springen gerade bei MPLS die Provider ein und bieten oft die Möglichkeit eines verschlüsselten MPLS-VPN als (natürlich teurere) Dienstleistung an. Sofern man als Kunde hier nicht die Kontrolle über das Schlüsselmaterial hat, muss man dabei natürlich dem Provider trauen.

Ist eine Glasfaserstrecke zu verschlüsseln, kommen IPsec-basierte VPNs schnell an die Grenzen ihrer Leistungsfähigkeit und bei einer Verbindung zwischen Rechenzentren sind neben einer Verschlüsselungsleistung von mehr als 10 Gbit/s auch Layer-2-Verbindungen zu unterstützen. Hierzu gibt es mit IEEE 802.1AE MACsec (z.B. im Cisco Nexus 7000) und mit Layer-2-Kryptoboxen zwar Lösungen, die leistungsfähig genug sind, sich auch für Carrier-Ethernet eignen, jedoch auch entsprechend teuer sind.

Die IT könnte bei diesen aufwendigen Techniken geneigt sein, den „schwarzen Peter“ vom Netz zu denjenigen Anwendungen zu schieben, die den hohen Schutzbedarf auch mitbringen. Falls im WAN – zumindest für alle kritischen Anwendungen – konsequent mit per HTTPS geschützten Web Applikationen oder mit anderen durch eine Verschlüsselung zusätzlich abgesicherten Techniken des Server-based Computing (Terminal Server, Virtual Desktop Infrastructure, VDI) gearbeitet würde, mag dies auch gelingen. Die Praxis sieht jedoch meist anders aus und die Folge wäre dann höchstwahrscheinlich ein Zoo von verschiedensten, heterogenen Lösungen, der in Summe nicht nur bei den Investitionen, sondern insbesondere im Betrieb einen nicht mehr überschaubaren Aufwand verursacht.

Also bleibt es doch beim Netz und der Forderung hier bei entsprechendem Schutzbedarf zu verschlüsseln. Um die ewige Diskussion der Schutzbedarfsfeststellung zu beenden, gibt es nicht wenige IT-Abteilungen, die sogar über eine pauschale Verschlüsselung aller Daten zumindest im WAN nachdenken.

Interessanterweise werden ähnliche Anforderungen auch an die Absicherung der Kommunikation im LAN gestellt. Dies hat durchaus damit zu tun, dass die Arbeitsannahme, dass ein LAN eine geschützte, vertrauenswürdige Umgebung sei, immer häufiger in Frage zu stellen ist. Unterschiedlichste Nutzer- und Gerätegruppen auf allen denkbaren Sicherheitsniveaus teilen sich hier eine gemeinsame LAN-Infrastruktur. In dieser Situation sind die Forderungen nach einer Netzzugangskontrolle und dem Aufbau einer mandantenfähigen LAN-Infrastruktur schnell gestellt. LANs, deren Netzzugang mit IEEE 802.1X abgesichert wird, sind tatsächlich immer häufiger anzutreffen und auch der Einsatz von Virtual Routing and Forwarding (VRF) zur Trennung der Gruppen (Mandanten) ist in der Praxis zu finden. Der Aufwand für den Betrieb solcher Lösungen ist jedoch meist erheblich, und VRF bzw. VLAN müssen außerdem mit der Vorhaltung leben, dass hier nur eine logische Trennung der Netze auf Layer 3 und Layer 2 stattfindet.

Wenn nun ein LAN immer weniger vertrauenswürdig ist (im Extremfall wird eine LAN-Infrastruktur wie Strom aus der Steckdose durch einen Provider bereitgestellt), könnte bei hohem Schutzbedarf von Daten (hinsichtlich der Vertraulichkeit oder Integrität) die oben diskutierte Forderung nach Verschlüsselung daher eins zu eins auf das LAN übertragen werden.

Die Standards hierzu haben wir mit MACsec und mit IEEE 802.1X-2010 bereits, d.h. es ist grundsätzlich möglich, konsequent über MACsec vom Client über LAN/MAN/WAN bis hin zum Server die gesamte Übertragung im Netz zu verschlüsseln. Wir haben aber ein Problem
mit der Verfügbarkeit entsprechender Produkte. Lediglich Cisco bietet Switches mit MACsec und eine entsprechende Client-Software an. Außerdem ist bei Cisco eine durchgängige Nutzung von MACsec erst seit kurzem möglich. Trotzdem ist diese Technik als hochinteressant einzustufen und wir werden 2013 tatsächlich erste Netze sehen, die konsequent mit MACsec verschlüsseln. Dass dies ein (kalkuliertes) Abenteuer darstellt und eine solche Technik mit Bedacht und schrittweise eingeführt werden muss, ist klar. Erfahrungen im Netzbetrieb, insbesondere im Trouble Shooting müssen hier erst noch gewonnen werden. Ob sich diese Technik durchsetzen wird und auch andere Hersteller MACsec unterstützen werden, kann auch noch nicht gesagt werden.

Es wird in den nächsten Jahren daher auch weiterhin mit den bewährten Mitteln des Aufbaus mandantenfähiger Netze und der Absicherung kritischer Daten mit VPN-Techniken gearbeitet werden müssen.

Fußnote 1: Siehe „Kurzstudie zu Gefährdungen und Maßnahmen beim Einsatz von DWDM“ vom Bundesamt für Sicherheit in der Informationstechnik (BSI), verfügbar unter https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/hilfmi/doku/doku.html

zugeordnete Kategorien: Endgeräte, 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.

*

.