Управление доступом
Привилегии
13
Авторские права
© Postgres Professional, 2015‒2022
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Виды привилегий для разных объектов
Категории ролей с точки зрения управления доступом
Групповые привилегии
Выдача и отзыв привилегий и право передачи
Привилегии по умолчанию
Примеры управления доступом
3
Привилегии
Привилегии определяют права доступа ролей к объектам
Таблицы
SELECT чтение данных
INSERT вставка строк
UPDATE изменение строк
REFERENCES внешний ключ
DELETE удаление строк
TRUNCATE опустошение таблицы
TRIGGER создание триггеров
Представления
SELECT чтение данных
TRIGGER создание триггеров
можно на уровне столбцов
Привилегии определяются на пересечении объектов кластера и ролей.
Они ограничивают действия, доступные для ролей в отношении этих
объектов.
Список возможных привилегий отличается для объектов различных
типов. Привилегии для объектов основных типов приведены на этом и
следующем слайдах.
Больше всего привилегий определено для таблиц. Некоторые из них
можно определить не только для всей таблицы, но и для отдельных
столбцов.
4
Привилегии
Табличные пространства,
базы данных, схемы
Последовательности
SELECT currval
UPDATE nextval setval
USAGE currval nextval
база данных
схема pg_temp
табл.
пр-во
таблица
таблица
объект
CREATE
USAGE
CREATE
таблица
таблица
объект
TEMPORARY
CREATE
CONNECT
Возможно, несколько неожиданный набор привилегий имеют
последовательности. Выбирая нужные, можно разрешить или
запретить доступ к трем управляющим функциям.
Для табличных пространств есть привилегия CREATE, разрешающая
создание объектов в этом пространстве.
Для баз данных привилегия CREATE разрешает создавать схемы в этой
БД, а для схемы привилегия CREATE разрешает создавать объекты
в этой схеме.
Поскольку точное имя схемы для временных объектов заранее
неизвестно, привилегия на создание временных таблиц вынесена на
уровень БД (TEMPORARY).
Привилегия USAGE схемы разрешает обращаться к объектам в этой
схеме.
Привилегия CONNECT базы данных разрешает подключение к этой БД.
5
Категории ролей
Суперпользователи
полный доступ ко всем объектам — проверки не выполняются
Владельцы
доступ в рамках выданных привилегий
(изначально получает полный набор)
а также действия, не регламентируемые привилегиями,
например: удаление, выдача и отзыв привилегий и т. п.
Остальные роли
доступ исключительно в рамках выданных привилегий
В целом можно сказать, что доступ роли к объекту определяется
привилегиями. Но можно выделить три категории ролей.
1. Проще всего с ролями с атрибутом суперпользователя. Такие роли
могут делать все, что угодно — для них проверки разграничения
доступа не выполняются.
2. Владелец объекта сразу получает полный набор привилегий для
этого объекта. В принципе, эти привилегии можно отозвать, но
владелец объекта обладает также неотъемлемым правом совершать
действия, не регламентируемые привилегиями. В частности, он может
выдавать и отзывать привилегии (в том числе и себе самому), удалять
объект и т. п.
3. Все остальные роли имеют доступ к объекту только в рамках
выданных им привилегий.
6
Управление привилегиями
Выдача привилегии
alice=> GRANT привилегии ON объект TO bob;
одна привилегия может быть независимо выдана разными ролями
Отзыв привилегии
alice=> REVOKE привилегии ON объект FROM bob;
alice bob
привилегии
на объект
Право выдачи и отзыва привилегий на объект имеет владелец этого
объекта (и суперпользователь).
Синтаксис команд GRANT и REVOKE достаточно сложен и позволяет
указывать как отдельные, так и все возможные привилегии; как
отдельные объекты, так и группы объектов, входящие в определенные
схемы и т. п.
8
Групповые привилегии
Роль получает привилегии групповых ролей,
в которые она включена
с атрибутом INHERIT привилегии наследуются автоматически
с атрибутом NOINHERIT требуется явное переключение
командой SET ROLE
Псевдороль public
неявно включает все остальные роли
Роль может получать привилегии для доступа к объекту не только
непосредственно, но и от групповых ролей, в которые она входит. Таким
образом, для упрощения администрирования можно выдать групповой
роли необходимый набор привилегий и затем выдавать пользователям
весь этот набор целиком. Групповую роль можно рассматривать как
особую привилегию; поэтому управление группами и выполняется теми
же командами GRANT и REVOKE, что и управление привилегиями.
Роль с атрибутом INHERIT (по умолчанию) автоматически обладает
привилегиями всех групп, в которые она входит. Это касается и
псевдороли public, в которую неявно входят все роли.
Если же роль создана как NOINHERIT, то она может воспользоваться
привилегиями группы, только выполнив команду SET ROLE и таким
образом переключившись на эту групповую роль. Все действия,
совершаемые ролью, будут совершаться от имени групповой роли
(например, групповая роль будет владельцем созданных объектов).
9
Преднастроенные роли
pg_signal_backend — завершение сеансов и отмена
запросов
pg_read_all_settings — чтение конфигурационных
параметров
pg_read_all_stats — доступ к статистике
pg_stat_scan_tables — доступ к статистике,
блокирующей доступ
pg_read_server_files — чтение файлов на сервере
pg_write_server_files — запись файлов на сервере
pg_execute_server_programs — выполнение программ на сервере
pg_monitor
В PostgreSQL уже есть ряд преднастроенных ролей, обладающих
рядом специальных привилегий для выполнения задач, которые
обычно может совершать только суперпользователь. Три последние
роли появилась в версии PostgreSQL 11.
Полный список всех ролей, включая предопределенные системные
роли, можно посмотреть в psql командой \duS.
Аналогично можно создавать и собственные групповые роли,
например, для управления резервным копированием и т. п.
11
Передача права
Выдача привилегии с правом передачи
alice=> GRANT привилегии ON объект TO bob WITH GRANT OPTION;
Отзыв привилегии
alice=> REVOKE привилегии ON объект FROM bob CASCADE;
Отзыв права передачи
alice=> REVOKE GRANT OPTION FOR
привилегии ON объект FROM bob CASCADE;
bob
charlie
alice
привилегии
dave
п
р
и
в
и
л
е
г
и
и
п
р
и
в
и
л
е
г
и
и
обязательно,
если привилегия
была передана
другим ролям
При выдаче роли полномочия можно передать ей право дальнейшей
передачи (и отзыва) этого полномочия. Это выполняется командой
GRANT … WITH GRANT OPTION. Если роль воспользуется этим
правом, образуется иерархия ролей.
Отозвать привилегию можно с помощью команды REVOKE. Роль может
отозвать привилегию только у той роли, которой она его выдала.
Например, в ситуации, показанной на слайде, alice не может отозвать
привилегию непосредственно у charlie или dave.
Однако при отзыве привилегии у bob привилегия будет автоматически
отозвана у всех ролей в иерархии. Для этого надо указать ключевое
слово CASCADE (если иерархия непуста, то без CASCADE будет
ошибка).
Право передачи можно отозвать, не отзывая у роли саму привилегию.
Это выполняется с помощью команды REVOKE GRANT OPTION FOR.
Слово CASCADE имеет здесь такое же значение, как и при отзыве
привилегии.
12
Вопрос
public
Привилегии на таблицу T получены Бобом от Алисы.
Если Алиса выполнит
REVOKE ALL ON T FROM bob CASCADE,
какие привилегии останутся у Чарли и Дейва?
alice
bob
select, update on T
select on T
dave
charlie
select on T
update on T
И у Чарли, и у Дейва останется только привилегия на чтение T,
полученная от public. Все привилегии, выданные Бобом другим ролям,
будут отозваны.
14
Подпрограммы
Единственная привилегия для функций и процедур
EXECUTE выполнение
Характеристики безопасности
SECURITY INVOKER выполняется с правами вызывающего
(по умолчанию)
SECURITY DEFINER выполняется с правами владельца
Для подпрограмм (функций и процедур) есть единственная привилегия
EXECUTE, разрешающая выполнение этой подпрограммы.
Тонкий момент состоит в том, от имени какого пользователя будет
выполняться подпрограмма. Если подпрограмма объявлена как
SECURITY INVOKER (по умолчанию), она выполняется с правами
вызывающего пользователя. В этом случае операторы внутри
подпрограммы смогут обращаться только к тем объектам, к которым
у вызывающего пользователя есть доступ.
Если же указать фразу SECURITY DEFINER, подпрограмма работает
с правами ее владельца. Так можно позволить другим пользователям
выполнять определенные действия над объектами, к которым у них нет
непосредственного доступа.
15
Привилегии public
По умолчанию роль public получает ряд привилегий
для баз данных CONNECT (подключение)
TEMPORARY (создание временных таблиц)
для схемы public CREATE (создание объектов)
USAGE (доступ к объектам)
для схем pg_catalog USAGE (доступ к объектам)
и information_schema
для подпрограмм EXECUTE (выполнение)
Удобно, но не безопасно
По умолчанию псевдороль public получает ряд привилегий (то есть,
фактически, их получают все роли):
- подключение и создание временных таблиц для всех баз данных;
- использование схемы public и создание в ней объектов;
- использование схем pg_catalog и information_schema;
- выполнение всех функций и процедур.
(В PostgreSQL 15 роль public лишится права создания объектов.)
Такое поведение может оказаться нежелательным. В этом случае надо
явно отозвать у public привилегии. Это можно сделать и в шаблонной
базе данных template1, чтобы изменения распространялись на новые
базы данных. Но для отзыва прав на подпрограммы надо пользоваться
механизмом привилегий по умолчанию, о котором будет сказано
дальше в этой теме.
17
Привилегии по умолчанию
Способ выдать или отозвать привилегии
при создании объекта
ALTER DEFAULT PRIVILEGES
[ FOR ROLE список_целевых_ролей ]
[ IN SCHEMA схема ]
GRANT привилегии ON класс_объектов TO роль;
ALTER DEFAULT PRIVILEGES
REVOKE привилегии ON класс_объектов FROM роль;
REVOKE
EXECUTE ON ROUTINES
FROM public
Можно настроить дополнительные привилегии, выдаваемые или
отзываемые при создании объекта. Для этого используется команда
ALTER DEFAULT PRIVILEGES.
Механизм срабатывает, когда целевая_роль (по умолчанию — текущий
пользователь) создает объект, принадлежащий указанному
классу_объектов (например, таблицы или функции) в указанной схеме
(по умолчанию — в любой). Предложение GRANT говорит о том, что на
созданный объект надо выдать указанные привилегии для указанной
роли. Предложение REVOKE, наоборот, используется для отзыва
привилегий.
Для роли public механизм привилегий по умолчанию выдает право
выполнения при создании подпрограмм. Чтобы public не получал такое
право, надо выдать команду
ALTER DEFAULT PRIVILEGES
FOR ROLE …
REVOKE EXECUTE ON ROUTINES FROM public;
При этом в предложении FOR ROLE надо указать все роли, которые
могут создать подпрограммы.
19
Пример 1
kolya
create, usage
kolya
vasya
semsem
create, usage
semsem
s
e
l
e
c
t
vasya
create, usage
s
e
l
e
c
t
Механизмы управления доступом (роли, атрибуты и привилегии,
а также схемы) весьма гибки и позволяют в разных случаях
организовать работу удобным образом. Приведем несколько примеров.
Пример простого использования.
Семен Семенович и его студенты Коля и Вася занимаются научными
исследованиями и хранят результаты измерений в базе данных.
Администратор создал на факультетском сервере БД каждому из них
своего пользователя и одноименную схему. Путь поиска он оставил по
умолчанию. Групповые роли не используются.
Каждый пользователь является владельцем объектов, которые он
создает в своей схеме. Кроме того, Коля и Вася дают доступ
к некоторым своим таблицам Семену Семеновичу, чтобы он мог
посмотреть их результаты.
20
Пример 2
inventory
usage
inv
fin
financials
usage
kladovkin
dostavkin
bigboss
kopeikina
roublev
Более сложный пример.
На выделенный сервер БД установлена система автоматизации
предприятия. Она состоит из двух модулей — складского и
финансового.
Для каждого из модулей создана своя схема (inv для склада и fin для
финансов) и своя групповая роль (inventory для склада и financials для
финансов). Групповая роль является владельцем всех объектов в своей
схеме.
В складском отделе работают Кладовкин и Доставкин. Для каждого
создан свой пользователь и включен в группу inventory.
В финансовом отделе работают Копейкина и Рублев. Для каждого
создан свой пользователь и включен в группу financials.
Для генерального директора предприятия на всякий случай создан
пользователь, включенный в обе группы, хотя вряд ли он когда-либо
воспользуется системой.
21
Пример 3
app
usage
application
support
select on all tables
сервер
приложений
веб-пользователи
Очень часто бывает так, что аутентификация пользователей
информационной системы происходит не в СУБД, а на сервере
приложений. Действительно, если у системы тысячи пользователей и
есть возможность онлайн-регистрации, нет никакого смысла управлять
ими в СУБД.
В этом случае сервер приложений подключается к базе данных под
одной заранее созданной ролью, а информацию о пользователе
передает при необходимости в виде какого-то контекста.
Но даже и в этом случае в СУБД наверняка понадобятся несколько
ролей. Например, специальная роль для технической поддержки,
сотрудники которой смогут читать таблицы основного сервера для
быстрого решения проблем.
22
Итоги
Привилегии определяют права доступа ролей к объектам
Роли, атрибуты и привилегии, схемы — гибкий механизм,
позволяющий по-разному организовать работу
можно легко разрешить все всем
можно строго разграничить доступ, если это необходимо
23
Практика
Настройте привилегии таким образом, чтобы одни пользователи
имели полный доступ к таблицам, а другие могли только
запрашивать, но не изменять информацию.
1. Создайте новую базу данных и две роли: writer и reader.
2. Отзовите у роли public все привилегии на схему public,
выдайте роли writer обе привилегии, а роли reader — только usage.
3. Настройте привилегии по умолчанию так, чтобы роль reader
получала доступ на чтение к таблицам, принадлежащим writer
в схеме public.
4. Создайте пользователей w1 в группе writer и r1 в группе reader.
5. Под пользователем writer создайте таблицу.
6. Убедитесь, что r1 имеет доступ к таблице только на чтение,
а w1 имеет к ней полный доступ, включая удаление.
24
Практика+
1. Создайте роль alice. Создайте таблицу.
Выдайте роли alice привилегию на чтение таблицы
и привилегию на изменение с правом передачи.
2. Проверьте права доступа к созданной таблице с помощью
представления table_privileges информационной схемы.
Сравните с выводом команды \dp.
3. Проверьте права доступа к созданной таблице с помощью
функции has_table_privilege.
2. Другие представления информационной схемы:
3. Другие функции для проверки привилегий:
