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ötigen Sie einen Verzeichnisdienst, einen Identity Provider, ein Gateway, ein Zertifikats- und DNS-Konzept, Policies und Ressourcen. Für lokale Anwendungen ist ein ZTNA-Agent erforderlich; Webanwendungen können agentenlos bereitgestellt werden.

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. Beginnen Sie mit genau einer Anwendung, einer Pilotgruppe und einem dokumentierten Rückweg. Erst wenn der Positiv- und Negativtest stimmen, erweitern Sie den Umfang.

Direkte Antwort: die richtige Reihenfolge

Richten Sie 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ötigen Sie 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.

Aktivieren und kontrollieren Sie die Lizenz über das Profilsymbol > Licensing. Für einen strukturierten Test verwenden Sie 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.

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

Technische Vorprüfung

Prüfen Sie 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

Ersetzen Sie alle Werte durch Ihre eigenen. Vermischen Sie Test- und Produktionsdomains nicht.

1. Zugriffspfad und Gateway-Modus wählen

Agentenlos oder mit Agent

Die Wahl ist technisch bindend:

Agentenloser Zugriff kann nur Webanwendungen und Webseiten steuern. 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; legen Sie dafür eine agentenlose ZTNA-Policy, eine eng begrenzte Ressource sowie die zugehörigen Protected-Browser-Objekte an. Kopieren Sie 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. Sie verwalten die Instanz und benötigen 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. Behandeln Sie sie trotzdem wie eine kontrollierte Änderung: DNS, Zertifikat, PoP, externe Namen und Tests müssen zum neuen Datenpfad passen.

Wählen Sie 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 ändern Sie unter Meine Produkte > ZTNA > Gateways, indem Sie das Gateway öffnen, Edit wählen, unter Points of Presence die Region ändern und speichern.

2. Verzeichnisdienst und Gruppen vorbereiten

ZTNA autorisiert anhand synchronisierter Benutzergruppen. Legen Sie deshalb zuerst eine kleine, sicherheitsaktivierte Pilotgruppe an und nehmen Sie 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. Registrieren Sie die ZTNA-Anwendung in Entra ID.
2. Hinterlegen Sie 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. Erfassen Sie 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. Erteilen Sie nur die benötigten Microsoft-Graph-Berechtigungen und die erforderliche Admin-Zustimmung.
5. Erstellen oder wählen Sie sicherheitsaktivierte Gruppen. Aus dem Microsoft-365-Portal oder aus AD importierte Gruppen müssen Sie darauf ausdrücklich prüfen.
6. Öffnen Sie in Sophos Fusion Globale Einstellungen > Verzeichnisdienst beziehungsweise Zugriffskontrolle > Anmeldung & Identität und fügen Sie Microsoft Entra ID hinzu.
7. Konfigurieren Sie Domain, Client-ID, Client secret, dessen Gültigkeitsdauer sowie den Zeitplan Stündlich, Täglich, Wöchentlich, Monatlich oder Keine.
8. Filtern Sie die zu synchronisierenden Benutzer und Gruppen auf den tatsächlich benötigten Umfang. Speichern Sie und prüfen Sie 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. Benennen Sie eine bereits zugewiesene Entra-Gruppe später um, wird der Name in der Zuweisung nicht automatisch aktualisiert; weisen Sie die Gruppe erneut zu.

Lokales Active Directory synchronisieren

Für AD laden Sie 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 Active Directory Sync, eindeutige Benutzer und E-Mail-Adressen sowie die erforderlichen Firewall- oder Proxy-Freigaben.

1. Validieren Sie Client-ID und Client Secret im Setup-Programm.
2. Verwenden Sie für LDAP ein Konto mit Lesezugriff auf die Gesamtstruktur und so wenig Rechten wie möglich.
3. Lassen Sie 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. Wählen Sie Benutzer und Benutzergruppen gemeinsam aus. Dasselbe gilt für Geräte und Gerätegruppen.
5. Begrenzen Sie den Scope mit Base Distinguished Names und LDAP-Filtern, zum Beispiel OU=Finance,DC=example,DC=net.
6. Führen Sie nach der Einrichtung oder Filteränderung zunächst eine manuelle Vorschau und Synchronisierung aus. Eine manuelle Synchronisierung kann bis zu 15 Minuten dauern.

