¿Cómo mantengo confidencial la clave ssl de nuestro sitio web?

Quiero mantener confidencial nuestra clave SSL para nuestro sitio web. Se almacena en 2 memorias USB, una en una caja de seguridad y otra que mantengo segura. Y luego soy el único que lo aplica al servidor web para que sea totalmente seguro.

Excepto...

Al menos en IIS, puede exportar la clave. Entonces, cualquier persona que sea administrador puede obtener una copia de la clave. ¿Hay alguna forma de evitar esto? ¿O, por definición, todos los administradores tienen acceso completo a todas las claves?

Actualización: tengo administradores de sistemas en los que confío plenamente. Lo que llevó a esto es que uno de ellos renunció (tenían una hora de viaje diario a nuestra empresa, un viaje de 5 minutos a la nueva). Si bien confío en esta persona, al igual que deshabilitamos su cuenta de Active Directory cuando alguien se va, pensé que deberíamos tener una manera de asegurarnos de que no conserven la capacidad de usar nuestro SSL.

Y lo que me pareció más fácil es si soy el único que lo tiene. Nuestro certificado expira en enero, así que este era el momento de cambiar la práctica si pudiéramos. Según las respuestas, parece que no podemos.

Entonces, esto lleva a una nueva pregunta: cuando alguien que tiene acceso al certificado se va, es una práctica habitual obtener un nuevo certificado y revocar el existente. O si la persona que se fue es confiable, ¿continuamos con el certificado que tenemos?

Una persona con acceso administrativo (o incluso físico) a un servidor podrá extraer la clave privada. Ya sea a través de la exportación, el rastreo de memoria u otro truco similar.

Sus administradores tienen acceso a las claves privadas de sus servidores web. Acepte esto como un hecho y evite eso. Si sus administradores de sistemas no son confiables, entonces puede necesitar mejores administradores de sistemas o al menos menos administradores de sistemas con acceso a los servidores web. Si se trata de una paranoia de seguridad de la administración, entonces puede haber un problema más profundo con respecto a su capacidad de confiar en un administrador de sistemas.

Esto no quiere decir que deba permitir que todos tengan acceso a la clave privada. Siempre debe haber una necesidad de acceso antes de que se otorgue el acceso. Con eso en mente, ¿va a tomar medidas extremas para asegurarse de que un administrador de sistemas con control total de un sitio web no pueda exportar la clave privada, pero aún puede manipular el sitio web de varias maneras casi imposibles de rastrear? Hemos vuelto a confiar aquí, y creo que ese es el núcleo del problema que debe abordarse.

Cuando importa la clave, tiene la opción de marcarla como no exportable. Esto evitará que use IIS o el certificado MMC para exportarlo. Al menos, lo hace un poco más difícil.

Sin embargo, si tienen una cuenta de administrador en la máquina o tienen acceso físico a ella, aún podrán obtener la clave a través de otros medios.

Aquí es donde una "CA intermedia" puede ayudar.

La "CA raíz" en este ejemplo a continuación es propiedad de una compañía SSL y no de usted.

No tiene control directo de las claves creadas por la CA raíz, por lo que si una clave firmada por la CA raíz se ve comprometida, debe revisarlas para revocarla.

Pero:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key for site

Si coloca otra CA en el medio y hace que su certificado SSL comprado firme su propio certificado de CA en lugar de firmar directamente su certificado de servidor, puede retener el control de los certificados de servidor a continuación y emitir certificados de revocación o hacer cualquier otra cosa si las cosas debajo están comprometidas .

Mantiene la clave privada de CA intermedia para usted y los administradores no necesitan verla.

También puedes hacer esto:

Root CA (SSL company)
 |
 +-Intermediate CA (You)
   |
   +-Server Key 1 for site
   +-Server Key 2 for site 
   +-Server Key 3 for site

Puede prepararse para el compromiso y generar certificados con anticipación, por lo que puede cambiar rápidamente en caso de que se revoque una clave individual. Los administradores no obtienen claves para 2 o 3 hasta el compromiso de 1. Puede poner un aviso en su sitio acerca de este esquema, y ​​esto también comunicaría a sus administradores que está listo en caso de un compromiso y ese negocio divertido en su Fin no destruirá su sitio.

Hay muchos artículos que sugieren almacenar las claves privadas en otro lugar que no sea el servidor, pero esas claves privadas son para certificados de firma de código . Imagine que tiene las claves en una computadora fuera de línea a la que solo tiene acceso, parte del software está escrito, obtiene la clave privada del servidor fuera de línea, firma el código y luego no necesita la clave privada nuevamente hasta que necesite firmar alguna. código de nuevo.

La mejor solución siempre ha sido y seguirá almacenando su clave fuera de línea. La forma en que lo haga depende completamente de usted (hay algunos métodos), solo recuerde mantenerlo bien guardado en una oficina segura o en un lugar que no sea fácil de guardar.

Lea más en: https://www.thesslstore.com/blog/heres-what-happens-when-your-private-key-gets-compromised/

Por el contrario, los certificados SSL son para sitios web que permiten la comunicación HTTPS: la clave privada es necesaria durante cada apretón de manos por parte del servidor web. Por lo tanto, almacenarlo sin conexión no funcionará.