Nicht alle IT-Organisationen waren gleichermaßen gut auf die Home-Office-Verpflichtung vorbereitet, die allen Betrieben und Behörden als Reaktion auf die "epidemische Lage nationaler Tragweite" auferlegt wurde. War ein Technologie-Start-Up von Beginn an auf geografisch verteiltes, ortsunabhängiges Arbeiten ausgelegt, so stellte "Work from Home" einige Behörden oder größere Finanzinstitute vor enorme Herausforderungen.

Dabei war die überstürzte Beschaffung von Notebooks für alle Mitarbeiter, deren Arbeitsplatz mit einem Desktop- oder Tower-PC ausgestattet war, noch das geringste Problem. Die kniffligere Aufgabe war es, diese Notebooks unter den neuen Bedingungen nutzbar zu machen.

Die meisten IT-Landschaften, die Anfang 2020 auf einen Präsenzbetrieb in zentralisierten Bürostandorten ausgerichtet waren, setzen stark auf klassische Win32-Anwendungen. Teils handelt es sich dabei um Standardsoftware wie Mailclients, Dokumenten- oder Tabellenverarbeitung. Den anderen Teil stellen branchenspezifische Applikationen ("Line of Business"-Software; LOB), die wiederum mit der Standardsoftware verzahnt sind, um beispielsweise Dokumente zu erzeugen und sie per E-Mail zu versenden.

Die meisten dieser Programme setzen auf Standardprotokolle wie SMB oder Microsoft SQL über TCP/IP, um an ihre Datenbestände zu kommen. Dabei wird das am Client interaktiv angemeldete Benutzerkonto – in der Regel ein Account aus einer Active-Directory-Domäne – für die Authentifizierung und Autorisierung des Datenzugriffs verwendet. Ironischerweise setzen sogar einige LOB-Anwendungen, die über eine eigene Benutzer- und Zugriffsverwaltung innerhalb des Programms verfügen, auf Windows-eigene Pass-Through-Authentifizierung, um den Zugriff auf Dateien und Datenbanken überhaupt erst zu ermöglichen. Einige der Branchenanwendungen verzichten auf eine richtige Paketierung und Verteilung ihrer Clientkomponenten zugunsten der Speicherung dieser ausführbaren Dateien in einer Fileserver-Freigabe, von wo die Nutzer die Anwendung mittels einer Desktop-Verknüpfung starten.

Ist das Netzwerk am Bürostandort schnell und robust genug, kann eine solche Anwendungslandschaft durchaus zufriedenstellend funktionieren. Sind das interne Netzwerk und die zugreifenden Clients durch einen stark befestigten Perimeter geschützt, kann eine solche Infrastruktur auch aus Sicherheitssicht als "gut genug" gelten. All das änderte sich schlagartig mit dem Auszug der Büroarbeitsplätze, als die überforderten IT-Teams zu einem Mittel griffen, das schnell umsetzbar war und ihnen in der Vergangenheit bereits für die Remote-Administration der IT-Systeme gute Dienste geleistet hat: Virtuelle Private Netzwerke (VPN). In ihrer Analyse der Bedrohungslage durch Remote-Arbeit [1] führen die Analysten von Deloitte "fast broadband and secure access to the corporate network via VPN" als Voraussetzung für eine erfolgreiche Home-Office-Strategie an. Leider weist im realen Leben das Konzept VPN in beiden von Deloitte erwähnten Disziplinen "fast broadband" und "secure" gravierende Mängel auf.

Menschen, die bereits vor 20 Jahren viel mit ihrem Computer von unterwegs arbeiten mussten, erinnern sich bestimmt noch an die DFÜ-Einwahl mit Modem, ISDN-Karte oder GSM- und später GPRS-Telefon. Unternehmen mussten für ihre Außendienstler große Modem-Bänke und entsprechende Amtsleitungen zur Einwahl in das interne Netz vorhalten. Als die ersten VPNs auf den Markt kamen, erschien vielen die Technologie zunächst einmal als großer Fortschritt, zumal sich im Privatbereich bereits DSL-Anschlüsse etablierten und auch Mobilfunknetze immer schnellere Datenübertragung ermöglichten. Für Verbindungen zwischen Unternehmensstandorten mit symmetrischen Internetleitungen und garantierter Quality-of-Service ist VPN nach wie vor ein probates Mittel, um preiswerte und gute Standortverbindungen herzustellen.

