Drei Fragen und Antworten: Wie man Zero Trust mit Minimalansatz einführt

Das Sicherheitskonzept Zero Trust geht davon aus, dass kein Benutzer, Gerät, Dienst oder Netzwerk automatisch als vertrauenswürdig gilt. Die Einführung gilt als langfristig und aufwendig. Doch statt gleich alles zu wollen, kann man sich auch auf einige wenige Basismaßnahmen mit großem Impact konzentrieren. Der Minimum-Viable-Ansatz setzt dort an, wo das Schadenspotenzial im Ernstfall am höchsten ist. Wie man diese Idee bei der Einführung von Zero Trust im Unternehmen umsetzen kann – das erklärt Marcel Küppers, einer der Titelautoren der neuen iX 09/2026, im Interview.

Die Einführung von Zero Trust kann in der Unternehmens-IT schnell zum endlosen Großprojekt ausarten. Woran liegt das?

Das liegt vor allem daran, dass Zero Trust häufig als umfassende Zielarchitektur verstanden wird, die gleichzeitig Netzwerk, Identitäten, Endgeräte, Anwendungen, Cloud-Dienste und Betriebsprozesse verändern soll. In gewachsenen Unternehmensumgebungen trifft dieser Anspruch auf heterogene Verzeichnisdienste, mehrere Identity Provider, Legacy-Anwendungen, historisch gewachsene Admin-Pfade und uneinheitliche Geräteverwaltung. Wenn dann noch versucht wird, alle Applikationen und Nutzergruppen gleichzeitig einzubeziehen, wächst der Scope sehr schnell.

Ein zweites Problem ist, dass Zero Trust oft zu stark auf Produkte oder Netzwerkmodernisierung reduziert wird. Dann stehen ZTNA, Mikrosegmentierung oder VPN-Ablösung im Vordergrund, obwohl privilegierte Identitäten, dauerhafte Admin-Rechte oder schlecht geschützte Service-Konten weiterhin die wesentlich größeren Risiken darstellen. Das Projekt wird technisch breit, ohne zuerst die kritischsten Angriffspfade zu schließen.

Hinzu kommt die fehlende Messbarkeit. Wenn nicht klar definiert ist, welches Risiko innerhalb eines bestimmten Zeitraums reduziert werden soll und anhand welcher Kennzahlen sich das belegen lässt, wird Zero Trust schnell zu einem Programm ohne eindeutigen Endpunkt.

Minimum Viable Zero Trust (MVZT) verspricht dagegen eine Einführung in 90 Tagen. Was macht dieser Ansatz anders?

MVZT versucht nicht, Zero Trust in 90 Tagen vollständig umzusetzen. Der wesentliche Unterschied liegt in der radikalen Eingrenzung des Scopes. Im Mittelpunkt stehen zunächst die Identitäten und Zugriffspfade, deren Kompromittierung den größten Schaden verursachen kann: privilegierte Konten, Cloud- und Directory-Administration, CI/CD, Secrets, Backup und zentrale Security-Systeme.

Statt jede Anwendung neu zu modellieren, behandelt MVZT Zero Trust als Kontrollsystem. Eine Zugriffsentscheidung basiert auf Identität, Authentifizierungsstärke, Gerätezustand, Risikosignalen und Schutzbedarf der Zielressource. Für besonders kritische Zugriffe kann die Policy beispielsweise eine stärkere Authentifizierung verlangen, eine Sitzung zeitlich begrenzen oder den Zugriff vollständig verweigern.

Entscheidend ist außerdem, dass Nachweisbarkeit von Anfang an Teil der Umsetzung ist. Policies, Authentifizierungs- und Audit-Logs, JIT-Aktivierungen oder Sitzungswiderrufe werden nicht erst für ein späteres Audit dokumentiert, sondern entstehen direkt im Betrieb. Damit lässt sich nach 90 Tagen nicht nur sagen, was implementiert wurde, sondern auch, wie groß die tatsächliche Abdeckung ist und wie schnell auf Identitätsmissbrauch reagiert werden kann.

Wie sieht der 90-Tage-Plan dann im Groben aus?

In den ersten beiden Wochen geht es zunächst darum, den Scope sauber festzulegen. Privilegierte Rollen und Identitäten werden inventarisiert, Tier-0- und Tier-1-Systeme definiert und die wichtigsten Admin-Pfade identifiziert. Für diesen eingeschränkten Bereich werden Phishing-resistente Authentifizierung und ein klarer Geräte-Compliance-Standard eingeführt. Parallel müssen Authentifizierungs- und Admin-Audit-Logs zentral verfügbar sein, weil ohne Telemetrie weder Wirkung noch Abdeckung messbar sind.

Zwischen Woche drei und sechs folgt die strukturelle Härtung. Administrationskonten werden von normalen Nutzerkonten getrennt, dauerhafte privilegierte Rollen möglichst durch Just-in-Time-Aktivierungen ersetzt und besonders kritische Rollen an Begründungen, Tickets oder Freigaben gebunden. Gleichzeitig werden die wichtigsten Secrets und Deployment-Credentials in einen Vault überführt, Rotation etabliert und grundlegende CI/CD-Leitplanken wie Branch-Schutz, Pflicht-Reviews und Secret-Scanning aktiviert. In dieser Phase entstehen auch die ersten hochsignaligen Identity-Detections.

In den verbleibenden Wochen wird das Modell operationalisiert. Privilegierte Anwendungen dürfen nur noch von konformen, verwalteten Geräten erreicht werden, Sitzungsdauer und Re-Authentifizierung werden kontrolliert und ausgewählte Response-Aktionen wie Session-Revoke oder Rollenentzug getestet. Ein Tabletop- oder Dry-Run-Szenario prüft anschließend, ob Erkennung, Reaktion und Beweissicherung tatsächlich zusammenspielen. Am Ende stehen nicht nur technische Kontrollen, sondern auch Kennzahlen zur MFA-Abdeckung, Geräte-Compliance, JIT-Nutzung, Secrets-Vault-Abdeckung, Telemetrie-Vollständigkeit und Time to Revoke.

Marcel, vielen Dank für die Antworten! Einen Überblick über Minimum Viable Zero Trust gibt es in der neuen iX. Außerdem zeigen wir, wie man Mikrosegmentierung im Netzwerk angeht – und werfen einen Blick auf die drei Säulen der hybriden Infrastruktursicherheit. All das und viele weitere Themen finden Leser im August-Heft, das ab sofort im heise Shop oder am Kiosk erhältlich ist.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)