Sophos Mobile: comprobar con seguridad los certificados SCEP y las rutas de conexión

SCEP permite instalar y renovar certificados en Sophos Mobile (MDM). Este procedimiento se centra en la integración de SCEP en el tenant y en las distintas conexiones que intervienen, no en la configuración completa de una CA de Windows, de una infraestructura Wi-Fi/VPN ni de todas las cargas de políticas de Android, Apple y Windows. La instalación y renovación de certificados mediante SCEP siguiendo este procedimiento no son compatibles con Chromebooks.

Antes de modificar el entorno de producción: los responsables de CA/PKI, redes y MDM y, cuando corresponda, el operador del servicio de autenticación Wi-Fi/VPN deben acordar qué dispositivos y modos de inscripción se verán afectados, si un servicio concreto puede utilizar el certificado SCEP y de qué forma, y cómo se podrá seguir accediendo a los dispositivos si pierden la conexión de red. Ni Save ni una política distribuida demuestran que se haya emitido o renovado un certificado de cliente o que se haya asociado a un perfil Wi-Fi/VPN.

Tres conexiones, no una apertura indiscriminada de puertos

Sophos Fusion se conecta a la CA propia habilitada para SCEP; por separado, el dispositivo administrado se comunica con Sophos Mobile. La posterior autenticación ante un servicio Wi-Fi/VPN mediante ese mismo certificado SCEP no se produce automáticamente y debe comprobarse para cada plataforma y perfil. Aquí, tenant se refiere al entorno propio de Sophos Mobile y MDM a su gestión de dispositivos.

Determinar la región del tenant: en Sophos Fusion, consultar la URL en la barra de direcciones del navegador en My Products > Mobile. La región aparece en el primer componente del nombre de host, es decir, antes del primer punto, justo después de smc-user-if-cloudstation-. En el ejemplo smc-user-if-cloudstation-eu-west-1, la región es eu-west-1. Para las reglas de acceso, utilizar la región de la URL del navegador propia, no el valor del ejemplo ni un texto idéntico en la ruta de la URL o en los parámetros de consulta. La región de alojamiento se elige al crear la cuenta de Sophos Fusion; para las cuentas existentes, aquí se determina a partir de la URL real del navegador. Este host de administración no es ni el endpoint de los dispositivos ni el servidor SCEP. La determinación de la región también se aplica a Mobile Threat Defense, pero no indica que MTD tenga una función SCEP propia.
De Fusion a los servidores propios (tráfico entrante): la lista regional actual de IP de origen para decidir la regla concreta de acceso entrante indica TCP 443 para SCEP y TCP 636 para la conexión LDAP/AD, que es independiente. Permitir únicamente las IP de origen de Mobile publicadas allí para la región real del tenant, y solo hacia el destino SCEP o AD propio que corresponda. No tomar la región de ejemplo ni crear una regla de entrada global o sin restricciones. La conexión LDAP/AD sirve para la autenticación del usuario con credenciales de AD durante el registro del dispositivo mediante Apple Business (antes Apple Business Manager), Google Zero-touch o Samsung KME. Esta autenticación no equivale a la primera emisión de un certificado de cliente SCEP para un dispositivo administrado ni a su posterior renovación.
Del dispositivo a Sophos Mobile (tráfico saliente): los dispositivos administrados necesitan acceso HTTPS 443 al host regional smc-device-if-cloudstation-. Los destinos completos de dispositivos son smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com para eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com para eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com para us-west-2 y smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com para us-east-2, en todos los casos mediante HTTPS 443. Utilizar únicamente el destino de la región real del tenant determinada anteriormente; estos destinos de dispositivos no son el host de administración ni los destinos SCEP propios. También se necesitan conexiones para notificaciones push, inscripción y otras funciones de las plataformas. Las vías de comprobación separadas y las guías internas de plataformas que siguen permiten distinguirlas según el tipo de dispositivo y la función realmente utilizada; los cuatro hosts regionales de dispositivos no constituyen una lista completa de tráfico saliente. Estos destinos adicionales no son IP de origen de tráfico entrante para SCEP ni una lista general de puertos SCEP.

