A veces es un error humano, otras la debilidad inherente de un determinado sistema o infraestructura… En cualquier caso, podemos tomar medidas para evitar desastres como el que leí recientemente de D-Link, en el que a alguien se le fue la pinza y publicó la clave utilizada para la firma digital del software legítimo de la compañía. Si esa clave cae en malas manos, puede llegar a firmar software ilegítimo o malicioso para hacerlo pasar por legítimo, y los usuarios tendrían muy difícil determinar que están siendo engañados, para hacernos a la idea del alcance de la situación….
Así pues, hay algunas cuestiones a tener en cuenta a la hora de tratar con claves privadas. Como en todo, hay distintos enfoques sobre este tema y cada cual adoptará uno u otro en función de las necesidades particulares:
- Recomendable elegir con mucho cuidado el propietario de la clave. Hay distintas formas de entender este tema según el software con el que estemos tratando. Por ejemplo, en el caso de Apache puede ponerse que el propietario sea el usuario que va a ejecutar Apache, que suele ser
www-data. Otro approach distinto es el de distros como Ubuntu, que guarda la clave privada con ownerroot, grupossl-certsy permisos640. - ¿Permisos? Suelo poner 400, o lo que es lo mismo, únicamente de lectura para el propietario de la clave, aunque como comentaba anteriormente Ubuntu enfoca este tema de manera distinta. Recordad que en Linux el esquema de permisos es
propietario-grupo-otros, y que lo que tendremos que evitar a toda costa es que “otros” puedan ver la clave, de ahí que sea importante aplicarle siempre el valor 0. - ¿Ponerle una frase de paso? (passphrase) Siempre es una posibilidad, pero complica mucho la gestión especialmente en los servidores web. Por ejemplo para cada reinicio de Apache tendremos que introducir la frase, lo cual se puede volver tedioso si administramos muchos servidores.
- Nunca jamás intercambiar claves privadas por medios inseguros como correo electrónico. De hecho, diría que la clave privada no debería salir del servidor donde se está haciendo uso de ella.
- No dejaría la clave privada en directorios compartidos. Puede resultar obvio pero en algunas infraestructuras las claves privadas/públicas se dejan en un directorio compartido (por ejemplo por NFS) para que puedan acceder varios servidores webs a esa localización. El problema es que si se compromete ese recurso compartido se compromete a su vez la seguridad de todos los servidores web que tienen sus claves públicas/privadas alojadas allí.
- Recordar que las claves privadas según los estándares actuales deben tener una longitud mínima de 2048 bits para considerarse seguras.
Como véis no hay una sóla manera de hacer las cosas… pero merece la pena darle una pensada a estos temas cuando trabajamos con infraestructuras PKI para reducir al mínimo las posibles brechas de seguridad. Muchas veces se trata de un tira y afloja entre flexibilidad de uso/administración y el nivel de seguridad que queramos implementar.