Integrera DNS Protection och ZTNA med Sophos Protected Browser

Sophos Protected Browser integrerar DNS Protection och ZTNA via två separata driftvägar. DNS Protection konfigureras inte i själva webbläsaren: Sophos Endpoint fångar upp DNS-frågor från enheter som stöds och vidarebefordrar dem via HTTPS till DNS Protection. För privata eller lokala applikationer ansluter Protected Browser i stället till den förberedda ZTNA-gatewayen.

Den korta processen är därför:

Kontrollera under Mina produkter > Protected Browser att du arbetar i rätt tenant. Integrationssidan har ingen gemensam DNS/ZTNA-brytare.
Kontrollera den befintliga Endpoint DNS-konfigurationen mot beredskapspunkterna nedan och testa den med en liten Windows-pilotgrupp.
Konfigurera ZTNA fullständigt med identitet, gateway, resurser och policyer.
Aktivera Tvinga Protected Browser för agentlösa applikationer och resurser utom RDP och SSH.
Testa DNS-upplösning och ZTNA-åtkomst separat, med både positiva och negativa tester. Ett lyckat DNS-test bevisar inte att ZTNA-åtkomsten fungerar, och omvänt.

Krav, licens och roller

DNS-vägen kräver en Workspace Protection-licens, en installerad Sophos Endpoint-agent och Windows-endpoints som stöds. Windows Server och macOS kan för närvarande inte läggas till i den dokumenterade Endpoint-policyn för detta ändamål. Detaljerade licensgränser ingår inte i denna integration; före piloten behöver du endast bekräfta att Workspace Protection är tillgängligt i tenant-miljön och att Sophos Endpoint är installerat på pilotenheterna.

För ZTNA-vägen måste användare och grupper, identitetsleverantör, gateway, resurser, policyer, DNS och certifikat redan fungera. Protected Browser kompletterar denna förberedda åtkomstväg och ersätter inte någon av dess grunder. Konfigurera Sophos ZTNA beskriver ordningsföljden och valideringen.

Sophos anger ingen särskild administratörsroll för integrationssidan. Personen som utför arbetet måste därför ha verifierad åtkomst till nödvändiga Endpoint-, DNS Protection-, ZTNA- och Protected Browser-objekt, utan att för säkerhets skull få Super Admin-rättigheter. Om en produkt eller kontroll saknas ska du först kontrollera tenant, licens och tilldelade behörigheter.

Dokumentera dessutom följande före piloten:

en liten användar- och enhetsgrupp;
en tillåten och en avsiktligt blockerad offentlig testdomän;
ett internt namn som även fortsättningsvis måste lösas av den lokala DNS-tjänsten;
en tillåten ZTNA-testresurs och en obehörig testanvändare;
den tidigare resolver- och åtkomstvägen som återställningsväg;
tidpunkt, ansvarig person och förväntat resultat för varje ändring.

Tillhandahålla DNS Protection för Protected Browser

Sidan under Mina produkter > Protected Browser fungerar som vägvisare för DNS Protection. Den innehåller ingen lokal DNS-konfiguration. Installation, paketversion, fullständig Endpoint-policy, platser, filtrering, domänundantag, blockeringssidor, felsökning och återställning beskrivs därför centralt i Konfigurera Sophos DNS Protection för endpoints.

För denna Protected Browser-integration räcker en beredskapskontroll före piloten:

DNS-komponenten är installerad på pilotenheterna; beroende på licensen kan den heta DNS och ZTNA.
Endpoint-policyn som tilldelats pilotenheterna eller pilotgrupperna är aktiv och Använd Sophos DNS Protection är aktiverat.
Den valda Standardplatsen, eller en egen plats, använder anslutningsmetoden Säker DNS. En nyskapad plats får inte använda en annan anslutningsmetod för denna Endpoint-väg.
Den förväntade filtreringspolicyn är tilldelad platsen. En filtreringspolicy kan tilldelas flera platser eller brandväggar, men varje enskild plats kan endast kopplas till en filtreringspolicy. Om filtreringen behöver kontrolleras gäller även följande gränser: DNS Protection stöder högst 50 filtreringspolicyer; Tillåt tillåter alla kategorier i en grupp, Blockera blockerar dem och Ange bestämmer åtgärden per kategori. Skapa och ändra filtreringspolicyer enligt den länkade guiden.
Det interna testnamnet finns där som ett undantag så att den avsedda lokala DNS-tjänsten fortsätter att lösa det.

Sophos Endpoint fångar därefter upp DNS-trafik, förutom de undantagna domänerna, och vidarebefordrar den via HTTPS till DNS Protection. Svaren går direkt till applikationen. Utan aktiverad integration behandlar den lokala DNS-tjänsten frågorna som tidigare. Domänlistor, NXDOMAIN-återförsök och certifikatdistribution konfigureras inte på nytt i den här artikeln, utan planeras och kontrolleras enligt den länkade guiden.

Tillhandahålla ZTNA för Protected Browser

ZTNA måste vara färdigkonfigurerat före webbläsarintegrationen. Protected Browser ansluter till ZTNA-gatewayen och möjliggör därmed kontrollerad åtkomst till interna applikationer och privata molnmiljöer. Den gemensamma ZTNA-konfigurationen finns kvar i det länkade ZTNA-runbooket; den upprepas inte här som en andra, potentiellt avvikande process.

Aktivera därefter Tvinga Protected Browser för agentlös åtkomst till applikationer och resurser utom RDP och SSH. Sophos dokumenterar ingen tillförlitlig menysökväg eller ytterligare formulärfält för detta. Använd därför endast brytaren i den ZTNA-konfiguration som visas i din egen tenant. Om den saknas ska du stanna här i stället för att gissa en sökväg från en annan produktvy.