Mantener separadas las demás dependencias de tráfico saliente de los dispositivos:

Notificaciones push de Windows: para equipos Windows, están documentados los destinos *.notify.windows.com, *.wns.windows.com y *.notify.live.net para Windows Notification Service (WNS) y Microsoft Push Notification Service (MPNS), en todos los casos mediante HTTPS 443. Se trata de conexiones push de Windows, no de puertos de tráfico entrante para SCEP.
Inscripción y aprovisionamiento de Android: para Android, consultar la guía de Android Enterprise y, para los requisitos de QR/Zero-touch/KME, la guía de aprovisionamiento; en esos casos sigue siendo necesario comprobar la autorización según el dispositivo y el modo concretos.
Notificaciones push de gestión de Apple: para la gestión de iPhones, iPads y Macs, comprobar por separado la ruta de notificaciones push de Apple; la guía de APNs describe la identidad del certificado, su renovación y la comprobación de accesibilidad disponible en iPhone/iPad.
Información sobre actualizaciones de Apple y cumplimiento: por separado, Sophos Mobile necesita información sobre las actualizaciones disponibles de Apple: si el servicio de Apple previsto para ello no es accesible, falta esa información y las reglas de cumplimiento que exigen actualizaciones no tienen efecto. Comprobar la ruta de red propia y las limitaciones de plataforma, sistema operativo e inscripción en la guía de cumplimiento. Las notificaciones push de gestión de Apple y la información sobre actualizaciones son requisitos de tráfico saliente de los dispositivos, no endpoints de tráfico entrante para SCEP ni de emisión de certificados.
Tráfico de la aplicación IXM: para iPhone/iPad con Sophos Intercept X for Mobile (IXM), comprobar las conexiones independientes de la aplicación en la guía de conexiones de red de IXM; allí se describen la correspondencia entre servicios y puertos y las limitaciones según la versión de la aplicación, la edición, el tipo de gestión y la función realmente utilizada. No se trata de conexiones de tráfico entrante para SCEP; el encabezado de Apple en una lista de conexiones de red no implica que IXM sea aplicable a los Mac.

Una dirección de destino documentada no demuestra por sí sola que sea accesible desde la propia red.

Ante una incidencia, registrar por separado si (a) Fusion alcanza el endpoint SCEP propio, (b) el dispositivo alcanza Sophos Mobile y recibe su política y (c) el servicio Wi-Fi/VPN acepta el certificado emitido. Que una ruta funcione no sustituye las otras dos comprobaciones.

Definir antes las relaciones de confianza y las responsabilidades

Términos para tomar decisiones: PKI es la infraestructura de certificados y CA es la autoridad que los emite. SCEP solicita el certificado de cliente; el sujeto y el SAN (nombre alternativo del sujeto) y, si procede, el UPN (identificador de usuario) determinan la identidad que debe comprobarse. EAP es el método de autenticación de un servicio Wi-Fi. Importar un PKCS #12 (.pfx) es un método de aprovisionamiento distinto de SCEP; el intervalo de renovación de SCEP no renueva automáticamente ese certificado.

Resolver por separado estas tres cuestiones de confianza, aunque la misma CA desempeñe varias funciones en la PKI propia:

Conexión con el servidor SCEP: antes de configurar SCEP, el equipo de MDM incorpora a la política correspondiente una configuración Root certificate con el certificado de la CA del servidor SCEP. En las políticas de dispositivos Android Enterprise, hay que seleccionar además ese certificado en el campo SCEP Root certificate entre los certificados de la misma política. No se trata del certificado de cliente emitido ni demuestra la identidad del cliente.
Identidad de cliente emitida: en Android Enterprise e iOS, el campo Subject debe contener un nombre X.500 válido de la persona o el dispositivo previstos una vez sustituidos todos los marcadores. Definir por separado el tipo y el valor del SAN; AD user logon name designa en los campos SCEP de dispositivos el UPN de AD del usuario, no un identificador de dispositivo cualquiera. El campo de iOS CA name es un nombre que la CA reconoce, por ejemplo, para distinguir sus instancias: no demuestra quién es el emisor ni establece un ancla de confianza. Por ello, el equipo de PKI/CA comprueba en el certificado realmente emitido la CA emisora y la cadena, los valores permitidos de sujeto/SAN/UPN, el uso de la clave y el acceso a la clave privada. Los equipos de MDM y del servicio acuerdan cómo cotejará la identidad el servicio que utilice el certificado; no deben adoptarse valores de ejemplo como si fueran reales.
Confianza del servicio: si Wi-Fi/VPN va a utilizar el certificado de cliente, el servicio correspondiente debe confiar en su cadena de CA. Si se usa EAP, también hay que comprobar que el dispositivo confía en el certificado del servidor Wi-Fi. Ninguna de estas comprobaciones queda resuelta por el mero hecho de confiar en el servidor SCEP.