Doch bei der Einwahl eines einzelnen Laptops ins Unternehmensnetz erzeugt ein VPN gegenüber der herkömmlichen DFÜ-Einwahl zwei große Probleme:

- Die Bandbreite einer DFÜ-Einwahl, sofern diese aus dem Festnetz erfolgte, war zwar nach den heutigen Maßstäben gering, aber dafür konstant und garantiert. Bandbreiten und Latenzen im Point-to-Site-VPN sind extremen Schwankungen unterworfen, mit denen nicht alle Datenübertragungsprotokolle gleichermaßen gut klarkommen.

- Ein VPN-Zugriff setzt eine Internetverbindung voraus. Diese muss bestehen, bevor ein VPN-Tunnel aufgebaut werden kann. Im "Work from Home"-Szenario wird dies in der Regel über das zu Hause vorhandene LAN oder WLAN erfolgen. Vor dem Aufbau des VPN-Tunnels ist der Arbeitsrechner daher allen Gefahren ausgesetzt, die in einem Heimnetz lauern – Router mit veralteter Firmware und Standardpasswort, notorisch unsichere Smart-Home-Geräte, neugierige Nachbarn, die das WLAN-Kennwort geknackt oder zufällig erfahren haben.

Der zweite Punkt ist besonders kritisch: Während die meisten Unternehmen umfangreiche Maßnahmen ergreifen, um keine fremden Geräte in ihr lokales Netz zu lassen, haben die wenigsten ein Problem damit, dass ein Unternehmens-Notebook, nachdem es sich in unbekannten Netzen herumgetrieben hat, wieder ins LAN kommt – sei es per VPN aus dem Home Office oder physisch beim nächsten Besuch des Mitarbeiters im Büro. Diese konzeptionellen Nachteile der VPN-Technologie sind den Anbietern durchaus bewusst. Die am weitesten verbreiteten Maßnahmen, um die Angriffsfläche eines Firmengeräts zu reduzieren, sind:

- Ausschließlich LTE-Verbindungen (und darüber einen VPN-Tunnel in die Firma) am Firmen-Notebook zulassen.

- VPN im Full-Tunnel-Modus betreiben. Damit geht die gesamte Kommunikation über die Infrastruktur des Arbeitgebers.

- VPN schnell nach Herstellung der Internetverbindung aufbauen und nur bestimmte Adressen für Verbindungen außerhalb des VPN-Tunnels zulassen.

Aus Sicherheitssicht ist der erste Ansatz noch am vielversprechendsten, sind die Firmengeräte damit doch nie mit fremden Geräten im gleichen Netz. Allerdings funktioniert diese Strategie im Hinblick auf die Usability und damit auf die Produktivität der Remote-Worker nur, wenn wirklich durchgehend LTE- oder 5G-Verbindungen vorhanden sind.

Alle Ansätze, die die Kommunikation des Firmen-Notebooks mit dem lokalen Netz zu Hause unterbinden, machen auch das Drucken unmöglich, sofern der Drucker zu Hause über LAN oder WLAN angeschlossen ist. Dies muss der Arbeitgeber berücksichtigen und eventuell den Arbeitnehmern einen vorinstallierten USB-Drucker mit nach Hause geben. Ein zusätzliches Gerät wird nicht jedes Home Office verkraften können und die Qualität der kompakten Drucker ist ebenfalls nicht unbedingt "Enterprise-fähig".

Schließlich führt das Einschränken der am VPN vorbei erreichbaren Adressen dazu, dass sich Internetzugänge mit einem Captive-Portal (im Zug, Hotel, Gastronomie oder auch in Gästenetzen befreundeter Unternehmen) nicht nutzen lassen. Manche VPN-Anbieter erlauben daher freies Internetsurfen für einige wenige Minuten und zurren die Firewall für ausgehende Verbindungen anschließend fest. Eine solche Lösung kann höchstens als "security by obscurity" gelten und führt oft zu Beschwerden der Nutzer, wenn die Zeitspanne für die Eingabe der WLAN-Informationen zu kurz ist.

