BYOD bien hecho: una guía de campo para proteger teléfonos personales con Intune

Si diriges una empresa pequeña con Microsoft 365 y quieres el correo del trabajo en el teléfono de todo el mundo, te topas con una pregunta que parece sencilla y no lo es: ¿cómo proteges los datos de la empresa en un dispositivo que no es tuyo?

La respuesta es un stack de herramientas bien definidas con trade-offs claros. Usadas correctamente, te dan una protección sólida para los datos de la empresa y privacidad total para los datos personales en el mismo teléfono. Esta es una guía de los conceptos, los trade-offs, la configuración exacta que usamos — y los problemas con los que nos encontramos por el camino, porque hubo varios.

Por qué molestarse — los hechos

Unas cuantas razones sencillas por las que vale la pena hacerlo bien:

• Los teléfonos ya son personales. Una empresa pequeña no reparte hardware corporativo. La gente revisa el correo y Teams en el dispositivo que lleva en el bolsillo, así que ese dispositivo ya está dentro del alcance, lo gestiones o no.
• El acceso sin gestionar es una vía de datos real. Si no haces nada, el correo y los archivos de la empresa viven en apps sin requisito de cifrado, sin PIN, sin control sobre a dónde se copian los datos y sin forma de eliminarlos si un teléfono se pierde o una persona se va.
• Manejamos datos que importan. Operamos una plataforma con fondos de jugadores e información personal, así que sometemos nuestro propio acceso interno a un listón definido (controles al estilo CIS/SOC 2), no a un "lo mejor que se pueda".
• La privacidad es un requisito, no un extra. Hagamos lo que hagamos, no puede extender el alcance de TI a las apps personales, las fotos, los mensajes ni la ubicación de nadie.

El objetivo era específico: cada vía de acceso a los datos de la empresa en un teléfono debe cumplir un estándar de seguridad definido, sin gestionar el dispositivo personal que la rodea.

El problema, planteado con precisión

Dos requisitos aplican al mismo tiempo:

• Los datos de la empresa necesitan protección — cifrados, con acceso controlado y eliminables si un teléfono se pierde o la persona se va.
• Un teléfono personal pertenece a la persona — fotos, chats, apps y ubicación se mantienen privados y fuera del alcance de TI.

La gestión de dispositivos móviles es el conjunto de herramientas creado para satisfacer ambos a la vez. El resto de esta guía es la caja de herramientas y cómo encajan las piezas.

La caja de herramientas: tres formas de gestionar un teléfono

Microsoft Intune ofrece un espectro, no un interruptor:

1. MAM — Mobile Application Management gestiona la app. Proteges las apps de trabajo y dejas el resto del teléfono en paz. Sin inscripción.

2. MDM — Mobile Device Management gestiona el dispositivo, en dos variantes distintas:

• Perfil de trabajo / User Enrollment — un contenedor de trabajo separado y cifrado dentro de un teléfono personal. TI gestiona solo el contenedor.
• Totalmente administrado — TI gestiona el dispositivo entero. Apropiado para hardware propiedad de la empresa, no para teléfonos personales.

La mayoría de los equipos solo consideran la opción 1 y el extremo "totalmente administrado" de la opción 2, rechazan ambos y se conforman con algo laxo. La opción útil es la del medio.

Concepto 1: MAM / protección de aplicaciones

Las directivas de protección de aplicaciones (App Protection Policies) de Intune son la capa MAM. Una directiva aplicada a una app como Outlook:

• Cifra los datos de la empresa dentro de la app.
• Exige un PIN o biometría para abrirla.
• Bloquea copy, Save As y Open in desde datos de la empresa hacia apps personales.
• Permite un borrado selectivo solo de los datos de la empresa, dejando intactos los personales.

Nada de esto requiere inscribir el dispositivo. El teléfono sigue siendo del todo personal; solo se gestionan las apps de trabajo. Para muchos casos de BYOD esto es suficiente — y fue nuestro punto de partida.

Concepto 2: el cumplimiento implica inscripción

El concepto que lo une todo es el cumplimiento del dispositivo (device compliance).

Un dispositivo es "compatible" (compliant) cuando está inscrito en la administración y cumple las reglas de estado que tú defines — cifrado de disco activado, bloqueo de pantalla configurado, sistema operativo parcheado, sin root, etcétera. El cumplimiento es un estado que el dispositivo reporta y la administración verifica.

