Zero Trust bedeutet dabei nicht, allen Benutzern grundsätzlich zu misstrauen. Jeder Zugriff wird vielmehr anhand überprüfbarer Signale freigegeben: Wer meldet sich an, mit welchem Gerät, an welcher Anwendung und unter welchen Risikobedingungen? Ein gültiges Kennwort allein reicht dann nicht mehr. Vor der Produktauswahl sollte das Unternehmen zuerst seine Benutzerkonten, Windows-Geräte, Anwendungen und besonders schützenswerten Administratorzugänge erfassen.
Welche Schutzaufgaben Zero-Trust-Software übernehmen muss
Eine tragfähige Zero-Trust-Architektur kontrolliert nicht nur den Weg ins Firmennetz. Sie entscheidet für jede Ressource, ob ein bestimmter Benutzer mit einem bestimmten Gerät darauf zugreifen darf. Dadurch verliert die klassische Unterscheidung zwischen internem und externem Netzwerk an Bedeutung.
Für Windows-PCs und Microsoft-Dienste sind fünf Funktionen maßgeblich:
- Identität und Anmeldung: Mehrstufige Authentifizierung, sichere Anmeldeverfahren und risikobasierte Entscheidungen erschweren den Missbrauch gestohlener Konten.
- Gerätezustand: Die Richtlinie berücksichtigt beispielsweise, ob ein Windows-PC verwaltet wird, Sicherheitsanforderungen erfüllt und die erwarteten Schutzfunktionen verwendet.
- Anwendungszugriff: Benutzer erhalten nur Zugriff auf die Anwendungen, die sie für ihre Aufgabe benötigen. Eine pauschale Verbindung mit dem gesamten internen Netz entfällt möglichst.
- Endpunkterkennung: Auffälliges Verhalten auf Windows-PCs muss erkannt und in Zugriffsentscheidungen einbezogen werden können.
- Protokollierung: Anmeldungen, Gerätebewertungen, Richtlinienentscheidungen und Sicherheitsereignisse müssen auswertbar sein.
Ein Produkt, das lediglich Mehrfaktor-Authentifizierung bereitstellt, ist daher noch keine vollständige Zero-Trust-Lösung. Dasselbe gilt für einen VPN-Dienst, eine Firewall oder eine Endpoint-Security-Software allein. Jedes dieser Werkzeuge kann ein Baustein sein, deckt aber nicht die gesamte Entscheidungskette ab.
Die geeigneten Lösungen im gemeinsamen Vergleich
Die folgenden Plattformen verfolgen unterschiedliche Ansätze. Ein fairer Vergleich muss sie nach denselben Fragen bewerten: Wie werden Identitäten eingebunden, wie wird der Gerätezustand berücksichtigt, welche Anwendungen lassen sich schützen, wie stark ist die Windows-Integration und welcher Betriebsaufwand entsteht? Produktnamen und Funktionsumfang können sich ändern; vor einer Beschaffung müssen deshalb die benötigten Funktionen in den offiziellen Produkt-, Lizenz- und Administrationsbereichen des jeweiligen Anbieters geprüft werden.
Microsoft Entra ID, Intune und Defender for Endpoint
Der Microsoft-Ansatz eignet sich besonders für Unternehmen, die Windows-PCs zentral verwalten und Microsoft 365 intensiv einsetzen. Microsoft Entra ID übernimmt Identitäten und Zugriffsentscheidungen. Microsoft Intune liefert Informationen zur Verwaltung und Konformität von Geräten. Microsoft Defender for Endpoint ergänzt die Erkennung und Reaktion auf Angriffe am Endgerät.
Der wesentliche Vorteil liegt in der Verbindung dieser Signale. Eine Zugriffsrichtlinie kann beispielsweise verlangen, dass ein Benutzer eine starke Anmeldung durchführt und ein verwaltetes, als konform bewertetes Gerät verwendet. Sicherheitsrisiken eines Endpunkts können ebenfalls Einfluss auf den Zugriff haben, sofern die eingesetzten Lizenzen und Integrationen dies abdecken.
- Identitäten: Sehr passend für Microsoft-Konten in Organisationen und hybride Identitätsumgebungen.
- Gerätezustand: Tief in die Verwaltung von Windows-Geräten integrierbar.
- Anwendungen: Besonders schlüssig für Microsoft 365, SaaS-Anwendungen und eingebundene Unternehmensanwendungen.
- Windows-Bezug: Unter den betrachteten Ansätzen am stärksten in die Microsoft-Verwaltungswelt eingebettet.
- Betriebsgrenze: Lizenzabhängigkeiten und mehrere Verwaltungsportale können Planung und Fehlersuche anspruchsvoll machen.
Diese Kombination ist keine automatische Komplettlösung für jedes interne Netzwerk. Ältere Anwendungen, nicht webfähige Protokolle, Produktionssysteme und Geräte ohne moderne Identität benötigen unter Umständen zusätzliche Zugriffskomponenten oder eine streng abgegrenzte Netzwerkzone.
Zscaler Private Access
Zscaler Private Access ist auf den anwendungsbezogenen Zugriff ausgerichtet. Benutzer werden nicht pauschal in ein Unternehmensnetz eingebucht, sondern mit freigegebenen privaten Anwendungen verbunden. Das kann die sichtbare Angriffsfläche gegenüber einem weitreichenden VPN-Zugang verringern.
- Identitäten: Einbindung vorhandener Identitätsanbieter und deren Anmeldesignale.
- Gerätezustand: Richtlinien können Endpunkt- und Gerätesignale berücksichtigen; die verfügbare Tiefe hängt von der eingesetzten Kombination ab.
- Anwendungen: Stärke beim Zugriff auf private Anwendungen in Rechenzentren und Cloud-Umgebungen.
- Windows-Bezug: Windows-Endgeräte lassen sich einbinden, die Plattform ist jedoch nicht auf das Microsoft-Ökosystem beschränkt.
- Betriebsgrenze: Anwendungen und Abhängigkeiten müssen sauber erfasst werden. Unbekannte Nebenverbindungen können bei der Umstellung zu Zugriffsfehlern führen.
Zscaler ist besonders interessant, wenn viele externe oder mobile Mitarbeiter auf interne Anwendungen zugreifen, ohne einen breit angelegten Netzwerkzugang erhalten zu sollen. Für reine Microsoft-365-Nutzung wäre eine solche private Anwendungszugriffsschicht allein dagegen keine vollständige Begründung.
Cloudflare Access
Cloudflare Access schützt Anwendungen über identitätsbezogene Richtlinien und lässt sich als Bestandteil einer breiteren Zero-Trust-Plattform einsetzen. Der Ansatz ist vor allem für webbasierte interne Anwendungen, SaaS-Zugänge und verteilte Infrastrukturen geeignet. Nicht jede ältere Client-Server-Anwendung lässt sich gleich einfach in dieses Modell überführen.
- Identitäten: Arbeitet mit externen Identitätsanbietern und zentralen Zugriffsregeln.
- Gerätezustand: Geräteinformationen können je nach eingesetztem Client und angebundener Verwaltung in Entscheidungen einfließen.
- Anwendungen: Besonders passend für webbasierte Dienste und veröffentlichte interne Anwendungen.
- Windows-Bezug: Windows-Geräte werden unterstützt, ohne eine ausschließlich auf Windows ausgerichtete Verwaltungsplattform vorauszusetzen.
- Betriebsgrenze: Nicht webfähige Anwendungen, spezielle Protokolle und komplexe Netzwerkabhängigkeiten brauchen eine gesonderte Prüfung.
Cloudflare Access kommt häufig dann infrage, wenn ein Unternehmen schnell identitätsbasierte Regeln vor interne Webanwendungen setzen möchte oder bereits Dienste der Plattform nutzt. Ob es auch den gesamten privaten Anwendungsverkehr abdecken kann, muss anhand der tatsächlich verwendeten Protokolle geprüft werden.
Palo Alto Prisma Access
Palo Alto Prisma Access verbindet cloudbereitgestellte Netzwerk- und Sicherheitsfunktionen. Der Ansatz passt zu Unternehmen, die Zugriffssteuerung, Datenverkehrskontrolle und bestehende Sicherheitsrichtlinien über Standorte, mobile Benutzer und Cloud-Umgebungen hinweg zusammenführen wollen.
- Identitäten: Identitätsinformationen können in Zugriffs- und Sicherheitsregeln einbezogen werden.
- Gerätezustand: Endpunktinformationen und die Einbindung ergänzender Komponenten ermöglichen abgestufte Entscheidungen.
- Anwendungen: Geeignet für privaten und internetgerichteten Datenverkehr in komplexeren Unternehmensumgebungen.
- Windows-Bezug: Windows-Clients sind ein wichtiger Einsatzfall, der Schwerpunkt liegt jedoch auf einer übergreifenden Sicherheitsarchitektur.
- Betriebsgrenze: Die Plattform verlangt fundierte Richtlinienplanung; für kleine Umgebungen kann das Betriebsmodell zu umfangreich sein.
Besonders naheliegend ist diese Lösung, wenn bereits Palo-Alto-Infrastruktur und entsprechendes Betriebswissen vorhanden sind. Eine vorhandene Firewall-Landschaft allein sollte aber nicht die Auswahl bestimmen. Entscheidend ist, ob Anwendungen, Identitäten und Endpunkte mit vertretbarem Aufwand in ein einheitliches Regelmodell überführt werden können.
Cisco Duo
Cisco Duo setzt einen starken Schwerpunkt auf Anmeldung, Mehrfaktor-Authentifizierung und Gerätevertrauen. Die Lösung kann den Zugang zu Anwendungen deutlich besser absichern, ersetzt aber nicht automatisch eine vollständige Segmentierungs-, Endpoint- und Netzwerksicherheitsplattform.
- Identitäten: Gut geeignet, um Anmeldungen mit zusätzlichen Faktoren und Richtlinien abzusichern.
- Gerätezustand: Geräteinformationen können für Zugriffsentscheidungen herangezogen werden, abhängig von Bereitstellung und Funktionsumfang.
- Anwendungen: Breite Einsatzmöglichkeiten an Anmeldepunkten und bei angebundenen Diensten.
- Windows-Bezug: Kann Windows-Anmeldungen und Zugänge zu Unternehmensdiensten ergänzen.
- Betriebsgrenze: Für umfassende Netzwerksegmentierung, Endpunkterkennung und Sicherheitsanalyse sind weitere Komponenten nötig.
Duo ist sinnvoll, wenn die größte unmittelbare Lücke bei Anmeldungen und Mehrfaktor-Authentifizierung liegt. Als alleinige Antwort auf seitliche Bewegungen eines Angreifers innerhalb des Unternehmensnetzes reicht dieser Schwerpunkt nicht aus.
Welche Lösung zu welcher Windows-Umgebung passt
Ein universeller Sieger wäre irreführend, weil die Produkte verschiedene Ebenen abdecken. Die Auswahl lässt sich stattdessen über die vorhandene Systemlandschaft eingrenzen.
- Windows 11, Microsoft 365 und zentrale Geräteverwaltung dominieren: Entra ID, Intune und Defender for Endpoint bilden einen eng verzahnten Ausgangspunkt. Prüfe zuerst vorhandene Microsoft-Lizenzen, registrierte Geräte und die Verfügbarkeit der benötigten Richtlinien.
- Interne Anwendungen sollen ohne weitreichenden VPN-Zugang erreichbar sein: Zscaler Private Access ist ein naheliegender Kandidat. Cloudflare Access kommt besonders bei webbasierten Anwendungen infrage.
- Standorte, mobile Benutzer und Cloud-Datenverkehr sollen unter einem Netzwerk-Sicherheitsmodell zusammenlaufen: Prisma Access ist für eine umfassendere Architektur ausgelegt, setzt aber entsprechendes Know-how voraus.
- Unsichere oder uneinheitliche Anmeldungen sind das dringendste Problem: Cisco Duo kann eine schnelle Verbesserung bewirken. Weitere Bausteine bleiben für Endpunkterkennung und Segmentierung erforderlich.
- Viele Altanwendungen und Spezialprotokolle sind vorhanden: Beginne nicht mit einer flächendeckenden Abschaltung des VPN. Erfasse zuerst Verbindungen, Ports, Dienstkonten und Abhängigkeiten und migriere Anwendung für Anwendung.
Mehrere Produkte können zusammen eingesetzt werden, doch überlappende Funktionen erhöhen den Aufwand. Zwei parallele Endpunkt-Clients, widersprüchliche Gerätezustände oder voneinander getrennte Richtlinienmodelle erschweren die Fehlersuche. Jede zusätzliche Plattform sollte daher eine klar benannte Lücke schließen.
Eine belastbare Auswahl beginnt mit Zugriffswegen statt Produktnamen
Vor einem Testbetrieb sollte das Unternehmen drei bis fünf repräsentative Zugriffswege auswählen. Dazu gehören beispielsweise ein verwalteter Windows-11-PC mit Microsoft 365, ein externer Zugriff auf eine interne Webanwendung, ein Administratorzugang und ein älteres Fachverfahren. So lässt sich prüfen, ob die Plattform nicht nur eine Präsentation, sondern den tatsächlichen Arbeitsablauf abbildet.
- Ressource festlegen: Bestimme eine Anwendung und die darin schützenswerten Daten. Ein vollständiges Netzwerksegment ist als erster Test meist zu grob.
- Identitäten zuordnen: Lege fest, welche Benutzergruppe und welche administrativen Rollen zugreifen dürfen. Gemeinsame Konten sollten nicht als Normalfall eingeplant werden.
- Geräteanforderungen definieren: Entscheide, ob nur verwaltete Windows-PCs zugelassen werden oder ob private Geräte einen eingeschränkten Browserzugriff erhalten.
- Störungsszenarien testen: Prüfe ein nicht konformes Gerät, eine fehlgeschlagene Mehrfaktor-Anmeldung und den Ausfall einer Verbindungskomponente. Eine Ablehnung muss verständlich protokolliert werden.
- Rückweg vorbereiten: Für den Pilotbetrieb braucht es eine zeitlich begrenzte Ausnahme oder den vorherigen Zugangsweg, damit ein Richtlinienfehler nicht den Geschäftsbetrieb blockiert.
Ein erfolgreicher Test besteht nicht nur darin, dass berechtigte Benutzer Zugriff erhalten. Ebenso wichtig ist die Gegenprobe: Ein unbekanntes oder nicht konformes Gerät darf die geschützte Anwendung nicht auf demselben Weg erreichen. Im Protokoll muss erkennbar sein, welche Bedingung zur Freigabe oder Ablehnung geführt hat.
Windows-Geräte liefern nur mit sauberer Verwaltung brauchbare Signale
Eine Zugriffsregel ist nur so zuverlässig wie die zugrunde liegenden Gerätedaten. Ein als verwaltet registrierter PC ist nicht automatisch sicher, und ein fehlendes Signal beweist nicht zwingend einen Angriff. Registrierungsstatus, Richtlinienübernahme, Endpoint-Sensor und Uhrzeit müssen zusammenpassen.
Auf einem Pilotgerät sollte die IT deshalb prüfen, ob der PC dem erwarteten Verzeichnis und der vorgesehenen Geräteverwaltung zugeordnet ist. Unter Windows lassen sich die grundlegenden Registrierungsinformationen mit einem auslesenden Befehl anzeigen:
dsregcmd /statusDer Befehl verändert das System nicht. Die Ausgabe enthält verschiedene Bereiche zum Geräte- und Benutzerstatus. Welche Einträge erwartet werden, hängt vom gewählten Bereitstellungsmodell ab; ein lokal eingebundener PC, ein Microsoft-Entra-verbundenes Gerät und eine hybride Konfiguration zeigen unterschiedliche Zustände. Die Ausgabe sollte nicht unbereinigt weitergegeben werden, weil sie organisations- und gerätebezogene Angaben enthalten kann.
Zusätzlich muss im jeweiligen Verwaltungsportal sichtbar sein, ob das Gerät zuletzt eingecheckt hat und welche Konformitätsregel greift. Wird ein berechtigter Benutzer abgewiesen, lautet die richtige Reihenfolge: zuerst Richtlinienprotokoll lesen, dann Geräteobjekt und Endpunktstatus kontrollieren und erst danach die Zugriffsregel ändern. Eine pauschale Ausnahme würde zwar den Zugriff wiederherstellen, aber zugleich die Aussagekraft des Zero-Trust-Modells schwächen.
Typische Fehlentscheidungen bei der Einführung
Die häufigste Fehlentscheidung ist der Kauf einer Plattform, bevor bekannt ist, welche Anwendungen geschützt werden sollen. Danach folgen drei Probleme: Richtlinien bleiben zu weit gefasst, Altanwendungen werden übersehen und Administratoren erhalten dauerhafte Ausnahmen.
Auch eine sofortige Pflicht zur Mehrfaktor-Authentifizierung für sämtliche Konten kann ohne Vorbereitung Betriebsstörungen auslösen. Dienstkonten, Notfallzugänge, Geräte ohne interaktive Anmeldung und ältere Protokolle müssen vorher identifiziert werden. Das Ziel ist nicht, diese Konten dauerhaft auszunehmen, sondern für jeden Sonderfall einen kontrollierten Ersatz oder eine enge technische Begrenzung festzulegen.
Ein weiterer Irrtum besteht darin, Zero Trust mit lückenloser Überwachung gleichzusetzen. Viele Protokolle erzeugen noch keine gute Entscheidung. Nützlich sind Ereignisse, die Benutzer, Gerät, Anwendung, Richtlinie und Ergebnis miteinander verbinden. Fehlt diese Beziehung, wächst lediglich die Datenmenge.
Abbruchgrenzen und sichere Einführung
Eine Zugriffsrichtlinie darf nicht organisationsweit aktiviert werden, solange ihre Auswirkungen nur vermutet werden. Microsoft-Umgebungen und andere Plattformen bieten je nach Produkt Möglichkeiten zur Auswertung, Simulation oder schrittweisen Zuweisung. Die Bezeichnung und Verfügbarkeit solcher Funktionen muss im jeweiligen Administrationsbereich geprüft werden.
Der Rollout sollte gestoppt werden, wenn Ablehnungen nicht eindeutig einer Richtlinie zugeordnet werden können, Notfallkonten vom selben Mechanismus abhängig sind oder geschäftskritische Anwendungen keinen getesteten Rückweg besitzen. Ebenso ist eine fachkundige Planung nötig, wenn industrielle Systeme, medizinische Geräte, stark regulierte Daten oder nicht mehr unterstützte Betriebssysteme betroffen sind.
Eine tragfähige Entscheidung lautet daher selten Microsoft gegen Zscaler, Cloudflare, Palo Alto oder Cisco. Sie lautet vielmehr: Welche Plattform kontrolliert in der vorhandenen Umgebung Identitäten und Windows-Geräte am zuverlässigsten, welche Lösung begrenzt den Zugriff auf private Anwendungen und wo bleiben erkennbare Lücken? Für Microsoft-zentrierte Unternehmen ist der Microsoft-Stack meist der sinnvollste Kern. Zusätzliche ZTNA- oder Netzwerksicherheitsplattformen sollten gezielt dort hinzukommen, wo private Anwendungen, mehrere Clouds, Standorte oder spezielle Datenverkehrskontrollen über diesen Kern hinausgehen.
