Implementando HSTS em Serviços AWS: Uma Estratégia de Segurança Unificada para Arquiteturas em Nuvem

O Desafio da Segurança Distribuída em Arquiteturas AWS

Aplicações web modernas construídas na AWS frequentemente combinam múltiplos serviços para oferecer soluções escaláveis e performáticas. Porém, essa arquitetura distribuída apresenta um desafio significativo: implementar uma estratégia coerente de segurança em camada de transporte entre todos esses componentes.

O principal obstáculo é que diferentes serviços AWS exigem abordagens distintas para configuração de HTTP Strict Transport Security (HSTS). Quando uma aplicação utiliza API Gateway para APIs, CloudFront para distribuição de conteúdo e Application Load Balancers para tráfego web, a ausência de políticas HSTS unificadas resulta em postura de segurança inconsistente. Ferramentas de auditoria de segurança frequentemente identificam headers HSTS faltantes, mas as orientações para remediar o problema estão dispersas em documentações específicas de cada serviço, criando lacunas de conformidade.

Entendendo HSTS e Seus Benefícios de Segurança

HTTP Strict Transport Security é um mecanismo de política de segurança web que protege websites contra ataques de rebaixamento de protocolo e roubo de cookies. Quando um servidor web declara política HSTS através do header Strict-Transport-Security, navegadores compatíveis convertem automaticamente solicitações HTTP para HTTPS para o domínio especificado.

Por Que HSTS Importa Além de Redirecionamentos HTTP→HTTPS

A maioria dos servidores web já implementa redirecionamento de HTTP para HTTPS. Porém, essa abordagem deixa uma janela de vulnerabilidade durante a primeira solicitação do navegador:

Usuário digita exemplo.com.br no navegador
Navegador envia requisição HTTP para http://exemplo.com.br
Servidor responde com redirecionamento 301/302 para https://exemplo.com.br
Navegador segue o redirecionamento e estabelece conexão HTTPS

A solicitação HTTP inicial (etapa 2) cria uma oportunidade para ataques. Uma parte não autorizada posicionada entre o usuário e a infraestrutura pode interceptar essa requisição e responder com conteúdo aparentemente legítimo mantendo uma conexão não segura. Essa técnica, conhecida como SSL stripping, pode ocorrer mesmo quando sua infraestrutura AWS está corretamente configurada com redirecionamentos HTTPS.

HSTS resolve essa vulnerabilidade movendo a imposição de segurança para o nível do navegador. Após receber uma política HSTS, o navegador converte automaticamente requisições HTTP para HTTPS antes de enviá-las pela rede:

Usuário digita exemplo.com.br no navegador
Navegador converte automaticamente para HTTPS graças à política HSTS armazenada
Navegador envia requisição HTTPS diretamente para https://exemplo.com.br
Nenhuma requisição HTTP inicial elimina a oportunidade de interceptação

Essa imposição no nível do navegador fornece proteção que complementa as configurações de segurança da infraestrutura AWS, criando defesa em profundidade contra problemas de rebaixamento de protocolo. HSTS também ajuda a prevenir acesso não autorizado a sessões, protegendo contra roubo de credenciais.

Casos de Uso Principais para HSTS

HSTS protege cenários que redirecionamentos HTTP simples não cobrem. Por exemplo, quando sistemas legados servem conteúdo misto, ou quando fluxos de SSO redirecionam usuários entre provedores, HSTS mantém as conexões criptografadas ao longo de todo o processo.

Em arquiteturas de microsserviços usando API Gateway com comunicação entre serviços, HSTS protege endpoints de API contra rebaixamento de protocolo durante conexões iniciais de clientes. Aplicações com CloudFront e múltiplos servidores de origem também se beneficiam, pois HSTS previne que navegadores façam fallback para HTTP durante cenários de failover.

Configurando HSTS no Amazon API Gateway

O Amazon API Gateway oferece múltiplas formas para adicionar headers HSTS em respostas de API.

HTTP APIs com Parameter Mapping

Para HTTP APIs, é possível configurar mapeamento de parâmetros de resposta para definir headers HSTS quando invocado via endpoint padrão ou domínio customizado:

Navegue até a configuração de rota da sua HTTP API no console do API Gateway
Acesse as configurações de integração na aba “Manage integrations”
Na seção de Response, insira 200 como código de status
Selecione “Append” como tipo de modificação
Em “Parameter to modify”, digite header.Strict-Transport-Security
Em Value, insira max-age=31536000; includeSubDomains; preload

REST APIs com Proxy e Non-Proxy Integration

REST APIs no API Gateway oferecem controle mais granular sobre implementação de HSTS através de padrões de integração proxy e non-proxy.

Para integrações proxy (como AWS Lambda), o serviço backend assume responsabilidade por gerar headers HSTS. Exemplo com Lambda:

import json

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'headers': {
            'Strict-Transport-Security': 'max-age=31536000; includeSubDomains; preload'
        },
        'body': json.dumps('Resposta segura com headers HSTS')
    }

Para integrações non-proxy, os headers HSTS devem ser retornados pelo API Gateway através de templates de mapeamento ou resposta de método. Usando templates de mapeamento com Velocity Template Language (VTL), é possível configurar geração dinâmica de headers:

$input.json("$")
#set($newValue = "$input.params().header.get('Host')")
#set($context.responseOverride.header.Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload")

Alternativamente, a aba “Method response” oferece configuração declarativa mapeando explicitamente o header strict-transport-security, seguido da aba “Integration response” onde você mapeia o valor como max-age=31536000; includeSubDomains; preload.

