Cómo la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso - AWS Identity and Access Management

Cómo la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso

El código de aplicación de AWS decide si una solicitud que se envía a AWS debe autorizarse o denegarse. AWS evalúa todas las políticas que se aplican al contexto de la solicitud. A continuación, se proporciona un resumen de la lógica de evaluación de políticas de AWS:

  • De forma predeterminada, todas las solicitudes se deniegan de manera implícita a excepción de Usuario raíz de la cuenta de AWS, que tiene acceso completo.

  • Para que se admitan, las solicitudes deben estar permitidas explícitamente por una política o conjunto de políticas que sigan la lógica de evaluación que se indica a continuación.

  • Una denegación explícita invalida todos los permisos concedidos.

El siguiente diagrama de flujo proporciona detalles sobre cómo se toma la decisión, tanto para el acceso a una sola cuenta como para el acceso entre cuentas.

Diagrama de evaluación

  • Denegar la evaluación - De forma predeterminada, se deniegan todas las solicitudes. Esto se denomina denegación implícita. El código de aplicación del AWS evalúa todas las políticas de la cuenta aplicables a la solicitud. Esto incluye las SCP y RCP de AWS Organizations, las políticas basadas en recursos, las políticas basadas en identidad, los límites de permisos de IAM y las políticas de sesión. En todas estas políticas, el código de aplicación buscará una instrucción Deny que se aplique a la solicitud. Esto se denomina una denegación explícita. Si el código de aplicación encuentra una sola denegación explícita aplicable, devuelve como decisión final Denegar. Si no hay ninguna denegación explícita, la evaluación del código de aplicación continúa.

  • RCP de Organizations: el código de aplicación evalúa las políticas de control de recursos de AWS Organizations que se aplican a la solicitud. Las RCP se aplican a los recursos de la cuenta a la que se adjuntan las RCP. Si el código de aplicación no encuentra ninguna instrucción Allow aplicable en las RCP, devuelve como decisión final Denegar. Tenga en cuenta que una política administrada de AWS llamada RCPFullAWSAccess se crea automáticamente y se adjunta a todas las entidades de su organización, incluida la raíz, cada OU y Cuenta de AWS cuando los RCP están habilitados. RCPFullAWSAccess no se puede separar, por lo que siempre habrá una instrucción de Allow. Si no hay ninguna RCP, o si la RCP permite la acción solicitada, la evaluación del código de aplicación continúa.

  • SCP de Organizations: el código evalúa las políticas de control de servicio (SCP) de AWS Organizations que se aplican a la solicitud. Las SCP se aplican a las entidades principales de la cuenta a la que se asocian las SCP. Si el código de ejecución no encuentra ninguna instrucción Allow aplicable en las SCP, devuelve como decisión final Denegar. Si no hay ninguna SCP, o si la SCP permite la acción solicitada, la evaluación del código de aplicación continúa.

  • Políticas basadas en recursos: dentro de la misma cuenta, las políticas basadas en recursos tienen un impacto diferente en la evaluación de políticas según el tipo de entidad principal que acceda al recurso y que se permite en la política basada en recursos. Según el tipo de entidad principal, un Allow en una política basada en recursos puede dar lugar a una decisión final de Allow, incluso si existe una denegación implícita en una política basada en identidad, un límite de permisos o una política de sesión.

    Para la mayoría de los recursos, solo necesita un permiso explícito de Allow para la entidad principal en una política basada en identidades o en una política basada en recursos para conceder acceso. Las políticas de confianza del rol de IAM y las políticas de claves de KMS son excepciones a esta lógica, porque deben permitir explícitamente el acceso a entidades principales.

    La lógica de políticas basada en recursos difiere de otros tipos de políticas si la entidad principal especificada es un usuario de IAM, un rol de IAM o una entidad principal de sesión. Las entidades principales de sesión incluyen sesiones de rol de IAM o una sesión de usuario federado de IAM. Si una política basada en recursos concede permiso directamente al usuario de IAM o a la entidad principal de sesión que realiza la solicitud, una denegación implícita en una política basada en identidad, un límite de permisos o una política de sesión no afecta a la decisión final.

    • Rol de IAM: las políticas basadas en recursos que otorgan permisos a un ARN de rol de IAM están limitadas por una denegación implícita en un límite de permisos o una política de sesión. Puede especificar el ARN del rol en el elemento de entidad principa o en la clave de condición aws:PrincipalArn. En ambos casos, la entidad principal que realiza la solicitud es la sesión de rol de IAM.

      Los límites de permisos y las políticas de sesión no limitan los permisos concedidos mediante la clave de condición aws:PrincipalArn con un comodín(*) en el elemento de entidad principal, a menos que las políticas basadas en identidad contengan una denegación explícita. Para obtener más información, consulte Entidades principales de rol de IAM.

      ARN de rol de ejemplo

      arn:aws:iam::111122223333:role/examplerole

    • Sesión de rol de IAM: dentro de la misma cuenta, las políticas basadas en recursos que otorgan permisos a un ARN de sesión de rol de IAM otorgan permisos directamente a la sesión de rol asumida. Los permisos otorgados directamente a una sesión no están limitados por una denegación implícita en una política basada en la identidad, un límite de permisos ni una política de sesión. Cuando asume un rol y realiza una solicitud, la entidad principal que realiza la solicitud es el ARN de sesión de rol de IAM y no el ARN del rol en sí. Para obtener más información, consulte Entidades principales de sesión de rol.

      Ejemplo ARN de sesión de rol

      arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname

    • Usuario de IAM: dentro de la misma cuenta, las políticas basadas en recursos que otorgan permisos a un ARN de usuario de IAM (que no es una sesión de usuario federado) no están limitadas por una denegación implícita en una política basada en identidad o en un límite de permisos.

      Ejemplo de ARN de usuario de IAM

      arn:aws:iam::111122223333:user/exampleuser

    • Sesiones de usuarios federados de IAM: una sesión de usuarios federados de IAM es una sesión creada mediante la llamada a GetFederationToken. Cuando un usuario federado realiza una solicitud, la entidad principal que realiza la solicitud es el ARN de usuario federado y no el ARN del usuario de IAM que se federó. En la misma cuenta, las políticas basadas en recursos que otorgan permisos a un ARN de usuario federado otorgan permisos directamente a la sesión. Los permisos otorgados directamente a una sesión no están limitados por una denegación implícita en una política basada en la identidad, un límite de permisos ni una política de sesión.

      Sin embargo, si una política basada en recursos concede permiso al ARN del usuario de IAM que se federó, las solicitudes realizadas por el usuario federado durante la sesión están limitadas por una denegación implícita en un límite de permisos o una política de sesión.

      Ejemplo de ARN de sesión de usuario federado de IAM

      arn:aws:sts::111122223333:federated-user/exampleuser

  • Políticas basadas en identidad: el código de aplicación comprueba las políticas basadas en la identidad de la entidad principal. En el caso de un usuario de IAM, se trata de las políticas del usuario y las políticas de los grupos a los que el usuario pertenece. Si no hay políticas ni instrucciones basadas en la identidad que permitan la acción solicitada, la solicitud se deniega implícitamente y el código de aplicación devuelve como decisión final Denegar. Si cualquier instrucción de cualquier política basada en identidad permite la acción solicitada, entonces la evaluación del código continúa.

  • Límites de permisos de IAM: el código de aplicación comprueba si la entidad de IAM utilizada por la entidad principal tiene un límite de permisos. Si la política empleada para establecer el límite de permisos no permite la acción solicitada, la solicitud se deniega implícitamente. El código devuelve como decisión final Deny (Denegar). Si no hay ningún límite de permisos, o si el límite de permisos permite la acción solicitada, la evaluación del código continúa.

  • Políticas de sesión: el código comprueba si la entidad principal es una entidad principal de sesión. Las entidades principales de sesión incluyen una sesión de rol de IAM o una sesión de usuario federado de IAM. Si la entidad principal no es una entidad principal de sesión, el código de ejecución devuelve como decisión final Permitir.

    Para las entidades principales de sesión, el código de aplicación comprueba si se ha pasado una entidad principal de sesión en la solicitud. Puede pasar una política de sesión con la AWS CLI o la API de AWS a fin de obtener credenciales temporales para un rol o un usuario federado de IAM. Si no ha pasado ninguna política de sesión, se crea una política de sesión predeterminada y el código de aplicación devuelve como decisión final Permitir.

    • Si existe una política de sesión y no permite la acción solicitada, la solicitud se deniega implícitamente. El código devuelve como decisión final Deny (Denegar).

    • El código de aplicación comprueba si la entidad principal es una sesión de rol. Si la entidad principal es una sesión de rol, la solicitud se permite. De lo contrario, la solicitud se deniega implícitamente y el código de aplicación devuelve como decisión final Denegar.

    • Si una política de sesión está presente y permite la acción solicitada, entonces el código de aplicación devuelve una decisión final de Allow.