AWS Identity and Access Management
Guía del usuario

Lógica de evaluación de políticas

Cuando una entidad principal intenta utilizar la Consola de administración de AWS, 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 – A continuación, AWS 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): 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ítica, consulte Políticas y permisos. Para obtener más información sobre la autorización entre cuentas, consulte Cómo los roles de IAM difieren de las políticas basadas en recursos.

  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 o un usuario federado) 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.

  3. Límites de permisos de IAM: los límites de permisos son una característica avanzada que establece los permisos máximos que una política basada en identidad 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. Los límites de permisos no afectan a los permisos concedidos por las políticas basadas en recursos.

  4. Políticas de control de servicios (SCP) de AWS Organizations: las SCP de Organizaciones especifican los permisos máximos para una organización o unidad organizativa (OU). El máximo de una SCP se aplica a las entidades de las cuentas de miembros, incluido cada Usuario de la cuenta raíz de AWS. Si existe una SCP, las políticas basadas identidad y en recursos solo concederán permisos a las entidades 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ámetro cuando se crea una sesión temporal mediante programación para una función 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 función) 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 y políticas basadas en recursos

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 y límites de permisos

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

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.


               Evaluación de políticas basadas en identidad y SCP

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 Organizaciones. Debe tener permisos adicionales para realizar la operación en la consola Organizaciones. 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 recopila 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 esas políticas dentro de una misma cuenta.

  • De forma predeterminada, todas las solicitudes se deniegan implícitamente. (Como alternativa, de forma predeterminada, Usuario de la cuenta raíz de AWS 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 Organizaciones 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.


            Diagrama de evaluación
  1. Evaluación de denegació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, los límites de permisos de IAM, las políticas de sesión de rol y las políticas basadas en identidad. 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, el código continúa.

  2. SCP de Organizaciones: a continuación, el código evalúa las políticas de control de servicios (SCP) de AWS Organizations aplicables a la solicitud. Las SCP se aplican si la solicitud se realiza en una cuenta que las tengan asociadas. 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, el código continúa.

  3. Políticas basadas en recursos: si el recurso solicitado tiene una política basada en recursos que permita a la entidad principal realizar la acción solicitada, el código devuelve como decisión final Allow (Permitir). Si no hay ninguna política basada en recursos, o si la política no contiene una instrucción Allow, el código continúa.

    nota

    Esta lógica puede comportarse de forma diferente si especifica el ARN de una función o usuario de IAM como la entidad principal de la política basada en recursos. Alguien puede utilizar las políticas de sesión para crear una sesión de credenciales temporales para esa función o usuario federado. En ese caso, los permisos efectivos para la sesión podrían no superar los autorizados por la política basada en la identidad del usuario o la función. Para obtener más información, consulte Políticas de sesión.

  4. Límites de permisos de IAM: el código de aplicación comprueba si la entidad de IAM que utiliza 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.

  5. Políticas de sesión: el código comprueba entonces si la entidad principal usa una sesión que se ha asumido pasando una política de sesión. Puede pasar una política de sesión con la AWS CLI o la API de AWS para obtener credenciales temporales para un rol o un usuario federado. Si existe tal 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, o si permite la acción solicitada, el código continúa.

  6. Políticas basadas en identidad: el código comprueba entonces las políticas basadas en identidad para 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 cualquier instrucción de cualquier política basada en identidad permite la acción solicitada, entonces el código de aplicación devuelve como decisión final Allow (Permitir). Si no hay instrucciones que permitan la acción solicitada, la solicitud se deniega implícitamente y el código devuelve como decisión final Deny (Denegar).

  7. Errores: si el código de aplicación de 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.

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

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

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:HeadBucket" ], "Resource": "*" }, { "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*", "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", "Action": "s3:*", "Principal": { "AWS": "arn:aws:iam::111122223333:user/carlossalazar" }, "Resource": "*" } ] }

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

Cuando Carlos realiza su solicitud para 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.


        Diagrama de evaluación

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. La política basada la identidad permite 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.

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 política siguiente para conceder a un administrador acceso completo a todos los recursos de AWS, pero denegarle explícitamente el acceso a la facturación. Si alguien añade otra política a este administrador que le conceda acceso a la facturación, se le seguirá denegando el acceso debido a esta denegación explícita.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] }

También puede crear la política siguiente para permitir a un usuario administrar otros usuarios, pero no grupos ni ningún otro recurso de IAM. Estas acciones se deniegan implícitamente, al igual que las acciones en otros servicios. Sin embargo, si alguien añade una política al usuario que le permita realizar estas otras acciones, se le permitirá hacerlo.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateUser", "iam:DeleteUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:ListUsers", "iam:PutUserPolicy", "iam:UpdateUser" ], "Resource": "*" } }