ADR: Substituindo SMS OTP por Autenticação Silenciosa no Cognito

O sistema em análise é uma plataforma CIAM financeira com ~4 milhões de usuários ativos mensais, operando em múltiplos países da América Latina. O fluxo de autenticação atual usa Amazon Cognito com SMS OTP via SNS para verificação de segundo fator. O custo mensal com SMS gira em torno de $18.000–$22.000, dos quais estimamos que 8–12% são originados por tráfego artificialmente inflado (AIT) — um número conservador baseado em análise de logs do SNS e padrões de destino.

As forças que motivaram esta revisão são concretas:

Pressão de segurança: O time de fraude identificou três incidentes de SIM swap bem-sucedidos nos últimos seis meses, todos resultando em account takeover completo. Em todos os casos, o SMS OTP foi entregue ao atacante porque o swap já havia ocorrido antes da tentativa de autenticação. Bancos de dados estáticos de lookup de número não detectaram nenhum dos três eventos.

Pressão de conversão: A taxa de conclusão do fluxo de login mobile está em 78,3% — abaixo da média do setor de 80%. Cada ponto percentual de conversão representa aproximadamente $340.000 em receita anual para este produto específico.

Pressão regulatória: A LGPD e as diretrizes do Banco Central para Open Finance exigem que mecanismos de autenticação sejam robustos contra ataques conhecidos. SS7 é um ataque conhecido e documentado. Manter SMS como único segundo fator começa a ser questionável do ponto de vista de compliance.

Pressão de custo de suporte: O helpdesk processa aproximadamente 12.000 tickets mensais relacionados a OTP não recebido ou expirado — um custo operacional que não aparece no dashboard de segurança mas é real.

A distinção técnica mais importante nesta decisão não é sobre UX — é sobre a camada de onde o sinal de identidade é derivado. Ferramentas tradicionais de verificação de identidade operam sobre dados agregados, cacheados ou comportamentais. Um serviço de lookup de número de telefone consulta um banco de dados estático que pode ter dias ou semanas de defasagem. Device fingerprinting analisa características do browser que podem ser falsificadas. Biometria comportamental constrói modelos a partir de sessões históricas — útil, mas um indicador defasado por definição.

O que diferencia a abordagem de rede móvel é a camada de origem do sinal: dados em tempo real diretamente dos operadores de rede móvel (MNOs). Quando você consulta se um SIM foi trocado recentemente, você está consultando a rede que executou o swap. Quando a Silent Authentication verifica um usuário, a prova de posse é a própria sessão de dados celulares — algo que não pode ser phished, interceptado ou engenheirado socialmente porque não existe como um segredo transmissível.

Para cenários de fraude financeira onde SIM swaps são usados para account takeover, 'recentemente' significa minutos ou horas, não dias. Bancos de dados estáticos atualizados semanalmente não detectam esses eventos — eles os registram após o fato. Consultas em tempo real ao operador fecham essa janela completamente.

Essa diferença de camada tem uma implicação arquitetural direta: os controles de Identity Insights (sim_swap, device_swap, subscriber_match, recycled_number, format/network_type) precisam ser executados antes de qualquer canal de verificação ser iniciado. Isso muda o ponto de decisão de risco do pós-desafio para o pré-desafio — o que, em termos de custo, significa que tentativas fraudulentas são bloqueadas antes de um único SMS ser enviado, antes de custos de verificação serem incorridos.

A decisão é adotar a Opção C como fluxo primário para autenticação mobile, com a Opção B como camada opt-in para usuários de alto valor e a Opção D como roadmap de 18 meses. O mecanismo técnico central é o fluxo CUSTOM_AUTH do Amazon Cognito, que expõe três pontos de extensão via Lambda triggers: DefineAuthChallenge, CreateAuthChallenge e VerifyAuthChallengeResponse.

O que torna o CUSTOM_AUTH adequado aqui não é apenas a flexibilidade — é a semântica correta. O fluxo foi projetado para desafios de autenticação externos, e a Silent Authentication é exatamente isso: um desafio resolvido por um terceiro (o MNO via Vonage) em vez de pelo usuário diretamente. O Cognito gerencia o ciclo de vida da sessão, emite tokens JWT com os claims corretos e mantém o audit trail — enquanto a lógica de verificação vive nos Lambdas.

Configuração crítica dos Lambdas: O CreateAuthChallenge Lambda é onde a chamada à API de Identity Insights da Vonage acontece. Este Lambda deve ter um timeout configurado para no mínimo 10 segundos (o padrão de 3s é insuficiente), usar uma VPC com NAT Gateway para chamadas de saída se a política de segurança exigir, e armazenar as credenciais da API Vonage no AWS Secrets Manager com rotação automática habilitada — nunca em variáveis de ambiente. O VerifyAuthChallengeResponse Lambda recebe o resultado da Silent Authentication e deve implementar idempotência via DynamoDB com TTL de 5 minutos para evitar replay attacks no token de verificação.

