Zero-Trust implementieren

Der vorangegangene Beitrag zum Thema Zero-Trust-Netzwerk stellte das Konzept vor und erläuterte, warum es den traditionellen Sicherheitsmodellen für Unternehmensnetzwerke vorzuziehen ist. Kurz gesagt, Unternehmens-Firewalls führen zu implizitem Vertrauen unter der Annahme, dass ein Akteur innerhalb der Firewall freundlich sein muss.

Dies ist jedoch nicht immer der Fall, und eine feindliche Partei, der es gelingt, in ein Unternehmensnetzwerk einzudringen, kann die Vorteile des niedrigen Sicherheitslevels nutzen, das hinter Firewalls und VPNs üblich ist. Zero-Trust-Netzwerke verzichten im Gegenteil auf das falsche Versprechen eines sicheren Perimeters und verlangen, dass sich alle Parteien gegenseitig identifizieren und über verschlüsselte Verbindungen kommunizieren.

In diesem Artikel wird erörtert, wie die notwendige Zero-Trust-Infrastruktur implementiert werden kann, mit einem Folgebeitrag über die Migration zu Zero Trust. Für die Zwecke dieses Artikels werden wir die folgenden Begriffe verwenden:

• Client – das Gerät, das eine Anfrage initiiert
• Service – die Anwendung, die auf eine Anfrage antwortet
• Benutzer – der Mensch, der den Client benutzt, falls zutreffend

Innerhalb eines Zero-Trust-Rahmens muss jedes dieser Elemente identifiziert und den anderen bekannt sein, damit eine bestimmte Anfrage Erfolg haben kann.

Client

Die Gewährleistung, dass Anfragen von einem bekannten sicheren Gerät stammen, bietet zusätzliche Sicherheit über die einfache Identifizierung des Benutzers des Geräts hinaus. Die Feststellung, dass ein Gerät „gesperrt“ ist, erfordert jedoch Infrastruktur und Automatisierung. Da alle Client-Geräte dem Zieldienst bekannt sein müssen, muss irgendwo eine Liste gültiger Geräte geführt werden. Bei Zero-Trust wird diese Liste in einer Datenbank geführt, die als Device Inventory Service bezeichnet wird. Geräte, die bei diesem Dienst registriert sind, identifizieren sich ständig selbst und relevante Merkmale, z.B. ob ihre Antiviren-Software auf dem neuesten Stand ist und ob ihre lokale Dateiablage verschlüsselt ist. Die Ergebnisse dieser Instrumentierung werden im Inventar gespeichert und verwendet, um festzustellen, ob und auf welcher Ebene das Gerät für den Zugriff qualifiziert ist. Aus der Tatsache, dass dieses Gerät dem Unternehmen bekannt ist, ergibt sich die Anforderung, dass es Software zur Durchsetzung dieser Richtlinien ausführen muss. Diese Software fällt unter die Kategorie Mobile Device Management (MDM) und wird in der Regel vor der erstmaligen Ausgabe des Geräts an den Benutzer installiert.

Angesichts dessen, was über den Benutzer und sein Client-Gerät bekannt ist, muss festgelegt werden, welche Berechtigung dem Benutzer/Gerät erteilt werden soll. Dies liegt in der Verantwortung des Trust Inferer, eines Infrastruktursystems, das die Regeln, die die Zugriffsrechte festlegen, besitzt und anwendet. Das Ergebnis einer Evaluierung sollte eine Zugriffsebene festlegen. Beispielsweise kann einem Gerät, das sich mit aktuellen Betriebssystem-Patches in gutem Zustand befindet, eine höhere Zugriffsebene gewährt werden als einem Gerät, das im Rückstand ist. Da es sich bei dem Client-Gerät um ein vom Unternehmen verwaltetes Gerät handelt, können Sicherheitsprüfungen den Device Inventory Service kontinuierlich aktualisieren, so dass der Trust Inferer fundierte Zugriffsentscheidungen in Bezug auf das Gerät treffen kann.

Service

Das Herzstück jeder komplexen Anwendung sind die Dienste, die Daten beinhalten, die Geschäftslogik ausführen und/oder Nachrichten verbreiten. Häufig wird jede dieser Komponenten unabhängig von den anderen entwickelt, eingesetzt und skaliert, insbesondere in modernen Mikrodienstarchitekturen. Selbst ein Unternehmen von bescheidener Größe verfügt in der Regel über Konstellationen von Diensten, Datenbanken und Messaging-Systemen, die über das Netzwerk kommunizieren. Bei Zero-Trust muss jede dieser Komponenten unabhängig voneinander gesichert werden.

In einer Zero-Trust-Architektur hilft der Access Proxy (AP), die Sicherheitsanforderungen zu erfüllen. Der AP sitzt zwischen Clients und Services im Netzwerk und stellt sicher, dass nur bekannte und zugelassene Benutzer und Geräte auf einen bestimmten Service zugreifen können. Vorkonfigurierte Regeln für dieZugriffskontrollliste (Access Control List, ACL) für jeden Dienst werden auf jede Dienstanforderung angewendet, und der AP bestimmt, ob sie vom Proxy an den unterstützenden Dienst weitergeleitet werden sollen.

Da der AP auch als Load Balancer dienen kann, ist er ein natürlicher Ort für die SSL/TLS-Terminierung zum Umgang mit https für Web-Tier-Dienste. Auf diese Weise kann sich der unterstützende Dienst auf die Schaffung eines Geschäftswerts konzentrieren, während die Zertifikatsverarbeitung und Authentifizierung/Autorisierung an den vorgeschalteten Proxy ausgelagert wird. Der AP kann benutzerdefinierte Metadaten an den unterstützenden Dienst weitergeben, der damit den Zugriff verschlechtern kann oder granularere Kontrollen als die von den ACLs implementieren kann. Eine Verschlechterung ist ein Kennzeichen eines gut implementierten Zero-Trust, da es eine hohe Sicherheitsposition aufrechterhält und gleichzeitig das Risiko verringert, dass ein Benutzer völlig vom notwendigen Zugriff abgeschnitten wird.

