Есть ли способ запретить пользователям делать массовые записи в базе данных Postgresql

Question

У меня есть 4 новых пользователя для ввода данных, которые используют определенный графический интерфейс для создания / обновления / удаления записей в нашей основной базе данных. Клиент "GUI" позволяет им видеть записи базы данных на карте и вносить в них изменения, что является хорошим и предпочтительным способом сделать это.

Но в последнее время многие парни обращались к локальной базе данных напрямую с помощью PGAdmin и запускали массовые запросы (например, обновление, вставка, удаление и т. Д.), Что порождает множество проблем, таких как люди, обновляющие множество записей, не зная или не делая ошибок при установке значений. Это также влияет на наши процедуры регистрации, так как мы рассчитываем средние значения и временные метки для целей отчетности, которые для нас очень важны.

Итак, есть ли способ запретить пользователям использовать PGAdmin (помните, что многие из них работают дома, а у нас нет доступа к их машинам) и запускают SQL-запросы непосредственно в базе данных.

Нам все еще нужно предоставить им доступ к определенным таблицам и разрешить им выполнять sql, пока он проходит через определенного клиента, но запретить доступ тому же пользователю, когда он / она пытается выполнить запрос непосредственно в БД.

Answer 1

Единственный разумный способ управления доступом к вашей базе данных - это преобразование ваших методов доступа в БД в трехуровневую структуру.Вы должны создать промежуточное программное обеспечение (может быть, какой-нибудь API отдыха или что-то подобное) и использовать этот API из своего приложения.База данных должна быть скрыта за этим промежуточным программным обеспечением, поэтому прямой доступ невозможен.С точки зрения БД, нет никаких способов узнать, является ли одно соединение с базой данных вашим приложением или каким-либо другим инструментом (pgadmin, простой psql или какой-либо пользовательский клиент сборки).Ваша база данных должна быть доступна только с доверенных хостов, а клиенты не должны иметь доступ к этим хостам.

Answer 2

То, что вы хотите сделать, это отозвать у ваших пользователей права на запись, затем создать новую роль с правами на запись, а затем в качестве этой роли вы СОЗДАЕТЕ ФУНКЦИЮ, определенную как SECURITY DEFINER, которая обновляет таблицу так, как вы разрешаете с проверками целостности, тогда GRANT EXECUTE доступ к этой функции для ваших пользователей.

На эту тему есть ответ на ServerFault , в котором содержится ссылка на следующую запись в блоге с подробным описанием.

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

Answer 3

Вы должны изучить дополнительные pg_hba.conf настройки .

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

• GSSAPI
• 1011 * Керберос *
• ССПИ
• Радиус сервера
• любой метод PAM

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

Answer 4

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

Позвольте этому приложению фильтровать и передавать только разрешенные команды.

При фильтрации следует проявлять большую осторожность - я бы тщательно подумал, будет ли вообще разрешен необработанный SQL.Лично я разработал бы некоторый упрощенный API, который позволил бы мне быть уверенным, что гипотетический клиент-злоумышленник ( Мы верим в Бога, все остальные, за которыми мы следим ) не найдут способ подкрасться к некоторой опасной модификации.

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

Answer 5

Это возможно только в том случае, если вы используете хитрость (которая также может быть использована, но, возможно, ваши пользователи не слишком умны).

В вашем клиентском приложении установите некоторый безвредный параметр, например geqo_pool_size = 1001 (еслиобычно это 1000).

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

Альтернативы: Создать временную таблицу и проверить ее существование.