# Políticas de segurança para APIs REST no API Gateway
Uma *política de segurança* é uma combinação predefinida da versão mínima do TLS e dos pacotes de criptografia oferecida pelo Amazon API Gateway. Quando seus clientes estabelecem um handshake do TLS para a API ou o nome do domínio personalizado, a política de segurança aplica a versão do TLS e o pacote de criptografia aceitos pelo API Gateway. As políticas de segurança protegem suas APIs e nomes de domínio personalizados contra problemas de segurança de rede, como violação e espionagem entre um cliente e o servidor.
O API Gateway aceita políticas de segurança legadas e políticas de segurança aprimoradas. `TLS_1_0` e `TLS_1_2` são políticas de segurança legadas. Use essas políticas de segurança para compatibilidade com versões anteriores. Qualquer política que comece com `SecurityPolicy_` é uma política de segurança aprimorada. Use essas políticas para workloads reguladas, governança avançada ou para usar criptografia pós-quântica. Ao usar uma política de segurança aprimorada, você também deve definir o modo de acesso ao endpoint para governança adicional. Para obter mais informações, consulte [Modo de acesso ao endpoint](#apigateway-security-policies-endpoint-access-mode).
## Como o API Gateway aplica políticas de segurança
O exemplo a seguir mostra como o API Gateway aplica políticas de segurança utilizando a política `SecurityPolicy_TLS13_1_3_2025_09` como exemplo.
A política de segurança `SecurityPolicy_TLS13_1_3_2025_09` aceita tráfego TLS 1.3 e rejeita tráfego TLS 1.2 e TLS 1.0. Para o tráfego TLS 1.3, a política de segurança aceita os seguintes pacotes de criptografia:
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`
O API Gateway não aceita nenhum outro pacote de criptografia. Por exemplo, a política de segurança rejeitaria qualquer tráfego TLS 1.3 que utilize o pacote de criptografia `AES128-SHA`. Para acessar mais informações sobre as versões de TLS e criptografias aceitas, consulte [Políticas de segurança aceitas](apigateway-security-policies-list.md).
Para monitorar quais protocolos TLS e criptografias os clientes usaram para acessar seu API Gateway, você pode usar as variáveis de contexto `$context.tlsVersion` e `$context.cipherSuite` em seus logs de acesso. Para obter mais informações, consulte [Monitorar APIs REST no API Gateway](rest-api-monitor.md).
## Modo de acesso ao endpoint
O modo de acesso ao endpoint é um parâmetro adicional que você deve especificar para qualquer API REST ou nome de domínio personalizado que use uma política de segurança aprimorada começando com `SecurityPolicy_`. Você faz isso ao criar seu recurso ou ao alterar a política de segurança de uma política legada para uma política aprimorada.
Quando o modo de acesso ao endpoint é definido como `STRICT`, todas as solicitações para sua API REST ou nome de domínio personalizado devem passar pelas seguintes verificações:
+ A solicitação deve ser originada do mesmo tipo de endpoint do API Gateway que seu recurso. Pode ser de um endpoint regional, otimizado para borda ou privado.
+ Se você usar um endpoint regional ou privado, o API Gateway usará a correspondência de host SNI. Se você utilizar um endpoint otimizado para borda, o API Gateway estará em conformidade com a proteção contra “domain fronting” do CloudFront. Para acessar mais informações, consulte [Domain fronting](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions).
Se alguma dessas condições não for atendida, o API Gateway rejeitará a solicitação. É recomendável utilizar o modo de acesso ao endpoint `STRICT` quando possível.
Para migrar uma API ou nome de domínio existente para usar o modo de acesso ao endpoint restrito, primeiro atualize sua política de segurança para uma política de segurança aprimorada e mantenha o modo de acesso ao endpoint definido como `BASIC`. Depois de validar seus logs de tráfego e acesso, defina o modo de acesso ao endpoint como `STRICT`. Quando você migra o modo de acesso ao endpoint de `STRICT` para`BASIC`, ele fica indisponível por cerca de 15 minutos à medida que as alterações se propagam.
Você não deve definir o modo de acesso ao endpoint como `STRICT` para determinadas arquiteturas de aplicações e, em vez disso, definir o modo de acesso ao endpoint como `BASIC`. A tabela a seguir mostra algumas arquiteturas de aplicações e uma recomendação para que sua API REST ou nome de domínio personalizado possa usar o modo de acesso ao endpoint `STRICT`.
| Arquitetura | Migração sugerida |
| --- | --- |
| Usar um endpoint da VPC para acessar um nome de domínio personalizado público. | Essa arquitetura utiliza tráfego do tipo entre endpoints. Recomendamos migrar para [Nomes de domínio personalizados para APIs privadas no API Gateway](apigateway-private-custom-domains.md). |
| Usar qualquer método para invocar uma API privada que não utilize um nome de domínio personalizado ou nomes DNS privados. | Essa arquitetura cria uma incompatibilidade entre o cabeçalho d host e o SNI utilizado no handshake TLS e não atende às restrições de “domain fronting” do CloudFront. Recomendamos que você migre sua VPC para utilizar o DNS privado. |
| Utilizar a fragmentação de domínio para distribuir conteúdo em vários domínios ou subdomínios. | Essa arquitetura cria uma incompatibilidade entre o cabeçalho d host e o SNI utilizado no handshake TLS e não atende às restrições de “domain fronting” do CloudFront. É recomendável que você utilize `HTTP/2` e migre para longe desse antipadrão. |
Veja a seguir algumas considerações sobre o uso do modo de acesso ao endpoint:
+ Se o modo de acesso ao endpoint de uma API ou nome de domínio for `STRICT`, você não poderá alterar o tipo de endpoint. Para alterar o tipo de endpoint, primeiro altere o modo de acesso ao endpoint para `BASIC`.
+ Depois de alterar o modo de acesso ao endpoint de `BASIC` para `STRICT`, há um atraso de 15 minutos para o API Gateway aplicar o modo de acesso restrito ao endpoint.
+ Ao alterar uma política de segurança de uma política que começa com `SecurityPolicy_` para uma política legada, você deve cancelar a definição do modo de acesso ao endpoint como `""`.
## Considerações
Veja a seguir algumas considerações sobre políticas de segurança para APIs REST no API Gateway:
+ Você pode importar a política de segurança em um arquivo de definição da OpenAPI. Para obter mais informações, consulte [x-amazon-apigateway-endpoint-access-modex-amazon-apigateway-security-policy](openapi-extensions-security-policy.md).
+ Sua API pode ser associada a um nome de domínio personalizado com uma política de segurança diferente da política da sua API. Quando você invoca esse nome de domínio personalizado, o API Gateway utiliza a política de segurança da API para negociar o handshake TLS. Se você desabilitar seu endpoint de API padrão, isso poderá afetar como os chamadores podem invocar sua API.
+ Se você alterar sua política de segurança, a atualização levará cerca de 15 minutos para ser concluída. É possível monitorar o `apiStatus` de sua API. No decorrer da atualização da sua API, o `apiStatus` será `UPDATING` e, quando o processo for concluído, será `AVAILABLE`. Quando o status da sua API é `UPDATING`, você ainda pode invocá-la.
+ O API Gateway aceita políticas de segurança em todas as APIs. No entanto, você só pode escolher uma política de segurança para as APIs REST. O API Gateway comporta apenas a política de segurança `TLS_1_2` para APIs HTTP ou de WebSocket.
+ Você não pode atualizar a política de segurança de uma API de `TLS_1_0` para `TLS_1_2`.
+ Algumas políticas de segurança comportam os pacotes de criptografia ECDSA e RSA. Se você usar esse tipo de política com um nome de domínio personalizado, os pacotes de criptografia corresponderão ao tipo de chave de certificado fornecido pelo cliente, RSA ou ECDSA. Se você usar esse tipo de política com uma API REST, os conjuntos de criptografia corresponderão aos pacotes aceitos com os tipos de certificados RSA.