O blog da AWS

Aprimorando a segurança de API com políticas de segurança TLS do Amazon API Gateway

Por Anton Aleksandrov, Prin. SSA, Serverless; Ben Kelly, Delivery Consultant e David Fowler, Principal EAE.

Aprimorando a segurança de API com políticas de segurança TLS do Amazon API Gateway

À medida que os frameworks de conformidade evoluem e os padrões criptográficos avançam, as organizações estão buscando controles adicionais para melhorar sua postura de segurança na nuvem. Um dos controles necessários é uma configuração TLS mais granular, por exemplo, quando requisitos regulatórios exigem a desativação de cifras mais antigas como CBC ou a imposição do TLS 1.3 como versão mínima.

Nesta publicação, você aprenderá como as novas políticas de segurança TLS aprimoradas do Amazon API Gateway ajudam você a atender padrões como PCI DSS, Open Banking e FIPS, ao mesmo tempo em que fortalecem como suas APIs lidam com a negociação TLS. Essa nova capacidade aumenta sua postura de segurança sem adicionar complexidade operacional e fornece uma maneira única e consistente de padronizar a configuração TLS em toda a sua infraestrutura do API Gateway.

Visão geral

Anteriormente, o API Gateway oferecia controle limitado sobre a configuração TLS, e apenas para nomes de domínio personalizados. Os endpoints padrão usavam políticas de segurança fixas, o que significava que você frequentemente tinha que introduzir infraestrutura adicional, como distribuições personalizadas do Amazon CloudFront, para atender aos requisitos de segurança ou conformidade da sua organização.

Com este lançamento, você pode configurar o comportamento TLS diretamente em todos os tipos de endpoint de REST API, incluindo Regional, edge-optimized e privado, e aplicar configurações TLS consistentes em suas APIs e seus nomes de domínio personalizados. Você pode escolher entre políticas de segurança aprimoradas predefinidas para impor as versões mínimas de TLS e conjuntos de cifras que suas cargas de trabalho exigem. Por exemplo, você pode impor TLS 1.3, usar TLS 1.2 reforçado sem cifras CBC, adotar conjuntos alinhados ao FIPS para cargas de trabalho governamentais ou se preparar para o futuro com políticas que incluem criptografia pós-quântica (PQC). As novas políticas de segurança fornecem controle mais refinado sem adicionar complexidade operacional, ajudando você a alinhar suas APIs com as expectativas de segurança e conformidade em evolução.

Compreendendo as políticas de segurança do API Gateway

Uma política de segurança no API Gateway é uma combinação predefinida de uma versão mínima de TLS e um conjunto curado de conjuntos de cifras. Quando um cliente se conecta à sua REST API ou nome de domínio personalizado, o API Gateway usa a política selecionada para determinar quais versões de protocolo e cifras ele aceitará durante o handshake TLS. Isso oferece uma maneira previsível e aplicável de controlar como os clientes estabelecem conexões criptografadas com suas APIs.

O API Gateway suporta duas categorias de políticas de segurança. Políticas legadas, como TLS_1_0 ou TLS_1_2, permanecem disponíveis para compatibilidade retroativa. Políticas aprimoradas, identificadas pelo prefixo SecurityPolicy_*, fornecem controles mais rigorosos e modernos para cargas de trabalho regulamentadas, governança avançada ou endurecimento criptográfico. Quando você usa uma política aprimorada, também deve especificar um modo de acesso ao endpoint, que adiciona validação adicional para como o tráfego alcança sua API, conforme descrito nas seções a seguir.

As políticas aprimoradas seguem padrões de nomenclatura consistentes que ajudam você a entender rapidamente o que cada política impõe. Por exemplo, para os tipos de endpoint REGIONAL e PRIVATE, o seguinte padrão se aplica:

SecurityPolicy_[TLS-Versions]_[Variant]_[YYYY-MM]

