Ir al contenido
Avanet

Planificar y verificar con seguridad las políticas de cumplimiento de Sophos Mobile

Una política de cumplimiento no es un certificado ni un perfil de dispositivo. Evalúa determinadas reglas para los dispositivos inscritos y puede desencadenar acciones cuando se infringen. Importan la edición real del producto (Sophos Mobile o Sophos Mobile Threat Defense), la plataforma y versión del sistema operativo, si el dispositivo es de empresa o personal, el modo de inscripción y administración, la aplicación Intercept X for Mobile (IXM) administrada por Sophos Mobile, si procede, y el grupo de dispositivos asignado. Que una regla o plantilla PCI/HIPAA aparezca en la consola no demuestra que sea aplicable a todos los dispositivos ni acredita certificación alguna.

Antes de cualquier intervención en producción: Check now comprueba todos los dispositivos inscritos y ejecuta las acciones configuradas. Crear o modificar una política y asignarla a un grupo tampoco son operaciones de solo lectura. Primero hay que delimitar todos los dispositivos afectados y definir cómo volver al estado anterior; no se debe usar una flota de producción para hacer pruebas.

¿Qué se evalúa realmente?

Primero hay que identificar la edición del producto y después comprobar la plataforma, el sistema operativo y el modo de inscripción: en Android Enterprise fully managed, MDM administra todo el dispositivo; Apple User Enrollment incorpora dispositivos Apple personales con un ámbito de administración limitado; supervised designa iPhones/iPads supervisados. Que Sophos Mobile administre una aplicación IXM no demuestra que el dispositivo esté sometido a Mobile Device Management (MDM) completo. Hay que contrastar en el propio tenant las reglas disponibles para la edición y el modo realmente utilizados, sin confundir el alcance de reglas y acciones de Sophos Mobile con el de Sophos Mobile Threat Defense.

Las reglas determinan qué funciones o estados del dispositivo están permitidos, prohibidos o son obligatorios. La respuesta a una infracción se elige por separado; un criterio de cumplimiento por sí solo no demuestra que se modifique o imponga activamente un ajuste del dispositivo.

Para crear una política en Sophos Mobile o en la edición independiente Sophos Mobile Threat Defense, abrir el menú Compliance policies, hacer clic en Create compliance policy y seleccionar la plantilla Default, PCI o HIPAA. Introducir un nombre y, opcionalmente, una descripción; elegir una plantilla no limita los ajustes posteriores. Solo la plantilla Default carece de acciones preconfiguradas; PCI/HIPAA pueden incluirlas. Sophos describe las reglas y acciones de las plantillas PCI/HIPAA como basadas en HIPAA y PCI DSS. Sin embargo, el orden de las plantillas y los estándares en la documentación es ambiguo; aquí no se deduce de él una correspondencia entre una plantilla concreta y un estándar. La pestaña de cada plataforma debe activarse mediante Enable platform: sin esa casilla no se comprueba el cumplimiento de los dispositivos de dicha plataforma. Los niveles de gravedad high, medium y low están asignados de forma fija a las reglas; no equivalen a una acción de respuesta elegida libremente. Al planificar la política, ayudan a valorar la importancia de cada regla y a elegir una respuesta adecuada a una infracción. Esto no autoriza a ejecutar una acción durante un incidente. Highlight rules, en la edición completa, ayuda a resaltar un tipo de administración, pero no demuestra que una regla tenga efecto en todos los dispositivos de ese tipo.

Solo cuando se hayan configurado y revisado las reglas y sus respuestas para todas las plataformas necesarias, hacer clic en Save. Así se guarda la política con el nombre introducido; la posterior asignación a grupos se realiza por separado, tras las comprobaciones descritas más abajo.

  • Sophos Mobile (edición completa/MDM): Además de las reglas de administración y del sistema operativo, que varían según la plataforma, puede haber señales de IXM si Sophos Mobile administra la aplicación. Las respuestas disponibles por regla son Deny email, Lock container, Set health, Create alert y Transfer task bundle; siguen siendo aplicables las restricciones de plataforma y los requisitos de cada acción.
  • Sophos Mobile Threat Defense (edición de producto independiente): Su conjunto separado de reglas incluye, entre otras, permisos de IXM y detecciones de malware y aplicaciones en Android, filtrado web en iOS y reglas de seguridad para Chromebooks. Para esta edición se describe Create alert como respuesta, no las acciones de MDM relativas al correo, contenedores, Health o paquetes de tareas.

