Cuando una entidad principal intenta asumir un rol de Resource Access Management (RAM), el servicio evalúa un conjunto de políticas para determinar si permite o deniega la solicitud. Este tema explica la lógica de evaluación que se aplica específicamente a la acción sts:AssumeRole.
Asumir un rol de RAM es una acción especial en la que se deben comprobar simultáneamente dos conjuntos de permisos:
Los permisos de la entidad principal: la entidad principal (un usuario de RAM u otro rol) que intenta asumir el rol debe contar con una política basada en identidad que le otorgue el permiso para invocar la acción
sts:AssumeRolesobre el rol de destino.La política de confianza del rol: el rol que se asume debe tener una política de confianza (una política basada en recursos) que especifique al solicitante como entidad principal de confianza.
Ambas condiciones deben cumplirse para que la solicitud sea exitosa. A continuación se ilustra el proceso de evaluación.
El proceso para evaluar las políticas al asumir un rol de RAM sigue la lógica de evaluación estándar, con una excepción importante: el paso de combinación de decisiones (paso 4).
Por lo tanto, si ya conoce el proceso estándar, solo necesita revisar el paso 4 de este tema. Para consultar la descripción general completa de las reglas estándar, consulte Cómo evalúa RAM las políticas.
Paso 1: evaluar las políticas de control de Resource Directory (si aplica)
Si la cuenta es miembro de un resource directory, RAM evalúa las control policies aplicables. Las políticas de control funcionan como límites de permisos para la cuenta.
Si la política de control no permite la acción solicitada, la solicitud se deniega y la evaluación se detiene.
Si la acción está permitida, la evaluación continúa con el siguiente paso.
Si no existen políticas de control, se omite este paso.
Las políticas de control se aplican a todas las entidades principales de RAM (usuarios y roles) dentro de una cuenta miembro. Sin embargo, no se aplican al propietario de esa cuenta ni a ninguna entidad principal de la cuenta de administración de Resource Directory.
Paso 2: evaluar las políticas de sesión del rol de RAM (si aplica)
Si la entidad principal es un rol de RAM asumido con una política de sesión (por ejemplo, mediante la operación AssumeRole), RAM evalúa dicha política.
Si la política de sesión no permite la acción solicitada, la solicitud se deniega y la evaluación se detiene.
Si la acción está permitida, la evaluación continúa.
Este paso se omite en las solicitudes de usuarios de RAM y en el inicio de sesión único (SSO) federado, ya que las políticas de sesión no se aplican en esos casos.
Paso 3: evaluar las políticas basadas en identidad y en recursos
RAM evalúa las políticas basadas en identidad (adjuntas al usuario o rol de RAM solicitante) y las políticas basadas en recursos (adjuntas al recurso de destino).
-
Política basada en identidad: RAM evalúa todas las políticas adjuntas a la entidad principal solicitante. Si alguna política deniega explícitamente la solicitud, el resultado es una denegación explícita. Si como mínimo una política permite la solicitud, el resultado es una autorización. De lo contrario, el resultado es una denegación implícita.
NotaDurante el SSO iniciado por el IdP, el usuario aún no ha asumido una identidad, por lo que no se evalúa ninguna política basada en identidad. Solo se comprueba la política de confianza del rol de RAM.
Política basada en recursos: si el recurso de destino tiene una política basada en recursos (como una política de bucket de OSS o una política de confianza de un rol de RAM), RAM la evalúa con la misma lógica. El resultado puede ser una autorización, una denegación explícita o una denegación implícita. Si no existe una política basada en recursos, se omite esta comprobación.
Paso 4: combinar las decisiones y determinar el resultado final
Por último, RAM combina los resultados del paso 3 para tomar una decisión final. La lógica para asumir un rol es más estricta que la de otras acciones:
La solicitud se permite únicamente si tanto la política basada en identidad como la política de confianza del rol de RAM dan como resultado
Allow.En todos los demás casos, incluida cualquier situación donde alguna de las políticas genere una denegación implícita o explícita, la solicitud se deniega.