Sophos Mobile: SCEP-certificaten en verbindingen veilig controleren

Met SCEP kan Sophos Mobile (MDM) certificaten installeren en vernieuwen. Deze procedure behandelt de SCEP-koppeling aan tenantzijde en de verbindingen die daarbij van elkaar moeten worden onderscheiden — niet de volledige inrichting van een Windows-CA, wifi-/VPN-infrastructuur of alle Android-, Apple- en Windows-policy-payloads. SCEP-installatie en -vernieuwing volgens deze procedure ondersteunen geen Chromebooks.

Vóór een wijziging in productie: De verantwoordelijken voor CA/PKI, netwerk en MDM en, waar van toepassing, de beheerder van de wifi-/VPN-authenticatiedienst bepalen samen welke apparaten en inschrijfmodi betrokken zijn, of en hoe een specifieke dienst het SCEP-certificaat kan gebruiken en hoe de apparaten bereikbaar blijven als het netwerk wegvalt. Noch Save noch een uitgerolde policy bewijst dat een clientcertificaat is uitgegeven, vernieuwd of aan een wifi-/VPN-profiel gekoppeld.

Drie verbindingen in plaats van één algemene poortregel

Sophos Fusion maakt verbinding met de eigen SCEP-geschikte CA; het beheerde apparaat communiceert afzonderlijk met Sophos Mobile. Latere authenticatie bij een wifi-/VPN-dienst met precies dat SCEP-certificaat is niet automatisch gegarandeerd en moet per platform en profiel worden aangetoond. Met tenant bedoelen we hier de eigen Sophos Mobile-omgeving; MDM is het apparaatbeheer daarvan.

Tenantregio bepalen: Controleer in Sophos Fusion onder My Products > Mobile de URL in de adresbalk van de browser. De regio staat in het eerste deel van de hostnaam, dus vóór de eerste punt, direct na smc-user-if-cloudstation-. In het voorbeeld smc-user-if-cloudstation-eu-west-1 is de regio eu-west-1. Gebruik voor de netwerkregels de regio uit de eigen browser-URL, niet de voorbeeldwaarde of dezelfde tekst in het URL-pad of de queryparameters. De hostingregio wordt gekozen bij het aanmaken van het Sophos Fusion-account; voor bestaande accounts wordt die hier bepaald aan de hand van de werkelijke browser-URL. Deze adminhost is noch een apparaatendpoint noch een SCEP-server. Deze manier van regiobepaling geldt ook voor Mobile Threat Defense, maar toont geen zelfstandige MTD-SCEP-functionaliteit aan.
Fusion naar eigen servers (inkomend): Voor SCEP vermeldt de actuele regionale lijst met bron-IP-adressen voor de concrete vrijgave van inkomend verkeer TCP 443 en voor de daarvan gescheiden LDAP-/AD-verbinding TCP 636. Sta alleen de Mobile-bron-IP-adressen toe die daar momenteel voor de werkelijke tenantregio zijn gepubliceerd, en alleen naar de betreffende eigen SCEP- of AD-bestemming. Neem de voorbeeldregio niet over en maak geen algemene of onbeperkte inkomende regel. De LDAP-/AD-verbinding dient voor gebruikersauthenticatie met AD-aanmeldgegevens bij apparaatregistratie via Apple Business (voorheen Apple Business Manager), Google Zero-touch of Samsung KME. Deze authenticatie is niet hetzelfde als de eerste uitgifte van een SCEP-clientcertificaat aan een beheerd apparaat of de latere certificaatvernieuwing.
Apparaat naar Sophos Mobile (uitgaand): Beheerde apparaten hebben HTTPS 443 nodig naar de regionale smc-device-if-cloudstation--host. De volledige apparaatbestemmingen zijn smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com voor eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com voor eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com voor us-west-2 en smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com voor us-east-2, elk via HTTPS 443. Gebruik alleen de bestemming van de eerder vastgestelde werkelijke tenantregio; deze apparaatbestemmingen zijn niet de adminhost en niet de eigen SCEP-bestemmingen. Daarnaast zijn verbindingen voor push, inschrijving en andere platformfuncties nodig. De onderstaande afzonderlijke controles en interne platformhandleidingen delen deze in naar apparaattype en daadwerkelijk gebruikte functie; de vier regionale apparaathosts vormen geen volledige lijst voor uitgaand verkeer. Deze aanvullende bestemmingen zijn geen bron-IP-adressen voor inkomend SCEP-verkeer en ook geen algemene lijst met SCEP-poorten.

