#sql #sql-server #database #backup #sensitive-data
#sql #sql-сервер #База данных #резервное копирование #конфиденциальные данные
Вопрос:
Я рассматриваю процедуру резервного копирования, которая позволяет создавать резервные копии нашей производственной базы данных с конфиденциальными данными, удаленными из определенных столбцов в базе данных, для экспорта на наш сервер тестирования.
Процедура должна требовать наименьшего вмешательства человека и, надеюсь, представлять собой простой настраиваемый SQL-скрипт без перевода рабочей базы данных в автономный режим.
Сервером базы данных является SQL Server 2008.
Комментарии:
1. стандартный или корпоративный? Я спрашиваю, потому что в enterprise есть функция, называемая прозрачным шифрованием данных, которая в любом случае скрывает данные от пользователей, поэтому вам не нужно удалять их перед созданием резервной копии…
2. Я не уверен, что есть какой-либо простой способ сделать это: если данные, которые вы храните, конфиденциальны, они должны храниться в зашифрованном виде в первую очередь …. и сами резервные копии могут быть зашифрованы….
3. Это стандартная версия SQL Server, и данные зашифрованы, но их все равно необходимо удалить. Мы не можем допустить, чтобы какие-либо конфиденциальные данные, зашифрованные или незашифрованные, были доступны с нашего производственного сервера
4. О скольких таблицах вы говорите? Не могли бы вы создать серию представлений, которые точно отражают структуру таблиц, но скрывают нужные данные, а затем использовать пакет SSIS для регулярного экспорта представления в виде набора данных на ваш тестовый сервер?
5. Пробовали ли вы какое-либо программное обеспечение для ETL , такое как AWS Glue ? Похоже, что этот инструмент способен решить проблему.
Ответ №1:
Я сталкивался с подобными требованиями раньше, и единственное известное мне надежное решение — использовать копию вашей рабочей базы данных. Вы можете замаскировать / удалить данные в копии и запускать резервные копии оттуда. Да, это некрасиво и пустая трата ресурсов, но на сегодняшний день я не нашел надежной альтернативы для этой конкретной проблемы.
Что касается метода копирования, у вас есть несколько вариантов:
- Репликация
- Запланированное копирование базы данных
- Резервное копирование / восстановление из рабочей среды
Итак, хотя я признаю, что это решение довольно неудобное, его можно автоматизировать и использовать в ваших целях. Если вы можете найти продуктивное применение копии базы данных, для которого не требуется ваша удаленная информация (например, отчеты, тестирование, разработка), то это действительно может быть не таким уж ужасным решением. Наличие слегка устаревшей версии рабочей базы данных с удаленными конфиденциальными данными может быть хорошим подспорьем в плане безопасности.
Комментарии:
1. Я выбрал ваш ответ, поскольку это лучшее решение, которое кто-либо придумал, и это то, что я реализовал.
Ответ №2:
Если вы хотите создать резервную копию, просто введите
РЕЗЕРВНАЯ БАЗА ДАННЫХ Dbname
Если вы хотите указать автономный режим или что-либо еще, вы можете это сделать. Файл резервной копии будет создан по пути SQL SERVER 2008 по умолчанию.