Migrar dispositivos Sophos entre tenants de Central

En caso de adquisición de una empresa, consolidación de tenants o asignación incorrecta de un cliente, los ordenadores administrados se trasladan de una cuenta de Sophos Fusion emisora a otra receptora mediante Device Migration. El procedimiento habitual utiliza Endpoint API: primero se crea un Receiving Job en el destino y, después, se inicia el Sending Job correspondiente en la cuenta de origen.

Ámbito de aplicación: La ayuda actual de Sophos describe este procedimiento para «computers». Antes del despliegue, debe confirmarse qué sistemas operativos, tipos de dispositivo, versiones del agente y productos instalados están permitidos en el tenant concreto mediante la documentación actual de Endpoint API, la respuesta del tenant activo o Sophos Support. Los tipos generales de Endpoint API no constituyen una lista de elementos autorizados para la migración. Los Access Points y Switches tienen sus propios procedimientos y no forman parte de este flujo de trabajo de API.

Qué hace Device Migration y qué debe prepararse por separado

Device Migration cambia el registro y la cuenta que administra el ordenador. Tras una migración correcta, queda administrado por la cuenta receptora. Si la migración falla, según Sophos, sigue administrado por la cuenta emisora.

La documentación pública no describe la transferencia de Policies, grupos, excepciones globales, listas de sitios web, licencias, asignaciones de productos, Alerts, investigaciones ni historial de auditoría. Por tanto, no puede deducirse que estos datos se transfieran automáticamente ni que permanezcan íntegramente en la cuenta de origen. Por ello, se prepara la configuración de destino y se comprueba el estado efectivo después de la migración.

Planificar los requisitos y el piloto

Antes del primer Job, se elabora un inventario del origen y del destino y se define un piloto pequeño y representativo. Los servidores críticos, sistemas VDI, dispositivos de teletrabajo, ordenadores aislados y portátiles que se conectan con poca frecuencia se incluyen en oleadas separadas.

Deben cumplirse los siguientes requisitos:

• La persona que ejecuta el proceso posee el rol de Sophos Admin en ambas cuentas.
• Existen API Credentials independientes para ambas cuentas con el rol de credencial Service Principal Super Admin. Un Super Admin humano debe crear y administrar estas credenciales; el rol Admin por sí solo no es suficiente.
• Se conocen el Tenant-ID y el host regional de API de ambas cuentas. Se obtienen mediante la configuración habitual de Sophos API y no se determinan por conjeturas.
• Los Endpoint-IDs que se van a migrar proceden de la cuenta emisora y la idoneidad de cada dispositivo piloto se ha confirmado en el tenant activo o con Sophos Support.
• En el destino se han preparado las licencias, Policies, grupos, excepciones y listas de sitios web adecuadas.
• Los Update Caches, Message Relays y Proxies de la cuenta de destino son accesibles desde la ubicación correspondiente de cada dispositivo.
• Los aislamientos, Alerts abiertos e investigaciones en curso están documentados; las pruebas necesarias de incidentes y auditoría se guardan antes del cambio.

El API Client Secret y el Bearer Token obtenido a partir de él pertenecen, en cada caso, a una cuenta. El Migration Job Access Token que posteriormente genera el Receiving Job es un secreto diferente. Los Client Secrets, Bearer Tokens y Migration Job Access Tokens no deben incluirse en capturas de pantalla, tickets, el historial del shell ni registros operativos.

Habilitar Device Migration en ambas cuentas

Primero, se inicia sesión en la cuenta emisora y después en la receptora, y en cada una se abre Global Settings > Platform > Device Migration:

1. Active Allow device migration.
2. Establezca un límite de tiempo lo más corto posible, pero suficiente para el piloto o la oleada.
3. Antes de iniciar el Job, compruebe de nuevo que la ventana esté activa en ambas cuentas.

Si la opción está bloqueada, la configuración procede de los ajustes globales del administrador del partner o de Enterprise. En ese caso, no se elude la restricción mediante soluciones alternativas; la administración superior responsable debe conceder la autorización.

Realizar la migración con Receiving Job y Sending Job

La ayuda actual de Sophos sobre Device Migration describe el orden de los Jobs. La Endpoint Migration API Guide conduce a la referencia actual de API. Justo antes de la ejecución, se comprueban en la definición actual de Endpoint API la estructura exacta de la solicitud, la asignación de campos y el límite de cantidad vigente. Los payloads o límites históricos no se adoptan sin verificarlos. Se sigue este orden:

1. Crear el Receiving Job en el destino

El patrón de la operación es POST /endpoint/v1/migrations. La llamada utiliza el host regional de API y las credenciales de la cuenta receptora. Envía el Bearer Token en el encabezado Authorization, el ID de la cuenta receptora en el encabezado X-Tenant-ID y, si hay un cuerpo JSON, el encabezado Content-Type: application/json.

El cuerpo identifica la cuenta emisora y los dispositivos confirmados del piloto o de la oleada. En el esquema histórico, estos campos se denominan fromTenant y endpoints; antes de la ejecución debe confirmarse si conservan exactamente esos nombres en el esquema activo y si ambos siguen siendo obligatorios en este paso.

