Enmascaramiento de datos SQL Server

Hola a todos, vamos a hablaros sobre cómo solucionar la necesidad de evitar mostrar datos reales de usuarios en los entornos no productivos y aun así seguir trabajando con la información no sensible. Por ejemplo, mostrar joaxxx@xxxx.es en lugar del email real o 95X XXX XX94 en vez del teléfono de un cliente. Esta técnica se denomina enmascaramiento.

Disponible desde la versión SQL Server 2016 (13.X) en adelante, inclusive en Azure SQL, nos permite evitar mostrar en su totalidad o parcialmente información confidencial.

Enmascaramiento de datos SQL Server

Desde SQL Server 2016 esta funcionalidad se encuentra de manera nativa. Se configura con comandos Transact-SQL y se conoce como «Enmascaramiento dinámico de datos», «Dynmamic Data Masking» o «DDM».

Para los que todavía no saben qué es y cómo se utiliza el enmascaramiento de datos, les daremos una breve introducción de cómo funciona, los tipos de funciones y lo fácil y entretenido que puede ser mientras cumplimos una necesidad muy importante para las empresas.

Introducción

El enmascaramiento dinámico de datos (DDM) tiene como finalidad limitar la exposición de la información confidencial, con lo que se impide que los usuarios vean datos a los que no deberían poder acceder. El enmascaramiento dinámico de datos no pretende evitar que los usuarios de la base de datos se conecten directamente a ella y ejecuten consultas exhaustivas que expongan información confidencial. Además, es complementario de otras características de seguridad de SQL Server (auditoría, cifrado, seguridad de nivel de fila…). Es muy recomendable que se use junto a esas características para proteger mejor la información confidencial en la base de datos.

Ejemplos de enmascaramiento

Una vez que ya hemos visto qué es, vamos a mostrarles unos ejemplos y posteriormente os explicaremos de que está compuesto:

La siguiente tabla tiene datos con información sensible para una empresa X por lo que se les solicitó restaurarla en un entorno no productivo. Pero sin mostrar datos confidenciales, con excepción de un grupo limitado de personas que si puedan verlo.

  • Estructura de la tabla clientes_dh sin enmascaramiento de datos:
CREATE TABLE [dbo].[clientes_dh](
	[id] [int] IDENTITY(1,1) NOT NULL,
	[fname] [nvarchar](30) NOT NULL,
	[lname] [nvarchar](30) NOT NULL,
	[ccard] [varchar](20)  NULL,
	[salaryi] [int] NULL,
	[email1] [nvarchar](60) NULL,
	[email2] [nvarchar](60) NULL,
	[somedate] [datetime] NULL
       )
  • Información de la tabla:

Tabla modelo con los siguientes datos sensibles: nombre, tarjeta de crédito, salario, correo 1 y 2, fecha:

Tabla modelo con los datos enmascarados en el entorno no productivo:

Los campos enmascarados fueron:

  • Fname. Se reemplazó por “XXXX”.
  • Ccard. Se muestra solo los dos primeros y últimos dígitos reales, el resto se reemplazó con “XXXX”.
  • Salary. Se reemplazó con 0.
  • Email1. Solo se muestra la primera letra del email, el “@” y el “.com” al final.
  • Somedate. Se reemplaza por valor por defecto: 1900-01-01 00:00:00.0000

Para realizar este proceso, se realizaron los siguientes comandos SQL:

alter table clientes_dh alter column fname         add masked with (function = 'DEFAULT()')
alter table clientes_dh alter column ccard         add masked with (function = 'PARTIAL(2, "XX-XXXX-XXXX-XX", 2)' )
alter table clientes_dh alter column salaryi       add masked with (function = 'DEFAULT()')
alter table clientes_dh alter column somedate      add masked with (function = 'DEFAULT()')
alter table clientes_dh alter column email1        add masked with (function = 'EMAIL()')

Cuando aplicamos los cambios, cualquier usuario que tenga permisos sobre la tabla, podrá automáticamente a ver la data enmascarada. Si queremos que haya excepciones, estos son los comandos a ejecutar:

Permitir que el usuario «usuario_gps1» vea los datos sin enmascarar:

grant unmask to usuario_gps1;

Dejar de permitir que el usuario «usuario_gps1» vea los datos sin enmascarar:

deny unmask to usuario_gps1;

Del mismo modo que resulta fácil enmascarar una tabla, también lo es retirarle el enmascaramiento. Para nuestro ejemplo, estos son los scripts que se deben aplicar:

alter table clientes_dh alter column fname 	   drop masked
alter table clientes_dh alter column ccard 	   drop masked
alter table clientes_dh alter column salary 	   drop masked
alter table clientes_dh alter column somedate      drop masked
alter table clientes_dh alter column email1 	   drop masked

Tipos de enmascaramiento

Describimos brevemente los diferentes tipos de funciones que podemos usar y que se mostraron en el ejemplo:

FUNCIONDESCRIPCION
DefaultDepende del tipo de dato de la columna. Cuando el tipo de dato es texto, utiliza ‘XXXX’. Si es numérico lo remplaza por ‘0’ y si es una fecha, le asigna el valor ‘01.01.1900 00:00:00.0000000’
EmailMuestra solo el primer carácter del email y termina con un @.com
RandomDiseñado para valores numéricos al azar con rangos definidos entre random([start], [end])
CustomMuestra el primer y último carácter, enmascarando lo que se encuentre en el medio de acuerdo a a función partial(prefix,[mask],sufix)

Conclusiones

El enmascaramiento de datos desde SQL Server 2016 en adelante se puede configurar en los campos requeridos para evitar mostrar información sensible en los conjuntos de resultados de consultas. Con DDM no se modifican los datos en la base de datos por lo que resulta fácil de usar con las aplicaciones existentes, ya que las reglas de enmascaramiento se aplican en los resultados de la consulta. Muchas aplicaciones pueden enmascarar información confidencial sin modificar las consultas existentes.

Esperamos que os sea de utilidad la entrada y que podáis utilizar esta nueva funcionalidad. Si quieres que analicemos tu caso para ver si es viable implantar este sistema en tu empresa. Contáctanos sin compromiso.

Consulta además nuestros servicios de soporte y mantenimiento SQL server o de consultoría. Seguro que podemos ayudarte a abordar tus proyectos.

Nos vemos en próximas entradas. No te las pierdas, suscribiéndote a nuestra newsletter mensual. Con un email al mes, estarás al día de nuestras publicaciones.

¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.

Sígue a GPS en LinkedIn

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *