Modelo de responsabilidade compartilhada Face Liveness - Amazon Rekognition

Modelo de responsabilidade compartilhada Face Liveness

A segurança e a conformidade são uma responsabilidade compartilhada entre AWS e você, o cliente. Leia mais sobre o modelo de responsabilidade compartilhada da AWS aqui.

  1. Todas as chamadas para o AWS serviço (via aplicativo cliente ou back-end do cliente) são autenticadas e autorizadas com AWS Auth (AWS Authentication). É responsabilidade dos proprietários do serviço Face Liveness garantir que isso aconteça.

  2. Todas as chamadas para o back-end do cliente (a partir do aplicativo do cliente) são autenticadas e autorizadas pelo cliente. Essa responsabilidade recai sobre o cliente. O cliente deve garantir que as chamadas do aplicativo cliente sejam autenticadas e não tenham sido manipuladas de forma alguma.

  3. O back-end do cliente deve identificar o usuário final que está executando o desafio Face Liveness. É responsabilidade do cliente vincular o usuário final a uma sessão do Face Liveness. O serviço Face Liveness não faz distinção entre usuários finais. Ele só consegue identificar a identidade AWS da chamada (que o cliente manipula).

  4. A AWS recomenda que os clientes apliquem verificações de validação adicionais, como localização geográfica (por exemplo, com base em IP), códigos de senha de uso único (OTPs), etc. além do Face Liveness, que se alinha aos requisitos de seu caso de uso e postura de segurança.

A configuração “FaceMovementAndLightChallenge” oferece a mais alta precisão para o Rekognition Liveness. Ela exige que os usuários movam o rosto em direção à tela e fiquem parados enquanto uma série de luzes pisca. Recomendamos que os clientes usem essa configuração padrão. Como alternativa, os clientes podem ativar a configuração “FaceMovementChallenge”, que reduz o tempo de verificação em vários segundos ao eliminar as luzes piscantes. Embora a “FaceMovementAndLightChallenge” continue sendo a melhor configuração para maximizar a precisão, a “FaceMovementChallenge” permite que os clientes priorizem verificações de vivacidade mais rápidas. Ao escolher entre essas configurações, os clientes devem considerar seus requisitos de caso de uso, incluindo os tipos de ataque esperados, as taxas desejadas de aceitação e rejeição falsas, e também implementar verificações adicionais, como geolocalização (por exemplo, com base em IP), códigos de senha de uso único (OTPs), etc. Os clientes devem tomar essa decisão após testar o desempenho do Liveness com vários limites de pontuação de confiança, dependendo do caso de uso. Eles também são responsáveis por implementar controles para proteger o dispositivo do qual o vídeo é enviado

O diagrama de fluxo a seguir mostra quais chamadas são autenticadas pelo serviço da AWS ou pelo cliente:

Fluxo de detecção de vivacidade mostrando interações entre o aplicativo cliente, o componente detector de vivacidade facial, o backend do cliente, o serviço Rekognition e o serviço de streaming Rekognition para uma sessão segura de vivacidade facial.

Todas as chamadas para o serviço Amazon Rekognition Face Liveness são protegidas pelo AWS Auth (usando mecanismo de assinatura da AWS). Isso inclui as seguintes chamadas:

Todas as chamadas para o back-end do cliente precisam ter um mecanismo de autenticação e autorização. Os clientes precisam garantir que o código/biblioteca/etc de terceiros usado esteja sendo mantido e desenvolvido ativamente. Os clientes também precisam garantir que o usuário final correto esteja fazendo chamadas para a sessão correta do Face Liveness. Os clientes devem autenticar e autorizar os seguintes fluxos:

  • [2] Criar sessão Face Liveness (a partir do aplicativo cliente)

  • [10] Obtenha o resultado da sessão Face Liveness (do aplicativo cliente)

Os clientes podem seguir o modelo de segurança STRIDE para garantir que suas chamadas de API estejam protegidas.

Tipo Descrição Controle de segurança
Spoofing Threat action aimed at accessing and use of another user’s credentials, such as username and password. Authentication
Tampering Threat action intending to maliciously change or modify persistent data. Examples include records in a database, and the alteration of data in transit between two computers over an open network, such as the internet. Integrity
Repudiation Threat action aimed at performing prohibited operations in a system that lacks the ability to trace the operations. Non-Repudiation
Information disclosure Threat action intending to read a file that one was not granted access to, or to read data in transit. Confidentiality
Denial of service Threat action attempting to deny access to valid users, such as by making a web server temporarily unavailable or unusable. Availability
Elevation of privilege Threat action intending to gain privileged access to resources in order to gain unauthorized access to information or to compromise a system. Authorization

AWS protege suas conexões das seguintes maneiras:

  1. Calcular a assinatura da solicitação e, em seguida, verificar a assinatura no lado do serviço. As solicitações são autenticadas usando essa assinatura.

  2. Os clientes da AWS precisam configurar os perfis do IAM adequadas para autorizar determinadas ações/operações. Esses perfis do IAM são necessárias para fazer chamadas ao serviço da AWS.

  3. Somente solicitações HTTPS para o serviço AWS são permitidas. As solicitações são criptografadas na rede aberta usando TLS. Isso protege a confidencialidade das solicitações e mantém a integridade da solicitação.

  4. AWS o serviço registra dados suficientes para identificar as chamadas feitas pelos clientes. Isso evita ataques de repúdio .

  5. AWS o serviço possui a manutenção de disponibilidade suficiente

O cliente é responsável por proteger seu serviço e suas chamadas de API das seguintes formas:

  1. O cliente deve garantir que siga um mecanismo adequado de autenticação. Há vários mecanismos de autenticação que podem ser usados para autenticar uma solicitação. Os clientes podem explorar a autenticação baseada em resumo, OAuth, conexão OpenID e outros mecanismos.

  2. Os clientes devem garantir que seu serviço ofereça suporte aos canais de criptografia adequados (como TLS/HTTPS) para fazer chamadas de API de serviço.

  3. Os clientes devem se certificar de registrar os dados necessários para identificar de forma exclusiva uma chamada de API e o chamador. Eles devem ser capazes de identificar o cliente que está chamando sua API com parâmetros definidos e a hora das chamadas.

  4. Os clientes devem garantir que seus sistemas estejam disponíveis e protegidos contra ataques de DDoS. Aqui estão alguns exemplos de técnicas de defesa contra ataques DDoS.

Os clientes são responsáveis por manter seus aplicativos atualizados. Para obter mais informações, consulte Diretrizes de atualização do Face Liveness.