De la respuesta se guardan:

• el ID del Receiving Job;
• el Migration Job Access Token para el Sending Job correspondiente;
• una fecha de caducidad emitida por la API actual, si la hay.

El Job-ID puede incluirse en el registro de cambios. El Migration Job Access Token solo se entrega, mediante un canal seguro para secretos, a la persona o automatización que crea el Sending Job y no se registra de forma permanente.

2. Iniciar el Sending Job en el origen

A continuación, la autenticación se realiza por separado en la cuenta emisora. El patrón de la operación es PUT /endpoint/v1/migrations/{receivingMigrationJobId}. La ruta contiene el Receiving-Job-ID. La llamada envía el Bearer Token en el encabezado Authorization y el ID de la cuenta emisora en el encabezado X-Tenant-ID; si hay un cuerpo JSON, se añade Content-Type: application/json.

El Sending Job utiliza:

• la lista confirmada de Endpoint-IDs de la cuenta de origen;
• el ID del Receiving Job creado previamente;
• su Migration Job Access Token.

El esquema histórico denomina los campos del cuerpo token y endpoints. Estos nombres y la estructura actual de la respuesta también se confirman en la definición activa antes de la ejecución.

La migración comienza con el Sending Job. Antes de enviarlo, se revisan de nuevo el contexto del tenant, la lista de Endpoints y el alcance de la oleada. No debe reutilizarse un token ni un Job-ID de otra ejecución. El Sending-Job-ID devuelto por la API actual se registra junto con el Receiving-Job-ID; solo se registra una fecha de caducidad si la respuesta activa proporciona una.

3. Supervisar el estado y la cola

El progreso se consulta mediante GET /endpoint/v1/migrations/{migrationJobId}/endpoints. La llamada se realiza para el Sending Job y el Receiving Job pertinentes en el contexto de la cuenta emisora o receptora, respectivamente, usando en cada caso su Bearer Token y X-Tenant-ID. Si hay varias páginas de resultados, se consultan todas y se cotejan con cada Endpoint-ID solicitado. De forma opcional, GET /endpoint/v1/settings/migration muestra si la migración está habilitada en la cuenta correspondiente.

La definición activa actual determina los valores de estado y los campos de detalle. El esquema histórico de API utilizaba pending, succeeded y failed; según el resultado, proporcionaba, entre otros datos, un nuevo Endpoint-ID, información temporal y un motivo del error. Estos nombres son orientativos y no garantizan el esquema actual. Se guardan los valores y campos que se emitan realmente.

Los ordenadores permanecen hasta 14 días en la cola de migración. Un ordenador sin conexión debe conectarse durante este periodo. Una ventana de migración configurada con una duración menor puede limitar aún más el tiempo disponible. Si el dispositivo permanece sin conexión más tiempo y la migración caduca, esta falla y un administrador debe volver a incluirlo manualmente en la migración.

Un dispositivo sin conexión que esté pendiente no se desinstala preventivamente ni se modifica mediante cambios locales del Tenant-ID. Primero se restablece la conexión dentro de la ventana válida. Si un intento falla, el dispositivo sigue administrado por la cuenta de origen.

Comprobar el éxito en el origen, el destino y el dispositivo

Un estado de API por sí solo no constituye una prueba de aceptación completa. Antes de la siguiente oleada, los resultados se cotejan entre ambas cuentas y el ordenador.

Evidencias oficiales de la migración

1. En el Audit Log de la cuenta emisora aparece el evento Send endpoints to another tenant.
2. En el Event del ordenador migrado correctamente figura Device registered with new account . It’s now managed by that account.
3. En el caso de un ordenador cuya migración haya fallado, figura en su lugar Device failed to register with new account . It continues to be managed by this account.
4. En el Audit Log de la cuenta receptora aparece Allow endpoints to migrate to this tenant.
5. En el destino, el ordenador está registrado en My Environment > Computers & Servers, asignado a un usuario y actualizado.
6. Los Endpoint-IDs solicitados están asignados íntegramente a los resultados de API; si se proporciona, también se documenta el nuevo Endpoint-ID.

Aceptación operativa

A continuación, se comprueba si el ordenador está realmente protegido y funciona en el destino según lo previsto:

• El tipo de dispositivo, la licencia y los productos instalados corresponden a la configuración de destino prevista.
• El grupo de destino, las Policies efectivas, las excepciones globales y las listas de sitios web son correctos.
• Las actualizaciones del agente, una prueba de protección autorizada y las funciones de respuesta previstas funcionan.
• El comportamiento de Update Cache, Message Relay y Proxy corresponde a la cuenta de destino.
• El registro antiguo de la cuenta de origen no se confunde con el registro activo de destino.

La siguiente oleada pequeña solo comienza cuando coinciden el resultado de API, los Audit y Endpoint Events y la aceptación operativa.

Delimitar los errores de forma segura

El Job permanece abierto

