Lógica de evaluación de políticas

Cuando una entidad principal intenta utilizar la AWS Management Console, la API de AWS o la AWS CLI, la entidad principal envía una solicitud a AWS. Cuando un servicio de AWS recibe la solicitud, AWS lleva a cabo varios pasos para determinar si debe permitir o denegar la solicitud.

1. Autenticación – AWS primero autentica la entidad principal que realiza la solicitud, si fuera necesario. Este paso no es necesario para algunos servicios, como Amazon S3, que permiten algunas solicitudes de usuarios anónimos.

2. Procesamiento del contexto de la solicitud – AWS procesa la información recopilada en la solicitud para determinar las políticas que se aplican a esta.

3. Evaluación de políticas dentro de una misma cuenta – AWS evalúa todos los tipos de políticas, lo que afecta al orden en el que se evalúan las políticas.

4. Cómo determinar si se una solicitud se permite o se deniega dentro de una cuenta – AWS A continuación, procesa las políticas teniendo en cuenta el contexto de la solicitud para determinar si esta se permite o se deniega.

Procesamiento del contexto de la solicitud

AWS procesa la solicitud para recopilar la información siguiente en un contexto de solicitud:

• Acciones (u operaciones): las acciones u operaciones que la entidad principal desea realizar.

• Recursos: el objeto de recurso de AWS sobre el que se realizan las acciones u operaciones.

• Entidad principal: el usuario, el rol, el usuario federado o la aplicación que envió la solicitud. La información sobre la entidad principal incluye las políticas asociada a dicha entidad principal.

• Datos de entorno: información sobre la dirección IP, el agente de usuario, el estado de habilitación de SSL o la hora del día.

• Datos de recursos: datos relacionados con el recurso que se está solicitando. Esto puede incluir información como, por ejemplo, un nombre de tabla de DynamoDB o una etiqueta de una instancia Amazon EC2.

A continuación, AWS utiliza esta información para buscar políticas que se apliquen al contexto de la solicitud.

Evaluación de políticas dentro de una misma cuenta

El modo en que AWS evalúa las políticas depende de los tipos de las políticas aplicables al contexto de la solicitud. Los tipos de políticas siguientes, que se muestran por orden de frecuencia, están disponibles para su uso dentro de una misma Cuenta de AWS. Para obtener más información acerca de estos tipos de políticas, consulte Políticas y permisos en IAM. Para obtener información sobre cómo AWS evalúa las políticas para el acceso entre cuentas, consulte Lógica de evaluación de políticas entre cuentas.

1. Políticas basadas en identidad - Las políticas basadas en identidad se asocian a una identidad de IAM (usuario, grupo de usuarios o rol) y conceden permisos a entidades de IAM (usuarios y roles). Cuando a una solicitud solo le son aplicables políticas basadas en identidad, AWS comprueba toda ellas para obtener al menos un permiso Allow.

2. Políticas basadas en recursos: las políticas basadas en recursos conceden permisos a la entidad principal (cuenta, usuario, rol y entidades principales como sesiones de rol y usuarios federados de IAM) especificada como entidad principal. Los permisos definen lo que la entidad principal puede hacer con el recurso al que está asociada la política. Cuando a una solicitud le son aplicables políticas basadas en recursos y también políticas basadas en identidad, AWS comprueba toda ellas para obtener al menos un permiso Allow. Cuando se evalúan las políticas basadas en recursos, el ARN de entidad principal especificado en la política determina si las denegaciones implícitas en otros tipos de políticas son aplicables a la decisión final.

3. Límites de permisos de IAM: los límites de permisos son una característica avanzada que le permite establecer los permisos máximos que una política basada en identidades puede conceder a una entidad de IAM (usuario o rol). Al establecer un límite de permisos para una entidad, esta solo puede realizar las acciones que le permitan tanto sus políticas basadas en identidad como sus límites de permisos. En algunos casos, una denegación implícita en un límite de permisos puede limitar los permisos concedidos por una política basada en recursos. Para obtener más información, consulte Cómo determinar si se una solicitud se permite o se deniega dentro de una cuenta más adelante en este tema.

