
La gestión de dispositivos solo contribuye a la seguridad en los dispositivos y ajustes que realmente cubre. Un panel de MDM que muestra dispositivos conformes requiere una segunda pregunta: ¿qué dispositivos faltan? Y le sigue una tercera: ¿«conforme» describe una configuración eficaz o simplemente una política asignada a un endpoint?
Para un CTO, la tarea consiste en que esas respuestas sean reproducibles. La gestión de dispositivos móviles debe conectar la titularidad de los dispositivos, la configuración, el acceso a las aplicaciones, la respuesta a incidentes y las evidencias. El objetivo no es un panel en verde. Es una explicación defendible de qué endpoints pueden acceder a la información de la empresa, cómo están protegidos y qué ocurre cuando la protección falla.
La gestión de dispositivos móviles (MDM) es la administración de endpoints mediante un servicio central y los mecanismos de gestión que admite cada plataforma. Según el producto, el sistema operativo y el modo de inscripción, puede desplegar perfiles de configuración, distribuir aplicaciones, informar del estado del dispositivo, restringir determinadas funciones y emitir comandos remotos. Los productos de gestión de endpoints más amplios pueden incluir portátiles y equipos de sobremesa junto a teléfonos y tabletas.
Estas capacidades no son uniformes. Un teléfono corporativo totalmente gestionado y un teléfono personal con un perfil de trabajo gestionado ofrecen controles y telemetría diferentes. Algunas plataformas utilizan servicios de gestión integrados; otras requieren agentes adicionales. No debe suponerse ni una conectividad continua ni una ejecución inmediata.
El MDM tampoco sustituye a la gestión de identidades, la detección en endpoints, la gestión de vulnerabilidades ni la clasificación de la información. Puede configurar esos controles o aportarles señales, pero su funcionamiento requiere una verificación independiente. Un dispositivo gestionado puede seguir teniendo permisos de aplicación excesivos, una sesión no revocada o una aplicación vulnerable.
Antes de seleccionar los ajustes, defina la afirmación de control. Por ejemplo: «Los portátiles de la empresa que acceden al entorno de administración de producción deben estar inscritos, cifrados, tener soporte y haber sido evaluados recientemente». Esa afirmación identifica una población, un recurso y condiciones observables. «Todos los dispositivos son seguros» no lo hace.
ISO/IEC 27001 se refiere a un sistema de gestión de la seguridad de la información con un alcance definido, no a la compra de una herramienta de endpoints concreta. Sus cláusulas 4 a 10 establecen los requisitos del sistema de gestión. El Anexo A ofrece un conjunto de referencia de 93 controles cuya aplicabilidad se considera mediante la evaluación y el tratamiento de riesgos; no es una lista universal de configuración de MDM.
La Declaración de Aplicabilidad recoge los controles necesarios, la justificación de su inclusión, su estado de implementación y la justificación de las exclusiones de controles del Anexo A. Un despliegue de MDM aporta parte de la implementación y de las evidencias de los controles pertinentes, pero no demuestra todo el SGSI.
Algunas conexiones útiles:
| Área de ISO/IEC 27001:2022 | Contribución de los endpoints | Evidencias adicionales necesarias |
|---|---|---|
| Cláusula 5.2 y A.5.1, políticas de seguridad de la información | Los ajustes técnicos implementan las reglas aprobadas para endpoints | Aprobación, comunicación y revisión de la política |
| A.8.1, dispositivos de usuario final | Inscripción, configuración y protección de la información accesible desde los endpoints | Cobertura de la población, titularidad y excepciones |
| A.5.15–A.5.18, gestión de accesos e identidades | Las condiciones del dispositivo respaldan las decisiones de acceso | Ciclo de vida de las identidades, autorización y revisiones de accesos |
| A.8.2, A.8.3 y A.8.5 | Las restricciones respaldan el acceso privilegiado, el acceso a la información y la autenticación | Aplicación de las restricciones en las aplicaciones y registros de autenticación |
| A.8.8, A.8.9 y A.8.19 | Despliegue de actualizaciones, gestión de la configuración y controles de instalación de software | Decisiones sobre vulnerabilidades, registros de cambios y permisos de instalación |
| A.8.24, uso de la criptografía | Configuración del cifrado y mecanismos de recuperación | Política criptográfica y evidencias del ciclo de vida de las claves |
Estas correspondencias describen contribuciones, no equivalencias. Por ejemplo, desplegar una configuración de inicio de sesión no demuestra que el acceso privilegiado esté debidamente aprobado. Utilice nuestra guía del Anexo A para conectar las medidas de endpoints con el SGSI en su conjunto, en lugar de tratar la conformidad de los dispositivos como una puntuación aislada.
Empiece por los dispositivos que almacenan, tratan o acceden a información dentro del alcance del SGSI. Incluya, cuando proceda, los equipos propiedad de la empresa y los de propiedad personal, los endpoints de contratistas, los dispositivos compartidos y los dispositivos de préstamo temporal. Acuerde los sistemas operativos admitidos, las reglas de inscripción y los límites de privacidad.
Construya el inventario en torno a identificadores estables y no solo a nombres visibles. Algunos campos útiles son el identificador del activo, el identificador de gestión, el usuario asignado, la titularidad, la plataforma, el modo de inscripción, la finalidad de negocio, la fecha de inscripción, el último contacto y el estado de baja. Registre explícitamente los custodios de los dispositivos compartidos.
Concilie el inventario del MDM con fuentes independientes. Los registros de compra de activos revelan equipos que nunca se inscribieron. Los registros de inicio de sesión de identidades y los registros de acceso a aplicaciones pueden revelar endpoints ausentes de la gestión. Los registros de protección de endpoints pueden poner de manifiesto agentes duplicados o dispositivos gestionados en otro sitio. Compruebe qué identificadores proporciona realmente cada fuente antes de intentar cruzarlas.
Clasifique las discrepancias en lugar de excluirlas en silencio:
El denominador importa. Un «98 % de conformidad» entre los dispositivos inscritos puede ocultar una población no gestionada considerable. Informe de la cobertura por separado de la conformidad de la configuración y conserve la fecha de la conciliación y los registros sin resolver.
Una configuración de referencia para endpoints debe traducir las decisiones de riesgo en ajustes y criterios de verificación. Debe distinguir plataformas y modelos de titularidad en lugar de fingir que todos los ajustes funcionan en todas partes.
Lo siguiente es un punto de partida práctico, no una lista universal exigida por la ley o por ISO:
| Área | Decisión de referencia | Verificación |
|---|---|---|
| Soporte del software | Sistemas operativos admitidos y versiones permitidas | Versión notificada contrastada con el estado de soporte |
| Actualizaciones | Ventanas de despliegue basadas en el riesgo y expectativas de reinicio | Versiones instaladas y registros de dispositivos con retraso |
| Cifrado | Protección exigida para el almacenamiento local aplicable | Estado efectivo del cifrado y mecanismos de recuperación |
| Bloqueo de pantalla | Tiempo de inactividad y autenticación al volver | Perfil efectivo más comportamiento verificado por muestreo |
| Protección de endpoints | Protección exigida cuando sea adecuada para la plataforma | Servicio activo, telemetría actual y alertas sin resolver |
| Instalación de software | Aplicaciones aprobadas y privilegios de instalación | Inventario de aplicaciones y comprobación de permisos |
| Acceso al negocio | Condiciones de acceso a las aplicaciones sensibles | Pruebas de las vías de acceso permitidas y denegadas |
| Salud de la gestión | Antigüedad aceptable del último contacto y salud del agente | Última evaluación correcta y registros de fallos |
Defina qué significa «desconocido». Un endpoint que no ha notificado su estado de cifrado no está demostrado como cifrado. Trate la telemetría ausente u obsoleta como un estado independiente con una respuesta clara, en lugar de convertirla en un aprobado.
Las ventanas de actualización deben reflejar la gravedad de la vulnerabilidad, la exposición, las mitigaciones disponibles y las limitaciones operativas. Documente el tratamiento de urgencia de las vulnerabilidades explotadas activamente y un proceso para las actualizaciones que rompen aplicaciones esenciales. Los informes de despliegue del MDM ayudan a determinar el estado de instalación; no explican por sí solos si el riesgo de vulnerabilidad sin resolver es aceptable.
En el caso de las aplicaciones, distinga la distribución del control. Instalar una aplicación aprobada no impide que los usuarios instalen alternativas, salvo que la plataforma y la configuración admitan esa restricción. Defina quién puede aprobar software, qué requiere evaluación y cómo se eliminan las aplicaciones obsoletas o prohibidas.
Toda excepción a la configuración de referencia necesita un responsable, los dispositivos afectados, el motivo de negocio, una evaluación de riesgos, medidas compensatorias, una aprobación y una fecha de caducidad. Un sistema operativo sin soporte con acceso sin restricciones a datos sensibles no debe permanecer indefinidamente bajo una nota genérica de «requisito de negocio».
Utilice un grupo piloto que represente cada plataforma, modo de titularidad y caso de uso de negocio importante. Pruebe el trabajo normal, los viajes, el funcionamiento sin conexión y la recuperación, no solo una inscripción correcta en la mesa de un administrador.
Antes del despliegue general, establezca los requisitos previos de la gestión: funciones de administrador, permisos de inscripción, certificados o credenciales de servicio necesarios y responsables de su renovación. Un servicio de gestión puede perder eficacia cuando caduca un certificado, aunque sus documentos de política no hayan cambiado.
Haga el seguimiento de la configuración a través de estados diferenciados: asignada, entregada, aplicada, evaluada y efectiva. Cuando la plataforma muestre menos fases, documente esa limitación y añada un método de verificación seguro. Inspeccione los perfiles en conflicto, los agentes obsoletos, los ajustes no admitidos y las acciones de los usuarios que impiden completar el proceso.
Utilice un despliegue escalonado con una vía de reversión o recuperación aprobada. Registre la versión de la configuración de referencia, los grupos destinatarios, los resultados del piloto, la aprobación y los fallos del despliegue. Una captura de pantalla de un editor de políticas demuestra los ajustes previstos; los informes de los dispositivos y las pruebas determinan si esos ajustes funcionaron.
Proteja también el propio plano de gestión. Utilice cuentas de administrador nominativas, una autenticación robusta adecuada, funciones con privilegios mínimos y registro de actividad. Limite los privilegios de borrado masivo y de modificación de la configuración. Revise los administradores y las credenciales de servicio, porque comprometer el servicio de gestión puede afectar a muchos endpoints a la vez.
En los portátiles, compruebe la protección del almacenamiento implementada, no solo una política de «activar el cifrado». En los teléfonos y tabletas, entienda el modelo de cifrado del sistema operativo, el comportamiento según el estado de bloqueo y la visibilidad que ofrece la gestión. El cifrado en reposo y el transporte cifrado por la red son afirmaciones distintas.
Decida qué almacenamiento local está cubierto, si se permiten soportes extraíbles y cómo puede salir la información de negocio de las aplicaciones gestionadas. Un disco del sistema protegido no protege automáticamente un archivo exportado a una unidad externa sin cifrar.
Los mecanismos de recuperación necesitan su propio diseño de control. Determine dónde se guarda el material de recuperación, quién puede obtenerlo, cómo se autoriza y registra su obtención y cuándo es necesario rotarlo o sustituirlo. No incluya secretos de recuperación en las evidencias generales de auditoría ni en los tickets del servicio de asistencia.
Pruebe la recuperación en un endpoint de prueba designado siguiendo un procedimiento aprobado. Conserve la autorización y el resultado, no el secreto. Un campo de la consola que muestra que existe una clave no demuestra que el personal autorizado pueda recuperar el dispositivo cuando lo necesite.
La protección de la red depende también de la configuración de las aplicaciones y los servicios. El MDM puede distribuir certificados o ajustes de red, pero no puede demostrar que todas las aplicaciones utilicen conexiones cifradas configuradas adecuadamente. Para el ciclo de vida completo, consulte cifrado y gestión de claves.
Una señal de conformidad tiene un valor limitado si los endpoints no conformes conservan un acceso sin restricciones. Cuando sea posible, conecte la información de confianza o conformidad del dispositivo con los controles de acceso de identidades y aplicaciones. Determine con precisión qué recursos aplican la condición y qué vías de acceso la eluden.
Pruebe, cuando proceda, el acceso desde el navegador, las aplicaciones nativas, la administración remota, la autenticación heredada y las sesiones existentes. Un navegador no gestionado puede estar bloqueado mientras un cliente autorizado previamente sigue funcionando. El comportamiento de la revocación de sesiones y la actualidad de las señales requieren pruebas explícitas.
Utilice restricciones basadas en el riesgo. Los sistemas administrativos sensibles pueden exigir condiciones de endpoint más estrictas que los recursos de colaboración de bajo riesgo. Defina procedimientos de acceso de emergencia y de recuperación para que un fallo del servicio de conformidad no dé lugar a excepciones permanentes no documentadas.
La autenticación para desbloquear el dispositivo no es lo mismo que la autenticación en las aplicaciones. El bloqueo de pantalla protege un endpoint desatendido; la autenticación multifactor y la autorización protegen el acceso a los recursos. El MDM puede respaldar la configuración, pero las evidencias del proveedor de identidades y de las aplicaciones deben acreditar esas afirmaciones independientes.
Para los dispositivos de propiedad personal, decida si la gestión es del dispositivo completo, de un perfil de trabajo, solo de aplicaciones o inexistente. Explique qué pueden ver los administradores, qué pueden cambiar, qué información de negocio se recoge y qué puede eliminarse. No dé por supuesto que el seguimiento de la ubicación o la visibilidad de las aplicaciones personales sean necesarios o estén disponibles.
Cuando la telemetría de los dispositivos de los empleados implique datos personales, evalúe las obligaciones de privacidad aplicables. El RGPD exige una base jurídica y el respeto de los principios de tratamiento pertinentes; el artículo 32 adopta un enfoque de la seguridad basado en el riesgo en lugar de imponer el cifrado en todas las circunstancias. No debe suponerse que el consentimiento del empleado es suficiente. Obtenga una revisión adecuada desde el punto de vista de la privacidad y del derecho laboral para los procedimientos de supervisión y de borrado.
Separe la eliminación selectiva de los datos de negocio del borrado completo del dispositivo. Confirme el comportamiento admitido para cada modo de inscripción y comuníquelo antes de la inscripción. La eliminación de un perfil de trabajo puede dejar intactos los datos personales, mientras que un borrado completo tiene consecuencias sustancialmente distintas.
Ante un dispositivo perdido, la respuesta debe identificar el endpoint y el usuario, evaluar la exposición, restringir el acceso, revocar las sesiones o credenciales pertinentes, emitir los comandos de bloqueo o borrado admitidos y registrar los resultados. El borrado remoto depende de la conectividad y de las capacidades de la plataforma. «Comando en cola» no es «datos eliminados».
Los procedimientos de salida deben abordar tanto la devolución del dispositivo como el acceso a la información. Revoque el acceso con independencia de que se recupere o no el dispositivo. Elimine los perfiles de trabajo cuando proceda, conserve la información sujeta a requisitos de conservación y dé de baja los registros del inventario solo después de las comprobaciones necesarias. Pruebe estos procesos en un ámbito seguro con cuentas y dispositivos de prueba.
Un paquete de evidencias debe permitir a un revisor reconstruir qué estuvo protegido durante un periodo determinado. Conserve exportaciones fechadas, recuentos de la población, decisiones sobre excepciones y registros de corrección. Incluya contexto suficiente para distinguir una evaluación puntual de las evidencias de un funcionamiento continuo.
Algunos entregables útiles son:
Documente los filtros de exportación, el momento de la recogida y la interpretación de los campos de estado. Proteja adecuadamente las exportaciones, porque pueden contener identificadores personales o detalles sensibles de la infraestructura. Las capturas de pantalla pueden explicar la configuración, pero las exportaciones con búsqueda suelen ser más útiles para analizar la población.
Tome muestras atendiendo al riesgo y a los modos de fallo, no solo de dispositivos en buen estado. Incluya distintas plataformas, inscripciones recientes, usuarios privilegiados, endpoints obsoletos y excepciones aprobadas. Un informe actual no puede reconstruir un periodo de revisión anterior a menos que se hayan conservado los registros históricos.
Las revisiones periódicas de cobertura deben incluir los dispositivos recién incorporados y los cambios en los patrones de acceso. Algunos indicadores operativos útiles son la cobertura de inscripción, la conformidad evaluada con la configuración de referencia, los informes obsoletos, las excepciones caducadas y la antigüedad de las correcciones. Defina cada denominador y cada umbral. La supervisión continua de controles aporta más contexto para distinguir las señales de las conclusiones revisadas.
Las cifras y umbrales siguientes son supuestos ilustrativos, no referencias del sector.
Una empresa identifica 120 portátiles corporativos y 30 teléfonos personales autorizados para el correo electrónico de trabajo. Su configuración de referencia para portátiles exige inscripción, cifrado, un sistema operativo con soporte, bloqueo de pantalla y una evaluación correcta en los últimos siete días. Los teléfonos personales requieren un perfil de trabajo gestionado y software con soporte; la gestión del dispositivo completo queda fuera del límite de privacidad aprobado.
La consola del MDM contiene 116 portátiles. De ellos, 108 cumplen la configuración de referencia, cuatro notifican actualizaciones con retraso, dos tienen evaluaciones obsoletas y dos muestran fallos de cifrado. Los cuatro portátiles restantes no están gestionados.
Informar solo del resultado de la consola da 108 de 116, aproximadamente un 93 % de conformidad con la configuración de referencia. Respecto a la población de portátiles establecida, se ha demostrado que 108 de 120, un 90 %, cumplen la configuración de referencia. La cobertura de inscripción es de aproximadamente el 97 %. Son indicadores distintos y ninguno demuestra los controles de los teléfonos personales.
Los registros de identidades muestran que dos portátiles no gestionados accedieron a una aplicación sensible. El equipo restringe ese acceso, investiga la titularidad e inscribe los dispositivos. Se confirma que los otros dos están dados de baja; las evidencias de revocación y eliminación respaldan su exclusión de la población activa.
En cuanto a los teléfonos, tres usuarios tienen acceso al correo electrónico sin el perfil de trabajo exigido. Su acceso se restringe hasta que completen la inscripción o una alternativa aprobada. Un teléfono de prueba confirma que la eliminación selectiva borra el perfil de trabajo sin eliminar el contenido personal.
El registro de la revisión conserva la población original, los cambios de la conciliación, los fallos, las restricciones de acceso y las correcciones verificadas. No sustituye la evaluación inicial fallida por una captura de pantalla posterior impecable.
Los errores habituales son operativos: contar solo los endpoints inscritos, confiar en la asignación de políticas, aceptar telemetría obsoleta, dejar excepciones abiertas y tratar los comandos remotos como acciones completadas. Todos pueden abordarse mediante una población definida, un tratamiento explícito de los estados y una verificación fechada.
Secani puede organizar este trabajo en torno a los sistemas, requisitos, responsables y evidencias pertinentes. Suba los documentos de la configuración de referencia, las exportaciones fechadas del MDM y los registros de pruebas; conéctelos con los controles o decisiones que respaldan; y convierta las evidencias que faltan o los fallos sin resolver en tareas asignadas. Preserve la revisión humana, la aprobación y el contexto de las fuentes para las conclusiones relevantes. El MDM sigue siendo la herramienta operativa de gestión de endpoints; el espacio de trabajo de cumplimiento preserva el contexto de la implementación y las decisiones de revisión.
Un siguiente paso práctico es seleccionar una aplicación sensible y conciliar cada endpoint que accede a ella con los registros de gestión. Pruebe un endpoint en buen estado, uno no gestionado y uno obsoleto. Registre los resultados de acceso y las evidencias de configuración y, a continuación, asigne cada discrepancia sin explicar a un responsable. Ese pequeño ejercicio pone a prueba a la vez la cobertura, la aplicación efectiva y las evidencias.
Secani conecta Scopes, evidencias, tareas y agentes de IA en un espacio de trabajo compartido.
Vincule los servicios críticos con los objetivos de recuperación, las dependencias, los ejercicios y las acciones correctivas para que los planes de continuidad reflejen la capacidad real.
Revise la identidad, la exposición, el cifrado, la recuperación y el registro en la nube con evidencias vinculadas a las cuentas, los servicios y los datos reales.
Combine comprobaciones técnicas periódicas y juicio experto periódico, con una cobertura clara, una recopilación en buen estado, umbrales definidos y responsables del seguimiento.