Cifrado de nivel de campo SQL, ¿qué tan seguro es?

Si está interesado en usar el cifrado a nivel de columna en SQL Server 2005 y superior, tengo un montón de código de ejemplo de cómo usar las funciones de cifrado integradas en SQL Server para proteger datos confidenciales. El código está disponible en enlace

En el código, muestro cómo cifrar datos confidenciales y me aseguro de que solo los usuarios autorizados puedan descifrarlos. Aprovecho la funcionalidad de administración de claves incorporada y tengo una clave AES simétrica generada de forma aleatoria administrada por el motor de base de datos y esas claves AES se aseguran con certificados. Los roles de la base de datos controlan quién tiene acceso a qué claves y con el cifrado integrado de SQL Server, incluso puede usar frases de contraseña para proteger adicionalmente claves o certificados, de modo que ni siquiera tenga que confiar en su DBA si los datos son muy confidenciales. Dicho esto, si no confías en tu DBA, tienes otros problemas :)

Ya que SQL Server hace lo correcto con el cifrado (asegurando IV únicos), no puede buscar columnas cifradas sin hacer una exploración de la tabla y descifrar cada fila para ver si hay una coincidencia. Proporciono algunos ejemplos de código para crear un HMAC de datos encriptados para que al menos pueda realizar una búsqueda básica sin perder información de texto simple.

También tengo ejemplos de cómo almacenar hashes de contraseñas ampliadas y con sal utilizando los algoritmos de hash integrados (que son insuficientes para el uso en producción) y una implementación SQLCLR del algoritmo de hashing bCrypt para un mejor almacenamiento de contraseñas.

También hay algunos ejemplos de código para mostrar el uso del cifrado de datos transparente para cifrar el contenido completo de sus datos y los archivos de registro en el disco.

Algunas de las ventajas de usar el cifrado integrado son:

• Excelente administración de claves, el servidor hace lo correcto cuando genera claves de encriptación y usa múltiples niveles de encriptación para proteger las claves
• Encriptación correcta, el servidor garantiza que cada parte de los datos se encripta con un nonce IV cada vez que se escribe, lo que significa que alguien no puede mirar dos valores encriptados y determinar que son valores de texto claro idénticos.
• Verificación de integridad opcional de las columnas cifradas para garantizar que alguien no pueda simplemente sobrescribir un valor cifrado con otro valor cifrado
• La portabilidad, puede acceder a sus datos desde múltiples plataformas sin tener que lidiar con los dolores de cabeza de las diferencias en las implementaciones de la plataforma que funcionan de manera diferente.
• Buena seguridad de los datos en reposo, el cifrado se realiza antes de que cualquier registro o páginas de datos se escriban en el disco, por lo que los datos registrados no contienen texto sin cifrar.
• Capacidad para seguir fácilmente el principio de privilegio mínimo y solo otorgar acceso a las claves de cifrado a los roles y / o usuarios que los requieren.

• Editar: Para obtener información específica sobre Microsoft SQL Server , lea @ el comentario de Joe a continuación . Además,

• Espero que mientras la función que describe encripta los binlogs (o similar, como en el caso de la intrusión en el sistema de archivos), probablemente no ayudaría si alguien obtuviera acceso a los datos mediante la inyección SQL, debido a la naturaleza automática. de la desencriptación. Creo que debería incluir la información confidencial en un usuario SQL separado (y restringir al usuario principal), alternativamente, podría agregar una capa adicional de cifrado / hashing.

• Sin mencionar la doble comprobación de su prevención de inyección SQL.

Como se mencionó, las bases de datos cifradas son computacionalmente más caras, sin mencionar el esfuerzo de programación.

Algunas sugerencias

• Como ya se mencionó, encripta información confidencial como contraseñas (que podrían usarse para obtener información más sensible en otras cuentas) o números de tarjeta de crédito, SSN (por supuesto). Si no necesita descifrar (por ejemplo, solo para comparar una contraseña cifrada con la que está en el archivo, no necesita descifrar), entonces use una función hash.

• Para la inyección de SQL reducción de riesgo, vea boxeando su acceso de usuario SQL . Las partes de autenticación de su sistema pueden estar separadas del resto del sistema. Esto puede ser una cantidad mucho menor de código que se revisa con más cuidado y se modifica con menos frecuencia.

• Si encripta los datos usando una rutina sólida y recomendada, como AES, y una clave aleatoria de longitud completa (no solo una simple frase de paso), luego los datos se vuelve inútil sin la clave , excepto por los aspectos básicos como que puede detectar duplicados, puede contar filas, ver cómo se relaciona con la información no cifrada, etc.

• El intruso puede obtener acceso a más de la base de datos . Si el intruso obtiene acceso a su base de datos y la clave (por ejemplo, si está codificado en su programa), entonces no es efectivo. Si lo desea, puede considerar un modelo complejo que impide el almacenamiento de la clave en plano . Por supuesto, esto implica una gran implicación si está modernizando un sistema existente.

