Preparar un tenant de Sophos Mobile y transferir su administración

Sophos Mobile se configura en un tenant de Sophos Fusion existente. Este procedimiento termina con la preparación y la decisión de autorización para una prueba piloto limitada, no con un enrollment realizado ni con un despliegue masivo en producción. Mobile Device Management (MDM) y Mobile Threat Defense tienen alcances de licencia y funciones distintos. Antes de realizar cambios, registrar el tenant, la edición, el rol, la plataforma de los dispositivos, el modelo de propiedad y el procedimiento de reversión. La activación general del tenant y la protección de los administradores a nivel global se describen en Poner en funcionamiento de forma segura un tenant de Sophos Fusion.

1. Aclarar previamente la licencia y los permisos

En Profile icon > Licensing del tenant de Fusion correcto, contrastar el producto, la edición y el alcance disponible con el encargo. Sophos Mobile Device Management (antes Central Mobile Standard) proporciona MDM para Android, iPhone/iPad, Mac y Windows; Sophos Mobile Threat Defense (antes Intercept X for Mobile) permite administrar Intercept X for Mobile y Sophos Chrome Security. Sophos Mobile (antes Central Mobile Advanced) incluye ambos. Que la interfaz de Mobile esté visible no demuestra que exista una autorización MDM determinada. No activar una licencia por suposición: la activación, la renovación y las consecuencias de las licencias forman parte del procedimiento de licencias de Fusion; primero se deben contrastar allí el tenant y el encargo.

Acreditar la región por separado: En la cuenta de Fusion correspondiente, abrir My Products > Mobile, identificar la región en la URL del navegador después de smc-user-if-cloudstation- y registrarla para la autorización de infraestructura y red. Los destinos de servidor de Sophos Mobile dependen de la región; la persona responsable de la red contrasta las conexiones necesarias para la región y la plataforma reales con la documentación de red vigente de Sophos. No deducir la región de la ubicación de la empresa, del idioma ni de la zona horaria personal del administrador. Sin una región acreditada y la autorización de red necesaria, no se debe aprobar la vía piloto afectada.

Para la configuración inicial, utilizar una cuenta Admin o Super Admin con los permisos necesarios. Los roles de Fusion se corresponden con los de Mobile de la siguiente manera:

En Fusion, determinar las personas responsables y sus roles según Asignar correctamente los roles de administración y, después, comprobar en Mobile con cuentas separadas de Help Desk y Read-only qué menús y acciones son realmente accesibles. No reducir los privilegios de la única cuenta de administrador operativa. Según la documentación de MDM, Helpdesk también puede registrar dispositivos e instalar aplicaciones. Las funciones críticas, como establecer ajustes y crear, editar y eliminar dispositivos, grupos de dispositivos y paquetes, están excluidas para este rol de Mobile. La descripción de roles de Threat Defense solo menciona tareas generales de soporte entre las acciones permitidas a Helpdesk; también excluye expresamente las funciones críticas indicadas. No deducir de ello que Helpdesk tenga permiso de enrollment en todas las ediciones. La conexión con un directorio o LDAP y la sincronización de identidades requieren su propio proceso de autorización y reversión; no son un efecto secundario de la asignación de roles.

2. Establecer los ajustes básicos sin modificar dispositivos

Los ajustes personales de visualización en Sophos Mobile Admin solo se aplican a la cuenta de administrador con la que se ha iniciado sesión. Sophos incluye entre ellos el idioma de la interfaz de usuario, que se puede configurar, pero en la página sobre ajustes personales no describe ningún selector de idioma, dónde se encuentra ni cómo se utiliza. El idioma de la interfaz debe distinguirse del idioma de los correos electrónicos salientes que se describe a continuación; esta documentación no acredita que se adopte automáticamente el idioma de Fusion.

En Sophos Mobile Admin > Setup > General, distinguir a quién corresponde cada ajuste:

1. Personal: configurar la zona horaria, las unidades de medida, las filas de las tablas, Expert mode y las plataformas de dispositivos mostradas para la cuenta de administrador que ha iniciado sesión, y seleccionar Save. Cada ajuste tiene el siguiente efecto:

   • Time zone establece la zona horaria en la que se muestran las fechas y las horas.
   • Unit system determina el sistema de unidades para las medidas de longitud: Metric o Imperial.
   • Lines per page in tables establece el número máximo de entradas que se muestran por página de una tabla.
   • Si Expert mode está activado, la página Show device incluye la pestaña Custom properties, con propiedades personalizadas del dispositivo, y la pestaña Internal properties, con propiedades adicionales comunicadas por el dispositivo. Varias páginas de configuración de políticas muestran también la sección Extra settings, donde se pueden configurar ajustes opcionales.

   Las plataformas activadas determinan la visibilidad de las páginas y los ajustes correspondientes; no activan ninguna licencia ni inscriben dispositivos. Tras guardar, comprobar que la plataforma esperada aparece en la navegación. Si faltan vistas, comprobar primero el filtro personal de plataformas y el rol; si es necesario, restablecer la selección anterior.

