Cuándo restringir dispositivos a un solo flujo de trabajo reduce el riesgo y cuándo crea otros nuevos

Los departamentos de TI y los MSP suelen desplegar dispositivos para tareas muy concretas, como estaciones de registro o terminales de punto de venta. Por su propia naturaleza, estos entornos deben supervisarse con cuidado, ya que un acceso sin restricciones puede convertirse fácilmente en una vulnerabilidad de la seguridad.

La restricción de dispositivos a un solo flujo de trabajo se usa habitualmente para reducir estos riesgos limitando lo que los usuarios pueden ver y hacer en el dispositivo. Aplicada de forma intencionada, mejora la fiabilidad y la seguridad. Sin embargo, si se implementa sin una planificación adecuada, las restricciones estrictas pueden introducir nuevos modos de fallo más difíciles de resolver que los problemas que pretendían evitar.

En este artículo te explicamos cómo identificar cuándo una restricción reduce el riesgo y cuándo genera riesgos nuevos.

Nota: aunque suele implementarse en dispositivos Android, ChromeOS o iOS, los principios de esta guía se aplican a cualquier plataforma.

Qué problemas resuelve la restricción a un solo flujo de trabajo

Restringir un dispositivo a un único flujo de trabajo busca aportar previsibilidad y un mayor control sobre una tarea concreta. Las organizaciones recurren a este enfoque para resolver un conjunto definido de problemas, como:

• Evitar usos o cambios de configuración no deseados: limitar el acceso reduce la posibilidad de que los usuarios modifiquen ajustes por accidente o instalen aplicaciones no aprobadas.
• Garantizar una ejecución coherente de las tareas: los dispositivos se comportan igual siempre, sin importar quién los utilice.
• Reducir la exposición a aplicaciones o contenidos ajenos: los usuarios no pueden navegar, explorar la configuración ni acceder a herramientas que no tengan relación con la tarea.
• Simplificar la experiencia de usuario: esto resulta especialmente importante en dispositivos compartidos, públicos o desatendidos, donde la formación es mínima.

La propiedad y la autoridad determinan la viabilidad

La eficacia de las restricciones estrictas depende menos de la tecnología y más de quién es el propietario del dispositivo y quién tiene autoridad para controlarlo. Los dispositivos que pertenecen claramente a un MSP son mucho más fáciles de restringir con éxito, porque no hay ambigüedad sobre quién decide cómo se usa o se configura el dispositivo.

Aun así, los equipos de TI deben prestar especial atención a implementar estrategias que les permitan recuperar, actualizar e intervenir cuando algo falla (te recomendamos leer nuestra guía sobre copia de seguridad y recuperación de datos para profundizar en este tema).

Tener una autoridad clara significa disponer de métodos fiables para desbloquear un dispositivo, cambiar configuraciones o restaurar el acceso durante un incidente. Si los equipos de soporte no cuentan con las herramientas o los permisos necesarios para actuar con rapidez, un dispositivo bloqueado puede quedar inservible en el peor momento posible.

Las restricciones también deben ser duraderas. Tienen que mantenerse tras los reinicios, las actualizaciones de software y los fallos inesperados sin necesidad de intervención manual. Cuando los controles se rompen después de una actualización o un reinicio, la restricción deja de ser una medida de seguridad y puede convertirse en una fuente de inconsistencia y riesgo. Es exactamente lo que ocurrió en esta historia de terror de TI, en la que la caída de un servidor dejó fuera de juego a un sistema de punto de venta.

Beneficios en la reducción de riesgos

Cuando el caso de uso es estable y la propiedad está clara, restringir el dispositivo a un solo flujo de trabajo puede reducir los riesgos de forma notable. Así es cómo:

• Menos interrupciones accidentales: si los usuarios no pueden acceder a la configuración del sistema ni a aplicaciones ajenas, hay muchas menos probabilidades de que algo se cambie o se rompa por error.
• Menor uso indebido: limitar un dispositivo a un único flujo de trabajo dificulta que los usuarios lo reutilicen para actividades no previstas, como navegar por internet o instalar aplicaciones.
• Menor exposición a acciones no aprobadas: eliminar el acceso a navegadores, menús del sistema y aplicaciones secundarias reduce el riesgo de que los usuarios accedan a contenidos que nunca debieron estar disponibles.
• Menos tickets de soporte por uso indebido: en entornos compartidos o públicos, muchas solicitudes de soporte se deben a errores del usuario y no a fallos técnicos.

