Compartiendo tokens 2FA

Este enfoque aborda dos de los problemas conocidos con las cuentas compartidas:

• "Cuantas más personas tengan una contraseña, más fácilmente se filtrará".
• "Una vez que una persona se marcha, la contraseña debe cambiarse para todos".

No afecta al tercero. Dependiendo de la aplicación, esto puede ser más o menos importante:

• "Cuando el usuario hace un cambio, no hay manera de saber qué persona lo hizo".

Si no está profundamente preocupado por la atribución, pero siente que será más fácil forzar cambios clave y controlar la distribución de claves bajo el nuevo esquema, entonces sí, esto es razonable.

Si está esperando abordar también la atribución, entonces esto no está haciendo un cambio significativo.

Si puede poner su 2FA detrás de un control de aplicación que es / es / por usuario, puede acercarse a todos ellos. Las personas usan sus credenciales individuales para obtener el código 2FA actual de una única ubicación central, luego usan ese código para iniciar sesión en la aplicación y, al correlacionar las dos sesiones, puede determinar quién inició sesión en la aplicación para una sesión determinada. El código siempre está cambiando, y el dispositivo 2FA está centralizado y no se comparte, por lo que los usuarios que salen no tienen acceso continuo. Y con un control de acceso adecuado sobre el acceso al dispositivo 2FA, el problema de fugas se reduce.

Si no puedes evitar usar una cuenta compartida, entonces lo que propones es una solución viable.

Sin embargo, puede ser posible emular cuentas separadas si está dispuesto a realizar un esfuerzo mayor. Cree algún servicio de envoltura que pueda representar al servicio de destino. Cree una cuenta para cada usuario, con 2FA como desee, dentro del contenedor. Cuando un usuario autorizado se autentica en el envoltorio, el envoltorio se autentica en el destino y reenvía la sesión al usuario. De esta manera, solo el reiniciador conoce las credenciales de la cuenta compartida en el destino, y el reiniciador puede registrar qué hicieron los usuarios al usar el objetivo aunque el objetivo no pueda hacerlo.

En términos simples, use un Servidor Jump con 2FA / MFA (autenticación multifactor) frente a su aplicación como capa de seguridad. Por lo tanto, cada usuario debe iniciar sesión utilizando su propia identidad en el servidor de salto y desde allí puede iniciar sesión en el servidor de destino.

Al hacer esto, puede identificar al usuario con los detalles de la sesión en los servidores Jump / target.

Esta es solo una solución alternativa, no es una solución perfecta y puede consultar el siguiente enlace para configurar el servidor de salto:

Servidores Jump para la seguridad