2. IT contact: indicar una dirección de soporte supervisada y un contacto accesible, seleccionar Save y comprobar el texto en un dispositivo de prueba previsto para ello solo después de la aprobación específica del piloto. Estos datos aparecen en los dispositivos de los usuarios. No introducir números privados ni información personal no autorizada. Guardar las correcciones en la misma pestaña y volver a comprobarlas en el dispositivo de prueba.

3. Email configuration: establecer el idioma de los correos electrónicos enviados por Sophos Mobile y seleccionar Save. Esto no configura un relay SMTP, un buzón de Exchange ni un proxy EAS. Comprobar en el piloto una ocasión real de envío de un mensaje de Mobile; Save por sí solo no confirma la entrega. Si el idioma es incorrecto, restablecer el valor anterior y evaluar otro mensaje de prueba.

El área Setup también contiene opciones de plataformas, privacidad e integración. No activar de forma generalizada certificados APNs, Android Enterprise, la sincronización de dispositivos, autorizaciones de privacidad ni EAS. La zona horaria personal no es una zona horaria global del tenant; en cambio, el contacto de TI y el idioma del correo electrónico forman parte de la configuración general de Mobile. La guía de inicio menciona además Fusion Self Service Portal como una etapa de configuración independiente.

3. Preparar únicamente los dispositivos y el Enrollment

Para MDM, aclarar primero la titularidad del dispositivo (de la organización o privado), la plataforma de destino, el modo de administración, el grupo de usuarios afectado, el número de dispositivos y el texto de consentimiento y privacidad. Para Android, aprobar por separado el modo de Android Enterprise y sus requisitos previos; para iPhone, iPad y Mac, aprobar antes del Enrollment el certificado APNs necesario en Sophos Mobile, junto con la persona responsable, su validez de un año y su renovación. Para una renovación posterior, el responsable de Apple debe acreditar la Apple Account original e identificar el certificado correcto mediante el Topic de APNs: un certificado nuevo o incorrecto con otro Topic puede interrumpir la administración de dispositivos ya inscritos y exigir un nuevo Enrollment. No eliminar el certificado APNs como medida de reversión para dispositivos existentes.

Si falta el certificado y nunca se ha cargado uno en este tenant, encargar la creación inicial del certificado APNs al responsable de APNs; la creación y la carga requieren una autorización específica y no se realizan de forma incidental en este procedimiento preparatorio. Si ya existe un certificado, el responsable de APNs se encarga del cotejo de identidad y la renovación. Para el traspaso, solicitar que se acrediten los detalles del certificado mostrados, la fecha de vencimiento, la Apple Account responsable y quién se encargará de la renovación; no copiar credenciales en el registro de comprobación ni equiparar una carga con la aceptación del piloto. El Apple-Business-Service-Token es independiente. El manual de Threat Defense no presenta la misma estructura de configuración de Apple/EAS que la edición MDM: compartir ajustes básicos no garantiza funciones de dispositivo idénticas.

Solo si se elige el Enrollment automatizado mediante Apple Business: El responsable de Apple/Enrollment acredita que la organización está registrada en Apple Business (antes Apple Business Manager), que dispone de una cuenta de Apple Business con los permisos necesarios y que hay un certificado APNs incorporado en Sophos Mobile, además de la conexión independiente mediante Apple-Business-Service-Token. Documentar la validez de un año del token y la responsabilidad de renovarlo; al renovarlo debe utilizarse la misma Apple Account que se empleó para el token original. Restablecer la integración elimina en Sophos Mobile el token, los dispositivos de Apple Business y los perfiles de Apple Business, y no es una medida de reversión inocua. Sin estas acreditaciones, no autorizar esta vía; Apple Business no es un requisito general para todas las vías de Enrollment de Apple. En este procedimiento básico del tenant, no crear ni restablecer tokens o perfiles.

