Permitir a los usuarios administradores iniciar sesión como otros usuarios

11

¿Cree que es una buena práctica implementar la posibilidad de permitir que un usuario administrador inicie sesión como otro usuario, omitiendo la contraseña? Esto podría implementarse mediante una contraseña maestra o una función dentro de la administración del usuario, "Iniciar sesión como este usuario".

Los administradores están pidiendo una función de este tipo para poder reproducir un problema reportado o verificar si las subvenciones están bien, por ejemplo.

security problem-solving

— Dan McGrath
fuente

99

En general, no es una buena idea en ingeniería de seguridad permitir que las personas inicien sesión como una cuenta compartida (o la cuenta de otras personas, incluso si sus permisos son idénticos). La autenticación debe ser un proceso separado de la autorización. Si las tareas se realizan en cuentas de usuario separadas, son responsables de ello.

— xmm0

1

+1 a Mehrdad Afshari. Me estremezco cada vez que escucho a personas hablando sobre administradores como este.

— Dan McGrath

2

@Mehrdad Afshari y @Dan McG, todo eso es bueno y verdadero, pero ¿qué propone hacer cuando un administrador necesita acceso a una cuenta de usuario en una situación cotidiana? ¿Solicitar al usuario que ingrese sus credenciales? A menudo sucede que para verificar o reproducir un problema, debe verificar la configuración de un usuario específico, especialmente cuando las cuentas están vinculadas a derechos complejos y otras configuraciones que no se pueden reproducir 1: 1 con una cuenta neutral.

— Pekka

44

Lo estás mirando de la manera incorrecta. Si el administrador necesita verificar la configuración de los usuarios, necesitamos desarrollar mejores herramientas para obtener esta información de diagnóstico del usuario. Por ejemplo: si su aplicación en Windows se bloquea, ¿desea que algún administrador de MS en Redmond RDPing en su cuenta de usuario revise las cosas o desea un método altamente automatizado para enviarles la información requerida (a discreción del usuario) ?

— Dan McGrath

2

@Dan: El cliente podría no estar dispuesto a pagar por eso.

15

No, en absoluto. Esto viola la segregación del deber.

También causa estragos en confiar en los registros para mostrar las acciones del usuario.

Si realmente necesita verificar cosas como esta, el administrador también debe tener una (s) cuenta (s) ficticia (s) configuradas como los usuarios. De esta manera, pueden confirmar primero las subvenciones, etc., funcionan correctamente en el usuario de prueba.

Además, los usuarios administradores no siempre deben tener todos los derechos que tiene un usuario. Por ejemplo, un usuario puede tener razones válidas para ver los números de tarjeta de crédito en un sistema. Un administrador no debería; Estos datos no son parte de su trabajo. Una vez más, esto se reduce a la segregación del deber.

Minimice su exposición minimizando la concesión de derechos inapropiados. Esto también debería incluir administradores ...

— Dan McGrath
fuente

2

Si bien tiene puntos válidos, no creo que la respuesta sea tan clara, en algunos casos es la mejor solución.

— sleske

11

Desde el punto de vista de los principios de seguridad y programación limpia, no es una buena idea. Pero puede ser una gran conveniencia en el trabajo diario para el administrador, por eso estoy a favor si se implementa bien.

Para mí, una implementación correcta tendría que cumplir con los siguientes requisitos:

El sistema inicia sesión como el usuario en cuestión, pero omite la autenticación de contraseña si ha iniciado sesión como administrador.
El sistema es consciente a través de un indicador de que este no es el usuario x, sino un administrador que inició sesión como usuario x. Cualquier instalación de registro reflejaría la diferencia.
No hay forma de "salir" del inicio de sesión del usuario al nivel de administrador.

En realidad, esto puede mejorar la seguridad porque el administrador no tiene que buscar y usar las credenciales de los usuarios, lo que en realidad suele ser el caso por las razones que menciona el OP: Algo debe verificarse, probarse, etc. en la cuenta del usuario .

— Pekka
fuente

8

Como siempre ... depende. No hay una respuesta fácil y ambos sistemas se usan en la práctica (por ejemplo, Windows: el administrador no puede iniciar sesión como usuario sin restablecer la contraseña frente a Linux: el administrador puede iniciar sesión como usuario local usando su).

Claramente, no permitir que el administrador inicie sesión como otro usuario es la opción más segura, por lo que debe decidir si la comodidad adicional (poder depurar problemas que solo ocurren para un determinado usuario) supera el riesgo. Si decide implementar tal opción, asegúrese de que haya un registro riguroso, de modo que un administrador (o alguien que haya obtenido una contraseña de administrador) no pueda ocultar sus pistas.

Alternativamente, puede usar el patrón que está usando Windows: un administrador no puede iniciar sesión como otro usuario, pero un administrador puede restablecer la contraseña de un usuario. De esa manera, un administrador puede obtener acceso, pero el usuario siempre sabrá que alguien accedió a su cuenta.

— Heinzi
fuente

Nitpick: sudono inicia sesión como usuario local, solo ejecuta un proceso como usuario (a la ventana "Ejecutar como usuario"). Para iniciar sesión como usuario local, use su. De lo contrario, estoy de acuerdo.

— sleske

@sleske: Por supuesto, gracias por ver esto. Fijo.

@sleske: no necesariamente, mira sudo -i.

— liori

La idea de un 'shell de inicio de sesión' tiene más que ver con el shcomportamiento del ejecutable que con los permisos otorgados. su - usery sudo -u user shconceder el mismo acceso; La diferencia es que shejecuta diferentes scripts de inicio.

— jpaugh

3

Bueno, phpBB3 tiene una funcionalidad de "Prueba de permisos de usuario" para administradores, lo cual es realmente útil. Además, realmente no le permite interferir con la cuenta de ese usuario, sino que solo obtiene la experiencia que tiene, en función de sus permisos.

Pero en realidad iniciar sesión como alguien más viene con una serie de problemas, como otros mencionaron.

— back2dos
fuente

1

Sí, dicha funcionalidad puede ser problemática, pero a veces no hay otra forma, por lo que puede ser necesaria.

Algunos ejemplos:

En Unix / Linux, esta funcionalidad existe ( su - <username>que da el mismo resultado que iniciar sesión como ese usuario, pero no requiere contraseña para root)
la aplicación en la que trabajo también tiene esto, y es esencial para depurar problemas con la configuración personal de un usuario (de los cuales nuestra aplicación tiene muchos)

Como se señaló, si las configuraciones complejas dependen del usuario conectado (variables de entorno, rutas, configuraciones personales en una aplicación), a menudo no hay otra forma práctica de depurar el problema de un usuario.

En cuanto al registro / auditoría: el uso de esta funcionalidad, por supuesto, debe registrarse. Aparte de eso, tendrás que confiar en tu administrador para no abusar de él. Pero eso es válido para los administradores en general.

Si necesita restringir más a sus administradores, necesita algún tipo de sistema MAC (control de acceso obligatorio), sin un administrador "verdadero". Eso es posible, pero mucho más complicado, por lo que es una compensación.

— sleske
fuente