Estoy trabajando en un servidor web que almacena recursos en Redis . Para hacer que los despliegues de enjambres sean lo más fáciles posible, estoy implementando una opción donde el servidor no necesita acceder al sistema de archivos para obtener datos operativos.
El protocolo de comunicación de Redis es de texto claro. Eso está bien porque la mayoría de los activos no son confidenciales y no se espera que el usuario haga accesible el enjambre Redis desde Internet. Excepto las claves privadas del certificado TLS, que también deben almacenarse en la base de datos de Redis. Si un atacante obtiene acceso a cualquiera de las estaciones en la subred privada con acceso al enjambre Redis, no necesitaría nada más para conectarse a Redis y buscar dicha clave.
Así que mi primera idea para una solución fue cifrar la clave del certificado TLS antes de almacenarla. Pero luego necesito proporcionar cada proceso en mi enjambre con la clave de cifrado simétrica. Ahora, aparentemente, no es seguro proporcionar esa clave de cifrado simétrica a través de los parámetros de la línea de comandos. Por ejemplo, si lo hago:
$ cat /proc/6630/status
...
Uid: 0 0 0 0
...
y luego
$ cat /proc/6630/cmdline
/sbin/dhclient-d-sf/usr/lib/NetworkManager/nm-dhcp-client.action-pf/run/sendsigs.omit.d/network-manager.dhclient-eth0.pid-lf/var/lib/NetworkManager/dhclient-90380716-3851-4c0f-98c5-aaf16acdc395-eth0.lease-cf/var/lib/NetworkManager/dhclient-eth0.confeth0
desde una cuenta normal, veo que un usuario con privilegios mínimos puede perfectamente detectar parámetros de línea de comandos de procesos iniciados por cualquier otro usuario, por ejemplo, root. Por lo tanto, el uso de un parámetro de línea de comando aún no es lo suficientemente bueno.
Tengo la opción 2: almacenar la clave privada en una ubicación protegida en el sistema de archivos. Esta única opción anula mi intención de que el servidor no acceda al sistema de archivos. Y la opción 3, para almacenar parte de la clave de cifrado simétrica en el binario del servidor web en sí mismo y ofrecer a las personas una forma de personalizar el fragmento de clave. Al menos en teoría, con la opción 3, un atacante tendría que estar registrado en una estación que ejecuta el servidor web y tener suficientes privilegios para leer el binario del propio servidor web. Esto es equivalente a la situación actual del status quo donde la clave privada se almacena en un archivo protegido en el servidor.
La opción 4 es colocar la clave simétrica en una variable de entorno, al parecer eso es más seguro:
$ cat /proc/6630/environ
cat: /proc/6630/environ: Permission denied
¿Hay una manera de evitar las fugas de la clave a través de /proc/<PID>/cmdline en el escenario 1? En el escenario 4, ¿hay alguna forma en la que el entorno de un proceso pueda filtrarse y no lo haya tenido en cuenta? Y finalmente, ¿hay alguna otra opción de diseño obvia que no haya tenido en cuenta?