Mínimo privilegio y separación de funciones

El Top 10 de OWASP de 2025 dedica una categoría entera, A06:2025, al diseño inseguro: controles que nunca se pensaron o que se pensaron mal. La diferencia con un fallo de implementación es de raíz. Un buen diseño puede tener un error de código que se corrige con un parche; un mal diseño no se salva con código perfecto, porque el control que hacía falta no existe. Por eso esta revisión se hace leyendo diagramas, decisiones y permisos, a veces antes de que exista una sola línea.

El primer principio es el de mínimo privilegio: cada componente, cuenta o persona recibe solo los permisos que necesita para su trabajo, y ninguno más. La razón es práctica. Cuando una pieza falla o alguien la usa mal, el daño posible es exactamente lo que esa pieza podía hacer. Una tarea nocturna que solo lee dos tablas y tiene permisos de dueño convierte un fallo menor en uno que alcanza toda la base. MITRE lo cataloga como CWE-250 (ejecución con privilegios innecesarios) y, cuando el problema está en cómo se reparten y revisan los permisos, como CWE-269.

La forma de medir el mínimo privilegio en una arquitectura es comparar dos columnas: lo que se concedió y lo que se usa. La primera sale de las concesiones de la base; la segunda, del registro de consultas de un periodo representativo. Donde lo concedido supera mucho a lo usado hay un hallazgo, y casi siempre tiene una historia detrás: una prisa, un error de permisos que se «arregló» dándolo todo, una revisión que nunca se hizo.

Abre cuentas-de-servicio.txt y lee las dos columnas de cada cuenta. Busca la que tiene la mayor distancia entre lo que puede y lo que hace.

El informe necesita el alcance exacto de la corrección: cuántas cuentas hay que recortar. No todas las diferencias pesan igual (un permiso de borrar que nadie usa no es lo mismo que poder conceder permisos a otros), pero las dos se recortan, y contar bien es lo que permite comprobar después que el cambio se hizo completo.

Recorre otra vez la tabla, cuenta por cuenta, y compara lo concedido con lo usado.

El mínimo privilegio mira cuánto puede cada pieza; la separación de funciones mira qué combinaciones de poder no deben caer en una sola mano. Crear un pago y aprobarlo, solicitar un permiso y concederlo, escribir un cambio y aceptarlo en producción: cada pareja existe para que un error o un abuso necesite a dos personas y no a una. En una aplicación, esa regla tiene que vivir en el servidor, que es quien decide; una política escrita que el sistema no hace cumplir es una intención.

Abre roles.txt: mira qué puede hacer cada rol, qué dice la política de crédito y cómo está configurado el panel.

La configuración del panel dice que la regla está apagada; el registro dice si alguien pasó por ese hueco. Ojo con el atajo de buscar el monto más grande: lo que delata el problema no es la cifra, es que el mismo usuario aparece en las dos acciones de la misma solicitud. Y fíjate en que dos analistas distintos sí cumplen la política, aunque compartan rol.

Abre flujo-desembolsos.txt y sigue cada solicitud de su creación a su aprobación.