Zero Trust erfordert klaren Architekturplan

Zero Trust betrifft alles: Identitäten, Anwendungen, Netze, Daten und Geräte. Wer alles auf einmal anfassen will, wird sich verzetteln. In unseren Untersuchungen haben wir festgestellt, dass die Unternehmen, die Zero Trust erfolgreich umgesetzt haben, sich in der ersten Phase mit dem Ausarbeiten einer Architektur beschäftigt haben. Schwierigkeiten bekamen indes Betriebe, die sich zu schnell in die Aufgabe hineinstürzten und gleich mit der Umstrukturierung von Netzwerken, dem Datenmanagement, dem Kauf von Tools oder dem Aufstellen von Implementierungsteams loslegten. Beim Aufbau einer Zero-Trust-Architektur zahlt es sich aus, erst genau darüber nachzudenken, wie alle Teile zusammenpassen.

Zur Klärung vorweg: Wenn wir von erfolgreicher Security sprechen, meinen wir Organisationen mit einer niedrigen Quote an schwerwiegenden Cybersicherheitsvorfällen. In den erfolgreichsten Organisationen sind maximal zwei von 100 Vorfällen schwerwiegend in dem Sinne, dass Mitarbeitende oder die Geschäftstätigkeit insgesamt betroffen sind oder die Öffentlichkeit informiert werden muss. Oft liegt bei den Vorreitern die Quote sogar deutlich unter zwei Prozent.

Zero-Trust-Planung

Zero Trust erfordert immer Änderungen auf der Architekturebene, im Netz, bei der Sicherheit und beim Datenzugang. Das liegt schon am Prinzip dieses Ansatzes: In einer Zero-Trust-Umgebung gibt es kein implizites Vertrauen, ganz egal, welche Standorte und welche Vertrauensbeziehungen involviert sind.

Zero Trust berührt zwangsläufig jeden Aspekt des Betriebs und jede Ebene der Systeme. Darüber hinaus stellt es einen radikalen Wechsel vom derzeit vorherrschenden Paradigma dar, bei dem einigen Nutzern und Teilen eines Netzes mehr Vertrauen entgegengebracht wird als anderen. Änderungen an den Kernsystemen müssen jedoch erst dann in Betracht gezogen werden, wenn das Gesamtbild der Zero-Trust-Umgebung definiert ist.

So können Architekten beispielsweise entscheiden, ob Zugriffsrechte auf der Anwendungs- oder der Netzwerkebene erteilt werden sollen. Auf der Netzebene lässt sich beispielsweise steuern, dass eine Geschäftseinheit für die Nutzung bestimmter Dienste autorisiert ist, eine andere aber nicht - und letztere kann auch nicht sehen, wie und womit die andere Einheit arbeitet. Sie kann auch keine Anmeldedaten erhalten. Für solche Fälle muss das Netz möglicherweise umgestaltet werden, um eine geeignete Policy Map durchsetzen zu können.

Zugriffsrechte können für Systeme, auf denen ein Software-definierter Perimeter-Client läuft, auch am Endpoint geregelt werden. Das Netzwerk kann solche Richtlinien nur für Geräte wie beispielsweise Sensoren oder Zeitschaltuhren durchsetzen. In jedem Fall sollten diesbezügliche Entscheidungen möglichst schon getroffen worden sein, bevor die Neugestaltung der einzelnen Technologiebereiche beginnt.

Zero-Trust-Umsetzung

Sobald die übergeordnete Architektur und die untergeordneten Architekturmerkmale festgelegt wurden, sollte sich die IT-Abteilung den Fragen der Implementierung zuwenden. Wie immer geht es dabei um Menschen, Prozesse, Richtlinien und Technologie.

Was die Mitarbeiter betrifft, so stellen die meisten Unternehmen (auch die erfolgreichsten) zu Beginn einer Zero-Trust-Initiative funktionsübergreifende Implementierungsteams zusammen. Diese beginnen damit, die Architekturvision in die Realität zu übersetzen und sich mit Portfolien und Prozessen zu beschäftigen. Da Zero-Trust einen grundlegend veränderten Ansatz bezüglich Sicherheit und Zugangsrechten bedeutet, muss irgendwann jeder im Unternehmen dem Zero-Trust-Team angehören.

Kurzfristig sollten jedoch wichtige Mitarbeiter aus der Netzwerktechnik, dem Datenmanagement und der Anwendungstechnik damit beauftragt werden, sich ganz auf die Einführung von Zero-Trust zu konzentrieren. In dieser Phase sollten sie so weit wie möglich von den täglichen Administrations- und Wartungsaufgaben abgezogen werden. Während sie die Lücken zwischen ihrer bestehenden IT-Umgebung und der angepeilten Zero-Trust-Architektur ausloten, werden sie vorschlagen, welche Tools eingesetzt werden sollten. Das Team wird sich dazu mit Fragen auseinandersetzen wie: Werden wir einen Software-definierten Perimeter (SDP) einführen? Wenn ja, welcher wird es sein und für welche Funktionen? Brauchen wir ein universelles Service-Gateway für den Benutzerzugang zu Anwendungen? Welches nehmen wir und wie kann es die Policiy mit der SDP austauschen?

Vom Zero-Trust-Team werden dann auch erste Veränderungen der Richtlinien für Sicherheit und Zugriffsrechte ausgehen. Dann geht es um Fragen wie: Welche Arten des Zugriffs auf Systeme sind ein "Grundrecht" für jeden Mitarbeiter und welche sind an bestimmte Aufgaben geknüpft? Und wie lässt sich die Einhaltung überprüfen? Abschließend lässt sich festhalten, dass der Übergang in die Zero-Trust-Welt mit der Architektur beginnt. Alles andere sollte sich daraus ergeben. Für die Umsetzung des neuen Paradigmas sind verschiedene Architekturebenen einzubeziehen und es wird auch nicht ohne neue Tools gehen Alles muss aber mit einer klaren Definition des Big Picture beginnen. (jm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Network World.