Para validar a implementação, utilize:

curl -i https://seu-api-gateway-url.execute-api.regiao.amazonaws.com/stage/recurso

A resposta esperada deve incluir:

strict-transport-security: max-age=31536000; includeSubDomains; preload

Implementando HSTS com Application Load Balancer

Os Application Load Balancers agora oferecem suporte integrado para modificação de headers de resposta HTTP, incluindo headers HSTS. Isso permite impor políticas de segurança consistentes em todos os seus serviços a partir de um único ponto, reduzindo esforço de desenvolvimento e garantindo proteção uniforme independentemente das tecnologias backend utilizadas.

Pré-requisitos e Configuração Inicial

Antes de implementar HSTS com load balancers, verifique se sua infraestrutura atende aos requisitos:

Listener HTTPS funcional corretamente configurado
Certificados TLS válidos na AWS Certificate Manager
Recurso de modificação de headers habilitado para o listener (desabilitado por padrão)

Ativando Modificação de Headers de Resposta

Application Load Balancers suportam injeção direta de headers HSTS através do recurso de modificação de headers de resposta, fornecendo imposição centralizada de políticas de segurança sem necessidade de configuração em aplicações individuais.

Abra o console Amazon EC2 e navegue até Load Balancers
Selecione seu Application Load Balancer
Na aba “Listeners and rules”, selecione o listener HTTPS
Na aba “Attributes”, escolha “Edit”
Expanda a seção “Add response headers”
Selecione “Add HTTP Strict Transport Security (HSTS) header”
Configure o valor do header como max-age=31536000; includeSubDomains; preload
Clique em “Save changes”

Quando a modificação de headers é habilitada no ALB, a aplicação automática segue padrão consistente: se a resposta do backend não incluir o header especificado, o ALB o adiciona com o valor configurado; se a resposta já o contiver, o ALB substitui o valor existente pelo configurado. Isso garante imposição de política consistente em todas as respostas através do load balancer.

Para validar:

curl -I https://seu-loadbalancer-xxxx.us-west-2.elb.amazonaws.com

Resposta esperada:

strict-transport-security: max-age=31536000; includeSubDomains; preload

Configurando HSTS no Amazon CloudFront

O Amazon CloudFront oferece suporte integrado para headers de segurança HTTP, incluindo HSTS, através de políticas de headers de resposta. Esse recurso possibilita gerenciamento centralizado de headers de segurança na borda da CDN, garantindo imposição consistente de política em conteúdo cacheado e não-cacheado.

Criando Política de Headers de Resposta

É possível utilizar o recurso de política de headers de resposta do CloudFront para configurar headers de segurança automaticamente adicionados às respostas servidas por sua distribuição. O CloudFront oferece políticas de headers de resposta gerenciadas com valores pré-definidos para headers de segurança HTTP mais comuns, ou você pode criar uma política customizada.

No console CloudFront, navegue até “Policies” e depois “Response headers”
Escolha “Create response headers policy”
Configure as definições:
- Name: HSTS-Security-Policy
- Description: HSTS e headers de segurança para aplicações web
Sob “Security headers”, configure:
- Strict Transport Security: ative e defina Max age como 31.536.000 segundos (1 ano)
- Preload: ative (opcional)
- IncludeSubDomains: ative (opcional)
Adicione headers de segurança adicionais:
- X-Content-Type-Options
- X-Frame-Options: selecione “SAMEORIGIN”
- Referrer-Policy: selecione “strict-origin-when-cross-origin”
- X-XSS-Protection: ative com “Block” selecionado
Clique em “Create”

Anexando a Política à Distribuição

Navegue até sua distribuição CloudFront
Selecione a aba “Behaviors”
Edite o comportamento padrão (ou crie um novo)
Sob “Response headers policy”, selecione a política criada
Clique em “Save changes”

Para validar:

curl -I https://seu-dominio-cloudfront.cloudfront.net

Resposta esperada:

strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
x-xss-protection: 1; mode=block
x-cache: Hit from cloudfront

Considerações de Segurança e Boas Práticas

Configuração de Max-Age

A diretiva max-age determina por quanto tempo navegadores aplicarão política HTTPS-only. As recomendações de duração são:

300 segundos (5 minutos): Seguro para experiências durante fase de teste inicial
86.400 segundos (1 dia): Compromisso de curto prazo, como ambientes de desenvolvimento
2.592.000 segundos (30 dias): Validação de médio prazo, como ambientes staging
31.536.000 segundos (1 ano): Compromisso de longo prazo, como ambientes produção

Recomenda-se começar com valores menores de max-age durante implementação inicial e aumentá-los gradualmente conforme você ganha confiança na estabilidade da infraestrutura HTTPS.

Diretiva includeSubDomains

A diretiva includeSubDomains estende imposição HSTS a todos os subdomínios. Oferece proteção abrangente em toda hierarquia de domínio e previne ataques baseados em subdomínios, porém requer que todos os subdomínios suportem HTTPS com certificados SSL válidos e mantenham política de segurança consistente na hierarquia de domínio.

Preload para Máxima Cobertura

Considerar implementar HSTS preload para cobertura máxima de segurança:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Preload fornece proteção para visitantes pela primeira vez através de imposição no nível do navegador antes de requisições de rede, mas requer submissão a listas de preload do navegador e é difícil de reverter, exigindo compromisso de longo prazo com infraestrutura HTTPS.

Fonte

Implementing HTTP Strict Transport Security (HSTS) across AWS services (https://aws.amazon.com/blogs/security/implementing-http-strict-transport-security-hsts-across-aws-services/)