Solo si se elige Android Enterprise: Antes del primer piloto de Android, el responsable de Android/Google acredita que se dispone de la licencia MDM adecuada, el modo de administración de Android Enterprise, el registro de la organización y la conexión de la cuenta de empresa de Google correcta con Sophos Mobile. La elección del modo, por sí sola, modifica los tipos de políticas disponibles; no registra ninguna organización. Comprobar el modo de registro y Enrollment realmente disponible, así como el origen y la disponibilidad de las cuentas de Google administradas para los usuarios de prueba: según la configuración, Sophos Mobile administra las cuentas, o los usuarios deben existir previamente en Google Workspace/Cloud Identity; solo si la organización se registró en el modo managed Google domain antes del 9 de abril de 2024 y la opción Use managed Google domain device enrollment está desactivada, Sophos Mobile comprueba durante el SSP-Enrollment si ya existe una cuenta de Google administrada construida a partir de la parte anterior a @ de la dirección de correo electrónico del usuario en Sophos Fusion y del dominio de Google administrado de la organización; si no existe, la crea sin administrar el resto de su ciclo de vida. Esta cuenta de usuario administrada no es la cuenta de empresa de Google utilizada para registrar Android Enterprise ni es automáticamente una cuenta autorizada para desbloquear FRP; comprobar por separado la correspondencia de identidades y el procedimiento de recuperación de la cuenta antes del piloto. Comprobar la política adecuada para el tipo de dispositivo elegido; para el SSP-Enrollment, aprobar el paquete de Enrollment asignado con un paquete de tareas de Android Enterprise (Enroll y Assign policy), así como la autorización de la aplicación Sophos Mobile Control en Managed Google Play para recibir actualizaciones automáticas. Comprobar que la vía concreta de Enrollment es adecuada para el modo; los dispositivos Android totalmente administrados solo pueden inscribirse si no están configurados o después de un restablecimiento de fábrica autorizado. Si para ello debe restablecerse un dispositivo que ya está en uso, el responsable del dispositivo debe comprobar antes el estado real de Factory Reset Protection (FRP) de ese dispositivo, la vía de restablecimiento prevista y el procedimiento autorizado de desbloqueo o recuperación de la cuenta. Para ello, debe garantizarse organizativamente el acceso a las cuentas de Google autorizadas para FRP en ese dispositivo; la cuenta utilizada para registrar Android Enterprise o la cuenta de usuario no es automáticamente una cuenta válida para desbloquear FRP. Según la vía de restablecimiento, FRP puede exigir iniciar sesión con una cuenta después del restablecimiento. No documentar las credenciales en la documentación del piloto. Esta comprobación se refiere a los restablecimientos previstos de dispositivos Android totalmente administrados, no de forma general a los perfiles de trabajo ni a los dispositivos Apple. No realizar de manera incidental registros de Google Enterprise, cambios de cuenta ni restablecimientos de dispositivos en este procedimiento básico.

Antes de enviar una invitación en Setup > Self Service Portal, documentar la configuración prevista para el piloto: tipos de dispositivo permitidos, modalidad de propiedad, grupo de dispositivos y paquete de inscripción adecuados, así como acciones de autoservicio permitidas. El número máximo de dispositivos limita los dispositivos por usuario, no el número de usuarios piloto ni el alcance de la configuración. El grupo piloto debe delimitarse por separado mediante la asignación efectiva de usuarios y grupos. Antes de modificar una configuración SSP compartida, comprobar y documentar la configuración Default efectiva (que se aplica si no hay una asignación más específica), todos los grupos aplicables tanto a usuarios piloto como a usuarios ajenos al piloto y sus prioridades, así como las acciones permitidas y los efectos sobre los dispositivos ya inscritos. Antes de escribir cualquier cambio en los ajustes SSP compartidos, obtener la autorización específica de una segunda persona con los permisos necesarios para el cambio concreto y su alcance; registrar los ajustes anteriores, incluidos Default, grupos, prioridades, acciones y asignaciones de plataformas, además de la vía de reversión. Sin esa autorización, dejar intacta la configuración. Después de Save, pero antes de enviar invitaciones o inscribir dispositivos, comprobar y documentar la asignación realmente efectiva para identidades piloto y ajenas al piloto, incluidos Default y los casos de pertenencia a varios grupos, así como los efectos sobre los dispositivos ya inscritos y sus acciones SSP. Si el alcance es inesperado, detener los cambios y las invitaciones, restaurar los ajustes anteriores y volver a comprobar la asignación efectiva y los efectos sobre los dispositivos; si no es posible revertir con seguridad el efecto, no dar el visto bueno y escalar el caso a los responsables correspondientes. Esta autorización de escritura es distinta de la aprobación posterior para el Enrollment piloto. Una configuración piloto aparentemente restringida puede afectar a otros usuarios por efecto de Default o de la pertenencia a varios grupos. Solo si la vía piloto aprobada exige aceptar los términos de uso del SSP: el responsable del SSP y de la inscripción comprueba, para la identidad de prueba y la plataforma elegida, el contenido aprobado de los Enrollment texts efectivos y del campo Terms of use específico de la plataforma. Si Terms of use está vacío, no se muestra ese texto antes de la inscripción ni se obtiene su aceptación; en ese caso, no se debe dar el visto bueno a esta vía de consentimiento mediante SSP. Si el consentimiento se obtiene mediante un proceso independiente aprobado, documentar esa vía; los términos de uso del SSP no son un requisito general para otras vías de inscripción. Las políticas, el cumplimiento y los paquetes de inscripción son requisitos independientes, no consecuencias automáticas de los ajustes básicos.

