Управление доступом

Подходы к настройке

Авторские права

Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов, Алексей Береснев

Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)

Использование материалов курса

Некоммерческое использование материалов курса (презентации,

демонстрации) разрешается без ограничений. Коммерческое

использование возможно только с письменного разрешения компании

Postgres Professional. Запрещается внесение изменений в материалы

курса.

Обратная связь

Отзывы, замечания и предложения направляйте по адресу:

edu@postgrespro.ru

Отказ от ответственности

Компания Postgres Professional не несет никакой ответственности за

любые повреждения и убытки, включая потерю дохода, нанесенные

прямым или непрямым, специальным или случайным использованием

материалов курса. Компания Postgres Professional не предоставляет

каких-либо гарантий на материалы курса. Материалы курса

предоставляются на основе принципа «как есть» и компания Postgres

Professional не обязана предоставлять сопровождение, поддержку,

обновления, расширения и изменения.

Темы

Администрирование без прав суперпользователя

Примеры организации доступа

Без суперпользователя

Административные роли

Предопределенные роли

Управление ролями

Административные роли

Не имеют атрибута суперпользователя

Используются для отдельных действий по сопровождению

административные атрибуты

параметр членства ADMIN

предопределенные роли

привилегии на параметры сервера

привилегии на системные функции

Традиционное администрирование баз данных средствами

суперпользователя удобно отсутствием каких-либо ограничений.

Однако в этом случае администратор имеет полный доступ ко всем

данным, а любая его ошибка может стать фатальной для системы.

Так же и злоумышленник или вредоносное ПО, получив максимальные

права, смогут прочитать любую информацию, повредить данные или

даже разрушить систему. Поэтому в производственной среде для

выполнения конкретных действий по сопровождению часто определяют

отдельные административные роли.

Дать административные права таким ролям можно с помощью:

●

атрибутов CREATEDB, CREATEROLE, BYPASSRLS, REPLICATION;

●

параметра членства ADMIN;

●

предопределенных ролей;

●

привилегий на изменение параметров сервера;

●

привилегий на отдельные системные функции;

●

привилегии MAINTAIN на отдельные таблицы для выполнения

административных команд, таких как VACUUM (начиная с

PostgreSQL 17).

Большинство из этих возможностей были рассмотрены в предыдущих

темах курса.

Предопределенные роли

Мониторинг

Чтение любых параметров настройки

Выполнение задач обслуживания

Владение базами данных

Доступ к любым таблицам на чтение или запись

Доступ к любым файлам сервера на чтение или запись

Передача сигналов обслуживающим процессам

…

В PostgreSQL имеется набор предопределенных ролей, дающих доступ

к часто востребованным, но не общедоступным функциям и данным.

Имеются роли, которые позволяют обращаться к любым таблицам

независимо от факта владения и наличия привилегий, разрешают

доступ к файлам и программам на сервере (разумеется, от имени

пользователя ОС postgres, под которым выполняется обслуживающий

процесс), позволяют завершать обслуживающие процессы и т. д.

https://postgrespro.ru/docs/postgresql/16/predefined-roles

Атрибут CREATEROLE

создание, изменение и удаление ролей

членство с параметром ADMIN в созданных ролях

alice=> CREATE ROLE bob;

Управление ролями

alice

bob

ADMIN

CREATEROLE

Если роль имеет атрибут CREATEROLE, она может создавать и удалять

другие роли, а также изменять их атрибуты. Созданная роль

автоматически включает в себя создавшую ее роль с параметром

членства ADMIN. Таким образом, роль с атрибутом CREATEROLE

может управлять членством в созданных ею ролях.

Чтобы создать роль с одним из атрибутов SUPERUSER, CREATEDB,

REPLICATION или BYPASSRLS, создающая роль должна сама

обладать соответствующим атрибутом.

Суперпользователи могут управлять включением любых ролей

в любые.

Примеры настройки

Личные схемы

Групповой доступ

Группа-владелец

Внешние пользователи

Личные схемы

alice

bob

walter

bob

ADMIN

SET

CREATE, USAGE

SELECT

CREATEROLE

CREATEDB

Механизмы управления доступом (роли, атрибуты и привилегии,

а также схемы) весьма гибки и позволяют в разных случаях

организовать работу удобным образом.