Responsables antes de la autorización:

Equipo de PKI/CA: comprobar que la CA de Windows admite SCEP, que /CertSrv/MSCEP_ADMIN y /CertSrv/MSCEP son accesibles y que existen permisos para generar desafíos e inscribir certificados. No incluir contraseñas de desafío, credenciales del servicio ni claves privadas en tickets o capturas de pantalla. La referencia histórica a Windows 2003 en la ayuda de Sophos no constituye una garantía actual de compatibilidad del servidor.
Equipo de redes: contrastar el FQDN de destino, la ruta del proxy TLS/HTTP y la apertura estrictamente limitada de IP de origen regionales con la topología real; comprobar por separado el tráfico saliente de los dispositivos, las notificaciones push y una ruta independiente de administración o acceso de red para emergencias. No sustituir estas comprobaciones por una desactivación general de los filtros.
Equipos de MDM y del servicio: definir la plataforma, el tipo de política de dispositivo o usuario y el modo de inscripción antes de configurar. Para la vía de dispositivos Android Enterprise descrita aquí, utilizar una Android Enterprise device policy; una política de Work Profile corresponde a un ámbito de gestión distinto. La guía de Android Enterprise explica esta elección del modo. Tratar por separado la carga SCEP de dispositivos iOS y no utilizarla como prueba de compatibilidad con políticas de usuario de iOS. Los campos SCEP comunes y específicos de cada plataforma se comprueban por separado en el procedimiento del piloto que figura a continuación. Detenerse si no se han confirmado el tipo de política y un modo de inscripción compatible.

Detenerse si no se han aclarado la identidad prevista o la cadena de confianza de la CA, si el tipo o modo del dispositivo no coincide con la política comprobada, o si el dispositivo solo se puede administrar mediante la misma red Wi-Fi/VPN que se va a cambiar y no existe una ruta de retorno independiente.

Emitir un certificado no significa asignarlo a Wi-Fi/VPN

La configuración SCEP solicita un certificado a la CA. Antes de modificar Wi-Fi/VPN, comprobar por separado:

Selector de certificados para Wi-Fi: en las políticas de dispositivos Android Enterprise y de dispositivos iOS, Identity certificate selecciona un certificado de una configuración Client certificate de la misma política. Esta configuración importa un archivo PKCS #12 (.pfx); es un método de aprovisionamiento distinto de SCEP. Esto no demuestra que en el selector de Wi-Fi pueda elegirse un certificado emitido mediante SCEP. Una red Wi-Fi EAP para Android Enterprise no puede estar oculta: debe difundirse el SSID.
Renovación y confianza en el servidor: planificar por separado la importación, la vigencia y la sustitución de certificados PKCS #12; SCEP renewal interval no los renueva automáticamente. El certificado raíz del servidor EAP en la política Wi-Fi no debe equipararse sin más al que establece la confianza en el servidor SCEP.

Tampoco existe una integración única de VPN con SCEP: en Android Enterprise, la política selecciona una aplicación VPN administrada de Google Play ya instalada; los parámetros de conexión se encuentran en su configuración administrada. En iOS, la autenticación mediante certificados y la selección del certificado dependen del tipo de conexión. Esa selección por sí sola no demuestra que se pueda utilizar un certificado SCEP. Antes de un piloto de Wi-Fi/VPN, confirmar mediante documentación pertinente del fabricante o en un piloto acotado la compatibilidad de la asignación del certificado y su comportamiento tras la renovación para la plataforma, el tipo de política, el método de autenticación y, cuando corresponda, el cliente VPN. Si falta esa prueba, limitar el piloto a la emisión y renovación mediante SCEP; no iniciar una migración de Wi-Fi/VPN ni retirar la cadena de confianza anterior.

