Обфускация данных в SQL Server

Какова лучшая практика для обфускации данных в SQL Server?

Мы хотели бы использовать маскированные производственные данные в нашей системе UAT.

Если мы хотим сделать это быстро и с более высоким уровнем запутанности, какой подход следует использовать? Я думаю о характере борьбы за имя и фамилию людей, но как? Должен ли я создать функцию самостоятельно или есть какие-либо предопределенные функции, доступные для использования? Я не хочу тратить время на переизобретение колеса :)

Как насчет полей даты? Например, следует ли случайным образом выбирать дату рождения из всей таблицы и назначать запись, или есть лучший способ сделать это?

Хотелось бы, чтобы я набрал 100 баллов только за то, что подумал об этом! Я видел эту тему так много раз, что она не соответствует действительности - так хорошо сделано. Из того, что я понимаю, вы на самом деле хотите скремблировать данные в самих полях, и хотя я понимаю, что вы пытаетесь достичь, это может быть не совсем необходимым, хотя это следует рассматривать в каждом конкретном случае.

Большинство законов о защите данных вращаются вокруг способности правильно связать часть данных с человеком - например, дата рождения или номер телефона. Вы можете выполнить требования закона, гарантируя, что при переносе данных из производства в UAT они смешиваются, поэтому их нелегко повторно сопоставить с исходным лицом, особенно когда вы смешиваете имена и фамилии.

Однако это не решает проблему, например, скажем, контактные данные. Вы можете выполнить требования закона, смешивая данные, но телефонные номера все еще действительны, электронные письма все еще действительны и т. Д. ... они просто не назначены правильному человеку. Для этого я рекомендую, чтобы при любой возможной очистке этих данных перед их передачей в UAT Red Gate создала программу под названием Data Generator, которая может создавать для вас случайные тестовые данные, чтобы вы могли заполнить поля данными, с которыми можно тестироваться.

Что касается скремблирования данных: существует множество приложений, которые делают это для вас, и, честно говоря, вы правы в том, что не хотите изобретать велосипед. В нашей компании мы используем продукт под названием Data Masker компании Net2000. Лицензия довольно дешевая, она работает очень быстро, и вам не нужно беспокоиться о необходимости отключить все свои ограничения перед шифрованием базы данных.

Конечно, вы можете свернуть свое собственное решение, если вы не найдете ничего, отвечающего вашим требованиям - если вы решите это сделать, я настоятельно рекомендую использовать для этого процедуры CLR, поскольку он гораздо более гибкий, чем чистый TSQL (не говоря уже о том, что вы не могу использовать TSQL, смотрите здесь ).

После того, как вы выбрали приложение для этого, вам нужно решить, что именно вы хотите / нужно шифровать? Честно говоря, ваш лучший ресурс для этого - юридическая команда вашей компании или аудиторы компании. Я знаю, что иногда нам может не нравиться работать с ними, но вам будет гораздо приятнее обращаться к ним и задавать им вопрос, а не пытаться делать это самостоятельно и ошибаться, в обращении за помощью нет абсолютно ничего плохого - особенно когда это так важно.

Я надеюсь, что это поможет вам, и я желаю вам удачи в ваших поисках ... ;-)

Мистер Браунстоун ударил гвоздь прямо в голову. Теперь, чтобы помочь вам немного, вот моя «искаженная» функция, используемая для запутывания строк (забавные результаты с именами!). Передав строку, она возвращает искаженную строку. Включите его в операторы обновления для строковых столбцов. Измените длину данных по своему усмотрению.

---------------------
-- 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

Я должен был сделать это для моих данных розничных продаж клиентов. Что касается имен, я пошел на перепись и загрузил все имена и фамилии, провел их через цикл, чтобы соединить каждое первое с каждым последним, добавил половой код и загрузил его в таблицу в верхнем регистре. У меня тогда была таблица с 400 миллионами уникальных имен. Я использовал верхний регистр, так как наши текущие данные не были в верхнем регистре, поэтому я мог бы легче узнать данные, которые были очищены.

Когда я очищал свои пользовательские данные, я обменивал имена, на день рождения я помещал всех на 1 января года, в котором они фактически родились, и обновлял любые телефонные номера своим почтовым индексом (мои данные были только для США). Адреса электронной почты стали первыми плюс фамилия @ mycompany.co. Почтовый адрес доставил мне больше всего горя, но я сохранил город, штат и почтовый индекс, потому что я считаю, что они не будут проблемой, если адрес будет изменен. У меня был сотрудник, у которого была какая-то программа, которая генерировала искаженные буквы и обновила адресную строку этим.

Везде, где у меня были дублированные данные, но главный пользователь все еще имел FK (плохой дизайн - да, но не мой), я тоже обновил эти данные, чтобы имя было одинаковым во всей базе данных для пользователя x.

В целом мои данные все еще были очень удобочитаемыми, хотя адрес не имел никакого смысла. Мне потребовалось несколько дней, чтобы все это заработало, но как только это было сделано и была создана работа агента sql, я мог очистить данные всего за 15 минут.

Для того, чтобы запутать одно поле, как насчет использования функции HASHBYTES (в SQL 2008+)? Вы можете выбрать свой алгоритм (вероятно, достаточно MD5), если вы засолите свои данные. Таким образом, вместо того, SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD>) чтобы просто убедиться, что вы делаете, SELECT HASHBYTES('SHA2_256', <LAST NAME FIELD> + '<my salt string>')и теперь у вас есть хеш, который нельзя легко переборить.

Это реальная функция, которая поддерживается, повторяется и, вероятно, намного быстрее. В зависимости от того, сколько вам нужно по-настоящему защищать, а не просто запутывать, вы также можете использовать более слабый и быстрый хеш.

Взгляните на модуль PowerShell dbatools, чтобы узнать о бесплатной опции статического маскирования данных, написанной Крисси Лемэр (@ chrissy-lemaire) и ее командой. Все их инструменты великолепны, поэтому я уверен, что это стоит посмотреть.

Две команды для поиска в dbatools: New-DbaDbMaskingConfig Invoke-DbaDbDataMasking

Посмотрите на сообщение в блоге, объявляющее об этом: автоматическое маскирование данных