Doch welche Maßnahmen Sie auch immer ergreifen, um eine klassische VPN-Einwahl sicherer zu machen, am Ende steht immer ein Gerät, das unbeaufsichtigt fremden Einflüssen unterliegt und netzwerktechnisch direkt ins Herz Ihrer Infrastruktur verbunden ist – zu Domaincontrollern, Dateiservern und unternehmenskritischen Datenbanken. Die auf dem Endgerät lokal installierte Antimalware- oder EDR-Lösung ist somit der einzige Schutz Ihrer Kerninfrastruktur.

Eine Reihe von Unternehmen und Organisationen mussten sich diesen Herausforderungen bereits vor einigen Jahren stellen und haben sie erfolgreich gemeistert. Anfang der 2010er Jahre war "Bring Your Own Device" (BYOD) in aller Munde. Damit ist gemeint, dass der Arbeitgeber, statt den Arbeitnehmern einen Computer oder ein Smartphone zur Verfügung zu stellen, den Kauf eines privaten Endgeräts und den Mobilfunktarif bezuschusst, sofern die angeschafften Devices gewisse Mindestvorgaben erfüllen. Es liegt in der Verantwortung des Arbeitnehmers, mit diesem Gerät im vereinbarten Maß arbeitsfähig zu sein, das heißt, das Gerät funktionsfähig zu halten und reparieren zu lassen, sollte es einmal defekt sein.

In Deutschland ist BYOD nie wirklich angekommen. Dafür gibt es viele Gründe, die teils in der Abgabenordnung, teils aber in den arbeitsrechtlich-sozialen Gepflogenheiten hierzulande begründet liegen. Allerdings konnte die Branche in der Pandemie durchaus von Unternehmen lernen, die den BYOD-Pfad eingeschlagen hatten. Mit der Entscheidung für BYOD ist nämlich die Feststellung verbunden, dass der Zugriff auf Unternehmensdaten und -anwendungen von einem Endgerät aus erfolgen muss, das von jemand anderem verwaltet wird. Idealerweise ist es der Nutzer, der die Hoheit über das Gerät hat, doch kann der Arbeitgeber nicht ausschließen oder verhindern, dass das Notebook mit Malware infiziert ist oder ein Familienmitglied Zugang dazu hat.

Um auch unter solchen Bedingungen optimales Arbeiten zu ermöglichen, muss die zentrale IT so beschaffen sein, dass der Client eine möglichst geringe Rolle im Arbeitsprozess spielt und die potenziellen Sicherheitsprobleme sich nicht vom Client in die IT des Arbeitgebers verbreiten können.

Gilt das Endgerät grundsätzlich als nicht vertrauenswürdig, ergeben sich daraus mehrere Anforderungen an den Daten- und Anwendungszugriff. Erstens wird jedes physische oder logische Netzwerk, mit dem der Client verbunden sein könnte, als "extern" eingestuft. Aus diesen Netzen ist kein Zugriff auf die zentrale IT mittels Protokollen möglich, die eine vertrauenswürdige Verbindung voraussetzen wie SMB, RPC oder ungesichertes RDP. Zweitens gibt es keine Notwendigkeit und keine legitime technische Möglichkeit, Unternehmensdaten lokal auf dem Endgerät zu speichern. Und da drittens nicht vollständig zu verhindern ist, dass sich Tastatureingaben und somit Namen und Passwörter vom Endgerät abfischen lassen, muss jeder Zugriff auf die Unternehmensanwendungen mit Multifaktor-Authentifizierung (MFA) geschützt sein. Idealerweise ist ein passwortloses Anmeldeverfahren anzuwenden. Schließlich ist trotz alledem der Nutzer per Vertrag zu verpflichten, sein Endgerät und die Anwendungen darauf aktuell zu halten, einen für das Betriebssystem zertifizierten Antimalware-Scanner zu installieren und dauerhaft zu aktivieren.

