Biometria Facial Comum vs. AWS Rekognition Face Liveness

1. Introdução

A biometria facial tornou-se um dos pilares da autenticação digital moderna, especialmente em setores como fintechs, gig economy, e-commerce, saúde e serviços governamentais. Entre empresas que buscam reduzir fraude em onboarding e autenticação, é comum confundir dois conceitos distintos: o que é uma solução de biometria facial "comum" (reconhecimento e comparação de faces) e o que é uma solução de biometria facial com prova de vida ativa baseada em nuvem, como o AWS Rekognition Face Liveness.

Este artigo apresenta uma comparação técnica entre as duas abordagens, detalhando fluxo de dados, modelo de ameaças, vetores de ataque mitigados, integração e considerações de arquitetura em aplicações de produção.

2. Biometria Facial Comum

A biometria facial tradicional consiste na extração de características faciais de uma imagem estática para gerar um vetor numérico (embedding ou template) que representa unicamente aquele rosto. A comparação entre templates permite verificar ou identificar um indivíduo.

2.1 Fluxo técnico típico

Um sistema de reconhecimento facial comum executa, tipicamente, quatro etapas encadeadas:

Detecção facial: localiza a face na imagem, geralmente via modelos como MTCNN, RetinaFace ou Haar Cascades.

Alinhamento: normaliza pose, rotação e escala utilizando landmarks (olhos, nariz, boca).

Extração de features: uma rede neural convolucional (FaceNet, ArcFace, DeepFace) gera um embedding de dimensão fixa, tipicamente entre 128 e 512 floats.

Comparação: pode operar em dois modos — verificação 1:1 (confirma identidade contra um template de referência) ou identificação 1:N (busca em uma galeria).

2.2 Modos de operação

Verificação (1:1): usada em login ou autenticação passo a passo, onde o sistema compara a selfie atual com uma foto pré-cadastrada, por exemplo, a foto do documento de identidade.

Identificação (1:N): a imagem é comparada contra uma base de templates, útil para antifraude (detecção de identidades repetidas) ou controle de acesso.

2.3 Limitações de segurança

O grande problema da biometria facial comum, quando isolada, é que ela valida aparência, não presença. Um sistema que apenas compara embeddings pode ser enganado por vetores conhecidos como ataques de apresentação (Presentation Attacks, ou PAD):

Print attack: foto impressa do rosto da vítima apresentada à câmera.

Replay attack: vídeo gravado da vítima exibido em tela de celular ou monitor.

Mask attack: máscaras 2D (papel) ou 3D (silicone, resina) representando o rosto.

Deepfake: vídeo sintético gerado por IA, com movimentos e expressões verossímeis.

Injeção de vídeo: bypass direto da câmera via driver virtual, injetando um vídeo pré-fabricado no stream da aplicação.

Um algoritmo pode ser matematicamente preciso na comparação e, ainda assim, falhar na camada de segurança se aceitar uma foto de alta resolução como rosto real. É por essa razão que a prova de vida (liveness detection) é considerada indissociável da biometria moderna.

3. AWS Rekognition Face Liveness

O AWS Rekognition Face Liveness é um serviço gerenciado da Amazon Web Services projetado especificamente para a camada de prova de vida. Ele não substitui o face match: ele o complementa, verificando se a pessoa em frente à câmera é real, presente e viva, antes ou depois de a comparação facial ocorrer.

3.1 Arquitetura do serviço

O Face Liveness opera sobre um vídeo curto de selfie capturado com desafio ativo. O SDK oficial (AWS Amplify) renderiza um componente cliente que conduz o usuário por um fluxo específico: posicionar o rosto dentro de um oval na tela, que não é customizável por design, justamente para garantir consistência estatística do modelo.

Existem dois tipos de desafio disponíveis:

FaceMovementAndLightChallenge: combina movimento da cabeça com uma sequência de luzes coloridas projetadas pela própria tela do dispositivo. É o modo de maior acurácia.

FaceMovementChallenge: apenas movimento da cabeça, sem o desafio de luz. Reduz a latência, ao custo de menor resistência a alguns tipos de ataque.

3.2 APIs principais

A integração é baseada em três operações server-side:

CreateFaceLivenessSession: inicia uma sessão e retorna um SessionId. Essa chamada é feita pelo backend do cliente.

StartFaceLivenessSession: invocada internamente pelo componente FaceLivenessDetector do Amplify. Estabelece o event stream que recebe os frames em tempo real.

GetFaceLivenessSessionResults: consultada pelo backend após o término, retorna score de confiança (0–100), reference image (frame de alta qualidade para posterior face match) e até 4 audit images para trilha de auditoria.

3.3 Vetores de ataque mitigados

Diferente de soluções passivas, o Face Liveness foi construído para detectar duas classes distintas de spoofing:

Ataques apresentados à câmera: foto impressa, foto digital exibida em tela, vídeo digital reproduzido em monitor, máscaras 2D e 3D.

Ataques que tentam burlar a câmera: vídeos pré-gravados injetados no stream e deepfakes sintéticos, que são detectados com base em inconsistências físicas (resposta à luz, profundidade, microexpressões).

3.4 Conformidade e certificação

O serviço passou nos testes iBeta PAD Nível 1 e Nível 2, conduzidos em conformidade com o padrão internacional ISO/IEC 30107-3, que define critérios para avaliação de tecnologias de detecção de ataques de apresentação. iBeta é laboratório acreditado pelo NIST/NVLAP, o que dá à certificação peso regulatório relevante em contextos como KYC bancário e onboarding sob regras do Banco Central.

3.5 Características operacionais

Latência: tipicamente 5 segundos end-to-end em condições ideais.

SDKs suportados: React (web), Swift (iOS nativo), Kotlin (Android nativo), via AWS Amplify UI.

