# Control de acceso a AWS STS mediante políticas de puntos de conexión de VPC Cuando crea un punto de conexión de VPC de interfaz para AWS Security Token Service (AWS STS), puede adjuntar una política de punto de conexión. La política controla qué entidades principales pueden usar el punto de conexión y qué acciones de AWS STS pueden realizar. Si no adjunta una política, el punto de conexión utiliza la política predeterminada que permite el acceso sin restricciones a todas las acciones de AWS STS para todas las entidades principales. Las políticas de puntos de conexión de VPC no conceden permisos por sí mismas. Actúan como un límite adicional que funciona junto con otras políticas. Tanto la política de punto de conexión como las políticas aplicables al intermediario deben permitir la aprobación de la solicitud. Para obtener más información sobre las políticas de puntos de conexión de VPC, consulte [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) en la *Guía de usuario de Amazon VPC*. **Topics** + [Política de puntos de conexión de VPC predeterminada](#reference_sts_vpc_endpoint_policies_default) + [Aspectos importantes para las políticas de puntos de conexión de VPC de AWS STS](#reference_sts_vpc_endpoint_policies_considerations) + [Claves de condición disponibles para las políticas de puntos de conexión de VPC de AWS STS](#reference_sts_vpc_endpoint_policies_condition_keys) + [Ejemplo: permitir todas las acciones de AWS STS para su organización](#reference_sts_vpc_endpoint_policies_example_org) + [Ejemplo: permitir todas las acciones de AWS STS para cuentas específicas](#reference_sts_vpc_endpoint_policies_example_accounts) + [Ejemplo: restringir a acciones específicas de AWS STS](#reference_sts_vpc_endpoint_policies_example_actions) + [Ejemplo: denegar el acceso a personas ajenas a una organización y permitir la federación](#reference_sts_vpc_endpoint_policies_example_deny) ## Política de puntos de conexión de VPC predeterminada Si no adjunta una política personalizada al crear el punto de conexión, AWS adjunta la siguiente política predeterminada. Esta política permite el acceso sin restricciones al punto de conexión. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } ``` Para limitar el acceso al punto de conexión, adjunte una política de punto de conexión personalizada. ## Aspectos importantes para las políticas de puntos de conexión de VPC de AWS STS AWS STS gestiona las solicitudes de dos tipos de intermediarios totalmente diferentes. La política del punto de conexión de VPC debe tener en cuenta ambos tipos para evitar el bloqueo involuntario de las solicitudes legítimas. **Entidades principales de AWS autenticadas** Usuarios de IAM y roles de IAM que firman las solicitudes con Signature Version 4 (SigV4) de AWS. Estos intermediarios tienen claves de condición estándar como `aws:PrincipalOrgID`, `aws:PrincipalAccount` y `aws:PrincipalArn` disponibles en el contexto de la solicitud. **Intermediarios federados** Entidades principales de SAML 2.0 y OpenID Connect (OIDC) que solicitan `AssumeRoleWithSAML` o `AssumeRoleWithWebIdentity`. Estos intermediarios se autentican con aserciones SAML o JSON Web Tokens (JWT), no con firmas SigV4. Como no tienen identidad de AWS en el momento de la solicitud, el contexto de la solicitud no incluye claves de condición basadas en la entidad principal, como `aws:PrincipalOrgID`, `aws:PrincipalAccount` y `aws:PrincipalArn`. **importante** Si su política del punto de conexión de VPC se basa únicamente en `aws:PrincipalOrgID` para permitir el acceso, las solicitudes federadas `AssumeRoleWithSAML` y `AssumeRoleWithWebIdentity` se deniegan implícitamente, ya que la clave de condición no está disponible para las entidades principales que no son de AWS. ### Cómo AWS STS evalúa las políticas de puntos de conexión de VPC para los intermediarios federados Cuando un intermediario federado invoca `AssumeRoleWithSAML` o `AssumeRoleWithWebIdentity` mediante un punto de conexión de VPC, se aplica lo siguiente: + El intermediario no es una entidad principal de AWS. Las claves de condición como `aws:PrincipalOrgID`, `aws:PrincipalAccount` y `aws:PrincipalArn` no están disponibles en el contexto de la solicitud. + Los intermediarios federados no tienen la clave de condición `aws:PrincipalIsAWSService` en el contexto de la solicitud. + El rol que se asume es un recurso de AWS. Las claves de condición basadas en recursos, como `aws:ResourceOrgID` y `aws:ResourceAccount`, están disponibles y hacen referencia al rol de destino. + La política de confianza del rol sigue siendo la principal puerta de autorización para el acceso federado. La política del punto de conexión de VPC establece un límite adicional a nivel de red. Recomendamos utilizar `aws:ResourceOrgID` o `aws:ResourceAccount` al redactar las instrucciones de política del punto de conexión de VPC que se deben aplicar a los intermediarios federados, ya que estos no tienen disponibles claves de condición basadas en la entidad principal. ## Claves de condición disponibles para las políticas de puntos de conexión de VPC de AWS STS En la siguiente tabla se muestran las claves de condición más utilizadas y su disponibilidad en el contexto de la solicitud para cada tipo de intermediario cuando se realizan solicitudes a través de un punto de conexión de VPC de AWS STS. Hay claves de condición adicionales disponibles además de las indicadas aquí. **Disponibilidad de la clave de condición por tipo de intermediario** | Clave de condición | Entidades principales de AWS autenticadas | Intermediarios federados | Descripción | | --- | --- | --- | --- | | `aws:PrincipalOrgID` | Sí | No | El ID de la organización de la entidad principal que realiza la llamada | | `aws:PrincipalAccount` | Sí | No | El ID de la cuenta de la entidad principal que realiza la llamada | | `aws:PrincipalArn` | Sí | No | El ARN de la entidad principal que realiza la llamada | | `aws:PrincipalIsAWSService` | Sí (se evalúa como falso) | No (la clave está ausente) | Si el intermediario es una entidad principal del servicio de AWS | | `aws:ResourceOrgID` | Sí | Sí | El ID de organización de la cuenta propietaria del recurso solicitado | | `aws:ResourceAccount` | Sí | Sí | El ID de cuenta que posee el recurso solicitado | **nota** En el caso de las entidades principales de AWS autenticadas (usuarios y roles de IAM), `aws:PrincipalIsAWSService` está presente en el contexto de la solicitud y se evalúa como falso. En el caso de los intermediarios federados, esta clave no aparece en absoluto en el contexto de la solicitud. Una condición que comprueba `"Bool": {"aws:PrincipalIsAWSService": "false"}` no coincide con los intermediarios federados, ya que la clave no está presente. ## Ejemplo: permitir todas las acciones de AWS STS para su organización La siguiente política del punto de conexión restringe el punto de conexión de VPC de AWS STS a su organización y, al mismo tiempo, admite el acceso federado. Permite todas las acciones de AWS STS para las entidades principales autenticadas de su organización y, por separado, permite que los intermediarios federados asuman roles en su organización. Los intermediarios federados (`AssumeRoleWithSAML` y `AssumeRoleWithWebIdentity`) requieren una instrucción independiente, ya que no tienen `aws:PrincipalOrgID` en el contexto de la solicitud. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowOrganizationPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } }, { "Sid": "AllowFederatedAssumeRole", "Effect": "Allow", "Principal": "*", "Action": [ "sts:AssumeRoleWithSAML", "sts:AssumeRoleWithWebIdentity" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-exampleorgid" } } } ] } ``` La primera instrucción usa `"Principal": {"AWS": "*"}` con `aws:PrincipalOrgID` para permitir a las entidades principales autenticadas de AWS desde su organización. La segunda instrucción usa `"Principal": "*"` para hacer coincidir los intermediarios federados y restringe el rol de destino a su organización mediante `aws:ResourceOrgID`. La política de confianza del rol sigue siendo el control principal para determinar los tipos de rol que las identidades federadas pueden asumir. Para obtener más información sobre la implementación de controles perimetrales de red, consulte [Building a data perimeter on AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) y los [ejemplos de políticas de perímetro de datos](https://github.com/aws-samples/data-perimeter-policy-examples) en el sitio web de GitHub. ## Ejemplo: permitir todas las acciones de AWS STS para cuentas específicas La siguiente política del punto de conexión permite todas las acciones de AWS STS para las entidades principales en cuentas específicas. Use esta política cuando sus cuentas no formen parte de una organización. Los intermediarios federados están permitidos en una instrucción independiente, ya que no tienen `aws:PrincipalAccount` en el contexto de la solicitud. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSpecificAccountPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount": [ "111122223333", "444455556666" ] } } }, { "Sid": "AllowFederatedAssumeRole", "Effect": "Allow", "Principal": "*", "Action": [ "sts:AssumeRoleWithSAML", "sts:AssumeRoleWithWebIdentity" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceAccount": [ "111122223333", "444455556666" ] } } } ] } ``` La primera instrucción usa `"Principal": {"AWS": "*"}` con `aws:PrincipalAccount` para permitir entidades principales de AWS autenticadas de las cuentas especificadas. La segunda instrucción usa `"Principal": "*"` para hacer coincidir los intermediarios federados y restringe el rol de destino a las mismas cuentas mediante `aws:ResourceAccount`. La política de confianza del rol sigue siendo el control principal para determinar los tipos de rol que las identidades federadas pueden asumir. ## Ejemplo: restringir a acciones específicas de AWS STS La siguiente política del punto de conexión solo permite `AssumeRole` para las entidades principales autenticadas y `AssumeRoleWithSAML` para los intermediarios federados, ambos limitados a los roles de su organización. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeRoleByOrgPrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } }, { "Sid": "AllowSAMLFederation", "Effect": "Allow", "Principal": "*", "Action": "sts:AssumeRoleWithSAML", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-exampleorgid" } } } ] } ``` Esta política bloquea otras acciones de AWS STS, como `GetCallerIdentity`, `GetSessionToken` y `AssumeRoleWithWebIdentity`, mediante este punto de conexión. Ajuste los elementos de `Action` para que se adapten a sus requisitos. ## Ejemplo: denegar el acceso a personas ajenas a una organización y permitir la federación La siguiente política del punto de conexión utiliza una denegación explícita para bloquear a las entidades principales autenticadas ajenas a la organización y, al mismo tiempo, preservar el acceso de los intermediarios federados. Este enfoque comienza con una autorización amplia y agrega una instrucción de denegación específica. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAll", "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" }, { "Sid": "DenyNonOrgPrincipals", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sts:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } } ] } ``` La instrucción de denegación utiliza `"Principal": {"AWS": "*"}`, que la limita únicamente a las entidades principales de AWS autenticadas. Los intermediarios federados (SAML y OIDC) no son entidades principales de AWS y este elemento `Principal` no coincide con ellas, por lo que la denegación no se les aplica. Este enfoque evita la necesidad de establecer condiciones `Null` o `Bool` complejas para crear excepciones para los intermediarios federados. **nota** La primera instrucción permite todas las acciones para todas las entidades principales. La denegación de la segunda instrucción tiene precedencia en el caso de las entidades principales de AWS autenticadas ajenas a la organización. La primera instrucción permite a los intermediarios federados, quienes no se ven afectados por la denegación, ya que el elemento `Principal` de la instrucción de denegación no coincide con ellos.