Políticas, roles y relaciones de confianza

Un rol de AWS no es una persona: es una identidad que alguien asume para obtener credenciales temporales. Lleva dos cosas distintas. La política de permisos dice qué acciones sobre qué recursos se permiten. La política de confianza dice qué principales pueden asumir el rol: una cuenta, un servicio, un usuario o una identidad federada.

Un rol con permisos modestos y una confianza abierta es tan riesgoso como uno con permisos amplios: quien lo asuma obtiene sus permisos, sea quien sea. Por eso al auditar un rol se leen las dos mitades.

El elemento Principal de una política de confianza nombra a quién se le da la llave. Puede ser un servicio de la plataforma, un usuario concreto, la raíz de otra cuenta (que delega en esa cuenta la decisión de quién entra) o un comodín que significa «cualquiera». Con el comodín y sin ninguna condición, la confianza no limita quién puede intentar asumir el rol: lo único que queda como barrera es lo que cada llamador tenga permitido en su propia cuenta.

Abre las cuatro políticas de confianza de aws/ y busca la que no pone límite a quién puede intentar asumirla.

En Azure, un permiso es una asignación de rol: un principal, un rol y un alcance (grupo de administración, suscripción, grupo de recursos o recurso). Lo asignado en un alcance rige sobre todo lo que cuelga de él. Por eso «Owner» sobre una suscripción entera pesa mucho más que «Owner» sobre un grupo de recursos: incluye la facultad de asignar roles a otros.

El archivo azure/asignaciones-de-rol.txt lista las asignaciones de la empresa. Hay varias de Owner, pero no todas con el mismo alcance.

En Google Cloud una vinculación une un rol con una lista de miembros, y la política de un proyecto es el conjunto de sus vinculaciones. Los roles básicos (propietario, editor y lector) son muy amplios porque cubren casi todos los servicios del proyecto; para casi cualquier tarea concreta existe un rol predefinido más estrecho.

Revisa gcp/politica-proyecto.txt y cuenta cuántos miembros reciben un rol básico capaz de modificar el proyecto, es decir, propietario o editor. Los de lector no cuentan.

Cuando una empresa externa asume un rol en tu cuenta, hay un riesgo sutil: un tercero con muchos clientes podría, por error o engaño, usar su acceso para actuar sobre la cuenta de otro cliente. La condición sts:ExternalId agrega un identificador acordado entre las dos partes que el tercero debe presentar al asumir el rol, y evita que se le use como intermediario con la cuenta equivocada.

El rol de lectura de auditoría de Barbasco lo lleva; el de soporte externo, cuya confianza nombra la raíz de otra cuenta de un proveedor, no.