¿Cuál es el mejor lugar para ocultar las claves de cifrado de larga duración?

0

Estoy considerando las opciones de cifrado para un nuevo proyecto de Sybase (solo con orientación interna, en nuestra intranet) para un cliente que tiene una política de seguridad que requiere que todos los datos confidenciales utilicen el cifrado de base de datos y solo esté disponible para unos pocos de confianza. Estoy pensando que el cifrado de Sybase es la estrategia equivocada porque a) los dba pueden ingresar fácilmente, yb) si y cuando migramos a SQL Server u Oracle, no quiero tratar con diferentes estrategias de cifrado.

Por lo tanto, estoy pensando en mantener una sola tabla de datos confidenciales y cifrar esa columna (cifrado simétrico) en mi código Java antes de almacenarlo en la base de datos.

Ahora, es mejor que los campos encriptados no cambien su clave de encriptación, excepto en un entorno muy controlado, lo que para mí significa "nunca". Así que será una contraseña permanente.

La pregunta es, dónde guardarlo. Si está en un archivo de propiedades, cualquier desarrollador con acceso a nuestro repositorio de Git podría verlo.

Podríamos codificarlo en el código fuente, pero buena ley, esa es una mala práctica.

¡Podríamos generarlo en la fuente, como el 10º Fibonacci o 3! +8! eso sería difícil de localizar, pero aún está bastante expuesto.

Podríamos hacer que las sa lo mantengan en el entorno, pero ¿dónde lo archivan para futuras consultas?

Tantas malas elecciones. ¿Hay alguna buena?

    
pregunta Victor Grazi 20.05.2016 - 22:06
fuente

2 respuestas

4

Bueno, si realmente estás realmente serio acerca de la seguridad de tus claves, entonces solo hay una respuesta.

HSM

Cifre sus datos en reposo utilizando un algoritmo simétrico y cifre las claves utilizadas para el algoritmo simétrico utilizando claves asimétricas, la clave privada se almacena en el HSM.

Los HSM se diseñan de manera cuidadosa y deliberada para que una vez que estén en ellos, las claves no puedan exportarse desde ellos. Envía un comando al HSM pidiéndole que "haga algo" con su clave (por ejemplo, cifrar, firmar, descifrar), pero la clave nunca deja el HSM en un formato legible, ya sea impreso en la consola o exportado a un archivo.

Si no puede justificar el costo de un HSM porque sus datos no son lo suficientemente valiosos o simplemente no puede obtener el presupuesto, entonces la opción "la mejor opción" probablemente será un "HSM en la nube" alojado.

Claro, hay riesgos relacionados con un tercero que aloja tu HSM, pero esos riesgos probablemente sean más bajos que los que intentas ser inteligente (y en su defecto) ofuscando tus claves y tratando de "esconderlas" solo porque no lo haces. No quiero pagar por tu propio HSM.

    
respondido por el Little Code 20.05.2016 - 23:25
fuente
2

Su problema es menos acerca de los lugares donde colocar las cosas y más acerca de en quién confiar. Pase lo que pase, la contraseña se almacenará en algún lugar al que alguien tenga acceso. Tienes que confiar en esa persona o personas.

La opción más lógica es limitar el acceso solo al entorno donde se ejecuta el código. Eso significa un conjunto limitado de administradores de sistemas. Estas personas tienen acceso a la raíz de todos modos, y si REALMENTE quisieran los datos, encontrarían la manera de obtenerlos.

Ahora, TAMBIÉN necesitas almacenar la contraseña en algún lugar si la "ubicación secreta" se quiebra. Una opción es simplemente algún tipo de almacenamiento en frío, poner en una caja de seguridad en el banco local. Los bancos son buenos para mantener las cosas seguras y solo dan acceso a las personas autorizadas correctas que usted mantiene archivadas con ellos.

    
respondido por el Steve Sether 20.05.2016 - 22:49
fuente

Lea otras preguntas en las etiquetas