Является ли разделение баз данных законной мерой безопасности?

Question

Когда предыдущим разработчикам в моей компании приходилось хранить конфиденциальные данные пользователя (например, медицинские записи), они делали следующее. Я сомневаюсь в его достоинствах.

1. Есть данные, считающиеся "нечувствительными" (логин пользователя, информация профиля) и "чувствительными" (медицинские записи пользователя).
2. Есть три базы данных. Нечувствительные данные в A, медицинские записи в B и отображение между A и B в C.
3. Хакер должен взломать все три базы данных, чтобы привязать пользователей (A) к медицинским записям (B).

Наш собственный внутренний код вызывает C, чтобы связать A и B данные вместе для отображения пользователем. Я думаю, что повсеместность этого кода сводит на нет преимущества разделения баз данных: если хакер получает доступ к нашей системе, он может назвать нашу логику.

Какие преимущества вышеуказанной системы я упускаю (или есть более эффективные способы защиты таких данных)?

Answer 1

Да, разделение данных на отдельные хранилища может помочь в обеспечении безопасности. Как пишет Джеймс Андерсон, большинство систем баз данных позволяют вам предоставлять разные привилегии отдельным таблицам.

Тем не менее, большинство анализов безопасности ищет самое слабое звено; Я сомневаюсь, что ваша самая слабая ссылка - это способ разделения ваших баз данных. Таким образом, если вы не прибегли к целой куче других вещей - управление паролями было очевидным, SQL-инъекция нападает на другое - в лучшем случае дизайн базы данных не имеет смысла; в худшем случае это добавляет сложности приложению, что вызывает ошибки; Большинство уязвимостей безопасности происходят от ошибок.

Это также может привести к ложному ощущению безопасности - «мы покрыты безопасностью, мы разделили наши базы данных» или кавалерскому отношению к защите «нечувствительных» данных.

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

Answer 2

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

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

Отвечая на некоторые комментарии ниже, даже в конкретном случае вашей системы, это не предрешено, что «нарушение системы» означает нарушение всех баз данных одновременно. Предположим, что злоумышленник использует уязвимость SQL-инъекции в вашем приложении. Если данные сопоставления являются отдельными и защищенными (скажем, дополнительные элементы управления кодом, который обращается к сопоставлениям), то изоляция может быть разницей между раскрытием неассоциированных и связанных данных.

Не утверждая, что это хороший дизайн для вашей системы. Просто пытаюсь объяснить различные виды обоснования, которое может пойти в этом.

Я использую ту же стратегию изоляции в аналогичной ситуации. «Базы данных» в моем случае - это хранилища конфигурации. Вся конфигурация preprod идет в одном репо, а производственная конфигурация идет в отдельном репо. Все разработчики имеют доступ к предварительному репо, но только инженеры по выпуску имеют доступ к репо. Смысл в том, что мне нужна глубокая защита: хотя я, безусловно, мог бы реализовать контроль доступа к отдельным папкам репо, я бы предпочел сделать рабочую конфигурацию просто недоступной по сети для всех неавторизованных сотрудников.

Answer 3

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

IЯ уверен, что у определенного человека будет достаточно информации, чтобы решить, что базы данных X, Y и Z связаны - если только вы не запутываете имена баз данных, имена таблиц и другие структурные показатели.

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

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

Answer 4

В большинстве серьезных систем СУБД вы можете контролировать доступ на уровне таблицы (иногда даже на уровне строк).

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

Пока ничто не защитит вас от хакера, который получит root (как отмечали другие авторы). Но эта стратегия защитит вас от несанкционированных пользователей в вашей системе, получающих доступ, а также от хакеров, которые получили свои идентификаторы и пароли. Так как подделка низкоуровневых сотрудников для предоставления информации о паролях все еще является одной из самых распространенных «атак», это стоит того.

Большое «если» - действительно ли вы можете разделить своих пользователей на группы «иметь доступ» и «иметь ограниченный доступ»?