Sophos Mobile: kontrollera SCEP-certifikat och anslutningsvägar säkert

SCEP kan installera och förnya certifikat i Sophos Mobile (MDM). Den här genomgången gäller anslutningen till SCEP i den egna Sophos Mobile-miljön och de olika nätverksförbindelserna som måste hållas isär – inte en fullständig konfiguration av en Windows-CA, en wifi-/VPN-infrastruktur eller samtliga policykomponenter för Android, Apple och Windows. Installation och förnyelse via SCEP enligt denna genomgång stöder inte Chromebook-enheter.

Innan något ändras i produktion: De ansvariga för CA/PKI, nätverk och MDM samt vid behov den som driver autentiseringstjänsten för wifi/VPN behöver tillsammans bestämma vilka enheter och registreringslägen som berörs, om och hur en viss tjänst kan använda SCEP-certifikatet och hur enheterna kan nås om nätverksanslutningen försvinner. Varken Save eller en distribuerad policy bevisar att ett klientcertifikat har utfärdats, förnyats eller kopplats till en wifi-/VPN-profil.

Tre förbindelser i stället för en generell portöppning

Sophos Fusion ansluter till organisationens egen SCEP-kompatibla CA; den hanterade enheten kommunicerar separat med Sophos Mobile. Att sedan autentisera mot wifi-/VPN-tjänsten med just SCEP-certifikatet fungerar inte automatiskt utan måste verifieras för respektive plattform och profil. Med miljön avses här den egna Sophos Mobile-miljön; MDM är dess enhetshantering.

Fastställ miljöns region: Kontrollera URL:en i webbläsarens adressfält i Sophos Fusion under My Products > Mobile. Regionen står i värdnamnets första del, alltså före den första punkten, direkt efter smc-user-if-cloudstation-. I exemplet smc-user-if-cloudstation-eu-west-1 är regionen eu-west-1. Använd regionen från den egna webbläsarens URL för trafikreglerna, inte exempelvärdet eller likadan text i URL-sökvägen eller frågeparametrarna. Hostingregionen väljs när Sophos Fusion-kontot skapas; för befintliga konton fastställs den här utifrån den faktiska URL:en i webbläsaren. Denna administrationsvärd är varken en enhetsslutpunkt eller en SCEP-server. Samma sätt att fastställa regionen gäller även för Mobile Threat Defense, men styrker inte att MTD har en separat SCEP-funktion.
Fusion till egna servrar (inkommande): I den aktuella regionala käll-IP-listan för beslut om den konkreta regeln för inkommande trafik anges TCP 443 för SCEP och TCP 636 för den separata LDAP-/AD-anslutningen. Tillåt bara de Mobile-käll-IP-adresser som för närvarande publiceras där för den faktiska regionen för miljön, och bara till den egna avsedda SCEP- respektive AD-servern. Använd inte exempelregionen och skapa ingen global eller obegränsad regel för inkommande trafik. LDAP-/AD-anslutningen används för användarautentisering med AD-inloggningsuppgifter vid enhetsregistrering via Apple Business (tidigare Apple Business Manager), Google Zero-touch eller Samsung KME. Denna autentisering är varken det första utfärdandet av ett SCEP-klientcertifikat till en hanterad enhet eller en senare certifikatförnyelse.
Enhet till Sophos Mobile (utgående): Hanterade enheter behöver HTTPS 443 till den regionala värden smc-device-if-cloudstation-. De fullständiga enhetsdestinationerna är smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com för eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com för eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com för us-west-2 och smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com för us-east-2, samtliga via HTTPS 443. Använd endast destinationen för den faktiska regionen för miljön som identifierats tidigare; dessa enhetsdestinationer är varken administrationsvärden eller de egna SCEP-destinationerna. Dessutom krävs anslutningar för push, registrering och andra plattformsfunktioner. Följande separata kontroller och interna plattformsguider hjälper till att skilja dessa åt utifrån enhetstyp och den funktion som faktiskt används; de fyra regionala enhetsvärdarna är inte en fullständig lista över destinationer för utgående trafik. Dessa ytterligare destinationer är varken käll-IP-adresser för inkommande SCEP-trafik eller en generell lista över SCEP-portar.

