El cifrado consiste en garantizar la confidencialidad . El cifrado no garantiza la confidencialidad en absoluto, pero traduce el problema a la clave : cuando los datos están cifrados, solo podrán leerlos las entidades que tengan acceso a la clave de descifrado. La clave no necesita estar almacenada en el mismo lugar que los datos en sí, y ese es el tipo de separación del que estamos hablando aquí. A saber, los datos encriptados están en la base de datos pero la clave de descifrado es en la aplicación , que puede ser una máquina distinta, por lo que ofrece protección contra los atacantes que pueden obtener un vistazo en el servidor de la base de datos, pero no en la máquina de la aplicación.
Como señala @Lucas, esto funciona contra algunas formas de inyección de SQL siempre que el descifrado no sea factible en SQL . Algunas bases de datos tienen capacidades para realizar la criptografía por sí mismas, por lo que los ataques de inyección de SQL pueden aprovechar estas habilidades. Como caso extremo, considere lo que Microsoft llama Cifrado de datos transparente en SQL Server: todos los datos son cifrado, pero esto lo hace automáticamente el propio servidor de base de datos; La aplicación ni siquiera es consciente de ello. Esto ofrece protección cero (nil, void, nada) contra inyecciones de SQL y otros hacks de nivel de aplicación. TDE solo se aplica a las personas que leen el medio de almacenamiento sin pasar por el código del servidor SQL.
Un atacante que secuestra la máquina de la aplicación podrá leer toda la base de datos y descifrarla por completo, por lo que el cifrado no puede proteger contra eso. De hecho, hay relativamente pocos escenarios plausibles en los que el cifrado de la base de datos realmente ofrece protección adicional (a diferencia de la contraseña hashing , que es unidireccional, y que ofrece mucha protección adicional como segunda línea de defensa).