Synchronisieren Sie 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. Entfernen Sie inaktive Konten im Quellverzeichnis, statt sie nur aus der Synchronisierung auszublenden.

Gastzugriff

Für externe Benutzer kann Microsoft Entra B2B eingesetzt werden. Prüfen Sie 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. Erstellen Sie eine eigene Gastgruppe, synchronisieren Sie sie nach Sophos Fusion und weisen Sie 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, öffnen Sie Meine Umgebung > Benutzer und Gruppen, wählen Benutzer hinzufügen und erfassen Vor- und Nachname, E-Mail-Adresse und bei Bedarf Rolle, Manager, Exchange-Login sowie Zu Gruppen hinzufügen (optional). Weisen Sie eine Administratorrolle nur zu, wenn sie wirklich benötigt wird; die Rolle Benutzer gewährt nur Zugriff auf das Self-Service-Portal. Aktivieren Sie E-Mail-Einrichtungslink nur, wenn der Benutzer ein eigenes Gerät schützen soll und dafür lokale Administratorrechte sowie Internetzugang besitzt. Speichern Sie und prüfen Sie, dass der Benutzer in der Liste und – falls gewählt – in der vorgesehenen ZTNA-Gruppe erscheint. Fehlt er, prüfen Sie zuerst E-Mail-Adresse, Gruppenfilter und ob stattdessen der Verzeichnisdienst die führende Quelle sein muss.

3. Identity Provider einrichten

Öffnen Sie 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. Vermeiden Sie Sonderzeichen wie ., @ oder # im Namen, da sich die Konfiguration sonst möglicherweise nicht speichern lässt.

Microsoft Entra ID

1. Wählen Sie Microsoft Entra ID (Azure AD).
2. Tragen Sie Name, Beschreibung, Client-ID, Tenant-ID und Client secret ein.
3. Testen Sie die Verbindung.
4. Speichern Sie erst nach erfolgreichem Test.

Lokales Active Directory

1. Wählen Sie Microsoft AD (on-prem).
2. Erfassen Sie Host und Port des primären AD-Servers, optional einen sekundären Server derselben Domain.
3. Aktivieren Sie TLS oder StartTLS. Wenn Sie Verify SSL certificate wählen, laden Sie ein Zertifikat im Format .pem, .crt oder .cer bis maximal 10 KB hoch.
4. Tragen Sie Bind DN, Bind-Kennwort sowie die Base DN für Benutzer und Benutzergruppen ein.
5. Optional können Sie Captcha und ein E-Mail-basiertes Einmalkennwort mit SMTP-Konfiguration aktivieren.
6. Weisen Sie den Identity Provider einem Gateway zu. Öffnen Sie danach den Provider erneut, wählen Sie 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ötigen Sie synchronisierte Gruppen und einen OIDC-Autorisierungsserver. Das Gateway muss mindestens Version 1.1 verwenden. Erstellen Sie in Okta eine OIDC-Webanwendung, aktivieren Sie Client Credentials und Refresh Token, verwenden Sie den passenden Callback-Pfad und weisen Sie die Gruppen zu. Erfassen Sie 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. Sie benötigen Superadmin-Rechte und müssen die Anmeldedomain zuerst unter Zugriffskontrolle > Anmeldung & Identität > Sophos-Anmeldung mit dem dort erzeugten TXT-Eintrag verifizieren. Öffnen Sie danach Zugriffskontrolle > Anmeldung und Identität > Verbundidentitätsanbieter und wählen Identitätsanbieter hinzufügen:

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

Aktivieren Sie die Verbundanmeldung erst, wenn alle betroffenen Administratoren und Benutzer einer Domain zugeordnet sind und einen passenden Identity Provider besitzen. Testen Sie vorher mit einem begrenzten Administratorkonto in einem privaten Browserfenster und halten Sie eine funktionierende Superadmin-Sitzung als Rückweg offen. Schlägt der Test fehl, deaktivieren Sie den neuen Provider in dieser Sitzung und prüfen Domainzuordnung, Endpoints, Zertifikatsvertrauen und MFA-Auswahl.

4. Gateway, Domains und Zertifikat bereitstellen