4. AWS OrganizationsPolíticas de control de servicios (SCP): las SCP de Organizations especifican los permisos máximos para una organización o unidad organizativa (OU). El máximo de una SCP se aplica a las entidades principales de las cuentas miembro, incluido cada Usuario raíz de la cuenta de AWS. Si existe una SCP, las políticas basadas en identidad y en recursos solo concederán permisos a las entidades principales de las cuentas miembro si la SCP también permite la acción. Si existen a la vez un límite de permisos y una SCP, el límite, la SCP y la política basada en identidad deben permitir conjuntamente la acción.

5. Políticas de sesión: las políticas de sesión son políticas avanzadas que se pasan como parámetros cuando se crea una sesión temporal mediante programación para un rol o un usuario federado. Para crear una sesión de rol mediante programación, utilice una de las operaciones de API AssumeRole*. Al hacerlo y pasar las políticas de sesión, los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades de la entidad IAM y las políticas de la sesión. Para crear una sesión de un usuario federado, se usan las claves de acceso de un usuario de IAM para llamar mediante programación a la operación de API GetFederationToken. Una política basada en recursos tiene un efecto diferente en la evaluación de los permisos de política de sesión. La diferencia depende de si el usuario o ARN de la función o ARN de la sesión se muestran como el principal de la política basada en recursos. Para obtener más información, consulte Políticas de sesión.

Recuerde que una denegación explícita en cualquiera de estas políticas anulará el permiso.

Evaluación de políticas basadas en identidad con políticas basadas en recursos

Las políticas basadas en identidad y las políticas basadas en recursos conceden permisos referidos a las identidades o recursos a los que están asociadas. Cuando una entidad de IAM (usuario o rol) solicita acceso a un recurso de la misma cuenta, AWS evalúa todos los permisos concedidos por las políticas basadas en identidad y las basadas en recursos. Los permisos resultantes son el total de aplicar los dos tipos. Si una política basada en identidad, una política basada en recursos, o ambas, permiten una acción, entonces AWS permite la acción. Una denegación explícita en una de estas políticas anulará el permiso.

Evaluación de políticas basadas en identidad con límites de permisos

Cuando AWS evalúa las políticas basadas en identidad y el límite de permisos para un usuario, los permisos resultantes son la intersección de las dos categorías. Esto significa que, cuando se añade un límite de permisos a un usuario que ya tiene políticas de permisos basadas en identidad, es posible que se reduzca el número de acciones que puede realizar. Del mismo modo, al eliminar un límite de permisos de un usuario, es posible que aumente el número de acciones que este puede realizar. Una denegación explícita en una de estas políticas anulará el permiso. Para ver información acerca del modo en que se evalúan otros tipos de políticas con los límites de permisos, consulte Evaluación de los permisos efectivos cuando se usan límites.

Evaluación de políticas basadas en identidad con SCP de Organizations

Cuando un usuario pertenece a una cuenta que es miembro de una organización, los permisos resultantes son la intersección de las políticas del usuario y la SCP. Esto significa que tanto la política basada en identidad como la SCP deben permitir la acción. Una denegación explícita en una de estas políticas anulará el permiso.

Puede saber si su cuenta es miembro de una organización en AWS Organizations. Los miembros de la organización podrían verse afectados por una SCP. Para ver estos datos a través del comando AWS CLI u operación de la API de AWS, debe tener permisos para la acción organizations:DescribeOrganization para su entidad de Organizations. Debe tener permisos adicionales para realizar la operación en la consola Organizations. Para saber si una SCP deniega el acceso a una solicitud específica o para cambiar los permisos efectivos, póngase en contacto con su administrador de AWS Organizations.

Cómo determinar si se una solicitud se permite o se deniega dentro de una cuenta

Supongamos que un principal envía una solicitud a AWS para acceder a un recurso en la misma cuenta que la entidad del principal. El código de aplicación de AWS decide si la solicitud 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 general de la lógica de evaluación de AWS para las políticas dentro de una misma cuenta.

• 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.

• Un permiso explícito en una política basada en identidad o en recursos anula esta opción predeterminada.

• Si existe un límite de permisos, una SCP de Organizations o una política de sesión, es posible que anule el permiso con una denegación implícita.

• Una denegación explícita en cualquier política invalida cualquier permiso concedido.

El siguiente diagrama ofrece información detallada acerca de cómo se toma una decisión. Este diagrama de flujo no cubre el impacto de las políticas basadas en recursos y las denegaciones implícitas en otros tipos de políticas.

