Roles y permisos en software: qué definir antes de contratar
Cómo definir roles y permisos en software antes de contratar: accesos por tarea, límites por cliente y pruebas para comprobar lo que debe bloquearse.
Definir roles y permisos en software no consiste en poner un login y decidir quién ve el menú de administración. Si vas a contratar un sistema para tu empresa, necesitas acordar quién puede hacer cada operación y sobre qué información. Descubrirlo después de desarrollar suele obligar a cambiar bastante más que un botón.
Imagina una plataforma de servicios donde cada cliente tiene su cuenta y sus documentos. Un ejecutivo necesita atender a sus clientes, pero no debería descargar los contratos de toda la empresa. Darle acceso de administrador para que pueda trabajar resuelve el problema de hoy y deja otro esperando.
El puesto no explica todos los permisos
"Administrador, supervisor y usuario" parece suficiente hasta que alguien pregunta si un supervisor puede cambiar precios o únicamente consultarlos. Dos personas con el mismo puesto también pueden trabajar con sucursales o clientes distintos.
Empieza por describir tareas concretas. Consultar un expediente, editarlo, exportarlo y eliminarlo son acciones diferentes. Después define el alcance de cada una. Poder consultar los documentos de tus clientes no implica poder consultar los de cualquier cliente.
Una matriz de permisos sirve para poner esos acuerdos por escrito. Cada cruce relaciona un perfil con una acción y el conjunto de registros al que puede acceder. No necesita ser elegante. Necesita que operación y desarrollo puedan leerla sin inventar reglas distintas.
Un ejemplo vale más que "acceso limitado"
En esa plataforma hipotética, el ejecutivo consulta y actualiza los expedientes que tiene asignados. El supervisor revisa los de su equipo y puede reasignarlos. Finanzas consulta los datos necesarios para cobrar, sin recibir automáticamente acceso a todos los documentos del cliente.
Todavía faltan decisiones. ¿Puede el ejecutivo descargar archivos? ¿Qué pasa cuando un cliente cambia de responsable? ¿Quién ve el historial anterior? ¿Una cuenta suspendida conserva acceso mediante una sesión que ya estaba abierta?
No hace falta resolver cada posibilidad imaginable antes de empezar. Sí conviene resolver las que afectan la operación inicial y registrar qué queda fuera. Esto complementa la definición del alcance del proyecto, pero baja al detalle que la palabra "usuarios" suele esconder.
Ocultar una pantalla no protege la información
El menú ayuda a que cada persona vea las funciones que necesita. La autorización decide si el sistema acepta una solicitud. Son trabajos distintos.
Aunque una opción no aparezca en pantalla, alguien podría intentar abrir su dirección directamente o repetir una solicitud con otro identificador. El servidor debe comprobar si esa cuenta tiene permiso para la acción y para el registro solicitado. También cuando la operación llega desde una integración, no solamente desde la página principal.
La guía de autorización de OWASP recomienda aplicar el mínimo privilegio, denegar por defecto y validar permisos en cada solicitud. En lenguaje de negocio, cada persona recibe lo necesario para trabajar, y lo que no está autorizado no se permite por accidente.
Eso no significa comprar la arquitectura más complicada. Un sistema pequeño puede empezar con perfiles fijos bien definidos. Los permisos configurables por cada cliente tienen otro costo y necesitan justificarse.
Las excepciones también se cotizan
"Solo esta persona puede aprobarlo cuando el gerente no está" puede implicar una delegación temporal, una fecha de vencimiento y un registro de quién autorizó el cambio. No es necesariamente una casilla adicional.
Al definir roles y permisos en software, pregunta quién podrá asignarlos y modificarlos después. Una pantalla donde cualquier administrador puede darse más acceso cambia el riesgo. También cambia el alcance si necesitas aprobaciones separadas o restricciones por monto.
Pide que la propuesta distinga los perfiles incluidos de las reglas configurables. Aclara qué movimientos dejarán historial, qué información guardará ese registro y quién podrá consultarlo. Tener una bitácora ayuda a investigar; no sustituye impedir una operación no autorizada.
Prueba también lo que debe fallar
La demostración debe incluir cuentas con permisos distintos. Si todo se prueba con el administrador, puedes aprobar una entrega que nunca funcionó para el equipo real.
En el ejemplo, un ejecutivo debe abrir el expediente de un cliente asignado. También debe intentar consultar otro que no le corresponde, usando datos de prueba. El primer caso debería funcionar y el segundo debería rechazarse sin revelar información ajena. Después cambien la asignación y comprueben que el acceso siga la regla acordada.
Estas comprobaciones complementan las pruebas del flujo de negocio. No son una auditoría de seguridad completa. Pide evidencia de las restricciones importantes y de la baja de usuarios antes de dar por terminado el módulo.
Lleva reglas a la cotización, no solamente nombres de puestos
Antes de contratar, elige una operación sensible y explica quién puede realizarla, sobre qué datos y bajo qué condiciones. Ese ejercicio permite conversar sobre roles y permisos en software con menos supuestos y una estimación más honesta.
En DevAces preferimos revisar ese flujo antes de prometer un panel "con todo incluido". Si estás definiendo una app interna o una plataforma para clientes, cuéntanos qué necesita hacer cada persona. Podemos empezar por ahí, sin que compartas contraseñas ni expedientes reales.