Planen und erstellen Sie das Gateway gemäss Sophos ZTNA Gateway planen und erstellen. Verwenden Sie 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 öffnen Sie Meine Produkte > ZTNA > Einstellungen > Domänen und Zertifikate und wählen Domäne hinzufügen. Fusion erzeugt einen CNAME für _acme-challenge.<domain>. Veröffentlichen Sie Namen und Ziel exakt im öffentlichen DNS, lassen Sie diesen CNAME für spätere Erneuerungen bestehen und wählen danach Verifizieren. Der Status muss auf verifiziert wechseln. Übernehmen Sie 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, stellen Sie sie vor der Erzeugung des verwalteten Zertifikats auf den aktuellen CNAME um. Nach jeder neu hinzugefügten Domain müssen Sie 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öffentlichen Sie den von Certbot verlangten TXT-Wert. Laden Sie anschliessend Zertifikat, vollständige Kette und privaten Schlüssel hoch und prüfen Sie 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ötigen Sie ö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 tragen Sie beim Anlegen der Ressource die interne Ziel-IP ein.

Sophos Cloud Gateway

Bestätigen Sie den Domainbesitz mit dem von Sophos erzeugten CNAME. Veröffentlichen Sie 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.

Prüfen Sie 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, legen Sie auch den Redirect-FQDN als Ressource an.

6. Policy erstellen

Öffnen Sie Sophos Central > My Products > ZTNA > Policies > Add policy beziehungsweise Meine Produkte > ZTNA > Richtlinien.

1. Klicken Sie auf Richtlinie hinzufügen.
2. Wählen Sie den Typ Agent oder Ohne Agent passend zur Ressource.
3. Vergeben Sie einen eindeutigen Namen, zum Beispiel ZTNA-Pilot-Healthy.
4. Lassen Sie bei einer Agent-Policy unter Zugriffsregeln die Option Bedingungen für die Zugriffsverwaltung verwenden aktiviert.
5. Wählen Sie unter Zugriff zulassen den erforderlichen Sicherheitszustand.
6. Speichern Sie.

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, können Sie die Policy bereits erstellen, müssen für agentenbasierte Tests aber auf die Bereitstellung und Installation des Agents warten.

7. Agent und besondere Zugriffsfälle

Installieren Sie die ZTNA-Komponente über den Sophos Endpoint Agent nur auf der Pilotgruppe. Prüfen Sie anschliessend am Endpoint, dass der Agent konfiguriert ist und die erwartete Policy erhalten hat.

Unter Meine Produkte > ZTNA > Einstellungen können Sie 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. Hinterlegen Sie 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. Aktivieren Sie diese Option nur, wenn die Ressourcen im LAN ohne ZTNA erreichbar sein sollen; auf macOS ist sie laut der zugewiesenen Produktdokumentation noch nicht verfügbar.

Besondere Fälle sollten Sie getrennt planen:

• RDS-Farm: Stellen Sie die RDS-Farm und ihre Domainzugehörigkeit zuerst nach aktueller Microsoft-Dokumentation fertig. Öffnen Sie dann Meine Produkte > ZTNA > Ressourcen und Zugriff > Ressource hinzufügen und wählen 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. Öffnen Sie vom Windows-Pilotgerät https://<rd-gateway-fqdn>/rdweb, laden Sie die RDP-Datei und verbinden Sie 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üfen Sie Agent, Ressourcentyp, Ports, Namensauflösung und RDS-Broker/Gateway, bevor Sie Benutzer erweitern.
• SaaS-Steuerung: Verwenden Sie diesen Weg nur, wenn die SaaS-Anwendung IP-Allow-Listen unterstützt. Legen Sie sie als ZTNA-Ressource an, weisen Sie nur die benötigte Gruppe zu und lassen Sie Interner FQDN/IP-Adresse leer; der externe FQDN wird dadurch als Ziel verwendet. Erlauben Sie 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 vergleichen Sie den tatsächlich ausgehenden NAT-Bereich mit der Allow-Liste und kontrollieren 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. Aktivieren Sie im Azure-Portal unter Geräte > Geräteeinstellungen das Verbinden von Geräten. Aktivieren Sie in Intune unter Geräte > Windows-Registrierung > Windows Hello for Business Windows Hello für alle Benutzer oder erstellen Sie unter Geräte > Konfigurationsprofile > Profil erstellen ein Profil Windows 10 und höher > Vorlagen > Identitätsschutz für genau die Pilotgruppe. Verbinden Sie das Pilotgerät unter Einstellungen > Konten > Auf Arbeits- oder Schulkonto zugreifen > Verbinden > Dieses Gerät in Azure Active Directory einbinden, starten Sie neu, melden Sie sich mit dem Entra-Konto an und richten Sie MFA sowie PIN oder Biometrie ein. Installieren Sie 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üfen Sie Entra-Join, Gruppenprofil, Hello-Anmeldung, gleiche Domain und Agentstatus. Die Menünamen von Microsoft können sich ändern; gleichen Sie sie vor dem Rollout mit der aktuellen Microsoft-Dokumentation ab.
• Im Büro: entscheiden Sie bewusst zwischen demselben ZTNA-Pfad wie extern und direktem LAN-Zugriff. Vermeiden Sie unbeabsichtigtes Hairpinning.
• Domain Controller: legen Sie 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 verwenden Sie Mehrere Domain Controller mit Sophos ZTNA einrichten, statt das Failover in einer allgemeinen Web-Ressource nachzubauen.