Benutzer

Nachdem sowohl das Client-Gerät als auch der Service, auf den es abzielt, positiv identifiziert wurden, vervollständigt die Identifizierung des Benutzers das Dreigestirn der Gewissheit, die Zero-Trust verlangt. Natürlich gelten System-zu-System-Anforderungen, an denen kein menschlicher Benutzer beteiligt ist, nicht für diese Anforderung oder diesen Abschnitt.

Menschliche Benutzer identifizieren sich normalerweise mit einem Benutzernamen oder einer E-Mail-Adresse und einem Passwort. Unabhängig davon, ob sie eine Thick-Client-Anwendung auf ihrem Gerät oder einen Browser verwenden, ist die Verwendung von Passwörtern in der Praxis gut etabliert. Schwache Passwörter, standortübergreifende Passwortwiederverwendung und andere solche unsicheren Praktiken führen zu Sicherheitsverletzungen. Dies hat zu einem verstärkten Einsatz der Multi-Faktor-Authentifizierung (MFA)geführt, bei der ein physisches Gerät zusammen mit einem Passwort verwendet wird, um sicherzustellen, dass eine Person die Person ist, für die sie sich ausgibt. Diese Geräte können in Form von Hardware-Sicherheitstokens, wie YubiKeys oder Smartcards, oder in Form von mobilen Geräten mit Hilfe einer Anwendung oder SMS-Textnachrichten verwendet werden.

Sobald ein Passwort mit ausreichender Sicherheit festgelegt und zusammen mit einer MFA verwendet wird, ist es oft vorrangig, eine einheitliche Erfahrung für alle Anwendungen innerhalb einer Organisation zu bieten. Dies wird durch Single Sign-On (SSO) unterstützt, bei dem die Anmeldedaten eines Benutzers den Zugang zu mehreren Systemen ermöglichen. Wenn ein externer Identitätsanbieter für diese Authentifizierung verwendet wird, spricht man von einer föderierten Identität. Benutzer sind wahrscheinlich damit vertraut, wenn sie beispielsweise mit ihrer Anmeldung bei Google, Apple oder Facebook Zugang zu einer anderen Website oder einem anderen Dienst erhalten.

Die Aufrechterhaltung individueller Zugriffsrechte für jeden Benutzer in einer Organisation wäre unerschwinglich teuer, daher werden rollenbasierte Zugriffskontrollen häufig eingesetzt, um Benutzern, die eine Klassifizierung teilen, gleichwertigen Zugriff zu ermöglichen, immer mit Blick auf das Prinzip der geringsten Privilegien. Die Kombination aus individueller und Gruppen-Authentifizierung und -Autorisierung umfasst das Identity Access Management (IAM).

[blocktweet]Gut durchdachte Rollen und strukturierte Prozesse rund um das Gruppenmanagement sind grundlegend für die sichere Implementierung von Zero-Trust.[/blocktweet]

Überlegungen zum Netzwerk

Vor der Implementierung der Authentifizierung und anderer Zero-Trust-Sicherheitsinfrastrukturen sollte dem Netzwerk selbst eine gewisse Aufmerksamkeit geschenkt werden. Beim Cloud Computing werden softwaredefinierte Netzwerke als Virtual Private Clouds (VPCs) bezeichnet, die verwandte Ressourcen umfassen, die sich einen IP-Adresspool teilen. Instanzen innerhalb einer VPC können nicht mit Instanzen in einer anderen VPC in Kontakt treten, ohne dass eine spezifische Handhabung des Netzwerks eine solche Kommunikation ermöglicht und leitet. Eine sorgfältige Anwendung von Berechtigungen sollte nicht genehmigte Kommunikation auch zu Peers innerhalb der VPC verbieten. Die von VPCs bereitgestellten Sicherheitsgrenzen fördern eine Praxis, die als Mikrosegmentierung bezeichnet wird, bei der Sammlungen von Services von anderen isoliert werden und genehmigte Kommunikation zwischen Clients und Services ausdrücklich erlaubt sein muss. Auf diese Weise wird der Explosionsradius möglicher Schäden auf ein Minimum beschränkt, selbst wenn eine VPC kompromittiert wird. Anders als bei der traditionellen Vernetzung wird eine fremde Partei keinen vertrauenswürdigen Zugang zu anderen Netzwerkmitgliedern haben.

Schlussfolgerung

Die Implementierung eines robusten Zero-Trust-Rahmens erfordert ein vollständiges Überdenken der Netzwerksicherheit. Die Verantwortung, dafür zu sorgen, dass es keine Sicherheitsverletzungen gibt, verlagert sich von einem handfreien „Castle-and-moat“-System, bei dem Vertrauen innerhalb des Perimeters vorausgesetzt wird, zu einem Modell, bei dem jeder Benutzer, jedes Gerät und jeder Dienst seine Identität und Vertrauenswürdigkeit durch die Bereitstellung von Berechtigungsnachweisen und Telemetriedaten nachweisen muss, die regelmäßig gesammelt und auf dem neuesten Stand gehalten werden. Dies erfordert eine beträchtliche Anfangsinvestition in Infrastruktur und Automatisierung, zahlt sich aber durch einfachen Zugang und ein höheres Maß an Sicherheit aus.