El punto clave: no puedes evaluar el cumplimiento de un dispositivo que nunca se inscribió. La premisa de MAM es que no hay inscripción, así que un teléfono solo con MAM está protegido a nivel de app pero nunca puede ser "compatible" — no hay nada inscrito que comprobar. Require compliant device y "sin inscripción" son mutuamente excluyentes por diseño.

Si quieres una garantía a nivel de dispositivo, el dispositivo tiene que estar inscrito en algo. Eso apunta a la opción del medio.

Concepto 3: el perfil de trabajo

En Android, la opción del medio es un perfil de trabajo (vía Android Enterprise). En iOS, el equivalente es User Enrollment. El modelo:

Un perfil de trabajo es un contenedor separado y cifrado dentro de un teléfono personal. TI gestiona solo lo que está dentro de ese contenedor. Todo lo que queda fuera — apps personales, fotos, mensajes, cuentas — está en un espacio que TI no puede ver, tocar ni borrar.

Las apps de trabajo aparecen como un conjunto con insignia junto a la pantalla de inicio personal, aisladas en el contenedor. El dispositivo pasa a estar inscrito y en cumplimiento, con el alcance limitado al contenedor de trabajo. Los datos personales siguen siendo privados. Aquí "inscripción" significa que la empresa gestiona un contenedor, no el dispositivo.

Concepto 4: acceso condicional

El acceso condicional (Conditional Access, CA) de Microsoft Entra es la puerta de entrada. Antes de conceder un inicio de sesión, comprueba las condiciones que tú definas. Aquí son relevantes dos concesiones (grants):

• Require app protection — se permite el acceso si la app tiene aplicada tu directiva MAM. Se empareja con MAM.
• Require compliant device — se permite el acceso si el dispositivo está inscrito y en buen estado. Se empareja con MDM / perfil de trabajo.

El acceso condicional es donde impones el modelo que estás usando. Cambia la concesión y cambias el listón del acceso.

El camino que tomamos

Con el modelo claro, la construcción es directa:

1. Empieza con MAM. Protección de aplicaciones en las apps de trabajo, más una regla de acceso condicional que exige protección de app. El toque más ligero.
2. Decide la garantía que necesitas. Si "la app está protegida" te basta, para aquí — es válido. Nosotros queríamos la garantía a nivel de dispositivo.
3. Habilita Android Enterprise vinculando Managed Google Play al tenant. Una conexión única que desbloquea la inscripción con perfil de trabajo.
4. Inscribe el teléfono como perfil de trabajo de propiedad personal. Se crea un espacio de trabajo cifrado y con insignia, el lado personal queda intacto, y el dispositivo reporta compliant en un par de minutos.
5. Entrega las apps de trabajo desde Managed Google Play — aprueba Outlook, Teams, Edge y las apps de Office, asígnalas, y se instalan en el contenedor.
6. Mueve la concesión de acceso condicional de Require app protection a Require compliant device — el mismo listón que se usa para los portátiles.

Esa es la versión limpia. Esto es lo que pasó en realidad.

Problemas que encontramos, y cómo los resolvimos

1. Todas las apps gestionadas bloqueadas con "el dispositivo no es compatible". Nuestra directiva de protección de aplicaciones MAM llevaba una regla de inicio condicional, appActionIfDeviceComplianceRequired, configurada en block. Cuando intentamos relajarla, Intune solo aceptaba block o wipe — la API rechaza null y warn. Combinado con el Concepto 2, es un bucle cerrado: la directiva exige un dispositivo compatible, un teléfono solo con MAM nunca está inscrito, así que nunca es compatible, así que todas las apps quedan bloqueadas y Company Portal insiste en inscribir. Se aplica del lado del cliente, así que nunca aparece como un fallo de inicio de sesión en Entra — un detalle que lo hace difícil de diagnosticar.

Solución: deja de pelearte con la puerta. Inscribe el dispositivo (perfil de trabajo) para que realmente pueda ser compatible, y luego abandona MAM en esa plataforma (problema 5).

2. Company Portal: "no cumple los requisitos para inscribirse". Antes de conectar Android Enterprise no existía ninguna vía de inscripción con perfil de trabajo, así que el intento de inscripción no tenía dónde aterrizar.