Houd overige afhankelijkheden voor uitgaand apparaatverkeer gescheiden:

Windows-push: Voor Windows-computers zijn voor Windows Notification Service (WNS) en Microsoft Push Notification Service (MPNS) de bestemmingen *.notify.windows.com, *.wns.windows.com en *.notify.live.net gedocumenteerd, elk via HTTPS 443. Dit zijn Windows-pushverbindingen, geen poorten voor inkomend SCEP-verkeer.
Android-inschrijving en provisioning: Raadpleeg voor Android de Android Enterprise-handleiding en voor de QR-/Zero-touch-/KME-vereisten de provisioninghandleiding; ook daar moet de vrijgave voor het specifieke apparaat en de modus worden gecontroleerd.
Apple-beheerpush: Controleer voor het beheer van iPhones, iPads en Macs afzonderlijk de Apple-pushverbinding; certificaatidentiteit, verlenging en de bereikbaarheidscontrole die op iPhone/iPad beschikbaar is, staan in de APNs-handleiding.
Apple-updateinformatie en compliance: Los daarvan heeft Sophos Mobile informatie over beschikbare Apple-updates nodig: als de daarvoor bedoelde Apple-dienst niet bereikbaar is, ontbreekt die informatie en hebben complianceregels voor verplichte updates geen effect. Controleer de eigen netwerkroute en de grenzen voor platform, besturingssysteem en inschrijvingsmodus in de compliancehandleiding. Apple-beheerpush en updateinformatie vereisen uitgaande apparaatverbindingen; het zijn geen inkomende SCEP-verbindingen of eindpunten voor certificaatuitgifte.
IXM-appverkeer: Controleer voor iPhone/iPad met Sophos Intercept X for Mobile (IXM) de afzonderlijke appverbindingen in de IXM-netwerkhandleiding; die beschrijft de bijbehorende diensten en poorten en de beperkingen per appversie, editie, beheervorm en daadwerkelijk gebruikte functie. Dit zijn geen inkomende SCEP-verbindingen; een Apple-kop in een netwerklijst betekent niet dat IXM ook op Macs van toepassing is.

Een gedocumenteerd bestemmingsadres bewijst nog niet dat het in het eigen netwerk bereikbaar is.

Leg bij een storing daarom afzonderlijk vast of (a) Fusion het eigen SCEP-endpoint bereikt, (b) het apparaat Sophos Mobile bereikt en zijn policy ontvangt en (c) de wifi-/VPN-dienst het uitgegeven certificaat accepteert. Succes op één pad vervangt de twee andere controles niet.

Vertrouwen en verantwoordelijkheden vooraf vastleggen

Begrippen voor de besluitvorming: PKI is de certificaatinfrastructuur; de CA is de certificerende instantie die de certificaten uitgeeft. SCEP vraagt het clientcertificaat aan; Subject en SAN (Subject Alternative Name), eventueel UPN (gebruikersidentificatie), bepalen welke identiteit moet worden gecontroleerd. EAP is de authenticatiemethode van een wifi-dienst. Een PKCS-#12-import (.pfx) is een andere manier van uitrollen dan SCEP; het geïmporteerde certificaat wordt niet automatisch vernieuwd door het SCEP-vernieuwingsinterval.

Beoordeel de drie vertrouwensvragen afzonderlijk, ook als dezelfde CA in de eigen PKI meerdere rollen vervult:

Verbinding met de SCEP-server: Het MDM-team voegt vóór SCEP een Root certificate-configuratie met het CA-certificaat van de SCEP-server toe aan de juiste policy. Selecteer bij apparaatpolicies voor Android Enterprise het certificaat daarnaast in het SCEP-veld Root certificate uit de certificaten van dezelfde policy. Dat is niet het uitgegeven clientcertificaat en bewijst geen clientidentiteit.
Uitgegeven clientidentiteit: Bij Android Enterprise en iOS moet Subject na vervanging van alle placeholders een geldige X.500-naam van de beoogde persoon of het apparaat zijn. Bepaal het SAN-type en de SAN-waarde afzonderlijk; AD user logon name verwijst in de SCEP-velden voor apparaten naar de AD-UPN van de gebruiker, niet naar een willekeurige apparaatidentificatie. Het iOS-veld CA name is een naam die de CA begrijpt, bijvoorbeeld om haar instanties te onderscheiden — geen bewijs voor de issuer of een vertrouwensanker. Het PKI-/CA-team controleert daarom op het daadwerkelijk uitgegeven certificaat de uitgevende CA en de certificaatketen, toegestane waarden voor Subject/SAN/UPN, sleutelgebruik en toegang tot de privésleutel. Het MDM-/dienstteam stemt de daadwerkelijke identiteitscontrole af met de dienst die het certificaat gebruikt; neem geen voorbeeld-placeholders over.
Vertrouwen van de dienst: Als wifi/VPN het clientcertificaat moet gebruiken, moet de betrokken dienst de CA-keten ervan vertrouwen. Bij EAP moet daarnaast worden gecontroleerd of het apparaat het certificaat van de wifi-server vertrouwt. Geen van deze bewijzen volgt uit alleen het vertrouwen in de SCEP-server.

