Ограничить запросы MySQL - PullRequest
Новая
       6

Ограничить запросы MySQL

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

Контекст: Клиентскому приложению Java требуется доступ к базе данных MySQL на стороне сервера.

Необходимость: Ограничение возможного количества запросов к базе данных для каждого клиента (на основе IP-адреса клиента).

Вопрос 1: Можно ли сделать это, просто изменив настройки базы данных MySQL?

Вопрос 2: Это хорошая идея, чтобы разрешить доступ к базе данных непосредственно из клиентского приложения? Или мне лучше заставить клиентское приложение взаимодействовать с серверным приложением по TCP? (и, следовательно, разрешить доступ к БД только приложению на стороне сервера)

Ответы [ 4 ]

4 голосов
/ 04 июня 2010

  1. Да. Посмотрите на синтаксис оператора MySQL GRANT . В параметре with_option вы можете указать MAX_QUERIES_PER_HOUR. Вы даже можете установить ограничения для существующего пользователя, не затрагивая другие привилегии:

    GRANT USAGE ON db. * Чтобы ... ЗАПРОСИТЬ SSL С MAX_QUERIES_PER_HOUR 120 MAX_UPDATES_PER_HOUR 100;

  2. Конечно, пока клиенты находятся во внутренней сети базы данных и им предоставляются только минимальные разрешения, необходимые им для правильной работы. Может быть несколько сложно поддерживать гранты MySQL для всех клиентов, но по крайней мере вы будете использовать проверенную систему безопасности, а не пытаться переписать систему безопасности как приложение на стороне сервера, в котором могут быть ошибки.

См. Также 5.5.4. Установка лимитов ресурсов учетной записи .

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

о вопросе 2.

Я думаю, что это зависит от чувствительности данных, сетевого соединения между сервером и клиентом и схемы развертывания клиентов.

  • Конфиденциальные данные: я бы точно выбрал решение клиент-сервер-БД для этого. Затем вы можете реализовать https-подключения с использованием, возможно, клиентских сертификатов или устройств чтения карт.
  • Сетевое соединение: вы не хотите выставлять БД в интернет. Когда-либо. Но если это внутреннее приложение, доступное только из защищенной сети компании, и данные не являются конфиденциальными, возможно прямое соединение с БД. Правильно выполняйте блокировку строк или обработку транзакций, иначе ваши пользователи не будут довольны:)
  • Схема развертывания. Если приложение активно разрабатывается, существует большая вероятность того, что схема базы данных изменится вместе с ним, заставляя клиентов обновляться. При использовании промежуточного сервера, например, SOAP / XML, вы отделяете схему базы данных от запросов данных и у вас появляется больше возможностей для обновления / изменения базы данных без обновления всех клиентов.

Я бы лично выбрал промежуточный сервер, так как его проще поддерживать и оптимизировать. В Python и Java есть хорошие решения, которые позволяют быстро создавать серверы SOAP / XML с доступом к базе данных. Затем вы можете определить сообщения XML на основе того, что необходимо на определенном экране, с соответствующими блокировками и без учета (ehm) схемы базы данных. Он отделяет модель базы данных от модели MVC на клиенте и позволяет клиенту быть относительно чистым.

2 голосов
/ 04 июня 2010
  1. Вы можете ограничить доступ к БД пользователем и хостом.
  2. Это зависит от чувствительности передаваемых вами данных и используемой сети (Интернет или ЛВС).
1 голос
/ 04 июня 2010

Клиент -> Сервер -> База данных, безусловно, является наиболее безопасным подходом, поскольку Клиент -> База данных требует, чтобы клиентское приложение содержало учетные данные для входа в базу данных.

Переход с клиента -> сервер -> база данных обнуляет вопрос один:].

...