Sophos ZTNA einrichten: Überblick und Reihenfolge

Sophos Zero Trust Network Access, kurz ZTNA, ersetzt nicht einfach ein VPN durch einen neuen Button. ZTNA besteht aus Identität, Gateway, Ressourcen, Policies, DNS, Zertifikaten und einem Client- oder agentlosen Zugriffspfad. Wenn diese Bausteine in der falschen Reihenfolge eingerichtet werden, funktioniert die Anmeldung vielleicht, aber die Anwendung bleibt trotzdem unerreichbar.

Dieser Artikel ordnet die Einrichtung ein und zeigt die sinnvolle Reihenfolge. Für den konkreten Gateway-Teil passt zusätzlich Sophos ZTNA Gateway planen und erstellen.

Für die herstellerneutrale Grundlage zu Zero Trust, ZTNA und der Abgrenzung zu VPN passt zuerst Zero Trust einfach erklärt: ZTNA statt klassischem VPN.

Voraussetzungen

Vor einem ZTNA-Test sollten diese Punkte geklärt sein:

• Sophos Central Account mit passender ZTNA-Lizenz oder Testumgebung.
• Microsoft Entra ID, früher Azure AD, oder ein unterstützter Identity Provider mit gepflegten Benutzern und Gruppen.
• Entscheidung für agentlosen Zugriff, ZTNA Client oder gemischten Betrieb.
• Gateway-Modell: On-premise Gateway, Sophos Cloud Gateway oder Sophos Firewall als Gateway-Variante.
• DNS-Namen für Gateway und veröffentlichte Ressourcen.
• Wildcard-Zertifikat oder passendes Zertifikatskonzept.
• Interne Erreichbarkeit der Anwendungen aus Sicht des Gateways.
• Owner für Policies, Zertifikate, Logs und spätere Änderungen.

Sophos Central ZTNA aktivieren

Wenn ZTNA noch nicht aktiv ist, kann der Test über einen bestehenden oder neuen Sophos Central Account vorbereitet werden. Wichtig ist, dass der Tenant, die Benutzerquelle und die späteren Ressourcen zum geplanten Test passen. Ein ZTNA-Test ohne echte Zielanwendung sagt wenig über Latenz, DNS, Browsererlebnis oder Policy-Design aus.

Ein Einstieg über die Sophos-Testseite kann für erste Laborumgebungen sinnvoll sein: Sophos Central Testaccount erstellen.

Zertifikat und DNS planen

Für ZTNA wird ein Zertifikat benötigt, das zu den geplanten Gateway- und Ressourcen-Domains passt. In vielen Umgebungen ist ein Wildcard-Zertifikat die einfachste Variante, weil mehrere Ressourcen unter derselben Domain veröffentlicht werden können.

Für produktive Umgebungen sollte man Ablaufdatum, Erneuerung, Zuständigkeit und Monitoring des Zertifikats klären. Für Tests kann Let’s Encrypt praktisch sein, wenn noch kein passendes Wildcard-Zertifikat vorhanden ist. Der Ablauf steht in Let’s Encrypt Wildcard Zertifikat erstellen.

Einrichtungsreihenfolge

Für einen sauberen ZTNA-Rollout sollte die Reihenfolge nicht beliebig gewählt werden:

1. Verzeichnisdienst hinzufügen: Microsoft Entra ID oder einen anderen unterstützten Verzeichnisdienst mit Sophos Central synchronisieren.
2. Identitätsanbieter hinzufügen: Die für die Authentifizierung benötigten Identitätsanbieter einrichten.
3. Gateway hinzufügen: Pro Standort oder Datenpfad das passende Gateway-Modell planen und bereitstellen.
4. Ressourcen anlegen: Anwendungen mit FQDN, Port, Zugriffstyp und Erreichbarkeit definieren.
5. Richtlinien hinzufügen: Benutzergruppen, Bedingungen und erlaubte Ressourcen bewusst zuordnen.
6. Client- oder agentlosen Zugriff testen: Mit Pilotbenutzern prüfen, ob Anmeldung und Anwendung funktionieren.

1. Benutzer synchronisieren

