Almacenamiento seguro de claves

Question

Almacenamiento seguro de claves

#1 de Gilles (1 votos)

2

Tenemos una solución de seguridad que se implementa en las instalaciones de empresas con grandes infraestructuras técnicas. Hacemos una evaluación de la vulnerabilidad / configuración en tiempo real de todos los activos críticos en la red.

El servidor de aplicaciones (denominado "nuestro servidor") tiene servicios que generalmente se conectan a otros activos (como servidores Linux, dispositivos de red, etc.) a través de una Administración de acceso privilegiado (PAM) que es propiedad del cliente. Una vez que se realiza la conexión, los datos relevantes se envían a nuestro servidor para su posterior procesamiento y luego se insertan en la base de datos.

Tenemos otro grupo de clientes que no tienen un PAM y almacenamos la clave privada en nuestra base de datos utilizando AES-256. Las claves AES respectivas se almacenan en el mismo servidor. No podemos usar algo como PBKDF2 o bcrypt para almacenar estas contraseñas porque deben usarse para hacer conexiones periódicas a todos los activos.

Nuestro equipo de VAPT fortalece y supervisa continuamente nuestro servidor, por lo que las posibilidades de que se comprometa son muy pocas. En el peor de los casos, si el servidor se ve comprometido, se convierte en una puerta para la infraestructura de red completa. Cuál es la principal preocupación de algunos de nuestros posibles clientes. En este momento, la respuesta y el plan es revocar el acceso a las claves y eliminar las claves públicas correspondientes de todos los activos.

¿Existe alguna forma en la que podamos almacenar las claves, reutilizarlas y, al mismo tiempo, protegerlas de cualquier persona (autorizada / no autorizada) que tenga acceso a nuestro servidor? Estamos evaluando algunos HSM aunque preferiríamos una solución que no incluya hardware adicional.

PS: No queremos una intervención manual cada vez que nuestra aplicación necesita conectarse a servidores remotos. (Inverso) Todos los servidores / activos que se conectan a este nodo central tampoco son preferibles.

TL DR: ¿Cómo puede FileZilla almacenar las credenciales de forma segura?

password-management key-management key-exchange key-generation

pregunta Nakul 18.05.2018 - 19:31

fuente

1 respuesta

Lea otras preguntas en las etiquetas password-management key-management key-exchange key-generation

Windows: ¿Cuáles son las implicaciones de seguridad de agregar una cuenta de servicio de red al grupo de "Lectores de registro de eventos"? certificado SSL para WebAPI

score 1 · Answer 1

Su servidor necesita poder acceder a la clave. Por lo tanto, cualquier atacante que pueda ejecutar código en su servidor puede acceder a la clave de la misma manera. Cualquier seguridad adicional solo puede limitar el impacto de la infracción dentro de esta restricción.

Hay un pequeño beneficio al poner la clave en un procesador separado, y permitir que el servidor solo realice solicitudes a este procesador separado (derivación de la clave, firma, descifrado según la función de la clave) y no vea los bits reales de la clave. Suponiendo que el procesador independiente no esté violado, esto significa que un atacante que incumpla el servidor tiene que seguir usando el procesador separado si desea seguir usando la clave.

Esto no evita que el atacante cause daño, pero significa que necesitan tener una presencia más activa y sostenida. No pueden simplemente obtener la clave, descargarla y borrar sus huellas. Esto aumenta la posibilidad de que detectes la violación. Además, en caso de una infracción, es probable que esto le brinde una evaluación más precisa, ya que es más probable que tenga registros confiables que indiquen lo que hicieron los atacantes (y no lo hicieron).

Otra ventaja es que si vuelve a instalar el servidor después de una infracción (aún suponiendo que no se haya violado el procesador por separado), el atacante ya no tiene acceso a la clave antigua, por lo que no necesita rotarla. No creo que esto importe en tu escenario; es principalmente importante para las claves privadas cuando la clave pública correspondiente se ha implementado ampliamente (por ejemplo, para una autoridad de certificación, esto puede hacer la diferencia entre tener que revocar una lista conocida de certificados y esencialmente cerrar el negocio porque ya nadie confía en usted) .

El procesador separado puede ser un módulo de seguridad de hardware adecuado, pero hay opciones más baratas. Un HSM está protegido contra la intrusión física, y eso es una parte importante de su costo. El solo hecho de colocar la llave en un servidor dedicado y separado le brinda tanto beneficio contra los ataques a la red. Incluso puede ser una máquina virtual, pero la superficie de ataque es mayor debido al riesgo de canales laterales de máquinas virtuales cruzadas y de ataques contra el hipervisor. Otra solución de bajo costo es una tarjeta inteligente, pero el ancho de banda es muy limitado.

Tenga en cuenta que la configuración tiene un costo: solo es útil si el procesador separado nunca revela la clave. El procesador puede firmar datos, descifrar tokens o derivar claves de sesión, pero nunca permite que la clave a largo plazo lo deje. No todo el software es compatible con esto, pero estas características pueden proporcionarse de forma genérica mediante una biblioteca criptográfica, por ejemplo, a través de motores externos en OpenSSL.

Si coloca la clave en un procesador separado, no olvide la redundancia: no podrá recuperar esa clave simplemente restaurando una copia de seguridad.