¿Puede un empleado robar la clave privada del certificado SSL de una empresa?

1

¿Es posible que un empleado deshonesto solo inicie sesión en un servidor de la empresa y robe las claves privadas utilizadas para asegurar las conexiones SSL? ¿Es tan fácil como copiar un archivo?

(Leí algunas preguntas en las que se centraba en lo que sucedía después de que se robara un certificado. Aquí, quiero saber qué tan fácil es obtener información confidencial de las personas con información privilegiada.)

Gracias.

    
pregunta Guest 03.08.2016 - 20:37
fuente

3 respuestas

6
  

¿Es posible que un empleado deshonesto solo inicie sesión en un servidor de la empresa?   ¿Y robar las claves privadas utilizadas para asegurar las conexiones SSL?

Sí, excepto cuando es difícil o cuando es imposible.

  

¿Es tan fácil como copiar un archivo?

Aquí es donde entra la gradación. Hay una gran variedad de niveles de seguridad, algunos de los cuales describiré aquí de fácil a difícil:

  1. En el caso más sencillo, sí, la clave privada es un archivo de texto simple (PEM), y puede que ni siquiera tenga las protecciones de archivos adecuadas *

  2. O el archivo de clave puede almacenarse con permisos restrictivos. Ahora el empleado no solo necesita estar en el servidor, sino que también debe tener los privilegios adecuados (administrador o aplicación) para copiar la clave.

  3. El archivo de clave puede estar protegido por contraseña pero automatizado. Por lo general, esto solo significa que, además del archivo de claves, el empleado debe encontrar el archivo de configuración con la contraseña almacenada y robarlo también. (Consulte también "java keystore changeit" ...)

  4. El archivo de clave podría estar protegido por contraseña y la clave ingresada en tiempo de ejecución por un operador humano. En este caso, la contraseña no puede simplemente ser robada del sistema. Por supuesto, su empleado podría ser un operador ... Además, en términos prácticos, muy pocos servidores se ejecutan para requerir intervención humana al reiniciar.

  5. Si recuerdo correctamente, IIS solía poder importar la clave en un almacén de claves que no era exportable por los usuarios, pero permitiría el uso por parte de los servicios. Estas cosas generalmente se pueden solucionar con suficientes privilegios.

  6. Finalmente, si se usa un Módulo de seguridad de hardware (HSM), que está diseñado para proteger las claves incluso desde el propio sistema operativo, para permitir su uso a través de operaciones criptográficas sin exponer las claves al hardware y software de la computadora. . En este caso, es probable que el empleado encuentre la clave imposible de robar.

  

Aquí, quiero saber cuán fácil es para un interno obtener las claves privadas.

Dependerá del sitio, pero en general, mi experiencia ha sido que la mayoría de los sitios almacenan la clave con nada más que permisos de archivo para protegerla. El sentido general es "Bueno, si alguien irrumpe en el servidor, ya ha recibido todo, y tendremos que emitir una nueva clave de todos modos cuando nos recuperemos". Por supuesto, esto ignora

  • la brecha entre compromiso y descubrimiento, y
  • el uso potencial de una clave privada para leer silenciosamente el tráfico mientras tanto.

El cambio hacia los cifrados TLS efímeros está cerrando lentamente esa segunda brecha, lo que hace que la clave privada sea mucho menos útil (a menudo la indagación es más valiosa que la suplantación; la suplantación se puede lograr de otras formas (posiblemente más simples)).

* Vamos, muchachos, no pretendan que no han visto una docena de configuraciones de Apache mal aseguradas donde las claves se dejaron legibles en todo el mundo.

    
respondido por el gowenfawr 03.08.2016 - 21:17
fuente
2

Puede o no puede ser. Las claves se pueden almacenar en:

  • Archivos en el sistema de archivos de los servidores que atienden las solicitudes de los clientes. Más barato, pero menos seguro; Como señala, los empleados deshonestos pueden copiar el archivo con la clave privada.
  • En un módulo de seguridad de hardware , que genera claves internamente y no permite que los clientes externos lean las claves privadas— solo realiza operaciones criptográficas a petición del cliente. Esto es más seguro, pero también mucho más caro.

Además, existen salvaguardas en forma de:

  1. Cadenas de certificados: los servidores de aplicaciones para el usuario preferiblemente no deberían tener el certificado "maestro", sino un certificado secundario firmado por el maestro.
  2. Revocación de certificado : si se considera que la clave privada de un certificado está comprometida, puede agregarse a una lista de revocación de certificados y publicarse .
  3. Caducidad del certificado: los certificados especifican una fecha después de la cual no deben aceptarse. Esto protege contra la divulgación no detectada al limitar el período de utilidad de dicho certificado.
respondido por el Luis Casillas 03.08.2016 - 21:09
fuente
0

Si la empresa tiene empleados deshonestos, tiene un problema. El empleado solo debe tener los derechos que realmente necesita. Y si necesita los derechos para configurar un servidor, es muy probable que tenga derecho a leer un archivo de clave privada. Así es como un empleado decide ir malicioso, usted tiene un problema. Si es esta misión crítica, debe implementar reglas de dos hombres.

Si está utilizando HSM, habrá un empleado que podrá generar pares de claves y respaldar las claves privadas de un HSM. Y si este empleado se está volviendo imprudente, también podría recuperar la copia de seguridad de la clave privada y todos los medios para restaurarla (dependiendo del HSM utilizado).

Nuevamente, este es un lugar para implementar los procesos correctos y las reglas de dos personas.

    
respondido por el cornelinux 03.08.2016 - 22:49
fuente

Lea otras preguntas en las etiquetas