Für den Zugang zu den Unternehmensdaten sind die herkömmlichen Win32-Anwendungen in einem solchen Szenario natürlich denkbar ungeeignet, denn diese verlassen sich in der Regel auf die Vertrauenswürdigkeit sowohl der Verbindung als auch des am Client lokal angemeldeten Benutzer-Accounts. Die bisher beste Möglichkeit, den Clientzugriff auf Unternehmensdaten abzuschirmen, bieten webbasierte Anwendungen mit modernen Reverse-Proxies und Web Application Firewalls davor. Wenn Ihre Organisation neue Anwendungen beschafft, mit denen auch mobile Nutzer arbeiten müssen, sollten Sie daher zumindest die Empfehlung aussprechen, Applikationen mit einem Webfrontend wohlwollend zu prüfen und bei gleicher Funktionalität den klassischen Win32-Programmen vorzuziehen.

Dies ist allerdings ein langfristiges Projekt, das auch Gefahren birgt, wenn Anwendungen migriert werden müssen oder neue Anbieter an Bord kommen. Gegenwärtig müssen Sie die vorhandenen Win32-Applikationen an Clients bringen, die aus einem fremden Netz kommen und mit den Anwendungsservern keine gemeinsame Authentifizierungsbasis haben. Dafür existieren bereits seit Jahrzehnten bewährte Lösungen. Ironischerweise haben viele Firmen und Organisationen diese sogar schon im Einsatz, greifen im Ernstfall aber dennoch häufig auf VPN und lokal installierte Anwendungen zurück.

Ist ein für "extern" erklärtes Endgerät nicht im Zuge von BYOD vom Mitarbeiter selbst angeschafft, sondern gehört dem Arbeitgeber, hat Letzterer natürlich ein großes Interesse daran, das Gerät dennoch zu verwalten. Die Verwaltbarkeit eines direkt angebundenen Geräts wird am häufigsten als Argument für die VPN-Anbindung und auch für die Active-Directory-Mitgliedschaft der Firmen-Notebooks angeführt. Dies ist besonders dann der Fall, wenn für die Geräteverwaltung die Windows-Bordmittel zum Einsatz kommen: WSUS statt Patchmanagement, Gruppenrichtlinien statt Konfigurationsmanagement, Turnschuh-Administration statt Softwareverteilung.

Dabei verfügt nahezu jede verbreitete Clientmanagement- oder Softwareverteilungsanwendung über die Fähigkeit, Geräte zu verwalten, die sich außerhalb der Infrastruktur aufhalten. Und reine Clouddienste wie Microsoft Intune (mittlerweile Teil des "Microsoft Endpoint Manager") können erst recht sehr gut mit Geräten umgehen, die sich in diversen öffentlichen Netzen tummeln.

Ein klarer Vorteil des Clientmanagements ohne VPN liegt in der Bandbreitenausnutzung beim Herunterladen von Updates für Windows, Office und andere Applikationen. Clients, die über VPN mit der Zentrale verbunden sind, sind in der Regel so konfiguriert, dass sie die Microsoft-Updates vom internen WSUS beziehen, was dem IT-Team die Möglichkeit gibt, Updates gezielt freizugeben oder abzulehnen.

In einer Situation, wo die Mehrzahl der Clients sich außerhalb der LAN-Standorte befindet, werden die Updates für jeden einzelnen Client über den Internet-Uplink der Firma übertragen. Das sorgt für verstopfte Internetleitungen, die Übertragung der Updates dauert länger und bricht manchmal sogar ab. Laden die Endgeräte ihre Updates hingegen direkt aus dem Internet herunter, wird die Bandbreite an Unternehmensstandorten geschont. Die IT kann mithilfe der eingesetzten Managementlösung dennoch kontrollieren, welche Updates für die Endgeräte freigegeben werden und wann.

Anbieter von Remote Access wie Citrix, Microsoft oder VMware haben sich bereits sehr früh Gedanken darüber gemacht, wie sich der Zugriff auf Desktops und Anwendungen auch aus "potenziell feindlichen" Netzen möglichst sicher und universell verwendbar gestalten lässt. Aus Clientsicht ist die Technik bei allen Herstellern identisch: Das proprietäre Kommunikationsprotokoll (RDP bei Microsoft, ICA/HDX bei Citrix, PCoIP oder Blast bei VMware) wird in HTTPS eingekapselt. Damit verbessert sich einerseits die Sicherheit durch eine zusätzliche Verschlüsselungsschicht.

