¿Cómo mitigar el daño de un volcado de base de datos?

Usted tiene razón al encriptar los datos en la capa de aplicación y almacenarlos en la base de datos tiene una limitación en la búsqueda, aunque la arquitectura inteligente de la aplicación podría solucionar parte de esto al permitir un descifrado temporal de los datos mientras la aplicación se está ejecutando, como en memoria: depende del tamaño del conjunto de datos, los requisitos de seguridad y los niveles de cumplimiento necesarios.

Creo que la opción de fragmentos, como probablemente indicas, no ofrece mucha protección, y puede complicar el sistema con pocos beneficios.

¿Qué hay de las opciones de cifrado de la base de datos completa? Estos son manejados por el motor de la base de datos y son transparentes para la aplicación: enlace

El cifrado es una buena idea. Pero es una pregunta, cómo el atacante podrá volcar el DB. Si sobre la aplicación que encripta / desencripta no tendría ningún efecto. El cifrado completo de la base de datos, como ha dicho correctamente, es solo protección contra ataques internos.

Con respecto a los datos de la tarjeta, hay requisitos exactos que debe seguir si desea almacenar, los llamados, datos del titular de la tarjeta. Si desea aprobar la certificación, es muy probable que se le solicite utilizar el Módulo de seguridad de Harware en dependencia del tipo de datos que desea procesar y almacenar. Si puede evitarlo, le recomendaría que no los almacene y que esté fuera del alcance del estándar PCI DSS.

Por lo que sé, no existe ningún buen esquema de protección contra el volcado de base de datos, mientras que aún sería posible operarlo, realizar búsquedas, etc.

Es mejor pensar en cómo puede suceder que se descargue el DB y proteja al DB (entorno completo) contra él. Y esto requeriría muchas más líneas de escritura;)

Suponga que desarrolla su solución globalmente distribuida, fragmentada, salada, hash, encriptada e indexada. Sus datos se almacenan como una serie de hash SHA256 con token en tablas de valor clave cifradas por filas distribuidas en centros de datos de todo el mundo, todos los cuales están protegidos por cortafuegos entre sí, y todos ejecutan cifrado de disco completo.

• Nadie puede iniciar sesión en un solo servidor y simplemente volcar los datos.
• Nadie puede tirar un disco duro y alejarse con los datos.
• Incluso si lo hicieran, obtendrían datos arbitrarios ('1568de12b5c51ac272fcd9112b5c9': '2b472568deac272fcd9112b5c51880f0ac443d1c').

¿Qué propones hacer exactamente con lo que has almacenado?

Cualquier mecanismo que desarrolle para buscar, recuperar y descifrar los datos de su caso de negocio se convertirá en el vector por el cual su sistema se verá comprometido. Probablemente será el resultado de la ingeniería social o el malware introducido a través de la ingeniería social. Alguien con acceso divulga sus credenciales en un correo electrónico de suplantación de identidad (phishing), o algún representante del centro de llamadas no puede autenticar a una persona que llama antes de cumplir su solicitud.

Todos sus controles de seguridad pueden ser negados por el hecho de que ahora existe un algoritmo para obtener datos materiales de su pajar.

Entonces, ¿cómo mitigar? No compliques demasiado tu arquitectura. No te salvará al final y todo lo que te quedará es una pesadilla inutilizable.

Simplemente implementa controles sanos y fortalece tus enlaces más débiles.

Como usted ha dicho, las contraseñas se pueden hashear. A veces es necesario ligar los datos, que rara vez se leerán (si es que se leerán), aquí el cifrado asimétrico con una clave pública (con la clave privada correspondiente fuera de línea) puede ser una solución, pero generalmente los datos de este tipo tienen un activo muy bajo valor. Todo lo demás necesita ser legible.

Eso significa que la aplicación necesita los medios para descifrar los datos. Por lo tanto, a menos que tenga puertas traseras en su base de datos, la ruta a los datos (encriptados) también proporciona acceso a las claves (o al texto sin cifrar). Podría impresionar a sus accionistas al escuchar que encripta todos sus datos con AES de 256 bits, pero no es beneficioso si el texto claro aún es recuperable a través de un ataque de inyección SQL. El cifrado de la base de datos tiene al menos un 20% de sobrecarga de rendimiento (en algunos casos mucho, mucho más alto). La mayoría de las personas tienen un presupuesto limitado para la seguridad y sugiero que es mejor gastar ese tiempo y dinero en proteger la superficie de ataque.

Tenga en cuenta que el cifrado de datos de la base de datos (o nivel de aplicación) (del cual supongo que está hablando) es bastante diferente del cifrado de dispositivos de archivos y bloques, que protege contra el acceso no deseado a sus medios físicos. Esto tiene una sobrecarga de rendimiento mucho menor y constante. Muchos dbms proporcionan cifrado de archivos (a menudo descrito como cifrado de base de datos completo ) y lo consideraría esencial si no controla la infraestructura de almacenamiento; El sistema de archivos es entonces potencialmente parte de la superficie de ataque.