En la edición independiente, Installed apps y Mandatory apps solo se aplican a Chromebooks. En Installed apps, seleccionar primero Allowed apps o Forbidden apps y después el grupo de aplicaciones con las aplicaciones o extensiones permitidas o prohibidas, respectivamente. En Mandatory apps, seleccionar el grupo de aplicaciones con las aplicaciones o extensiones que deben estar instaladas. Las correspondencias para Android, iOS y Mac descritas más abajo, así como las indicaciones sobre aplicaciones del sistema y actualizaciones de aplicaciones Android, pertenecen al catálogo general de la edición completa de Sophos Mobile, no a estas dos reglas de la edición independiente Threat Defense.

El catálogo independiente Mobile Threat Defense compliance rules, dentro de la ayuda de Sophos Mobile, describe un subconjunto para dispositivos Android/iOS cuya aplicación IXM administra Sophos Mobile: por ejemplo, root/jailbreak, límites de versión del sistema operativo, sincronización de IXM y análisis de aplicaciones Android. Una aplicación administrada no demuestra por sí sola la administración MDM completa del dispositivo; este subconjunto tampoco es el catálogo de reglas de la edición independiente Sophos Mobile Threat Defense. En Android, la regla Intercept X for Mobile permissions can be denied determina si denegar permisos a la aplicación IXM hace que el dispositivo deje de cumplir la política. Puede mostrar como infracción la pérdida de Web Filtering cuando se deniega Accessibility Service; Sophos recomienda el valor No si se utiliza Web Filtering. La regla de iOS Web Filtering turned on figura en el catálogo general de reglas de Sophos Mobile y en el de la edición independiente Threat Defense, no en el subconjunto de IXM mencionado. En iPhones y iPads, exige que la función Web Filtering de Intercept X for Mobile esté activada; es un criterio independiente, no la regla de permisos de Android. Las reglas de Chromebook no son automáticamente reglas de Android/iOS.

El subconjunto de IXM administrada está documentado en ambas ayudas, tanto en la de Sophos Mobile como en la de Sophos Mobile Threat Defense. Para los dispositivos cuya aplicación IXM administra Sophos Mobile, establece las siguientes correspondencias:

  • Managed required se aplica a Android e iOS. La regla determina la respuesta cuando un dispositivo deja de estar administrado. No equivale a Device administrator management allowed ni demuestra una administración MDM completa.
  • Minimum OS version y Maximum OS version se aplican a Android e iOS en este subconjunto. Establecen la versión mínima requerida y la versión máxima permitida del sistema operativo, respectivamente. La ausencia de una lista de plataformas en el catálogo general que figura más abajo no modifica esta correspondencia.
  • Malware apps allowed solo se aplica a Android en este subconjunto. Esta regla determina si se permiten las aplicaciones maliciosas detectadas por IXM.
  • PUAs allowed solo se aplica a Android en este subconjunto. Esta regla determina si se permiten las aplicaciones potencialmente no deseadas detectadas por IXM.

Las dos reglas de aplicaciones evalúan el cumplimiento. No son ajustes de análisis ni una autorización para desbloquear las aplicaciones detectadas o excluirlas de futuros análisis. Las consecuencias de las detecciones y las excepciones se revisan por separado en la guía de respuesta a un incidente de cumplimiento enlazada más abajo.

Una regla Maximum interval between … synchronizations es una regla de cumplimiento configurable para la fuente de sincronización correspondiente: el software MDM nativo del sistema operativo, Sophos Mobile Control, IXM o Sophos Chrome Security. En el catálogo general se establece la siguiente correspondencia:

  • Native MDM: iPhones/iPads sin Sophos Mobile Control ni IXM, así como Mac y equipos Windows.
  • SMC (Sophos Mobile Control): dispositivos Android e iPhones/iPads.
  • Intercept X for Mobile: dispositivos Android e iPhones/iPads.
  • Sophos Chrome Security: Chromebooks.

