Zero Trust in kleinen Schritten: Warum ein "Minimum Viable"-Ansatz mehr bringt als das Großprojekt

Hallo, hier ist wieder Kora. Heute geht es um ein Buzzword, das mir in Kundengesprächen regelmäßig begegnet: Zero Trust. Und um die erfrischend pragmatische Idee, es einfach mal klein anzufangen.

Warum Zero-Trust-Projekte so oft versanden

Die Beobachtung aus der Praxis, über die ich gestolpert bin, kennen viele von uns: Zero Trust startet als Großprojekt – und endet als Großprojekt. Der Anwendungsbereich wird zu breit gewählt, Teams und Systeme hängen voneinander ab, und irgendwo unterwegs setzt sich die Erwartung fest, man könne Zero Trust wie ein Produkt einkaufen und ausrollen. Kann man nicht.

Dazu kommt die typische Ausgangslage im deutschsprachigen Raum, und die dürfte den meisten von euch bekannt vorkommen: historisch gewachsene Identitätslandschaften, oft ein Active Directory plus mehrere Identity Provider und mehrere Cloud-Tenants nebeneinander. Dazu Schatten-IT durch SaaS-Dienste, die nie jemand freigegeben hat, uneinheitliche Adminpfade und Legacy-Authentifizierung, die niemand anfassen will. Und Engineering-Kapazitäten, die – seien wir ehrlich – ohnehin knapp sind.

Minimum Viable Zero Trust: Scope bewusst klein halten

Der Ansatz Minimum Viable Zero Trust, kurz MVZT, überträgt das aus der Produktentwicklung bekannte Minimum-Viable-Prinzip auf Sicherheitsarchitektur. Die Idee: Man schneidet den Geltungsbereich bewusst so zu, dass sich innerhalb von 90 Tagen ein messbar reduziertes Risiko zeigt. Ohne Buzzword-Architektur, ohne dass ein Hersteller die Roadmap diktiert.

Das finde ich deshalb überzeugend, weil es die richtige Frage in den Mittelpunkt rückt. Nicht: "Ersetzen wir das VPN?" oder "Modernisieren wir das Gateway?" Sondern: Können wir kontrollieren, wer auf welche Ressource zugreift, von welchem Gerät und unter welchen Bedingungen? Und – der Punkt, der in der Praxis am häufigsten fehlt – lässt sich eine Sitzung schnell beenden, wenn diese Bedingungen verletzt werden?

Zero Trust ist ein Kontrollsystem, kein Umbauprojekt

Der entscheidende Perspektivwechsel: Zero Trust ist keine einmalige Aktion, bei der ein Netzwerk umgerüstet wird, sondern ein Kontrollsystem. Bodenhaftung bekommt so ein Programm erst, wenn vier Bausteine zusammenspielen:

• Identität – wer greift zu, sauber und zentral nachvollziehbar
• Gerätezustand – von welchem Endpunkt, in welchem Zustand
• Policy – unter welchen Bedingungen der Zugriff erlaubt ist
• Telemetrie – ob und wie schnell wir mitbekommen, dass etwas nicht stimmt

Fehlt einer dieser vier Bausteine, bleibt der Rest Stückwerk. Eine perfekte Policy nützt wenig, wenn niemand ihre Verletzung sieht. Und die schönste Telemetrie hilft nicht, wenn es keinen Hebel gibt, um eine Sitzung zu beenden.

Was das für Hosting- und Rechenzentrumsumgebungen heißt

Bei uns im Betrieb sehe ich genau dieselben Muster wie beschrieben – nur eben auf Infrastrukturebene. Admin-Zugänge, die über Jahre gewachsen sind. Servicekonten, deren Besitzer niemand mehr benennen kann. Management-Interfaces, die "nur intern" erreichbar sind, bis jemand ein Routing ändert. Genau da lohnt sich der MVZT-Gedanke aus meiner Sicht am meisten: Statt das gesamte Netz neu zu denken, nimmt man sich einen klar abgegrenzten, aber besonders sensiblen Bereich vor – etwa die administrativen Zugriffspfade auf produktive Systeme – und bringt dort Identität, Gerätezustand, Policy und Telemetrie sauber zusammen.

Der Reiz liegt im Nebeneffekt: Ein kleiner, abgeschlossener Scope liefert nach wenigen Wochen ein vorzeigbares Ergebnis. Das schafft Vertrauen bei der Geschäftsführung, es schafft Erfahrungswerte im Team, und es liefert eine Blaupause für den nächsten Bereich. Ein zweijähriges Programm dagegen liefert vor allem eines: Statusberichte.

Mein Fazit

Ich halte wenig davon, Sicherheitskonzepte an der Anzahl der beteiligten Produkte zu messen. Viel spannender finde ich die Frage, wie schnell ein Unternehmen einen kompromittierten Zugriff erkennen und stoppen kann. Wer diese Frage für einen kleinen Ausschnitt seiner Landschaft überzeugend beantworten kann, ist weiter als jemand, der ein hübsches Architekturdiagramm für die gesamte IT besitzt – und keine einzige aktive Kontrolle darin.

Falls ihr bei euch überlegt, wo ihr anfangen sollt: Nehmt den Bereich, bei dem euch ein erfolgreicher Angriff am meisten wehtun würde. Nicht den, der technisch am einfachsten wäre.

Bis demnächst, eure Kora

Quelle: heise online