Configurar SCEP únicamente en un piloto acotado

En Setup > Sophos setup > SCEP, acordar con el equipo de PKI la URL del servidor SCEP https://<server>/CertSrv/MSCEP y la del desafío https://<server>/CertSrv/MSCEP_ADMIN. Utilizar un usuario autorizado con el formato username@domain y su contraseña; comprobar con PKI los tipos de caracteres admitidos para el desafío y los permisos. Seleccionar los tipos de caracteres acordados en el campo Challenge characters para la contraseña del desafío antes de ejecutar Save, y mantener la longitud de desafío predeterminada por Sophos. Aplicar un requisito distinto de PKI solo como excepción documentada, aprobada y probada por separado. Si hay un proxy HTTP activado, Use HTTP proxy se aplica inicialmente a esta conexión; desactivar la opción únicamente si Sophos Mobile debe llegar deliberadamente al servidor SCEP sin pasar por el proxy.
Ejecutar Save y documentar la prueba de conexión con el servidor SCEP. Si falla, revisar con los responsables la URL, la confianza en el certificado, el proxy, los permisos y las IP de origen permitidas; no cambiar de inmediato políticas de forma masiva.
Primero, crear una política adecuada para el modo del piloto o editar una política existente. Para la creación, la edición de la configuración, el guardado y la posterior asignación al piloto, consultar la guía de políticas; comprobar previamente la plataforma y el tipo de política compatible. En esta política, configurar primero Root certificate con el certificado de la CA del servidor SCEP, después SCEP y SCEP renewal interval. Para los campos SCEP URL y Challenge, las ayudas de políticas de dispositivos Android Enterprise e iOS describen respectivamente los marcadores %_SCEPPROXYURL_% y %_CACHALLENGE_% para las URL del servidor SCEP y del desafío configuradas previamente; acordar con PKI y el servicio de destino el sujeto, SAN/UPN, tamaño y uso de la clave para la plataforma concreta. Asignar la política solo al grupo piloto delimitado. PKI y MDM deben definir de antemano, para esa plataforma y ese modo de política, dónde se pueden observar la entrega de la política, el certificado del dispositivo y la emisión/renovación en PKI; si también se ha demostrado la asignación a Wi-Fi/VPN, definir además el registro del servicio. No presuponer campos de estado ni nombres de registros comunes a todos los dispositivos. SCEP renewal interval determina cuándo el dispositivo solicita la renovación, no que esta tenga éxito.
Campos SCEP específicos de cada plataforma: en las políticas de dispositivos Android Enterprise, definir un Alias name reconocible para los diálogos de selección y seleccionar en el campo Root certificate el certificado de la CA del servidor SCEP de la misma política. En las políticas de dispositivos iOS, acordar CA name con la CA; Retries cuenta los reintentos tras una respuesta pending del servidor y Retry delay establece el intervalo en segundos. No presentar estos campos de iOS como campos de Android. Key size debe ser compatible con la configuración del servidor SCEP. En Certificate usage, acordar por separado con PKI y el servicio el uso previsto como Use as digital signature o Use for encryption; no inventar un tamaño ni una selección predeterminados.
Para Type of Subject Alternative Name y Value of Subject Alternative Name, cotejar por separado el tipo y el valor documentados: RFC 822 name para una dirección de correo electrónico válida, DNS name para el nombre DNS del servidor de la CA o Uniform resource identifier para su URL completa. AD user logon name sigue siendo el UPN de AD del usuario. La descripción de los campos no sustituye la comprobación de la identidad en el certificado realmente emitido.
Emisión inicial tras entregar la política: en el dispositivo piloto, cotejar el emisor y la cadena, el sujeto y SAN/UPN, el número de serie, las fechas de inicio y fin de validez y el uso de la clave con los requisitos aprobados de PKI. El registro de un dispositivo en AD no cuenta como emisión de un certificado de cliente SCEP. Si no se observa la emisión: detenerse; no autorizar la rotación.
Renovación posterior: PKI y MDM establecen un periodo de observación en función del intervalo y de la validez del certificado. Durante ese periodo, comprobar en el dispositivo que existe un certificado nuevo y válido, con otro número de serie y valores de identidad y emisor adecuados, así como la operación confirmada en PKI. Si la renovación no puede observarse o no se produce durante el piloto, no dar la rotación por validada.
Solo si se ha demostrado la asignación a Wi-Fi/VPN en el piloto: vincular en el registro del servicio utilizado la autenticación satisfactoria antes y después de la renovación con ese dispositivo piloto y ese certificado concretos. Sin registro del servicio o sin asignación confirmada, no cambiar Wi-Fi/VPN.

