Управление доступом
Обзор
16
Авторские права
© Postgres Professional, 2017–2024
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов, Игорь Гнатюк
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Роли и атрибуты
Подключение к серверу
Парольная аутентификация
Привилегии и управление ими
Категории ролей
Групповые и предопределенные роли
Привилегии по умолчанию
Привилегии и подпрограммы
3
Роли и атрибуты
Роль может быть пользователем СУБД
не связана с пользователем ОС
Роли можно включать друг в друга
удобно при настройке доступа
Свойства роли определяются атрибутами
LOGIN возможность подключения
SUPERUSER суперпользователь
CREATEDB возможность создавать базы данных
CREATEROLE возможность создавать роли
и другие
Роли в PostgreSQL используют для двух целей. Во-первых, роль может
выступать как пользователь, подключающийся к СУБД. Во-вторых, роли
можно включать друг в друга — это удобно при настройке доступа.
Формально роли никак не связаны с пользователями операционной
системы, хотя многие программы это предполагают, выбирая значения
по умолчанию. Например, psql, запущенный от имени пользователя ОС
student, автоматически использует одноименную роль student (если
в ключах утилиты не указана какая-либо другая роль).
При создании кластера определяется одна начальная роль, имеющая
суперпользовательский доступ (обычно она называется postgres).
В дальнейшем роли можно создавать, изменять и удалять.
Роль обладает некоторыми атрибутами, определяющими ее общие
особенности и права (не связанные с определенными объектами).
Обычно атрибуты имеют два варианта, например, CREATEDB (дает
право на создание БД) и NOCREATEDB (не дает такого права).
Если у роли есть атрибут LOGIN, эта роль — пользователь. Если
NOLOGIN — роль не является пользовательской и не сможет
подключиться к серверу; такие роли обычно используют для включения
других ролей.
В таблице перечислены лишь некоторые из атрибутов.
5
Подключение к серверу
1. Строки pg_hba.conf просматриваются сверху вниз
2. Выбирается первая запись, соответствующая параметрам
подключения (тип, база, пользователь и адрес)
# TYPE DATABASE USER ADDRESS METHOD
local all postgres peer
local all all peer
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
local — сокет all — любая роль
host — TCP/IP имя роли
all — любая БД all — любой IP
имя БД IP/маска
доменное имя
listen_addresses
Для каждого нового клиента сервер определяет, надо ли разрешить
подключение к базе данных. Настройки подключения определяются
в конфигурационном файле pg_hba.conf («host-based authentication»).
Как и с основным конфигурационным файлом postgresql.conf,
изменения вступают в силу только после перечитывания файла
сервером (SQL-функцией pg_reload_conf() или командой reload утилиты
управления).
При появлении нового клиента сервер просматривает конфигурацион-
ный файл сверху вниз в поисках строки, подходящей к запрашиваемо-
му клиентом подключению. Соответствие определяется по четырем
полям: типу подключения, имени БД, имени пользователя и IP-адресу.
Ниже перечислены только самые основные возможности.
Подключение — local (unix-сокеты) или host (подключение по протоколу
TCP/IP).
База данных – ключевое слово all (соответствует любой БД) или имя
конкретной базы данных.
Пользователь — all или имя конкретной роли.
Адрес — all, диапазон IP-адресов или доменное имя. Не указывается
для типа local. По умолчанию PostgreSQL слушает входящие
соединения только с localhost; обычно параметр listen_addresses ставят
в значение «*» (слушать все интерфейсы) и дальше регулируют доступ
средствами pg_hba.conf.
6
Подключение к серверу
3. Выполняется аутентификация указанным методом
4. Удачно — доступ разрешается, иначе — запрещается
(если не подошла ни одна запись — доступ запрещается)
# TYPE DATABASE USER ADDRESS METHOD
local all postgres peer
local all all peer
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
trust — разрешить
reject — отказать
scram-sha-256 и md5 — запросить пароль
peer — спросить ОС
Когда в файле найдена подходящая строка, выполняется
аутентификация указанным в этой строке методом, а также
проверяется наличие атрибута LOGIN и привилегии CONNECT. Если
результат проверки успешен, то подключение разрешается, иначе —
запрещается (другие строки файла при этом уже не рассматриваются).
Если ни одна из строк не подошла, то доступ также запрещается.
Таким образом, записи в файле должны идти сверху вниз от частных
правил к общим.
Существует множество методов аутентификации:
Ниже перечислены только самые основные.
Метод trust безусловно разрешает подключение. Если вопросы
безопасности не важны, можно указать «все all» и метод trust — тогда
будут разрешены все подключения.
Метод reject, наоборот, безусловно запрещает подключение.
Методы scram-sha-256 запрашивает у пользователя пароль и проверяет
его соответствие хешу, который хранится в системном каталоге
кластера. Парольный метод md5 также используется, но объявлен
устаревшим.
Метод peer запрашивает имя пользователя у операционной системы и
разрешает подключение, если имя пользователя ОС и пользователя БД
совпадают (можно установить и другие соответствия имен).
7
Парольная аутентификация
На сервере
пароль устанавливается при создании роли или позже
пользователю без пароля будет отказано в доступе
пароль хранится в системном каталоге pg_authid
Ввод пароля на клиенте
вручную
из переменной окружения PGPASSWORD
из файла ~/.pgpass (строки в формате узел:порт:база:роль:пароль)
Если используется аутентификация по паролю, для роли обязательно
должен быть установлен пароль, иначе в доступе будет отказано.
Хеш-код пароля хранится в системном каталоге в таблице pg_authid.
Пользователь может вводить пароль вручную, а может
автоматизировать его ввод. Для этого есть две возможности.
Во-первых, можно задать пароль в переменной окружения
PGPASSWORD на клиенте. Однако это неудобно, если приходится
подключаться к нескольким базам, а также не рекомендуется из
соображений безопасности.
Во-вторых, можно задать пароли в файле ~/.pgpass на клиенте.
К файлу должен иметь доступ только его владелец (установлены права
доступа 600), иначе PostgreSQL проигнорирует его.
9
Привилегии
Привилегии определяют права доступа ролей к объектам
Таблицы и представления
SELECT чтение данных
INSERT вставка строк
UPDATE изменение строк
REFERENCES внешний ключ (для таблиц)
DELETE удаление строк
TRUNCATE опустошение (для таблиц)
TRIGGER создание триггеров
можно на уровне столбцов
Привилегии устанавливают связь между субъектами (ролями) и
объектами кластера. Они определяют действия, доступные для ролей в
отношении этих объектов.
Список возможных привилегий отличается для объектов различных
типов. Привилегии для основных типов объектов приведены на этом и
следующем слайдах.
Больше всего привилегий определено для таблиц и представлений.
Часть из них можно задать не только для всего отношения, но и для
отдельных столбцов.
10
Привилегии
Табличные пространства,
базы данных, схемы
Последовательности
SELECT currval
UPDATE nextval setval
USAGE currval nextval
база данных
схема pg_temp
табл.
пр-во
таблица
таблица
объект
CREATE
USAGE
CREATE
таблица
таблица
объект
TEMPORARY
CREATE
CONNECT
Возможно, несколько неожиданный набор привилегий имеют
последовательности. Выбирая нужные, можно разрешить или
запретить доступ к трем управляющим функциям.
Для табличных пространств есть привилегия CREATE, разрешающая
создание объектов в этом пространстве.
Для баз данных привилегия CREATE разрешает создавать схемы в этой
БД, а для схемы привилегия CREATE разрешает создавать объекты
в этой схеме.
Поскольку точное имя схемы для временных объектов заранее
неизвестно, привилегия на создание временных таблиц вынесена на
уровень БД (TEMPORARY).
Привилегия USAGE схемы разрешает обращаться к объектам в этой
схеме.
Привилегия CONNECT базы данных разрешает подключение к этой БД.
11
Категории ролей
Суперпользователи
полный доступ ко всем объектам — проверки не выполняются
Владельцы
изначально все привилегии для объекта (можно отозвать)
действия со своими объектами, не регламентируемые привилегиями,
например: удаление, выдача и отзыв привилегий и т. п.
Остальные роли
доступ в рамках выданных привилегий
В целом можно сказать, что доступ роли к объекту определяется
привилегиями. Но имеет смысл выделить три категории ролей
и рассмотреть их по отдельности:
1. Роли с атрибутом SUPERUSER (суперпользователи). Такие роли
могут делать все, что угодно — для них проверки разграничения
доступа не выполняются.
2. Владелец объекта. Изначально это роль, создавшая объект, хотя
потом его можно сменить. Владельцем считается не только сама
роль-владелец, но и любая другая роль, включенная в нее. Владелец
объекта сразу получает полный набор привилегий для этого объекта.
В принципе, эти привилегии можно отозвать, но владелец объекта
обладает также неотъемлемым правом совершать действия, не
регламентируемые привилегиями. В частности, он может выдавать
и отзывать привилегии (в том числе и себе самому), удалять объект
и т. п.
3. Все остальные роли имеют доступ к объекту только в рамках
выданных им привилегий.
Чтобы проверить, есть ли у роли необходимая привилегия в отношении
некоторого объекта, можно воспользоваться функциями has_*_privilege:
12
Управление привилегиями
Выдача привилегий
alice: GRANT привилегии ON объект TO bob;
Отзыв привилегий
alice: REVOKE привилегии ON объект FROM bob;
alice bob
привилегии
на объект
Право выдачи и отзыва привилегий на объект имеет владелец этого
объекта (и суперпользователь).
Синтаксис команд GRANT и REVOKE достаточно сложен и позволяет
указывать как отдельные, так и все возможные привилегии; как
отдельные объекты, так и группы объектов, входящие в определенные
схемы и т. п.
14
public
Включение роли в роль
Включение в роль
alice: GRANT dba TO bob;
псевдороль public неявно включает
в себя все остальные роли
Исключение из роли
alice: REVOKE dba FROM bob;
alice bob
dba
dba
bob
alice
Любая роль может включать в себя другие роли, то есть выступать
группой. Отдельного понятия «группа» в PostgreSQL нет.
Роль может быть включена в несколько ролей; включенная роль может,
в свою очередь, включать в себя третьи роли, но циклы при этом не
допускаются.
По умолчанию роль наследует привилегии роли, в которую она
включена. Это поведение можно изменить, указав роли атрибут
NOINHERIT — тогда, чтобы воспользоваться привилегиями
включающей роли, надо будет явно переключиться на нее с помощью
SET ROLE. Атрибуты ролей не наследуются, но можно переключиться
на включающую роль и воспользоваться ее атрибутами.
Роли, включающие другие роли, обычно имеют атрибут NOLOGIN и
называются «групповыми». Фактически это именованный набор
привилегий, который удобно «выдать» обычной роли точно так же, как
выдается одиночная привилегия. Это упрощает управление доступом и
администрирование.
Существует псевдороль public, которая неявно включает в себя все
остальные роли. Если выдать какие-либо привилегии роли public, эти
привилегии получат вообще все роли.
15
Предопределенные роли
pg_read_all_settings чтение всех параметров сервера
pg_read_all_stats доступ к статистике
pg_stat_scan_tables мониторинг и блокировки таблиц
pg_read_all_data чтение данных из всех таблиц
pg_write_all_data изменение данных во всех таблицах
pg_read_server_files чтение файлов на сервере
pg_write_server_files запись в файлы на сервере
pg_execute_server_programs выполнение программ на сервере
...
pg_monitor
В PostgreSQL имеется набор предопределенных ролей, имеющих
доступ к часто востребованным, но не общедоступным функциям
и данным. Членство в этих ролях может быть предоставлено обычным
пользователям для решения ряда задач администрирования — чтобы
избежать наделения этих пользователей суперпользовательскими
полномочиями.
Количество предопределенных ролей увеличивается с каждой новой
версией PostgreSQL. Полный список всех ролей, включая
предопределенные, можно просмотреть с помощью команды \duS
в psql.
Можно создавать и свои собственные «административные» роли,
например, для выполнения задач резервного копирования.
17
Подпрограммы
Единственная привилегия для функций и процедур
EXECUTE выполнение
Характеристики безопасности
SECURITY INVOKER выполняется с правами вызывающего
(по умолчанию)
SECURITY DEFINER выполняется с правами владельца
Для функций и процедур есть единственная привилегия EXECUTE,
разрешающая выполнение этой подпрограммы.
Тонкий момент связан с тем, от имени какого пользователя будет
выполняться подпрограмма. Если подпрограмма объявлена как
SECURITY INVOKER (по умолчанию), она выполняется с правами
вызывающего пользователя. В этом случае операторы внутри
подпрограммы смогут обращаться только к тем объектам, к которым
у вызывающего пользователя есть доступ.
Если же указать фразу SECURITY DEFINER, подпрограмма работает
с правами ее владельца. Это способ позволить другим пользователям
выполнять определенные действия над объектами, к которым у них нет
непосредственного доступа.
18
Привилегии по умолчанию
Привилегии псевдороли public
подключение к любой базе данных
доступ к системному каталогу
выполнение любых подпрограмм
привилегии выдаются автоматически для каждого нового объекта
Настраиваемые привилегии по умолчанию
возможность дополнительно выдать или отозвать привилегии
для вновь создаваемого объекта
Как уже говорилось, псевдороль public включает в себя все остальные
роли, которые, таким образом, пользуются всеми привилегиями,
выданными для public.
При этом public имеет довольно широкий спектр привилегий по
умолчанию. В частности:
●
право подключения к любой базе данных (именно поэтому роль alice
смогла подключиться к базе данных несмотря на то, что привилегия
CONNECT не выдавалась ей явно);
●
доступ к системному каталогу;
●
выполнение любых подпрограмм.
Это, с одной стороны, позволяет комфортно работать, не задумываясь
о привилегиях, а с другой — создает определенные сложности, если
разграничение доступа действительно необходимо.
Описанные выше привилегии появляются у public автоматически при
создании новых объектов. То есть недостаточно, например, просто
отозвать у public привилегию EXECUTE на все подпрограммы: как
только появится новая, public немедленно получает привилегию на ее
выполнение.
Однако существует специальный механизм «привилегий по
умолчанию», который позволяет автоматически выдавать и отзывать
привилегии при создании нового объекта. Этот механизм можно
использовать и для отзыва права выполнения функций у псевдороли
public.
20
Итоги
Роли, атрибуты и привилегии — гибкий механизм,
позволяющий по-разному организовать работу
можно легко разрешить все всем
можно строго разграничить доступ, если это необходимо
При создании новых ролей надо позаботиться
о возможности их подключения к серверу
21
Практика
1. Создайте две роли (пароль должен совпадать с именем):
– employee — сотрудник магазина,
– buyer — покупатель.
Убедитесь, что созданные роли могут подключиться к БД.
2. Отзовите у роли public права выполнения всех функций
и подключения к БД.
3. Разграничьте доступ таким образом, чтобы:
– сотрудник мог только заказывать книги, а также
– добавлять авторов и книги,
– покупатель мог только приобретать книги.
Проверьте выполненные настройки в приложении.
1. Сотрудник — внутренний пользователь приложения, аутентификация
выполняется на уровне СУБД.
Покупатель — внешний пользователь. В реальном интернет-магазине
управление такими пользователями ложится на приложение, а все
запросы поступают в СУБД от одной «обобщенной» роли (buyer).
Идентификатор конкретного покупателя может передаваться как
параметр (но в нашем приложении мы этого не делаем).
3. Вообще говоря, разграничение доступа должно быть заложено,
в том числе, в приложение. В нашем учебном приложении
разграничение не сделано специально: вместо этого на веб-странице
можно явно выбрать роль, от имени которой пойдет запрос в СУБД.
Это позволяет посмотреть, как поведет себя серверная часть при
некорректной работе приложения.
Итак, пользователям нужно выдать:
●
Право подключения к БД bookstore и доступ к схеме bookstore.
●
Доступ к представлениям, к которым происходит непосредственное
обращение.
●
Доступ к функциям, которые вызываются как часть API. Если
оставить функции SECURITY INVOKER, придется выдавать доступ
и ко всем «нижележащим» объектам (таблицам, другим функциям).
Однако удобнее просто объявить API-функции как SECURITY
DEFINER.
Разумеется, ролям нужно выдать привилегии только на те объекты,
доступ к которым у них должен быть.
22
Практика
Настройте привилегии таким образом, чтобы одни пользователи
имели полный доступ к таблицам, а другие могли только
запрашивать, но не изменять информацию.
1. Создайте новую базу данных и двух пользователей: writer и reader.
2. Отзовите у роли public все привилегии на схему public, выдайте роли
writer обе привилегии, а роли reader — только usage.
3. Настройте привилегии по умолчанию так, чтобы роль reader получала
доступ на чтение к таблицам, принадлежащим writer в схеме public.
4. Создайте пользователя w1, включив его в роль writer, и пользователя
r1, включив его в reader.
5. Под ролью writer создайте таблицу.
6. Убедитесь, что r1 имеет доступ к таблице только на чтение, а w1
имеет к ней полный доступ, включая удаление.
