Seguridad de cifrado de base de datos

Cuando hice esto, aparté el cifrado del servidor web por completo. Básicamente he tenido el siguiente escenario

• Un servidor de base de datos que almacena el datos encriptados
• Un servidor web que ejecuta la aplicación y almacena / recupera datos encriptados
• Un servidor criptográfico que realiza la cifrado y descifrado y que está bloqueado

Básicamente, el servidor web llama a un servicio web en el servidor criptográfico, que solo está disponible en una red interna y dice "Aquí hay algunos datos y el tipo de datos". El servidor criptográfico toma una decisión sobre el tamaño de la clave, la caducidad de la misma, etc. según el tipo de datos, la cifra con una nueva clave simétrica y sal y devuelve un blob binario más un identificador de clave. Luego, el servidor criptográfico almacena la clave en su propia base de datos SQL, pero primero la protege con un certificado X509, al que solo tiene acceso el servicio criptográfico, por lo que si logra acceder a la base de datos de forma remota, es inútil, ya que todavía necesitará acceso al sistema operativo. para obtener el certificado X509 para descifrar las claves, y en cualquier caso, los datos se guardan en otro lugar.

Las contraseñas de administrador del servidor de cifrado se guardan en un "cuadro de interrupción" donde se necesitan dos personas separadas para combinar sus partes para obtener la contraseña.

Esto significa que los desarrolladores no tienen que preocuparse por los algoritmos que deben usar o el almacenamiento seguro de claves, ya que el servidor criptográfico se encarga de ellos, y usted puede actualizar los algoritmos utilizados a medida que su proceso cambia o surgen nuevas reglas sin tener que para actualizar cualquier cosa que no sea el servidor criptográfico. Solo el proceso que ejecuta la aplicación web puede llamar al servidor de cifrado, las cuentas de usuario normales o incluso las cuentas de administrador no pueden. Los administradores de bases de datos que pueden ver la base de datos web solo ven datos encriptados y tampoco pueden acceder a las claves.

Incluso si el servidor web está comprometido, todavía está limitado en lo que puede hacer, llame al servidor de cifrado para obtener las claves y luego llame a la base de datos de almacenamiento de datos para obtener los datos a los que se refieren las claves. Es difícil de hacer si el compromiso es simplemente la capacidad de ejecutar código arbitrario, sin saber cómo suceden estas cosas o dónde se encuentran los servidores en la red interna.

Por supuesto, si el compromiso es un arraigo, y el atacante puede tomar su código y hacerse pasar por procesos, todas las apuestas están desactivadas, pero ese siempre será el caso.

Las respuestas aquí son buenas (tanto en @blowdart como en @Tate), pero lo más importante a tener en cuenta es que si su sitio web está comprometido, es una cuestión de juego en lo que respecta a la seguridad: ha sido pwned.

El código de adquisición malintencionado puede hacer cualquier cosa que pueda hacer su sitio, incluido el acceso a su código, el proceso de ejecución, la base de datos, etc. Eso significa que, independientemente de cómo realice el cifrado, sin importar dónde lo coloque. Su clave, ellos pueden llegar a ella y descifrar sus datos también. Lo que sea que intente, es simplemente oscuro, en el mejor de los casos, y en el peor de los casos, pueden dejar que SU código haga el trabajo de desencriptación e interceptarlo después.

El mejor recurso disponible en mi opinión en este momento con respecto a todo lo relacionado con la seguridad de la base de datos es el documento de Securosis:

  

Comprensión y selección de una solución de cifrado o tokenización de base de datos
  Este documento incluye descripciones de las principales tecnologías de cifrado y tokenización de bases de datos, un árbol de decisiones para ayudar a determinar qué tipo de cifrado es el mejor para usted y ejemplos de casos de uso extraídos de implementaciones del mundo real.   Si está considerando algún proyecto de cifrado o tokenización de la base de datos, este documento le ahorrará horas de investigación y tiempo de desarrollo de la arquitectura.

enlace

Enlace directo a PDF: enlace

Primero, este es un problema extremadamente difícil. El problema básico es que si su aplicación web tiene el conocimiento suficiente para descifrar los datos, si se secuestra, tendrá información suficiente para descifrar los datos. Realmente tienes que empezar allí. Esto significa un par de cosas.

1. Si confía en su aplicación para descifrar los datos, entonces si se toma el control, puede descifrar todos los datos.

2. Si no confía en su aplicación para descifrar los datos, es probable que se le confíe algún conjunto de texto sin formato.

Una opción es tener un servicio entre su aplicación y la base de datos que maneja el cifrado y el descifrado. Esto puede diseñarse de modo que dos personas necesiten trabajar juntas para almacenar las claves en la memoria, pero incluso si ese no es el caso, aún obtienes algo de defensa en profundidad. Si se toma el control de su aplicación web, solo obtiene acceso a lo que el servicio de descifrado puede obtener, por lo que la mitigación puede ser parte de esa estrategia. Un atacante tendría que comprometer su servicio de descifrado / cifrado para acceder a datos sin procesar (defensa en profundidad en el trabajo).

(Para ser honesto, tiendo a combinar este servicio de cifrado / descifrado con la base de datos, pero se pueden escribir libros sobre cómo hacer esto de manera segura para cualquier RDBMS dado y no es una solución simple).

Muy buenas respuestas en este hilo. Básicamente, esto se debe a dos problemas principales, a saber, el método de cifrado y el almacenamiento de la clave de cifrado.

He trabajado para un proveedor de cifrado de bases de datos y he trabajado en varios proyectos similares implementando nuestra solución D'Amo . Por lo general, los datos encriptados en el nivel de la base de datos dependen del tipo de base de datos, pero en un caso como este instalamos un agente de seguridad (módulo) de encriptación / descifrado en el servidor web que se puede monitorear de forma remota para configurar las políticas de enc / dec que se deben seguir durante operación.

Nuestro consejo general es almacenar las claves en un Servidor de administración de claves (KMS) dedicado y separado que también podríamos proporcionar. Algunos clientes incluso tomaron un paso adicional para solicitarnos o comprar a un tercero un Módulo de seguridad de hardware ( HSM) para la gestión de claves. Debido a que nuestra solución se basa en columnas, hubo diferentes claves para cada columna encriptada. También es necesario asegurar la comunicación entre Security Agent y KMS para evitar un ataque MITM cuando Security Agent obtiene las claves de KMS.

Divulgación: Soy ingeniero en Penta Security Systems Inc.