Roles, atributos y relaciones: qué modelo para qué problema

La autorización basada en roles (RBAC) agrupa permisos en roles que representan funciones y asigna los roles a las personas. Responde a la pregunta «¿qué hace esta persona en la empresa?». El modelo de referencia es el de NIST, adoptado como norma ANSI/INCITS 359-2004, que además de roles contempla jerarquías y roles que no pueden coincidir en la misma persona. Funciona muy bien cuando el permiso depende de la función y la función cambia poco.

La autorización basada en atributos (ABAC) decide evaluando reglas sobre atributos del sujeto (función, región, verificación vigente), del recurso (clasificación, obra, monto), de la acción y del entorno (equipo, hora). NIST SP 800-162 la describe como guía. Responde a «¿se cumplen estas condiciones en esta petición?» y sirve cuando la decisión compara valores o depende del contexto.

La autorización basada en relaciones (ReBAC) decide por los vínculos entre objetos: esta persona es miembro de esta obra, esta carpeta está dentro de aquella, esta carpeta se compartió con esta firma. Responde a «¿qué une a esta persona con este objeto?» y es la forma natural de expresar compartir, pertenecer y heredar. En la práctica se combinan: lo importante es saber qué pregunta resuelve cada pieza.

Que una necesidad figure como «cubierta» es la opinión de quien la revisó, no un hecho. Se comprueba leyendo el mecanismo con que se cubre y preguntando si concede exactamente lo que la necesidad pide. Un mecanismo que concede más también deja la casilla en verde: nadie se queja de tener permisos de sobra, así que el exceso no aparece en ningún incidente hasta que alguien lo usa.

Abre el laboratorio y lee necesidades.txt junto con modelo-actual.txt. Compara, fila por fila, el texto de la necesidad con lo que concede el mecanismo de hoy, y desconfía de la columna de estado.

Un rol es un conjunto fijo de permisos. Puede decir que alguien aprueba pagos, pero no puede comparar dos valores de la misma petición: quién la hace y quién registró el pago que se aprueba. Esa comparación es una separación de funciones por transacción, y necesita un atributo del recurso (quién lo registró) y un atributo del sujeto (quién pide), evaluados en el momento. Crear más roles no la resuelve: solo cambia de nombre a las personas que aprueban.

Lee propuesta-del-equipo.txt y comprueba, para cada necesidad, si el modelo propuesto puede expresar la regla tal como está escrita en necesidades.txt.

Corregida la propuesta, quedan tres tipos de regla en la misma plataforma: funciones estables, pertenencias que cambian cada semana (obra asignada, carpeta compartida) y condiciones de contexto (equipo, verificación, monto). Mezclar modelos no es desorden si las tres piezas se evalúan en el mismo sitio y con la misma política; el desorden aparece cuando cada servicio resuelve su parte a su manera.