Modulo 01. Arquitectura de Intune y conceptos MDM MAM

Objetivo del modulo

Comprender la arquitectura de Microsoft Intune, diferenciar Mobile Device Management de Mobile Application Management y saber cuando aplicar cada modelo segun el tipo de dispositivo, la propiedad y el riesgo.

Resultados esperados

• Explicar que hace MDM y en que se diferencia de MAM.
• Identificar los componentes de la arquitectura Intune y su relacion con Entra ID, Defender y acceso condicional.
• Elegir el modelo de gestion adecuado segun propiedad del dispositivo y perfil de usuario.

Desarrollo teorico

Microsoft Intune es el servicio cloud de Microsoft para la gestion moderna de endpoints. Su proposito es controlar dispositivos, aplicaciones y datos corporativos sin depender de infraestructura de directorio local ni de imagenes monoliticas. Intune forma parte del conjunto Microsoft Intune Suite dentro de Microsoft 365, y se apoya en Entra ID para identidad, en Microsoft Defender for Endpoint para senales de seguridad y en acceso condicional para decisiones de acceso basadas en contexto.

La arquitectura de Intune puede entenderse en cuatro capas. La primera es la identidad: todo dispositivo gestionado se asocia a una cuenta de Entra ID, ya sea mediante Entra Join, Hybrid Entra Join o registro simple. La segunda es la inscripcion o enrollment: el proceso mediante el cual el dispositivo queda bajo gestion, ya sea de forma automatica por Autopilot, mediante inscripcion manual del usuario o por enrollment corporativo masivo. La tercera es la configuracion: perfiles de dispositivo, politicas de cumplimiento (compliance), lineas base de seguridad y configuraciones de aplicaciones. La cuarta es la operacion continua: acciones remotas, reporting, integracion con el service desk y mantenimiento del estado deseado.

MDM, Mobile Device Management, gestiona el dispositivo completo. Cuando un equipo esta inscrito en MDM, Intune puede aplicar perfiles de configuracion de Wi-Fi, VPN, certificados, correo, cifrado, firewall, actualizaciones y restricciones del sistema operativo. Tambien puede ejecutar acciones remotas como wipe, retire, reinicio, sincronizacion forzada o localizacion. MDM es el modelo natural para dispositivos propiedad de la empresa, portatiles Windows, tabletas iPad corporativas o moviles Android Enterprise. El nivel de control es alto porque la organizacion es duena del hardware y tiene legitimidad para gobernar la experiencia completa del endpoint.

MAM, Mobile Application Management, protege aplicaciones y datos corporativos sin necesidad de gestionar el dispositivo completo. Esto es fundamental para escenarios BYOD, donde el empleado usa su propio telefono o tableta y no quiere ni debe ceder el control total a la empresa. Las politicas de proteccion de aplicaciones, conocidas como APP o App Protection Policies, pueden exigir PIN de aplicacion, cifrado de datos corporativos dentro de la app, impedir copiar y pegar entre apps gestionadas y no gestionadas, bloquear capturas de pantalla, forzar version minima de la app o del sistema operativo y borrar selectivamente datos corporativos sin tocar fotos, mensajes o apps personales del usuario.

La decision entre MDM y MAM no es binaria. En muchas organizaciones coexisten ambos modelos. Un empleado de oficina con portatil Windows corporativo estara inscrito en MDM completo. Un comercial que usa su propio iPhone para consultar correo y Teams puede estar solo bajo MAM. Un trabajador de primera linea con una tableta compartida puede requerir MDM con modo dispositivo compartido (shared device mode). Un colaborador externo puede acceder solo via navegador con acceso condicional y sin gestion de dispositivo. Estos escenarios deben mapearse antes de configurar politicas, porque una politica mal ajustada al escenario produce bloqueos innecesarios o controles insuficientes.

La relacion con Entra ID es critica. El estado de inscripcion del dispositivo alimenta las politicas de acceso condicional. Una politica tipica puede decir: si el dispositivo no esta inscrito y no cumple la politica de compliance, bloquear el acceso a Exchange Online y SharePoint. De este modo, Intune no trabaja solo como consola de configuracion, sino como fuente de senales de confianza para el control de acceso. Defender for Endpoint complementa con senales de riesgo del dispositivo: si Defender detecta una amenaza activa, la puntuacion de riesgo del equipo sube y acceso condicional puede restringir el acceso hasta que se remedie.