Håll övriga beroenden för enheternas utgående trafik separata:

Windows-push: För Windows-datorer är destinationerna *.notify.windows.com, *.wns.windows.com och *.notify.live.net dokumenterade för Windows Notification Service (WNS) och Microsoft Push Notification Service (MPNS), samtliga via HTTPS 443. Detta är Windows-pushanslutningar, inte portar för inkommande SCEP-trafik.
Android-registrering och provisionering: Använd Android Enterprise-guiden för Android och provisioneringsguiden för förutsättningarna för QR/Zero-touch/KME; där måste det fortfarande kontrolleras vad som är tillåtet för den specifika enheten och det specifika läget.
Apples push för enhetshantering: För hantering av iPhone, iPad och Mac ska Apples pushanslutning kontrolleras separat. Certifikatidentitet, förnyelse och den kontroll av tillgänglighet som finns för iPhone/iPad beskrivs i APNs-guiden.
Information om Apple-uppdateringar och efterlevnad: Separat behöver Sophos Mobile information om tillgängliga Apple-uppdateringar: Om den avsedda Apple-tjänsten inte går att nå saknas denna information och efterlevnadsregler för obligatoriska uppdateringar får ingen effekt. Kontrollera den egna nätverksvägen och begränsningarna för plattform, OS och registreringsläge i guiden för efterlevnad. Apples push för enhetshantering och uppdateringsinformation är krav på enheternas utgående trafik, inte slutpunkter för inkommande SCEP-trafik eller certifikatutfärdande.
IXM-apptrafik: För iPhone/iPad med Sophos Intercept X for Mobile (IXM) ska appens separata anslutningar kontrolleras i IXM-nätverksguiden; där beskrivs vilka tjänster och portar som hör ihop samt begränsningar utifrån appversion, edition, hanteringssätt och den funktion som faktiskt används. Detta är inte inkommande SCEP-anslutningar; Apple-rubriken i en nätverkslista innebär inte att IXM är tillämpligt på Mac-datorer.

En dokumenterad destinationsadress är inte i sig ett bevis på att den kan nås från det egna nätverket.

Vid felsökning ska man därför dokumentera separat om (a) Fusion når den egna SCEP-slutpunkten, (b) enheten når Sophos Mobile och får sin policy och (c) wifi-/VPN-tjänsten accepterar det utfärdade certifikatet. Att en väg fungerar ersätter inte kontrollerna av de andra två.

Fastställ förtroende och ansvar i förväg

Begrepp inför beslutet: PKI är certifikatinfrastrukturen och CA den utfärdande certifikatutfärdaren. SCEP begär klientcertifikatet; Subject och SAN (Subject Alternative Name), samt vid behov UPN (användaridentifierare), avgör vilken identitet som ska kontrolleras. EAP är autentiseringsmetoden för en wifi-tjänst. Import av PKCS #12 (.pfx) är ett annat distributionssätt än SCEP; ett sådant certifikat förnyas inte automatiskt av SCEP:s förnyelseintervall.

Avgör följande tre förtroendefrågor var för sig, även om samma CA har flera roller i den egna PKI-miljön:

Anslutning till SCEP-servern: Före SCEP lägger MDM-teamet till en konfiguration för Root certificate med SCEP-serverns CA-certifikat i rätt policy. För Android Enterprise-enhetspolicyer ska certifikatet dessutom väljas i SCEP-fältet Root certificate bland certifikaten i samma policy. Det är inte det utfärdade klientcertifikatet och bevisar ingen klientidentitet.
Utfärdad klientidentitet: För Android Enterprise och iOS måste Subject efter att alla platshållare har ersatts vara ett giltigt X.500-namn för den avsedda personen eller enheten. Bestäm SAN-typ och SAN-värde separat; AD user logon name betecknar användarens AD-UPN i enheternas SCEP-fält, inte någon valfri enhetsidentifierare. iOS-fältet CA name är ett namn som CA:n förstår, till exempel för att skilja mellan dess instanser – inte ett bevis för utfärdaren eller ett förtroendeankare. PKI-/CA-teamet kontrollerar därför på det faktiskt utfärdade certifikatet utfärdande CA och certifikatkedja, tillåtna värden för Subject/SAN/UPN, nyckelanvändning och åtkomst till den privata nyckeln. MDM-/tjänstteamet stämmer av hur den tjänst som ska använda certifikatet faktiskt matchar identiteten; använd inte exempelvärden som platshållare.
Tjänstens förtroende: Om wifi/VPN ska använda klientcertifikatet måste tjänsten lita på dess CA-kedja. Vid EAP måste man dessutom kontrollera att enheten litar på wifi-serverns certifikat. Inget av detta följer automatiskt av att SCEP-servern är betrodd.