Für ZTNA braucht Sophos Central Benutzer und Gruppen, die später in Policies verwendet werden. In Microsoft-Umgebungen ist Microsoft Entra ID der typische Einstieg. Entscheidend ist, dass nur die benötigten Gruppen verwendet werden und dass Namen, UPN, E-Mail-Adressen und Gruppenmitgliedschaften später nachvollziehbar sind.

Die Grundlage steht in Sophos Central Azure AD hinzufügen.

2. Identitätsanbieter hinzufügen

Nach dem Verzeichnisdienst wird der Identity Provider eingerichtet. Bei Microsoft Entra ID gehören dazu typischerweise Client ID, Tenant ID und Client secret. Diese Werte sind sicherheitsrelevante Konfigurationsdaten und sollten wie Zugangsdaten behandelt werden.

3. Gateway hinzufügen

Das ZTNA Gateway verbindet den Benutzerzugriff mit den internen Anwendungen. Je nach Design steht es als On-premise Gateway im eigenen Netz, wird über Sophos Cloud Gateway betrieben oder nutzt eine unterstützte Sophos-Firewall-Variante.

Die Gateway-Planung ist ein eigener Arbeitsschritt, weil DNS, Zertifikat, Netzwerksegment, DNAT, interne Erreichbarkeit und Logs zusammenpassen müssen. Der Ablauf steht in Sophos ZTNA Gateway planen und erstellen.

4. Ressourcen anlegen

Ressourcen sind die Anwendungen, die über ZTNA erreichbar sein sollen. Dafür sollte man pro Anwendung dokumentieren:

• interner FQDN oder interne Ziel-IP,
• Protokoll und Port,
• Zugriffstyp, zum Beispiel Web-App oder TCP-App,
• benötigte Benutzergruppe,
• gewünschter externer Name,
• Testbenutzer und Abnahmekriterium.

Eine Ressource sollte nicht breiter veröffentlicht werden als nötig. Gerade bei Admin-Tools, RDP, SSH oder internen Fachanwendungen braucht es klare Gruppen, Logging und einen Owner.

5. Richtlinien hinzufügen

Policies verbinden Benutzergruppen mit Ressourcen. In der Praxis sollte man mit einer kleinen Pilotgruppe beginnen und nicht sofort ganze Abteilungen oder alle Mitarbeitenden freischalten.

Gute Policy-Fragen:

• Welche Gruppe braucht diese Anwendung wirklich?
• Ist agentloser Zugriff ausreichend oder braucht es den ZTNA Client?
• Muss der Zugriff nach Gerät, Zustand oder Standort eingeschränkt werden?
• Wie wird geloggt und wer prüft Fehlversuche?
• Gibt es einen Rückfallweg, wenn ZTNA oder der Identity Provider gestört ist?

6. Zugriff testen

Nach der Einrichtung sollte nicht nur die Anmeldung getestet werden. Entscheidend ist, ob die reale Anwendung erreichbar ist und ob die Policy exakt so greift wie geplant.

Prüfpunkte:

• Testbenutzer ist in der richtigen Gruppe.
• DNS zeigt auf das erwartete Gateway oder den erwarteten CNAME.
• Zertifikat wird ohne Browserwarnung akzeptiert.
• Anmeldung am Identity Provider funktioniert.
• Die Ressource öffnet mit dem geplanten Zugriffstyp.
• Nicht berechtigte Benutzer werden nachvollziehbar abgewiesen.
• Logs in Sophos Central, Gateway und Firewall sind auswertbar.

Häufige Fehler

• Gateway, DNS und Zertifikat werden erst nach den Policies geprüft.
• Ressourcen werden zu breit veröffentlicht.
• Testbenutzer haben mehr Gruppenmitgliedschaften als normale Benutzer.
• Interne DNS-Auflösung funktioniert nur im LAN, aber nicht aus Sicht des Gateways.
• ZTNA wird als Ersatz für jede VPN- oder Admin-Verbindung geplant, obwohl manche Spezialfälle weiterhin VPN, Jump Host oder ein anderes Zugriffsmodell brauchen.