Cada una de estas reglas limita el intervalo máximo permitido entre las sincronizaciones del agente correspondiente con Sophos Fusion; no intercambiar agentes ni valores de tiempo. En cambio, Maximum interval between Intercept X for Mobile scans limita en Android el intervalo entre análisis de malware de IXM, no entre sincronizaciones. Solo se puede evaluar si se ha superado un límite examinando la regla efectivamente activada e infringida y la hora de sincronización o análisis correspondiente. Por separado, una sincronización retrasada o fallida puede hacer que el estado de cumplimiento mostrado esté desactualizado; por sí sola no demuestra ni una infracción ni conformidad. Un estado desconocido para el EAS Proxy constituye otro caso distinto dentro del proceso de cuarentena de Exchange configurado aparte; no implica automáticamente una infracción de la regla de intervalo máximo.

Seleccionar las reglas según lo que se necesita comprobar

Los siguientes grupos organizan el catálogo general de reglas de la edición completa de Sophos Mobile para facilitar la planificación. No son una lista de valores predeterminados recomendados. Primero hay que comprobar la edición y el modo de gestión; después, seleccionar únicamente los criterios adecuados y revisar por separado la respuesta de cada regla.

Estado de gestión, versiones y actualizaciones

  • Managed required / Device administrator management allowed: La primera regla se refiere a dispositivos que han dejado de estar gestionados; la segunda determina las acciones para los dispositivos Android en los que el propio Sophos Mobile actúa como Device Administrator. Este modo de gestión está obsoleto en Sophos Mobile y solo está disponible para Android 9 o versiones anteriores; no puede utilizarse con Android 10 o versiones posteriores. Sophos recomienda migrar a Android Enterprise. Se trata de una limitación de este modo de gestión de Sophos Mobile, no de una afirmación de que las API de Android Device Administrator se hayan eliminado en general ni de una guía para incorporar nuevos dispositivos en ese modo.
  • Minimum SMC version: Versión mínima permitida de la aplicación Sophos Mobile Control, para Android e iPhones/iPads. No confundirla con la versión de IXM ni con la del sistema operativo.
  • Minimum OS version / Maximum OS version: Versión mínima y máxima permitida del sistema operativo, respectivamente. El catálogo no incluye una lista específica de plataformas para estas dos entradas; comprobar su disponibilidad en la pestaña de la plataforma correspondiente.
  • Mandatory OS updates: Para iPhones/iPads supervisados, no para Apple User Enrollment. Latest available update exige la última actualización disponible; Latest critical update, la última actualización que Apple haya clasificado como crítica. La última actualización disponible puede ser más reciente que la última crítica. Latest critical update no está disponible a partir de iOS/iPadOS 27. Para gestionar las actualizaciones de estos dispositivos, Sophos indica una política declarativa con Software update settings o Enforced software update; no deducir que la selección de cumplimiento anterior mantenga el mismo efecto. Software update settings requiere iOS/iPadOS 26 o posterior, el modo de administración Apple Device Enrollment y un dispositivo supervisado. Para Enforced software update, Sophos indica como requisitos iOS/iPadOS 26 o posterior y Apple Device Enrollment, pero no añade un requisito de supervisión. Esta versión mínima 26 es distinta del límite 27 para la selección anterior Latest critical update.

La información sobre actualizaciones de Apple necesita una ruta de red propia: Para obtener información sobre las actualizaciones disponibles en iPhone, iPad y Mac, mesu.apple.com debe ser accesible mediante HTTPS 443. Si este destino no es accesible, Sophos Mobile no dispone de información sobre actualizaciones; en ese caso, las reglas de cumplimiento relativas a actualizaciones obligatorias no tienen efecto. Comprobar la ruta real con el equipo de administración de red antes de considerar fiable el estado de una regla de este tipo. Esto no amplía las limitaciones de plataforma, sistema operativo o inscripción de Mandatory OS updates mencionadas anteriormente, ni afirma que fallen todas las instalaciones de actualizaciones de Apple.

