Responsabilidade partilhada pela deteção da vivacidade facial

É responsabilidade partilhada entre o Azure e os seus clientes criar uma solução de vivacidade facial segura e compatível. Você pode saber mais sobre a responsabilidade compartilhada do Azure em Responsabilidade compartilhada na nuvem. Compreender o modelo de responsabilidade compartilhada é especialmente importante para soluções de deteção de vivacidade. Este documento aborda vários aspetos de como proteger e monitorar sua solução.

Proteja as conexões

O diagrama a seguir mostra como os clientes trabalham com o Azure para proteger as conexões de ponta a ponta.

Siga estas diretrizes para proteger as conexões:

• Certifique-se de que seu serviço de back-end atue como o orquestrador em aplicativos de deteção de vivacidade, usando a infraestrutura de segurança do Azure para iniciar sessões de deteção de vivacidade e examinar os resultados. O cliente é responsável por garantir o seu serviço de back-end.
• Implemente autenticação e autorização adequadas para o aplicativo cliente no back-end. Certifique-se de que a comunicação entre o aplicativo cliente e o serviço de back-end esteja protegida contra manipulação.
• Autentique a identidade real do usuário final e vincule as informações da conta dele à sessão de liveness.
• Assine o aplicativo e distribua-o apenas pelas lojas oficiais.

A deteção de vivacidade do Azure protege a conexão das seguintes maneiras:

• Valide todas as transações usando o token de autorização de sessão adquirido por meio da API de criação de sessão.
• Permitir apenas chamadas HTTPS para o serviço de back-end.
• Ofereça suporte à configuração de funções do IAM (Gerenciamento de Acesso a Identidades) para que os clientes autentiquem e executem ações.

Proteger o aplicativo cliente

Um invasor sofisticado pode alterar ou adulterar o aplicativo cliente, o que pode tornar o resultado de vivacidade não confiável. Use abordagens diferentes, dependendo da plataforma que seu aplicativo usa:

Aplicações móveis

Nas plataformas Android e iOS, existem soluções nativas e de terceiros para verificar a integridade do aplicativo, como o iOS App Attest e o Android Play Integrity. É responsabilidade do desenvolvedor de aplicativos incorporar o recurso de verificação de integridade e responder prontamente a possíveis hacks.

A deteção de vivacidade do Azure implementa proteções contra ambientes de tempo de execução não confiáveis. O SDK de deteção de vivacidade fornece um resumo de suas chamadas de serviço de deteção de vivacidade, que podem ser passadas para as APIs de integridade do aplicativo.

Aplicações Web

Os aplicativos Web são executados no contexto dos navegadores nos quais são carregados. Os navegadores modernos suportam verificações robustas de integridade de aplicativos. Você é responsável por implementar as verificações de integridade do aplicativo Web que é implantado nos navegadores. Essas responsabilidades incluem, mas não estão limitadas a:

• Garantir que os cabeçalhos de segurança estejam configurados corretamente. Em particular, atenção extra deve ser dada ao cache, HTTP Strict Transport Security (HSTS), iframe e políticas de origem cruzada.
• Configurar a Política de Segurança de Conteúdo (CSP) mais rigorosa possível para todos os recursos. O CSP ajuda a negar ataques XSS (Cross-Site Scripting), clickjacking e fraquezas associadas a páginas de conteúdo misto.
• Habilitando a integridade de subrecursos (SRI) por meio do CSP e verificando se o SDK carregado é uma cópia autêntica, conforme publicado pela Microsoft.

O Azure publica hashes criptográficos do SDK da Web de deteção de vivacidade juntamente com cada versão, que os clientes podem usar em seu cabeçalho CSP de integridade de script. O Azure também garante que o SDK da Web possa ser executado dentro das restrições de recursos do Contexto Seguro em navegadores modernos.

Proteger o dispositivo cliente

Diferentes aplicativos têm diferentes necessidades de segurança com base em seus casos de uso e cenários específicos, variando de protocolos básicos a altamente rigorosos. Você deve adaptar as medidas de segurança para atender a esses requisitos. Aqui, destacamos os diferentes níveis de segurança necessários para diferentes ambientes.

Nas plataformas Android e iOS, as soluções de integridade de aplicativos (incluindo suas respetivas ofertas de primeira parte) já incluem integridade e/ou reputação do dispositivo. Os clientes que implementam aplicativos Web e exigem que sua linha de base de segurança inclua a integridade do dispositivo precisam garantir que o aplicativo seja acessado somente por meio de um navegador moderno confiável em um dispositivo confiável. Normalmente, este processo envolve:

• Solução de Gestão de Dispositivos Empresariais configurada para gerir o dispositivo acedendo à aplicação.
• Rede Virtual para silo da comunicação do dispositivo com o Azure, imposta pelo Gerenciamento de Dispositivos.
• Inicialização Segura para garantir a integridade do hardware, imposta pelo Gerenciamento de Dispositivos
• Segurança da cadeia de suprimentos para linhas de base de segurança mais altas, que podem garantir que o dispositivo já é gerenciado e todas as suas políticas de segurança são aplicadas desde o ponto de fabricação.

