Сохраните информацию о базе данных

Question

есть эта интересная проблема, которую я не могу решить самостоятельно. Я буду очень рад, если вы поможете мне.
Вот он:
Есть много клиентских приложений, которые отправляют записи данных на один сервер MySQL.
Немногие данные не очень важны, но вся база данных. (Вы можете себе представить, что facebook DB :))
Есть ли какой-либо способ гарантировать, что

• данные из БД не будет использоваться кем-либо, кроме истинного владельца
• DB сохранит основные функции, такие как сортировка и т. д.

Предполагая, что злоумышленник может загадочно получить полный доступ к серверу?
Вы не можете просто шифровать данные на стороне клиента и хранить их зашифрованными, поскольку клиентское приложение широко распространено, и злоумышленник может получить от него ключ.
Возможно, добавление некоторых слоев между приложением и БД или объединение методов шифрования на стороне клиента и на стороне сервера (с использованием встроенных методов mysql) помогут?

Answer 1

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

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

Решения, подобные TPM, обеспечивают защиту от физических потерь сервера, но не против скомпрометированного корня.

Ваш корень так же важен, как и основной ключ базы данных, поэтому вы должны защищать свой корень с тем же вниманием, что и ключи. Это означает настройку рабочих процедур, скрининг, у кого есть доступ к корню, поворот пароля root и т. Д. И т. Д. В тот момент, когда кто-то получает «таинственно полный доступ», игра в значительной степени потеряна.

Answer 2

Я понятия не имею, если такая вещь существует в MySql, но на уровне строк-версий в Oracle позволяет определить права доступа на уровне строк В базы данных: так что это означает, независимо от того, какой инструмент используемый для доступа к данным, пользователь только когда-либо видит тот же выбор, который определяется его/ее полномочиями.

Поэтому, если моему имени/роли разрешено видеть данные, ограниченные каким-либо предложением WHERE, которое может быть добавлено к каждому SELECT, которое появляется в базе данных, независимо от того, приходит ли оно из веб-приложения, инструмент SQL-запросов , или что-то еще.

Answer 3

Я буду использовать 2-й слой и firwall между ними. , так что у вас есть брандмауэр ---- веб-сервер --- брандмауэр - сервер второго уровня --- firewll --- db

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

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

Answer 4

Я в значительной степени согласен с ответом Ремуса Русану.

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

Если вы можете развернуть физический доступ к ящику злоумышленником, то есть несколько вещей, которые вы можете сделать, чтобы укрепить вашу безопасность. Прежде всего, я настроил бы ssh-доступ только для того, чтобы разрешать соединения только с определенного IP-адреса или IP-диапазона (и, конечно же, без доступа root). Вы также можете сделать это на своем брандмауэре. Это означает, что самым слабым звеном является ваш сервер (приложение, которое получает данные/запросы от клиентов, может быть веб-сервером и любыми сценариями, которые вы используете). Теперь вам просто нужно убедиться, что никто не сможет использовать ваш сервер. Есть намного больше вещей, которые вы могли бы сделать, чтобы ожесточить свою систему, но он считает, что было бы более уместно спросить на ServerFault.

Если вы беспокоитесь о физическом доступе к ПК, на самом деле вы ничего не можете сделать, и большинство вещей уже упоминалось в ответе Ремуса.

Существует еще один вариант. Это, безусловно, самый неэффективный способ от скорости и простоты разработки точки зрения, но он частично защитит вас от любой атаки на вашем сервере (включая физический). На самом деле это довольно просто, но немного сложно реализовать - только хранить зашифрованные данные в базе данных и обрабатывать все клиентские приложения шифрования/дешифрования с помощью javascript или flash. Только у клиента будет ключ, и данные всегда будут передаваться по проводу и сохранены в зашифрованном формате. Самый большой недостаток заключается в том, что, как только клиент забудет ключ, нет пути назад, данные недоступны.

Конечно, все дело в времени, деньгах и усилиях - с достаточным количеством этих вещей можно сломать все.