Ansvariga före godkännande:

PKI-/CA-teamet: Kontrollera en SCEP-kompatibel Windows-CA, att /CertSrv/MSCEP_ADMIN och /CertSrv/MSCEP går att nå samt behörighet att skapa challenge-lösenord och registrera certifikat. Lägg inte challenge-lösenord, tjänstens inloggningsuppgifter eller privata nycklar i ärenden eller skärmbilder. Den historiska hänvisningen till Windows 2003 i Sophos hjälpdokumentation är inget aktuellt löfte om serverstöd.
Nätverksteamet: Kontrollera målserverns FQDN, vägen via TLS-/HTTP-proxy och en snävt begränsad tillåtelselista över regionala käll-IP-adresser mot den verkliga nätverkstopologin. Kontrollera separat enheternas utgående trafik, push och en oberoende hanterings-/nätverksväg för nödlägen. Ersätt inte kontrollerna med att stänga av filtreringen generellt.
MDM-/tjänstteamet: Fastställ plattform, enhets- eller användarpolicytyp och registreringsläge före konfigurationen. Använd en Android Enterprise device policy för den Android Enterprise-enhetskonfiguration som beskrivs här; en Work Profile-policy gäller ett annat hanteringsområde. Android Enterprise-guiden förklarar detta val av läge. Behandla SCEP-policykomponenten för iOS-enheter separat och använd den inte som belägg för iOS-användarpolicyer. Gemensamma och plattformsspecifika SCEP-fält kontrolleras separat i pilotförfarandet nedan. Stoppa arbetet om policytypen inte har bekräftats eller registreringsläget inte stöds.

Stoppa arbetet om den avsedda identiteten eller CA-förtroendekedjan är oklar, om enhetstypen eller läget inte motsvarar den kontrollerade policyn, eller om enheten bara kan hanteras via just det wifi/VPN som ska ändras och det inte finns någon oberoende väg tillbaka.

Ett utfärdat certifikat är inte automatiskt kopplat till wifi/VPN

SCEP-konfigurationen begär ett certifikat från CA:n. Kontrollera följande separat innan wifi/VPN ändras:

Val av certifikat för wifi: I Android Enterprise-enhetspolicyer och iOS-enhetspolicyer används Identity certificate för att välja ett certifikat från en Client certificate-konfiguration i samma policy. Denna konfiguration importerar en PKCS #12-fil (.pfx); det är ett annat distributionssätt än SCEP. Detta styrker inte att ett SCEP-utfärdat certifikat går att välja i wifi-fältet. Ett EAP-wifi för Android Enterprise får inte vara dolt: SSID:t måste sändas ut.
Förnyelse och förtroende för servern: Planera import, giltighet och utbyte av PKCS #12-certifikat separat; SCEP renewal interval förnyar dem inte automatiskt. Rotcertifikatet för EAP-servern i wifi-policyn är inte nödvändigtvis samma förtroende som för SCEP-servern.

Inte heller VPN har en enhetlig SCEP-koppling: För Android Enterprise väljer policyn en redan installerad hanterad VPN-app från Google Play; anslutningsparametrarna finns i appens Managed Configuration. För iOS beror certifikatautentisering och certifikatval på anslutningstypen. Detta val i sig styrker inte att ett SCEP-certifikat kan användas. Före en wifi-/VPN-pilot ska stödet för att koppla certifikatet till profilen och beteendet efter förnyelse bekräftas för plattformen, policytypen, autentiseringsmetoden och vid behov VPN-klienten med relevant leverantörsdokumentation eller i en avgränsad pilot. Saknas belägg ska piloten begränsas till utfärdande och förnyelse via SCEP; påbörja ingen wifi-/VPN-migrering och dra inte tillbaka den befintliga förtroendekedjan.

