Políticas de confianza y quién puede asumir un rol

Una trust policy es el documento asociado a un rol que define exactamente qué principals pueden asumirlo. Es el guardián de la entrada: aunque una política de permisos conceda un acceso potente, nadie puede utilizar el rol a menos que la política de confianza lo incluya. En el examen, los errores en las políticas de confianza son una causa frecuente tanto de accesos bloqueados como de concesiones peligrosamente amplias.

El elemento Principal de una política de confianza puede hacer referencia a:

• AWS: una cuenta, un usuario o un ARN de rol (Amazon Resource Name).
• Service: un servicio de AWS, como lambda.amazonaws.com.
• Federated: un proveedor SAML o un proveedor de identidades web.

Elegir el tipo de principal adecuado y especificarlo con precisión es esencial para no conceder más confianza de la prevista.

La asunción entre cuentas requiere que ambas partes estén de acuerdo. La política de confianza del rol en la cuenta de destino debe permitir al principal que realiza la llamada, y ese principal debe tener una política de identidad que permita sts:AssumeRole sobre el ARN del rol. Si falta cualquiera de las dos partes, la solicitud se bloquea. Este acuerdo en dos direcciones es una trampa clásica del examen.

Esta política de confianza permite que un rol específico de la cuenta 111122223333 asuma el rol. Indicar un ARN exacto en lugar de la cuenta completa es más restrictivo y seguro.

Especificar un principal como arn:aws:iam::ACCOUNT:root establece confianza en toda la cuenta: cualquier principal de esa cuenta que también tenga permiso sts:AssumeRole puede asumir el rol. Esto es amplio. Siempre que sea posible, indique el ARN exacto del usuario o del rol para aplicar el principio de mínimo privilegio y reducir la superficie de confianza.

Las políticas de confianza admiten bloques de Condition que restringen quién puede asumir el rol y cómo puede hacerlo. Entre las claves habituales se incluyen sts:ExternalId (para evitar el problema del delegado confundido), aws:MultiFactorAuthPresent (para exigir MFA) y aws:SourceIp. Las condiciones permiten conceder la asunción únicamente en circunstancias específicas y verificables.

Un patrón potente consiste en exigir MFA antes de poder asumir un rol sensible. La condición de la política de confianza comprueba que la sesión que realiza la llamada se autenticó con MFA. Esto significa que ni siquiera una credencial de larga duración robada puede asumir el rol privilegiado sin el segundo factor, lo que eleva considerablemente la dificultad para los atacantes.

Algunos roles son service-linked roles, predefinidos por AWS con una política de confianza que no puede editar. Permiten que un servicio administre recursos en su nombre con exactamente la confianza que AWS requiere. Es importante reconocerlos porque sus permisos y su confianza están estrechamente controlados y vinculados al ciclo de vida del servicio.

Confiar en un principal interno (de la misma cuenta) suele implicar menos riesgo que confiar en una external account o en un proveedor SaaS externo. Para la confianza externa, combine siempre un principal específico con condiciones como ExternalId. Considere cada declaración de confianza externa como un punto de entrada que un atacante estaría encantado de aprovechar.

IAM Access Analyzer revisa automáticamente las políticas de confianza y las políticas de recursos para encontrar roles que puedan ser asumidos por cuentas externas o por el público. Señala la confianza entre cuentas o pública no prevista para que pueda restringirla. Revisar los hallazgos de Access Analyzer es un control recomendado y relevante para el examen, ya que permite detectar una confianza demasiado amplia.

Para diseñar la confianza de forma segura, indique el principal más específico posible, añada condiciones como ExternalId y MFA cuando corresponda, prefiera los roles a la confianza en la raíz de la cuenta y revise la configuración con Access Analyzer. Recuerde que la política de confianza responde a quién, mientras que las políticas de permisos responden a qué; ambas deben estar alineadas para que el acceso funcione y respete el mínimo privilegio.

Ponga a prueba sus conocimientos sobre las políticas de confianza.

Una trust policy define qué principals pueden asumir un rol y actúa como guardián independientemente de las políticas de permisos. La asunción entre cuentas requiere un acuerdo en dos direcciones: la política de confianza más el permiso sts:AssumeRole del solicitante. Prefiera ARN de principales específicos en lugar de la raíz de la cuenta, añada conditions como ExternalId y MFA, y audite con IAM Access Analyzer.