RBAC

Un rol es un paquete de permisos con nombre que se corresponde con un puesto. A las identidades se les asignan roles, la decisión en el momento de la petición es consultar si alguno de los roles que tienen concede la operación, y administrar pasa a ser gestionar pertenencias en vez de gestionar derechos. Los roles son muchas veces jerárquicos, de forma que uno superior hereda de uno inferior, y la separación de funciones se puede expresar como una regla que impida que una misma identidad tenga dos roles determinados.

El modelo alternativo, el control basado en atributos, evalúa en cambio atributos en el momento de la petición: departamento, ubicación, estado del dispositivo, clasificación del objeto, hora del día. RBAC responde a qué trabajo haces; ABAC responde a si las circunstancias de esta petición son aceptables. La mayoría de los parques usan RBAC para la decisión gruesa y atributos para las condiciones que se aplican encima, que es también lo que hace el acceso condicional en un tenant de Microsoft.

La explosión de roles. Cada excepción se convierte en un rol nuevo, y un parque que empezó con quince tiene cuatrocientos, momento en el que nadie sabe decir qué significa ninguno y administrar es peor que en el modelo por usuario al que sustituyó. La señal son los roles con nombre de persona o de proyecto.

El segundo es la acumulación. La gente cambia de puesto y conserva el rol antiguo porque quitarlo podría romper algo, así que antigüedad y privilegio acaban correlacionados. El ingeniero veterano que ha pasado por cuatro equipos es la cuenta más valiosa del directorio y nadie lo diseñó así.

El tercero es qué contiene el rol de verdad. Los roles predefinidos del cloud son con frecuencia mucho más amplios de lo que sugiere su nombre, y uno que parece cubrir la lectura de la configuración puede incluir leer secretos, o el permiso para modificar la política que concede roles, que es administración con otro nombre. Ahí es donde una asignación de rol se convierte en un attack path, y es por lo que el mínimo privilegio hay que medirlo contra los permisos efectivos y no contra los nombres de los roles.

Resolvemos los permisos efectivos en vez de leer las asignaciones, porque la herencia, el anidamiento de grupos, la jerarquía de recursos y la asunción de roles cambian la respuesta. El hallazgo nombra la identidad, el permiso resuelto y el camino por el que se obtuvo, porque el camino es lo que hay que cortar. Informamos tanto de los roles que no tiene asignados nadie como de los que tiene asignados todo el mundo: lo primero es desorden, lo segundo es la ausencia de un modelo. Esto forma parte de cómo enumeramos los permisos efectivos en un tenant cloud.