Konfigurera SCEP enbart i en avgränsad pilot

Gå till Setup > Sophos setup > SCEP och stäm av SCEP-serverns URL https://<server>/CertSrv/MSCEP och challenge-URL:en https://<server>/CertSrv/MSCEP_ADMIN med PKI-teamet. Använd en behörig användare i formatet username@domain och dennes lösenord; kontrollera tillåtna teckentyper för challenge-lösenordet och behörigheterna med PKI-teamet. Välj de överenskomna teckentyperna i fältet Challenge characters för challenge-lösenordet innan du klickar på Save, och behåll den challenge-längd som Sophos har förinställt. Tillämpa en annan PKI-föreskrift bara som ett separat dokumenterat, godkänt och testat undantag. Om en HTTP-proxy är aktiverad används Use HTTP proxy till att börja med för denna anslutning; inaktivera alternativet bara om Sophos Mobile avsiktligt ska nå SCEP-servern utan att gå via proxyn.
Klicka på Save och dokumentera anslutningstestet till SCEP-servern. Vid fel: kontrollera URL, certifikatförtroende, proxy, behörigheter och tillåtna käll-IP-adresser tillsammans med de ansvariga – ändra inte omedelbart policyer i stor skala.
Skapa först en policy eller redigera en befintlig policy som passar pilotens läge. Använd policyguiden för att skapa policyn, redigera konfigurationer, spara och sedan tilldela policyn till piloten; kontrollera plattformen och vilka policytyper som stöds i förväg. Konfigurera i denna policy först Root certificate med SCEP-serverns CA-certifikat, därefter SCEP och SCEP renewal interval. För SCEP-fälten URL och Challenge anger policyhjälpen för Android Enterprise- och iOS-enheter platshållarna %_SCEPPROXYURL_% respektive %_CACHALLENGE_% för den tidigare konfigurerade SCEP-serverns URL respektive challenge-URL. Stäm av Subject, SAN/UPN, nyckelstorlek och användningsområde med PKI-teamet och måltjänsten för just den plattformen. Tilldela policyn enbart den avgränsade pilotgruppen. PKI- och MDM-teamen fastställer i förväg var policyleverans, enhetscertifikat samt utfärdande/förnyelse i PKI kan observeras för just denna plattform och detta policyläge; om kopplingen till wifi/VPN också är belagd ska även tjänstens logg bestämmas. Utgå inte från att samma statusfält eller loggnamn finns för alla enheter. SCEP renewal interval styr när enheten gör en begäran, inte om den lyckas.
Plattformsspecifika SCEP-fält: För Android Enterprise-enhetspolicyer ska ett igenkännbart Alias name anges för valdialoger, och SCEP-serverns CA-certifikat ska väljas från samma policy i fältet Root certificate. För iOS-enhetspolicyer ska CA name stämmas av med CA:n; Retries anger antalet nya försök efter serversvaret pending, och Retry delay anger intervallet i sekunder. Beskriv inte dessa iOS-fält som Android-fält. Key size måste stämma överens med SCEP-serverns konfiguration. För Certificate usage ska den avsedda användningen stämmas av separat med PKI-teamet och tjänsten som Use as digital signature eller Use for encryption; hitta inte på någon standardstorlek eller något standardval.
För Type of Subject Alternative Name och Value of Subject Alternative Name ska den dokumenterade typen och värdet kontrolleras var för sig: RFC 822 name för en giltig e-postadress, DNS name för CA-serverns DNS-namn eller Uniform resource identifier för dess fullständiga URL. AD user logon name är fortfarande användarens AD-UPN. Fältbeskrivningen ersätter inte identitetskontrollen på det faktiskt utfärdade certifikatet.
Första utfärdandet efter att policyn har levererats: Jämför utfärdare/kedja, Subject och SAN/UPN, serienummer, giltighetstidens början och slut samt nyckelanvändning på pilotenheten med de godkända PKI-kraven. En AD-enhetsregistrering räknas inte som utfärdande av ett SCEP-klientcertifikat. Om inget utfärdande kan observeras: stoppa arbetet och godkänn ingen rotation.
Senare förnyelse: PKI- och MDM-teamen bestämmer en observationsperiod utifrån intervallet och certifikatets giltighetstid. Kontrollera under den perioden att enheten har ett nytt giltigt certifikat med nytt serienummer och korrekta identitets- och utfärdarvärden samt att motsvarande PKI-händelse har bekräftats. Om förnyelsen inte kan observeras eller inte sker under pilotperioden får rotationen inte godkännas som validerad.
Endast om kopplingen till wifi/VPN har belagts i piloten: Kontrollera i den berörda tjänstens logg att lyckad autentisering före och efter förnyelsen går att knyta till just denna pilotenhet och detta certifikat. Utan tjänstelogg eller bekräftad koppling: inget byte av wifi/VPN.

