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

33

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

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

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

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

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

Сварог
источник
26
Вы действительно измерили влияние на производительность полного шифрования диска. Я использовал его на старых ноутбуках и не заметил существенного снижения производительности. Современные операционные системы довольно хорошо кешируют, а диски все равно работают медленно. Худшее влияние, вероятно, на срок службы батареи.
5gon12eder
69
Если честно, это не похоже на правильный подход. 1) Зачем разработчикам нужна производственная база данных на своих машинах? Разве нет способа создать фиктивные данные для базы данных разработчиков? 2) Почему пароль хранится в виде обычного текста в файле конфигурации? Кажется, вы пытаетесь нанести ущерб процессу с ошибками. Возможно, вы сможете изменить то, что на самом деле живет на машинах разработчиков, а также то, как хранится пароль для базы данных.
Томас Стрингер
2
Есть причины, по которым разработчикам нужна производственная база данных. По историческим причинам их работа слишком связана с живыми данными. Я знаю, что это плохая идея, и если мы не найдем хорошего решения, мы перейдем к фиктивным данным. Сейчас я пытаюсь найти хорошее решение без этого.
Сварог
6
Ни один пользователь MacBook Pro не может сказать вам по скорости машины, включено ли полное шифрование диска на SSD-накопителе. Там нет разницы. Ничто из того, что вы можете заметить. Может быть, тот, который вы можете измерить, но ничего, что заметно.
gnasher729
5
Я второй комментарий @ gnasher729. Много лет использовав полное шифрование диска в регулируемых средах (финансовых и медицинских), это не должно приводить к заметному снижению производительности. Многие люди поднимают другие действительные вопросы, но в среде HIPAA трудно иметь разумную политику без полного шифрования диска, даже если базы данных не размещены на ноутбуках. Электронные письма и другие фрагменты данных часто оказываются там в любом случае. Файлы подкачки .... и т.д ... Полное шифрование диска не подходит, но обычно это необходимо.
Joshp

Ответы:

100

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

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

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

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

  • В производственной среде авторизованный администратор базы данных создает копию производственных данных.
  • В производственной среде тот же авторизованный администратор выполняет процедуру, которая анонимизирует все конфиденциальные данные. Если сомневаешься, оставь анонимным.
  • Только тогда данные должны быть перемещены в другую среду.
Корбин Март
источник
31
и пароль к копии базы данных не должен совпадать с паролем для
рабочей
3
«Например, в США нельзя вывести производственные данные из производственной среды, если они содержат регламентированную информацию» Что? У вас есть источник для этого? Разве вы не можете, например, использовать резервные копии производственной базы данных в качестве данных для промежуточной среды или для тестирования баз данных на компьютерах разработчиков?
няня
12
@nanny Нет, если вы используете регулируемые данные. Например, я работал в соответствии с правилами HIPAA. HIPAA заявляет, что «организации, на которые распространяется действие страховки, также должны применять разумные минимально необходимые политики и процедуры, ограничивающие объем защищенной медицинской информации, используемой, раскрываемой и запрашиваемой для определенных целей». Минимально необходимая политика открыта для некоторой интерпретации. Наш юрисконсульт предложил строгое толкование, в котором содержались конфиденциальные данные, которые не были доступны разработчикам (Действительно ли им необходимо выполнять свою работу?) То же самое относится и к финансовым нормам, таким как PCI.
Корбин март
4
@nanny Воспринимайте это как слухи не юриста, но, насколько я понимаю, правила сильно различаются в зависимости от штата. Адвокат, с которым я работаю, всегда ошибается из-за осторожности. Строго говоря, разработчикам не нужны настоящие номера SSN для выполнения своих обязанностей, поэтому адвокат предполагает, что эти SSN живут в защищенной среде, где разработчики не могут получить к ним доступ. Не слушай меня, хотя. Юрист, который следит за вашими долгосрочными интересами, будет лучшим ресурсом.
Корбин март
5
Строго говоря, небрежно быть небрежным с ИЦП, если только вы не выполняете государственную работу, тогда в игру вступает «Титул 32» ... но это серьезный риск гражданской ответственности. В противном случае это отличный ответ. upvoted.
Dwoz
9

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