• No utilice las funciones de cifrado integrado de SQL . Usted se encontraría con un problema similar si un intruso obtiene acceso a su base de datos y a los binlogs . (Registros de sentencias de SQL, por ejemplo en MySQL) Las rutinas integradas de SQL se evalúan después de la sentencia, con los parámetros en claro se copian en los registros de bin. Debería atenerse al cifrado en el programa para evitar esta filtración de la versión simple, que se abre camino en los registros de instrucciones (registros de bin, registros lentos), también podría filtrarse en la lista de procesos.

Pero en realidad

• Debes asegurarte de que no haya inyección SQL primero.

Y otras vulnerabilidades más obvias. El endurecimiento de su capa exterior parece una inversión más económica.

• Parcheando sus servicios web,
• deshabilitar puertas de acceso no utilizadas,
• incluir también una lista de acceso es una buena idea para evitar direcciones IP no confiables, o usuarios no VPN de explotar vulnerabilidades (sin mencionar que puede reducir) carga que ayuda contra ataques de denegación de servicio)

El cifrado es una línea de defensa posterior / reducción de responsabilidad potencialmente valiosa.
Pero incluso el modelo complejo al que me he referido es tan fuerte como el eslabón más débil .

• Muchas personas realmente usan solo una palabra para su contraseña ,

y puedes encontrar que te estás perdiendo algo, como

• no usa una rutina hash lo suficientemente lenta, o
• sin anticipar que el intruso podría alquilar un clúster de craqueo por un corto tiempo.

Pero todavía debes hacer un mejor esfuerzo.

Idealmente , sus computadoras solo entregarían lo que está permitido, y el cifrado del almacenamiento sería inútil. Esto es raramente el caso.

Tenga en cuenta que esta respuesta solo se centra en la piratería directa, y no en el acceso físico, o el acceso a través de una de las PC de su administrador de sistemas.

La criptografía a menudo no es el problema. En la mayoría de los casos, cifrar toda la base de datos es casi una pérdida de tiempo.

A menudo hay valores muy importantes que deben estar encriptados. Un valor que a menudo se pasa por alto es el identificador de sesión, los tokens csrf, el salto de contraseña y el token de contraseña olvidado . Si es lo suficientemente tonto como para almacenar su ID de sesión en la base de datos, un pirata informático con una falla de Inyección SQL puede extraer este valor e iniciar sesión sin necesidad de descifrar un hash de contraseña.

Como ya han dicho otros usuarios, cifrar toda la base de datos probablemente sea una exageración, lo que significa que perdería demasiado rendimiento y obtendría poca seguridad adicional, ya que cifraría campos que no es necesario cifrar.

Piénsalo de esta manera: imagina que un atacante ha logrado acceder a todos los datos de tu base de datos gracias a una inyección de SQL. ¿Qué información no debería ver el atacante y qué información no es tan importante, lo que significa que incluso si pudiera leerla, no podría hacer nada con ella? Un ejemplo del primer tipo serían las contraseñas de los usuarios, y uno de los muchos ejemplos del segundo tipo podría ser el color favorito del usuario, si por alguna razón necesita almacenar esta información en la base de datos: D

Por lo tanto, cifrar toda la base de datos no vale la pena ni el tiempo ni la pérdida de rendimiento, pero hay algunos campos que es absolutamente necesario que estén cifrados (contraseñas, números de tarjetas de crédito, SSN, identificadores de sesión y también puede agregar información personal del usuario a esta lista, como números de teléfono, etc., sus usuarios estarían agradecidos por esto :)).

No olvide que si el atacante tiene acceso a su base de datos, podría obtener acceso a toda la información que contiene, incluso si algunos campos han sido cifrados, solo necesita más tiempo para hacerlo. Y si tiene información muy importante en su base de datos, este tiempo adicional es extremadamente importante.

Y, finalmente, una sugerencia: invertir tiempo en la prevención de ataques de inyección SQL. Esta es probablemente la técnica más utilizada con la que un atacante puede tener acceso ilegítimo a su base de datos.

Depende. Recuerde que los atacantes siempre apuntarán al enlace de seguridad más débil de su sistema. ¿Cree que los datos de base de datos no cifrados son el enlace más débil de su sistema? Parece algo improbable. Si bien es cierto que proporcionará protección adicional, es probable que se dedique más tiempo a proteger otras partes de su sistema, ya que es más probable que sea el enlace más débil de seguridad.

Además, tenga en cuenta que cifrar una base de datos es generalmente bastante costoso, en términos computacionales. Si su base de datos proporciona una gran cantidad de datos a muchos clientes, esto podría ralentizar su sistema.