Ofuscación de datos en SQL Server

¿Cuál es la mejor práctica para la ofuscación de datos en SQL Server?

Nos gustaría utilizar datos de producción enmascarados en nuestro sistema UAT.

Si queremos hacerlo rápidamente, y con un mayor nivel de obstrucción, ¿qué enfoque se debe tomar? Estoy pensando en la codificación de caracteres para el nombre de pila y el apellido de las personas, pero ¿cómo? ¿Debo crear una función yo mismo o hay funciones predefinidas disponibles para usar? No quiero pasar tiempo reinventando la rueda :)

¿Qué tal para los campos de fecha? Por ejemplo, ¿la fecha de nacimiento debe elegirse al azar de toda la tabla y asignarse a un registro, o hay una mejor manera de hacerlo?

¡Ojalá pudiera votarte 100 puntos solo por pensar en esto! He visto este tema pasado por alto tantas veces que es falso, muy bien hecho. Por lo que entiendo, en realidad desea codificar los datos dentro de los campos mismos, y aunque entiendo lo que está tratando de lograr, puede que no sea muy necesario hacerlo, aunque debería considerarse caso por caso.

La mayoría de las leyes de protección de datos giran en torno a la capacidad de asociar correctamente un dato con un individuo, por ejemplo, una fecha de nacimiento o un número de teléfono. Puede cumplir con los requisitos de la ley asegurándose de que cuando mueva sus datos fuera de producción a UAT, se mezclen para que no se vuelvan a mapear fácilmente a la persona original, especialmente cuando mezcla nombres y apellidos.

Sin embargo, esto no resuelve el problema, por ejemplo, digamos los detalles de contacto. Puede cumplir con los requisitos de la ley mezclando los datos, pero los números de teléfono siguen siendo reales, los correos electrónicos siguen siendo reales, etc. simplemente no están asignados a la persona correcta. Para esto, recomiendo si es posible borrar esos datos antes de pasarlos a UAT, Red Gate hace un software llamado Generador de datos que puede crear datos de prueba aleatorios para que pueda repoblar los campos con datos que se pueden probar.

En cuanto a la codificación de datos: existen muchas aplicaciones que hacen esto por usted y, sinceramente, tiene razón al no querer reinventar la rueda. El que usamos en nuestra compañía es un producto llamado Data Masker por una compañía llamada Net2000. La licencia es bastante barata, funciona extremadamente rápido y no tiene que preocuparse por tener que desactivar todas sus restricciones antes de codificar la base de datos.

Por supuesto, puede lanzar su propia solución si no encuentra nada que cumpla con sus requisitos; si decide hacerlo, le recomendaría encarecidamente que utilice los procedimientos CLR para hacerlo, ya que es mucho más flexible que TSQL puro (por no decir que usted no puede usar TSQL ver aquí ).

Una vez que haya elegido una aplicación para realizar esto, lo siguiente que debe decidir es qué es lo que realmente quiere / necesita mezclar. Honestamente, su mejor recurso para esto es el equipo legal de su empresa o los auditores de la empresa. Sé que a veces puede que no nos guste trabajar con ellos, pero serán mucho más amables con usted al acercarse a ellos y hacerles la pregunta en lugar de intentar hacerlo por su cuenta y equivocarse, no hay absolutamente nada de malo en pedir ayuda - especialmente cuando es tan importante como esto.

Espero que esto te ayude y te deseo buena suerte en tu búsqueda ... ;-)

El Sr. Brownstone se clavó el clavo en la cabeza. Ahora, para ayudarlo un poco, aquí está mi función "ilegible", utilizada para ofuscar cadenas (¡resultados divertidos con nombres!). Pase una cadena, devuelve una cadena ilegible. Inclúyalo en las declaraciones de actualización contra columnas de cadena. Cambie la longitud de los datos como mejor le parezca.

---------------------
-- Garble Function --
---------------------
-- Make a function to slightly garble the strings
IF (object_id('fn_Garble') is not null)
  drop function fn_Garble
go
create function fn_Garble
(
  @String varchar(255)
)  
returns varchar(255)
as
BEGIN
  select @String = replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(@String,'o','e'),'a','o'),'i','a'),'u','i'),'t','p'),'c','k'),'d','th'),'ee','e'),'oo','or'),'ll','ski')
  return @String
END
go

Tenía que hacer esto para los datos de ventas minoristas de mis clientes. Para los nombres, fui al censo y descargué todos los nombres y apellidos, los ejecuté a través de un bucle para unir cada uno a cada último, agregué código de sexo y lo cargué en una tabla en mayúsculas. Luego tuve una tabla con unos 400 millones de nombres únicos. Utilicé mayúsculas ya que nuestros datos actuales no estaban en mayúsculas, por lo que pude distinguir más fácilmente los datos que se borraron.

Cuando borré mis datos de usuario, cambié los nombres, por cumpleaños puse a todos al 1 de enero del año en que nacieron y actualicé cualquier número de teléfono con su código postal (mis datos eran solo de EE. UU.). Las direcciones de correo electrónico se convirtieron en los primeros iniciales más el apellido @miempresa.co. La dirección postal me causó la mayor pena, pero mantuve la ciudad, el estado y el código postal porque creo que no serán un problema si se cambia la dirección. Tenía un compañero de trabajo que tenía un programa que generaba letras confusas y actualizaba la línea de dirección con eso.

En cualquier lugar que tenía datos duplicados, pero todavía tenía un FK para el usuario principal (mal diseño, sí, pero no el mío), también actualicé esos datos para que el nombre fuera coherente en la base de datos para el usuario x.

En general, mis datos aún eran muy legibles, aunque la dirección no tenía ningún sentido. Me llevó un par de días hacer que todo funcionara, pero una vez que se hizo y se creó un trabajo de agente SQL, pude eliminar los datos en tan solo 15 minutos.

Para ofuscar un solo campo, ¿qué tal usar la función HASHBYTES (en SQL 2008+)? Puedes elegir tu algoritmo (MD5 probablemente sea suficiente) siempre que saques tus datos. Entonces, en lugar de solo SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD>) asegurarte de hacerlo, SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD> + '<my salt string>')ahora tienes un hash que no se puede forzar con fuerza bruta.

Es una función real que es soportable, repetible y probablemente mucho más rápida. Dependiendo de cuánto necesite realmente proteger frente a solo ofuscar, también podría usar un hash más débil y rápido.

Eche un vistazo al módulo PowerShell de dbatools para obtener una opción gratuita para el enmascaramiento de datos estáticos, escrito por Chrissy Lemaire (@ chrissy-lemaire) y su equipo. Todas sus herramientas son geniales, así que estoy seguro de que vale la pena echarle un vistazo.

Los dos comandos para buscar en dbatools son: New-DbaDbMaskingConfig Invoke-DbaDbDataMasking

Eche un vistazo a la publicación del blog que anuncia esto: enmascaramiento de datos automatizado