Estos beneficios son más evidentes cuando los dispositivos están desatendidos o los comparten muchos usuarios distintos. En esos casos, la previsibilidad y el control suelen importar más que la flexibilidad.

Cuando la restricción se convierte en un lastre

Aunque restringir los dispositivos aporta múltiples ventajas, también hay situaciones en las que puede convertirse en un lastre. Algunos de esos escenarios son:

• Los flujos de trabajo cambian con frecuencia: cuando la tarea que soporta el dispositivo se actualiza a menudo, una restricción estricta implica reconfigurar constantemente. Con el tiempo, esto genera inestabilidad y frustra tanto a los usuarios como a los equipos de TI, que siempre van por detrás de los cambios.
• La resolución de problemas exige flexibilidad: los dispositivos bloqueados limitan lo que los equipos de soporte pueden ver o hacer durante un incidente. Si no se pueden realizar diagnósticos básicos ni soluciones temporales, resolver incluso un problema sencillo puede llevar mucho más tiempo de lo necesario.
• La propiedad no está clara o está repartida: cuando no se sabe quién tiene la última palabra sobre el dispositivo, las decisiones se bloquean durante las incidencias. Los equipos de soporte pueden dudar antes de anular las restricciones, mientras los equipos de negocio esperan que actúe TI, y el tiempo de inactividad se alarga.
• Los procesos de recuperación no están documentados: sin pasos claros para desbloquear, restaurar o reiniciar un dispositivo restringido, los fallos pequeños se agravan. Lo que podría haber sido una solución rápida se convierte en una interrupción prolongada porque nadie conoce la vía de recuperación aprobada.

Fallos de gobernanza habituales que conviene revisar

Seamos claros: la mayoría de los problemas (si no todos) que surgen con los dispositivos restringidos vienen de una mala planificación, no de la tecnología en sí. Por eso insistimos tanto en la importancia de contar con estrategias sólidas de gestión de copias de seguridad y de aplicar las mejores prácticas de seguridad en dispositivos móviles.

Un error habitual es restringir un dispositivo sin una forma clara de recuperarlo. Si el dispositivo está bloqueado y la aplicación principal se cierra de forma inesperada o no carga, los usuarios pueden quedarse completamente atascados. Sin un procedimiento documentado para desbloquearlo o restablecerlo, incluso un problema pequeño puede derivar en una interrupción larga.

Otro problema frecuente es la falta de claridad sobre la propiedad. Si no está claro quién tiene autoridad para tomar decisiones de emergencia, un imprevisto (o peor, un ataque de ransomware) puede desatar el pánico, porque nadie sabe exactamente a quién le corresponde actuar. Los equipos de negocio pueden esperar que TI tome la iniciativa, mientras TI duda porque el dispositivo o la política no «son suyos».

También surgen problemas cuando las organizaciones dan por hecho que el caso de uso no cambiará nunca. En la práctica, los flujos de trabajo evolucionan, las aplicaciones se sustituyen y los requisitos se mueven. Si las restricciones se construyen sobre la idea de que nada va a cambiar, cada actualización se vuelve un suplicio. Los equipos acaban rehaciendo configuraciones una y otra vez solo para mantener los dispositivos utilizables.

Por último, algunas organizaciones tratan la restricción como si fuera la solución en sí misma. Bloquear un dispositivo puede dar la sensación de que «ya hemos cubierto el riesgo», pero sin un plan para cuando algo falle esa confianza es engañosa. Las restricciones no evitan que las aplicaciones se bloqueen: solo limitan lo que los usuarios pueden hacer cuando eso ocurre.

Define una estrategia de bloqueo de dispositivos

Restringir los dispositivos a un solo flujo de trabajo puede reducir el riesgo, pero también puede aumentarlo si se hace sin una planificación adecuada. Es importante que apliques las restricciones con protocolos fiables, una propiedad bien definida y una buena preparación operativa.

Temas relacionados:

• Cómo estandarizar los flujos de trabajo de dispositivos compartidos para puestos flexibles, turnos y equipos de primera línea
• Mejora la eficiencia con la automatización de flujos de trabajo de TI
• Cómo estandarizar y reutilizar plantillas de aprobación para el acceso a dispositivos, los cambios de rol y la incorporación de proveedores