Si la API actual muestra un estado todavía incompleto, primero se comprueba si el ordenador está conectado, puede comunicarse con Sophos y ambas ventanas de migración siguen siendo válidas. Mientras la migración esté habilitada, un dispositivo sin conexión puede permanecer en la cola. Tras un fallo o una caducidad, el Endpoint se vuelve a incluir manualmente con una ventana de migración nueva y válida.

La migración falla

Primero, el motivo del error emitido por la API actual se coteja con el Event del ordenador y los Audit Logs de ambas cuentas. Después, se comprueban el contexto del tenant, el Endpoint-ID, la asignación del Job, la autorización actual de migración y la idoneidad confirmada para ese ordenador. Si el error no está claro, se guardan ambos Job-IDs, el Endpoint-ID, la marca de tiempo, los datos de correlación de API y un archivo SDU, y se entregan a Sophos Support, sin secretos ni tokens.

Si se produce un fallo, la administración no se ha transferido correctamente; el dispositivo permanece en la cuenta de origen. Para una migración ya completada correctamente, la API documentada no acredita ningún procedimiento automático de Cancel, Undo o Rollback. El retorno se planifica como una nueva migración o un nuevo registro que deben confirmarse por separado.

Se rechaza la llamada de API

Se comprueba que el Bearer Token, X-Tenant-ID y el host regional de API pertenezcan a la misma cuenta, y que las API Credentials tengan allí el rol Service Principal Super Admin. El Bearer Token no debe confundirse con el Migration Job Access Token del Receiving Job. Además, Allow device migration debe seguir activo en ambas cuentas.

Alternativa para Windows: volver a registrar con --registeronly

--registeronly no forma parte del procedimiento con Receiving Job y Sending Job y no sustituye la migración mediante API. Este parámetro sirve para volver a registrar por separado un dispositivo Windows ya protegido cuando Device Migration no es adecuada o no está disponible para el caso concreto y esta vía se ha confirmado mediante la documentación actual del instalador de Windows o Sophos Support.

Se aplican requisitos propios:

• El dispositivo Windows cuenta con una instalación funcional de Sophos Protection.
• Se obtiene un instalador SophosSetup.exe actual y sin modificar de la cuenta de destino, en My Environment > Installers.
• Según el requisito documentado para --registeronly, Tamper Protection está desactivado en el dispositivo.
• El comando se ejecuta localmente o mediante distribución de software con privilegios de administrador; el dispositivo debe poder comunicarse con Sophos.

En el dispositivo Windows, se abre un símbolo del sistema o PowerShell como administrador y se inicia el instalador de destino:

.\SophosSetup.exe --registeronly

El nombre del archivo y la ruta pueden variar. Un paquete de la cuenta de origen no permitiría alcanzar el destino. Después del comando se aplican las mismas comprobaciones operativas del destino indicadas anteriormente; que finalice el proceso del instalador por sí solo no constituye una prueba de éxito.

El parámetro de Windows no debe aplicarse a macOS ni Linux. Para volver a registrar otras plataformas, se utiliza el procedimiento actual para esa plataforma documentado por Sophos o se recurre a Sophos Support. Si el agente de Windows está dañado o ya se ha eliminado, no puede utilizarse --registeronly. En ese caso, se sigue el procedimiento admitido de reparación o desinstalación y, después, se realiza una instalación nueva con el instalador de destino. Para Windows, Desinstalar Sophos Endpoint con la protección contra manipulaciones habilitada describe el procedimiento de recuperación admitido.

Los cambios en el Registro de Windows, los trucos con el modo seguro, la manipulación de archivos MCS y la configuración manual de Tenant-IDs no son procedimientos admitidos para una migración ni para volver a la cuenta de origen. Si --registeronly falla, se comprueban el origen y la vigencia del instalador, los privilegios de administrador, la accesibilidad a Internet/Proxy y el estado del agente. Se guardan los registros de instalación y, si es necesario, un archivo SDU antes de recurrir a Sophos Support.

Finalizar la oleada y guardar las evidencias

Después de cada oleada, se cotejan la lista prevista y los resultados. Se documentan:

• el Receiving-Job-ID y el Sending-Job-ID, así como la asignación del Job indicada en el resultado de API;
• el Endpoint-ID anterior y, si se proporciona, el nuevo;
• los datos de estado, tiempo y error emitidos por la API actual;
• la ventana de migración habilitada, el alcance de la oleada y la persona responsable;
• la aceptación técnica y operativa;
• el propietario de las API Credentials utilizadas, pero ningún secreto, Bearer Token ni Migration Job Access Token.

Después de la última oleada, se cierran Allow device migration o las autorizaciones temporales, se eliminan las excepciones provisionales y todos los controles de protección vuelven al estado previsto. Los objetos antiguos del origen no se eliminan indiscriminadamente: primero se comprueban el resultado de API, el estado de propiedad y los requisitos de conservación. Las evidencias de incidentes y auditoría permanecen archivadas por separado conforme a las directrices internas.

Preguntas frecuentes