Rotación y vía de recuperación

Antes de cambiar la URL de SCEP, el acceso para los desafíos o la CA, así como antes de cualquier cambio de perfil Wi-Fi/VPN justificado por separado, registrar en el acta del piloto las asignaciones de políticas antigua y nueva, las anclas de confianza y los grupos afectados para cada clase de dispositivo. PKI, redes y MDM deben definir la ruta de administración realmente accesible e independiente de la red basada en certificados que se va a cambiar, el responsable local de recuperación y el criterio para detener el proceso. El método concreto para reasignar o retirar una política y sus efectos en los dispositivos deben validarse en el piloto para la plataforma y el modo de inscripción; aquí no se presupone un procedimiento universal de reversión. Según Sophos, Uninstall policy solo está previsto para políticas de dispositivos Android, contenedores Knox y dispositivos iOS; para otros tipos, incluidas las políticas de dispositivos Android Enterprise, se debe actualizar la política o asignar otra. Esto no demuestra que se retire o restablezca una CA o un certificado de cliente ya instalados.

Decisión antes del despliegue: distribuir primero la nueva cadena de confianza en el piloto solo si el modo concreto admite la distribución en paralelo. Comprobar la nueva emisión y una renovación posterior real. Si está previsto cambiar Wi-Fi/VPN, comprobar además la asignación documentada al perfil y la autenticación ante el servicio antes y después de la renovación. Retirar los perfiles y las anclas de confianza anteriores únicamente tras una aceptación controlada y un despliegue planificado. No retirar prematuramente la CA anterior si sigue siendo necesaria para conexiones existentes.

En caso de fallo, actuar según la accesibilidad:

Detener todas las nuevas asignaciones y retiradas. Conservar la CA, los perfiles y las anclas de confianza anteriores; implicar a los responsables de PKI, redes y MDM con el acta del piloto.
Si se puede acceder al dispositivo por la ruta independiente verificada: el equipo de MDM restablece la asignación anterior documentada de política, red y CA mediante el método de asignación o retirada validado previamente para ese modo; PKI y redes comprueban su parte. Si se modificó Wi-Fi/VPN, volver a probar la autenticación en el registro del servicio.
Si el dispositivo está sin conexión o carece de una ruta independiente: el responsable local de recuperación designado con anterioridad emplea exclusivamente el procedimiento de recuperación local previamente planificado y probado; después vuelve a comprobar la accesibilidad y, si corresponde, la autenticación ante el servicio. Restablecer simplemente una configuración en la nube no constituye una reversión demostrada para dispositivos que han quedado sin conexión. Si no se ha probado la vía local, no afirmar que existe una recuperación remota segura ni ampliar el cambio.

Sin una emisión inicial y una renovación observadas, además de una vía de recuperación comprobada, no se autoriza el cambio productivo a SCEP; un cambio de Wi-Fi/VPN requiere además demostrar la asignación del certificado y su uso satisfactorio antes y después de la renovación.

Límite de lo demostrado: este es un borrador basado en fuentes que no se ha probado en el tenant ni en dispositivos. Las versiones de sistemas operativos y servidores compatibles, el comportamiento del cliente al renovar sin conexión y la comprobación concreta de la identidad mediante EAP/VPN deben confirmarse por separado en el entorno propio.