Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
É responsabilidade compartilhada entre o Azure e seus clientes criar uma solução de detecção facial segura e compatível. Saiba mais sobre a responsabilidade compartilhada do Azure em responsabilidade compartilhada na nuvem. Entender o modelo de responsabilidade compartilhada é especialmente importante para soluções de detecção de atividade. Este documento aborda vários aspectos de como proteger e monitorar sua solução.
Importante
É importante que os desenvolvedores estejam cientes das implicações de segurança ao escolher a solução certa : Web ou Mobile. Embora as soluções Web e Móveis estejam em conformidade com os padrões de PAD do iBeta Nível 1 e Nível 2 ISO/IEC 30107-3, a solução Móvel inclui proteções automáticas de aplicativo em tempo de execução (RASP) adicionais fornecidas pelo GuardSquare, que não está disponível na solução Web.
Notavelmente, a solução Web tem limitações inerentes à execução em ambientes de navegador e pode ser mais vulnerável a determinados tipos de ataques. Portanto, recomendamos usar a solução Móvel sempre que possível.
Se você escolher a solução Web, é essencial que você siga de perto as diretrizes neste documento, verifique se a câmera em uso é um dispositivo físico confiável e considere implementar proteções e monitoramento adicionais para mitigar possíveis ataques de runtime.
Proteger 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:
- Verifique se o serviço de back-end atua como o orquestrador em aplicativos de detecção de atividade, usando a infraestrutura de segurança do Azure para iniciar sessões de detecção de atividade e examinar os resultados. O cliente é responsável por proteger seu serviço de back-end.
- Implemente a autenticação e a autorização adequadas para o aplicativo cliente no back-end. Verifique se a comunicação entre o aplicativo cliente e o serviço de back-end está protegida contra manipulação.
- Autentique a identidade real do usuário final e vincule suas informações de conta à sessão de atividade.
- Assine o aplicativo e distribua-o somente por meio de lojas oficiais.
A detecção de atividade 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.
- Dê suporte à configuração de funções do IAM (Gerenciamento de Identidades e Acesso) 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 atividade não confiável. Use abordagens diferentes dependendo de qual plataforma seu aplicativo usa:
Aplicativos móveis
Nas plataformas Android e iOS, há soluções nativas e de terceiros para verificar a integridade do aplicativo, como o Atestar Aplicativo do iOS e a Integridade do Android Play. É responsabilidade do desenvolvedor de aplicativos incorporar o recurso de verificação de integridade e responder prontamente a possíveis hacks.
A detecção de atividade do Azure implementa proteções contra ambientes de runtime não confiáveis. O SDK de detecção de atividade fornece um resumo de suas chamadas de serviço de detecção de atividade, que podem ser passadas para as APIs de integridade do aplicativo.
Aplicativos Web
Os aplicativos Web são executados no contexto dos navegadores nos quais são carregados. Os navegadores modernos dão suporte a verificações robustas de integridade do aplicativo. Você é responsável por implementar as verificações de integridade do aplicativo Web que é implantado em navegadores. Essas responsabilidades incluem, mas não se limitam a:
- Garantir que os cabeçalhos de segurança estejam configurados corretamente. Em particular, deve-se prestar atenção extra ao cache, à HSTS (Segurança de Transporte Estrito HTTP), ao iframe e às políticas entre origens.
- Configurando a CSP (Política de Segurança de Conteúdo) mais rigorosa possível para todos os recursos. A CSP ajuda a negar ataques XSS (cross-site scripting), sequestro de clique e pontos fracos associados a páginas de conteúdo misto.
- Habilitando a SRI (Integridade de Sub-Recursos) por meio da CSP e verificando se o SDK carregado é uma cópia autentica, conforme publicado pela Microsoft.
O Azure publica hashes criptográficos do SDK da Web de detecção de atividade ao lado de 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 recurso do Contexto Seguro em navegadores modernos.
Proteger o dispositivo cliente
Diferentes aplicativos têm diferentes necessidades de segurança com base em seus casos e cenários de uso específicos, desde protocolos básicos a altamente rigorosos. Personalize as medidas de segurança para corresponder a esses requisitos. Aqui, destacamos os diferentes níveis de segurança necessários para ambientes diferentes.
Nas plataformas Android e iOS, as soluções de integridade do aplicativo (incluindo suas respectivas ofertas de primeira parte) já incluem integridade e/ou reputação do dispositivo. Os clientes que implementam aplicativos Web e exigem sua linha de base de segurança para incluir a integridade do dispositivo precisam garantir que o aplicativo seja acessado apenas por meio de um navegador moderno confiável em um dispositivo confiável. Normalmente, esse processo envolve:
- Solução de Gerenciamento de Dispositivos Enterprise configurada para gerenciar o dispositivo acessando o aplicativo.
- 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 Fornecedores para linhas de base de segurança mais altas, o que pode garantir que o dispositivo já seja gerenciado e que todas as suas políticas de segurança sejam impostas a partir do ponto de fabricação.
Essas considerações também são aplicáveis às plataformas Android e iOS.
A API de Detecção Facial do Azure 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 referenciar uma solução de Gerenciamento de Dispositivos, como o Microsoft Defender para Pontos de Extremidade.
Mantenha sua solução atualizada
A Microsoft atualiza regularmente o SDK e o serviço do cliente de detecção de atividade 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 detecção de atividade enfrenta ataques ativos e sofisticados. O cliente sempre deve 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 as versões do SDK do lado do cliente.
Monitorar o abuso
A tecnologia de reconhecimento do rosto, quando usada para autorização de acesso, pode ser um destino para invasores que tentam contorná-la ou a tecnologia de detecção de atividade criada sobre ela. Muitas vezes, essas tentativas envolvem materiais diferentes que forçam brutalmente, como várias fotos impressas, na frente do sistema, o que é considerado abuso do sistema. Para atenuar esses ataques de força bruta, você poderá executar ações específicas em relação à contagem de repetições e à limitação de taxa.
- Crie uma sessão com limites de tempo e chamada conservadores: uma sessão serve como a primeira linha de defesa do processo de detecção de atividade, impedindo comprometimentos 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 tentativas de detecção de atividade ou de reconhecimento. Se um usuário do aplicativo não tiver êxito dentro dos limites de tentativa, um novo token será necessário. Exigir um novo token permite uma reavaliação do risco associado a novas tentativas. Ao definir um número cautelosamente baixo de chamadas permitidas por sessão, você poderá 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: a ID de correlação do dispositivo habilita a heurística de monitoramento de abuso automático dentro da API de Detecção Facial para ajudar você a negar o tráfego abusivo para seu sistema. Quando um identificador de correlação específico atinge o limite de tentativas abusivas, ele não pode mais ser usado para criar sessões. Gere uma cadeia de caracteres GUID aleatória e associá-la a tentativas sequenciais do mesmo identificador primário individual em seu sistema. A escolha do identificador ou do identificador definido para mapear depende das necessidades do 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 aplicativo.
- Projete o sistema para dar suporte ao julgamento humano: quando uma ID de correlação de dispositivo é sinalizada 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 devido ao 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 fornece vários mecanismos para monitorar sessões de detecção de atividade e mitigar o abuso:
- Monitoramento de Tráfego: observa a atividade em várias sessões quando rotulada pelo desenvolvedor com diferentes IDs de correlação e dispara alertas quando padrões suspeitos são detectados.
- Auditoria por meio da API: oferece funcionalidades de API para auditar e baixar imagens de atividade quando a sessão estiver ativa.
- Log abrangente: mantém logs detalhados para ajudar a evitar ataques de repúdio.
Relatar abuso
Se a API de Detecção Facial de IA do Azure não detectar um instrumento de ataque de apresentação que você acredita que deve ser detectado como falsificação, crie uma solicitação de suporte do Azure.
A solicitação de suporte deve incluir:
- Tipo de material de falsificação apresentado.
- Informações de serviço retornadas do serviço como parte da chamada à API. No mínimo, as informações devem incluir o caminho da API, a ID da solicitação (
apim-request-id), a ID da sessão (SID) e a versão do modelo de 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 comercial do ataque.
É possível tentar recriar o ataque antes de reportá-lo à Microsoft. As etapas de reprodução seriam especialmente úteis se você não puder fornecer a imagem explorada.