Protección del dispositivo y separación de los datos de trabajo

  • Root access allowed (Android): Determinar si se permiten dispositivos con acceso root. La autorización documentada también incluye dispositivos Sony con Enterprise API Level 4 o posterior y dispositivos Samsung con Knox Standard SDK 5.5 (API Level 17) o anterior que el sistema operativo considera inseguros. Son precisiones históricas de la ayuda de la regla, no una recomendación para utilizar hoy esos dispositivos.
  • Android Debug Bridge (ADB) allowed (Android): Determinar si se permite o prohíbe la interfaz de depuración ADB.
  • Allow jailbreak (iPhone/iPad): Determinar por separado si se permiten dispositivos con jailbreak; no trasladar la regla de root de Android.
  • Screen lock required (Android, iPhone/iPad, Windows): Determinar si se exige una contraseña del dispositivo u otro mecanismo de bloqueo. En Android cuentan Pattern, PIN y Password, no Swipe. En Apple User Enrollment, la regla se cumple si la política asignada contiene una configuración Password policies.
  • Encryption required (Android, Mac, Windows): Exigir cifrado; en macOS, la regla se refiere al cifrado completo con FileVault. Según la ayuda de la regla, los iPhones y iPads siempre están cifrados y no figuran en su lista de plataformas compatibles.
  • Container configured (Android): Debe haber un contenedor configurado y activado, por ejemplo, un perfil de trabajo de Android o un contenedor Samsung Knox. Es un criterio de estado, no la respuesta Lock container.
  • Data roaming allowed: Permitir o prohibir la itinerancia de datos, para Android e iPhones/iPads sin Apple User Enrollment.

No aplicar una reparación general al cifrado de Android: La ayuda actual de la regla aún menciona Require PIN to start device o Require Password to start device al configurar un bloqueo de pantalla. Esto no demuestra que esas opciones de PIN o contraseña de arranque estén disponibles en versiones actuales de Android ni en todos los modos de Android Enterprise. La KBA-000004067, por separado, describe un fallo con la clave de cifrado predeterminada que aparece en pantalla y propone como remedio un PIN de arranque y una sincronización manual, sin especificar versión del sistema operativo ni modo de inscripción; no es una solución universal para versiones actuales de Android ni para los modos de Android Enterprise. Antes de intervenir en cualquier dispositivo, hay que identificar el error realmente observado, la versión del sistema operativo compatible y el modo de inscripción; no se debe recomendar cambiar el PIN de forma generalizada ni pulsar Synchronize now.

Aplicaciones, perfiles y permisos

  • Installed apps: Seleccionar primero Allowed apps o Forbidden apps y después el grupo de aplicaciones permitidas o prohibidas. Se aplica a Android, iPhones/iPads sin Apple User Enrollment, Mac y Chromebooks. Las aplicaciones del sistema de Android siempre están permitidas; los grupos de aplicaciones de Chrome OS pueden incluir aplicaciones y extensiones.
  • Mandatory apps: Seleccionar de la lista el grupo de aplicaciones que deben estar instaladas. Los grupos de Chrome OS también pueden incluir extensiones. En iOS, no incluir aplicaciones del sistema como obligatorias: Sophos Mobile no puede detectar su instalación y, según la ayuda de la regla, marca todos los dispositivos afectados como no conformes. Para Android, Sophos describe en SMCAND-3159 que las actualizaciones simultáneas de aplicaciones durante una sincronización de la aplicación Control con el backend de Mobile pueden hacer que el estado pase brevemente a no conforme y luego vuelva a conforme, especialmente en dispositivos más antiguos. Para evaluar la situación mediante comprobaciones de solo lectura, comparar la regla realmente incumplida, el momento de las actualizaciones y de la sincronización, así como el estado observado posteriormente. Esto no justifica flexibilizar la regla de aplicaciones obligatorias. Un estado conforme posterior no permite deducir que el funcionamiento no haya tenido consecuencias ni que se haya restablecido el acceso a aplicaciones, correo o Wireless; el retorno automático a la conformidad documentado no es un resultado observado aquí ni implica un plazo garantizado.
  • Suspicious apps allowed (Android): Determinar si se permiten las aplicaciones sospechosas detectadas por IXM. Es una selección de cumplimiento independiente, no equivale automáticamente a los ajustes de análisis de aplicaciones de baja reputación.
  • Third-party profiles allowed (iPhone/iPad, sin Apple User Enrollment): Determinar si se permiten perfiles de configuración que no estén gestionados por Sophos Mobile.
  • Unmanaged apps from unknown sources allowed (iPhone/iPad): Determinar si se permiten aplicaciones de desarrollo propio instaladas manualmente mediante un archivo IPA y firmadas con un perfil de aprovisionamiento ad hoc. No equipararla a la regla de Chromebook para aplicaciones ajenas a Chrome Web Store.
  • SMC permissions can be denied (Android): La aplicación Control necesita para funcionar permisos que deben concederse durante la instalación. La regla determina si denegarlos provoca una infracción de cumplimiento. Se trata de una aplicación distinta a la de Intercept X for Mobile permissions can be denied, descrita anteriormente.
  • Locate permission required (Android): Para la función Locate, determinar si se exige, para cumplir la política, el permiso concedido a la aplicación Control durante la instalación para obtener datos de ubicación.
  • App is able to locate (iPhone/iPad): Los servicios de ubicación deben estar activados y la aplicación Control debe poder utilizarlos. Esta combinación es distinta del criterio de instalación de Android. Ninguna de las reglas de ubicación otorga autorización organizativa ni legal para recopilar datos de ubicación.

