Modelo de responsabilidade compartilhada Face Liveness

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

1. Todas as chamadas para o AWS serviço (via aplicativo do cliente ou back-end do cliente) são autenticadas e autorizadas com AWS Auth (AWS Autenticação). É 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ó é capaz de identificar a AWS identidade 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 One Time Pass (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, exigindo que os usuários movam o rosto em direção à tela e fiquem parados por uma série de luzes piscando. 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 'FaceMovementAndLightChallenge' continue sendo a melhor configuração para maximizar a precisão, 'FaceMovementChallenge' permite que os clientes priorizem verificações de atividade mais rápidas. Ao selecionar 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 falsa e rejeição, e também implementar verificações adicionais, como geolocalização (por exemplo, com base em IP), códigos One Time Pass (OTPs) etc. Os clientes devem tomar essa decisão depois de testar o desempenho do Liveness com vários limites de pontuação de confiança, dependendo do caso de uso. Os clientes 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:

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

• [3] Chamada de CreateFaceLivenessSessionAPI (do back-end do cliente)

• [7] Chamada de StartFaceLivenessSessionAPI (do aplicativo cliente)

• [11] Chamada de GetFaceLivenessSessionResultsAPI (do back-end do cliente)

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 usuário code/library/etc terceirizado 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
Falsificação	Ação de ameaça que visa acessar e usar as credenciais de outro usuário, como nome de usuário e senha.	Autenticação
Adulteração	Ação de ameaça com a intenção de alterar ou modificar dados persistentes de forma maliciosa. Os exemplos incluem registros em um banco de dados e a alteração de dados em trânsito entre dois computadores em uma rede aberta, como a Internet.	Integridade
Repúdio	Ação de ameaça destinada a realizar operações proibidas em um sistema que não tem a capacidade de rastrear as operações.	Não repúdio
Divulgação de informações	Ação de ameaça com a intenção de ler um arquivo ao qual não foi concedido acesso ou ler dados em trânsito.	Confidencialidade
Negação de serviço	Ação de ameaça que tenta negar acesso a usuários válidos, por exemplo, tornando um servidor web temporariamente indisponível ou inutilizável.	Disponibilidade
Elevação do privilégio	Ação de ameaça com a intenção de obter acesso privilegiado aos recursos para obter acesso não autorizado às informações ou comprometer um sistema.	Autorização

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. AWS os clientes precisam configurar funções adequadas do IAM 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 AWS serviço 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 resumos OAuth , o OpenID Connect 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 seu sistema esteja disponível e protegido contra ataques DDo S. Aqui estão alguns exemplos de técnicas de defesa contra ataques DDo S.

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