Estas considerações também se aplicam às plataformas Android e iOS.

A API do Azure Face dá suporte a Redes Virtuais e pontos de extremidade privados. Consulte o guia.

O cliente que usa uma linha de base de alta segurança pode fazer referência a uma solução de Gerenciamento de Dispositivos, como o Microsoft Defender for Endpoints.

Mantenha a sua solução atualizada

A Microsoft atualiza regularmente o SDK e o serviço do cliente de deteção de vivacidade para melhorar a segurança, a confiabilidade e a conveniência do usuário. Manter-se atualizado com essas atualizações é crucial porque o campo de deteção de vivacidade enfrenta ataques ativos e sofisticados. O cliente deve sempre usar o SDK mais recente do lado do cliente, o serviço mais recente e o modelo mais recente. Para obter mais detalhes, consulte Noções básicas sobre versões do SDK do lado do cliente.

Monitorar o abuso

A tecnologia de reconhecimento facial, quando usada para autorização de acesso, pode ser um alvo para invasores que tentam ignorá-la ou a tecnologia de deteção de vivacidade construída sobre ela. Muitas vezes, essas tentativas envolvem forçar diferentes materiais, como várias fotos impressas, na frente do sistema, o que é considerado abuso do sistema. Para mitigar esses ataques de força bruta, você pode tomar ações específicas em relação à contagem de tentativas e ao limite de taxa.

• Crie uma sessão com chamada conservadora e limites de tempo: uma sessão serve como a primeira linha de defesa do processo de deteção de vivacidade, dissuadindo compromissos de força bruta. Um token de autorização de sessão é gerado para cada sessão e é utilizável para uma cota predefinida de reconhecimento ou tentativas de deteção de vivacidade. Se um usuário do aplicativo não tiver êxito dentro dos limites de tentativa, um novo token será necessário. A exigência de um novo token permite uma reavaliação do risco associado a novas tentativas. Ao definir um número conservadoramente baixo de chamadas permitidas por sessão, você pode reavaliar esse risco com mais frequência antes de emitir um novo token.
• Use o identificador de correlação apropriado ao criar uma sessão: o ID de correlação de dispositivo habilita a heurística de monitoramento automático de abuso na API do Face para ajudá-lo a negar tráfego abusivo ao seu sistema. Quando um determinado identificador de correlação atinge o limiar de tentativas abusivas, ele não pode mais ser usado para criar sessões. Gere uma cadeia de caracteres GUID aleatória e associe-a a tentativas sequenciais a partir do mesmo identificador primário individual dentro do seu sistema. A escolha do identificador ou conjunto de identificadores para mapear depende das necessidades do seu aplicativo e de outros parâmetros usados para avaliar o risco de acesso. Para permitir a regeneração de um novo GUID aleatório quando necessário, evite usar o identificador primário do seu aplicativo.
• Projete o sistema para suportar o julgamento humano: quando um ID de correlação de dispositivo é sinalizado e não é possível criar mais sessões com o identificador, implemente um processo de revisão humana significativo para garantir que as falhas não sejam devidas a tráfego abusivo ou tentativas de força bruta. Se, após a revisão, você decidir permitir mais tentativas da mesma entidade porque falhas anteriores são consideradas legítimas, redefina a associação gerando um novo GUID aleatório mapeado para o identificador individual.

Suporte do Azure para monitoramento de abuso

O Azure disponibiliza vários mecanismos para monitorizar sessões de deteção de liveness e mitigar abusos:

• Monitorização de Tráfego: Observa atividade em múltiplas sessões quando rotulada pelo programador com diferentes IDs de correlação, e dispara alertas quando são detetados padrões suspeitos.
• Auditoria via API: Oferece capacidades da API para auditar e descarregar imagens de liveness quando a sessão está ativa.
• Registo Abrangente: Mantém registos detalhados para ajudar a prevenir ataques de repudiação.

Comunicar abuso

Se a API do Azure AI Face não detetar um instrumento de ataque de apresentação que você acredita que deva ser detetado como falsificação, crie uma solicitação de suporte do Azure.

O pedido de apoio deve incluir:

• Tipo de material de falsificação apresentado.
• Informações de serviço retornadas do serviço como parte da chamada de API. No mínimo, as informações devem incluir caminho da API, ID da solicitação (apim-request-id), ID da sessão (SID) e versão do modelo da API (model-version).
• Condições específicas necessárias para reproduzir o ataque.
• Instruções passo-a-passo para reproduzir o ataque.
• Explorar imagem ou imagem de prova de conceito (se possível).
• Descrição do impacto do ataque nos negócios.

Você pode tentar recriar o ataque antes de denunciá-lo à Microsoft. As etapas de reprodução seriam especialmente úteis se você não puder fornecer a imagem explorada.

Próximo passo

Tutorial: Detetar vivacidade em rostos