¿Cómo administrar una protección de clave privada SSL de servidores web (contraseña versus sin contraseña)?

Tenemos una discusión en el grupo de seguridad de mi compañía sobre cuál es la peor de las siguientes opciones para administrar la clave privada SSL.

El servidor web necesita acceso a la clave privada para la operación de cifrado. Este archivo debe estar protegido contra el acceso no autorizado. Al mismo tiempo, el servidor debe iniciarse automáticamente, sin intervención humana (si es lo suficientemente seguro).

Estamos discutiendo tres opciones:

1. Proteja la clave con permisos del sistema de archivos.

2. Use una clave protegida por contraseña e ingrese la clave manualmente en cada reinicio.

3. Use una clave protegida por contraseña y almacene la clave en el sistema de archivos para automatizar el reinicio.

Nuestras preocupaciones son las siguientes:

1. Con la opción 1, los reinicios son automáticos, pero un compromiso podría copiar la clave privada y, como no está protegido, podría usarse para descifrar la comunicación o hacerse pasar por nuestros servidores.

2. La opción 2 parece más segura, pero necesita intervención humana y los administradores de sistemas están preocupados si ocurre fuera de horario. Además, la contraseña debe compartirse con varios administradores de sistemas y usted sabe que un secreto compartido ya no es un secreto.

3. La opción 3 tiene la mejor de las dos opciones anteriores, pero si alguien tiene acceso a la clave también podría tener acceso a la contraseña :(, por lo que no parece tan segura en absoluto.

¿Cómo gestiona la seguridad de las claves privadas de sus servidores? ¿Hay alguna otra opción (más segura)?

La opción 1 es, creo, el estándar aceptado.

Sin embargo, si realmente desea la seguridad adicional, ¿por qué no tiene un servidor seguro (no en su DMZ) configurado para monitorear su servidor web, y si apache se cae, puede iniciar sesión automáticamente de forma remota y reiniciar apache , suministrando la frase de contraseña

Entonces, la frase de contraseña se mantiene en una computadora, pero no es la misma que se está ejecutando Apache, y no en su DMZ. Obtiene la seguridad adicional de usar una frase de contraseña y mantiene la capacidad de reiniciar automáticamente.

Si alguien tiene acceso suficiente al servidor para leer la clave, lo más probable es que también tenga acceso suficiente para adjuntar un depurador y obtener la clave de la memoria.

A menos que realmente le guste despertarse en medio de la noche para escribir las contraseñas, vaya a la opción 1. Cuando tiene muchos servidores, desea reiniciar automáticamente en caso de falla, y la opción 2 no lo permite.

Una posibilidad de mayor seguridad que 1. pero menos tiempo de inactividad que 2. es crear claves privadas con una corta validez y reciclarlas regularmente. De esa manera, puede almacenarlos sin frase de contraseña pero reducir la ventana de vulnerabilidad.

Como reconoció, la opción 3. no proporciona ninguna seguridad adicional sobre 1.

La practicidad dicta que en casi todas las situaciones terminarás usando la opción (1). Los permisos del sistema de archivos son la mejor manera de avanzar en la mayoría de los escenarios de seguridad frente a los prácticos.

En un sistema * nix, puede restringir la clave privada solo a root, ya que la mayoría de los buenos servidores web (como apache) comenzarán como root pero degradarán sus privilegios a un usuario restringido una vez que tengan los puertos privilegiados que necesitan (80, 443, etc.) .

Como mencionó, la opción (3) es desde el punto de vista de la seguridad lo mismo que la opción (1).