Sophos ZTNA einrichten: vollständiges Setup-Runbook

Sophos Zero Trust Network Access, kurz ZTNA, steuert den Zugriff auf interne Anwendungen und Webseiten über Identität, Gruppen und Richtlinien. Für ein vollständiges Setup benötigt man einen Verzeichnisdienst, einen Identity Provider, ein Gateway, ein Zertifikats- und DNS-Konzept, Policies und Ressourcen. Der native Zugriff auf lokale Anwendungen nutzt den ZTNA-Agenten; Webanwendungen können agentenlos bereitgestellt werden. Zusätzlich besteht ein separater agentenloser RDP-/SSH-Pfad über den vollständigen Protected Browser mit eigenen Ressourcen und Policies. Die Browser-Erweiterung genügt dafür nicht; eine allgemeine Freigabe beliebiger lokaler Protokolle ist daraus nicht abzuleiten.

Dieses Runbook beschreibt die Gesamtarchitektur und die richtige Einrichtungsreihenfolge. Es ersetzt weder die Detailplanung eines Gateways noch Spezial-Runbooks für Domain Controller, RDP oder SSH. Man beginnt mit genau einer Anwendung, einer Pilotgruppe und einem dokumentierten Rückweg. Erst wenn der Positiv- und Negativtest stimmen, erweitert man den Umfang.

Direkte Antwort: die richtige Reihenfolge

Man richtet Sophos ZTNA in dieser Reihenfolge ein:

1. Lizenz, Administratorzugriff, Plattformen und Zielanwendung prüfen.
2. Zugriffsart und Gateway-Modus festlegen.
3. Benutzer und Sicherheitsgruppen aus Microsoft Entra ID oder Active Directory synchronisieren.
4. Identity Provider einrichten und dessen Verbindung testen.
5. Wildcard-Zertifikat, Domain und Gateway bereitstellen.
6. Öffentliche und private DNS-Auflösung konfigurieren.
7. Eine kleine ZTNA-Policy erstellen.
8. Den ZTNA-Agenten nur dort ausrollen, wo der Zugriffstyp ihn benötigt.
9. Ressource mit genau einer Policy und den vorgesehenen Gruppen anlegen.
10. Berechtigten und nicht berechtigten Zugriff sowie Logs testen.
11. Erst danach weitere Benutzer, Anwendungen und Standorte migrieren.

Sophos Fusion ist dabei die Verwaltungsebene. Gateway, Agent, Verzeichnisdienst, Identity Provider, Zertifikat, DNS, Policy und Ressource bleiben getrennte technische Abhängigkeiten. Eine erfolgreiche Anmeldung beweist deshalb noch nicht, dass die Anwendung erreichbar oder richtig eingeschränkt ist.

Voraussetzungen, Lizenz und Rollen

Lizenz und Testbetrieb

Sophos ZTNA ist Bestandteil von Sophos Workspace Protection. Die Lizenz ist als eigenständige Laufzeitlizenz, über MSP Flex oder im Paket Sophos Endpoint Plus Workspace Protection erhältlich. Bei Workspace Protection richtet sich die erforderliche Anzahl nach dem höchsten Verbrauch der enthaltenen Produkte; für ZTNA zählen eindeutige authentifizierte Benutzer innerhalb von 30 Tagen. Derselbe Lizenztyp deckt agentenbasierten und agentenlosen Zugriff sowie lokale und Sophos Cloud Gateways ab.

Die eigenständige Workspace-Protection-Lizenz enthält keine Sophos-Endpoint-Lizenz. Für agentenbasierten Zugriff benötigt man deshalb zusätzlich eine passende Endpoint-Berechtigung und die Möglichkeit, den Sophos Endpoint Agent zu installieren. Das ist unabhängig davon, dass die ZTNA-Lizenz selbst beide Zugriffsmethoden abdeckt.

Für Sophos Cloud Gateway gilt zusätzlich ein durchschnittliches Übertragungslimit von 15 GB pro Benutzer und Monat. Eine Testlizenz läuft regulär 30 Tage. In einem Test-Tenant sind pro Objekttyp höchstens 1.000 Einträge möglich, beispielsweise Benutzer, Gruppen oder Geräte. Nach dem Lizenzablauf sind die Workspace-Protection-Produkte in Sophos Fusion nicht verfügbar; die Konfiguration bleibt erhalten und erscheint nach einer Verlängerung wieder.

Man aktiviert und kontrolliert die Lizenz über das Profilsymbol > Licensing. Für einen strukturierten Test verwendet man Sophos Fusion Trial starten und sicher auswerten.

Zuständigkeiten

Vor Änderungen müssen mindestens diese Rollen geklärt sein:

• Sophos-Fusion-Administrator: darf Verzeichnisquellen, Identity Provider, Gateways, Policies und Ressourcen konfigurieren. Für das Einrichten einer AD-Verzeichnisquelle ist ein Administrator der Sophos-Central-Verwaltungskonsole erforderlich.
• Identity-Administrator: erstellt App-Registrierung, Client Secret, Gruppen, Redirect-URIs und gegebenenfalls Gastkonten beim Identity Provider.
• DNS- und Zertifikatsverantwortlicher: kann öffentliche und interne DNS-Einträge setzen, Domainbesitz bestätigen und Zertifikate erneuern.
• Netzwerk- oder Firewall-Administrator: stellt Routing, ausgehende Verbindungen, NAT und Firewall-Freigaben für den gewählten Gateway-Modus bereit.
• Application Owner: kennt internen FQDN oder Ziel-IP, Ports, Authentifizierung, Redirects und das fachliche Abnahmekriterium.
• Endpoint-Verantwortlicher: verteilt den Sophos Endpoint Agent mit ZTNA-Komponente und prüft unterstützte Betriebssysteme.

Man speichert Client Secrets, Bind-Kennwörter und private Schlüssel nicht im Ticket oder Runbook. Man dokumentiert stattdessen Owner, Ablageort, Ablaufdatum und Rotationsprozess.

Technische Vorprüfung

Man prüft vor dem ersten Klick:

• Gateway-Host: VMware ESXi 6.5 oder höher beziehungsweise Hyper-V auf Windows Server 2016 oder höher. Für beide nennt Sophos mindestens 2 CPU-Kerne, 4 GB RAM und 80 GB Speicher; SSD wird empfohlen. Datum und Uhrzeit müssen stimmen, die Zeitzone muss UTC sein.
• Sophos Firewall als Gateway: SFOS 19.5 MR3 oder höher und Verwaltung durch Sophos Fusion. Hardware-, Cloud-, virtuelle und Software-Firewalls werden unterstützt. Einzelne neuere Funktionen können eine höhere SFOS-Version benötigen.
• Zertifikat: Wildcard-Zertifikat von Let’s Encrypt oder einer vertrauenswürdigen CA. Unterstützt werden RSA ab 2048 Bit und ECDSA, jedoch nicht P-384 oder P-521.
• Verzeichnis: Microsoft Entra ID oder lokales Active Directory mit gepflegten Gruppen. Entra-Gruppen für ZTNA müssen sicherheitsaktiviert sein.
• Identity Provider: Microsoft Entra ID, Okta oder lokales Active Directory.
• Agent-Plattform: Windows 10 1803 oder höher beziehungsweise macOS 11 Big Sur oder höher.
• Anwendung: statische, bekannte Ports. Anwendungen mit dynamischer Portzuweisung oder sehr grossen Portbereichen, etwa ältere VoIP-Produkte, werden nicht unterstützt.
• Netzwerk: interne Erreichbarkeit und private Namensauflösung vom Gateway zur Anwendung. Für lokale Gateways müssen zusätzlich die von Sophos geforderten Ziele ausgehend erreichbar sein; SSL/TLS-Inspection darf die erforderlichen Gateway-Verbindungen nicht aufbrechen.

Für die Gateway-Architektur, Dimensionierung und Netzfreigaben folgt Sophos ZTNA Gateway planen und erstellen.

Beispielwerte für dieses Runbook

Man ersetzt alle Werte durch die eigenen Umgebungswerte. Man vermischt Test- und Produktionsdomains nicht.

1. Zugriffspfad und Gateway-Modus wählen

Agentenlos oder mit Agent

Die folgende Tabelle vergleicht den klassischen agentenlosen Webzugriff mit dem nativen Zugriff über den ZTNA-Agenten. Der separate Bereitstellungsfall mit vollständigem Protected Browser folgt darunter:

Der hier beschriebene klassische agentenlose Webzugriff steuert Webanwendungen und Webseiten; er bewertet den Gerätezustand nicht. Eine agentenbasierte Policy kann den Sicherheitszustand prüfen und alle unterstützten Ressourcentypen beschränken. Agentenbasierte Policies und Ressourcen funktionieren erst, wenn die ZTNA-Komponente auf den Geräten installiert ist.

Der vollständige Protected Browser und dessen Erweiterung sind nicht gleichwertig: Die Erweiterung in einem anderen Browser bewertet den Endpoint-Integritätsstatus nicht. Bedingungen zum Endpoint-Schutz gelten deshalb nur für Traffic des vollständigen Protected Browser. Agentenlose RDP- und SSH-Sitzungen über Protected Browser sind eigene Bereitstellungsfälle; dafür legt man eine agentenlose ZTNA-Policy, eine eng begrenzte Ressource sowie die zugehörigen Protected-Browser-Objekte an. Man kopiert nicht unbesehen eine Web-App-Policy auf administrative RDP- oder SSH-Ziele.

Lokales Gateway oder Sophos Cloud Gateway

• Lokales Gateway: Die virtuelle Appliance steht im eigenen Rechenzentrum und ist aus dem Internet erreichbar. Man verwaltet die Instanz und benötigt passende Firewall-Ports und NAT-Regeln.
• Sophos Cloud Gateway: Sophos betreibt die Cloud-Datenebene. Eine Gateway-Instanz im Rechenzentrum verbindet diese Ebene mit den internen Ressourcen; direkte Internetexposition, eingehende Portfreigaben und NAT-Regeln für den Zugriffsweg entfallen.

Die Modi sind austauschbar, eine Migration ist möglich. Man behandelt sie trotzdem wie eine kontrollierte Änderung: DNS, Zertifikat, PoP, externe Namen und Tests müssen zum neuen Datenpfad passen.

Man wählt beim Cloud-Modus den Point of Presence (PoP) in der Nähe des Rechenzentrums, nicht automatisch in der Nähe der Benutzer. Verfügbar sind Regionen in Irland, Frankfurt, Ohio, Oregon, Mumbai und Sydney. Ab ZTNA 2.1 wird standardmässig ein benachbarter sekundärer PoP eingerichtet und für automatisches Failover verwendet. Den PoP ändert man unter Meine Produkte > ZTNA > Gateways, indem man das Gateway öffnet, Edit wählt, unter Points of Presence die Region ändert und speichert.

2. Verzeichnisdienst und Gruppen vorbereiten

ZTNA autorisiert anhand synchronisierter Benutzergruppen. Man legt deshalb zuerst eine kleine, sicherheitsaktivierte Pilotgruppe an und nimmt nur den erlaubten Testbenutzer auf. Ein zweiter Benutzer ausserhalb der Gruppe ist für den Negativtest erforderlich.

Microsoft Entra ID synchronisieren

Die bestehende Schritt-für-Schritt-Anleitung Microsoft Entra ID mit Sophos Fusion synchronisieren bleibt der Detail-Owner. Für ZTNA sind insbesondere diese Punkte wichtig:

1. Man registriert die ZTNA-Anwendung in Entra ID.
2. Man hinterlegt für ESXi- und Hyper-V-Gateways https://<gateway-fqdn>/oauth2/callback, für Sophos-Firewall-Gateways https://<gateway-fqdn>/ztna-oauth2/callback als Redirect-URI. Mehrere Gateway-FQDNs sind möglich.
3. Man erfasst Client-ID, Tenant-ID und den Wert des Client secret direkt bei der Erstellung. Der Secret-Wert kann später nicht erneut angezeigt werden.
4. Man erteilt nur die benötigten Microsoft-Graph-Berechtigungen und die erforderliche Admin-Zustimmung.
5. Man erstellt oder wählt sicherheitsaktivierte Gruppen. Aus dem Microsoft-365-Portal oder aus AD importierte Gruppen muss man darauf ausdrücklich prüfen.
6. Man öffnet in Sophos Fusion Globale Einstellungen > Verzeichnisdienst beziehungsweise Zugriffskontrolle > Anmeldung & Identität und fügt Microsoft Entra ID hinzu.
7. Man konfiguriert Domain, Client-ID, Client secret, dessen Gültigkeitsdauer sowie den Zeitplan Stündlich, Täglich, Wöchentlich, Monatlich oder Keine.
8. Man filtert die zu synchronisierenden Benutzer und Gruppen auf den tatsächlich benötigten Umfang. Man speichert und prüft das Ergebnis unter Meine Umgebung > Benutzer und Gruppen.

Eine Synchronisierung mehrerer Entra-ID-Quellen aus derselben Domain ist nicht möglich. Office 365 GCC High wird für diese Synchronisierung nicht unterstützt. Wenn UPN und Endpoint-Anmeldung nicht übereinstimmen, können doppelte oder nicht verknüpfte Benutzer entstehen. Benennt man eine bereits zugewiesene Entra-Gruppe später um, wird der Name in der Zuweisung nicht automatisch aktualisiert; dann weist man die Gruppe erneut zu.

Lokales Active Directory synchronisieren

Für AD lädt man unter Globale Einstellungen > Verzeichnisdienst das Active Directory Synchronization Setup herunter. Voraussetzungen sind .NET Framework 4.6.2 auf dem Sync-Computer, Sophos-API-Zugangsdaten mit der Rolle Service Principal Directory Sync nach englischer AD-Sync-Hilfe, eindeutige Benutzer und E-Mail-Adressen sowie die erforderlichen Firewall- oder Proxy-Freigaben. Die deutsche Setup-Hilfe nennt Service Principal Active Directory Sync; den AD-Sync-Rollenhinweis mit der tatsächlichen Tenant-Rolle abgleichen, ohne daraus identische Rollen-IDs oder zusätzliche Rechte abzuleiten.

1. Man validiert Client-ID und Client Secret im Setup-Programm.
2. Man verwendet für LDAP ein Konto mit Lesezugriff auf die Gesamtstruktur und so wenig Rechten wie möglich.
3. Man lässt LDAP über SSL-Verbindung verwenden nach Möglichkeit aktiv. Üblich sind Port 636 für LDAPS und Port 389 für eine ungesicherte Verbindung.
4. Man wählt Benutzer und Benutzergruppen gemeinsam aus. Dasselbe gilt für Geräte und Gerätegruppen.
5. Man begrenzt den Scope mit Base Distinguished Names und LDAP-Filtern, zum Beispiel OU=Finance,DC=example,DC=net.
6. Man führt nach der Einrichtung oder Filteränderung zunächst eine manuelle Vorschau und Synchronisierung aus. Eine manuelle Synchronisierung kann bis zu 15 Minuten dauern.

Man synchronisiert Benutzer und Gruppen derselben Domain nicht gleichzeitig aus AD und Entra ID. Primäre AD-Benutzergruppen werden für ZTNA nicht synchronisiert; betroffene Benutzer müssen zusätzlich Mitglied einer anderen AD-Gruppe sein. Änderungen an Base DN oder Filtern können zuvor importierte Objekte aus dem Suchbereich entfernen und damit in Sophos Fusion löschen. Man entfernt inaktive Konten im Quellverzeichnis, statt sie nur aus der Synchronisierung auszublenden.

Gastzugriff

Für externe Benutzer kann Microsoft Entra B2B eingesetzt werden. Man prüft vorab, ob der Tenant externe Zusammenarbeit zulässt, welche Domain eingeladen werden darf und wer Einladungen genehmigt. Gäste können einzeln oder in einer kontrollierten Batch-Aktion hinzugefügt werden. Man erstellt eine eigene Gastgruppe, synchronisiert sie nach Sophos Fusion und weist nur die benötigten Ressourcen zu. Der Application Owner muss Austrittsdatum und Sponsor jedes Gastkontos kennen.

Einzelnen Benutzer manuell anlegen

Wenn ein Benutzer nicht aus einem Verzeichnis synchronisiert wird, öffnet man Meine Umgebung > Benutzer und Gruppen, wählt Benutzer hinzufügen und erfasst Vor- und Nachname, E-Mail-Adresse und bei Bedarf Rolle, Manager, Exchange-Login sowie Zu Gruppen hinzufügen (optional). Man weist eine Administratorrolle nur zu, wenn sie wirklich benötigt wird; die Rolle Benutzer gewährt nur Zugriff auf das Self-Service-Portal. Man aktiviert E-Mail-Einrichtungslink nur, wenn der Benutzer ein eigenes Gerät schützen soll und dafür lokale Administratorrechte sowie Internetzugang besitzt. Man speichert und prüft, dass der Benutzer in der Liste und – falls gewählt – in der vorgesehenen ZTNA-Gruppe erscheint. Fehlt er, prüft man zuerst E-Mail-Adresse, Gruppenfilter und ob stattdessen der Verzeichnisdienst die führende Quelle sein muss.

3. Identity Provider einrichten

