Todos los dispositivos Android inscritos en Applivery MDM tienen su almacenamiento de encriptación por defecto gracias a la encriptación basada en archivos (FBE) de Android. La configuración encryptionPolicy te permite definir exactamente cómo esa encriptación interactúa con el proceso de arranque del dispositivo — lo que tiene un impacto directo en la gestionabilidad remota.
Cómo funciona la encriptación de Android
Android utiliza la encriptación basada en archivos (FBE), que cifra los archivos de forma individual y divide el almacenamiento en dos áreas:
Tipo de almacenamiento | Cuándo está accesible | Qué contiene |
|---|---|---|
Encriptación del Dispositivo (DE) | Inmediatamente tras el arranque, antes de la autenticación del usuario | Procesos del sistema, apps con soporte para Direct Boot, Android Device Policy |
Encriptación con Credenciales (CE) | Solo después de que el usuario desbloquee con PIN, contraseña o biometría | Datos del usuario, la mayoría de las apps, archivos personales |
Esta separación es lo que hace posible el Direct Boot: el dispositivo puede arrancar, conectarse a Wi-Fi y ejecutar servicios esenciales (incluida la comunicación con el MDM) antes de que el usuario haya introducido su PIN.
Valores de encryptionPolicy
El campo encryptionPolicy en tu política de Android, controla si la encriptación es obligatoria y cómo gestiona el dispositivo el proceso de arranque.
ENCRYPTION_POLICY_UNSPECIFIED
La Android Management API ignora este valor — no se establece ningún requisito de encriptación explícito. El comportamiento de la encriptación depende completamente de los valores predeterminados del propio dispositivo. Este valor no se recomienda para despliegues empresariales gestionados.
ENABLED_WITHOUT_PASSWORD (Recomendado)
La encriptación es obligatoria, pero el dispositivo no requiere el PIN al arrancar. Android deriva la clave de encriptación del hardware del dispositivo al iniciarse, lo que hace que el almacenamiento DE esté disponible de inmediato. El almacenamiento CE (y los datos del usuario) permanece encriptado hasta que el usuario se autentica.
Este es el comportamiento estándar de los dispositivos Android modernos y el valor recomendado para los despliegues empresariales porque:
Android Device Policy se inicia con normalidad tras cada reinicio.
Los comandos remotos (incluido Restablecer contraseña) llegan al dispositivo de inmediato.
El encriptación sigue siendo obligatoria — los datos están totalmente protegidos contra ataques fuera del dispositivo.
ENABLED_WITH_PASSWORD
La encriptación es obligatoria y el dispositivo exige el PIN o la contraseña del usuario al arrancar, antes de descifrar el almacenamiento encriptado. Esto corresponde a la función Inicio seguro en los dispositivos Android.
Cuando ENABLED_WITH_PASSWORD está activo y un dispositivo se reinicia, entra en estado Before First Unlock (BFU) hasta que el usuario introduce su PIN. En estado BFU, Android Device Policy no puede iniciarse — el dispositivo aparece conectado en Applivery pero es completamente inaccesible para los comandos remotos. Consulta Comandos remotos — Solución de problemas para Restablecer contraseña para más información sobre cómo resolver esta situación.
Usa este valor solo si tu política de seguridad exige explícitamente la autenticación antes del arranque — por ejemplo, en entornos regulados donde no se permite el arranque desatendido del dispositivo.
Dónde configurarlo
Una vez en el panel de Applivery, ve a cualquiera de tus Políticas 1. En el menú lateral izquierdo, ve a Restricciones 2, selecciona la sección Sistema y localiza el ajuste Política de encriptación 3.
Cómo elegir el valor correcto
Escenario | Valor recomendado |
|---|---|
Despliegue empresarial estándar |
|
Dispositivos en modo quiosco o desatendidos |
|
Entorno regulado que exige PIN antes del arranque |
|
Dispositivo bloqueado en BFU y no accesible | Recupéralo físicamente y considera cambiar a |
Consideraciones de seguridad
Una preocupación habitual es si ENABLED_WITHOUT_PASSWORD es menos seguro que ENABLED_WITH_PASSWORD. La respuesta depende del modelo de amenaza:
Contra ataques fuera del dispositivo (extraer el chip de almacenamiento y leerlo externamente): ambos valores ofrecen una protección equivalente mediante el FBE de Android. La clave DE se deriva de una clave ligada al hardware que no puede extraerse sin el dispositivo.
Contra un atacante con acceso físico a un dispositivo en funcionamiento:
ENABLED_WITH_PASSWORDañade una capa adicional impidiendo que el dispositivo arranque de forma desatendida, pero esto debe sopesarse frente al riesgo operativo de que los dispositivos queden permanentemente inaccesibles si el usuario olvida su PIN.
Para la mayoría de los despliegues empresariales, ENABLED_WITHOUT_PASSWORD ofrece el equilibrio adecuado entre seguridad y control operativo.