Comprobar específicamente Chromebook, Mac y Windows

Chromebooks: Las siguientes reglas se refieren a Sophos Chrome Security, no a la aplicación Control de Android:

  • Tamper protection turned off: Seleccionar las respuestas para el caso de que se haya manipulado la Chrome Security policy.
  • Minimum Sophos Chrome Security version: Establecer la versión mínima permitida de la extensión Chrome Security.
  • Apps from unknown sources allowed: Determinar si se permiten aplicaciones y extensiones ajenas a Chrome Web Store.

Mac: Los criterios se refieren a la protección activada correspondiente, no demuestran que la propia regla de cumplimiento la active:

  • Firewall required: El firewall de macOS debe estar activado.
  • System Integrity Protection required: SIP debe estar activada. Esta función de protección de macOS limita las acciones del usuario root; puede configurarse al arrancar desde macOS Recovery. Esto no autoriza a modificar SIP durante el funcionamiento normal.
  • Security updates required: La instalación automática de actualizaciones de seguridad de macOS debe estar activada. La ayuda de la regla la limita a macOS 26 (Tahoe) o anterior; no es el límite de iOS/iPadOS 27 de la regla de actualizaciones móviles.

Equipos Windows: Seleccionar tres criterios independientes de Defender y no deducirlos de un único estado:

  • Windows Defender must be turned on: La protección en tiempo real de Windows Defender debe estar activada. Este criterio previsto se mantiene. Sin embargo, para Windows 10, Sophos describe en SMCSRV-13801 una limitación de la comprobación: la regla solo comprueba si el servicio de Defender está en ejecución, no si la protección en tiempo real está activada. Por tanto, un dispositivo puede aparecer como conforme aunque la protección esté desactivada. Antes de confiar en la protección, comprobar por separado y solo en modo de lectura la protección en tiempo real efectiva en el dispositivo Windows 10 en cuestión, sin cambiar los controles de protección ni las políticas. Un servicio en ejecución y el estado de conformidad no sustituyen esta comprobación del dispositivo.
  • Clean status from Windows Defender required: El dispositivo no cumple la política si Windows Defender muestra advertencias.
  • Up-to-date Windows Defender definitions required: Windows Defender debe utilizar las últimas definiciones de spyware.