Брайан Кноблаух
источник
это больше похоже на комментарий, см. Как ответить
Гнат
5
@gnat, этот ответ может быть коротким, но это очень хорошая альтернатива.
Не будь таким педантом, @gnat ... это хороший ответ.
Двое
@ dan1111 В этом проблема. Это не ответ. Это альтернатива. Это делает это комментарием, а не ответом.
CorsiKa
2
@corsiKa, ответы, которые оспаривают предпосылку вопроса, разрешены и часто являются очень хорошими ответами. См. Проблему XY: meta.stackexchange.com/questions/66377/what-is-the-xy-problem . И более подробные ответы могут быть лучше, но это все же ответ.
8

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

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

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

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

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

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

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

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


источник
1
«Не идеальное решение» следует заменить на «совершенно глупую идею» ИМО
Дархогг
@ Дархогг, ты прав, это должно быть сильнее. Ред. Я бы не стал настолько «глупым», не зная, насколько чувствительно приложение. Практически говоря, риск компрометации очень, очень низок, если использовать полное шифрование диска, поэтому можно сделать слишком многое из этого в качестве проблемы безопасности.
Я согласен с первым пунктом, но не вторым. Если вы не храните свой пароль в открытом виде, где вы храните его (1) зашифрованный текст или (2) ваш мозг. Если (1), то где вы храните пароль для шифра (обнаружен бесконечный цикл). Если (2), то я надеюсь, что вы хотели проснуться в 2:00 утра, чтобы ввести пароль для перезапуска службы.
Эмори
1

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

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

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

dwoz
источник
5
client user data/transactional data... should NEVER be used in a development environment "as is." - Это звучит нереально для меня. Проблемы, связанные с производственным программированием, связанные с данными конкретного клиента, были бы неразрешимыми при такой договоренности. Кроме того, фактические данные в реальном времени чрезвычайно полезны с точки зрения тестирования. Усилия по приватизации или анонимизации должны быть сосредоточены исключительно на данных, которые конкретно регулируются.
Роберт Харви,
@RobertHarvey, это неработоспособно, только если вы не можете воспроизвести проблему производства в среде разработчика. Я думаю, что за всю свою карьеру (в течение долгого времени) я могу рассчитывать на пару пальцев, сколько раз надлежащим образом обработанные данные испытаний не подходили для воспроизведения производственной ошибки. «Собственная бизнес-информация» выходит далеко за рамки номеров SSN и CC!
Dwoz
4
Но если вы собираетесь пойти по этому пути, у вас будут ИТ-специалисты, которые не могут выполнять свою работу, потому что у них нет административного доступа ко всему. Я признаю, что это вызывает потенциальные проблемы Сноудена, но я не вижу работоспособной альтернативы, кроме как нанять людей, которым вы можете доверять. Сарбейнс Оксли и HIPAA очень точно определяют, какие данные должны быть изолированы, и они не включают «все производственные данные», не говоря уже о том, что нужно. Тем не менее, я не верю, что производственные данные любого рода должны существовать на ноутбуках в роуминге.
Роберт Харви
1
-1 НИКОГДА. Ваши более подробные комментарии лучше, чем ваш ответ; Вы должны отредактировать их в этом.
1
@ dan1111 тогда мы можем согласиться не соглашаться. Данные клиента "как есть" НИКОГДА НЕ ДОЛЖНЫ использоваться в системах разработки. Это всегда должно быть продезинфицировано. Вы не верите этому, потому что вас еще не укусил этот бешеный мангуст ... и вот что это, когда это случается. Бешеный безумный грызун, который намеревается взять у тебя кровь. Прими мой совет, избегай бешеного мангуста.
Двое
1

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

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

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

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

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

папараццо
источник
0

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

Джейсон Кросби
источник
это, кажется, просто повторяет высказанное и объясненное в верхнем ответе неделю назад
комнат