# 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.
La evaluación de la política puede variar en función de si la solicitud se hace en una sola cuenta o en una solicitud entre cuentas. Para obtener detalles sobre cómo se toma una decisión de evaluación de políticas para un usuario o rol de IAM en una sola cuenta, consulte [Evaluación de políticas para solicitudes dentro de una misma cuenta](reference_policies_evaluation-logic_policy-eval-basics.md). Para obtener detalles sobre cómo se toma una decisión de evaluación de políticas para las solicitudes entre cuentas, consulte [Lógica de evaluación de políticas entre cuentas](reference_policies_evaluation-logic-cross-account.md).
+ **Denegar la evaluación** - De forma predeterminada, se deniegan todas las solicitudes. Esto se denomina [denegación implícita](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). 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](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). 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 AWS 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 AWS 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](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies) y las [políticas de claves de KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) son excepciones a esta lógica, porque deben permitir explícitamente el acceso a [entidades principales](reference_policies_elements_principal.md). Las políticas basadas en recursos para servicios distintos que no sean IAM y AWS KMS también pueden requerir una instrucción `Allow` explícita en la misma cuenta para conceder el acceso. Para obtener más información, consulte la documentación del servicio específico con el que trabaja.
Para las solicitudes de evaluación de políticas de una sola cuenta, 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 roles de IAM](reference_policies_elements_principal.md#principal-role-session) o [entidades principales de usuario federado de AWS STS](reference_policies_elements_principal.md#sts-session-principals). 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(\$1) 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](reference_policies_elements_principal.md#principal-roles).
**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](reference_policies_elements_principal.md#principal-role-session).
**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
```
+ **Entidad principal de usuario federado de AWS STS**: una sesión de usuario federado es una sesión creada mediante una llamada a [`GetFederationToken`](id_credentials_temp_request.md#api_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**
```
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 AWS STS. 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 transferir una política de sesión al usar la AWS CLI o la API de AWS para obtener credenciales temporales para un rol o una entidad principal de usuario federado de AWS STS. 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**.
# Evaluación de políticas para solicitudes dentro de una misma cuenta
## Evaluación de políticas para un rol de IAM
En el siguiente diagrama de flujo se proporcionan detalles sobre cómo se toma una decisión de evaluación de políticas para un rol de IAM en una sola cuenta.
![\[Diagrama de flujo de evaluación para un rol de IAM en una sola cuenta\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png)
## Evaluación de políticas para un usuario de IAM
En el siguiente diagrama de flujo se proporcionan detalles sobre cómo se toma una decisión de evaluación de políticas para un usuario de IAM en una sola cuenta.
![\[Diagrama de flujo de evaluación de un usuario de IAM en una sola cuenta\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png)
## 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 `amzn-s3-demo-bucket-carlossalazar-logs`.
Supongamos también que la política siguiente está asociada al usuario de IAM `carlossalazar`.
------
#### [ JSON ]
****
```
{
"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:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-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 `amzn-s3-demo-bucket-carlossalazar`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/carlossalazar"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
]
}
]
}
```
------
Esta política especifica que únicamente el usuario `carlossalazar` puede obtener acceso al bucket `amzn-s3-demo-bucket-carlossalazar`.
Cuando Carlos solicita guardar un archivo en el bucket `amzn-s3-demo-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\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/EffectivePermissionsShort.png)
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 `amzn-s3-demo-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.
# Lógica de evaluación de políticas entre cuentas
Puede permitir que un principal de una cuenta acceda a los recursos de una segunda cuenta. Esto se denomina acceso entre cuentas. Cuando permite el acceso entre cuentas, la cuenta donde se encuentra el principal se denomina cuenta de *confianza*. La cuenta donde se encuentra el recurso es la cuenta de *confianza*.
Para permitir el acceso entre cuentas, debe asociar una política basada en recursos al recurso que desea compartir. También debe asociar una política basada en identidad a la identidad que actúa como entidad principal en la solicitud. La política basada en recursos de la cuenta de confianza debe especificar la entidad principal de la cuenta de confianza que tendrá acceso al recurso. Puede especificar toda la cuenta o los usuarios de IAM, las entidades principales de usuario federado de AWS STS, los roles de IAM o las sesiones de rol asumido. También puede especificar un servicio de AWS como principal. Para obtener más información, consulte [Cómo especificar una entidad principal](reference_policies_elements_principal.md#Principal_specifying).
La política basada en la identidad del principal debe permitir el acceso solicitado al recurso en el servicio de confianza. Para ello, puede especificar el ARN del recurso.
En IAM, puede asociar una política basada en recursos a un rol de IAM para permitir que los principales de otras cuentas asuman ese rol. La política basada en recursos del rol se denomina política de confianza de rol. Después de asumir ese rol, los principales permitidos pueden utilizar las credenciales temporales resultantes para acceder a varios recursos de la cuenta. Este acceso se define en la política de permisos basada en la identidad del rol. Para saber la diferencia entre permitir el acceso entre cuentas mediante roles y permitir el acceso entre cuentas mediante otras políticas basadas en recursos, consulte [Acceso a recursos entre cuentas en IAM](access_policies-cross-account-resource-access.md).
**importante**
Otros servicios pueden afectar a la lógica de evaluación de políticas. Por ejemplo, AWS Organizations admite [políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) y [políticas de control de recursos](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) que se pueden aplicar a entidades principales y recursos de una o varias cuentas. AWS Resource Access Manager admite [fragmentos de políticas](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html) que controlan las acciones que las entidades principales pueden realizar en los recursos que se comparten con ellas.
## Determinación de si se permite una solicitud entre cuentas
Para las solicitudes entre cuentas, el solicitante en la `AccountA` de confianza debe tener una política basada en la identidad. Dicha política debe permitirles hacer una solicitud al recurso en la de confianza `AccountB`. Además, la política basada en recursos en `AccountB` debe permitir al solicitante en `AccountA` obtener acceso al recurso.
Cuando realiza una solicitud entre cuentas, AWS realiza dos evaluaciones. AWS evalúa la solicitud en la cuenta de confianza y en la cuenta en que se confía. Para obtener más información acerca de cómo se evalúa una solicitud dentro de una sola cuenta, consulte [Cómo la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso](reference_policies_evaluation-logic_policy-eval-denyallow.md). La solicitud solo se permite si ambas evaluaciones devuelven una decisión de tipo `Allow`.
![\[Evaluación entre cuentas\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png)
1. Una solicitud entre cuentas es el proceso mediante el cual un principal de una cuenta realiza una solicitud para acceder a un recurso de otra cuenta.
1. El principal solicitante existe en la cuenta en la que se confía (`AccountA`). Cuando AWS evalúa esta cuenta, comprueba la política basada en la identidad y cualquier política que pueda limitar una política basada en la identidad. Para obtener más información, consulte [Evaluación de políticas basadas en identidad con límites de permisos](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound).
1. El recurso solicitado existe en la cuenta de confianza (`AccountB`). Cuando AWS evalúa esta cuenta, comprueba la política basada en recursos que está asociada al recurso solicitado y cualquier política que pueda limitar una política basada en recursos. Para obtener más información, consulte [Evaluación de políticas basadas en identidad con políticas basadas en recursos](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp).
1. AWS permite la solicitud solo si ambas evaluaciones de políticas de cuenta permiten la solicitud.
En el siguiente diagrama de flujo se proporciona una ilustración más detallada de cómo se toma una decisión de evaluación de políticas para una solicitud entre cuentas. De nuevo, AWS permite la solicitud solo si ambas evaluaciones de políticas de cuenta permiten la solicitud.
![\[Evaluación de políticas entre cuentas detallada\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png)
## Ejemplo de evaluación de política entre cuentas
En el ejemplo siguiente se muestra una situación en la que una política basada en recursos de una cuenta concede permisos a un rol de otra cuenta.
Supongamos que Carlos es un desarrollador con un rol de IAM denominado `Demo` en la cuenta 111111111111. Carlos quiere guardar un archivo en el bucket `amzn-s3-demo-bucket-production-logs` Amazon S3 de la cuenta 222222222222.
Supongamos también que la política siguiente está asociada al rol de IAM `Demo`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "AllowS3ProductionObjectActions",
"Effect": "Allow",
"Action": "s3:*Object*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
},
{
"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 Amazon S3. La instrucción `AllowS3ProductionObjectActions` concede a Carlos acceso completo al bucket `amzn-s3-demo-bucket-production`.
Además, la siguiente política basada en recursos (denominada política de bucket) está asociada al bucket `amzn-s3-demo-bucket-production` de la cuenta 222222222222.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject*",
"s3:PutObject*",
"s3:ReplicateObject",
"s3:RestoreObject"
],
"Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" },
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
}
]
}
```
------
Esta política permite al rol `Demo` obtener acceso a los objetos del bucket `amzn-s3-demo-bucket-production`. El rol puede crear y editar, pero no eliminar los objetos del bucket. El rol no puede administrar el propio bucket.
Cuando Carlos solicita guardar un archivo en el bucket `amzn-s3-demo-bucket-production-logs`, AWS determina qué políticas se aplican a la solicitud. En este caso, la política basada en la identidad asociada al rol de `Demo` es la única política que se aplica en la cuenta `111111111111`. En la cuenta `222222222222`, no hay ninguna política basada en recursos asociada al bucket `amzn-s3-demo-bucket-production-logs`. Cuando AWS evalúa la cuenta `111111111111`, devuelve una decisión de tipo `Deny`. Esto se debe a que la instrucción `DenyS3Logs` de la política basada en la identidad deniega explícitamente el acceso a cualquier bucket de registro. Para obtener más información acerca de cómo se evalúa una solicitud dentro de una sola cuenta, consulte [Cómo la lógica del código de aplicación de AWS evalúa las solicitudes para permitir o denegar el acceso](reference_policies_evaluation-logic_policy-eval-denyallow.md).
Dado que la solicitud se deniega explícitamente dentro de una de las cuentas, la decisión final es denegar la solicitud.
![\[Solicitud al bucket amzn-s3-demo-bucket-production-logs\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png)
Supongamos que Carlos se da cuenta de su error e intenta guardar el archivo en el bucket `Production`. AWS primero comprueba la cuenta `111111111111` para determinar si la solicitud está permitida. Solo se aplica la política basada en la identidad, que permite la solicitud. A continuación, AWS comprueba la cuenta `222222222222`. Solo se aplica la política basada en recursos asociada al bucket `Production`, que permite la solicitud. Dado que ambas cuentas permiten la solicitud, la decisión final es permitir la solicitud.
![\[Solicitud al bucket Production\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)