Verantwoordelijken vóór vrijgave:

PKI-/CA-team: Controleer de SCEP-geschikte Windows-CA, de bereikbaarheid van /CertSrv/MSCEP_ADMIN en /CertSrv/MSCEP en de rechten om challenges aan te maken en certificaten in te schrijven. Leg challengewachtwoorden, diensttoegang en privésleutels niet vast in tickets of schermafbeeldingen. De historische verwijzing naar Windows 2003 in de Sophos-hulp is geen actuele toezegging over serverondersteuning.
Netwerkteam: Toets de doel-FQDN, de route via TLS/HTTP-proxy en de strikt beperkte vrijgave van regionale bron-IP-adressen aan de werkelijke topologie; controleer afzonderlijk uitgaand apparaatverkeer, push en een onafhankelijk beheer-/netwerkpad voor noodgevallen. Vervang deze controles niet door filters in het algemeen uit te schakelen.
MDM-/dienstteam: Leg vóór de configuratie het platform, het policytype voor apparaat of gebruiker en de inschrijfmodus vast. Gebruik voor het hier beschreven Android Enterprise-apparaatpad een Android Enterprise device policy; een Work Profile-policy betreft een ander beheergebied. De Android Enterprise-handleiding licht deze moduskeuze toe. Behandel de SCEP-payload voor iOS-apparaten afzonderlijk en gebruik die niet als bewijs voor iOS-gebruikerspolicies. De gemeenschappelijke en platformspecifieke SCEP-velden worden hieronder in de pilotprocedure afzonderlijk gecontroleerd. Stop als het policytype en de ondersteunde inschrijfmodus niet bevestigd zijn.

Stop als de beoogde identiteit of CA-vertrouwensketen onduidelijk is, het apparaattype of de modus niet past bij de gecontroleerde policy, of het apparaat uitsluitend via het te wijzigen wifi-/VPN-netwerk beheerd kan worden en er geen onafhankelijk terugvalpad bestaat.

Certificaatuitgifte is nog geen wifi-/VPN-koppeling

De SCEP-configuratie vraagt een certificaat aan bij de CA. Controleer vóór een wifi-/VPN-wijziging afzonderlijk:

Keuzeveld voor wifi: Bij apparaatpolicies voor Android Enterprise en iOS selecteert Identity certificate een certificaat uit een Client certificate-configuratie van dezelfde policy. Deze configuratie importeert een PKCS-#12-bestand (.pfx); dat is een andere manier van uitrollen dan SCEP. Daarmee is niet aangetoond dat een via SCEP uitgegeven certificaat in het keuzeveld voor wifi kan worden geselecteerd. Een EAP-wifinetwerk voor Android Enterprise mag niet verborgen zijn: de SSID moet worden uitgezonden.
Vernieuwing en serververtrouwen: Plan de import, geldigheid en vervanging van PKCS-#12-certificaten apart; SCEP renewal interval vernieuwt deze niet automatisch. Het rootcertificaat voor de EAP-server in de wifi-policy mag niet zonder meer worden gelijkgesteld aan het vertrouwen in de SCEP-server.

Ook VPN is geen uniforme SCEP-koppeling: Bij Android Enterprise selecteert de policy een al geïnstalleerde beheerde Google Play-VPN-app; de verbindingsparameters staan in de Managed Configuration van die app. Bij iOS zijn certificaatauthenticatie en certificaatselectie afhankelijk van het verbindingstype. Deze selectie alleen toont niet aan dat een SCEP-certificaat kan worden gebruikt. Bevestig vóór een wifi-/VPN-pilot de ondersteunde certificaatkoppeling en het gedrag na vernieuwing voor het platform, policytype, de authenticatiemethode en, waar van toepassing, de VPN-client aan de hand van passende documentatie van de fabrikant of in een afgebakende pilot. Als dit bewijs ontbreekt, beperk de pilot dan tot SCEP-uitgifte en -vernieuwing; start geen wifi-/VPN-migratie en trek de bestaande vertrouwensketen niet in.

