Administrar y almacenar muchas claves SSH en la nube

13

Tengo un grupo de servidores en la nube (~ 50) que necesitan hablar con muchos otros servidores remotos en la nube (~ 4000) mediante SSH. Cada servidor remoto tiene su propia clave SSH, por lo que necesitamos un lugar para almacenar de forma segura todas las claves SSH de estos servidores remotos. ¿Cómo deberíamos guardar estas claves sin guardarlas todas?

¿Cuál es la mejor manera de almacenar de manera segura muchas claves SSH en un lugar y hacer que nuestros servidores las soliciten en tiempo de ejecución?

    
pregunta iCode 04.02.2014 - 05:18
fuente

4 respuestas

18

Tienes que hacer distinciones importantes: hay claves públicas y claves privadas . Cuando se "almacenan de forma segura", piden nociones diferentes de "de forma segura".

Cada servidor SSH posee un par de claves pública / privada. Cada servidor debe generar su propio par de claves, y la clave privada debe nunca abandonar el servidor. La clave pública es pública , lo que significa que todos pueden aprenderla. Cuando se conecta al servidor, esa es una de las primeras cosas que el servidor le dice: su clave pública. Se grita en toda la red. Al tratar con las claves públicas de SSH y su almacenamiento, la pregunta es realmente acerca de integridad : un determinado cliente de SSH debe recordar las claves públicas de todos los servidores de los que quiere hablar. a (el archivo $HOME/.ssh/known_hosts con clientes habituales de Linux SSH); el atacante puede querer incluir una clave pública falsa para ejecutar un servidor falso.

Cada cliente SSH puede poseer un par de claves pública / privada: dicho par de claves se utilizará para la autenticación del cliente por parte del servidor. Si utiliza la autenticación de cliente basada en contraseña, entonces los clientes no tienen tales pares de claves. Si utiliza la autenticación de cliente basada en clave, entonces cada servidor debe conocer las claves públicas de "clientes autorizados" (el $HOME/.ssh/authorized_keys para implementaciones de Linux SSH).

En su caso, tiene 50 clientes SSH que hablan con servidores 4000 SSH. Por lo tanto, utilizando el modelo SSH normal, debería asegurarse de que:

  • Cada uno de los 50 clientes conoce una copia de las claves públicas de los 4000 servidores.
  • Si utiliza la autenticación de cliente basada en clave, cada uno de los 4000 servidores debe conocer una copia de las 50 claves públicas de cliente.

Dadas estas cifras, los archivos relevantes serán voluminosos y la administración de claves será un problema (si agrega un nuevo cliente, la clave pública del nuevo cliente debe importarse a 4000 servidores, con integridad protegida). Se crearon Infraestructuras de clave pública para resolver ese problema. Una instancia en bruto, "oficial" OpenSSH no sabe cómo usar los certificados X.509; sin embargo, existe una versión modificada (consulte también esa pregunta anterior ). Con una base de código SSH compatible con X.509, puede ejecutar su propia Autoridad de Certificación (por ejemplo, el código abierto EJBCA ), y emita certificados para sus clientes y servidores. De esa manera, el cliente y los servidores SSH se enviarán entre sí sus certificados cuando sea necesario, de forma dinámica. Cada máquina solo tendrá que almacenar su propia clave privada y certificado, y también "conocer" el certificado de CA (en el "almacén de confianza" correspondiente). Agregar un nuevo cliente o un nuevo servidor a la mezcla es solo emitir un certificado y el problema de administración se resuelve (o, mejor dicho, se movió : ahora tiene que manejar una PKI).

    
respondido por el Thomas Pornin 04.02.2014 - 15:59
fuente
3

Este es un trabajo para un software de administración de configuración como Puppet, Chef, etc. Fue creado para manejar exactamente este tipo de problemas. Le recomiendo que utilice software de administración de configuración si tiene tantos servidores.

    
respondido por el Matrix 04.02.2014 - 09:01
fuente
3

En lo que respecta a la parte sobre el almacenamiento seguro de claves, una opción es almacenar las claves privadas en un HSM (módulo de seguridad de hardware). Hay algunos proveedores bien conocidos que ofrecen estos, pero hay alternativas. Consulte, por ejemplo, Cryptostick .

La ventaja de usar un HSM es que las claves privadas solo se pueden usar mientras el dispositivo de hardware esté presente en el sistema y no se pueden copiar las claves privadas en otro lugar.

Este tipo de solución también requeriría una auditoría y administración adecuadas de las claves SSH autorizadas en los servidores SSH. De lo contrario, nada impediría a un intruso generar y colocar su propio conjunto de claves en el servidor SSH.

Sin embargo, administrar esas claves es un problema. Existen productos comerciales para administrar las claves SSH pero no conozco ninguna buena solución de código abierto.

Como Thomas dijo que una opción es cambiar a un enfoque basado en PKI, sin embargo, esto requeriría actualizar todos sus clientes y servidores SSH.

Descargo de responsabilidad: trabajo para una empresa que vende un producto comercial de gestión de claves SSH.

    
respondido por el Roman 08.02.2014 - 19:00
fuente
-3

Considere algún software de administración de claves ssh que pueda almacenar y administrar dinámicamente (cambiar) las claves ssh, esto es directamente análogo a un sistema de administración de contraseñas.

Sin embargo, estas soluciones tienen un costo!

    
respondido por el user98173 25.01.2016 - 16:28
fuente

Lea otras preguntas en las etiquetas