1. 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 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 encuentra una sola denegación explícita aplicable, devuelve como decisión final Deny (Denegar). Si no hay ninguna denegación explícita, la evaluación del código de aplicación continúa.

2. Organizations SCP (Políticas de control de servicios de Organizations): A continuación, el código evalúa las 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 aplicación no encuentra ninguna instrucción Allow aplicable en las SCP, la solicitud se deniega implícitamente. El código devuelve como decisión final Deny (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.

3. 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 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.

   La tabla siguiente lo ayuda a comprender el impacto de las políticas basadas en recursos para los distintos tipos de entidades principales cuando hay denegaciones implícitas en las políticas basadas en identidad, los límites de permisos y las políticas de sesión basadas en identidad.

   En la siguiente tabla, se muestran las políticas basadas en recursos y las denegaciones implícitas en otros tipos de políticas de la misma cuenta.

   Entidad principal efectuando la solicitud	Política basada en recursos	Políticas basadas en identidad	Límite de permisos	Política de sesión	Resultado	Motivo
   Rol de IAM	No aplicable	No aplicable	No aplicable	No aplicable	No aplicable	Un rol en sí no puede realizar una solicitud. Las solicitudes se realizan con la sesión de rol después de asumir un rol.
   Sesión de rol de IAM	Permite el ARN de rol o Permite ARN de sesión de rol	Denegación implícita	Denegación implícita	Denegación implícita	DENEGAR: ARN de rol o PERMITIR: ARN de sesión de rol	Cuando la entidad principal de la política basada en recursos es un ARN de rol, el límite de permisos y la política de sesión se evalúan como parte de la decisión final. Una denegación implícita en cualquiera de las políticas da como resultado una decisión DENY. Cuando la entidad principal en la política basada en recursos es un ARN de sesión de rol, los permisos se otorgan directamente a la sesión. Otros tipos de políticas no afectan a la decisión.
   Usuario de IAM	Permite ARN de usuario de IAM	Denegación implícita	Denegación implícita	No aplicable	PERMITIR	Los permisos se conceden directamente al usuario. Otros tipos de políticas no afectan a la decisión.
   Usuario federado de IAM (GetFederationToken)	Permite ARN de usuario de IAM o Permite ARN de sesión de usuario federado de IAM	Denegación implícita	Denegación implícita	Denegación implícita	DENEGAR: ARN de usuario de IAM o PERMITIR: ARN de sesión de usuario federado de IAM	Cuando la entidad principal de la política basada en recursos es el ARN de un usuario de IAM, una denegación implícita en el límite de permisos o en la política de sesión da como resultado un DENEGAR. Cuando la entidad principal de la política basada en recursos es un ARN de sesión de usuario federado de IAM, los permisos se otorgan directamente a la sesión. Otros tipos de políticas no afectan a la decisión.
   Usuario raíz	Permite ARN de usuario raíz	No aplicable	No aplicable	No aplicable	PERMITIR	El usuario raíz ofrece acceso completo e ilimitado a todos los recursos de la Cuenta de AWS. Para obtener información sobre cómo controlar el acceso de los usuarios raíz a las cuentas de AWS Organizations, consulte Service control policies (SCPs)(Políticas de control de servicios [SCP]) en la Organizations User Guide (Guía del usuario de Organizations).
   Entidad principal de servicio de AWS	Permite una entidad principal del servicio de AWS	No aplicable	No aplicable	No aplicable	PERMITIR	Cuando una política basada en recursos concede permisos directamente a una entidad principal del servicio de AWS, otros tipos de políticas no afectan a la decisión.

   • 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

4. Políticas basadas en identidad — A continuación, el código 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 devuelve una decisión final de Deny. Si cualquier instrucción de cualquier política basada en identidad permite la acción solicitada, entonces el código continúa.

5. Límites de permisos de IAM: el código 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, el código continúa.

6. Políticas de sesión: a continuació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 una decisión final de Allow.

   Para las entidades principales de sesión, el código 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 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).

   • Si no hay ninguna política de sesión, el código 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 devuelve una decisión final de Deny.

   • 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.

7. Errores – Si el código de aplicación AWS encuentra un error en cualquier momento durante la evaluación, generará una excepción y se cerrará.

Ejemplo de evaluación de políticas basadas en identidad y políticas basadas en recursos

