Cuando un software online suma usuarios, la pregunta deja de ser solo quién puede ingresar. También importa qué información puede consultar cada persona, qué acciones puede realizar y bajo qué condiciones. Resolverlo con permisos agregados caso por caso suele terminar en perfiles ambiguos, datos expuestos y dificultades para auditar cambios.
La alternativa es diseñar los accesos como parte del proceso de trabajo. El control de acceso basado en roles —RBAC— agrupa autorizaciones según funciones organizacionales, en lugar de asignarlas individualmente a cada usuario. NIST define RBAC justamente a partir de roles que reúnen autorizaciones necesarias para funciones definidas.
Un permiso útil no responde a quién lo pidió primero, sino a qué necesita una función para completar su trabajo con responsabilidad.
Primero: separá identidad, rol y permiso
Son conceptos relacionados, pero no equivalentes:
- Usuario: la persona, cuenta o integración que accede al sistema.
- Rol: una función de trabajo, como ventas, administración, supervisión o soporte.
- Permiso: una acción habilitada sobre un recurso, por ejemplo ver clientes, editar un pedido o exportar un reporte.
- Alcance: el límite de ese permiso: todos los registros, solo los propios, una sucursal o un equipo.
Por ejemplo, “supervisor comercial” no debería ser un permiso. Es un rol. Sus permisos podrían incluir consultar oportunidades del equipo, reasignarlas y aprobar descuentos dentro de un límite definido.
Relevá acciones reales, no pantallas
Antes de crear perfiles como “administrador”, describí las decisiones y tareas que el sistema debe soportar. Una pantalla puede contener acciones de distinto riesgo: consultar, crear, modificar, aprobar, descargar, eliminar o compartir.
- Listá los recursos sensibles: clientes, precios, facturas, archivos, usuarios, configuraciones y reportes.
- Anotá las acciones posibles sobre cada recurso.
- Definí el alcance de cada acción: propio, equipo, área, sucursal o toda la organización.
- Identificá acciones irreversibles o de alto impacto, como eliminar, aprobar pagos, cambiar datos bancarios o administrar usuarios.
- Asigná responsables de negocio para validar cada regla.
La matriz de permisos resultante puede ser simple: filas para roles, columnas para acciones y una aclaración del alcance. Es preferible una matriz comprensible a una lista extensa de permisos que nadie puede explicar.
Aplicá cuatro reglas de diseño que evitan excesos
1. Otorgá el mínimo necesario
El principio de mínimo privilegio indica que cada usuario debe recibir solo los accesos necesarios para cumplir su tarea. OWASP recomienda aplicarlo desde el diseño: es más sencillo sumar un permiso justificado que retirar uno demasiado amplio después. La guía de autorización de OWASP también recomienda evitar que el acceso se conceda por comodidad o por defecto.
2. Denegá lo no definido
Una función nueva, una API o un archivo no deberían quedar accesibles porque nadie creó una regla explícita. El criterio de “denegar por defecto” obliga a justificar cada acceso y reduce los vacíos que aparecen al ampliar el sistema.
3. Separá tareas incompatibles
Si una misma persona puede crear un pago, aprobarlo y cambiar la cuenta de destino, el problema no es solo técnico: falta un control operativo. Cuando una acción tiene impacto económico, legal o reputacional, conviene dividir preparación, aprobación y ejecución entre roles o exigir una confirmación adicional.
4. Revisá permisos sobre cada operación
Ocultar un botón no equivale a proteger una acción. La autorización debe verificarse en el servidor cada vez que el sistema intenta consultar, modificar, aprobar o eliminar un recurso. NIST explica que una transacción debe estar autorizada a través de los roles asignados al usuario; no alcanza con que la persona haya iniciado sesión. Las preguntas frecuentes de NIST sobre RBAC describen esta relación entre rol, transacción y autorización.
Cuándo un rol no alcanza por sí solo
RBAC funciona muy bien para responsabilidades estables. Sin embargo, algunas reglas dependen del contexto. Un asesor puede ver clientes, pero solo los asignados a su cartera; un responsable puede aprobar gastos, pero hasta cierto monto; un proveedor puede descargar un archivo, pero solo hasta una fecha determinada.
En esos casos, combiná el rol con condiciones: pertenencia a una cuenta, estado del registro, límite monetario, fecha, sede o relación con el caso. La clave es no convertir cada excepción en un nuevo rol. Si aparecen “ventas-norte”, “ventas-sur”, “ventas-norte-temporal” y decenas de variantes, probablemente el sistema necesita roles generales más reglas de alcance.
Probá y revisá el modelo antes de escalarlo
Convertí la matriz en casos de prueba. Para cada rol, comprobá tanto lo que debe poder hacer como lo que debe quedar bloqueado. Probá además cambios de URL, identificadores de registros, acciones desde integraciones y accesos a archivos o exportaciones.
- ¿Un usuario puede acceder a información de otro equipo cambiando un identificador?
- ¿Una persona sin aprobación puede ejecutar la acción por una ruta alternativa?
- ¿Un usuario dado de baja pierde el acceso de inmediato?
- ¿Queda registro de cambios de permisos, aprobaciones y acciones sensibles?
- ¿Hay una revisión periódica de cuentas con privilegios altos?
También definí un responsable para altas, cambios y bajas. Un modelo de permisos correcto se degrada si los movimientos de personal, proveedores o reemplazos no actualizan las cuentas.
Conclusión: diseñá accesos como una decisión operativa
Un buen esquema de permisos no busca controlar todo con complejidad. Busca que cada persona tenga la información y las acciones necesarias, que los cambios importantes puedan rastrearse y que el sistema no dependa de privilegios informales.
Empezá por una matriz de roles, acciones y alcances para el proceso más sensible de tu operación. Luego validala con quienes realizan el trabajo y con quienes responden por sus resultados. Si el sistema necesita traducir procesos, responsabilidades y aprobaciones particulares en reglas mantenibles, Ideasweb puede ayudarte a desarrollar un software y sistema a medida con esa lógica incorporada desde el inicio.
