No todos los riesgos de un dispositivo vienen de un ajuste que puedas configurar. Un dispositivo puede cumplir todas las políticas que le has asignado y aun así no ser de fiar, sencillamente porque alguien ha modificado su sistema operativo. La postura de seguridad es la señal que te avisa de que eso ha ocurrido.
Responde a una pregunta distinta de la del resto de tus políticas: no "¿está este dispositivo configurado como pedí?" sino "¿puedo seguir confiando datos corporativos a este dispositivo?".
Qué te dice la postura de seguridad
Android Enterprise evalúa cada dispositivo y reporta uno de estos tres valores:
Valor | Qué significa |
|---|---|
Seguro ( | El dispositivo es seguro. |
En riesgo ( | El dispositivo puede ser más vulnerable ante actores maliciosos de lo recomendable para usarse con datos corporativos. |
Potencialmente comprometido ( | El dispositivo puede estar comprometido y los datos corporativos que contiene podrían ser accesibles para terceros no autorizados. |
Potencialmente comprometido es el valor que obtienes ante un dispositivo rooteado. Conviene tratarlo como un incidente y no como un aviso: a partir de ahí ya no puedes dar por hecho que las restricciones de tu política se estén aplicando de verdad, porque el sistema operativo que las aplica es justo la parte que se ha modificado.
Dónde consultarla en el panel
Applivery muestra la postura de seguridad en dos sitios, con dos niveles de detalle distintos.
En el listado de dispositivos
Cada dispositivo del listado muestra un escudo junto al campo de la política. Es un resumen de las comprobaciones de conformidad del dispositivo:
Escudo | Qué significa |
|---|---|
🟢 Verde | El dispositivo es conforme y su postura es Segura. |
⚪ Gris | Algo en el dispositivo requiere atención, pero no es la postura de seguridad. |
🔴 Rojo | La postura de seguridad es En riesgo o Potencialmente comprometido. |
De aquí se derivan dos cosas, y las dos importan cuando estás triando un parque:
El rojo siempre es un problema de seguridad, nunca una configuración pendiente. Gris y rojo son categorías de incidencia distintas y piden respuestas distintas: el gris es operativo, el rojo es una cuestión de si se puede seguir confiando en el dispositivo.
Los dos valores de riesgo levantan el mismo escudo rojo. Para distinguir En riesgo de Potencialmente comprometido, abre el dispositivo.
En las comprobaciones de conformidad del dispositivo
Abre el dispositivo y ve a la sección Overview, donde encontrarás los Compliance checks. Un dispositivo cuya postura esté en riesgo o comprometida tiene una comprobación propia, en rojo, titulada con el valor de la postura: En riesgo o Potencialmente comprometido.
Dentro, por cada riesgo detectado, obtienes:
El nombre del riesgo — SO desconocido, SO comprometido o Evaluación de hardware fallida — con un tooltip que explica qué ha detectado Play Integrity.
El consejo de Google para mitigarlo, dirigido a ti como administrador. Por ejemplo: "El usuario debería bloquear el bootloader de su dispositivo".
Un dispositivo cuya postura sea Segura no muestra ninguna comprobación de seguridad. Aquí la ausencia es la buena noticia: no hay una entrada en verde que lo confirme, así que no interpretes "no hay comprobación de seguridad" como "no se ha evaluado".
Por qué se marca un dispositivo
Cuando la postura no es Segura, el riesgo concreto que hay detrás es uno de estos tres:
Riesgo | Qué ha detectado Google |
|---|---|
SO desconocido ( | El dispositivo ejecuta un sistema operativo desconocido: la comprobación |
SO comprometido ( | El dispositivo ejecuta un sistema operativo comprometido: la comprobación |
Evaluación de hardware fallida ( | El dispositivo no ofrece una garantía sólida de integridad del sistema: falta la etiqueta |
Existe un cuarto valor, Riesgo de seguridad no especificado (SECURITY_RISK_UNSPECIFIED), que aparece cuando Google no concreta el motivo. No es accionable por sí mismo.
Los tres proceden de la Play Integrity API de Google, que es el componente que realmente inspecciona el dispositivo. Applivery reporta el veredicto; no lo genera.
Como la evaluación ocurre del lado de Google, la postura es un informe, no un ajuste. No hay nada que activar en una política para habilitarla, ni ningún valor que puedas configurar para hacerla más estricta.
Los dispositivos AOSP no tienen postura de seguridad
La Play Integrity API forma parte de Google Play Services. Los dispositivos AOSP — las builds sin GMS, habituales en terminales rugerizados e industriales — no tienen Google Play Services, así que no hay ninguna señal de integridad que Android pueda reportar ni postura que Applivery pueda mostrar.
No es una limitación de Applivery, y ningún MDM puede sortearla: el componente que realiza la comprobación sencillamente no está presente en el dispositivo. Si necesitas detección de integridad o de root en un parque AOSP, tiene que venir de una solución Mobile Threat Defense (MTD) de terceros.
Actuar ante un dispositivo comprometido
La postura de seguridad informa de un riesgo, pero no actúa sobre él. Bloquear o borrar es una decisión aparte, y tienes tres vías:
Comandos remotos, aplicados manualmente desde el panel: bloquear el dispositivo, restablecer la contraseña o borrarlo. Es la respuesta directa ante un dispositivo que acabas de ver marcado.
Policy Enforcement Rules, para acciones automáticas de bloqueo y borrado pasados unos días. Fíjate en a qué reaccionan: a un ajuste de la política que no se puede aplicar en el dispositivo, no a la postura de seguridad. Son un complemento útil, no un consumidor de esta señal.
Reglas de automatización, para aplicar automáticamente una política restrictiva de cuarentena. Actúan sobre audiencias de dispositivos, que se construyen a partir de etiquetas, así que necesitas algo que etiquete antes el dispositivo. Eso es lo que aporta una integración de Mobile Threat Defense como Check Point Harmony Mobile: sus grupos de riesgo se corresponden con las etiquetas de Applivery, las etiquetas alimentan una audiencia de dispositivos y la regla de automatización aplica la política de cuarentena.
Una regla de automatización no puede borrar un dispositivo. Sus únicas acciones son aplicar una política y añadir un Smart Attribute: configura dispositivos, no envía comandos. Si hay que borrar un dispositivo comprometido, hazlo manualmente con un comando remoto o haz que la política de cuarentena lleve sus propias Policy Enforcement Rules para bloquear y después borrar. No prometas un flujo de un solo paso del tipo "el MTD lo detecta y Applivery lo borra", porque no es lo que ocurre.
Postura de seguridad y estado de conformidad no son lo mismo
Es fácil confundirlas, y la diferencia importa cuando tienes que explicar un dispositivo marcado:
Postura de seguridad | Estado de conformidad | |
|---|---|---|
Pregunta que responde | ¿Se puede confiar en el sistema operativo? | ¿Cumple el dispositivo las políticas que le asigné? |
Quién decide | Google, mediante la Play Integrity API | La configuración de tu política |
Causa típica de un problema | El dispositivo está rooteado o ejecuta un SO modificado | Un ajuste obligatorio no se aplica, o el usuario ha cambiado algo |
¿Se puede configurar? | No — se reporta, no se establece | Sí — depende de las políticas que definas |
Un dispositivo puede ser perfectamente conforme y estar a la vez Potencialmente comprometido, y esa combinación es precisamente la que conviene vigilar: todo parece correcto, pero la capa que lo garantiza ya no es de fiar.