Principales, roles y confianza entre cuentas

En una nube pública, un principal es la identidad que hace una petición. Los más comunes son el usuario (una identidad con credenciales de larga duración, como una contraseña o una llave de acceso) y el rol (una identidad sin credenciales propias que alguien o algo se pone por un rato). Quien asume un rol recibe credenciales temporales: una sesión que caduca sola.

Por eso los roles se prefieren para personas y cargas de trabajo: si una credencial temporal se filtra, deja de servir cuando la sesión termina. Una llave de usuario filtrada sirve hasta que alguien la desactive. Cada rol lleva dos cosas aparte: una política de confianza (quién puede ponérselo) y las políticas de permisos (qué puede hacer quien lo lleva puesto).

Abre la carpeta y mira cómo está organizada la empresa.

ls principales
cat principales/cuentas-de-la-organizacion.txt

La política de confianza de un rol dice quién puede asumirlo. Lleva un Principal (una cuenta, un usuario, un rol, un servicio o un proveedor de identidad externo) y una acción de asunción. El principal * significa «cualquiera»: si no hay una condición que lo recorte, el rol queda abierto a cualquier identidad de cualquier cuenta que tenga permiso de asumir roles en la suya.

Un comodín en la confianza es el hallazgo clásico de una revisión. Lee las cuatro políticas de confianza de la empresa y busca la que no se puede defender.

ls principales
cat principales/confianza-*.json

Las confianzas entre cuentas llevan el número de la cuenta de origen. La revisión consiste en comparar cada número con dos listas: las cuentas de la organización y los acuerdos vigentes con terceros. Un número que no está en ninguna de las dos es una confianza sin dueño conocido.

El inventario de la oficina de TI trae las dos listas. Cruza cada política de confianza con ellas.

cat principales/cuentas-de-la-organizacion.txt
grep -h Principal principales/confianza-*.json

Cuando el rol está en la cuenta A y quien lo quiere asumir está en la cuenta B, hacen falta dos permisos. La política de confianza del rol (en A) tiene que nombrar a la cuenta B, y la identidad de B tiene que tener, en su propia cuenta, el permiso de asumir ese rol. Si falta uno de los dos lados, la asunción falla.

Un tercero con un identificador externo exigido en la condición está más protegido: sin el valor acordado, la asunción no prospera. Es la defensa contra el «delegado confundido», el caso en que un proveedor es engañado para actuar en nombre de otra empresa.

Una política dice quién puede asumir un rol; el registro de asunciones dice quién lo hizo. Las dos fuentes se leen juntas: la política es el permiso, el registro es el uso. En el registro, cada línea trae la cuenta de origen y el resultado: exito o AccessDenied. Un intento denegado no se cuenta como uso, pero sí cuenta como señal de que alguien probó.

Cuenta con cuidado las asunciones que sí prosperaron.

cat principales/registro-de-asunciones.csv
grep 620358174905 principales/registro-de-asunciones.csv