Cómo definir un rol de consulta mediante casos de aceptación

«Solo consulta» parece preciso hasta que una persona puede exportar registros de todos los clientes o aprobar una solicitud mediante un enlace antiguo. Antes de asignar el rol, define qué registros puede ver y qué acciones siguen prohibidas. Ocultar el botón Editar es solo una parte del acuerdo.

El ejercicio ficticio siguiente permite consultar informes de servicio completados de una sucursal. Es un plan de aceptación propuesto para una aplicación bajo tu control, no una evaluación de seguridad de un sistema de cliente.

Definir el límite con lenguaje del negocio

Empieza con una matriz pequeña: recurso, registros permitidos, campos visibles y acción admitida. En este ejemplo, la persona puede leer informes completados de la sucursal A, no puede leer los de B ni cambiar el estado de un informe. Decide expresamente si se incluyen adjuntos y exportaciones. Exportar copia información fuera de la interfaz aunque no modifique el origen.

La guía de autorización de OWASP recomienda privilegios mínimos, denegar por defecto y comprobar permisos en cada solicitud. Utiliza esos principios para revisar tanto la pantalla habitual como las rutas alternativas hacia la misma operación.

Preparar registros y cuentas de contraste

Crea informes desechables A-23 y B-23 en sucursales diferentes y un informe sin terminar de A que quede fuera del alcance del rol. Utiliza una cuenta de prueba con los permisos propuestos, no una cuenta administradora que simule ser de consulta. Conserva otra cuenta con permisos de edición como control.

Registra el estado y los valores iniciales. Acuerda cómo comprobar cambios almacenados y efectos pendientes después de una acción denegada. Registrar el intento puede ser correcto; modificar el registro empresarial o programar una notificación no es un efecto aceptable de una denegación.

Probar la consulta permitida y las acciones prohibidas

• Consulta habitual: la cuenta abre A-23 y solo ve los campos y adjuntos autorizados.
• Acceso directo: un enlace guardado a B-23 o al informe sin terminar no revela su contenido.
• Rutas de edición: una persona autorizada para la prueba comprueba las solicitudes documentadas de modificación, aprobación y borrado con la cuenta de consulta. El servidor deniega las acciones prohibidas y los registros no cambian.
• Exportaciones: si se permiten, contienen solo registros y campos autorizados. Si se excluyen, tanto el control visible como la operación subyacente aplican la decisión.
• Control positivo: la cuenta editora realiza el cambio previsto en pruebas. Así se distingue una denegación por rol de una función averiada.

Comprobar los cambios de acceso

Retira el rol de consulta mientras hay un informe abierto y solicita otra operación protegida. Verifica el comportamiento acordado para la revocación y cómo explica la interfaz la pérdida de acceso. No supongas que retirar el rol permite recuperar archivos ya descargados.

Repite los casos relevantes en vistas móviles y otros clientes admitidos. Las diferencias de pantalla no deben crear permisos empresariales distintos. Los errores deben ser útiles sin revelar información de registros protegidos.

Aprobar con evidencia, no con una etiqueta

Registra en cada caso el rol, el recurso, la acción solicitada, la decisión esperada, la respuesta observada y el estado de los datos. Oculta credenciales y utiliza contenido ficticio. Una captura sin botón de edición no demuestra que se rechazó una solicitud directa.

Conserva la matriz junto a la definición del rol y revísala al añadir endpoints, campos, exportaciones o integraciones. El alcance y el esfuerzo dependen del modelo de autorización, los límites de datos y la cantidad de clientes. Consulta con Dynelink una matriz de permisos y un plan de aceptación práctico.

Ilustración conceptual generada con IA; no es una captura de un cliente.