8. Ressource anlegen und Zugriff zuweisen

Öffnen Sie Sophos Central > My Products > ZTNA > Resources & access > Add resource beziehungsweise Meine Produkte > ZTNA > Ressourcen und Zugriff.

Dokumentieren Sie 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 verwenden Sie einen FQDN. Lokale Apps verbinden Sie ü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. Klicken Sie auf Ressource hinzufügen.
2. Wählen Sie Gateway und Zugriffstyp.
3. Tragen Sie internen und externen Namen, Protokoll und Port ein.
4. Wählen Sie die zuvor erstellte Policy.
5. Weisen Sie nur die Pilotgruppe zu.
6. Speichern Sie und öffnen Sie die Ressourcenzusammenfassung zur Gegenprüfung.

Änderungen an Gruppenmitgliedschaften können bis zu einer Stunde benötigen, bis sie am Gateway wirksam sind. Beobachten Sie diesen Zeitraum, bevor Sie die Konfiguration erneut ändern.

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. Öffnen Sie die Anwendung als berechtigter Pilotbenutzer über ihren externen FQDN, nicht über die IP-Adresse.
2. Bestätigen Sie die Anmeldung beim konfigurierten Identity Provider.
3. Prüfen Sie die echte Anwendungsfunktion, nicht nur die Startseite: Anmeldung, Navigation und ein ungefährlicher Lesevorgang müssen funktionieren.
4. Testen Sie mit einem Benutzer ausserhalb der freigegebenen Gruppe. Der Zugriff muss nachvollziehbar abgewiesen werden.
5. Ändern Sie bei einer Agent-Policy testweise nur in einem kontrollierten Testfenster den relevanten Gerätezustand. Die definierte Bedingung muss greifen.
6. Prüfen Sie ZTNA-, Gateway-, Identity-Provider-, DNS- und Firewall-Logs auf denselben Zeitstempel.
7. Dokumentieren Sie 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. Testen Sie die Verbindung unter Meine Produkte > ZTNA > Identitätsanbieter.
2. Prüfen Sie Client-ID, Tenant-ID, Secret-Ablauf und Redirect-URI.
3. Kontrollieren Sie, ob Benutzer und Gruppe synchronisiert und sicherheitsaktiviert sind.
4. Bei AD: Prüfen Sie Bind DN, Base DN, Port, TLS-Zertifikat und ein gültiges E-Mail-Feld des Testbenutzers.
5. Warten Sie 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üfen Sie die App-ID und ob die Benutzeranmeldung für die Anwendung in Entra ID aktiviert ist.

Anmeldung funktioniert, Anwendung aber nicht

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

Benutzer erhält unerwartet keinen Zugriff

• Prüfen Sie die effektive, nicht nur die erwartete Gruppenmitgliedschaft.
• Warten Sie nach einer Gruppenänderung bis zu eine Stunde.
• Weisen Sie umbenannte Entra-Gruppen erneut zu.
• Stellen Sie bei AD sicher, dass der Benutzer nicht nur Mitglied einer primären Gruppe ist.
• Prüfen Sie, ob Filter oder Base DN den Benutzer aus dem Sync-Scope entfernt haben.