RDP och SSH är en separat variant. Sophos kräver en särskild ZTNA-konfiguration för agentlösa RDP- respektive SSH-resurser. Ett allmänt webbapplikationstest eller enbart aktivering av Tvinga Protected Browser validerar inte den vägen.

Validera piloten

Valideringen skiljer avsiktligt mellan DNS och ZTNA. Börja med att testa exakt en pilotenhet med en behörig användare.

Kontrollera DNS-resultatet

Förväntade resultat:

Den tillåtna offentliga testdomänen löses och kan nås.
Den blockerade testdomänen blockeras enligt den tilldelade filtreringspolicyn.
Det interna testnamnet använder den avsedda lokala DNS-tjänsten och förblir nåbart.
DNS-frågor från pilotenheten visas vid den förväntade platsen eller i tillhörande DNS-rapportering.
En applikation med eget Secure DNS- eller DNS-over-HTTPS-beteende testas separat, i stället för att dra slutsatser om alla applikationer från enbart ett webbläsartest.

Om en förväntad träff saknas ska du inte omedelbart lätta på filtreringen. Kontrollera först den installerade komponenten, den Endpoint-policy som faktiskt är aktiv, Använd Sophos DNS Protection, Secure DNS-platsen och den resolver som faktiskt används. Ytterligare DNS-felsökning finns i den länkade guiden.

Kontrollera ZTNA-resultatet

Öppna den förberedda privata testresursen i Protected Browser med den behöriga användaren. Ett lyckat resultat innebär att inloggning, ZTNA-gateway, resurstilldelning och applikation fungerar tillsammans. Låt sedan en användare utanför den godkända gruppen bekräfta det negativa fallet: resursen får inte vara tillgänglig eller nåbar för den användaren.

Logga DNS- och ZTNA-testet separat med tidpunkt och resultat. Då förblir det tydligt vilken väg som påverkas av ett senare fel.

Felsökning efter symptom

DNS fungerar inte på pilotenheten

Kontrollera först att det är en Windows-endpoint som stöds, att Sophos Endpoint och DNS-komponenten är installerade och att den faktiskt aktiva Endpoint-policyn aktiverar Använd Sophos DNS Protection. Kontrollera sedan den valda Secure DNS-platsen och HTTPS-anslutningen till DNS Protection. Windows Server och macOS är inte lämpliga jämförelsetester för denna Endpoint-policyväg. Ändringar av policy, plats, filter, domän eller återställning utförs enligt den länkade guiden.

Om du även kontrollerar en nätverksbaserad plats för att avgränsa felet behöver den en giltig offentlig IPv4-adress eller ett upplösningsbart FQDN för platsen. RFC 1918-adresser inom 10.0.0.0/8, 172.16.0.0/12 eller 192.168.0.0/16 är inte giltiga offentliga adresser för detta. Alla adresser som börjar med 172. eller 192. är dock inte privata; en sådan förkortning får därför inte användas som kontrollkriterium.

ZTNA-inloggningen fungerar, men inte applikationen

Då är DNS Protection inte den första misstänkta orsaken. Kontrollera användar- och grupptilldelningen, ZTNA-resursen, den valda gatewayen samt applikationens nåbarhet ur gatewayens perspektiv. Bekräfta sedan att Tvinga Protected Browser är aktivt för den avsedda agentlösa åtkomsten. Jämför inte RDP och SSH med den allmänna webbapplikationsvägen.

Om Tvinga Protected Browser saknas eller om processen som visas i tenant-miljön är oklar ska du inte ändra konfigurationen mer vid denna punkt. Ansvarigt ZTNA-team måste reda ut licens, behörighet och aktuell produktvy innan skyddsmekanismer kringgås eller resurser skapas på nytt.

Säker återställning och avveckling

Avveckla inte DNS och ZTNA samtidigt. Dokumentera pilotenheter, berörd väg, ansvarig person och det senaste lyckade testresultatet före varje återställning.

Återställ DNS-vägen uteslutande enligt återställningsprocessen i den länkade guiden och validera därefter både intern och offentlig namnupplösning. Ta inte bort den gemensamma programvarukomponenten DNS och ZTNA som en omedelbar åtgärd, eftersom det även kan påverka ZTNA-vägen.

Sophos dokumenterar ingen fullständig borttagnings- eller återställningsprocess för Tvinga Protected Browser. För ZTNA ska därför varken gatewayen eller gemensamt använda identitets-, DNS-, certifikat- eller policyobjekt tas bort som en förmodad omedelbar återställning. Om åtkomsten måste stoppas ska ansvarigt ZTNA-team få den berörda resursen och användargruppen; upprepa sedan det negativa testet. Utan ett reversibelt steg som har bekräftats i tenant-miljön avslutas återställningen här.

Drift och regelbunden kontroll

Efter piloten ska olika personer ansvara för DNS- respektive ZTNA-vägen. Upprepa berörda positiva och negativa tester efter ändringar i Endpoint DNS-konfigurationen eller i användargrupper, gateway eller ZTNA-resurs. Kontrollera regelbundet att Workspace Protection är tillgängligt, att Endpoint-komponenten är installerad, DNS-beredskapspunkterna, ZTNA-åtkomsten och den dokumenterade återställningsvägen.

Beslut om fortsatt drift ska baseras på den aktuella produktkonfiguration som visas i tenant-miljön och den aktuella hjälpen för respektive komponent. Härled inga migrationsfrister, avstängningsdatum eller EOL-datum från historiska meddelanden. Om Sophos ändrar ett krav eller en produktvy ska piloten först genomföras igen innan den breda utrullningen anpassas.