Mejor práctica: “Una clave ssh por usuario” o “múltiples claves ssh por host” [duplicado]

Question

Mejor práctica: “Una clave ssh por usuario” o “múltiples claves ssh por host” [duplicado]

#1 de D.W. (14 votos)
#2 de bobmagoo (3 votos)

19

La semana pasada participé en una conversación sobre qué enfoque de las claves ssh es más "seguro". Tenga en cuenta que al considerar "seguro" intentábamos tener en cuenta el comportamiento humano (la parte más insegura de cualquier sistema de seguridad).

El entorno ssh es principalmente máquinas Unix / Linux (también algunas PuTTY). Los usuarios de ssh son "usuarios humanos" así como "cuentas de automatización" que se utilizan para ejecutar tareas / scripts programados que requieren scp / ssh para copiar archivos o ejecutar comandos remotos.

En un intento por encontrar una mejor práctica para nuestros usuarios, estamos considerando las siguientes recomendaciones:

"una clave ssh por usuario": el usuario genera un solo par de claves y envía la clave pública a nuestro proceso automatizado que copia la clave pública en el archivo authorized_keys del usuario en los hosts donde el usuario puede iniciar sesión. Se le indica al usuario que use la misma clave privada protegida por contraseña en todos los hosts que usa como cliente ssh. Este enfoque da como resultado un par de claves para cada usuario.

“claves ssh múltiples 'por cliente-host'”: los usuarios deben generar un par de claves ssh para cada cliente SSH. El usuario envía la clave pública a un proceso automatizado que copia la clave en el archivo authorized_keys. El archivoised_keys en los hosts donde el usuario puede iniciar sesión. Este enfoque da como resultado pares de teclas “u x c”; donde "u" es el número de usuarios y "c" es el número de clientes.

En nuestras discusiones, hemos notado ventajas / desventajas para cada enfoque. Por ejemplo: el enfoque de "una clave ssh por usuario" tiene la ventaja de impresionar en la mente del usuario la importancia de su única clave, así como la capacidad de auditar la presencia del público del usuario en las auditorías de authorized_key archivos. Por otro lado, el enfoque de "múltiples claves ssh 'por cliente' tiene la ventaja de permitir que las auditorías de archivos autorizadas determinen el usuario y la máquina cliente que puede iniciar sesión, lo que parece particularmente útil para comprender los tipos de acceso. que tienen las cuentas no humanas (ejecutar scripts que llaman a SSH / SCP).

Me gustaría mucho escuchar lo que ha funcionado bien para las personas en este foro. Gracias de antemano.

key-management identity

pregunta Srinivas 20.08.2012 - 18:24

fuente

2 respuestas

Lea otras preguntas en las etiquetas key-management identity

¿Hay algo que obstaculice el cifrado de correo electrónico yendo a la corriente? [cerrado] OAuth2: concesión de credenciales de contraseña del propietario del recurso

score 14 · Answer 1

Le recomiendo que adopte el modelo de "una clave ssh por usuario". Es fácil de usar para los usuarios finales, fácil de explicar a los usuarios y es probable que cumpla con los requisitos de seguridad.

La facilidad de uso es muy importante. Si un mecanismo de seguridad es demasiado difícil de usar, las personas encontrarán una manera de evitar su mecanismo de seguridad. Un mecanismo de seguridad fácil de usar y bastante bueno es mucho mejor que un mecanismo de seguridad difícil de usar que en teoría es altamente seguro (porque en la práctica, si es difícil de usar, probablemente no sea tan seguro como usted) espere que una vez que las personas encuentren una manera de evitar el mecanismo de seguridad para que puedan realizar su trabajo).

Creo que "una clave ssh para máquina cliente, por usuario" es una mala idea. Suena como un desastre. Francamente, parece que las TI se vuelven locas, de una forma que da a la seguridad un mal nombre y hace que las personas odien a los departamentos de TI. ¿Quiere decir que tengo que generar una clave SSH separada para cada cliente y administrarlas todas? ¿Todo por un beneficio de seguridad amorfo que no está claro? Ugh! Odiaría estar a cargo de vender esto a los usuarios.

Sugiero que piense en este tipo de decisiones en términos de "presupuesto de cumplimiento". Sus empleados tolerarán una cierta cantidad de mandatos de cumplimiento molestos (por ejemplo, requisitos de seguridad) impuestos sobre ellos. Hasta cierto punto, seguirán estos mandatos. Sin embargo, si llega a ser demasiado, eventualmente se enojarán y solo harán lo que tengan que hacer para hacer su trabajo, incluso si viola todos los principios de seguridad. Por lo tanto, imponer demasiados requisitos o demasiados inconvenientes puede ser contraproducente para la seguridad. Entonces, antes de imponer cualquier tipo de requisito de seguridad o inconveniencia relacionada con la seguridad a los usuarios, piense con mucho cuidado. Imagina que tienes un presupuesto muy limitado para imponer mandatos. ¿Es este el mejor artículo para gastar su "presupuesto de cumplimiento" limitado?

En una nota relacionada, creo que los beneficios de "una clave ssh para la máquina cliente, por usuario" son bastante menores. No entiendo por qué alguien debería preocuparse tanto por las cuentas en las que puedo iniciar sesión con mi computadora portátil y mi computadora de escritorio. ¿Esto es solo microgestión? ¿A quien le importa? Soy yo, de cualquier manera. Si confías en mí, confías en mí, no importa cuál de mis máquinas esté usando, ¿verdad? No me queda claro que esto es tan importante que harías que las vidas de tus usuarios sean más difíciles debido a ello.

P.S. Mencionas algo sobre la gestión de los privilegios que tienen los no humanos. No seguí exactamente a qué se refería eso. Mencionó scripts que llaman a SSH / SCP, pero ¿quién está invocando esos scripts? Si es una persona, entonces presumiblemente esa persona está autorizando la actividad, ¿verdad? Si no es invocado por una persona, entonces no tengo claro cómo funcionaría eso (según mi experiencia, tales scripts no tienen acceso a su clave privada SSH, ya que no conocen su frase de contraseña y no están adjunta a cualquier sesión de ssh-agent que les permita acceder a su clave privada SSH). No sé si me estoy perdiendo algo importante en esa declaración.

score 3 · Answer 2

Me cuesta mucho pensar que la experiencia del usuario en el enfoque de muchos a muchos será aceptable. La confusión que rodea al tratar de recordar qué par de claves pub / priv va con qué sistema parece demasiado engorroso.

El espíritu del enfoque clave de uno a muchos parece mejor en términos de aspectos de gestión y experiencia del usuario. Digo el espíritu porque creo que si tiene más de un número muy pequeño de usuarios y sistemas, la gestión se volverá difícil rápidamente. Te diriges hacia una solución de administración de acceso centralizada, ¿por qué no ir hasta el final? Configure un servidor LDAP (AD / OpenLDAP / este hilo tiene algunas ideas ), defina roles para sus usuarios, otorgue a esos roles acceso a los servidores / sistemas que necesitan y asigne roles a los usuarios a medida que los necesiten. Esto le permite aprovisionar / desaprovisionar el acceso a muchos sistemas con un simple cambio de rol y mantener todos los registros de auditoría en una ubicación central.

Es una excelente pregunta que merece una reflexión seria sobre la escalabilidad y la funcionalidad de una solución a medida que su organización crece en número y complejidad.