DNS oder Zertifikat ist fehlerhaft

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

Agent ist installiert, Tunnel oder Gerätezustand greift nicht

• Prüfen Sie Betriebssystem, Endpoint-Version und installierte ZTNA-Komponente.
• Stellen Sie sicher, dass Policy und Ressource beide agentenbasiert sind.
• Berücksichtigen Sie 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; testen Sie solche Bedingungen im vollständigen Protected Browser oder mit dem ZTNA-Agenten.

Eskalation an Sophos Support

Unter Globale Einstellungen > Produkte und Services > ZTNA legen Sie die Ablaufzeit für Supportzugriff fest. Erzeugen Sie anschliessend in den Gateway-Einstellungen ein zeitlich begrenztes Support-Token. Übermitteln Sie keine dauerhaften Zugangsdaten und widerrufen beziehungsweise lassen Sie das Token nach Abschluss auslaufen.

Sicherer Rückweg und Offboarding

Fehlgeschlagenen Pilot zurücknehmen

1. Stoppen Sie die Ausweitung auf weitere Benutzer.
2. Entfernen Sie die Pilotgruppe aus der Ressource oder setzen Sie die Policy auf Richtlinie umgangen. Beachten Sie: Damit können Benutzer nicht auf die verwalteten Ressourcen zugreifen.
3. Stellen Sie den zuvor dokumentierten Zugriffspfad wieder her, etwa VPN oder direkten LAN-Zugriff. Lassen Sie ihn erst wegfallen, wenn ZTNA abgenommen ist.
4. Entfernen Sie die ZTNA-Komponente nur von Pilotgeräten, wenn keine weitere agentenbasierte Ressource sie benötigt.
5. Nehmen Sie öffentliche Ressourcen-CNAMEs erst nach bestätigter Rückkehr zum alten Pfad zurück. Löschen Sie Gateway-DNS und Zertifikat nicht vorschnell, solange andere Ressourcen sie verwenden.
6. Prüfen Sie mit Positiv- und Negativtest, dass der alte Pfad funktioniert und keine unbeabsichtigte öffentliche Veröffentlichung verbleibt.

Deaktivieren Sie Bedingungen für die Zugriffsverwaltung verwenden nicht als vermeintlichen Notfall-Bypass: Damit entfernen Sie die Gerätezustandsprüfung. Wenn ein sicherer Zugriff nicht wiederhergestellt werden kann, stoppen Sie an dieser Stelle und eskalieren Sie, statt die Policy zu erweitern.

Benutzer oder Gast offboarden

1. Entziehen Sie die Gruppenmitgliedschaft im führenden Verzeichnis beziehungsweise deaktivieren Sie das Konto beim Identity Provider.
2. Berücksichtigen Sie 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. Kontrollieren Sie, dass keine zweite synchronisierte Gruppe denselben Zugriff gewährt.
4. Prüfen Sie die ZTNA-Logs nach dem Entzug mit einem Negativtest.
5. Entfernen Sie 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. Berücksichtigen Sie das besonders bei gemeinsam genutzten Geräten.

Ressource oder Gateway ausser Betrieb nehmen

1. Inventarisieren Sie alle zugewiesenen Gruppen, Policies, Ressourcen, DNS-Namen und Zertifikatsabhängigkeiten.
2. Entfernen Sie zuerst den Benutzerzugriff und beobachten Sie die Logs.
3. Löschen Sie danach die Ressource.
4. Entfernen Sie öffentliche DNS-Einträge erst, wenn kein anderer Zugriffspfad sie benötigt.
5. Löschen Sie ein Gateway erst, wenn alle Ressourcen migriert und der neue Pfad validiert sind.
6. Widerrufen Sie nicht mehr benötigte Secrets und Zertifikate und entfernen Sie alte Firewall- oder NAT-Regeln.

Betrieb, Review und Lifecycle

Führen Sie 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. Nutzen Sie 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.

Behandeln Sie diese Angaben als Release-Planung, nicht als Garantie für einen konkreten Termin. Prüfen Sie 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