El modelo de co-management permite una transicion gradual desde Configuration Manager (SCCM) a Intune. En co-management, algunas cargas de trabajo las gestiona SCCM y otras Intune. Por ejemplo, el compliance puede evaluarse en Intune mientras que el despliegue de aplicaciones Win32 sigue en SCCM. Este modelo es habitual en empresas con gran parque legacy que no pueden migrar de golpe. El objetivo final suele ser cloud-native management, donde todo pasa por Intune y Autopilot, pero la transicion requiere planificacion y validacion por cargas de trabajo.

Las politicas de cumplimiento o compliance definen el estado minimo aceptable del dispositivo: cifrado activo, firewall habilitado, version minima de sistema operativo, antivirus actualizado, sin jailbreak o root, y nivel de riesgo de Defender aceptable. Si el dispositivo no cumple, se marca como no conforme y acceso condicional puede actuar en consecuencia. Las politicas de configuracion, en cambio, definen el estado deseado: configuraciones de Wi-Fi, certificados, restricciones de funcionalidad, experiencia de pantalla de bloqueo y parametros de actualizaciones.

Un error frecuente es confundir compliance con configuracion. Compliance evalua si el dispositivo cumple un umbral minimo. Configuracion aplica ajustes de forma activa. Un equipo puede estar configurado correctamente pero no cumplir compliance porque el usuario deshabilito algo manualmente. Un equipo puede cumplir compliance pero tener configuracion suboptima que afecta experiencia. Ambas capas deben operar juntas pero se gestionan con perfiles distintos.

La operacion de Intune requiere ownership claro. Alguien debe decidir que perfiles se aplican, como se segmentan usuarios y dispositivos, como se gestionan excepciones y como se comunica al usuario el impacto. Un despliegue de Intune sin soporte preparado genera tickets que nadie sabe resolver, bloqueos sin explicacion y desconfianza del usuario. El service desk necesita runbooks para problemas tipicos: dispositivo no conforme, inscripcion fallida, app que no se instala, acceso denegado por acceso condicional o BitLocker recovery solicitado.

Contenido ampliado

Puntos clave

• MDM gestiona el dispositivo completo; MAM protege apps y datos sin gestionar el hardware.
• La eleccion entre MDM y MAM depende de la propiedad del dispositivo y del nivel de control necesario.
• Intune no trabaja solo: depende de Entra ID, acceso condicional y Defender para formar un sistema coherente.
• Compliance y configuracion son capas distintas que deben operar juntas.
• Co-management permite transicion gradual desde SCCM.

Checklist operativa

• Mapear escenarios de dispositivo: corporativo, BYOD, shared device, externo.
• Definir modelo de gestion por escenario: MDM, MAM o solo acceso condicional.
• Crear politicas de compliance con umbrales claros y accion ante incumplimiento.
• Preparar runbooks de soporte para inscripcion, compliance fallido y acceso denegado.
• Documentar excepciones con owner, justificacion y fecha de revision.

Errores frecuentes

• Aplicar MDM a dispositivos BYOD sin consentimiento ni comunicacion clara.
• Confundir compliance con configuracion y no entender por que un equipo esta bloqueado.
• Desplegar Intune sin preparar al service desk para los nuevos tipos de incidencia.
• No segmentar politicas por tipo de dispositivo o grupo de usuarios.
• Tratar Intune como consola aislada en lugar de integrarlo con Entra ID y Defender.

Practica sugerida

Diseña una matriz de escenarios de dispositivo para una empresa de 800 empleados con portatiles corporativos, 200 usuarios BYOD en movil, 50 tabletas de primera linea y 30 colaboradores externos. Para cada escenario indica modelo de gestion, politicas de compliance minimas, politicas MAM necesarias y flujo de soporte cuando el usuario queda bloqueado.

Preguntas de autoevaluacion

• Que diferencia practica existe entre una politica de compliance y un perfil de configuracion y por que un dispositivo puede cumplir una pero no la otra.
• En que escenario elegirias MAM sin inscripcion MDM y que riesgos residuales aceptas.
• Como afecta el estado de compliance del dispositivo a las decisiones de acceso condicional.

