# Políticas de seguridad de las API de REST en API Gateway
Una *política de seguridad* es una combinación predefinida de versión mínima de TLS y conjuntos de cifrado que ofrece API Gateway. Cuando los clientes realizan un establecimiento de comunicación de TLS en la API o el nombre de dominio personalizado, la política de seguridad aplica la versión de TLS y el conjunto de cifrado aceptado por API Gateway. Las políticas de seguridad protegen las API y los nombres de dominio personalizados de los problemas de seguridad de red como, por ejemplo, la manipulación y el espionaje entre un cliente y el servidor.
API Gateway admite políticas de seguridad heredadas y políticas de seguridad mejoradas. `TLS_1_0` y `TLS_1_2` son políticas de seguridad heredadas. Utilice estas políticas de seguridad para compatibilidad con versiones anteriores. Cualquier política que comience con `SecurityPolicy_` es una política de seguridad mejorada. Utilice estas políticas para cargas de trabajo reguladas, una gobernanza avanzada o para utilizar la criptografía poscuántica. Al utilizar una política de seguridad mejorada, también debe configurar el modo de acceso de punto de conexión para una mayor gobernanza. Para obtener más información, consulte [Modo de acceso de punto de conexión](#apigateway-security-policies-endpoint-access-mode).
## Cómo aplica API Gateway las políticas de seguridad
El siguiente ejemplo muestra cómo API Gateway aplica las políticas de seguridad mediante la política de seguridad `SecurityPolicy_TLS13_1_3_2025_09` como ejemplo.
La política de seguridad `SecurityPolicy_TLS13_1_3_2025_09` acepta el tráfico de TLS 1.3 y rechaza el tráfico de TLS 1.2 y TLS 1.0. Para el tráfico de TLS 1.3, la política de seguridad acepta los siguientes conjuntos de cifrado:
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`
API Gateway no acepta ningún otro conjunto de sistemas de cifrado. Por ejemplo, la política de seguridad rechazaría cualquier tráfico de TLS 1.3 que utilice el conjunto de cifrado de `AES128-SHA`. Para obtener más información acerca de los cifrados y versiones de TLS, consulte [Políticas de seguridad admitidas](apigateway-security-policies-list.md).
Para supervisar qué protocolo TLS y qué cifrado utilizan los clientes para acceder a la API Gateway, puede utilizar las variables de contexto `$context.tlsVersion` y `$context.cipherSuite` en los registros de acceso. Para obtener más información, consulte [Supervisión de las API de REST en API Gateway](rest-api-monitor.md).
## Modo de acceso de punto de conexión
El modo de acceso de punto de conexión es un parámetro adicional que debe especificar para cualquier API de REST o nombre de dominio personalizado que utilice una política de seguridad mejorada que comience por `SecurityPolicy_`. Esto se hace al crear el recurso o al cambiar la política de seguridad de una política heredada a una política mejorada.
Cuando el modo de acceso de punto de conexión está configurado como `STRICT`, cualquier solicitud a la API de REST o al nombre de dominio personalizado debe superar las siguientes comprobaciones:
+ La solicitud debe provenir del mismo tipo de punto de conexión de API Gateway que el recurso. Puede provenir de un punto de conexión regional, optimizado para bordes o privado.
+ Si utiliza un punto de conexión regional o privado, API Gateway usa la coincidencia de host de SNI. Si utiliza un punto de conexión optimizado para bordes, API Gateway cumple con la protección de domain fronting de CloudFront. Para obtener más información, consulte [Domain fronting](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions).
Si no se cumple alguna de estas condiciones, API Gateway rechaza la solicitud. Le recomendamos que utilice el modo de acceso de punto de conexión `STRICT` siempre que sea posible.
Para migrar una API o un nombre de dominio existentes para utilizar un modo de acceso estricto de punto de conexión, primero actualice la política de seguridad a una política de seguridad mejorada y mantenga el modo de acceso de punto de conexión configurado en `BASIC`. Tras validar los registros de tráfico y acceso, configure el modo de acceso de punto de conexión en `STRICT`. Al migrar el modo de acceso de punto de conexión de `STRICT` a `BASIC`, el punto de conexión no estará disponible durante unos 15 minutos a medida que se propaguen los cambios.
No debe configurar el modo de acceso de punto de conexión como `STRICT` para determinadas arquitecturas de aplicaciones, sino configurar el modo de acceso de punto de conexión como `BASIC`. En la siguiente tabla se muestran algunas arquitecturas de aplicaciones y una recomendación para que la API de REST o el nombre de dominio personalizado puedan utilizar el modo de acceso de punto de conexión `STRICT`.
| Arquitectura | Migración sugerida |
| --- | --- |
| Uso de un punto de conexión de VPC para acceder a un nombre de dominio personalizado público. | Esta arquitectura utiliza tráfico de tipo cruzado entre puntos de conexión. Se recomienda que migre a [Nombres de dominio personalizados para API privadas en API Gateway](apigateway-private-custom-domains.md). |
| Uso de cualquier método para invocar una API privada que no utilice un nombre de dominio personalizado o nombres de DNS privados. | Esta arquitectura crea una discordancia entre el encabezado del host y el SNI utilizado en el establecimiento de comunicación de TLS y no supera las restricciones de domain fronting de CloudFront. Le recomendamos que migre la VPC para usar un DNS privado. |
| Uso de la partición de dominios para distribuir contenido en varios dominios o subdominios. | Esta arquitectura crea una discordancia entre el encabezado del host y el SNI utilizado en el establecimiento de comunicación de TLS y no supera las restricciones de domain fronting de CloudFront. Le recomendamos utilizar `HTTP/2` y dejar de utilizar este antipatrón. |
A continuación, se incluyen consideraciones que se deben tener a la hora de utilizar el modo de acceso de punto de conexión:
+ Si el modo de acceso de punto de conexión de una API o un nombre de dominio es `STRICT`, no puede cambiar el tipo de punto de conexión. Para cambiar el tipo de punto de conexión, primero cambie el modo de acceso del punto de conexión a `BASIC`.
+ Tras cambiar el modo de acceso del punto de conexión de `BASIC` a `STRICT`, API Gateway tarda 15 minutos en aplicar el modo de acceso estricto del punto de conexión.
+ Al cambiar una política de seguridad de una política que comienza con `SecurityPolicy_` a una política heredada, debe desactivar el modo de acceso del punto de conexión a `""`.
## Consideraciones
A continuación, se muestran consideraciones sobre las políticas de seguridad para las API de REST en API Gateway:
+ Puede importar la política de seguridad en un archivo de definición de OpenAPI. Para obtener más información, consulte [x-amazon-apigateway-endpoint-access-modex-amazon-apigateway-security-policy](openapi-extensions-security-policy.md).
+ La API se puede asignar a un nombre de dominio personalizado con una política de seguridad diferente a la de la API. Al invocar ese nombre de dominio personalizado, API Gateway utiliza la política de seguridad de la API para negociar el establecimiento de comunicación TLS. Si desactiva el punto de conexión de la API predeterminado, esto podría afectar a la forma en que los intermediarios pueden invocar a la API.
+ Si cambia la política de seguridad, esta tardará unos 15 minutos en completarse. Puede supervisar el `apiStatus` de la API. A medida que la API se actualice, el `apiStatus` será `UPDATING` y cuando se complete será `AVAILABLE`. Si el estado de la API es `UPDATING`, puede seguir invocándola.
+ API Gateway admite políticas de seguridad en todas las API. Sin embargo, solo puede elegir una política de seguridad para las API de REST. API Gateway solo admite la política de seguridad `TLS_1_2` para las API HTTP o de WebSocket.
+ No puede actualizar la política de seguridad de una API de `TLS_1_0` a `TLS_1_2`.
+ Algunas políticas de seguridad admiten los conjuntos de cifrado ECDSA y RSA. Si utiliza este tipo de política con un nombre de dominio personalizado, los conjuntos de cifrado coinciden con el tipo de clave de certificado proporcionada por el cliente, ya sea RSA o ECDSA. Si utiliza este tipo de política con una API de REST, los conjuntos de cifrado coinciden con los conjuntos de cifrado compatibles con los tipos de certificados RSA.