AWS detalha arquitetura de referência para mTLS de dispositivo no CloudFront

A pergunta que abre qualquer discussão de segurança em app mobile é simples de fazer e difícil de responder: como garantir que quem fala com a API é mesmo o seu aplicativo, rodando naquele aparelho, e não um script ou um emulador? Um artigo publicado no blog da AWS Brasil, assinado por André Botelho, Eduardo Rodrigues e Edgar Costa Filho (Solutions Architects na AWS), descreve uma arquitetura de referência que responde a isso com autenticação mútua (mTLS) de dispositivo terminada no Amazon CloudFront.

O ponto de partida é um recurso do CloudFront que suporta mTLS no viewer, ou seja, a camada que fala diretamente com o dispositivo do usuário. Antes dele, montar essa autenticação mútua sem expor a origin para tráfego não confiável era bem mais trabalhoso. O artigo entrega, junto com a explicação, um laboratório completo em Terraform para reproduzir a arquitetura.

Três camadas que se reforçam

O desenho não se resume a emitir certificado por dispositivo. Ele combina três ideias que cobrem lacunas diferentes:

• Device binding: vincular uma identidade criptográfica ao aparelho, via certificado por dispositivo.
• Chave em hardware: o par de chaves nasce e vive dentro do enclave seguro do aparelho (Keystore no Android, Secure Enclave/Keychain no iOS), nunca é extraído pelo próprio app.
• Platform attestation: um veredito do fornecedor da plataforma (Play Integrity no Android, App Attest no iOS) de que o app é genuíno e o ambiente não foi adulterado.

Nenhuma das três sozinha resolve o problema. Um certificado prova só posse de uma chave; a attestation é uma foto do momento, não uma prova criptográfica contínua. É por isso que o artigo insiste num ponto fácil de pular: a attestation precisa estar vinculada ao mesmo CSR que vai virar certificado, e essa amarração precisa ser validada no servidor. Sem isso, a garantia de que a chave nunca saiu do hardware é afirmação do cliente, não fato verificado.

Enrollment: a rota sem mTLS que mais precisa de atenção

No enrollment, o dispositivo ainda não tem certificado, então essa rota (/enroll no exemplo) não pode exigir mTLS. Ela fica protegida por attestation, o que a torna, segundo o próprio artigo, a maior superfície de ataque da solução: é onde a identidade nasce.

O laboratório deixa isso explícito como limitação didática. O Lambda de enrollment aceita qualquer token de attestation não vazio (um stub), e o user_id chega no corpo da requisição sem nenhuma prova de identidade. Para produção, os autores são diretos: trate o enrollment como um endpoint de emissão de credenciais, não como uma API comum. Isso significa autenticação forte do usuário antes de vincular o device, rate limiting e AWS WAF na frente, e um limite de dispositivos por usuário com idempotência no device_id.

Por que terminar o mTLS no CloudFront

Com o viewer mTLS configurado, o CloudFront valida o certificado do device contra um trust store (o bundle da CA) já no handshake, na borda. Isso traz três vantagens que o artigo detalha: corte antes de o tráfego entrar no perímetro, capacidade de absorver picos e ataques distribuídos de negação de serviço, e separação de responsabilidade, já que a origem (ALB, Lambda) nem chega a ver o handshake do device.

A identidade chega à origem via headers, como CloudFront-Viewer-Cert-Serial-Number. Aqui mora uma pegadinha operacional citada no artigo: esse valor vem em hexadecimal separado por dois-pontos, e a origem, a borda e o CloudFront KeyValueStore (KVS) precisam normalizar esse serial para a mesma forma canônica antes de comparar. Divergência de normalização entre os três pontos é, segundo os autores, uma das causas mais comuns de falso negativo na revogação.

O viewer mTLS é configurado por distribuição, não por rota. Como /enroll não pode exigir certificado, a arquitetura de exemplo usa duas distribuições CloudFront apontando para o mesmo Application Load Balancer interno via VPC origin: uma sem mTLS para enrollment, outra com mTLS Required para o data plane. Vale lembrar um pré-requisito que passa despercebido: o viewer mTLS exige HTTP/2 e não funciona em HTTP/3, algo que só vira problema se alguém habilitar HTTP/3 na distribuição de API.

Validade curta, recert como caminho crítico

O artigo trata a validade do certificado como um trade-off, não como "quanto menor, melhor". Certificado de vida curta reduz a janela de exposição, mas cobra disponibilidade: se a renovação falhar (rede instável, backend fora, erro no cliente), o dispositivo simplesmente para de passar no handshake.

Em resumo: o laboratório usa certificados de 7 dias emitidos pela AWS Private CA em modo short-lived, valor didático pensado para rotação frequente a custo por certificado menor. Em produção, essa calibragem depende do apetite de risco e da confiabilidade do pipeline de renovação, não de um número fixo copiado do artigo.

O recert acontece de forma silenciosa, entre 50% e 70% da vida do certificado, reaproveitando a mesma chave de hardware: só o certificado muda, a chave nunca é regerada. Como boas práticas, os autores recomendam grace period considerando clock skew, idempotência/retry para tolerar falha de rede móvel, fallback para /enroll quando o certificado expira (com idempotência segura por device_id, autorizada pela autenticação do usuário, não pelo próprio device_id) e re-attestation periódica embutida no corpo do /renew, sem precisar de rota própria.

Revogação em três camadas, três velocidades

Para cortar um dispositivo antes da hora (roubo, chave comprometida, fraude), a arquitetura combina três mecanismos que atuam em pontos e velocidades diferentes:

O artigo faz um esclarecimento útil sobre documentação: certificados short-lived podem ser implantados sem mecanismo de revogação, o que não é o mesmo que dizer que não o suportam. No laboratório, OCSP está habilitado (ocsp_configuration { enabled = true }), mas é tratado como opcional na arquitetura real, por dois motivos que pesam em produção: ele entra no caminho crítico do handshake (responder inalcançável ou resposta Unknown/Error leva o CloudFront a negar a conexão por padrão) e trafega em HTTP não criptografado, expondo à CA qual certificado está sendo consultado e quando.

Um limite físico vale registrar: o KVS tem teto de 5 MB e não expira chaves sozinho. Como os certificados são de vida curta, a denylist tende a ficar pequena (um serial revogado só é útil até a data em que o certificado expiraria de qualquer forma), mas o artigo recomenda uma rotina agendada para remover seriais já expirados.

O que falta para produção

O próprio material é explícito sobre o que é demonstração e o que é decisão de produção. Três pontos concentram o risco: o enrollment sem autenticação forte de usuário, o stub de attestation que aceita qualquer token não vazio e a checagem de status por Lambda a cada request na origem, que os autores sugerem mover para uma camada de autorização dedicada (Amazon API Gateway com Lambda authorizer, Envoy/Istio via ext_authz, ou um gateway com Open Policy Agent), cacheando a decisão ou codificando o estado num JWT de vida curta.

Vale notar também o alcance real da revogação pelo KVS: ela vale para novos handshakes. Uma conexão TLS já estabelecida não é derrubada, porque o certificado é checado no handshake, não a cada request; quem cobre essa janela é o DynamoDB na origem, e encerrar sessões em curso é responsabilidade da aplicação. Para quem avalia essa arquitetura, o código Terraform e os scripts de teste publicados no artigo são o ponto de partida mais direto: subir o laboratório antes de decidir o que entra na versão de produção.

Fonte: AWS Brasil — Blog