SCEP uitsluitend in een afgebakende pilot instellen

Stem onder Setup > Sophos setup > SCEP de SCEP-server-URL https://<server>/CertSrv/MSCEP en challenge-URL https://<server>/CertSrv/MSCEP_ADMIN af met het PKI-team. Gebruik een hiervoor gemachtigde gebruiker in de vorm username@domain en diens wachtwoord; controleer toegestane tekentypen voor de challenge en de rechten met het PKI-team. Selecteer de afgesproken tekentypen voor het challengewachtwoord in het veld Challenge characters voordat je op Save klikt; behoud de door Sophos vooraf ingestelde challengelengte. Pas een afwijkende PKI-eis alleen toe als afzonderlijk gedocumenteerde, goedgekeurde en geteste uitzondering. Als een HTTP-proxy actief is, geldt Use HTTP proxy in eerste instantie voor deze verbinding; schakel de optie alleen uit als Sophos Mobile de SCEP-server bewust buiten de proxy om moet bereiken.
Klik op Save en documenteer de verbindingstest met de SCEP-server. Controleer bij een fout de URL, het certificaatvertrouwen, de proxy, de rechten en de toegestane bron-IP-adressen met de verantwoordelijken — wijzig niet meteen op grote schaal policies.
Maak eerst een policy aan of bewerk een bestaande policy die bij de pilotmodus past. Raadpleeg de handleiding voor policytoewijzing voor het aanmaken van de policy, het bewerken van configuraties, het opslaan en de daaropvolgende toewijzing aan de pilotgroep; controleer vooraf het platform en het ondersteunde policytype. Configureer in deze policy eerst Root certificate met het CA-certificaat van de SCEP-server, vervolgens SCEP en SCEP renewal interval. Voor de SCEP-velden URL en Challenge beschrijven de policyhandleidingen voor Android Enterprise- en iOS-apparaten de placeholders %_SCEPPROXYURL_% respectievelijk %_CACHALLENGE_% voor de eerder ingestelde SCEP-server- en challenge-URL. Stem Subject, SAN/UPN, sleutelgrootte en gebruiksdoel voor het specifieke platform af met PKI en de beoogde dienst. Wijs de policy alleen toe aan de afgebakende pilotgroep. PKI en MDM bepalen vooraf voor precies dit platform en deze policymodus waar policyaflevering, het apparaatcertificaat en PKI-uitgifte/-vernieuwing kunnen worden waargenomen; leg bij een daarnaast aangetoonde wifi-/VPN-koppeling ook het dienstlog vast. Ga niet uit van dezelfde statusvelden of lognamen voor alle apparaten. SCEP renewal interval bepaalt wanneer het apparaat een certificaat aanvraagt, niet of dit lukt.
Platformspecifieke SCEP-velden: Stel bij apparaatpolicies voor Android Enterprise een herkenbare Alias name in voor keuzedialogen en selecteer in het veld Root certificate het CA-certificaat van de SCEP-server uit dezelfde policy. Stem bij iOS-apparaatpolicies CA name af met de CA; Retries telt herhaalde pogingen na een serverantwoord pending, en Retry delay bepaalt de tijd tussen die pogingen in seconden. Presenteer deze iOS-velden niet als Android-velden. Key size moet overeenkomen met de SCEP-serverconfiguratie. Stem bij Certificate usage het beoogde gebruik afzonderlijk af met PKI en de dienst als Use as digital signature of Use for encryption; verzin geen standaardgrootte of standaardkeuze.
Controleer voor Type of Subject Alternative Name en Value of Subject Alternative Name het gedocumenteerde type en de waarde afzonderlijk: RFC 822 name voor een geldig e-mailadres, DNS name voor de DNS-naam van de CA-server of Uniform resource identifier voor de volledige URL daarvan. AD user logon name blijft de AD-UPN van de gebruiker. De veldbeschrijving vervangt niet de identiteitscontrole op het daadwerkelijk uitgegeven certificaat.
Eerste uitgifte na aflevering van de policy: Vergelijk op het pilotapparaat de issuer/certificaatketen, Subject en SAN/UPN, het serienummer, de begin- en einddatum van de geldigheid en het sleutelgebruik met de goedgekeurde PKI-vereisten. AD-apparaatregistratie telt niet als uitgifte van een SCEP-clientcertificaat. Geen waarneembare uitgifte: stop; geef geen rotatie vrij.
Latere vernieuwing: PKI en MDM bepalen op basis van het interval en de certificaatgeldigheid een observatieperiode. Controleer daarin op het apparaat een nieuw geldig certificaat met een nieuw serienummer en overeenkomende identiteits- en issuerwaarden, evenals de bevestigde PKI-transactie. Niet waarneembaar of niet opgetreden tijdens de pilotperiode: keur de rotatie niet als gevalideerd goed.
Alleen bij een aangetoonde wifi-/VPN-koppeling in de pilot: Koppel in het log van de betrokken dienst de geslaagde authenticatie vóór en na de vernieuwing aan precies dit pilotapparaat en certificaat. Geen dienstlog of bevestigde koppeling: geen wifi-/VPN-omschakeling.

