Usuarios, roles y permisos. La lógica invisible de una app
- Editorial
- 10 ago
- 5 min de lectura
Una aplicación no está completamente definida cuando sabemos qué funciones tendrá, sino cuando también entendemos quién puede utilizarlas, bajo qué condiciones y con qué nivel de autoridad.
Una app puede parecer terminada y seguir funcionalmente incompleta. Las pantallas existen, los botones responden y los formularios guardan información, pero nadie ha definido con precisión quién puede consultar, modificar, aprobar, cancelar o eliminar cada registro.
El problema suele aparecer durante el desarrollo. Entonces comienzan las preguntas: ¿todos los usuarios pueden ver la misma información?, ¿un supervisor puede editar lo que creó un colaborador?, ¿quién autoriza una solicitud?, ¿qué sucede cuando alguien cambia de puesto?
Cuando estas decisiones no forman parte de la documentación funcional, el equipo técnico termina interpretando la estructura de autoridad del negocio. Una suposición aparentemente pequeña puede convertirse en una vulnerabilidad, un conflicto operativo o una reconstrucción costosa del sistema.
Identidad, responsabilidad y capacidad de acción
Un usuario es la persona o actor que interactúa con la aplicación; su cuenta representa la identidad con la que accede. La autenticación confirma quién es. La autorización determina qué puede hacer.
El rol representa la responsabilidad que esa persona desempeña dentro del sistema. Los permisos especifican las acciones que puede realizar sobre determinados recursos. No son conceptos equivalentes ni deberían documentarse como si lo fueran.
El control de acceso basado en roles, conocido como RBAC, organiza los permisos alrededor de funciones y responsabilidades, en lugar de configurarlos individualmente para cada persona. Este modelo, documentado por el National Institute of Standards and Technology, facilita la asignación, administración y revisión de accesos.
“Una app no solo debe saber quién eres; también debe entender qué responsabilidad representas dentro del sistema.”
Puedes escuchar este artículo aquí:
Dentro de una plataforma interna pueden existir colaboradores, supervisores, administradores y auditores. El colaborador crea solicitudes; el supervisor las revisa; el administrador configura reglas y usuarios; el auditor consulta movimientos sin modificarlos. Una misma persona, además, podría desempeñar más de un rol según el proceso en el que participe.
La matriz que debe existir antes de la interfaz
La documentación funcional no debería limitarse a indicar que determinado perfil tiene acceso a un módulo. Entrar a una sección no significa tener autorización para realizar todas sus operaciones.
La matriz de permisos debe relacionar seis componentes: rol, recurso, acción, alcance, estado y condición. De esta manera puede establecerse quién consulta, crea, edita, asigna, aprueba, rechaza, cancela, elimina o exporta información, así como el contexto en el que puede hacerlo.
Un supervisor, por ejemplo, podría consultar todas las solicitudes de su equipo, pero editar únicamente las que todavía no han sido aprobadas. Un colaborador podría modificar sus propios registros mientras permanezcan en borrador, pero perder esa facultad después de enviarlos. Un auditor tendría acceso a la trazabilidad completa sin capacidad para alterar el expediente.
El estado de la información modifica los permisos. Una solicitud puede editarse durante su preparación, quedar bloqueada al enviarse y permitir cambios posteriores solo mediante una devolución autorizada. Por eso no basta con definir quién puede hacer algo; también debe precisarse sobre qué información, en qué momento y bajo qué condiciones.
Esta matriz permite detectar contradicciones antes de diseñar pantallas. Si alguien puede aprobar su propia solicitud, un auditor puede modificar lo que debe revisar o cualquier colaborador puede exportar información sensible, el problema no es visual: está en la lógica del producto.
Cada rol necesita una experiencia coherente
Los permisos transforman la experiencia de usuario. Dos personas pueden entrar al mismo módulo y encontrar diferentes acciones, filtros, indicadores y niveles de información.
Un colaborador necesita identificar qué debe hacer. Un supervisor requiere detectar pendientes, retrasos y excepciones. Un administrador necesita configurar usuarios y reglas. Un auditor busca fechas, responsables y movimientos. Mostrar la misma interfaz a todos puede parecer más sencillo, pero suele producir pantallas saturadas y recorridos confusos.
La decisión de ocultar o desactivar una acción también debe responder a una regla. Si una función está temporalmente bloqueada porque falta completar un dato o porque el registro se encuentra en determinado estado, puede mostrarse desactivada junto con una explicación. Si el usuario nunca tendrá autorización para utilizarla, exhibirla sin contexto solo genera frustración y expone capacidades innecesarias.
Diseñar por roles no significa crear una aplicación distinta para cada persona. Significa construir una estructura común que priorice las tareas, decisiones e información relevantes para cada responsabilidad.
Puedes ver este artículo aquí:
Ocultar un botón no protege una operación
Quitar un botón de la pantalla evita que el usuario lo vea, pero no garantiza que la acción esté protegida. Los permisos no pueden existir únicamente en la interfaz.
La autorización debe validarse en el servidor cada vez que alguien intenta consultar, crear, modificar, aprobar, eliminar o exportar un recurso protegido. La interfaz comunica las posibilidades del usuario; el sistema confirma si realmente tiene autorización para ejecutarlas.
OWASP recomienda aplicar el principio de menor privilegio —otorgar únicamente los accesos indispensables— y negar por defecto cualquier operación que no haya sido autorizada expresamente. Esta lógica reduce la exposición de datos y evita que una persona actúe fuera de las responsabilidades asignadas.
“Cuando los permisos se improvisan en desarrollo, la organización convierte sus reglas internas en excepciones técnicas.”
Documentar para que el sistema pueda evolucionar
Una documentación completa debe incluir tipos de usuario, descripción de roles, matriz de permisos, alcance de los datos, estados del proceso, reglas de aprobación, excepciones y procedimientos para asignar, modificar o retirar accesos.
También debe evitar dos extremos: crear un rol diferente para cada persona o concentrar facultades innecesarias en un perfil con acceso absoluto. El primer escenario vuelve inmanejable el sistema; el segundo aumenta el riesgo operativo.
Los roles deben representar responsabilidades estables, no nombres propios ni posiciones momentáneas. Así, cuando alguien cambia de área o una nueva persona se incorpora, la aplicación puede reasignar sus accesos sin reconstruir la lógica del producto.
Definir usuarios, roles y permisos no es una tarea secundaria de programación. Es la manera de convertir la estructura real del negocio en reglas comprensibles, verificables y listas para diseñarse.
Si tu idea necesita más claridad antes de convertirse en código, en Sr. Zorro App Design Studio te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
¿Tu aplicación ya define con precisión quién puede ver, crear, modificar, aprobar y eliminar cada elemento, o esa lógica sigue esperando a que desarrollo la descubra?
Escrito por: Editorial
Comentarios