Escala: serverless e elástica — o modelo de cobrança é por verificação, sem provisioning manual.

Regiões: disponível em um conjunto limitado, incluindo US East (N. Virginia), US West (Oregon), Europa (Irlanda), Ásia-Pacífico (Tóquio e Mumbai).

4. Comparativo Direto

A tabela a seguir sintetiza as diferenças entre as duas abordagens em dimensões técnicas e operacionais relevantes para decisão de arquitetura.

5. Fluxo de Integração Recomendado

Em uma aplicação de produção que exige KYC ou autenticação de alta segurança, a recomendação é combinar as duas camadas, não escolher entre elas. Um fluxo típico completo é:

O cliente (web ou mobile) inicia o fluxo solicitando ao backend a criação de uma sessão de liveness via CreateFaceLivenessSession.

O componente FaceLivenessDetector conduz o usuário pelo desafio, capturando o vídeo de selfie e fazendo streaming seguro para a AWS.

O backend consulta GetFaceLivenessSessionResults e obtém o score, a reference image e as audit images.

Caso o score esteja acima do threshold definido pela aplicação (configurável conforme apetite a risco), a reference image é enviada para uma operação de face match (por exemplo, CompareFaces do próprio Rekognition, ou outro provedor) contra a foto do documento ou do cadastro prévio.

A decisão final de aprovação combina os dois scores, liveness e match, junto a outros sinais de risco (device fingerprint, geolocalização, análise comportamental).

6. Considerações de Arquitetura

6.1 Threshold calibrado ao caso de uso

O score de liveness é probabilístico, não binário. Aplicações de baixo risco podem operar com thresholds mais permissivos (por exemplo, 70), enquanto bancos e credenciamentos regulados tendem a exigir thresholds acima de 85 ou 90, com rejeições enviadas a um fluxo de revisão manual.

6.2 Privacidade e LGPD

A captura de dados biométricos se enquadra como dado pessoal sensível sob a LGPD (Lei 13.709/2018). O Face Liveness pode armazenar o vídeo para melhoria do serviço, salvo opt-out expresso. Em implementações no Brasil, é recomendado configurar o opt-out e deixar claro no consentimento qual provedor de nuvem processa os dados, em qual região, e por quanto tempo.

6.3 Acessibilidade e UX

O desafio com luzes coloridas tem excelente performance em termos de detecção, mas pode ser problemático para usuários com epilepsia fotossensível. Para esses casos, o FaceMovementChallenge (sem luz) deve ser oferecido como alternativa. A forma oval no centro da tela e seu tamanho não são customizáveis — isso é uma decisão consciente do serviço para garantir consistência estatística do modelo.

6.4 Custo

A cobrança é por chamada bem-sucedida. Em fluxos de alto volume, vale modelar o custo por usuário ativo considerando também retries (usuários que falham no primeiro desafio por iluminação ou movimento) e escolher o ponto ótimo entre experiência e custo.

7. Por que o HIVE usa AWS Face Liveness?

A biometria facial comum, embora pareça segura, valida apenas a aparência e não a presença física. Para um sistema de gestão de EPI que visa eliminar passivos trabalhistas, confiar em fotos estáticas é um risco jurídico alto, pois esse método é vulnerável a ataques de apresentação (PAD).

1. O Diferencial da Prova de Vida (Liveness)

Diferente da biometria tradicional que compara embeddings de imagens estáticas, o AWS Rekognition Face Liveness exige um vídeo curto com desafios ativos:

Desafio Face + Luz: Projeta sequências de luzes coloridas na tela para verificar a resposta física do rosto.

Detecção de Deepfakes: O modelo identifica inconsistências físicas, microexpressões e respostas à luz que vídeos sintéticos ou injeções de drivers virtuais não conseguem replicar.

Certificação Internacional: O motor possui certificação iBeta PAD Nível 1 e 2, em conformidade com o padrão global ISO/IEC 30107-3. Isso dá ao HIVE um peso regulatório equivalente ao de grandes fintechs e bancos.

2. Comparativo

8. Conclusão

A biometria facial comum e o AWS Rekognition Face Liveness resolvem problemas diferentes. A primeira responde à pergunta "esta pessoa é quem diz ser?", enquanto a segunda responde "esta pessoa está de fato presente, viva, em frente à câmera, agora?". Em sistemas modernos sujeitos a fraude sofisticada, incluindo deepfakes e ataques de injeção, nenhuma das duas é suficiente isoladamente.

A combinação de prova de vida ativa (via Face Liveness ou equivalente) com face match (via um provedor de biometria) e outros sinais de risco é, hoje, o padrão de fato em onboarding digital seguro. O diferencial do Face Liveness está na combinação de certificação iBeta PAD Nível 2, arquitetura serverless gerenciada, SDKs prontos para web, iOS e Android, e um modelo de cobrança por uso — o que reduz o tempo de integração em relação a montar uma pipeline equivalente com modelos open-source self-hosted.

Para equipes que avaliam a adoção, a recomendação prática é: tratar a biometria facial como uma composição de camadas (detecção → liveness → match → decisão de risco), calibrar thresholds por caso de uso e estabelecer desde o início o contrato de privacidade com o usuário, alinhado à LGPD.

Referências

Amazon Web Services. Amazon Rekognition Face Liveness — Product page.

AWS Documentation. Detecting Face Liveness — Developer Guide.

AWS Documentation. Programming the Amazon Rekognition Face Liveness APIs.

AWS Machine Learning Blog. Detect real and live users and deter bad actors using Amazon Rekognition Face Liveness.

ISO/IEC 30107-3:2023 — Information technology — Biometric presentation attack detection — Part 3: Testing and reporting.

iBeta Quality Assurance — Presentation Attack Detection (PAD) Conformance Testing Reports.