Retirar Sophos Mobile Container: traspasar los datos y los dispositivos de forma segura
Decisión rápida: No volver a desplegar el Sophos Container, que ya no tiene soporte, con Sophos Secure Email y Sophos Secure Workspace. Una política de Samsung Knox Container corresponde a otra forma de gestión: el fin de Sophos Container no implica el fin general de Samsung Knox Workspace. En los dispositivos existentes, identificar primero el tipo de contenedor, el modo de gestión y los datos empresariales. Ni una nueva inscripción ni la retirada del dispositivo antiguo transfieren automáticamente los datos del contenedor.
¿A qué contenedor afecta?
Sophos Container: Sophos Container con Secure Email y Secure Workspace ha llegado al fin de su soporte. Sophos señala Android Enterprise con perfil de trabajo y Apple User Enrollment como futuras formas de gestión para los escenarios correspondientes de Android y Apple. Son modelos de gestión de destino, no una garantía de que se transfieran archivos, mensajes, cuentas o configuraciones de aplicaciones.
El 6 de mayo de 2024, las aplicaciones Secure Workspace para Android e iOS dejaron de poder descargar documentos de trabajo de Sophos Mobile. El 7 de octubre de 2024, Sophos anunció que estaba retirando la posibilidad de crear nuevas políticas de contenedor para Android e iOS y de añadir o actualizar documentos de trabajo. El 21 de octubre de 2024, Sophos comunicó que empezaba a eliminar los documentos de trabajo de Secure Workspace subidos anteriormente a Sophos Mobile. Esto no demuestra que se hayan eliminado todas las copias ni establece un método de recuperación actualmente admitido; que siga apareciendo una entrada de archivo no prueba que su contenido pueda recuperarse del servicio.
Samsung Knox Container: Las páginas de Sophos sobre Knox container policies que aún se pueden consultar describen los contenedores Samsung Knox: requisitos de contraseña, restricciones y una cuenta de correo electrónico. No acreditan que actualmente se admita un nuevo despliegue de Knox en un dispositivo concreto.
Samsung distingue entre los contenedores CL y COM obsoletos, Knox Workspace como contenedor gestionado y los perfiles de trabajo de Android Enterprise. Aunque Samsung sigue describiendo Knox Workspace como contenedor gestionado en dispositivos aptos, esto no garantiza ni su compatibilidad con Sophos Mobile en el tenant propio ni la disponibilidad de nuevas funciones de Knox.
Android Device administrator es un modo obsoleto en Sophos Mobile, disponible únicamente para Android 9 o versiones anteriores. Ninguna de estas afirmaciones establece una fecha de desactivación general de Knox.
Inventariar sin realizar cambios
Crear una lista de trabajo para cada dispositivo, con responsables y estado de aprobación:
- Registrar el dispositivo, el tipo de propiedad (de empresa o particular), el modelo, la versión de Android o iOS, el usuario y el área de negocio. Comparar el tipo real de contenedor y el modo de gestión en el dispositivo y en el tenant. En la página Show device de Sophos, Status, Policies, Device properties, Installed apps y, en los Samsung, Knox apps y Knox system apps ofrecen indicios, entre otros; que aparezca una aplicación no significa que exista una copia de seguridad de sus datos.
- Revisar las políticas de Knox asignadas, en particular Password, Restrictions y Email account, sin modificarlas. Anotar qué cuentas empresariales, archivos, adjuntos y aplicaciones hay en el contenedor y quién es responsable de esos datos. La entrada documentada de una cuenta Exchange no demuestra ni que la autenticación funcione actualmente ni que sea posible exportar los correos electrónicos almacenados localmente.
- Aclarar con el responsable de los datos si el contenido está en el servicio original o exclusivamente en el contenedor local, si ya existe una copia de seguridad autorizada y si el acceso funciona hoy. En el caso de Knox, comprobar la licencia correspondiente al dispositivo y su fecha de caducidad: una licencia de Workspace caducada puede bloquear el acceso, especialmente en versiones antiguas de Android, sin que los datos necesariamente se hayan borrado. De ello no se desprende un método universal de recuperación.
Detenerse si no hay acceso a los datos: No probar distintas contraseñas ni restablecer el contenedor. Una política de contraseñas de Knox puede borrar el contenedor tras demasiados intentos fallidos. La antigua opción de autoservicio ResetContainerPassword contiene hoy únicamente el aviso del fin de soporte de Sophos Container y la indicación de contactar con TI, no instrucciones de restablecimiento ni de recuperación.
Autorizar el traspaso de datos antes de dar de baja el dispositivo
Antes de cualquier cambio, TI, el usuario y el responsable de los datos deben determinar, para cada tipo de dato afectado y según la titularidad del dispositivo y los requisitos de protección de datos, un método autorizado de exportación específico de la aplicación o de recuperación del acceso desde el servidor, así como el nuevo destino.
Una lista de nombres de archivo o de aplicaciones instaladas no basta: con un pequeño grupo piloto, abrir en el destino los documentos autorizados y los mensajes necesarios utilizando la identidad prevista, y comprobar los permisos de acceso. Solo se debe demostrar la restauración si realmente existe un procedimiento aprobado de copia de seguridad y restauración. Volver a abrir un documento desde el servidor no equivale a restaurar los datos locales borrados del contenedor.
Condición para las copias: Por cada dispositivo, tipo de dato necesario e identidad prevista, comprobar el acceso autorizado e independiente en el nuevo destino aprobado o restaurar realmente la copia en un destino independiente y aprobado durante el piloto. Revisar con el responsable de los datos los contenidos y permisos restaurados; documentar y obtener su aceptación explícita para cualquier contenido exclusivamente local que quede excluido. Una restauración solo en el dispositivo antiguo no autoriza su restablecimiento, baja ni eliminación. Si falta algún dato necesario, detenerse y dejar el dispositivo intacto.
Si falla el acceso o, cuando corresponda, la restauración necesaria, no dar de baja el dispositivo ni borrar datos; escalar el caso a los equipos competentes de Sophos o Samsung y al responsable de los datos, indicando el tipo de dispositivo, el modo de gestión, el estado de la licencia y el error observado. La alternativa puede consistir en dejar intacto el dispositivo antiguo; no se presupone que sea posible una recuperación técnica. En el caso de Secure Workspace, no está acreditada la existencia de una opción general para descargar hoy los documentos del servicio ni para recuperar los ya borrados.
La opción de Knox Allow data export permite a las aplicaciones privadas acceder a los datos del contenedor; no es una función de copia de seguridad lista para usar ni una autorización general para transferir datos empresariales al ámbito privado. Allow all certificates, en el antiguo perfil de correo de Knox, tampoco es una solución aceptable para sortear problemas de autenticación o certificados. No activar ninguna de las dos opciones por precaución.
Autorización y prueba piloto
Solo cuando los datos piloto sean legibles en el nuevo destino y se haya acordado qué hacer si falla el traspaso se debe planificar la gestión adecuada para cada dispositivo. Un piloto satisfactorio no demuestra que los datos guardados exclusivamente en local sean accesibles en todos los demás dispositivos. Para cada dispositivo afectado y cada tipo de dato, comprobar el método de acceso aprobado para ese caso y la autorización del responsable de los datos antes de darlo de baja, eliminar su entrada de la consola, borrar datos, retirar políticas o aplicaciones, o ejecutar un Wipe.
Forma de gestión según la titularidad
Antes de cualquiera de las dos vías, verificar por dispositivo el acceso a los datos y la autorización del responsable según lo indicado arriba. En una inscripción antigua en modo Device administrator, Unenroll desactiva el administrador del dispositivo Sophos Mobile Control, elimina las credenciales de acceso al servidor y otros datos recibidos de este, y restablece Sophos Intercept X for Mobile; después, Delete elimina el registro del dispositivo y sus datos almacenados por Sophos Mobile. Primero darlo de baja y después eliminarlo: borrar un dispositivo aún inscrito puede dejarlo inutilizable. Esta secuencia no transfiere contenido local de Knox ni de Sophos Container. No debe aplicarse a un perfil de trabajo Android Enterprise existente: al retirarlo se borran todas las aplicaciones y todos los datos dentro del perfil. Dar de baja un dispositivo Android Enterprise completamente gestionado exige un restablecimiento de fábrica. Comprobar el modo real y autorizar los posibles riesgos de pérdida de datos antes de actuar.
Comprobación previa a acciones destructivas (antes de Wipe o Delete): En un dispositivo Android Enterprise completamente gestionado, Delete también provoca un restablecimiento de fábrica; Unenroll antes de Delete no lo evita. Para ese dispositivo concreto, confirmar la identidad, la autorización para disponer de los datos y el responsable del restablecimiento y la nueva inscripción, además de Factory Reset Protection (FRP): validar los identificadores de las cuentas de Google configuradas y que el custodio puede utilizar o recuperar sus credenciales tras el restablecimiento. Las cuentas FRP no válidas o las credenciales desconocidas pueden dejarlo inutilizable. Si no se confirma la custodia del dispositivo o las cuentas, detenerse y escalar sin Wipe, Unenroll ni Delete. La retirada de un perfil de trabajo borra sus aplicaciones y datos; la secuencia antigua de Device administrator siguiente solo procede tras comprobar ese modo.
Para los dispositivos Android de empresa ya inscritos en Sophos Mobile en el modo Device administrator, el cambio documentado a Android Enterprise con gestión completa del dispositivo exige primero un restablecimiento de fábrica (en la consola de administración, Show device > Actions > Wipe) y solo después una nueva inscripción. Antes del Wipe deben estar configurados Android Enterprise, comprobados la identidad del dispositivo y los posibles riesgos de pérdida de datos, y acreditados para cada dispositivo el acceso a los datos y la autorización del responsable de los datos; sin esas comprobaciones, no ejecutar el Wipe. Para los dispositivos Android particulares, la otra secuencia documentada solo se aplica si ya están inscritos en el modo Device administrator: tras configurar Android Enterprise, en la consola de administración, ir a Show device > Actions > Unenroll, después a Actions > Delete y, por último, volver a inscribir el dispositivo con un perfil de trabajo de Android Enterprise. No es una acción de autoservicio (SSP) para retirar un perfil de trabajo ya existente. Ambas son formas de gestión, no migraciones del contenido local de los contenedores Knox o Sophos.
Los efectos de Unenroll, Delete, la desinstalación de una política, la desinstalación de una aplicación y Wipe son distintos; en particular, un Wipe puede eliminar datos de forma irrecuperable. No considerar que ninguna de estas acciones, por el mero hecho de que la tarea se haya completado correctamente en la consola, equivalga a un traspaso completo de los datos.
Comprobación final y criterio de parada
Tras el cambio controlado de los dispositivos piloto, comprobar por separado la autenticación, el perfil de trabajo o User Enrollment, las aplicaciones gestionadas y el acceso a los datos empresariales autorizados.
Detenerse en cada dispositivo: Antes de cualquier cambio son necesarios la autorización requerida y, además, o bien el acceso confirmado y autorizado a los datos empresariales aprobados en el nuevo destino o bien, si corresponde, una restauración demostrada. Si falta el acceso y no se ha demostrado una restauración aplicable, dejar intacto el dispositivo antiguo y escalar el caso. Sin autorización, también debe permanecer intacto. Ni la prueba piloto ni la baja del dispositivo demuestran que puedan recuperarse los datos locales borrados.
Restaurar una copia solo en el dispositivo antiguo nunca cumple este criterio. Para cada tipo de dato e identidad necesarios, exigir un destino aprobado accesible de forma independiente o una copia restaurada y validada en otro destino aprobado durante el piloto, con aceptación del responsable para los datos exclusivamente locales excluidos. Sin acceso independiente demostrado, custodia FRP cuando corresponda o aprobación, no realizar acciones destructivas.