Andererseits erleichtert dies auch in stark geregelten Umgebungen den Verbindungsaufbau, denn HTTPS auf Standardport 443 ist in den meisten Organisationen, Hotel- und Konferenz-WLANs ausgehend an der Firewall zugelassen. Proprietäre Protokolle, allen voran das aus Sicherheitssicht problematische RDP auf Port 3389, sind hingegen oft in öffentlichen wie privaten Netzen gesperrt.

Bei Citrix und VMware können die jeweiligen Sicherheitsgateways (Netscaler ADC beziehungsweise VMware UAG) sogar miteinander kaskadieren, sodass ein externes Gateway in der DMZ Verbindungen aus dem Internet annimmt und den verschlüsselten Tunnel an das interne Gateway weiterreicht. Auf diese Weise unterhält kein einzelnes System gleichzeitige Verbindungen zum Internet und zum internen LAN. Trotz dieser Technologie setzen viele IT-Teams dennoch weiterhin auf VPN als Mittel für die Absicherung externer Remote-Zugänge und vergeben dabei einige Performance-Vorteile.

Die meisten Einwahl-VPNs funktionieren nach dem "SSL VPN"-Prinzip und bauen auf dem TCP-Protokoll mit seiner garantierten Zustellung, Sendewiederholung und Berücksichtigung der genauen Reihenfolge der Pakete auf. Im Remote-Access-Bereich setzt sich bei allen Herstellern jedoch das verbindungslose UDP durch, bei dem die schnelle Zustellung möglichst vieler Pakete wichtiger ist als die garantierte Zustellung jedes einzelnen. Die herstellereigenen Sicherheitsgateways beherrschen sowohl TCP als auch UDP und präferieren bei Verfügbarkeit UDP, da dieses Protokoll dem Wesen des Remote Access viel besser entspricht. Kapseln Sie hingegen die Kommunikation durch Einsatz eines SSL-VPN in TCP ein, zwingen sie das verbindungslose UDP in den engen Rahmen der TCP-Verbindungen.

Weitere Sicherheitsfeatures wie etwa das Durchschleifen lokal angeschlossener Peripherie in eine Remote-Sitzung funktionieren ebenfalls besser und lassen sich granularer steuern, wenn die Verbindungen durch native Gateways aufgebaut werden und die Netztopologie nicht durch VPN verfälscht wird. So kann ein UAG beispielsweise unterscheiden, ob der Client sich im Netz eines Partnerunternehmens oder im freien Internet befindet. Werden alle Verbindungen aus dem IP-Adresskreis des VPN-Konzentrators aufgebaut, ist diese Erkennung nicht mehr möglich.

Ein häufig zitiertes Szenario, das auf den ersten Blick gegen die auf externen Endgeräten und auf Remote Access basierenden Architekturen spricht, ist der berühmte "ICE im Tunnel" ohne Verbindung zur Außenwelt. Um diesen Fall abzubilden, versuchen IT-Verantwortliche, möglichst sichere Hintertüren zu schaffen, um Daten aus der zentralen Umgebung auf die Endgeräte und wieder zurück zu schmuggeln, damit sie sich offline bearbeiten lassen.

Sehr häufig ist dieser Fall jedoch nur konstruiert und wird aus Angst angeführt, auf gewohnte Arbeitsweisen verzichten zu müssen. Jede Art lokaler Datenverarbeitung auf dem Client stellt Sie vor eine ganze Reihe von Herausforderungen:

- Die Anwendungen, die die Daten verarbeiten, müssen auf die Endgeräte gebracht, dort konfiguriert und dauerhaft aktuell gehalten werden.

- Oft genug diktieren die benötigten Anwendungen die Wahl des Client-Betriebssystems, sodass Clientkonzepte, die auf Chromebooks und anderen "leichten" Plattformen basieren, nicht mehr flächendeckend möglich sind.

