Cifrado de datos en SQL Server

El cifrado de los datos es vital para protegernos de fugas de información y cumplir con la normativa de protección de datos sensibles. Repasamos todas las opciones que ofrece SQL Server.

El otro día, hablando de preguntas en entrevistas de trabajo para DBA, comentamos el tema del cifrado de datos en SQL Server. Como es un tema muy interesante y que a veces genera dudas vamos a verlo en profundidad. 

Antes de empezar, una aclaración. Mi profesor de ciberseguridad siempre decía que se dice CIFRAR, la palabra ENCRIPTAR nunca ha existido en el castellano. La gente usa encriptar por una mala traducción del inglés encrypt. Aunque lo cierto es que el uso de encriptar está tan extendido que en 2022 la RAE lo incluyó en las últimas versiones del diccionario (junto a almóndiga y cocreta), la forma correcta de decirlo sigue siendo CIFRAR. Al fin y al cabo no vamos a meter nada en ninguna cripta, ¿verdad?.

¿Qué es el cifrado y que tipos existen?

El cifrado es un proceso que transforma la información en un formato ilegible para quienes no tienen la clave para descifrarla. De esta forma, podemos evitar que personas no autorizadas accedan a nuestros datos sensibles o confidenciales.

Existen dos escenarios principales donde el cifrado es importante: en tránsito y en espera. El cifrado en tránsito es la protección de los datos mientras se transmiten por la red, por ejemplo, entre el cliente y el servidor, o entre dos servidores. Sin embargo, cuando decimos cifrado en espera nos referimos a la protección de los datos mientras se almacenan, por ejemplo, en un disco duro o en la nube.

El cifrado en SQL Server

SQL Server nos ofrece varias opciones para implementar el cifrado en ambos escenarios. Veamos algunas de ellas:

TLS para cifrado en tránsito

Para el cifrado en tránsito, podemos usar el protocolo TLS (Transport Layer Security), que crea un canal seguro entre dos partes que se comunican por la red. SQL Server soporta TLS desde la versión 2005 y lo podemos habilitar mediante la configuración del servidor y del cliente. También podemos usar certificados digitales para autenticar las partes y garantizar la integridad de los datos. Los certificados son documentos electrónicos que contienen información sobre la identidad y la clave pública de una entidad. SQL Server nos permite crear, importar y administrar certificados mediante el uso de cláusulas Transact-SQL o mediante el uso de herramientas gráficas como el Administrador de configuración de SQL Server o el Explorador de objetos de SQL Server Management Studio.

TDE para cifrado en espera de bases de datos 

Para el cifrado en espera, podemos usar el TDE (Transparent Data Encryption), que cifra los archivos de datos, los logs de registro y las copias de seguridad de las bases de datos. SQL Server soporta TDE desde la versión 2008 y lo podemos habilitar mediante la creación de una clave de cifrado de base de datos y una clave maestra de base de datos. El TDE no afecta al rendimiento ni al diseño de las aplicaciones, ya que el cifrado y el descifrado se realizan de forma transparente.

TDE se puede configurar con EKM (Extensible Key Management), que nos permite usar proveedores externos para almacenar y administrar las claves de cifrado. El EKM nos ofrece mayor seguridad y flexibilidad para gestionar las claves.

Always Encrypted para cifrado en espera de columnas

Otra opción para el cifrado en espera es Always Encrypted, que nos permite cifrar los datos sensibles dentro de las columnas de las tablas, tanto en el servidor como en el cliente. SQL Server soporta Always Encrypted desde la versión 2016 y lo podemos habilitar mediante la configuración del driver del cliente y la creación de una clave maestra columnar y una clave columnar. El Always Encrypted nos permite separar las claves de los datos, lo que implica que ni siquiera nosotros como DBAs podremos ver los datos sin autorización.

Enmascaramiento de datos

