El permiso de más

Una política de permisos declara tres cosas: quién (el principal), qué puede hacer (las acciones), y sobre qué (el recurso). En AWS se escribe en una política JSON con Allow/Deny, Action y Resource; en Azure es una asignación de rol con un ámbito. El mínimo privilegio consiste en que las acciones y el recurso sean justo los que la tarea necesita y ni uno más. La señal de alarma es el comodín: una acción * concede todas las acciones del servicio, y un recurso * las concede sobre todo. Un rol de aplicación que solo tiene que leer objetos de un almacenamiento no necesita ningún comodín.

Leer una política es responder tres preguntas —quién, qué y sobre qué— y comparar el "qué" con lo que la tarea de verdad hace.

La aplicación de la tienda de Cobalto solo necesita leer los objetos de un almacenamiento de catálogo. Pero su rol tiene adjunta la política de administración completa: acción * sobre recurso *. Con eso, cualquiera que consiga hacerse pasar por ese rol —una credencial filtrada, un fallo en la aplicación, un servidor comprometido— puede crear usuarios, borrar registros, abrir almacenamientos y apagar el registro de auditoría. Es el abuso de una cuenta válida: no hace falta romper nada, basta con que una identidad legítima pueda hacer más de lo que debería. El permiso de más convierte un incidente pequeño en uno total.

Un rol con administración completa para una tarea de solo lectura es la diferencia entre un incidente contenido y uno que se lleva la cuenta entera.

En Azure el patrón se repite con otra forma. Una cuenta de servicio de Cobalto tiene asignado el rol de propietario (Owner) sobre la suscripción entera, cuando solo administra un grupo de recursos. El rol de propietario incluye gestionar los permisos de los demás, así que esa identidad no solo puede tocar todo: puede concederse y conceder más accesos. Reducir el ámbito de la suscripción al grupo de recursos correcto, y bajar de propietario a un rol que permita justo lo que hace, cierra las dos cosas a la vez —el alcance y la capacidad de ampliarlo—.

En Azure el permiso de más se mide en dos ejes, el rol y su ámbito; hay que estrechar los dos.

El arreglo de los dos casos es el mismo principio: dar exactamente lo que la tarea necesita. El rol de la aplicación de AWS pasa de administración completa a una política con la acción de lectura de objetos sobre el almacenamiento concreto del catálogo, y nada más. La cuenta de servicio de Azure baja de propietario en la suscripción a un rol de menor alcance sobre el grupo de recursos que administra. Reducir el privilegio no se hace "cuando haya tiempo": es lo que hace que una credencial filtrada valga poco. Y se comprueba mirando la política ya corregida, no confiando en que alguien la cambió.

Ajustar cada identidad al mínimo que su trabajo pide es lo que hace que un permiso robado sirva para poco.

Abre el laboratorio de identidad de Cobalto. Entre los roles, encuentra el de la aplicación —el que concede todas las acciones sobre todos los recursos, cuando solo debería leer el catálogo— y lee el informe de la revisión, que cierra con el código del hallazgo.