Solución: conecta Managed Google Play para vincular Android Enterprise. Esa única conexión es lo que hace posible la inscripción con perfil de trabajo.

3. El conflicto de la cuenta de Google — el paso que más tiempo nos costó. Managed Google Play se vincula usando una cuenta de Google que pasa a ser la propietaria de la empresa en la plataforma. Nuestro correo del negocio ya estaba ligado a una cuenta personal de Google, y Google lo trata como una cuenta en conflicto — no te deja usar la misma dirección para crear el administrador organizacional o de Workspace. Es fácil pasarlo por alto y lo atasca todo.

Solución: resuelve el conflicto primero. O liberas el correo mediante el proceso de cuentas en conflicto de Google (renombrar o cerrar la cuenta personal de Google existente en esa dirección) o usas una cuenta dedicada sin registro previo en Google. Reserva tiempo de verdad para esto — es lo que con más probabilidad bloqueará a un equipo pequeño el primer día, y no tiene nada que ver con Intune.

4. El perfil de trabajo estaba vacío tras la inscripción. Las apps del perfil de trabajo no se traspasan desde el lado personal. Un contenedor recién creado no tiene nada dentro.

Solución: aprueba las apps en Managed Google Play y asígnalas a tu grupo como Required (instalación automática) o Available (instalación a demanda desde la tienda del perfil de trabajo). Entonces aparecen como apps con insignia dentro del contenedor.

5. Seguía "no compatible" — incluso después de que el dispositivo ya lo fuera. El dispositivo ya reportaba compliant, pero Outlook seguía negándose. La causa: la directiva de protección de aplicaciones MAM seguía aplicada a la misma app que ahora estaba administrada por MDM en el perfil de trabajo, y su puerta de cumplimiento de dispositivo entraba en conflicto con la inscripción. MAM y MDM no quieren cogestionar la misma app.

Solución: comprométete con un solo modelo por plataforma. Desasignamos la directiva de protección de aplicaciones de Android y cambiamos la concesión de acceso condicional de Android de Require app protection a Require compliant device. El dispositivo con perfil de trabajo la satisface directamente; no queda ninguna puerta MAM que entre en conflicto.

6. Nuestra propia directiva bloqueó nuestras herramientas de administración — AADSTS530033. Al automatizar los cambios de Intune, se rechazó un inicio de sesión de administrador: el acceso condicional denegando un login por código de dispositivo porque ese token no está vinculado a un dispositivo compatible.

Solución: ejecuta el trabajo privilegiado desde un dispositivo ya compatible, de modo que el token quede vinculado al dispositivo — por ejemplo, Connect-MgGraph de forma interactiva desde una máquina administrada. La conclusión es positiva: si tu acceso condicional es capaz de frenar un login por código de dispositivo, está configurado correctamente.

Sobre construir con IA

Construimos en público, y construimos con IA, incluso en operaciones. La IA es eficaz recorriendo rápidamente las muchas ramas de una configuración. La emparejamos con una regla: la IA propone, un humano decide — especialmente en cualquier cosa que toque la seguridad. Esa división del trabajo permite a un equipo pequeño operar al ritmo de uno más grande.

Los modelos mentales que conviene conservar

1. MAM gestiona la app; MDM gestiona el dispositivo. Elige según la garantía que necesites.
2. El cumplimiento implica inscripción. No puedes verificar un dispositivo que nunca se inscribió, así que Require compliant device y "sin inscripción" no pueden coexistir.
3. El perfil de trabajo es la opción del medio. Gestiona un contenedor, no el dispositivo — cumplimiento del dispositivo y privacidad personal a la vez.
4. Un solo modelo por app. No dejes una directiva MAM en una app que ya has movido a MDM; elige un carril.
5. El acceso condicional marca el listón. Elige la concesión que corresponda a tu modelo y deja que ella lo imponga.

Ponemos este nivel de cuidado en unas cuantas bandejas de correo de trabajo porque la misma disciplina que asegura nuestro acceso móvil es la que protege tu cuenta, tus fondos y tus datos en la plataforma. La seguridad es un hábito que atraviesa todo el trabajo interno, no solo las partes que ven los clientes.

Nos vemos en las mesas.