Punto de aprobación antes de cada inscripción piloto: una segunda persona autorizada comprueba en el tenant real la edición y la licencia, así como el alcance de las licencias Mobile disponibles para los usuarios piloto identificados o los dispositivos sin usuario; los roles; la región acreditada y el acceso de red autorizado; para las vías SSP, la asignación SSP efectiva para la identidad de prueba y una identidad ajena al piloto, incluidos Default, las prioridades y el alcance de los grupos, en lugar del límite de dispositivos por usuario; para los Dedicated Devices sin usuario, en cambio, la vía de Enrollment de Android totalmente administrado aprobada por separado y la asignación de los dispositivos; además, la plataforma y el modo de gestión, el consentimiento, las políticas y el paquete, y las responsabilidades de copia de seguridad, restablecimiento y retirada de la gestión. Si la vía aprobada exige consentimiento mediante SSP, la decisión de Go/No-go incluye los Enrollment texts efectivos, el campo Terms of use específico de la plataforma cumplimentado con el texto aprobado y la identidad de prueba; de lo contrario, debe documentarse el proceso independiente de consentimiento aprobado. Para las vías Apple MDM elegidas, se requiere la acreditación del responsable de APNs; si se elige una vía Apple Business o Android Enterprise, la segunda persona solicita además las acreditaciones de los responsables específicas de esa vía mencionadas anteriormente. Si está previsto restablecer de fábrica un dispositivo Android totalmente administrado, también deben constar expresamente el estado de FRP acreditado de antemano, la vía de restablecimiento prevista y la vía aprobada de desbloqueo o recuperación de cuenta para las cuentas FRP efectivamente autorizadas. Las vías no elegidas no constituyen impedimentos generales. La segunda persona documenta una decisión expresa de Go/No-go para las cuentas y los dispositivos de prueba identificados. Si falta alguna acreditación o la decisión es No-go: no enviar invitaciones, no inscribir dispositivos ni modificarlos; devolver el asunto a los responsables correspondientes. Estas instrucciones de documentación no otorgan por sí mismas ninguna aprobación ni acreditan que se hayan probado el tenant o los dispositivos.

Solo después de un Go independiente, en las vías vinculadas a usuarios, el responsable del Enrollment realiza el ensayo piloto limitado con un usuario de prueba identificado y creado expresamente para cada plataforma aprobada, y registra la identidad de Enrollment, la inscripción, el grupo asignado, la política de destino, el estado de las tareas, el contacto de TI y la recepción de mensajes en ese dispositivo, así como la vía de reversión. Solo en un piloto de Dedicated Devices sin usuario aprobado por separado, el responsable del dispositivo y del Enrollment comprueba, en cambio, en el dispositivo de prueba identificado la vía elegida de gestión y Enrollment sin asignación de usuario, la identidad de Enrollment o la asignación del dispositivo, la política de destino incluida la configuración de quiosco, el estado de las tareas y la vía acreditada de recuperación y retirada de la gestión; no presumir para esta vía un usuario de prueba ni una coincidencia de grupo SSP. Solo si la vía aprobada exige consentimiento mediante SSP, debe observar y documentar además que los Terms of use aprobados se muestran antes del Enrollment y que la identidad de prueba los acepta; si se utiliza un proceso de consentimiento independiente, debe emplearse su vía aprobada de acreditación. Sophos recomienda realizar la prueba antes de invitar a usuarios reales; una aprobación aquí no sustituye esa observación ni la posterior decisión de despliegue. Según el modo, las vías de inscripción son el asistente Add-device, la inscripción manual, Self Service Portal o la inscripción automatizada específica de la plataforma; aquí no se afirma que exista una secuencia universal de clics para todos los dispositivos.

4. Reversión y traspaso