IAM e isolamento: Cada Lambda trigger deve ter uma role IAM separada com permissões mínimas. O CreateAuthChallenge precisa de secretsmanager:GetSecretValue escoped ao ARN específico do segredo Vonage. Nenhum dos triggers deve ter permissões de escrita no User Pool — apenas cognito-idp:RespondToAuthChallenge via o SDK do Cognito chamado pelo cliente.

Adotar o fluxo CUSTOM_AUTH com dependência de terceiro no caminho crítico de autenticação introduz consequências operacionais que precisam ser gerenciadas explicitamente.

Disponibilidade e fallback: O SLA do Vonage para a API de Verify é documentado, mas qualquer dependência externa em um fluxo de autenticação precisa ter um circuit breaker. Implementei isso no CreateAuthChallenge Lambda usando AWS Lambda Powertools com o decorator @circuit_breaker, configurado para abrir após 5 falhas consecutivas em uma janela de 60 segundos. Quando o circuit breaker está aberto, o Lambda retorna um desafio de fallback que instrui o Cognito a usar SMS OTP padrão via SNS — garantindo que nenhum usuário legítimo seja bloqueado por indisponibilidade do Vonage.

Observabilidade: O VerifyAuthChallengeResponse Lambda emite métricas customizadas para CloudWatch com as seguintes dimensões: AuthMethod (silent_auth | sms_fallback | blocked_fraud), RiskSignal (sim_swap_detected | clean | recycled_number), e Outcome (success | failure | challenge_expired). Isso permite criar um SLO de autenticação silenciosa separado do SLO de autenticação geral — crítico para identificar degradação de cobertura MNO por região.

Latência: A Silent Authentication adiciona ~800ms–1.2s de latência ao fluxo de autenticação em condições normais (consulta MNO em tempo real). Para o CreateAuthChallenge Lambda, configurei memória em 512MB — acima do mínimo, porque a chamada HTTP à API Vonage se beneficia de CPU adicional para TLS handshake. O timeout do Lambda em 10s é conservador; o p99 observado foi de 3.2s.

Custo: O custo incremental por autenticação bem-sucedida via Silent Auth é maior que SMS puro, mas o modelo de ROI muda quando você considera: (a) eliminação de 8–12% de AIT, (b) redução de ~60% em tickets de suporte OTP, e (c) recuperação de 2–5 pontos percentuais de conversão. Para 4M MAU com frequência de login de 3x/mês, a matemática favorece a migração.

Nenhuma decisão de autenticação elimina o risco — ela redistribui o modelo de ameaça. Com SMS OTP, o vetor primário é o atacante que controla o número de destino (SIM swap, SS7). Com Silent Authentication, o vetor residual é o atacante que compromete o dispositivo físico — o que é um bar significativamente mais alto, mas não zero.

O que o modelo de ameaça residual parece: Um atacante com acesso físico ao dispositivo desbloqueado pode completar uma Silent Authentication. Isso é verdade para qualquer mecanismo baseado em posse de dispositivo, incluindo TOTP e passkeys. A diferença é que Silent Authentication não tem um segredo que possa ser phished remotamente — o ataque requer presença física ou comprometimento do SO do dispositivo.

Integração com WAF e threat intelligence: O CreateAuthChallenge Lambda deve registrar o IP de origem, user-agent e características do dispositivo no CloudWatch Logs com structured logging (JSON). Um AWS WAF rule group no API Gateway que antecede o Cognito pode bloquear IPs com histórico de fraude antes que a requisição chegue ao fluxo CUSTOM_AUTH — reduzindo o custo de chamadas à API Vonage para tentativas claramente maliciosas.

Auditoria e não-repúdio: Cada autenticação bem-sucedida deve gerar um evento no CloudTrail com o AuthMethod usado. Para fins de compliance financeiro (PCI-DSS, SOC 2), o registro de qual mecanismo autenticou cada sessão é necessário para investigações de fraude. Configure o CloudTrail com S3 Object Lock em modo COMPLIANCE para garantir imutabilidade dos logs de autenticação por pelo menos 7 anos.

Política de risco escalonada: O resultado dos pre-checks do Identity Insights deve alimentar uma política de risco com três saídas: (1) clean → Silent Auth, (2) elevated risk (ex: sim_swap nos últimos 24h) → step-up com TOTP ou biometria, (3) high risk (ex: VoIP number + sim_swap recente) → hard block com notificação ao time de fraude. Essa política vive no DefineAuthChallenge Lambda e deve ser versionada como código.