Какова хорошая практика безопасности для хранения критически важной базы данных на ноутбуках разработчика?

У нас есть несколько подарков:

1. Разработчикам нужна копия производственной базы данных на их машинах.
2. Разработчики имеют пароль к указанной базе данных в файлах App.config.
3. Мы не хотим, чтобы данные в указанной базе данных были скомпрометированы.

Несколько предложенных решений и их недостатки:

1. Полный диск-шифрование. Это решает все проблемы, но ухудшает производительность ноутбука, и мы начинаем, поэтому у нас нет денег на лошадей.
2. Создание виртуальной машины с зашифрованным жестким диском и сохранение базы данных на ней. Работает хорошо, но не сильно помогает, так как в Web.Config есть пароль.
3. Решение № 2 + требует от разработчика вводить пароль базы данных каждый раз, когда он запускает что-либо. Это решает все проблемы, но для разработчиков действительно сложно работать с приложением, которое иногда запускает приложение несколько раз в минуту. Кроме того, у нас есть несколько приложений, которые подключаются к одной и той же базе данных, и реализация экрана пароля должна отличаться в каждом.

Итак, мой вопрос: есть ли какое-либо общее решение для такой проблемы или какие-либо предложения о том, как сделать любое из вышеперечисленных решений работоспособным?

Вы не только не хотите получить копию производственной базы данных, но и на самом деле она может быть незаконной. Например, в США вы не можете вывести производственные данные из производственной среды, если они содержат регулируемую информацию, такую ​​как личные данные о здоровье, финансовые данные или даже данные, которые могут быть использованы при краже личных данных. В противном случае вас могут оштрафовать, потерять статус соответствия и, следовательно, подвергнуть более агрессивным проверкам или даже обвинить в судебном процессе.

Если вам нужны производственные данные для тестирования, у вас есть пара вариантов:

1. Генерация всех фиктивных данных. Это сложнее, чем кажется. Удивительно сложно и трудоемко генерировать разумные воображаемые данные.
2. Анонимизируйте ваши производственные данные. Это может быть проще, но действуйте с осторожностью.

Для варианта № 2

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

Можете ли вы по крайней мере предоставить виртуальные машины разработчиков в вашем центре обработки данных, в которые они могут использовать RD для этой работы? Хотя они действительно должны работать с непроизводственными данными, это будет безопаснее, пока вы не доберетесь до них, поскольку данные не будут храниться на легко похищенных ноутбуках.

Измените ваш способ работы, если это возможно.

Как уже отмечали другие:

• Использование производственных данных для разработки не является хорошей практикой.
• Хранение пароля в виде простого текста не является хорошей практикой.

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

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

Если это действительно необходимо, вам просто нужно выполнить полное шифрование диска.

Учитывая риски, вам нужно использовать наилучшую доступную опцию безопасности, и это все. Если есть удар по производительности, смирись с этим. Это стоимость работы с конфиденциальными данными.

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

Ответ Корбина Марча довольно хороший, я просто добавлю дополнительную деталь, что у вас обычно есть два класса данных в вашей производственной базе данных: метаданные системы / приложения; и данные пользователя клиента / данные транзакции. Этот последний НИКОГДА не должен использоваться в среде разработки "как есть".

На самом деле очень редко требуется информация о реальных производственных клиентах для разработки.

Тем не менее, если проблема, которую описывает OP, включает в себя данные коммерческой тайны или иные данные, являющиеся частной собственностью системы, которые не включают данные клиента, что требуется разработчикам ... подход к обеспечению безопасности должен включать схему, которая не имеет пароль БД хранится в открытом тексте в файле ресурсов где-то. Должен быть механизм, например, для восстановления ежедневного пароля, который не хранится на диске.

Вы не указываете, какая база данных и какая среда.

Если вы можете использовать встроенную защиту, то база данных будет недоступна без входа в систему под этим пользователем. Да, если данные находятся на жестком диске, их можно взломать, но это защита первого уровня.

App.config заставляет меня думать, что это может быть .NET. Поместите config в флеш-накопитель и прочитайте его с флешки. Если диск отсутствует, введите пароль пользователя.

Есть ли способ сохранить пароль в памяти при первом его вводе и прочтении всеми. Опять вы не заявляете об окружающей среде. Отображенные в память файлы

С некоторыми TDE вы можете хранить ключ на отдельном устройстве, чтобы они просто передавали ключ при запуске сервера базы данных.

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