Cierre

Intune aporta valor real cuando se entiende como un sistema integrado de identidad, gestion y seguridad del endpoint, no como una consola de configuracion mas. La decision entre MDM y MAM define la experiencia del usuario y el nivel de proteccion de datos, y esa decision debe tomarse por escenario, no de forma uniforme.

Modulo 02. Inscripcion de dispositivos y tipos de propiedad

Objetivo del modulo

Inscribir un dispositivo significa registrarlo y gestionarlo en Intune segun su plataforma y propiedad: corporativo, personal o compartido.

Resultados esperados

• Tipos de propiedad bien entendido
• Metodos de enrolment aplicado con criterio
• Necesidad de ownership y soporte

Desarrollo teorico

La inscripcion de dispositivos en Microsoft Intune es el proceso mediante el cual un endpoint queda bajo gestion corporativa, recibiendo identidad, politicas, aplicaciones y controles de seguridad. La inscripcion no es un tramite tecnico aislado: es la puerta de entrada al modelo de gestion moderna y determina que nivel de control puede ejercer la organizacion, que experiencia vivira el usuario y que riesgos quedan cubiertos o expuestos. La decision de como inscribir cada dispositivo depende de tres variables fundamentales: la plataforma del sistema operativo, el tipo de propiedad y el escenario de uso.

Tipos de propiedad

La propiedad del dispositivo condiciona todo el modelo de gestion. Un dispositivo corporativo permite control total: MDM completo, politicas de configuracion extensas, restricciones de sistema operativo, cifrado obligatorio, wipe remoto sin restricciones y despliegue automatizado de aplicaciones. La organizacion es duena del hardware y puede imponer cualquier control justificado por su politica de seguridad. Un dispositivo personal, en cambio, pertenece al empleado. Aplicar MDM completo sobre un movil personal genera rechazo y puede vulnerar privacidad. En estos casos el modelo natural es MAM sin inscripcion de dispositivo, donde Intune protege aplicaciones corporativas como Outlook, Teams o OneDrive sin tocar fotos, mensajes ni apps personales. La tercera categoria es el dispositivo compartido, habitual en primera linea, fabricas, hospitales o tiendas. Aqui el equipo no esta asociado a una persona sino a un rol o una ubicacion. El shared device mode de Entra ID permite que varios usuarios inicien y cierren sesion limpiamente, con datos de sesion eliminados al cerrar. La eleccion incorrecta del modelo de propiedad genera bloqueos innecesarios, desconfianza del usuario o controles insuficientes.

Metodos de enrolment

Cada plataforma tiene metodos de inscripcion distintos. En Windows, el metodo recomendado para dispositivos corporativos es Autopilot con Entra Join, que automatiza el alta desde el primer encendido. Para equipos existentes se puede usar la inscripcion manual desde Configuracion o mediante GPO en escenarios hybrid join. En iOS y iPadOS, Apple Business Manager con Automated Device Enrollment permite que los dispositivos comprados por la empresa se inscriban automaticamente. Para dispositivos personales, el usuario descarga Company Portal y se inscribe voluntariamente aceptando el nivel de control ofrecido. En Android, Android Enterprise ofrece perfiles de trabajo que separan datos corporativos y personales en el mismo dispositivo. El perfil totalmente gestionado aplica MDM completo para equipos corporativos, mientras que el perfil de trabajo personal protege apps corporativas sin invadir el espacio personal. Cada metodo tiene implicaciones distintas en experiencia, velocidad de despliegue y capacidad de gobierno.

Join y registration

El estado de identidad del dispositivo en Entra ID determina que politicas pueden aplicarse y que nivel de confianza se otorga en acceso condicional. Entra Join significa que el dispositivo es cloud-native y su identidad reside exclusivamente en Entra ID; es el estado recomendado para nuevos despliegues sin dependencia de Active Directory. Hybrid Entra Join implica que el equipo esta unido tanto a AD local como a Entra ID, lo cual es necesario cuando existen recursos on-prem que requieren autenticacion Kerberos o NTLM. Entra Registration es el estado mas ligero: el dispositivo se registra pero no se une; se usa habitualmente en escenarios BYOD donde el usuario quiere acceder a recursos corporativos desde su equipo personal sin entregarlo a gestion completa. La confusion entre estos estados es una de las causas mas frecuentes de tickets de soporte, porque determina que perfiles se aplican, que politicas de acceso condicional se evaluan y que acciones remotas estan disponibles.