No confundir las respuestas con las reglas

  • Create alert crea en la edición completa un evento visible en la página de detalles del dispositivo y una alerta; Threat Defense describe alertas en Sophos Fusion. Una alerta no equivale a un bloqueo configurado del correo o de un contenedor. Sin embargo, seleccionar solo Create alert no garantiza que la Health del dispositivo ni el acceso inalámbrico permanezcan sin cambios; también puede haber otras consecuencias del incumplimiento.
  • Deny email es una respuesta configurada a la infracción de una regla de política en la edición completa; requiere una conexión configurada con Sophos Mobile EAS Proxy y está prevista para Android, iPhone/iPad y Windows. La mera existencia de un EAS Proxy no demuestra que el servicio de correo correspondiente se autentique mediante él ni que la entrega se haya interrumpido o restablecido realmente. Por otra parte, Sophos describe una cuarentena de Exchange para dispositivos no inscritos solo si EAS Proxy funciona en PowerShell mode y se ha configurado la correspondiente regla predeterminada de acceso a Exchange. Allí también pueden quedar en cuarentena dispositivos inscritos si el proxy desconoce su estado de cumplimiento por llevar demasiado tiempo sin sincronizarse o por falta de conexión con Sophos Mobile. La notificación de inscripción que Exchange envía en ese proceso de cuarentena no es Create alert ni demuestra que se haya activado Deny email. No hay que inferir una cuarentena general ni una recuperación automática del correo a partir de una infracción o una alerta; la investigación pertenece a la respuesta a incidentes, no a esta planificación de políticas.
  • Lock container está previsto en la edición completa actual para Android Enterprise; no se puede dar por confirmada una función de bloqueo de contenedor en iOS. La tabla de acciones de cumplimiento de la edición completa describe esta acción configurada como un bloqueo de todas las aplicaciones excepto Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages y Phone. Esta descripción general no determina el efecto en las aplicaciones del perfil personal BYOD; ni las seis excepciones ni el ejemplo del perfil de trabajo siguiente demuestran que las aplicaciones personales sigan accesibles. Para un perfil de trabajo Android compatible, Sophos documenta en el control de acceso independiente las opciones Auto (valor predeterminado sin permiso de acceso manual: el perfil de trabajo se bloquea si una regla de cumplimiento infringida incluye Lock container), Deny (perfil de trabajo bloqueado) y Allow (perfil de trabajo desbloqueado). Cuando se bloquea, las aplicaciones y los datos del perfil de trabajo quedan inaccesibles; el ajuste solo se aplica tras sincronizar el dispositivo. Este control de acceso del perfil de trabajo es distinto de la orden de bloquear todo el dispositivo; no demuestra el efecto de la acción de cumplimiento configurada sobre las aplicaciones personales, ni su disponibilidad en todos los escenarios BYOD o de inscripción, ni una reversión probada. Antes de autorizar el cambio, comprobar el ámbito y el efecto en un dispositivo de prueba autorizado.
  • Distinguir Set health de la Health calculada: Set health es una acción elegida expresamente para cada regla en la edición completa: cuando se infringe, se asigna el valor seleccionado rojo/amarillo/verde; si se infringen varias reglas, prevalece el peor valor de Health asignado. Para Android, iPhone y iPad, esta acción requiere que Synchronized Security esté activada; para obtener el efecto inalámbrico previsto, también deben configurarse en la política el valor de Health para los dispositivos no conformes y las reglas de Wireless. Por otra parte, Fusion muestra una Health del dispositivo basada en infracciones de reglas de cumplimiento; con Synchronized Security activada puede sobrescribirse manualmente, mientras que Auto vuelve a calcularla a partir del estado de cumplimiento. No está aclarado qué valor se genera sin una acción Set health en cada edición y modo, ni qué prioridad tiene una modificación manual frente a una acción de regla simultánea; no se debe deducir de Create alert ni una asignación automática de rojo/amarillo ni que la Health permanezca igual. Hay que comprobar por separado la regla infringida y el incumplimiento, la acción Set health guardada, la Health mostrada y su modo manual/Auto, el valor comunicado a Wireless y el acceso real. Sophos Wireless puede restringir el acceso a la red según la configuración; una indicación en la consola por sí sola no demuestra un efecto inalámbrico concreto.
  • Transfer task bundle puede configurar mal los dispositivos o incluso borrarlos. No establecer tareas de borrado/restablecimiento ni paquetes de tareas automáticos como respuesta predeterminada; None aquí solo significa que no se transfiere ningún paquete de tareas, no que el incumplimiento carezca de consecuencias.

Caso especial: En la edición completa, cuando un dispositivo Android Enterprise fully managed no cumple la política, todas sus aplicaciones se desactivan automáticamente, con independencia de la respuesta elegida para cada regla. Esto no equivale a la acción configurable Lock container, ni está demostrado que suceda en dispositivos Android BYOD/con perfil de trabajo, dispositivos solo MTD u otros modos de Android. En Android BYOD, el efecto de Lock container depende del modo de administración realmente compatible y de la configuración; no se debe deducir un bloqueo del dispositivo entero de un posible bloqueo del espacio de trabajo. Antes de autorizar cualquier cambio, comprobar en un dispositivo de prueba autorizado la accesibilidad del teléfono, del espacio de trabajo, de las opciones de recuperación y de las aplicaciones críticas.

