Вопрос о безопасности базы данных / масштабировании

Question

Обычно я использую базу данных, такую как MySQL или PostgreSQL, на том же компьютере, что и приложение, использующее ее, что делает доступ простым и безопасным.Я только сейчас создаю первый сайт, у которого будет отдельный физический сервер базы данных (он появится позже в этом году).Меня интересуют 3 вещи:

1. (безопасность) На что мне следует обратить внимание для начала, касающееся безопасности доступа к базе данных отдельного компьютера?
2. (масштабируемость) Есть ли у них проблемы с масштабируемостью, о которых я должен подумать, связанные с этим (независимо от технологии)?
3. (подробнее ServerFaultish, но связанный) При запуске базы данных на том же физическом сервере (с использованием отдельной виртуальной машины VMware) и последующем переходе на другой физический сервер, есть ли скрытые проблемы, с которыми мне придется иметь дело?Разве доступ к другой виртуальной машине по-прежнему осуществляется не через localhost?

Если эти вопросы совершенно нелепы, я приношу извинения вам, экспертам по БД.

Answer 1

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

Однако, чтобы перейти к вашим трем вопросам:

1. Сначала рассмотрим, как можно ограничить доступ к таблицам базы данных, используя модель безопасности серверов баз данных.А именно, если вашему приложению не нужно удалять таблицы, убедитесь, что пользователь, которого оно использует для подключения, не имеет такой возможности.Во-вторых, посмотрите, как зашифровать соединение между сервером базы данных и вашим приложением.В Windows это довольно прозрачно через kerberos и даже может быть реализовано с помощью параметров групповой политики, не уверен насчет других платформ.В-третьих, посмотрите, какими функциями обладает база данных для шифрования данных "в состоянии покоя".Имеется в виду, поддерживает ли он изначально шифрование самих файлов данных?

Дело здесь в том, что ваше приложение является только одной из возможных точек входа на сам сервер базы данных.Спросите себя, что произошло бы, если бы кто-то мог подключиться напрямую не просматривая ваше приложение используя учетные данные ваших приложений.Затем спросите, что может произойти, если они обнаружат проблему с SQL-инъекцией..Кроме того, спросите себя, какую информацию можно получить, если кто-то сможет отслеживать IP-трафик, проходящий между вашим приложением и сервером.Могут ли они различить Любой данные?Наконец, спросите себя, что, если они получат копию самой базы данных?

Длина, на которую вы пойдете для # 1, будет зависеть от нескольких факторов, таких как ценность данных (например:что случилось бы с вами, вашей компанией или вашими клиентами, если бы это было потеряно);и сколько времени у вас есть, чтобы придумать идеальное решение?

2. масштабируемость:Это чисто функция нагрузки.К сожалению, единственный способ масштабирования большинства приложений баз данных - это увеличение масштаба.Это означает, что вы приобретаете сервер базы данных большего размера по мере необходимости.Stack Overflow прошел через это не так давно.Некоторые типы баз данных (nosql, mongodb и т.д.) Поддерживают концепцию, известную как измельчение или сегментирование.MySQL, PostgreSQL и т.д. Этого не делают.Вместо этого вам придется специально разработать приложение, чтобы справиться с этим.Это означает, что не нужно использовать такие вещи, как ключи автоматического увеличения и т.д.Это может быть королевский ЛАВАШ...вот почему масштабирование - это гораздо более простая перспектива, в зависимости от вашего приложения.

3. Другая виртуальная машина недоступна через "localhost".localhost определяет доступ к вашему текущему серверу.Является ли этот сервер виртуальной машиной или нет, не имеет значения.Вам нужно будет ссылаться на свой сервер базы данных по имени.Теперь перенос виртуальной машины базы данных на другой физический сервер должен иметь нулевой эффект, поскольку вы ссылаетесь на нее по имени.Помимо этого, нет никаких других соображений.

Answer 2

В дополнение к обоснованному ответу Криса,

Безопасность

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

Масштабируемость

При переходе с локальных баз данных на удаленные возникает одна проблема масштабируемости.Удаленная связь по протоколу TCP / IP происходит намного медленнее, чем локальная связь по каналу.Возможно, у вашего приложения есть скрытые проблемы с масштабируемостью из-за частых обращений к базе данных.Между каждым запросом ваше приложение последовательно ожидает ответа каждой базы данных.В локальной системе задержка настолько мала, что вы, возможно, ее не заметили.