Segurança em API Gateway: autenticação, logs, throttling e proteção de APIs
O API Gateway é a porta das suas APIs. Veja como autenticar, limitar e observar sem deixar endpoints abertos.
O API Gateway expõe APIs ao mundo, o que o coloca na linha de frente. Os problemas mais comuns são endpoints sem autenticação adequada, ausência de limites de taxa que permite abuso, e falta de logs que cega tanto a detecção quanto a investigação. Como o Gateway costuma estar na frente de funções Lambda e serviços internos, uma falha aqui expõe tudo o que está atrás.
Antes de configurar controles, vale entender que existem dois tipos principais no API Gateway, com recursos de segurança diferentes. As REST APIs oferecem authorizers, API keys, usage plans, resource policies, mTLS e integração direta com o AWS WAF. As HTTP APIs são mais simples e baratas, com authorizers JWT e Lambda nativos, mas sem alguns controles das REST APIs. Escolher o tipo certo já é parte da decisão de segurança, e cada rota precisa de uma decisão de autenticação explícita, seja qual for o tipo.
Este guia trata da segurança do API Gateway de forma defensiva: autenticação por authorizers, controle de taxa, restrição por resource policy, integração com WAF, configuração de CORS e observabilidade. O objetivo é que cada endpoint exposto seja autenticado, limitado e auditável.
Autenticação e authorizers
Cada rota exposta precisa de uma decisão de autenticação explícita. O API Gateway suporta vários mecanismos, e a escolha depende de quem chama a API. Para acesso entre serviços da AWS, a autorização IAM assina a requisição com credenciais temporárias. Para usuários finais, um authorizer JWT valida tokens emitidos por um provedor de identidade, e um authorizer Lambda permite lógica de autorização personalizada quando as opções nativas não bastam. Evite o padrão perigoso de deixar rotas abertas por descuido, especialmente em APIs que cresceram organicamente e acumularam endpoints esquecidos.
O authorizer valida a requisição antes que ela chegue ao backend, o que reduz carga indevida e concentra a decisão de identidade em um ponto. Um authorizer Lambda pode cachear a resposta por um tempo para não ser chamado a cada requisição, o que melhora latência, mas exige atenção ao definir a chave de cache: cachear pela identidade errada pode conceder acesso indevido. Valide sempre a assinatura, o emissor, a audiência e a expiração do token, não apenas a presença dele.
API keys não são autenticação
API keys servem para identificar e cotar consumidores por meio de usage plans, mas não são autenticação por si só, porque uma chave vazada concede acesso. Use API keys junto de autenticação real, nunca no lugar dela. A autorização por recurso, ou seja, se aquele usuário pode acessar aquele objeto específico, precisa acontecer no backend para cada requisição, porque o Gateway não conhece a lógica de propriedade dos seus dados.
Resource policy e APIs privadas
Além do authorizer, uma REST API aceita uma resource policy que decide, antes de tudo, quem pode sequer invocar a API, com base em condições como origem de rede, conta de origem ou VPC endpoint. É uma camada útil para restringir uma API a uma faixa de IPs confiáveis ou a uma VPC específica, reduzindo a exposição na internet aberta. Quando a API só precisa ser consumida internamente, considere uma API privada, acessível apenas por um VPC endpoint, em vez de deixá-la pública com controles por cima.
{
"Effect": "Deny",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:REGIAO:CONTA:API_ID/*",
"Condition": {
"NotIpAddress": { "aws:SourceIp": ["203.0.113.0/24"] }
}
}Trate a resource policy como filtro de exposição, não como substituto da autenticação. Ela reduz quem alcança a API, mas quem passa por ela ainda precisa ser autenticado e autorizado. Restrição por IP é frágil quando o público é amplo ou móvel, então ela cabe melhor em APIs internas, de parceiros conhecidos ou de administração.
Throttling, WAF, CORS e mTLS
Configure throttling para limitar a taxa de requisições e proteger o backend contra abuso e picos. O API Gateway aplica limites em vários níveis: um teto por conta e região, limites por estágio e por método, e limites por consumidor via usage plan, com burst e taxa média. Defina limites por consumidor para que um único cliente mal comportado não degrade a API para todos, e mantenha o teto de estágio como rede de segurança geral.
Combine o throttling com um WAF na frente para mitigar ataques web e padrões maliciosos. O AWS WAF associa Web ACLs diretamente a REST APIs regionais e, para HTTP APIs, a proteção equivalente costuma vir de um CloudFront com WAF na borda. A configuração de CORS merece atenção: um CORS permissivo, liberando qualquer origem, pode expor a API a uso indevido a partir de páginas de terceiros. Restrinja a origem, os métodos e os cabeçalhos ao que a aplicação realmente usa.
Access-Control-Allow-Origin: https://app.seu-dominio
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600Para integrações entre parceiros que exigem garantia de identidade do cliente, o mTLS em domínio personalizado obriga cada cliente a apresentar um certificado válido, o que barra chamadas de clientes não credenciados antes mesmo do authorizer. É um controle forte para APIs de máquina a máquina, ao custo de gerenciar a autoridade certificadora e a lista de confiança.
- Exigir autenticação em toda rota exposta, sem rota aberta por descuido
- Usar authorizers para validar antes do backend, com verificação de emissor, audiência e expiração
- Tratar API key como identificação por usage plan, não como autenticação
- Restringir a exposição com resource policy ou API privada quando possível
- Configurar throttling por estágio e por consumidor para conter abuso e picos
- Colocar WAF na frente para mitigar ataques web
- Definir CORS restrito, sem liberar qualquer origem
- Avaliar mTLS em integrações máquina a máquina de parceiros
Logs, observabilidade e detecção
Habilite logs de acesso e de execução e exporte métricas. Sem logs, abuso de endpoint e tentativas de exploração passam invisíveis, e a investigação fica sem base. O log de acesso é personalizável por meio das variáveis de contexto, então registre o que importa para investigar: identificador da requisição, origem, rota, status e o resultado do authorizer. Evite registrar corpo de requisição, tokens ou dados sensíveis, para que o próprio log não vire um vazamento.
{
"requestId": "$context.requestId",
"ip": "$context.identity.sourceIp",
"requestTime": "$context.requestTime",
"httpMethod": "$context.httpMethod",
"routeKey": "$context.routeKey",
"status": "$context.status",
"authorizerError": "$context.authorizer.error"
}Sinais que merecem alerta
A cobertura de log só vira detecção quando alguns padrões disparam alerta. Monitore rajadas de erros de autorização, que indicam tentativas de acesso indevido ou credencial vazada em teste, picos de throttling, que sugerem abuso ou ataque, e endpoints com volume anômalo fora do horário esperado. Defina o estágio de produção com configurações mais restritas do que ambientes de desenvolvimento, e trate a habilitação repentina de um estágio de teste exposto como algo a revisar.
Checklist prático
- Escolher o tipo de API (REST ou HTTP) conforme os controles necessários
- Exigir autenticação explícita em toda rota exposta
- Usar authorizers (IAM, JWT ou Lambda) validando emissor, audiência e expiração
- Garantir autorização por recurso no backend
- Tratar API keys como identificação em usage plan, não autenticação
- Restringir exposição com resource policy ou API privada quando aplicável
- Configurar throttling por estágio e por consumidor
- Colocar WAF na frente da API
- Definir CORS restrito a origens conhecidas
- Avaliar mTLS em integrações máquina a máquina de parceiros
- Habilitar logs de acesso e de execução sem registrar dados sensíveis
- Monitorar erros de autorização, throttling e volume anômalo
- Restringir mais o estágio de produção que o de desenvolvimento
Boas práticas
- Autentique e autorize em camadas, no Gateway e no backend
- Use resource policy e APIs privadas para reduzir exposição na internet aberta
- Aplique throttling por consumidor para isolar o cliente que abusa
- Combine WAF e Gateway para defesa de borda
- Mantenha CORS restrito e revisado
- Observe a API com logs e métricas desde o início, sem registrar segredos
- Elimine endpoints e estágios esquecidos e sem dono
Erros comuns
Rota exposta sem autenticação por descuido
Acesso direto ao backend sem qualquer barreira.
Tratar API key como autenticação
Uma chave vazada concede acesso sem segundo controle.
CORS liberando qualquer origem
Páginas de terceiros podem usar a API em nome do usuário.
Sem throttling por consumidor
Um único cliente abusivo sobrecarrega o backend e eleva custo para todos.
Estágio de teste exposto com controles frouxos
Uma porta secundária dá acesso à mesma integração de produção.
API sem logs ou com token registrado no log
Ou a exploração passa invisível, ou o próprio log vira vazamento.
Quando procurar apoio especializado
Revisar autenticação, autorização e exposição de APIs é parte dos serviços de Pentest e de Segurança de Aplicações da GUARDIASEC, que avaliam APIs e endpoints com foco em risco real e evidência.
Perguntas frequentes
API key é suficiente para proteger minha API?
Não. A API key serve para identificar e cotar consumidores por meio de usage plans, mas não é autenticação robusta: uma chave vazada concede acesso direto. Ela deve ser usada junto de autenticação real, como authorizers IAM, JWT ou Lambda, e a autorização por recurso precisa acontecer no backend. Depender só de API key deixa a API vulnerável.
Onde devo validar a autorização, no Gateway ou no backend?
Em ambos, em camadas. O Gateway valida a autenticação cedo, com authorizers, reduzindo carga indevida no backend. Mas a autorização por recurso, ou seja, se aquele usuário pode acessar aquele objeto, precisa acontecer no backend a cada requisição. Confiar apenas no Gateway costuma deixar brechas de autorização em nível de objeto.
Qual a diferença entre REST API e HTTP API no controle de segurança?
A REST API oferece mais controles nativos: API keys com usage plans, resource policies, integração direta com o AWS WAF, mTLS e validação de requisição. A HTTP API é mais simples e barata, com authorizers JWT e Lambda nativos, porém sem alguns desses recursos. Para HTTP APIs, a proteção de WAF costuma vir de um CloudFront na frente. Escolha o tipo pela necessidade real de controle, não só por custo.
Por que CORS é uma preocupação de segurança?
Um CORS permissivo que libera qualquer origem permite que páginas de terceiros façam requisições à sua API a partir do navegador do usuário, o que pode ser explorado para uso indevido. O recomendado é restringir as origens permitidas às que você controla e ter cuidado redobrado ao permitir credenciais. CORS frouxo é uma exposição comum e subestimada.
Throttling protege contra ataques?
Throttling limita a taxa de requisições, o que mitiga abuso, força bruta e picos que sobrecarregariam o backend. Não é uma defesa completa por si só, mas é uma camada importante, especialmente combinada com WAF e autenticação. Defina limites por consumidor, além do teto de estágio, para que um cliente abusivo não degrade a API para os demais.
Como restrinjo o acesso a uma API interna sem deixá-la pública?
Duas abordagens se complementam. Uma resource policy pode negar invocação fora de uma faixa de IPs ou de uma VPC específica. Para isolamento maior, uma API privada só é acessível por um VPC endpoint, sem exposição na internet. Escolha conforme o público: parceiros externos conhecidos combinam com resource policy por IP, e consumo apenas interno combina com API privada.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.