Ställa in Sophos ZTNA: översikt och ordning

Sophos Zero Trust Network Access, ZTNA för kort, ersätter inte bara en VPN med en ny knapp. ZTNA består av identitet, gateway, resurser, policyer, DNS, certifikat och en klient- eller agentlös åtkomstväg. Om dessa byggstenar ställs in i fel ordning kan inloggningen fungera, men applikationen kommer fortfarande att vara otillgänglig.

Den här artikeln klassificerar installationen och visar den förnuftiga ordningen. Planera och skapa Sophos ZTNA Gateway är också lämplig för den specifika gatewaydelen.

För den leverantörsneutrala grunden om Zero Trust, ZTNA och skillnaden mot VPN, börja med Zero Trust enkelt förklarat: ZTNA i stället för klassisk VPN.

Krav

Före ett ZTNA-test bör dessa punkter klargöras:

Sophos Central Account med lämplig ZTNA-licens eller testmiljö.
Microsoft Entra ID, tidigare Azure AD, eller en stödd identitetsleverantör med underhållna användare och grupper.
Beslut mellan agentlös åtkomst, ZTNA-klient eller blandad operation.
Gatewaymodell: On-premise Gateway, Sophos Cloud Gateway eller Sophos Firewall som gatewayvariant.
DNS-namn för gateway och publicerade resurser.
Jokerteckencertifikat eller matchande certifikatkoncept.
Intern tillgänglighet för applikationerna ur gatewayens perspektiv.
Ägare för policyer, certifikat, loggar och efterföljande ändringar.

Aktivera Sophos Central ZTNA

Om ZTNA ännu inte är aktivt kan testet förberedas med ett befintligt eller nytt Sophos Central-konto. Det är viktigt att hyresgästen, användarkällan och de efterföljande resurserna matchar det planerade testet. Ett ZTNA-test utan en riktig målapplikation säger lite om latens, DNS, webbläsarupplevelse eller policydesign.

Att komma igång via Sophos testsida kan vara användbart för initiala laboratoriemiljöer: Skapa ett Sophos Central-testkonto.

Plancertifikat och DNS

ZTNA kräver ett certifikat som matchar den planerade gatewayen och resursdomänerna. I många miljöer är ett jokerteckencertifikat det enklaste alternativet eftersom flera resurser kan publiceras under samma domän.

För produktiva miljöer bör du klargöra utgångsdatum, förnyelse, ansvar och övervakning av certifikatet. Let’s Encrypt kan vara användbart för att testa om ett lämpligt jokerteckencertifikat ännu inte existerar. Processen är i Skapa Let’s Encrypt jokerteckencertifikat.

Inställningsordning

För en ren ZTNA-utbyggnad bör ordningen inte väljas godtyckligt:

Lägg till katalogtjänst: Synkronisera Microsoft Entra ID eller annan katalogtjänst som stöds med Sophos Central.
Lägg till identitetsleverantörer: Ställ in de identitetsleverantörer som krävs för autentisering.
Lägg till gateway: Planera och distribuera lämplig gatewaymodell för varje plats eller datasökväg.
Skapa resurser: Definiera applikationer med FQDN, port, åtkomsttyp och tillgänglighet.
Lägg till policyer: tilldela medvetet användargrupper, villkor och tillåtna resurser.
Testa klient- eller agentlös åtkomst: Verifiera med pilotanvändare att inloggning och applikation fungerar.

1. Synkronisera användare

För ZTNA behöver Sophos Central användare och grupper som senare kommer att användas i policyer. I Microsoft-miljöer är Microsoft Entra ID den typiska ingångspunkten. Det är avgörande att endast de grupper som krävs används och att namn, UPN, e-postadresser och gruppmedlemskap kan spåras senare.

Grunden finns i Lägg till Sophos Central Azure AD.

2. Lägg till identitetsleverantör

Efter katalogtjänsten ställs identitetsleverantören in. För Microsoft Entra ID inkluderar dessa vanligtvis klient-ID, hyresgäst-ID och klienthemlighet. Dessa värden är säkerhetsrelevanta konfigurationsdata och bör behandlas som åtkomstdata.

3. Lägg till gateway

ZTNA Gateway ansluter användaråtkomst till interna applikationer. Beroende på design står den som en lokal gateway i ditt eget nätverk, drivs via Sophos Cloud Gateway eller använder en Sophos brandväggsvariant som stöds.

Gatewayplanering är ett separat arbetssteg eftersom DNS, certifikat, nätverkssegment, DNAT, intern tillgänglighet och loggar måste passa ihop. Processen är i Planera och skapa Sophos ZTNA Gateway.

4. Skapa resurser

Resurser är de applikationer som ska vara tillgängliga via ZTNA. För att göra detta bör du dokumentera följande för varje ansökan:

intern FQDN eller intern destinations-IP,
protokoll och port,
Åtkomsttyp, till exempel webbapp eller TCP-app,
nödvändig användargrupp,
önskat externt namn,
Testa användar- och acceptanskriterier.

En resurs bör inte publiceras i större utsträckning än nödvändigt. Speciellt med adminverktyg, RDP, SSH eller interna specialistapplikationer behöver du tydliga grupper, loggning och en ägare.

5. Lägg till policyer

Policyer kopplar användargrupper till resurser. I praktiken bör man börja med en liten pilotgrupp och inte direkt aktivera hela avdelningar eller alla anställda.

Bra policyfrågor:

Vilken grupp behöver verkligen denna applikation?
Är agentlös åtkomst tillräcklig eller krävs ZTNA-klienten?
Behöver åtkomsten begränsas av enhet, skick eller plats?
Hur går loggning till och vem kontrollerar misslyckade försök?
Finns det en reservväg om ZTNA eller identitetsleverantören störs?

6. Testa åtkomst

Efter installationen är det inte bara inloggningen som ska testas. Det avgörande är om den verkliga tillämpningen kan uppnås och om policyn fungerar exakt som planerat.

Kontrollpunkter:

Testanvändaren är i rätt grupp.
DNS pekar på den förväntade gatewayen eller CNAME.
Certifikatet accepteras utan webbläsarvarning.
Registrering hos identitetsleverantören fungerar.
Resursen öppnas med den schemalagda åtkomsttypen.
Obehöriga användare avvisas tydligt.
Loggar i Sophos Central, Gateway och Firewall kan utvärderas.

Vanliga misstag

Gateway, DNS och certifikat kontrolleras endast efter policyerna.
Resurser publiceras för mycket.
Testanvändare har fler gruppmedlemskap än vanliga användare.
Intern DNS-upplösning fungerar bara på LAN, men inte ur gatewayens perspektiv.
ZTNA är planerad att ersätta alla VPN- eller adminanslutningar, även om vissa speciella fall fortfarande kan kräva VPN, Jump Host eller annan åtkomstmodell.