Postgres ACL для схем

Question

Я не администратор базы данных, и у меня есть некоторые вопросы по элементам управления доступом для схем. Предположим, у меня есть сервер Postgres, на котором запущено несколько баз данных. Пользователь admin - postgres. У меня есть еще один пользовательский tmpUser, с которым я могу войти на удаленный сервер, используя pgadmin3 client.

Теперь я создаю базу данных myDatabase, которая по умолчанию принадлежит пользователю postgres. Затем я использую свой администратор для удаленного входа в эту myDatabase с помощью учетной записи tmpUser.

Теперь я создаю новую схему внутри этой myDatabase, называемую myDbSchema. Я создал новую роль под названием myDbRole и использовал использование гранта, предоставил все на myDatabase, myDbSchema myDbRole.

Вопрос теперь в том, как я должен контролировать доступ к этой myDatabase. Я попытался войти на удаленный сервер, используя tmpUser, и когда я попытался выполнить select * from myTable, где myTable - это таблица в myDatabase, она вернулась с разрешением, отклоненным sql-сообщением. Поэтому я изменил владельца таблицы на tmpUser, которого я действительно не хочу!

Есть ли руководство или что-то о том, как мне следует создавать и организовывать роли с помощью схем в postgres?

Answer 1

Это не совсем понятно, в чем ваша проблема (например, то, что роль «myDbRole» для, является то, что группа роли (NOLOGIN) или роль пользователя (LOGIN)?), Но в целом вы могли бы следовать этому образцу управления разрешениями:

1. Создайте определенную роль, чтобы иметь собственную базу данных и все или большинство объектов в ней. Это должно быть групповой ролью (NOLOGIN) по соображениям безопасности. Не используйте пользователя postgres; если вам нужно часто входить в эту роль, чтобы выполнять обычную работу с базой данных, вы делаете что-то неправильно. Любой суперпользователь (или другая роль пользователя, которому предоставлена ​​эта роль) может «олицетворять» эту роль владельца, используя SET SESSION AUTHORIZATION для выполнения необходимого обслуживания. В производственной среде это вряд ли понадобится; во время разработки вы, возможно, захотите рассмотреть вопрос о том, чтобы сделать роль с разрешением LOGIN для удобства использования.
2. Владелец создает все схемы, таблицы, представления, функции и т. Д., Которые необходимы для вашего приложения. По умолчанию все эти объекты доступны только владельцу базы данных, за исключением функций.
3. Определите несколько профилей ролей групп, каждый из которых имеет конкретные требования к базе данных. Вы могли бы, например, sales_staffproduct_managers, accounting и senior_management для компании, или web_user, web_admin, app_developer и app_manager для веб-сайта. Владелец базы данных затем GRANT s доступ к базе данных (CONNECT), схемы (USAGE), таблицы, представления и функции (EXECUTE), при необходимости. Я обычно REVOKE ALL ON FUNCTION x() TO public, из соображений безопасности.
4. Присвойте членство в ролевой группе роли пользователя, если необходимо: GRANT sales_staff TO jane. Роли пользователей должны иметь LOGIN INHERIT, чтобы они могли входить в систему и наследовать разрешение ролей групп, членом которых они являются. Это включает в себя разрешение на подключение к базе данных и права использования на схемах. Обратите внимание, что одна роль пользователя может иметь членство в нескольких групповых ролях.

Наконец, обновите файл pg_hba.conf, чтобы включить удаленный доступ к базе данных.