A partir desta estrutura, você pode identificar as versões mínimas de TLS suportadas, quaisquer variantes criptográficas especializadas (como FIPS, PFS ou PQ) e a data de lançamento da política. Por exemplo, SecurityPolicy_TLS13_1_3_2025_09 aceita apenas tráfego TLS 1.3, enquanto SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09 suporta TLS 1.2 como versão mais baixa e TLS 1.3 como versão mais alta de TLS com sigilo futuro e aprimoramentos pós-quânticos.

Cada política mapeia para uma combinação curada de cifras. Por exemplo, SecurityPolicy_TLS13_1_3_2025_09 aceita apenas três conjuntos de cifras TLS 1.3 (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 e TLS_CHACHA20_POLY1305_SHA256) e rejeita quaisquer outras versões de protocolo ou cifras. Para uma lista completa de políticas e cifras suportadas, e padrão de nomenclatura para o tipo de endpoint EDGE, consulte a documentação do API Gateway.

Como as políticas de segurança se aplicam a endpoints padrão e domínios personalizados

Você pode usar o API Gateway para anexar diferentes políticas de segurança ao seu endpoint de API padrão e nomes de domínio personalizados. Durante a negociação TLS, o API Gateway seleciona a política com base no valor de Indicação de Nome do Servidor (SNI) no handshake TLS do cliente, não no cabeçalho HTTP Host. Isso significa que a política depende do nome do host que o cliente usa ao iniciar o TLS.

Por exemplo, se um cliente se conecta diretamente ao seu endpoint padrão, como:

https://abcdef1234.execute-api.us-east-1.amazonaws.com

O API Gateway usa a política anexada ao endpoint padrão porque o valor SNI corresponde ao seu hostname.

Se o cliente se conectar através de um nome de domínio personalizado, como:

https://api.example.com

O API Gateway usa a política anexada a esse domínio personalizado. Neste caso, o valor SNI api.example.com determina qual política é aplicada.

Essa distinção é importante mesmo se você desabilitar seu endpoint padrão. A negociação TLS sempre ocorre antes que o API Gateway avalie as configurações do endpoint, portanto, a política de segurança do endpoint padrão ainda se aplica aos clientes que se conectam diretamente ao seu hostname. Para evitar comportamento inesperado do cliente, você deve manter a API e seu nome de domínio personalizado alinhados com a mesma política de segurança sempre que possível.

Compreendendo o modo de acesso ao endpoint

Quando você usa uma política de segurança aprimorada (SecurityPolicy_*), também deve especificar um modo de acesso ao endpoint. O modo de acesso ao endpoint define com que rigor o API Gateway valida o caminho de rede que uma solicitação percorre antes de alcançar sua API. Isso oferece uma camada adicional de governança e ajuda a prevenir tráfego não autorizado ou mal direcionado.

Você pode escolher entre dois modos:

  • O modo BASIC fornece o comportamento padrão do API Gateway. É o ponto de partida recomendado quando você migra uma API existente para uma política de segurança aprimorada. Os clientes podem continuar acessando sua API como fazem hoje, sem validação adicional.
  • O modo STRICT adiciona verificações de conformidade para garantir que as solicitações se originem do tipo de endpoint correto e que a negociação TLS esteja alinhada com sua configuração.

Quando você habilita o modo STRICT, o API Gateway executa validações adicionais, como:

  • Os valores SNI e do cabeçalho HTTP Host correspondem
  • A solicitação se origina do mesmo tipo de endpoint que sua API (Regional, edge-optimized ou privado)

Se alguma dessas validações falhar, o API Gateway rejeita a solicitação. STRICT é uma escolha viável quando você precisa de garantias de segurança mais fortes, como ao executar cargas de trabalho regulamentadas ou sensíveis. Consulte a documentação do API Gateway para detalhes adicionais.