Synchronized Security no está disponible para todos los dispositivos: Sophos excluye los Chromebooks, Apple User Enrollment y los dispositivos con una dirección MAC específica de la red, privada o aleatoria, porque no comunican su dirección MAC a Sophos Mobile. La posibilidad independiente de enviar la dirección MAC mediante la configuración de la aplicación IXM cuando se usa un EMM de terceros no demuestra ninguna excepción para las direcciones MAC privadas o aleatorias. Planificar una prueba piloto de Wireless solo para un modo de dispositivo/inscripción realmente compatible, con la configuración de MAC y Synchronized Security comprobada; la Health mostrada no sustituye una prueba de acceso.

Asignación gradual en vez de prueba global

  1. Registrar el inventario y los requisitos: Documentar el tenant, la licencia/edición, el modo de administración, la plataforma/sistema operativo, la propiedad, el estado de administración de IXM, la última sincronización, las reglas existentes y las dependencias activas de EAS Proxy y Sophos Wireless. Registrar la compatibilidad con Synchronized Security y las restricciones de MAC, la Health mostrada para cada dispositivo y su modo manual/Auto, las reglas de Wireless existentes y las políticas y asignaciones actuales.
  2. Evaluar cada regla y acción por separado: Abrir el catálogo de reglas actual de la edición correcta del producto; para cada plataforma activada, inventariar cada regla heredada de la plantilla o configurada manualmente y su respuesta. Comprobar la señal, el modo y los requisitos de la acción antes de Save y antes de asignar la política; no considerar pasivas las plantillas PCI/HIPAA. Para una prueba piloto aprobada, planificar una política nueva y aislada sin acciones de bloqueo ni destructivas y volver a comprobar las acciones que quedaron realmente guardadas. La ausencia de Set health no demuestra que la Health calculada o modificada manualmente ni el acceso a Wireless sigan iguales. Importante: Ni siquiera Create alert como única acción o None para un paquete de tareas impide la desactivación automática documentada de las aplicaciones en un dispositivo Android Enterprise fully managed no conforme. Excluir dichos dispositivos de esta prueba piloto de solo alertas o sin acciones hasta que se autorice y prepare una prueba específica de la accesibilidad de las aplicaciones y de la recuperación para la versión y el modo reales.
  3. Elegir un grupo piloto limitado: Considerar por separado los dispositivos de empresa y los personales previstos. Si se necesita un grupo nuevo para la prueba piloto aprobada, primero preparar el grupo de dispositivos y contrastar su alcance. Si se gestionan ambos tipos de propiedad, Sophos recomienda políticas de cumplimiento distintas para dispositivos de empresa y personales; dos campos de asignación separados no significan por sí solos que se utilicen políticas diferentes. En Device groups > [nombre del grupo] > Compliance policies se asignan por separado las políticas de corporate y personal. Antes de Save, comprobar para cada dispositivo de destino su único grupo de dispositivos actual (incluido el grupo Default existente, si está asignado), su tipo de propiedad (corporate/personal) y la política asignada a ese grupo, para detectar cualquier alcance no previsto. Tras seleccionar las políticas para corporate y personal y comprobar el alcance, hacer clic en Save para guardar la asignación al grupo. Después, en la página Device groups, comparar las dos columnas Compliance policy (corporate) y Compliance policy (personal) del grupo elegido con la asignación prevista. Antes de modificar una política existente y compartida, revisar todos los grupos a los que esté asignada; el cambio puede afectar a otros grupos, pero no porque un dispositivo pertenezca a varios grupos. Una nueva prueba piloto aislada no debe modificar tácitamente una política compartida.
  4. Comprobar el efecto en la prueba piloto autorizada: Antes de provocar deliberadamente una infracción, volver a asegurarse de que no haya ningún dispositivo Android Enterprise fully managed en la prueba piloto de solo alertas o sin acciones; Create alert y None no protegen sus aplicaciones. Comparar primero la asignación del grupo y el dispositivo concreto con su nuevo valor de cumplimiento, la regla infringida, la hora de sincronización y, en su caso, la alerta o el evento. En un dispositivo de prueba compatible, observar por separado antes y después de la infracción la acción Set health realmente guardada, la Health mostrada y su modo manual/Auto y, si está activada Synchronized Security, la Health comunicada, la regla de Wireless y el acceso real a Wireless; comprobar también el flujo del correo y la accesibilidad de las aplicaciones si la configuración lo requiere. No dar por supuesto que el acceso a la red permanecerá igual aunque no haya una acción Set health; no interpretar una sincronización retrasada o ausente como conformidad. Provocar deliberadamente una infracción solo si se ha confirmado cómo revertirla y sin poner en riesgo datos de producción. Antes de ampliar el alcance a dispositivos Android Enterprise totalmente administrados, comprobar primero en un dispositivo autorizado si la consecuencia automática documentada se produce en la versión y el modo reales y si la recuperación funciona.
  5. Ampliar solo tras la aceptación: Comparar los dispositivos afectados y las infracciones inesperadas con el estado inicial. Si aparecen desviaciones, detener la ampliación, restaurar tras la autorización la asignación de grupo y la configuración de reglas y acciones anteriores que se documentaron, y volver a verificar la recuperación en el dispositivo y en los servicios externos. Eliminar una regla no revierte automáticamente los paquetes de tareas ya ejecutados, los borrados ni los bloqueos de acceso externos.

