it-swarm-es.com

Seguridad de cifrado de base de datos

Estoy encriptando y desencriptando los datos de mi base de datos desde mi API de aplicaciones web. Si mi servidor web se ve comprometido, ¿qué impedirá que alguien utilice el mismo método para recuperar los datos?

Por ejemplo, digamos que tengo una aplicación PHP en mi servidor web que realiza el cifrado/descifrado de la base de datos. Si el servidor web está comprometido, ¿qué impide que alguien tenga acceso a la clave y descifre los datos? .

El problema no es específico del idioma, el problema es almacenar una clave que la aplicación web puede usar, pero aún así estar segura de alguien que tenga acceso administrativo al servidor.

16
ksexton

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

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

Básicamente, el servidor web llama a un servicio web en el servidor de cifrado, 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 clave, etc. en función del tipo de datos, los 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 la protege primero 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 aún necesitaría 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 una "caja de interrupción" donde se necesitan dos personas distintas para combinar sus partes para obtener la contraseña.

Esto significa que los desarrolladores no tienen que preocuparse por qué algoritmos usar, o por el almacenamiento seguro de claves, ya que está a cargo del servidor criptográfico, y puede actualizar los algoritmos utilizados a medida que su proceso cambia o surgen nuevas reglas sin tener que actualizar nada. que no sea el servidor de cifrado. Solo el proceso que ejecuta la aplicación web puede llamar al servidor criptográfico, 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 cifrados 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 claves y luego llame a la base de datos de almacenamiento de datos para obtener los datos a los que se refieren las claves. Difícil de hacer si el compromiso es solo 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 enraizamiento y el atacante puede tomar su código y hacerse pasar por procesos, bueno, todas las apuestas están canceladas, pero ese siempre será el caso.

5
blowdart

Las respuestas aquí son buenas (tanto @blowdart como @Tate), pero lo importante a tener en cuenta es que si su sitio web se ve comprometido, se acabó el juego en lo que respecta a la seguridad: usted ha sido engañado.

El código de adquisición malicioso puede hacer cualquier cosa que su sitio pueda hacer, incluido el acceso a su código, el proceso en ejecución, la base de datos, etc. Eso significa que, no importa cómo haga su cifrado, no importa dónde ponga su clave, también pueden acceder a él y descifrar sus datos. Lo que sea que intente, es solo oscuridad, en el mejor de los casos, y en el peor de los casos, pueden dejar que SU código haga el trabajo duro de descifrado e interceptarlo después.

7
AviD

En mi opinión, el mejor recurso disponible en este momento con respecto a todo lo relacionado con la seguridad de las bases de datos es el artículo 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 mejor para usted y ejemplos de casos de uso extraídos de implementaciones del mundo real. Si está considerando cualquier proyecto de cifrado o tokenización de bases de datos, este documento debería ahorrarle horas de investigación y tiempo de desarrollo de arquitectura.

http://securosis.com/research/publication/understanding-and-selecting-a-database-encryption-or-tokenization-solution/

Enlace directo a PDF: http://securosis.com/reports/Securosis_Understanding_DBEncryption.V_.1_.pdf

5
Tate Hansen

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, entonces si es secuestrada tendrá suficiente información para descifrar los datos. Realmente tienes que empezar por ahí. Esto significa un par de cosas.

  1. Si confía en que su aplicación descifrará los datos, entonces, si se hace cargo, puede descifrar todos los datos.

  2. Si no confía en su aplicación para descifrar los datos, probablemente se le confiará 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 descifrado. Esto se puede diseñar 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 obtiene 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. Entonces, 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 fusionar este servicio de cifrado/descifrado con la base de datos, pero se podrían escribir libros sobre cómo hacer esto de forma segura para cualquier RDBMS dado y no es una solución simple).

2
Chris Travers

Bastante 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.

Trabajé para un proveedor de cifrado de bases de datos y trabajé en varios proyectos similares implementando nuestra solución D'Amo . Por lo general, ciframos los datos a nivel de la base de datos en función del tipo de base de datos, pero en un caso como este, instalamos un agente de seguridad de cifrado/descifrado (módulo) en el servidor web que se puede controlar de forma remota para configurar las políticas enc/dec que se seguirán durante operación.

Nuestro consejo general es almacenar las claves en un servidor de administración de claves (KMS) separado y dedicado que también podríamos proporcionar.Algunos clientes incluso dieron un paso adicional para solicitarnos o comprar a una empresa externa un módulo de seguridad de hardware (HSM) para gestión de claves. Dado que nuestra solución se basa en columnas, había diferentes claves para cada columna cifrada. Además, la comunicación entre el Security Agent y el KMS debe asegurarse para evitar un ataque MITM cuando el Security Agent obtiene las claves del KMS.

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

1
NA AE