Los tipos de políticas más habituales son las políticas basadas en identidad y las políticas basadas en recursos. Cuando se solicita acceso a un recurso, AWS evalúa todos los permisos otorgados por las políticas para que haya al menos un permiso dentro de la misma cuenta. Una denegación explícita en cualquiera de las políticas anulará el permiso.

importante

Si la política basada en identidad o la política basada en recursos de la misma cuenta permite la solicitud y la otra no, la solicitud aún está permitida.

Supongamos que Carlos tiene el nombre de usuario carlossalazar y que intenta guardar un archivo en el bucket de Amazon S3 carlossalazar-logs.

Supongamos también que la política siguiente está asociada al usuario de IAM carlossalazar.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowS3Self",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*log*"
        }
    ]
}

La instrucción AllowS3ListRead de esta política permite a Carlos ver una lista de todos los buckets de la cuenta. La instrucción AllowS3Self concede a Carlos acceso completo al bucket que tiene el mismo nombre que su nombre de usuario. La instrucción DenyS3Logs deniega a Carlos el acceso a los buckets de S3 que contengan log en el nombre.

Además, la siguiente política basada en recursos (denominada política de bucket) está asociada al bucket carlossalazar.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        }
    ]
}

Esta política especifica que únicamente el usuario carlossalazar puede obtener acceso al bucket carlossalazar.

Cuando Carlos solicita guardar un archivo en el bucket carlossalazar-logs, AWS determina qué políticas se aplican a la solicitud. En este caso, solo se aplican la política basada en identidad y la política basada en recursos. Ambas son políticas de permisos. Debido a que no se aplica ningún límite de permisos, la lógica de evaluación se reduce a lo siguiente.

AWS comprueba en primer lugar si existe una instrucción Deny que se aplique al contexto de la solicitud. Encuentra una, ya que la política basada en identidad deniega explícitamente a Carlos el acceso a los buckets de S3 que se usan para el registro. A Carlos se le deniega el acceso.

Supongamos que luego se da cuenta de su error e intenta guardar el archivo en el bucket carlossalazar. AWS comprueba si existe una instrucción Deny y no encuentra ninguna. A continuación, comprueba las políticas de permisos. Tanto la política basada en la identidad como la política basada en los recursos permiten la solicitud. Por lo tanto, AWS permite la solicitud. Si alguna de ellas denegase explícitamente la instrucción, la solicitud habría sido denegada. Si uno de los tipos de política permite la solicitud y el otro no, la solicitud sigue estando permitida.

Diferencia entre denegaciones implícitas y explícitas

Una solicitud da como resultado una denegación explícita si una política aplicable incluye una instrucción Deny. Si las políticas que se aplican a una solicitud incluyen una instrucción Allow y una instrucción Deny, la instrucción Deny prevalece sobre la instrucción Allow. La solicitud se deniega explícitamente.

Una denegación implícita se produce cuando no hay instrucciones Deny ni Allow aplicables. Dado que a los usuarios, roles o usuarios federados de IAM se les deniega el acceso de forma predeterminada, se les debe permitir explícitamente realizar una acción. De lo contrario, se les deniega implícitamente el acceso.

Al diseñar su estrategia de autorización, debe crear políticas con instrucciones Allow que permitan a las entidades principales realizar solicitudes sin problemas. Sin embargo, puede elegir cualquier combinación de denegaciones implícitas y explícitas.

Por ejemplo, puede crear la siguiente política que incluye acciones permitidas, acciones denegadas implícitamente y acciones denegadas explícitamente. La declaración AllowGetList permite acceso de solo lectura a acciones de IAM que empiezan por los prefijos Get y List. Todas las demás acciones de IAM, como iam:CreatePolicy se deniegan implícitamente. La declaración DenyReports deniega explícitamente el acceso a los informes de IAM al denegar el acceso a acciones que incluyen el sufijo Report, como iam:GetOrganizationsAccessReport. Si alguien agrega otra política a esta entidad principal para otorgarle acceso a los informes de IAM, como iam:GenerateCredentialReport, las solicitudes relacionadas con informes se siguen denegando debido a esta denegación explícita.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetList",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyReports",
            "Effect": "Deny",
            "Action": "iam:*Report",
            "Resource": "*"
        }
    ]
}