Маскирование данных или безопасность с помощью представлений?

Среда: SQL Server 2012 Я пытаюсь помочь создать решение, которое включает в себя маскировку и шифрование данных для нашей организации.

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

Один из подходов заключается в использовании какого-то инструмента, такого как генератор данных Redgate или DataVeil, который может генерировать фиктивные данные для базы данных для полей, которые мы хотим создать для среды Dev или UAT. Другой вариант - использовать какую-то функцию, которая маскирует некоторые символы как xxxx или **** в зависимости от длины.

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

Далее идет доступ на основе пользователей с использованием представлений. Там не так много материалов по безопасности с использованием представлений, поэтому спрашиваю, как мы могли бы реализовать, если мы выберем этот путь вместо вышеупомянутого.

Я понимаю, что пользователям может быть предоставлен доступ к базовым таблицам с помощью представлений. А как насчет существующих запросов, отчетов SSRS и Cube? Как это могло работать с представлениями? Могу ли я менять каждый запрос? Я здесь немного заблудился.


database security sql-server tsql data-masking
person Jerry    schedule 18.07.2018    source источник
comment
Вам нужны уникальные поддельные данные для сред UAT и DEV, или для каждой записи будут работать одни и те же фиктивные данные?   -  person seagulledge    schedule 18.07.2018
comment
Нам еще предстоит решить, будет ли иметь значение уникальность записей или нет. Если требуется уникальность, поможет любой инструмент. Я думаю об этом, что делать, когда данные маскируются на основе доступа / разрешений. SQL 2016 легко справляется с этим, но мы используем SQL 2012, и я не уверен, как это реализовать.   -  person Jerry    schedule 19.07.2018

Ответы (2)


arrow_upward
3
arrow_downward

Опцию View можно сделать, создав новое представление «маски», которое включает все столбцы из исходных таблиц и заменяет чувствительные столбцы фиктивным фиксированным значением.

Например:

create view vMaskPeople
as
SELECT ID, DateCreated, 'Sample Name' as FullName, 'Sample Telephone' as Phone
FROM People

Если вам нужны более уникальные образцы данных, частично замаскируйте столбцы, например:

SELECT ID, DateCreated, 
    Left(FullName,3)+'XXXXXX' as FullName, 
    'XXX-XXXX-'+Right(Phone,4) as Phone

Если вы не можете каким-либо образом настроить среду разработки для использования нового представления маски, вы можете переименовать исходную таблицу People в «People1», а затем назвать представление маски «People».

person seagulledge    schedule 18.07.2018
comment
Итак, мой вопрос: я создаю представление и просто предоставляю пользователям доступ к этому представлению для новых требований. А как насчет уже построенных запросов и отчетов SSRS, основанных на процедурах или кубах, получающих данные из многомерной базы данных? И можно ли позволить некоторым пользователям видеть немаскированные данные, а некоторым - не на основе разрешений? - person Jerry; 19.07.2018

arrow_upward
2
arrow_downward

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

person David Atkinson    schedule 20.07.2018
comment
Спасибо. Я также проверил продукт RedGate и в последнее время часто использую SQL Doc от вас. Большинство генераторов данных могли бы генерировать поддельные данные, но я искал замаскированные данные на основе доступа. - person Jerry; 20.07.2018