Quando você muda de modo BASIC para STRICT, leva até 15 minutos para que a mudança se propague completamente. Sua API permanece disponível durante este período. Se o modo de acesso ao endpoint estiver definido como STRICT, você não pode alterar o tipo de endpoint até reverter o modo de volta para BASIC.

Aplicando políticas de segurança a APIs novas e existentes

Você pode aplicar uma política de segurança ao criar uma nova REST API ou nome de domínio personalizado, ou atualizar um recurso existente para usar uma das opções aprimoradas SecurityPolicy_*. Ao migrar APIs existentes, a abordagem recomendada é começar com o modo BASIC, validar o comportamento do cliente (valores SNI e cabeçalho HTTP Host correspondem, a solicitação se origina do mesmo tipo de endpoint que sua API) e, em seguida, mudar para o modo STRICT depois de confirmar a compatibilidade.

Os seguintes trechos de código ilustram como aplicar políticas de segurança a diferentes cenários:

Criar uma REST API com uma política de segurança e modo de acesso ao endpoint STRICT

Você pode anexar uma política de segurança diretamente durante a criação da API, eliminando a necessidade de infraestrutura extra apenas para controlar a negociação TLS.

aws apigateway create-rest-api \
  --name "your-private-api-name" \
  --endpoint-configuration '{"types":["PRIVATE"]}' \
  --security-policy "SecurityPolicy_TLS13_1_3_2025_09" \
  --endpoint-access-mode STRICT \
  --policy file://api-policy.json

Criar um nome de domínio personalizado com uma política de segurança e modo de acesso ao endpoint STRICT

Você também pode especificar a política de segurança ao criar um nome de domínio personalizado. O API Gateway aplica a política selecionada durante a negociação TLS com base no valor SNI que o cliente fornece.

aws apigateway create-domain-name \
  --domain-name api.example.com \
  --regional-certificate-arn arn:aws:acm:region:account-id:certificate/certificate-id \
  --endpoint-configuration '{"types":["REGIONAL"]}' \
  --security-policy SecurityPolicy_TLS13_1_3_2025_09 \
  --endpoint-access-mode STRICT

Atualizando REST API existente

Se você estiver migrando uma API existente, comece aplicando a política de segurança aprimorada com o modo BASIC. Depois de confirmar que seus clientes podem se conectar com o modo BASIC conforme esperado, prossiga para habilitar o modo STRICT.

1. Aplique a nova política com o modo BASIC

aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[
    {
         "op": "replace",
         "path": "/securityPolicy",
         "value": "SecurityPolicy_TLS13_1_3_2025_09"
    },
    {
         "op": "replace",
         "path": "/endpointAccessMode",
         "value": "BASIC"
     }
]'

Verifique se seus clientes podem consumir a API conforme esperado usando logs de acesso e métricas de desempenho no Amazon CloudWatch.

2. Habilite o modo STRICT após a validação

aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[
    {
        "op": "replace",
        "path": "/endpointAccessMode",
        "value": "STRICT"
     }
]'

Atualizando nome de domínio personalizado existente

Os nomes de domínio personalizados seguem a mesma abordagem de migração que as REST APIs.

1. Aplique a nova política com o modo BASIC e valide que os clientes podem se conectar com sucesso.

aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[
    {
        "op": "replace",
        "path": "/securityPolicy",
        "value": "SecurityPolicy_TLS13_1_3_2025_09"
    },
    {
        "op": "replace",
        "path": "/endpointAccessMode",
        "value": "BASIC"
     }
]'

2. Habilite o modo STRICT após a validação

aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[
    {
        "op": "replace",
        "path": "/endpointAccessMode",
        "value": "STRICT"
     }
]'

Depois de atualizar sua REST API ou configuração de domínio personalizado, reimplante sua API para que os estágios recebam as novas configurações. Quando você altera uma política de segurança, a atualização leva até 15 minutos para ser concluída. O status da API aparece como UPDATING enquanto a alteração se propaga e retorna para AVAILABLE quando concluída. Sua API permanece totalmente funcional durante todo este processo.