Rotation och väg tillbaka

Innan SCEP-URL, åtkomst för challenge eller CA ändras, eller ett separat verifierat byte av wifi-/VPN-profil genomförs, ska gamla och nya policytilldelningar, förtroendeankare och berörda grupper dokumenteras i pilotprotokollet för varje enhetsklass. PKI-, nätverks- och MDM-teamen fastställer vilken hanteringsväg som faktiskt kan nås oberoende av det certifikatbaserade nätverk som ska bytas, vem som ansvarar för lokal återställning och vilket kriterium som ska stoppa arbetet. Den konkreta metoden för att tilldela eller ta bort en policy på nytt och dess effekt på enheterna måste valideras i piloten för plattformen och registreringsläget; här förutsätts ingen universell återställningsmetod. Enligt Sophos är Uninstall policy endast avsett för Android-enhetspolicyer, Knox-containerpolicyer och iOS-enhetspolicyer; för andra typer, däribland Android Enterprise-enhetspolicyer, ska policyn i stället uppdateras eller en annan tilldelas. Det är därmed inte styrkt att en redan installerad CA eller ett klientcertifikat tas bort eller återställs.

Beslut före utrullning: Distribuera den nya förtroendekedjan först i piloten endast om parallell distribution stöds i det aktuella läget. Kontrollera nytt utfärdande och faktisk senare förnyelse. Vid ett planerat byte av wifi/VPN ska dessutom den verifierade profilkopplingen och autentiseringen mot tjänsten kontrolleras före och efter förnyelsen. Ta bort gamla profiler och förtroendeankare först efter kontrollerat godkännande och planerad utrullning. Dra inte tillbaka den gamla CA:n i förtid om den fortfarande behövs för befintliga anslutningar.

Vid fel: avgör åtgärd utifrån om enheten går att nå:

Stoppa alla ytterligare tilldelningar och återkallelser. Behåll tidigare CA, profiler och förtroendeankare; involvera ansvariga för PKI, nätverk och MDM utifrån pilotprotokollet.
Enheten kan nås via den kontrollerade oberoende vägen: MDM-teamet återställer den dokumenterade tidigare tilldelningen av policy/nätverk/CA med den metod för tilldelning eller borttagning som i förväg har validerats för detta läge; PKI- och nätverksteamen kontrollerar sina respektive delar. Om wifi/VPN har ändrats ska autentiseringen testas igen i tjänstens logg.
Enheten är offline eller saknar en oberoende väg: Den i förväg utsedda lokala återställningsansvariga använder enbart den lokala återställningsmetod som har planerats och testats i förväg; kontrollera sedan att enheten går att nå och, om relevant, att autentiseringen mot tjänsten fungerar. Att bara återställa en molninställning är ingen verifierad återställning för enheter som har gått offline. Om den lokala metoden inte har verifierats ska man varken påstå att säker fjärråterställning är möjlig eller utvidga ändringen.

Utan observerat första utfärdande, förnyelse och en kontrollerad väg tillbaka får SCEP-bytet inte genomföras i produktion; ett byte av wifi/VPN kräver dessutom en verifierad certifikatkoppling och lyckad användning före och efter förnyelsen.

Begränsning av underlaget: Detta är ett källbaserat utkast som inte har testats i en Sophos Mobile-miljö eller på enheter. Stöd för OS- och serverversioner, klientbeteende vid förnyelse offline och den konkreta identitetsmatchningen för EAP/VPN måste bekräftas separat i den egna miljön.