Rotatie en terugvalpad

Leg vóór een wijziging van de SCEP-URL, de challenge-toegang of de CA, en vóór een afzonderlijk aangetoonde wijziging van het wifi-/VPN-profiel, per apparaatklasse de oude en nieuwe policytoewijzing, vertrouwensankers en betrokken groepen vast in het pilotverslag. PKI, netwerk en MDM bepalen het daadwerkelijk bereikbare beheerpad dat onafhankelijk is van het certificaatnetwerk dat gewijzigd wordt, de verantwoordelijke voor lokaal herstel en het stopcriterium. De concrete methode voor het opnieuw toewijzen of verwijderen van een policy en het effect daarvan op de apparaten moeten voor het platform en de inschrijfmodus in de pilot zijn gevalideerd; hier wordt geen universele resetmethode verondersteld. Volgens Sophos is Uninstall policy alleen bedoeld voor Android-apparaatpolicies, Knox-containerpolicies en iOS-apparaatpolicies; werk bij andere typen, waaronder apparaatpolicies voor Android Enterprise, de policy bij of wijs een andere toe. Daarmee is niet aangetoond of een al geïnstalleerde CA of een clientcertificaat wordt verwijderd of hersteld.

Besluit vóór de uitrol: Rol de nieuwe vertrouwensketen eerst in de pilot uit, alleen als de specifieke modus parallelle uitrol ondersteunt. Controleer nieuwe uitgifte en een daadwerkelijke latere vernieuwing. Controleer bij een geplande wifi-/VPN-omschakeling daarnaast de aangetoonde profielkoppeling en authenticatie bij de dienst vóór en na vernieuwing. Verwijder oude profielen en vertrouwensankers pas na gecontroleerde acceptatie en een geplande uitrol. Trek de oude CA niet voortijdig in als deze nog nodig is voor bestaande verbindingen.

Bepaal de aanpak bij een fout op basis van de bereikbaarheid:

Stop alle verdere toewijzingen en intrekkingen. Behoud de bestaande CA, profielen en vertrouwensankers; betrek de PKI-, netwerk- en MDM-verantwoordelijken aan de hand van het pilotverslag.
Apparaat bereikbaar via het gecontroleerde onafhankelijke pad: Het MDM-team herstelt met de eerder voor deze modus gevalideerde methode voor toewijzing/verwijdering de gedocumenteerde oude policy-/netwerk-/CA-koppeling; PKI en netwerk controleren hun deel. Test bij een gewijzigd wifi-/VPN-netwerk de authenticatie opnieuw in het dienstlog.
Apparaat offline of zonder onafhankelijk pad: De vooraf aangewezen verantwoordelijke voor lokaal herstel gebruikt uitsluitend de vooraf geplande en geteste lokale herstelmethode; test daarna de bereikbaarheid en, indien van toepassing, de authenticatie bij de dienst opnieuw. Alleen een cloudinstelling terugzetten is geen bewezen rollback voor apparaten die offline zijn geraakt. Als de lokale methode niet is aangetoond, suggereer dan geen veilig herstel op afstand en breid de wijziging niet uit.

Zonder waarneembare eerste uitgifte, vernieuwing en een gecontroleerd terugvalpad blijft de SCEP-omschakeling in productie geblokkeerd; voor een wifi-/VPN-omschakeling zijn bovendien een aangetoonde certificaatkoppeling en succesvol gebruik vóór en na vernieuwing vereist.

Beperking van het bewijs: Dit is een op bronnen gebaseerd concept dat niet in de tenant of op apparaten is getest. Ondersteunde OS-/serverversies, clientgedrag bij offline vernieuwing en de concrete EAP-/VPN-identiteitscontrole moeten afzonderlijk in de eigen omgeving worden bevestigd.