Revertendo o modo de acesso ao endpoint

Se você notar que os clientes estão falhando ao se conectar à sua API após aplicar o modo STRICT, você pode reverter o modo de acesso ao endpoint de volta para BASIC a qualquer momento. O trecho de código abaixo ilustra como fazer isso para uma REST API.

aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[
    {
      "op": "replace",
      "path": "/endpointAccessMode",
      "value": "BASIC"
    }
  ]'

Você pode usar a mesma abordagem para atualizar um nome de domínio personalizado.

Monitorando o uso de TLS e migrações de políticas

À medida que você adota políticas de segurança aprimoradas, é importante entender como os clientes negociam conexões criptografadas com sua API. O monitoramento ajuda você a verificar a prontidão do cliente, identificar consumidores legados que podem exigir atualizações e validar que o modo de acesso ao endpoint STRICT se comporta conforme esperado durante a implantação. Use as seguintes variáveis de logs de acesso do API Gateway para monitorar o uso de protocolo e cifra ao longo do tempo.

  • $context.tlsVersion – a versão TLS negociada
  • $context.cipherSuite – o conjunto de cifras selecionado durante o handshake

Você pode usar essas variáveis para confirmar que:

  • Os clientes estão usando a versão mínima de TLS esperada
  • Cifras baseadas em CBC não são mais usadas depois que você muda para uma política reforçada
  • Políticas alinhadas ao PQC e FIPS estão sendo exercidas pelos clientes apropriados

Os logs de acesso são especialmente úteis durante migrações, onde validar o comportamento real do cliente é um pré-requisito antes de habilitar o modo STRICT. Por exemplo, se você ainda observar clientes ativos negociando cifras TLS 1.0 ou TLS 1.2 CBC após aplicar uma política reforçada no modo BASIC, você pode identificar os clientes afetados e planejar a remediação antes de mudar para o modo STRICT.

Configurações de segurança preparadas para o futuro

Algumas das novas políticas combinam TLS 1.3 com criptografia pós-quântica (PQC) para ajudá-lo a se preparar para um futuro onde existam atores de ameaças com capacidade quântica. Com essas políticas, você pode começar a testar e adotar algoritmos resistentes a computação quântica sem redesenhar sua arquitetura de API.

À medida que os padrões evoluem e novos conjuntos de cifras são introduzidos, o modelo de política do API Gateway fornece um caminho claro para adicionar novas variantes, mantendo sua configuração simples e previsível.

Conclusão e próximos passos

As políticas de segurança TLS aprimoradas e o modo de acesso ao endpoint no Amazon API Gateway oferecem controle direto sobre como os clientes estabelecem conexões seguras com suas APIs. Você pode escolher as políticas que correspondem às suas necessidades de conformidade, como PCI DSS, FIPS, Open Banking, PQC, e usar o modo STRICT para controlar como o tráfego alcança seus endpoints e aplicar validações adicionais no nível do domínio, endurecendo ainda mais a segurança de suas APIs

Para começar:

  1. Revise a lista de políticas de segurança disponíveis na documentação do API Gateway.
  2. Identifique quais REST APIs e domínios exigem controles TLS mais fortes.
  3. Aplique uma política SecurityPolicy-* apropriada com o modo BASIC.
  4. Valide o comportamento do cliente usando logs de acesso e métricas do CloudWatch.
  5. Mude para o modo STRICT quando estiver pronto para impor proteção adicional no nível de conexão.

Para mais informações sobre a construção de arquiteturas Serverless, consulte ServerlessLand.com

Este conteúdo foi traduzido da publicação original do blog, que pode ser encontrado aqui.

Autores

Anton Aleksandrov, Prin. SSA, Serverless
Ben Kelly, Delivery Consultant
David Fowler, Principal EAE

Tradutores

Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/