No utilizar como prueba: Compliance policies > Check now afecta a todos los dispositivos inscritos y ejecuta las acciones configuradas, aunque solo se pretendiera probar un grupo pequeño. Antes de una comprobación global prevista, deben revisarse todos los grupos y respuestas y aprobarse el cambio; este artículo no autoriza a pulsar ese botón en un tenant de producción.

Solo como ejemplo de planificación, no probado: Un grupo aprobado expresamente con un iPhone de empresa (sin Apple User Enrollment y que no sea Android Enterprise fully managed), una regla no destructiva cuya aplicabilidad se haya comprobado previamente y Create alert podría servir como prueba piloto limitada. Antes de asignar la política, registrar todas las parejas de reglas y acciones, las pertenencias a grupos y, si Wireless forma parte de la prueba, la compatibilidad con Synchronized Security y la configuración de MAC y Wireless. Ante una infracción de prueba autorizada y reversible, comprobar en la edición completa la infracción/el incumplimiento y el evento en la página de detalles del dispositivo en la consola, así como la alerta en la consola; en la edición independiente Sophos Mobile Threat Defense, comprobar la alerta en la página Alerts de Sophos Fusion. Por separado, comprobar la Health mostrada (manual/Auto) y, en el dispositivo de destino, el flujo del correo, la accesibilidad de las aplicaciones y el acceso real a Wireless antes y después de la sincronización. No deducir solo de Create alert que la Health o la red permanecerán sin cambios. Detener la prueba si resultan afectados otros dispositivos, no se produce la sincronización o la Health o el acceso cambian de forma inesperada; no ampliar el alcance, restaurar la asignación anterior tras la autorización y volver a comprobar sus efectos. Se trata de un plan de verificación, no de un resultado observado.

Alcance y requisitos previos para el uso

La investigación de un dispositivo que ya presenta anomalías o está bloqueado, la clasificación de alertas, el tratamiento de falsos positivos y la recuperación del acceso al correo o a Wireless no forman parte de esta guía de planificación de políticas. Tampoco sustituye una guía de respuesta a incidentes ni de restablecimiento. Una medida relativa al PIN de arranque de Android o una sincronización manual basada en KBA-000004067 no constituyen una reparación general sin comprobar el error concreto y la combinación de dispositivo e inscripción compatible. Para el triaje inicial de solo lectura y la comprobación del acceso Wi-Fi, sirve la guía sobre la respuesta a un incidente de cumplimiento; tampoco otorga autorización operativa.

Los procedimientos descritos no se han validado en dispositivos ni en un tenant. Este artículo no otorga autorización operativa. Aquí no queda resuelta para todos los modos la relación entre la acción Set health elegida, la Health calculada automáticamente o modificada manualmente y el efecto en Wireless. Antes de adoptar estas indicaciones operativamente, deben autorizarse y comprobarse en dispositivos concretos las combinaciones de reglas y acciones para cada edición, sistema operativo y modo, así como las vías de recuperación de EAS/Wireless y de la accesibilidad de las aplicaciones Android.