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 en la Guía de usuario de Amazon VPC.

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.

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:

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

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 y los ejemplos de políticas de perímetro de datos 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.