Вопрос безопасности / масштабирования базы данных - PullRequest
0 голосов
/ 15 июня 2010

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

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

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

Ответы [ 2 ]

3 голосов
/ 15 июня 2010

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

Чтобы ответить на три вопроса:

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

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

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

  1. масштабируемость: это просто функция нагрузки. К сожалению, единственный способ масштабирования большинства приложений баз данных - это масштабирование. Это означает, что вы приобретаете больший сервер базы данных по мере необходимости. Переполнение стека прошло через это не так давно. Некоторые типы баз данных (nosql, mongodb и т. Д.) Поддерживают концепцию, известную как уничтожение или разбиение. MySql, PostGreSql и т. Д. Нет. Вместо этого вам придется специально разработать приложение, чтобы справиться с ним. Это означает, что не нужно использовать такие вещи, как автоинкрементные ключи и т. Д. Это может быть королевская PITA ... поэтому масштабирование гораздо проще в зависимости от вашего приложения.

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

2 голосов
/ 15 июня 2010

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

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

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

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

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

...