- Die zu bearbeitenden Dateien müssen sich bewegen, ohne dass das Gerät eine direkte Verbindung zu der Kerninfrastruktur bekommt. Dafür eignen sich am besten webbasierte Dienste – entweder Dokumentenspeicher a la SharePoint oder spezielle Portale für solche Transfers. In jedem Fall ist die Übertragung an externe Geräte mit MFA zu sichern und zu protokollieren.

- Da sich auf dem Endgerät nun Unternehmensdaten befinden, sind Festplattenverschlüsselung, modernes EDR und idealerweise auch ein Data-Leak-Prevention-Programm (DLP) Pflicht.

- Besonders kritisch ist der Moment, in dem offline bearbeitete Dateien zurück in die zentrale Arbeitsumgebung geschleust werden müssen. Dafür muss der Client nach einer Offline-Phase eine Netzwerkverbindung herstellen. Die installierten Sicherheitslösungen sind in diesem Moment nicht wieder auf dem aktuellen Stand und bieten keinen Schutz gegen zwischenzeitlich bekannt gewordene Zero-Day-Attacken. Daher müssen Sie für den Datentransfer auf einen Weg zurückgreifen, der diese Risiken auffangen kann – optimalerweise auf eine "Datenschleuse" mit Webfrontend.

Die hohe Komplexität, die mit einer halbwegs sicheren Umsetzung des "Offline Use Case" einhergeht, sollte Sie dazu veranlassen, dieses Szenario gegenüber den Fachabteilungen kritisch zu hinterfragen und nach Ansätzen für die dort konkret bestehenden Anforderungen zu suchen. Ein Clientendgerät abwechselnd in Netzen unterschiedlicher Sicherheitsstufen zu betreiben, kann aus Sicherheitssicht nicht die Lösung sein.

Ist in einer modernen Client-/Server-Landschaft überhaupt noch Platz für einen vertrauenswürdigen Client, der über AD-Mitgliedschaft und direkte Verbindungen zu Infrastrukturservern verfügt? Durchaus, wenn sich der Client dauerhaft ausschließlich im Unternehmensnetz befindet. Dies kann ein fester Arbeitsplatzrechner im Büro sein oder ein Endgerät beim Benutzer zu Hause, das sich aber nicht durch einen lokal installierten VPN-Client, sondern mittels einer "Office Extension" – also eines kleinen vom Arbeitgeber gestellten VPN-Routers – mit dem Büro verbindet.

Besonders wichtig ist die auf "vertrauenswürdigen Clients" basierende Architektur in drei Szenarien:

- Schneller Zugriff auf große Datenmengen bei gleichzeitiger schneller Verarbeitung dieser Daten, zum Beispiel bei großen CAD-Zeichnungen komplexer Objekte. Trotz GPU-Virtualisierung sollten Sie in einem solchen Use Case durchaus eine physische Workstation in Betracht ziehen.

- Bearbeitung hochsensibler Daten, die nicht remote durchgeführt werden darf. Dazu gehört beispielsweise die Tier-0-Systemadministration in einem Netzwerk mit hoher Schutzstufe. Doch auch die Bearbeitung von Verschlusssachen kann solchen Kriterien unterliegen.

- Arbeitsplätze, die sich durch den Charakter der Tätigkeit nicht ins Home Office verlegen lassen, beispielsweise im Sicherheits- oder Produktionsbereich.

Auf solchen Clients deaktivieren Sie am besten per Gruppenrichtlinie die zwischengespeicherte Anmeldung, sodass eine Benutzeranmeldung nur dann möglich ist, wenn eine aktive Verbindung zu der zentralen Infrastruktur besteht.

Eine mobile und gleichzeitig sichere Clientflotte zu betreiben, ist möglich. Dafür müssen Sie sich von den Managementpraktiken der Jahrtausendwende verabschieden und eine moderne Verwaltung über das Internet einsetzen, wahlweise aus der Cloud oder aus Ihrer Infrastruktur heraus. Um den sicheren Zugriff auf herkömmliche Win32-Applikationen in einem solchen Szenario zu ermöglichen, stehen Ihnen Terminalserver und VDI inklusive der dazugehörigen Gateways zur Verfügung. Damit lässt sich der Zugriff besser absichern und granularer steuern wie mittels VPN.