O Score Trust foi o projeto que desenvolvemos para o FIAP Challenge 2025, como trabalho de conclusão de curso. É uma plataforma que analisa o comportamento do usuário no momento do login ou do checkout de uma aplicação e decide, em tempo real, se a operação deve ser liberada, revisada ou negada.
Todo o backend roda em uma arquitetura serverless na AWS. Neste post de apoio ao vídeo, explico o papel de cada serviço, como o score é calculado e as decisões de segurança do projeto.
O problema
Fraudes em e-commerce acontecem justamente nos pontos mais sensíveis: login com credenciais vazadas, criação de contas falsas e checkout com dados roubados. Bloquear tudo gera atrito e perde vendas. Liberar tudo gera prejuízo. A ideia do Score Trust é dar a cada tentativa uma nota de risco e agir de forma proporcional:
| Score | Ação |
|---|---|
| 0 a 30 | ALLOW: segue normalmente |
| 31 a 75 | REVIEW: pede uma verificação extra (biometria facial) |
| 76 a 100 | DENY: bloqueia a operação |
A arquitetura na AWS
O e-commerce integra um SDK em JavaScript que coleta os sinais do usuário e chama a API do Score Trust. A partir daí, tudo é serverless:
| Serviço AWS | Papel no Score Trust |
|---|---|
| Route 53 | DNS e domínio das APIs |
| AWS Certificate Manager | Certificados TLS das APIs |
| AWS WAF | Proteção na borda, antes de qualquer requisição chegar à lógica. Veja como configurar: Como configurar o AWS WAF |
| Amazon API Gateway | Expõe as rotas /identity/verify, /identity/face-verify e /getRiskEvents, com API Key e planos de uso |
| AWS Lambda (Python) | Motor de risco, verificação facial, consulta de eventos e administração de regras |
| Amazon DynamoDB | Tabelas de eventos, regras, pesos e dispositivos conhecidos |
| Amazon S3 | Armazenamento das fotos usadas na biometria |
| Amazon Rekognition | CompareFaces para comparar a foto atual com a foto base do usuário |
| AWS KMS | Criptografia dos dados em repouso |
| IAM | Roles com permissão mínima para cada Lambda |
| Amazon CloudWatch | Logs e observabilidade de todas as funções |
Por que serverless
- Custo proporcional ao uso: sem servidor ligado esperando requisição. Para um projeto que começa pequeno, isso faz muita diferença.
- Escala automática em picos, como Black Friday, sem planejamento de capacidade.
- Menos superfície de ataque: não há sistema operacional para manter e corrigir.
Como o score é calculado
A Lambda RiskEngineEvaluate soma pesos de acordo com os sinais de risco encontrados. Os pesos ficam na tabela RuleWeights do DynamoDB, então dá para ajustar o motor sem mexer no código:
| Sinal | Peso |
|---|---|
| País de origem diferente do Brasil | 80 |
| User-Agent suspeito (ex.: navegador headless) | 50 |
| Dispositivo não reconhecido | 40 |
| IP privado ou suspeito | 40 |
| Biometria facial não verificada | 25 |
Timezone inesperado (fora de America/Sao_Paulo e America/Buenos_Aires) | 20 |
| IP com reputação ruim no AbuseIPDB | 20 |
| Idioma diferente de português | 10 |
O score final é limitado a 100 pontos e convertido em ação pelas faixas da tabela ScoringRules. A resposta da API é simples e explicável:
{
"score": 68,
"action": "REVIEW",
"reason": [
"Dispositivo não reconhecido",
"Timezone inesperado",
"País de origem não é Brasil"
]
}A lista de motivos (reason) é importante: quem opera o sistema entende por que uma decisão foi tomada, o que facilita ajustar os pesos e atender o cliente.
Verificação facial com Amazon Rekognition
Quando o resultado é REVIEW, o usuário pode confirmar a identidade com uma foto, pela Lambda faceVerify:
- Primeira captura: a foto é salva no S3 como imagem base do usuário. Nenhuma comparação é cobrada nesse momento.
- Capturas seguintes: a nova foto é comparada com a base usando o
CompareFacesdo Rekognition. - Se a similaridade passa do limite configurado, o evento muda para
ALLOWe o score é reduzido. Se não passa, viraDENY.
O evento original no DynamoDB é atualizado, e não duplicado, o que mantém a linha do tempo de cada usuário limpa para auditoria.
Decisões de segurança
- AWS WAF na frente do API Gateway.
- APIs separadas por tipo de uso: usuário final e administrador.
- API Key e planos de uso no API Gateway, para limitar o consumo.
- KMS para dados em repouso e TLS em todas as chamadas.
- TTL no DynamoDB, para que eventos antigos expirem automaticamente (minimização de dados, alinhada à LGPD).
- IAM Roles com privilégio mínimo em cada Lambda. É o mesmo princípio que mostro com o Secrets Manager: AWS Secrets Manager com Lambda.
Próximos passos do projeto
- Portal de gestão para administrar regras e pesos.
- Detecção de vivacidade (face liveness) na biometria.
- Aprendizado contínuo para ajustar os pesos automaticamente com base nos resultados.
Equipe e material de apoio
O Score Trust foi desenvolvido por Adrian Wicke, Ana Carolina, Camille, Demetrio Paszko e Luiz Pessol.
- Vídeo completo no canal: Projeto Challenge 2025 da FIAP – Score Trust em AWS
- Site da plataforma: scoretrust.com.br
- Código no GitHub: score-trust
Se você trabalha com prevenção a fraudes ou arquitetura serverless, conta nos comentários como você resolveria esse problema.
Atualmente atua como Architecture Manager pela Atos Brasil, entusiasta Microsoft, FreeBSD e Debian, com mais de 20 anos de experiência em infraestrutura de T.I com ambientes heterogêneos, possuí o título de Microsoft Certified Trainer, AWS Community Builder, FinOps Member Foundation, Membro do comitê público do IDCIBER e especialista em segurança de perímetro, tendo atuado com soluções como Isa Server, iptables, IPFW, Cisco ASA, SonicWall, Fortigate, pfSense e soluções de Web Application Firewall.
Deixe um comentário