Experiencia del usuario

El proceso de inscripcion es la primera impresion que el empleado recibe del servicio de puesto de trabajo digital. Si la inscripcion es larga, confusa o bloquea el uso del equipo durante horas, la percepcion sera negativa independientemente de lo bien configurado que este el entorno. La comunicacion previa es esencial: el usuario debe saber que pasara con su dispositivo, que datos puede ver la empresa, que aplicaciones se instalaran y cuanto tiempo tomara el proceso. En dispositivos corporativos, Autopilot con Enrollment Status Page bien optimizada puede dejar el equipo productivo en menos de 30 minutos. En dispositivos personales, el proceso de Company Portal debe ser sencillo y transparente, explicando claramente que la empresa podra ver estado de compliance pero no leer correos personales ni acceder a fotos. Una mala experiencia de inscripcion genera tickets de soporte, resistencia a la adopcion y shadow IT.

Comparativa operativa

La comparativa anterior sirve para seleccionar la capacidad adecuada segun el contexto de negocio, el modelo de permisos y el riesgo aceptable. Elegir el modelo equivocado provoca resistencia del usuario, tickets repetitivos o brechas de seguridad que podrian haberse evitado con una clasificacion previa de escenarios.

Procedimiento paso a paso

Paso 1: clasificar cada perfil de usuario y su tipo de dispositivo, separando corporativo, personal y compartido. Paso 2: seleccionar el metodo de inscripcion adecuado segun plataforma y propiedad, validando prerequisitos de identidad y licencias. Paso 3: configurar perfiles de inscripcion, restricciones de plataforma y politicas de compliance minimas. Paso 4: comunicar al usuario que ocurrira durante la inscripcion, que datos seran visibles y cuanto durara el proceso. Paso 5: monitorizar tasas de inscripcion exitosa, errores frecuentes y tickets generados para iterar el modelo.

Escenario aplicado

Una empresa de 500 empleados entrega portatiles Windows corporativos a oficina, permite BYOD en movil para comerciales y tiene 40 tabletas compartidas en planta de produccion. Sin clasificar escenarios, el equipo de workplace aplica MDM completo a todos, incluyendo los moviles personales. Los comerciales se quejan de que la empresa puede borrar su telefono, varios desinstalan Company Portal y empiezan a usar cuentas personales de correo para trabajo. El problema no es de Intune sino de modelo: los portatiles debian estar en MDM con Autopilot, los moviles personales en MAM sin inscripcion de dispositivo y las tabletas compartidas en shared device mode con perfil restrictivo.

Controles y gobierno

La gobernanza de la inscripcion necesita ownership claro, criterios de clasificacion documentados, runbooks de soporte para inscripciones fallidas y revision periodica de dispositivos inscritos que ya no estan activos o que no cumplen compliance. Las excepciones deben gestionarse con aprobacion, plazo y revision. Una implementacion madura combina configuracion tecnica, politicas, ownership, monitorizacion y formacion del usuario. Sin revision periodica, el inventario de dispositivos inscritos se degrada y las politicas se aplican sobre un universo que ya no refleja la realidad.

Contenido ampliado

Puntos clave

• Tipos de propiedad bien entendido
• Metodos de enrolment aplicado con criterio
• Necesidad de ownership y soporte
• Relación entre control y experiencia

Checklist operativa

• Definir ownership.
• Asignar politicas con criterio.
• Validar resultados.
• Medir y revisar.

Errores frecuentes

• Tratar Intune como consola aislada.
• No explicar impacto al usuario.
• No medir cumplimiento o fallos.

Practica sugerida

Documenta como operarias este bloque en un tenant corporativo con usuarios, soporte y excepciones.

Preguntas de autoevaluacion

• Que cambiaría segun tipo de dispositivo.
• Que evidencia necesitas para diagnosticar.
• Que riesgo creas si aplicas control sin soporte.

Cierre

Intune aporta valor cuando combina control tecnico con operacion sostenible.