Políticas de cumplimiento: cifrado, bloqueo, versión e integridad

Un teléfono con el sistema alterado (con acceso de administrador total en Android, o con las restricciones del fabricante quitadas en iOS) pierde garantías que la empresa da por supuestas: aislamiento entre apps, almacenamiento protegido, integridad de lo que se ejecuta. Por eso casi toda política lo incluye como condición.

Hay un matiz que separa a quien lee políticas con criterio de quien las copia: esa señal la produce un software que corre en el propio aparato, y un aparato alterado puede engañar a un detector local. Por eso se trata como una señal valiosa, no como una prueba definitiva. Mejora mucho cuando se combina con una atestación respaldada por el fabricante o por el hardware, y nunca sustituye a los otros controles: cifrado, versión, protección de las apps y, sobre todo, el servidor, que sigue decidiendo qué se le permite a cada petición.

Abre el laboratorio y lee la tabla politica. Cada requisito tiene tres datos: el valor exigido, los días de gracia y qué ocurre cuando el plazo vence. Un plazo de gracia es una decisión de negocio: da margen a la persona para actualizar el sistema o cambiar el PIN antes de perder el acceso. Pero un requisito que no admite margen existe por una razón, normalmente porque la condición incumplida es una señal de que el aparato ya no es de fiar y esperar no arregla nada.

Después lee evaluaciones: cada móvil con su estado, el requisito que incumple y desde cuándo. Cruzar las dos tablas permite saber si un móvil no conforme todavía está dentro de su margen o ya perdió el acceso.

La versión mínima del sistema es el requisito que más discusiones provoca y el que más protege. Un móvil con un sistema que ya no recibe parches de seguridad arrastra vulnerabilidades conocidas, con detalle público, que cualquier aplicación o sitio malicioso podría aprovechar. La política fija una versión por plataforma, y el margen de gracia existe para que una persona pueda actualizar sin quedarse sin acceso de un día para otro.

Al leer la evaluación, el campo incumple dice qué requisito falla, y la política dice cuál de ellos es la versión mínima. No hace falta comparar versiones a mano en el inventario: la evaluación ya lo hizo. Lo que sí conviene hacer es comprobar que el resultado coincide con el inventario, porque una evaluación puede estar desactualizada.

La cifra que se lleva al comité no es la lista, es el número. Un conteo de no conformes se calcula sobre las evaluaciones, no sobre el inventario, y tiene una trampa: hay estados que no son ni «conforme» ni «no conforme». Contar solo lo que está marcado como no conforme da una cifra honesta de incumplimientos medidos; mezclar los «sin evaluar» da una cifra distinta que mide otra cosa. Conviene siempre decir qué se contó.

Cuenta los móviles en estado «no conforme» en la tabla de evaluaciones, incluidos los que todavía están dentro de su plazo de gracia, porque incumplen aunque aún conserven el acceso.

Tres móviles aparecen como «sin evaluar»: dos tienen solo MAM y uno no está inscrito. Esa palabra no significa que cumplan: significa que el sistema no puede mirar el aparato. Tratarlos como conformes es un error de omisión: la política parece limpia porque no se midió lo que podía estar mal. Bloquearlos a ciegas tampoco ayuda: la empresa perdería el acceso de personas que trabajan con apps protegidas.

La práctica razonable es un estado propio, con su propia decisión de acceso: por ejemplo, permitir solo desde apps con protección de datos y limitar lo demás. Y dejar constancia del límite en el informe, para que nadie lea «sin incumplimientos» donde debería leer «sin medir».