Roles, atributos y relaciones: cuándo usar cada modelo

Toda regla de acceso responde a lo mismo: quién puede hacer qué sobre qué recurso. Lo que cambia entre modelos es de dónde sale la respuesta. En el control por roles (RBAC), la persona recibe uno o varios roles y cada rol trae un conjunto fijo de permisos: «compras crea órdenes». Es fácil de auditar porque la pregunta «qué puede hacer este rol» tiene una lista corta como respuesta.

En el control por atributos (ABAC), la decisión se calcula con propiedades de la persona, del recurso, de la acción y del entorno: el monto del gasto, la clasificación del documento, la hora. La guía de NIST sobre este modelo (SP 800-162) lo describe como reglas que combinan esos atributos en el momento de decidir. En el control por relaciones (ReBAC), lo que decide es el vínculo entre la persona y el recurso: es residente de esta obra, tiene contrato en este frente, es autora de este documento.

Ningún modelo gana siempre. Los roles sirven para permisos que valen igual en toda la organización; en cuanto la regla dice «de su obra» o «hasta tal monto», los roles solos empiezan a multiplicarse. La mayoría de las aplicaciones reales combinan los tres: un rol que habilita la función, y una relación o un atributo que acota sobre qué objetos.

Abre reglas-de-acceso.txt. Son siete reglas aprobadas por la gerencia. Clasifícalas mentalmente: unas se resuelven solo con el rol, otras necesitan saber qué relación tiene la persona con la obra o el frente, otras miran una propiedad del recurso. Una de ellas no depende ni de la persona ni del recurso, sino de una condición del momento en que se pide la acción.

Esa clase de regla es la que más delata a un diseño solo por roles, porque ningún rol cambia según la hora.

Cuando las reglas dicen «de su obra» y el modelo solo tiene roles, la salida fácil es crear un rol por obra: residente_obra_0412, residente_obra_0415… y después uno por frente, y después uno por tope. Cada rol nuevo es una línea más que alguien tiene que asignar, revisar y retirar a mano. A ese crecimiento se le llama explosión de roles, y es la señal de que el modelo ya no encaja con las reglas.

Abre catalogo-de-roles.txt y separa las familias que expresan una función de la organización de las que solo repiten el mismo permiso cambiando la obra, el frente o el tope.

Un rol asignado a mano dura lo que tarde alguien en quitarlo. La regla R4 dice «contrato vigente», pero el catálogo traduce esa condición a un rol que se asigna al firmar y se retira cuando alguien lo pide. Cuando el contrato termina, el rol sigue ahí. Una relación calculada a partir del contrato, en cambio, desaparece sola el día en que el contrato vence.

Cruza en asignaciones-contratistas.txt la fecha de fin de cada contrato con la fecha del corte.

Con lo que encontraste, tienes que recomendar un diseño para las reglas R3 y R4 que no obligue a crear un rol cada vez que se abre una obra o un frente, y que no deje permisos vivos cuando un contrato termina.