Modelo de responsabilidad compartida de Face Liveness - Amazon Rekognition

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Modelo de responsabilidad compartida de Face Liveness

La seguridad y el cumplimiento son una responsabilidad compartida entre usted AWS y usted, el cliente. Obtenga más información sobre el modelo de responsabilidad AWS compartida aquí.

  1. Todas las llamadas al AWS servicio (a través de la aplicación del cliente o del servidor del cliente) se autentican y autorizan con AWS Auth (AWS autenticación). 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 AWS identidad de la llamada (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 (OTPs), etc., además de Face Liveness, que se ajuste a los requisitos de sus casos de uso y a su postura de seguridad.

El ajuste «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. Si bien «FaceMovementAndLightChallenge» sigue siendo el mejor ajuste para maximizar la precisión, «FaceMovementChallenge» permite a los clientes priorizar los controles de actividad más rápidos. Al seleccionar una de estas opciones, los clientes deberían tener en cuenta los requisitos de cada caso de uso, incluidos los tipos de ataque esperados y las tasas de falsas aceptaciones y rechazos falsos que desean, y también implementar controles adicionales, como la geolocalización (por ejemplo, basada en IP), los códigos de pase único (OTPs), 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 AWS protegidas por Auth (mediante un mecanismo de firma). 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 tercero code/library/etc 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
Suplantación de identidad Acción de amenaza destinada a acceder y utilizar las credenciales de otro usuario, como el nombre de usuario y la contraseña. Autenticación
Manipulación Acción de amenaza destinada a cambiar o modificar los datos persistentes de forma malintencionada. Algunos ejemplos son los registros de una base de datos y la alteración de los datos en tránsito entre dos ordenadores a través de una red abierta, como Internet. Integridad
Repudio Acción de amenaza destinada a realizar operaciones prohibidas en un sistema que carece de la capacidad de rastrear las operaciones. Falta de repudio
Divulgación de información Acción de amenaza destinada a leer un archivo al que no se ha concedido acceso o a leer datos en tránsito. Confidencialidad
Denegación de servicio Acción de amenaza que intenta denegar el acceso a usuarios válidos, por ejemplo, haciendo que un servidor web no esté disponible o se pueda utilizar temporalmente. Disponibilidad
Elevación de privilegios Acción de amenaza destinada a obtener acceso privilegiado a los recursos para obtener acceso no autorizado a la información o poner en peligro un sistema. Autorización

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. AWS los clientes deben configurar las funciones de IAM adecuadas 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 AWS servicio. Las solicitudes se cifran en la red abierta mediante TLS. Esto protege la confidencialidad de las solicitudes y mantiene su integridad.

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

  5. AWS el servicio 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 , la conexión OpenID 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 los ataques DDo S. Estos son algunos ejemplos de técnicas de defensa contra los ataques DDo S.

Los clientes son responsables de conservar sus aplicaciones up-to-date. Para obtener más información, consulte Directrices de actualización de Face Liveness.