Modelo de responsabilidad compartida de Face Liveness - Amazon Rekognition

Modelo de responsabilidad compartida de Face Liveness

Los asuntos relacionados con la seguridad y la conformidad son una responsabilidad compartida entre AWS y el cliente. Obtenga más información sobre el modelo de responsabilidad compartida de AWS aquí.

  1. Todas las llamadas al servicio de AWS (a través de la aplicación del cliente o del servidor del cliente) se autentican y autorizan con AWS Auth (AWS Authentication). Es responsabilidad de los propietarios del servicio Face Liveness garantizar que esto suceda.

  2. Todas las llamadas al backend del cliente (desde la aplicación del cliente) se autentican y autorizan a través del cliente. Esta responsabilidad recae en el cliente. El cliente debe asegurarse de que las llamadas desde la aplicación cliente estén autenticadas y no hayan sido manipuladas de ninguna manera.

  3. El backend del cliente debe identificar al usuario final que realiza el desafío Face Liveness. Es responsabilidad del cliente vincular a un usuario final a una sesión de Face Liveness. El servicio Face Liveness no distingue entre los usuarios finales. Solo puede identificar la identidad de AWS que llama (que gestiona el cliente).

  4. AWS recomienda a los clientes aplicar comprobaciones de validación adicionales, como la geolocalización de la ubicación (por ejemplo, basada en IP), códigos One Time Pass (OTP), etc., además de Face Liveness, que se ajuste a los requisitos de sus casos de uso y a su posición de seguridad.

La configuración “FaceMovementAndLightChallenge” ofrece la máxima precisión para Rekognition Liveness, ya que requiere que los usuarios muevan la cara hacia la pantalla y se queden quietos durante una serie de luces parpadeantes. Recomendamos a los clientes que utilicen esta configuración predeterminada. Como alternativa, los clientes pueden activar la configuración “FaceMovementChallenge”, que reduce el tiempo de comprobación en varios segundos al eliminar las luces parpadeantes. Aunque “FaceMovementAndLightChallenge” sigue siendo la mejor opción para maximizar la precisión, “FaceMovementChallenge” permite a los clientes priorizar los controles de actividad más rápidos. Al seleccionar entre estas configuraciones, los clientes deberían tener en cuenta los requisitos de cada caso de uso, incluidos los tipos de ataque esperados y las tasas deseadas de falsas aceptaciones y falsos rechazos, y también deberían implementar comprobaciones adicionales, como la geolocalización (por ejemplo, basada en IP), los códigos One Time Pass (OTP), etc. Los clientes deben tomar esta decisión después de probar el rendimiento de Liveness con varios umbrales de confianza en función de su caso de uso. Los clientes son responsables de implementar controles para proteger el dispositivo desde el que se envía el vídeo.

El siguiente diagrama de flujo muestra qué llamadas autentican el servicio de AWS o el cliente:

Flujo de detección de Liveness que muestra las interacciones entre la aplicación del cliente, el componente detector de Face Liveness, el backend del cliente, el servicio Rekognition y el servicio de transmisión de Rekognition para una sesión segura de Face Liveness.

Todas las llamadas al servicio Amazon Rekognition Face Liveness están protegidas por AWS Auth (mediante un mecanismo de firma de AWS). Estas incluyen las siguientes llamadas:

Todas las llamadas al backend del cliente deben tener un mecanismo de autenticación y autorización. Los clientes deben asegurarse de que el código/biblioteca/etc. de terceros utilizado se mantenga y desarrolle activamente. Los clientes también deben asegurarse de que el usuario final correcto realiza las llamadas a la sesión correcta de Face Liveness. Los clientes deben autenticar y autorizar los siguientes flujos:

  • [2] Cree una sesión de Face Liveness (desde la aplicación del cliente)

  • [10] Obtenga el resultado de la sesión de Face Liveness (desde la aplicación del cliente)

Los clientes pueden seguir el modelo de seguridad STRIDE para asegurarse de que sus llamadas a la API estén protegidas.

Tipo Descripción Control de seguridad
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 sus conexiones de las siguientes maneras:

  1. Calcule la firma de la solicitud y, a continuación, verifique la firma en el lado del servicio. Las solicitudes se autentican con esta firma.

  2. Los clientes de AWS deben configurar los roles de IAM adecuados para autorizar determinadas acciones u operaciones. Estos roles de IAM son necesarios para realizar llamadas al servicio de AWS.

  3. Solo se permiten las solicitudes HTTPS al servicio de AWS. Las solicitudes se cifran en la red abierta mediante TLS. Esto protege la confidencialidad de las solicitudes y mantiene su integridad.

  4. El servicio de AWS registra datos suficientes para identificar las llamadas realizadas por los clientes. Esto evita los ataques de rechazo.

  5. El servicio AWS es propietario y mantiene una disponibilidad suficiente

El cliente es responsable de proteger sus llamadas al servicio y a la API de las siguientes maneras:

  1. El cliente debe asegurarse de seguir un mecanismo de autenticación adecuado. Existen varios mecanismos de autenticación que se pueden utilizar para autenticar una solicitud. Los clientes pueden explorar la autenticación basada en resúmenes, OAuth, OpenID Connect y otros mecanismos.

  2. Los clientes deben asegurarse de que su servicio admite los canales de cifrado adecuados (como TLS/HTTPS) para realizar llamadas a la API del servicio.

  3. Los clientes deben asegurarse de registrar los datos necesarios para identificar de forma exclusiva una llamada a la API y a la persona que llama. Deben poder identificar al cliente que llama a su API con parámetros definidos y la hora de las llamadas.

  4. Los clientes deben asegurarse de que su sistema esté disponible y de que estén protegidos contra ataques DDoS. Estos son algunos ejemplos de técnicas de defensa contra los ataques DDoS.

Los clientes son responsables de mantener sus aplicaciones actualizadas. Para obtener más información, consulte Directrices de actualización de Face Liveness.