¿Quién puede cambiar un precio? Define los permisos de tu app empresarial

Por Noe Guerrero III

Una app empresarial necesita más que una cuenta de “administrador” y otra de “personal”. Antes del desarrollo, anota quién puede realizar cada acción importante, a qué registros puede acceder y qué debe pasar cuando no tiene permiso. Ese pequeño documento les da al dueño del negocio y al desarrollador algo concreto sobre lo cual ponerse de acuerdo.

Empieza con una decisión que podría complicar un día normal de trabajo: cambiar un precio, descargar datos de clientes o pasar un trabajo a otro técnico. Si la respuesta es “las personas indicadas pueden hacerlo”, el documento del proyecto todavía no está terminado.

Describe el trabajo antes de nombrar los roles

El nombre de un rol solo cuenta parte de la historia. “Técnico” podría referirse a alguien que puede ver todas las solicitudes de reparación o a alguien que solo puede ver sus trabajos asignados. Son requisitos diferentes, aunque el menú de la cuenta se vea idéntico.

Enumera las acciones con verbos sencillos: ver, crear, editar, aprobar, exportar y archivar. Sepáralas cuando el negocio las trate de manera diferente. Que una persona pueda consultar la cita de un cliente no resuelve automáticamente si debería poder descargar toda la lista de clientes.

Después agrega el límite. ¿El permiso abarca un trabajo asignado, una sucursal o todo el negocio? Anota junto a él cualquier condición necesaria, como “la cita todavía es un borrador”. Deja las preguntas pendientes claramente identificadas, en lugar de tratarlas como un permiso sin decirlo.

La guía de autorización de OWASP distingue entre iniciar sesión y tener permiso para actuar. Recomienda conceder solo los privilegios necesarios, denegar el acceso de forma predeterminada y comprobar los permisos en cada solicitud. Ocultar un botón no basta para hacer cumplir la regla; el servidor también debe comprobarla.

El dueño del negocio aporta las decisiones operativas. El desarrollador elige e implementa un diseño adecuado de control de acceso. Una tabla breve de planificación facilita esa conversación sin pretender ser la implementación.

Revisa un taller de reparación hipotético

Imagina un pequeño taller de reparación de electrodomésticos en McAllen que está planeando una app interna para agendar trabajos. Tanto el taller como sus reglas son ficticios. Cuenta con recepción, técnicos y un gerente; la primera versión propuesta atenderá a una sucursal.

Esta es una matriz de permisos inicial para ese ejemplo. Todo lo que quede fuera de estas filas todavía necesita una decisión antes de incluirse en la versión.

Observa las preguntas que esto deja al descubierto. Recepción puede crear un borrador, pero ¿quién lo confirma? ¿Puede un gerente reabrir un trabajo terminado? ¿Qué pasa cuando falta el técnico asignado? Son preguntas sobre el producto que hay que resolver con el taller, no motivos para darles acceso sin restricciones a todos.

Mantén la primera versión lo suficientemente acotada para poder explicarla. Si una excepción propuesta necesita un párrafo, dale su propia regla y ejemplo. Por ejemplo, un técnico de reemplazo temporal podría recibir una reasignación documentada en lugar de acceso a todos los trabajos.

Para cada fila, identifica también a la persona que puede aprobar un cambio de política. De lo contrario, una petición para facilitar el trabajo durante una tarde ocupada puede convertirse, sin que nadie lo note, en un permiso permanente que nadie recuerda haber aprobado.

Separa la aprobación de la ejecución del trabajo

Un equipo puede querer que alguien solicite un cambio de precio sin permitirle aplicarlo. Escríbelas como acciones separadas. Decide quién revisa la solicitud, si quien la presenta puede aprobar su propia propuesta y cuándo entra en vigor el precio aprobado.

Usa un ejemplo cotidiano para comprobar la redacción: un técnico nota que el precio indicado de un servicio está desactualizado. ¿Puede enviar una propuesta de corrección? ¿Quién la ve? ¿Qué precio debe cotizar recepción mientras la solicitud está pendiente? El documento del proyecto debería permitir que el personal responda esas preguntas sin leer código.

No agregues un flujo de aprobación solo porque suena sofisticado. Si únicamente el gerente cambia el precio directamente, indícalo. El resultado útil es un proceso acordado que el negocio pueda operar, con las decisiones pendientes claramente marcadas.

Esta tabla puede acompañar el recorrido del cliente, los campos de datos y los criterios de aceptación en un documento de proyecto para desarrollar una app. Explica una parte específica del alcance, en lugar de dejar la “gestión de usuarios” como un punto sin definir.

Pide evidencia de los casos denegados

Una demostración con una cuenta de gerente no mostrará si las restricciones de un técnico funcionan correctamente. Revisa las acciones permitidas y las denegaciones esperadas con cuentas de prueba separadas y registros inventados en un entorno de prueba acordado.

La guía de OWASP para automatizar las pruebas de autorización describe una matriz que relaciona funciones, roles y, cuando hace falta, datos del negocio. Su enfoque convierte esas combinaciones en pruebas de integración. Pregunta al desarrollador cómo representará las reglas acordadas en comprobaciones repetibles.

Para el taller ficticio, el dueño podría solicitar estos escenarios de aceptación:

• Recepción puede guardar una cita en borrador, pero no puede cambiar la lista de precios.

• Un técnico puede leer las notas de servicio de un trabajo que tiene asignado, pero no puede leer las notas de servicio de un trabajo asignado a otra persona.

• Un técnico puede terminar un trabajo asignado que esté en curso, pero no puede terminar uno que todavía no se haya iniciado, según esta regla propuesta.

• Un técnico no puede exportar la lista de clientes, ni siquiera mediante una solicitud directa al servicio de exportación.

• Después de reasignar un trabajo de prueba, el técnico anterior no puede leer sus notas de servicio ni marcarlo como terminado.

Pide al desarrollador que registre el rol de la cuenta, la asignación o el estado del registro que corresponda, la acción intentada, el resultado esperado y el resultado observado. Cuando se deniegue una acción que modificaría datos, comprueba que el registro correspondiente no haya cambiado. Conserva las fallas y los casos sin resolver en la entrega; una captura de un menú oculto no es la misma evidencia.

Conserva las reglas para la siguiente versión

Las nuevas exportaciones, sucursales y etapas de aprobación ameritan otra revisión de este documento. La guía de OWASP sobre pruebas de regresión de autorización aborda la comprobación de los límites de acceso conforme cambia el software, incluido el acceso a registros de otro usuario y a acciones que requieren mayores privilegios.

Pon una fecha de revisión, una persona responsable de la política y una referencia de la versión en la matriz. Cuando cambie un flujo de trabajo, actualiza su regla, su ejemplo y su prueba al mismo tiempo. Pregunta también quién actualiza el acceso de una persona cuando cambian sus responsabilidades.

Una matriz de permisos no demuestra que una app sea segura. Hace que los límites previstos por el negocio se puedan revisar, para que el desarrollo y las pruebas tengan un objetivo claro. Empieza con las pocas acciones que más importan, define su alcance y pide ver tanto los resultados permitidos como los denegados.