Man öffnet Sophos Central > My Products > ZTNA > Identity providers > Add identity provider beziehungsweise Meine Produkte > ZTNA > Identitätsanbieter. Pro Identity Provider ist nur ein Eintrag möglich. Man vermeidet Sonderzeichen wie ., @ oder # im Namen, da sich die Konfiguration sonst möglicherweise nicht speichern lässt.

Microsoft Entra ID

1. Man wählt Microsoft Entra ID (Azure AD).
2. Man trägt Name, Beschreibung, Client-ID, Tenant-ID und Client secret ein.
3. Man testet die Verbindung.
4. Man speichert erst nach erfolgreichem Test.

Lokales Active Directory

1. Man wählt Microsoft AD (on-prem).
2. Man erfasst Host und Port des primären AD-Servers, optional einen sekundären Server derselben Domain.
3. Man aktiviert TLS oder StartTLS. Wenn man Verify SSL certificate wählt, lädt man ein Zertifikat im Format .pem, .crt oder .cer bis maximal 10 KB hoch.
4. Man trägt Bind DN, Bind-Kennwort sowie die Base DN für Benutzer und Benutzergruppen ein.
5. Optional kann man Captcha und ein E-Mail-basiertes Einmalkennwort mit SMTP-Konfiguration aktivieren.
6. Man weist den Identity Provider einem Gateway zu. Man öffnet danach den Provider erneut, wählt unter Test Connection das Gateway und optional einen Benutzernamen. Der Test zeigt bei einem angegebenen Benutzer auch dessen Gruppen.

Für AD als Identity Provider muss ein ESXi- oder Hyper-V-Gateway mindestens ZTNA 2.1 verwenden; auf Sophos Firewall ist mindestens SFOS 19.5 MR3 erforderlich. Das E-Mail-Feld des Testbenutzers muss gültig sein. ZTNA unterstützt in diesem Szenario nur eine Domain, nicht mehrere Child Domains in einem Forest. Bei lokalem AD müssen sich Benutzer am ersten Zugriff auf Ressourcen hinter jedem Gateway authentifizieren und können jeweils nur auf einem Gerät authentifiziert sein.

Okta

Für Okta benötigt man synchronisierte Gruppen und einen OIDC-Autorisierungsserver. Das Gateway muss mindestens Version 1.1 verwenden. Man erstellt in Okta eine OIDC-Webanwendung, aktiviert Client Credentials und Refresh Token, verwendet den passenden Callback-Pfad und weist die Gruppen zu. Man erfasst danach Client-ID, Client Secret und Issuer URI in ZTNA. Bei einem eigenen Okta-Autorisierungsserver ist eine API-Access-Management-Lizenz erforderlich.

Verbundanmeldung für Sophos Fusion

Die Verbundanmeldung der Sophos-Fusion-Verwaltung ist ein eigener Kontrollpfad und nicht mit dem ZTNA-Identity-Provider oben gleichzusetzen. Man benötigt Superadmin-Rechte und muss die Anmeldedomain zuerst unter Zugriffskontrolle > Anmeldung & Identität > Sophos-Anmeldung mit dem dort erzeugten TXT-Eintrag verifizieren. Man öffnet danach Zugriffskontrolle > Anmeldung und Identität > Verbundidentitätsanbieter und wählt Identitätsanbieter hinzufügen:

1. Man erfasst Name und Beschreibung ohne Sonderzeichen wie ., @ oder #.
2. Man wählt Microsoft Entra ID, OpenID Connect oder Microsoft AD FS. Für Entra ID benötigt man die Tenant-ID, für OIDC Client-ID, Aussteller, Autorisierungs-Endpoint und JWKS-URL, für AD FS die Metadaten-URL.
3. Man ordnet die verifizierte Domain zu. Mehrere Domains sind möglich, ein Benutzer darf aber nur einer Domain zugeordnet sein.
4. Man wählt bewusst Vom IdP erzwungene MFA oder Keine vom IdP erzwungene MFA. Bei der zweiten Option erzwingt Sophos Fusion MFA nach erfolgreicher IdP-Authentifizierung.
5. Man speichert und aktiviert den Provider. Er lässt sich bei unvollständigen oder ungültigen Angaben nicht aktivieren.

Man aktiviert die Verbundanmeldung erst, wenn alle betroffenen Administratoren und Benutzer einer Domain zugeordnet sind und einen passenden Identity Provider besitzen. Man testet vorher mit einem begrenzten Administratorkonto in einem privaten Browserfenster und hält eine funktionierende Superadmin-Sitzung als Rückweg offen. Schlägt der Test fehl, deaktiviert man den neuen Provider in dieser Sitzung und prüft Domainzuordnung, Endpoints, Zertifikatsvertrauen und MFA-Auswahl.

4. Gateway, Domains und Zertifikat bereitstellen

Man plant und erstellt das Gateway gemäss Sophos ZTNA Gateway planen und erstellen. Man verwendet für mehrere Ressourcen unter derselben Domain ein Wildcard-Zertifikat. Für Let’s Encrypt steht Let’s Encrypt Wildcard Zertifikat erstellen bereit.

Für den von Sophos Fusion verwalteten Let’s-Encrypt-Weg öffnet man Meine Produkte > ZTNA > Einstellungen > Domänen und Zertifikate und wählt Domäne hinzufügen. Fusion erzeugt einen CNAME für _acme-challenge.<domain>. Man veröffentlicht Namen und Ziel exakt im öffentlichen DNS, lässt diesen CNAME für spätere Erneuerungen bestehen und wählt danach Verifizieren. Der Status muss auf verifiziert wechseln. Man übernimmt das generierte Ziel vollständig; je nach DNS-Anbieter ist ein abschliessender Punkt nötig, damit keine eigene Domain angehängt wird. Wurde eine bestehende Domain früher mit TXT validiert, stellt man sie vor der Erzeugung des verwalteten Zertifikats auf den aktuellen CNAME um. Nach jeder neu hinzugefügten Domain muss man das einzige verwaltete Zertifikat des Accounts neu generieren, damit die Domain aufgenommen wird.

Davon getrennt ist der manuelle Certbot-DNS-Challenge-Weg für ein eigenes Wildcard-Zertifikat: Nur dort veröffentlicht man den von Certbot verlangten TXT-Wert. Man lädt anschliessend Zertifikat, vollständige Kette und privaten Schlüssel hoch und prüft Domain sowie Subject Alternative Names. Ein Zertifikat gilt erst als betriebsbereit, wenn ein externer Client die vollständige Kette ohne Warnung akzeptiert. Die vollständige Ausstellung bleibt im verlinkten Wildcard-Zertifikat-Runbook.

5. DNS konfigurieren

Lokales Gateway

Für ein agentenloses Setup benötigt man öffentlich:

• einen A-Record für den Gateway-FQDN, zum Beispiel ztna.example.net,
• pro Ressource einen CNAME auf den Gateway-FQDN, zum Beispiel wiki.example.net,
• Gateway und agentenlose Ressourcen in derselben Domain.

Für agentenbasierten Zugriff genügt öffentlich der A-Record des Gateways; Ressourcen benötigen keinen öffentlichen CNAME. Das Gateway muss intern den Ziel-FQDN auflösen können. Alternativ trägt man beim Anlegen der Ressource die interne Ziel-IP ein.

Sophos Cloud Gateway

Man bestätigt den Domainbesitz mit dem von Sophos erzeugten CNAME. Man veröffentlicht danach den CNAME für den Gateway-Alias. Für jede agentenlose Ressource kommt ein eigener CNAME auf den angezeigten Ressourcen-Alias hinzu. Bei agentenbasierten Ressourcen ist kein öffentlicher Ressourcen-CNAME erforderlich.

Man prüft jeden Namen aus drei Perspektiven:

1. öffentlich aus einem externen Netz,
2. intern aus dem Gateway-Netz,
3. vom Pilotgerät im vorgesehenen Zugriffsmodus.

Der Agent fängt Traffic anhand des FQDN ab, nicht anhand der IP-Adresse. Wenn eine Webanwendung auf einen weiteren FQDN umleitet, legt man auch den Redirect-FQDN als Ressource an.

6. Policy erstellen

Man öffnet Sophos Central > My Products > ZTNA > Policies > Add policy beziehungsweise Meine Produkte > ZTNA > Richtlinien.

1. Man klickt auf Richtlinie hinzufügen.
2. Man wählt den Typ Agent oder Ohne Agent passend zur Ressource.
3. Man vergibt einen eindeutigen Namen, zum Beispiel ZTNA-Pilot-Healthy.
4. Man lässt bei einer Agent-Policy unter Zugriffsregeln die Option Bedingungen für die Zugriffsverwaltung verwenden aktiviert.
5. Man wählt unter Zugriff zulassen den erforderlichen Sicherheitszustand.
6. Man speichert.

Eine Policy legt Zugriffsmethode und Bedingungen fest. Benutzergruppen werden nicht der Policy, sondern der Ressource zugewiesen. Pro Ressource ist genau eine Policy möglich; eine neue Zuweisung ersetzt die bisherige.

Bei agentenlosen Policies gibt es keine Gerätezustandsregeln. Wenn auf der Policy-Seite Agent anfordern erscheint, kann man die Policy bereits erstellen, muss für agentenbasierte Tests aber auf die Bereitstellung und Installation des Agents warten.

7. Agent und besondere Zugriffsfälle

Man installiert die ZTNA-Komponente über den Sophos Endpoint Agent nur auf der Pilotgruppe. Man prüft anschliessend am Endpoint, dass der Agent konfiguriert ist und die erwartete Policy erhalten hat.

Unter Meine Produkte > ZTNA > Einstellungen kann man die Inaktivitätszeit des Agent-Tunnels auf 5, 15 oder 30 Minuten beziehungsweise 1 Stunde setzen; Standard sind 5 Minuten. Der Tunnel wird bei neuem Traffic automatisch wieder aufgebaut. Die Mindestzeit, bevor ein geänderter Gerätezustand eine Regel auslöst, verhindert unnötige Sperren bei kurzen Statusproblemen.

Für Windows kann Lokalen Datenverkehr nicht überwachen Hairpinning im Büro vermeiden. Dafür ist mindestens Sophos Core Agent 2025.2.1.709 erforderlich. Man hinterlegt einen FQDN und eine IP in Sophos Fusion und dieselbe Zuordnung im internen DNS. Stimmt die Auflösung, lässt der Agent den lokalen Traffic direkt über das LAN laufen. Man aktiviert diese Option nur, wenn die Ressourcen im LAN ohne ZTNA erreichbar sein sollen; auf macOS ist sie laut Sophos-Produktdokumentation noch nicht verfügbar.

Besondere Fälle werden getrennt geplant:

• RDS-Farm: Man stellt die RDS-Farm und ihre Domainzugehörigkeit zuerst nach aktueller Microsoft-Dokumentation fertig. Man öffnet dann Meine Produkte > ZTNA > Ressourcen und Zugriff > Ressource hinzufügen und wählt Gateway, Zugriffsmethode: Agent, Ressourcentyp: Remote Desktop Protocol (RDP), den externen FQDN des RD-Gateways, die benötigten Ports (im dokumentierten Beispiel 3389, 443 und 80), den internen FQDN oder die IP des RD-Gateways sowie die Pilotgruppe. Man öffnet vom Windows-Pilotgerät https://<rd-gateway-fqdn>/rdweb, lädt die RDP-Datei und verbindet sich. Erwartet wird eine Sitzung auf einem Session Host. Eine Paketerfassung muss den ZTNA-Verkehr am TAP/TUN-Adapter zeigen; an der primären Schnittstelle darf kein direkter Verkehr zur RD-Gateway- oder Session-Host-IP sichtbar sein. Andernfalls prüft man Agent, Ressourcentyp, Ports, Namensauflösung und RDS-Broker/Gateway, bevor man den Benutzerkreis erweitert.
• SaaS-Steuerung: Man verwendet diesen Weg nur, wenn die SaaS-Anwendung IP-Allow-Listen unterstützt. Man legt sie als ZTNA-Ressource an, weist nur die benötigte Gruppe zu und lässt Interner FQDN/IP-Adresse leer; der externe FQDN wird dadurch als Ziel verwendet. Man erlaubt in der SaaS-Anwendung ausschliesslich die öffentliche IP beziehungsweise den IP-Bereich der NAT-Schnittstelle vor dem ZTNA-Gateway. Ein Pilotbenutzer muss die SaaS-Anwendung über ZTNA erreichen, ein nicht berechtigter Benutzer oder ein direkter Weg ausserhalb des erlaubten NAT-Bereichs nicht. Bei Fehlern vergleicht man den tatsächlich ausgehenden NAT-Bereich mit der Allow-Liste und kontrolliert Gruppe, externen FQDN und Gatewaypfad.
• Windows Hello: Dieser schlüsselbasierte, kennwortlose Weg erfordert Microsoft Entra ID, eine Azure-Premium-Lizenz, Windows 10 oder 11, eine bestehende ZTNA-Konfiguration und einen Anwendungsserver in derselben Domain wie das Agentgerät. Man aktiviert im Azure-Portal unter Geräte > Geräteeinstellungen das Verbinden von Geräten. Man aktiviert in Intune unter Geräte > Windows-Registrierung > Windows Hello for Business Windows Hello für alle Benutzer oder erstellt unter Geräte > Konfigurationsprofile > Profil erstellen ein Profil Windows 10 und höher > Vorlagen > Identitätsschutz für genau die Pilotgruppe. Man verbindet das Pilotgerät unter Einstellungen > Konten > Auf Arbeits- oder Schulkonto zugreifen > Verbinden > Dieses Gerät in Azure Active Directory einbinden, startet neu, meldet sich mit dem Entra-Konto an und richtet MFA sowie PIN oder Biometrie ein. Man installiert danach den ZTNA-Agenten. Beim direkten Zugriff auf eine agentenbasierte Anwendung – einschliesslich CIFS oder RDP – darf keine erneute IdP-Abfrage erscheinen; Sophos Endpoint muss ZTNA als konfiguriert und den Benutzer als authentifiziert anzeigen. Falls doch, prüft man Entra-Join, Gruppenprofil, Hello-Anmeldung, gleiche Domain und Agentstatus. Die Menünamen von Microsoft können sich ändern; deshalb gleicht man sie vor dem Rollout mit der aktuellen Microsoft-Dokumentation ab.
• Im Büro: Man entscheidet bewusst zwischen demselben ZTNA-Pfad wie extern und direktem LAN-Zugriff. Man vermeidet unbeabsichtigtes Hairpinning.
• Domain Controller: Man legt diese für Windows-Geräte als agentenbasierte Ressourcen an. Seit Endpoint-Version 2026.1 unterstützt Sophos mehrere Domain Controller; Priorität und Gewichtung der automatisch erzeugten SRV-Einträge ermöglichen Failover und Lastverteilung. Für das konkrete Drei-DC-Setup verwendet man Mehrere Domain Controller mit Sophos ZTNA einrichten, statt das Failover in einer allgemeinen Web-Ressource nachzubauen.

8. Ressource anlegen und Zugriff zuweisen

Man öffnet Sophos Central > My Products > ZTNA > Resources & access > Add resource beziehungsweise Meine Produkte > ZTNA > Ressourcen und Zugriff.

Man dokumentiert vorab:

• Ressourcenname und Application Owner,
• Gateway,
• Webanwendung, Webseite oder lokale Anwendung,
• interner FQDN oder interne IP,
• externer FQDN,
• Protokoll und Port,
• Zugriff mit oder ohne Agent,
• Policy,
• erlaubte Gruppen,
• Redirect-FQDNs,
• Positiv- und Negativtest.

Für Webanwendungen und Webseiten verwendet man einen FQDN. Lokale Apps verbindet man über eine IP-Adresse. Beim agentenlosen Zugriff muss der externe FQDN öffentlich verfügbar sein. Beim agentenbasierten Zugriff darf der externe FQDN nicht öffentlich verfügbar sein, sonst ist die Ressource nicht erreichbar.

1. Man klickt auf Ressource hinzufügen.
2. Man wählt Gateway und Zugriffstyp.
3. Man trägt internen und externen Namen, Protokoll und Port ein.
4. Man wählt die zuvor erstellte Policy.
5. Man weist nur die Pilotgruppe zu.
6. Man speichert und öffnet die Ressourcenzusammenfassung zur Gegenprüfung.

Änderungen an Gruppenmitgliedschaften können bis zu einer Stunde benötigen, bis sie am Gateway wirksam sind. Man beobachtet diesen Zeitraum, bevor man die Konfiguration erneut ändert.

Validierung und erwartetes Ergebnis

Konfiguration prüfen

• Unter Meine Produkte > ZTNA > Dashboard sind keine unerwarteten High- oder Medium-Alerts sichtbar.
• Der Identity-Provider-Verbindungstest ist erfolgreich und zeigt beim AD-Test die erwartete Gruppe.
• Domain und Zertifikat sind gültig; externe Browser melden keinen Zertifikatsfehler.
• Öffentliche DNS-Einträge zeigen auf das erwartete Gateway oder den von Sophos erzeugten Alias.
• Das Gateway löst das interne Ziel auf und erreicht dessen Port.
• Policy-Typ, Ressourcentyp und Agent-Status passen zusammen.
• Die Ressource zeigt genau die vorgesehene Policy und Pilotgruppe.

Zugriff testen