Мы рассмотрим несколько вариантов настройки доступа, чтобы

показать, как изученные в предыдущих темах возможности могут

работать в реальных ситуациях.

Начнем с простого примера. Алиса и Боб занимаются научной работой

под руководством Уолтера и хранят результаты измерений на сервере

в базе данных своей лаборатории.

Уолтер не является суперпользователем, администратор баз данных

предоставил ему атрибуты CREATEDB и CREATEROLE. Благодаря

этому Уолтер может создавать роли для сотрудников и управлять ими.

Путь поиска установлен в значение по умолчанию, чтобы

пользователям было удобно работать со своими схемами, не указывая

их явно. Каждый пользователь становится владельцем объектов,

которые он создает в своей схеме. Уолтер имеет права чтения таблиц

в схемах сотрудников.

Групповой доступ

bio_lab

chem_lab

alice

walter

charlie

SET

INHERIT

SET

INHERIT

bob

USAGE

ALL

ADMIN

Более сложный пример.

Все лаборатории университета теперь хранят информацию на одном

сервере, в одной базе данных. При этом каждая лаборатория хранит

свои таблицы в отдельной схеме.

Чтобы упростить настройку, все сотрудники лаборатории включены

в групповую роль, имеющую необходимые привилегии.

Чтобы гарантировать порядок, Уолтер создает необходимые объекты

сам; он является владельцем и схем, и объектов в них.

Группа-владелец

bio_lab

application

alice

walter

dave

SET

INHERIT

SET

bob

USAGE

ALL

ADMIN

Если работа с данными происходит через приложение, конечные

пользователи могут и не догадываться о том, какие объекты

существуют в базе данных. Созданием и сопровождением приложения

занимаются разработчики, для которых в базе данных также созданы

пользователи.

Разработчиков может быть несколько, но удобно, чтобы всеми

объектами владела одна роль — и с точки зрения администрирования,

и чтобы можно было выполнять подпрограммы от имени владельца.

Для установки нужного владельца есть два способа:

●

использовать команду смены владельца после создания объекта;

●

переключиться на групповую роль, которая должна владеть

объектом, а затем создать объект.

В обоих случаях требуются членство ролей разработчиков в групповой

роли владельца объектов с параметром SET.

Внешние пользователи

bio_lab

application

walter

dave

SET

USAGE

ALL

сервер

приложений

веб-пользователи

аутентификация

app

служебная

информация

приложения

ADMIN

Очень часто бывает так, что аутентификация пользователей

информационной системы происходит не в СУБД, а на сервере

приложений. Действительно, если у системы тысячи пользователей,

регистрирующихся онлайн, нет никакого смысла управлять ими в СУБД.

В этом случае сервер приложений подключается к базе данных под

одной общей ролью, а информацию о пользователе передает при

необходимости в виде какого-то контекста.

Но даже и в этом случае в СУБД наверняка понадобятся несколько

ролей. В нашем примере роли Алисы и Боба больше не нужны, но

остаются роли, связанные с разработкой. Может потребоваться роль

для технической поддержки, сотрудники которой смогут выполнять

ограниченный круг административных задач для быстрого решения

проблем, и т. п.

Обычно бывает удобно распределить объекты приложения по

нескольким схемам. Часто выделяют схему со служебной информацией

приложения: сеансами, учетными записями и т. д. Информацию,

относящуюся к предметной области, можно разделить на несколько

схем в соответствии с группами пользователей, таких как

администраторы, сотрудники компании и клиенты. Это упрощает

управление правами доступа.

Итоги

Отдельные задачи по сопровождению можно делегировать

привилегированным ролям

Схемы, роли и привилегии позволяют варьировать

строгость разграничения доступа в зависимости

от уровня доверия

Практика

Рассмотрите сценарий, в котором на одном сервере право

создания ролей имеют два пользователя.

1. Создайте базу данных и роли bio_lab и chem_lab, обе

с атрибутом CREATEROLE, владеющие одноименными

схемами.

2. От имени bio_lab создайте пользователей alice и bob, выдайте

им доступ к схеме bio_lab.

От имени chem_lab создайте пользователя charlie, выдайте

ему доступ к схеме chem_lab.

3. Убедитесь, что chem_lab не управляет пользователем alice.

4. Проверьте, что пользователи имеют доступ к «своим»

схемам.