BlogPermisos internos
Roles y permisos: quién consulta, cambia y autoriza en tu sistema
Un menú oculto no demuestra que una acción esté bloqueada. Define permisos por tarea y comprueba el resultado con cada rol.
Hoja de prueba: Roles y permisos internos: consulta, cambio y aprobación
Un menú oculto no demuestra que una acción esté bloqueada. Define permisos por tarea y comprueba el resultado con cada rol. Registra datos, resultado esperado, evidencia, responsable y resultado observado.
Empieza por las decisiones que pueden afectar dinero o datos
«Administrador» y «empleado» suelen ser categorías demasiado amplias. En una distribuidora, ventas necesita preparar un descuento; finanzas puede autorizarlo; almacén debe surtir lo aprobado. Escribe esas acciones antes de elegir nombres de roles. Incluye exportar información y cambiar reglas: ambos pueden afectar al negocio aunque no modifiquen un pedido directamente.
Business Central distingue permisos de lectura, inserción, modificación, eliminación y ejecución. OWASP recomienda privilegios mínimos, denegar por defecto y validar permisos en cada solicitud. Por eso conviene probar el resultado de la acción, no solo la presencia de un botón. La combinación de roles también debe revisarse.
Ejemplo ficticio: descuento del pedido P-606
Ventas solicita 12% de descuento para P-606. La regla del ensayo permite a ventas proponer, pero exige a finanzas aprobar descuentos superiores a 8%. La misma persona no puede aprobar su propia solicitud. Son umbrales ficticios elegidos para comprobar el flujo, no una recomendación de margen ni una capacidad ya implementada.
Si el vendedor también recibe un rol temporal de supervisor, la separación entre solicitud y aprobación sigue vigente. Al rechazar el intento, el pedido mantiene el precio anterior y la solicitud queda identificada. Si finanzas autoriza, el sistema conserva quién decidió y qué versión del pedido vio. Un cambio posterior de cantidad requiere la revisión acordada, no reutilizar silenciosamente una aprobación antigua.
| Acción | Ventas | Finanzas | Almacén |
|---|---|---|---|
| Consultar pedido | Sí, para su trabajo | Sí, para revisar | Sí, datos de surtido |
| Solicitar 12% | Sí | No es necesario para este ensayo | No |
| Aprobar solicitud propia | No | No | No |
| Aprobar de otra persona | No | Sí, con criterio acordado | No |
| Cambiar permiso de un usuario | No | No por ser aprobador | No |
Prueba el permiso efectivo de cada cuenta
Usa cuentas de ensayo con un rol y luego con combinaciones reales. Comprueba también una acción iniciada antes del cambio de permiso y completada después. Define cuándo toma efecto la revocación según el producto y qué debe pasar con trabajo pendiente. Registrar esa dependencia es más útil que prometer un efecto instantáneo que no has probado.
| Caso | Resultado esperado | Evidencia |
|---|---|---|
| Ventas solicita 12% en P-606 | Solicitud pendiente, sin aplicar descuento | Pedido y solicitud |
| Ventas intenta aprobar su solicitud | Rechazo; precio sin cambio | Intento y comparación |
| Finanzas aprueba solicitud ajena | Descuento aplicado una vez a la versión revisada | Decisión y versión |
| Almacén intenta cambiar precio | Cambio rechazado aunque conozca la ruta | Solicitud y estado final |
| Se retira rol de finanzas | Nuevo intento no conserva el permiso retirado | Hora y prueba del permiso efectivo |
| Se repite aprobación tras una respuesta perdida | Misma decisión, sin doble cambio | Referencia de aprobación |
Define excepciones con duración y dueño
Una sustitución por vacaciones puede necesitar permisos temporales. Anota motivo, fecha de inicio, fin y quién revisará su retirada. Si nadie puede aprobar durante una ausencia, acuerda un suplente; no entregues una contraseña compartida para resolverlo. Los accesos de emergencia necesitan un procedimiento distinto, con comprobación posterior de lo que se hizo.
Revisa qué hereda cada usuario de grupos, roles e integraciones. El alcance de un permiso puede depender de licencia, configuración y reglas personalizadas. Si la herramienta existente ya permite cumplir la matriz, configúrala y prueba antes de pedir otra. Si falta una separación crítica, documenta el caso concreto para comparar alternativas.
Conserva una matriz que puedas mantener
Actualiza la matriz cuando cambie una tarea, no solo cuando ingrese alguien. Relaciona las acciones con una bitácora de cambios, comprueba la baja de empleados y conserva responsables de llaves digitales. Los permisos del portal de clientes tienen otra frontera: allí también importa impedir acceso a información de otros clientes.
La hoja descargable propone diez pruebas internas y deja los resultados vacíos. Lleva tus aprobaciones, roles actuales y una excepción anonimizada a una consulta gratuita de ciberseguridad. Podemos revisar qué acciones requieren un control verificable y qué depende de la configuración del sistema.
Preguntas frecuentes
No demuestra autorización. Un usuario puede intentar la acción desde otra pantalla o por una solicitud directa. Comprueba que la decisión del sistema bloquea el cambio y deja el dato correcto, siguiendo las funciones y pruebas disponibles del producto.
No por su puesto. Identifica las acciones que necesita y separa administración de usuarios, aprobación de negocio y consulta. Dar permiso para autorizar descuentos no implica que deba poder cambiar las reglas que limitan esos descuentos.
Ejecuta la matriz con la combinación efectiva de grupos y roles. Presta atención a permisos que se suman o se excluyen y a restricciones de aprobación propia. La cuenta individual puede tener más acceso que cualquiera de sus roles visto por separado.
Define quién puede asumir temporalmente la decisión y por cuánto tiempo. Si la operación debe detenerse hasta obtener aprobación, hazlo explícito. Compartir credenciales elimina la atribución y no sustituye una regla de suplencia.
Fuentes
- Define granular permissionsMicrosoft
- Authorization Cheat SheetOWASP
Última actualización: