Dar acceso a un software no significa que todas las personas deban ver, aprobar o modificar lo mismo. Un vendedor puede necesitar consultar pedidos de su cartera, mientras una persona de finanzas necesita revisar pagos. Definir permisos antes de construir las pantallas ayuda a evitar que una función cómoda exponga información o permita decisiones fuera de responsabilidad.

Separa identidad, rol y permiso

La autenticación responde quién está usando la cuenta; la autorización determina qué puede hacer con un recurso concreto. OWASP recomienda aplicar el menor privilegio necesario y comprobar la autorización en cada solicitud. Ocultar un botón puede mejorar la interfaz, pero no reemplaza un control en el servidor.

Un rol agrupa responsabilidades similares, pero no siempre resuelve todas las diferencias. Dos personas con el rol «comercial» podrían necesitar acceso a cuentas distintas. Define también el alcance: sus propios registros, los de un equipo o todos los de la organización, según cada caso.

Construye una matriz de acciones

Haz una fila por recurso o tarea y una columna por rol. Usa verbos precisos: crear, consultar, editar, aprobar, exportar o eliminar. No marques simplemente «acceso total». Anota si una persona puede ver todos los datos de una ficha o únicamente los que necesita para cumplir su trabajo.

Imagina una empresa que recibe solicitudes de compra. Una persona las registra; un supervisor revisa; finanzas consulta el presupuesto y una gerencia aprueba importes específicos. El flujo es hipotético: sus roles y límites deben surgir de las responsabilidades reales de cada empresa.

Piensa en excepciones y cambios

¿Qué ocurre si quien aprueba está ausente? ¿Puede delegar durante un período? ¿Quién revoca el acceso cuando alguien cambia de equipo? ¿Cómo se trata una corrección posterior a una aprobación? Las excepciones necesitan reglas explícitas para evitar compartir contraseñas o conceder permisos amplios indefinidamente.

También acuerda qué acciones necesitan un registro: responsable, momento y cambio realizado. Un historial no sustituye impedir una acción indebida, pero puede ayudar a investigar diferencias. La cantidad de información registrada debe ajustarse a la sensibilidad del proceso.

Revisa permisos después de los cambios

La matriz inicial deja de representar la realidad cuando cambian los equipos, las responsabilidades o los proveedores. Acuerda una revisión periódica de cuentas activas y accesos especiales con quienes conocen el proceso. Si una persona cambia de funciones, retira lo que ya no necesita y verifica que mantenga lo necesario para su nuevo trabajo.

Piensa también en cuentas compartidas y de proveedores externos: si varias personas usan la misma identidad, resulta más difícil saber quién realizó una acción. Prefiere cuentas identificables cuando el sistema lo permita y documenta el procedimiento de alta y retiro.

Comprueba la matriz con casos reales

  • Prueba una acción autorizada para cada rol importante.
  • Prueba la misma acción con otra cuenta que no deba realizarla.
  • Intenta consultar registros de otro equipo o cliente cuando corresponda.
  • Revisa exportaciones, archivos y enlaces, además de pantallas.
  • Documenta quién aprueba y revisa los cambios de permisos.

Empieza con permisos limitados y amplía solo cuando exista una necesidad justificada. Las matrices son una guía para conversar y probar; ninguna lista genérica garantiza por sí sola la seguridad del sistema.

Fuentes consultadas

Aclaremos quién necesita hacer qué

Cuéntanos los usuarios y las decisiones de tu proceso para definir un alcance de software coherente.

Conversar sobre permisos