1. Man öffnet die Anwendung als berechtigter Pilotbenutzer über ihren externen FQDN, nicht über die IP-Adresse.
2. Man bestätigt die Anmeldung beim konfigurierten Identity Provider.
3. Man prüft die echte Anwendungsfunktion, nicht nur die Startseite: Anmeldung, Navigation und ein ungefährlicher Lesevorgang müssen funktionieren.
4. Man testet mit einem Benutzer ausserhalb der freigegebenen Gruppe. Der Zugriff muss nachvollziehbar abgewiesen werden.
5. Man ändert bei einer Agent-Policy testweise nur in einem kontrollierten Testfenster den relevanten Gerätezustand. Die definierte Bedingung muss greifen.
6. Man prüft ZTNA-, Gateway-, Identity-Provider-, DNS- und Firewall-Logs auf denselben Zeitstempel.
7. Man dokumentiert Benutzer, Gerät, FQDN, Uhrzeit, erwartetes und tatsächliches Ergebnis.

Benutzer können Webanwendungen direkt oder über das ZTNA-Benutzerportal öffnen. Die Portaladresse ist der beim Gateway hinterlegte FQDN. Bei Plattformtyp Sophos Firewall muss ein Administrator zuerst eine Ressource für den Portalzugriff konfigurieren. Das Portal zeigt die erlaubten agentenlosen Anwendungen gatewayübergreifend; agentenbasierte Anwendungen werden dort nicht angezeigt. Nach sieben Tagen ohne Ressourcenzugriff ist eine neue Anmeldung erforderlich. Fünf aufeinanderfolgende fehlgeschlagene Authentifizierungen sperren weitere Ressourcen für 60 Minuten.

Troubleshooting nach Symptom

Anmeldung schlägt fehl

1. Man testet die Verbindung unter Meine Produkte > ZTNA > Identitätsanbieter.
2. Man prüft Client-ID, Tenant-ID, Secret-Ablauf und Redirect-URI.
3. Man kontrolliert, ob Benutzer und Gruppe synchronisiert und sicherheitsaktiviert sind.
4. Bei AD: Man prüft Bind DN, Base DN, Port, TLS-Zertifikat und ein gültiges E-Mail-Feld des Testbenutzers.
5. Man wartet nach fünf Fehlversuchen die 60-minütige Sperre ab, statt weitere Tests zu erzeugen.

Ein Provider lässt sich nicht aktivieren, solange das Setup unvollständig ist oder ungültige Angaben enthält. Bei der Meldung Verifizierung fehlgeschlagen aufgrund ungültiger Client-ID prüft man die App-ID und ob die Benutzeranmeldung für die Anwendung in Entra ID aktiviert ist.

Anmeldung funktioniert, Anwendung aber nicht

1. Man öffnet exakt den externen Ressourcen-FQDN.
2. Man prüft Redirects und legt jeden weiteren FQDN als Ressource an.
3. Man testet interne Auflösung und Zielport vom Gateway-Netz.
4. Man vergleicht Ressourcentyp, Policy-Typ und Agent-Installation.
5. Man prüft, ob der externe Ressourcen-FQDN beim agentenlosen Zugriff öffentlich und beim agentenbasierten Zugriff gerade nicht öffentlich auflösbar ist.
6. Man kontrolliert, ob eine neue Policy die alte Ressourcenzuweisung ersetzt hat.
7. Funktioniert der direkte Zugriff, aber nicht das Benutzerportal auf einer Sophos Firewall, prüft man, ob die erforderliche Portalressource konfiguriert und der richtigen Gruppe zugewiesen ist.

Benutzer erhält unerwartet keinen Zugriff

• Man prüft die effektive, nicht nur die erwartete Gruppenmitgliedschaft.
• Man wartet nach einer Gruppenänderung bis zu eine Stunde.
• Man weist umbenannte Entra-Gruppen erneut zu.
• Man stellt bei AD sicher, dass der Benutzer nicht nur Mitglied einer primären Gruppe ist.
• Man prüft, ob Filter oder Base DN den Benutzer aus dem Sync-Scope entfernt haben.

DNS oder Zertifikat ist fehlerhaft

• Man vergleicht A- und CNAME-Werte Zeichen für Zeichen mit Sophos Fusion. Man prüft einen TXT-Wert nur beim getrennten manuellen Certbot-Weg oder bei der Domainverifizierung für die Fusion-Verbundanmeldung.
• Man kontrolliert beim verwalteten Zertifikat den CNAME unter _acme-challenge.<domain>, lässt ihn für Erneuerungen bestehen und generiert das Account-Zertifikat nach einer Domainänderung neu.
• Man prüft, ob der DNS-Anbieter den eigenen Domainnamen an den CNAME angehängt hat.
• Man kontrolliert Zertifikatskette, Wildcard-Scope, Ablaufdatum und unterstützten Schlüsseltyp.
• Man testet öffentlich und intern getrennt. Ein erfolgreicher LAN-Test beweist keine öffentliche Auflösung.

Agent ist installiert, Tunnel oder Gerätezustand greift nicht

• Man prüft Betriebssystem, Endpoint-Version und installierte ZTNA-Komponente.
• Man stellt sicher, dass Policy und Ressource beide agentenbasiert sind.
• Man berücksichtigt die konfigurierte Mindestzeit für den Gerätezustand.
• Bei Lokalen Datenverkehr nicht überwachen müssen FQDN und IP intern exakt mit der Central-Konfiguration übereinstimmen.
• Die Protected-Browser-Erweiterung liefert keinen Endpoint-Integritätsstatus; deshalb testet man solche Bedingungen im vollständigen Protected Browser oder mit dem ZTNA-Agenten.

Eskalation an Sophos Support

Unter Globale Einstellungen > Produkte und Services > ZTNA legt man die Ablaufzeit für Supportzugriff fest. Man erzeugt anschliessend in den Gateway-Einstellungen ein zeitlich begrenztes Support-Token. Man übermittelt keine dauerhaften Zugangsdaten und widerruft beziehungsweise lässt das Token nach Abschluss auslaufen.

Sicherer Rückweg und Offboarding

Fehlgeschlagenen Pilot zurücknehmen

1. Man stoppt die Ausweitung auf weitere Benutzer.
2. Man entfernt die Pilotgruppe aus der Ressource oder setzt die Policy auf Richtlinie umgangen. Man beachtet: Damit können Benutzer nicht auf die verwalteten Ressourcen zugreifen.
3. Man stellt den zuvor dokumentierten Zugriffspfad wieder her, etwa VPN oder direkten LAN-Zugriff. Man lässt ihn erst wegfallen, wenn ZTNA abgenommen ist.
4. Man entfernt die ZTNA-Komponente nur von Pilotgeräten, wenn keine weitere agentenbasierte Ressource sie benötigt.
5. Man nimmt öffentliche Ressourcen-CNAMEs erst nach bestätigter Rückkehr zum alten Pfad zurück. Man löscht Gateway-DNS und Zertifikat nicht vorschnell, solange andere Ressourcen sie verwenden.
6. Man prüft mit Positiv- und Negativtest, dass der alte Pfad funktioniert und keine unbeabsichtigte öffentliche Veröffentlichung verbleibt.

Die Option Bedingungen für die Zugriffsverwaltung verwenden nicht als vermeintlichen Notfall-Bypass deaktivieren: Damit entfernt man die Gerätezustandsprüfung. Wenn ein sicherer Zugriff nicht wiederhergestellt werden kann, stoppt man an dieser Stelle und eskaliert, statt die Policy zu erweitern.

Benutzer oder Gast offboarden

1. Man entzieht die Gruppenmitgliedschaft im führenden Verzeichnis beziehungsweise deaktiviert das Konto beim Identity Provider.
2. Man berücksichtigt bis zu eine Stunde für die Wirkung am Gateway. Eine Deaktivierung beim Identity Provider führt danach zur erzwungenen Abmeldung und blockiert Ressourcen.
3. Man kontrolliert, dass keine zweite synchronisierte Gruppe denselben Zugriff gewährt.
4. Man prüft die ZTNA-Logs nach dem Entzug mit einem Negativtest.
5. Man entfernt verwaiste Gastkonten, Einladungen und temporäre Gruppen im Quellsystem.

Benutzer bleiben grundsätzlich angemeldet, bis sie sieben Tage inaktiv waren. Eine sofortige Abmeldung kann derzeit nur ein Administrator auslösen. Man berücksichtigt das besonders bei gemeinsam genutzten Geräten.

Ressource oder Gateway ausser Betrieb nehmen

1. Man inventarisiert alle zugewiesenen Gruppen, Policies, Ressourcen, DNS-Namen und Zertifikatsabhängigkeiten.
2. Man entfernt zuerst den Benutzerzugriff und beobachtet die Logs.
3. Man löscht danach die Ressource.
4. Man entfernt öffentliche DNS-Einträge erst, wenn kein anderer Zugriffspfad sie benötigt.
5. Man löscht ein Gateway erst, wenn alle Ressourcen migriert und der neue Pfad validiert sind.
6. Man widerruft nicht mehr benötigte Secrets und Zertifikate und entfernt alte Firewall- oder NAT-Regeln.

Betrieb, Review und Lifecycle

Man führt mindestens quartalsweise und nach jeder grösseren Änderung einen Review durch:

• aktive Benutzer und Lizenzverbrauch der letzten 30 Tage,
• Gruppen- und Gastmitgliedschaften,
• Ressource-zu-Policy-Zuordnung und Application Owner,
• Zertifikatsablauf und Secret-Rotation,
• Gateway-, Agent-, SFOS- und Hypervisor-Versionen,
• PoP, Failover und aktuelle Statusmeldungen,
• nicht erreichbare agentenlose Ressourcen und Alert-Trends,
• ausgehende Firewall-Ausnahmen, NAT und alte DNS-Einträge,
• Positiv- und Negativtest je kritischer Anwendung,
• dokumentierter Notfall- und Rückweg.

Das ZTNA-Dashboard zeigt Alert-Zahlen und die fünf Anwendungen mit dem höchsten Datentransfer der letzten 24 Stunden. Man nutzt die Reports Gateway bandwidth und Resource bandwidth, um authentifizierte Benutzer und Datenvolumen nachzuvollziehen.

Eine aktive ZTNA-Lizenz umfasst Feature- und Maintenance-Releases, 24x7-Support und die zugehörigen Sophos-Fusion-Funktionen. Sophos erwartet Feature-Releases etwa alle sechs bis zwölf Monate und Maintenance-Releases alle ein bis drei Monate. Gepflegt werden die aktuelle und eine ausgewählte weitere Feature-Version; pro gepflegter Feature-Version sollen die letzten zwei Maintenance-Releases unterstützt werden. Der erwartete Supportzeitraum einer Feature-Version liegt bei ungefähr 24 Monaten, mit üblicherweise 90 Tagen öffentlicher Vorankündigung zum Supportende.

Man behandelt diese Angaben als Release-Planung, nicht als Garantie für einen konkreten Termin. Man prüft vor Upgrades die aktuellen ZTNA-Release Notes, bekannte Einschränkungen, Agent-Kompatibilität und den Status der verwendeten PoPs. Historische Übergangs-, Entitlement-, Migrations- oder EOL-Aussagen ohne aktuelle Produktmitteilung gehören nicht in den Betriebsplan.

Verwandte bestehende Anleitungen

• Sophos ZTNA Gateway planen und erstellen
• Microsoft Entra ID mit Sophos Fusion synchronisieren
• Mehrere Domain Controller mit Sophos ZTNA einrichten
• Let’s Encrypt Wildcard Zertifikat erstellen
• Sophos Fusion Trial starten und sicher auswerten
• Zero Trust einfach erklärt: ZTNA statt klassischem VPN