Antes del piloto, documentar los valores y permisos originales. Personal, IT contact y Email configuration pueden restablecerse recuperando el valor anterior y pulsando de nuevo Save; después, verificarlo en la cuenta correspondiente, en el dispositivo de prueba o mediante un nuevo mensaje de prueba. Corregir en Fusion cualquier rol concedido por error con un alcance excesivo, utilizando un administrador que siga disponible, y volver a iniciar sesión con la cuenta afectada. Revertir las configuraciones de los grupos piloto y del SSP solo después de comprobar la asignación efectiva; eliminar una configuración sin más no demuestra que se hayan dado de baja los dispositivos ya inscritos ni que se hayan detenido nuevas inscripciones.

Transferir expresamente la retirada de dispositivos de la gestión al responsable de dispositivos e inscripción: Para un piloto de dispositivos dedicados sin usuario, el responsable debe detener también la vía de inscripción autorizada, comprobar que no se pueden inscribir más dispositivos por esa vía e inventariar los dispositivos de prueba ya inscritos; bloquear las invitaciones a usuarios o grupos no detiene por sí solo esa vía. Si se cancela el piloto o este finaliza, pedir primero al responsable correspondiente que detenga las nuevas invitaciones y vías de inscripción dentro del alcance de usuarios y grupos realmente afectado, y comprobar que la medida surte efecto; después, entregarle un inventario de los dispositivos de prueba ya inscritos, con su plataforma, modo, propiedad y asignación. El responsable de dispositivos decide para cada uno sobre la baja, la asignación de usuario y dispositivo y las comprobaciones posteriores, y registra los resultados. Unenroll no revierte los ajustes: según la plataforma, se eliminan perfiles, aplicaciones, certificados, cuentas y datos gestionados; para dar de baja dispositivos Android Enterprise totalmente administrados es necesario restablecerlos de fábrica. Antes de restablecer de fábrica uno de estos dispositivos, el responsable de dispositivos debe acreditar también el estado de FRP, la vía de restablecimiento prevista y la vía aprobada de desbloqueo o recuperación de cuenta para las cuentas FRP efectivamente autorizadas; sin esa acreditación, no restablecerlo. Antes de efectuar una baja, comprobar el modo del dispositivo, la copia de seguridad, la propiedad, la autorización y las consecuencias oficiales específicas de la plataforma. Eliminar no es una simple limpieza del inventario: primero dar de baja el dispositivo siguiendo el procedimiento específico de la plataforma y comprobar el resultado; después, eliminar la entrada de un dispositivo que ya no esté gestionado. Si, en cambio, se elimina un dispositivo todavía inscrito, se dará de baja en la siguiente sincronización; eliminar un dispositivo Android Enterprise totalmente administrado provoca un restablecimiento de fábrica y puede destruir datos. Antes de eliminar una entrada, comprobar qué información del dispositivo y qué datos almacenados deben conservarse; la desaparición de la entrada de la consola no demuestra ni que la baja del dispositivo se haya completado ni que exista una vía para recuperar los datos. En cambio, eliminar la entrada de un dispositivo Windows inscrito no lo da de baja automáticamente; comprobar el estado real en el propio dispositivo. En el caso de dispositivos Apple, antes de restablecerlos, darlos de baja o liberarlos, pedir también al responsable de Apple o del dispositivo que compruebe el estado de Activation Lock y la vía de reactivación correspondiente; no restablecer ni eliminar un certificado APNs o una integración con Apple Business como supuesto método de retirada de la gestión. La opción de la aplicación Unenroll y la acción SSP Unenroll device son controles independientes; ocultar una no deshabilita automáticamente la otra. No presentar la eliminación de dispositivos, la retirada de licencias ni la reversión de ajustes del tenant como métodos reversibles para detener la gestión.

Para el traspaso a operaciones, una segunda persona autorizada debe verificar el tenant y la licencia Mobile, el alcance funcional de los roles delegados, los ajustes básicos guardados, el alcance efectivo del SSP y el traspaso de las decisiones de aprobación o detención y de la retirada de dispositivos de la gestión. El proxy EAS y el flujo de correo de Exchange siguen siendo responsabilidad del encargado de EAS; la sincronización LDAP y de directorios, del encargado de identidades. Sin procedimientos operativos aprobados y disponibles para dispositivos e inscripción, EAS y LDAP, no dar a entender que esos procesos están aprobados ni incluir referencias que no funcionen. Esta guía informativa no certifica que se haya probado ningún tenant ni dispositivo piloto; los cambios reales en dispositivos siguen requiriendo una autorización independiente.