Además del cifrado, otra forma de proteger nuestros datos es el enmascaramiento. SQL Server ofrece,desde la versión 2016, una opción llamada DDM (Dynamic Data Masking) que nos permite ocultar o modificar los datos sensibles cuando se muestran a los usuarios. Esta opción nunca va a alterar los datos reales almacenados en la base de datos. El DDM nos permite limitar la exposición de los datos según si el usuario tiene o no un permiso. En concreto los usuarios sysadmin o con el permiso UNMASK leerán los datos tal como están guardados en la base de datos y el resto verá los datos enmascarados

Es importante destacar que el DDM no es lo mismo que el cifrado, ya que el DDM no cambia los datos reales, sino solo su presentación. Por lo tanto, el DDM no es suficiente para garantizar la seguridad de los datos, sino que debe usarse junto con otras medidas como el cifrado o el control de acceso.

¿Cómo funciona DDM?

DDM funciona mediante la definición de máscaras o reglas que se aplican a las columnas que contienen los datos que queremos proteger. Estas máscaras pueden ser de diferentes tipos, como por ejemplo:

– Máscara parcial: oculta parte del valor original, dejando visible solo algunos caracteres. Por ejemplo, podemos mostrar solo los últimos cuatro dígitos de un número de teléfono o de una tarjeta de crédito.
– Máscara por defecto: reemplaza el valor original por un valor fijo o predeterminado. Por ejemplo, podemos mostrar un asterisco (*) en lugar del nombre completo de una persona.
– Máscara aleatoria: genera un valor aleatorio dentro de un rango especificado. Por ejemplo, podemos mostrar una fecha aleatoria entre el año 2000 y el 2020 en lugar de la fecha real de nacimiento de una persona.
– Máscara personalizada: permite definir una expresión o una función que se encarga de generar el valor enmascarado. Por ejemplo, podemos mostrar el nombre de una ciudad al azar en lugar del nombre real de la ciudad donde vive una persona.

Para implementar el DDM en SQL Server, solo tenemos que usar la instrucción ALTER TABLE y especificar el tipo de máscara y el valor que queremos aplicar a cada columna. Por ejemplo, si tenemos una tabla llamada Clientes con las columnas Nombre, Apellido, Teléfono y Ciudad, podemos definir las siguientes máscaras:

De esta forma, cuando consultemos la tabla Clientes, veremos algo así:

Nombre Apellido Teléfono Ciudad
*AXXXXXXX XXX-12345
*BXXXXXXX XXX-56783
*CXXXXXXX XXX-90127

Conclusión

Hemos visto algunos ejemplos de los tipos de cifrado y protección que podemos usar con SQL Server. Aunque existen otras opciones como el cifrado estático de columnas son opciones antiguas que prácticamente no se usan. Como habéis podido ver, el cifrado y el DDM son herramientas muy útiles y poderosas para proteger nuestros datos y cumplir con las normativas de privacidad y seguridad. Cada opción tiene sus ventajas y desventajas, dependiendo del nivel de seguridad y rendimiento que se busque. Espero os haya gustado este post y que lo podáis poner en práctica. Como siempre dejo a vuestra disposición los comentarios, mi cuenta de Twitter y mi mail para cualquier duda.

 

Publicado por Roberto Carrancio

Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.

4 comentarios

[…] el post de ayer vimos cómo cifrar o enmascarar los datos en SQL Server pero, ¿qué datos debemos proteger? Eso es justo lo que vamos a ver hoy, en este artículo te voy […]

[…] últimos días hemos estado viendo cómo cifrar y enmascarar datos confidenciales en SQL Server y cómo clasificar los datos en función de su tipología y confidencialidad. Hemos […]

[…] con los requisitos de la RGPD. Ya hemos hablado de ellas en este blog de una manera detallada en este artículo, por lo que hoy vamos a hacerlo desde el punto de vista del cumplimiento […]

[…] DDM nos permite enmascarar la información sensible de nuestra base de datos y, en ocasiones, la propia ausencia de información es sensible en sí. Sin embargo, y esto es algo mejorable a mi parecer, DDM no nos permite ocultar valores NULL sensibles en nuestras tablas. Es decir, DDM solo enmascara datos conocidos, mostrando un valor NULL real a los usuarios sin privilegios igual que a los que sí tienen permiso de desenmascarar. […]

Deja una respuesta