Разграничение доступа
Обзор разграничения доступа
12
Авторские права
© Postgres Professional, 2017–2020
Авторы: Егор Рогов, Павел Лузанов
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Роли и атрибуты
Подключение к серверу
Привилегии
Политики защиты строк
3
Роли и атрибуты
Роль — пользователь СУБД
роль не связана с пользователем ОС
Свойства роли определяются атрибутами
LOGIN возможность подключения
SUPERUSER суперпользователь
CREATEDB возможность создавать базы данных
CREATEROLE возможность создавать роли
REPLICATION использование протокола репликации
и другие
Роль — это пользователь СУБД. (Роль также может выступать
в качестве группы пользователей, но об этом будет сказано позже.)
Формально роли никак не связаны с пользователями операционной
системы, хотя многие программы это предполагают, выбирая значения
по умолчанию. Например, psql, запущенный от имени пользователя ОС
student, автоматически использует одноименную роль student (если
в ключах утилиты не указана какая-либо другая роль).
При создании кластера определяется одна начальная роль, имеющая
суперпользовательский доступ (обычно она называется postgres).
В дальнейшем роли можно создавать, изменять и удалять.
Роль обладает некоторыми атрибутами, определяющими ее общие
особенности и права (не связанные с правами доступа к объектам).
Обычно атрибуты имеют два варианта, например, CREATEDB (дает
право на создание БД) и NOCREATEDB (не дает такого права). Как
правило, по умолчанию выбирается ограничивающий вариант.
Если у роли нет атрибута LOGIN, она не сможет подключиться
к серверу. (Такие роли тоже имеют смысл в качестве групповых.)
В таблице перечислены лишь некоторые из атрибутов. Атрибуты
INHERIT и BYPASSRLS рассматривается чуть дальше в этой теме.
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 md5
host all all ::1/128 md5
local — сокет all — любая роль
host — TCP/IP имя роли
all — любая БД all — любой IP
имя БД IP/маска
доменное имя
listen_addresses
Для каждого нового клиента сервер определяет, надо ли разрешить
подключение к базе данных. Настройки подключения определяются
в конфигурационном файле pg_hba.conf («host-based authentication»).
Как и с основным конфигурационным файлом postgresql.conf,
изменения вступают в силу только после перечитывания файла
сервером (SELECT pg_reload_conf() в SQL, либо pg_ctl reload из
операционной системы).
При появлении нового клиента сервер просматривает конфигурацион-
ный файл сверху вниз в поисках строки, подходящей к запрашиваемо-
му клиентом подключению. Соответствие определяется по четырем
полям: типу подключения, имени БД, имени пользователя и IP-адресу.
Ниже перечислены только самые основные возможности.
Подключение — local (unix-сокеты, не доступно в Windows) или 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 md5
host all all ::1/128 md5
trust — верить
reject — отказать
scram-sha-256 и md5 — запросить пароль
peer — спросить ОС
Когда в файле найдена подходящая строка, выполняется аутентифика-
ция указанным в этой строке методом, а также проверяется наличие
атрибута LOGIN и привилегии CONNECT. Если результат проверки
успешен, то подключение разрешается, иначе — запрещается (другие
строки при этом уже не рассматриваются).
Если ни одна из строк не подошла, то доступ также запрещается.
Таким образом, записи в файле должны идти сверху вниз от частного
к общему.
Существует множество методов аутентификации:
Ниже перечислены только самые основные.
Метод trust безусловно разрешает подключение. Если вопросы
безопасности не важны, можно указать «все all» и метод trust — тогда
будут разрешены все подключения.
Метод reject наоборот, безусловно запрещает подключение.
Наиболее распространены методы md5 и более надежный scram-sha-
256, которые запрашивают у пользователя пароль и проверяют его
соответствие паролю, который хранится в системном каталоге
кластера.
Метод peer запрашивает имя пользователя у операционной системы и
разрешает подключение, если имя пользователя ОС и пользователя БД
совпадают (можно установить и другие соответствия имен).
7
Парольная аутентификация
На сервере
пароль устанавливается при создании роли или позже
пользователю без пароля будет отказано в доступе
пароль хранится в системном каталоге pg_authid
Ввод пароля на клиенте
вручную
из переменной окружения PGPASSWORD
из файла ~/.pgpass (строки в формате узел:порт:база:роль:пароль)
Если используется аутентификация по паролю, для роли должен быть
указан эталонный пароль, иначе в доступе будет отказано.
Пароль хранится в системном каталоге в таблице pg_authid.
Пользователь может вводить пароль вручную, а может
автоматизировать ввод. Для этого есть две возможности.
Во-первых, можно задать пароль в переменной окружения
PGPASSWORD на клиенте. Однако это неудобно, если приходится
подключаться к нескольким базам, и не рекомендуется из соображений
безопасности.
Во-вторых, можно задать пароли в файле ~/.pgpass на клиенте.
К файлу должен иметь доступ только владелец, иначе PostgreSQL
проигнорирует его.
9
Привилегии
Привилегии определяют права доступа ролей к объектам
Таблицы
SELECT чтение данных
INSERT вставка строк
UPDATE изменение строк
REFERENCES внешний ключ
DELETE удаление строк
TRUNCATE опустошение таблицы
TRIGGER создание триггеров
Представления
SELECT чтение данных
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: GRANT привилегии ON объект TO роль2;
Отзыв привилегий
роль1: REVOKE привилегии ON объект FROM роль2;
роль1 роль2
привилегии
на объект
Право выдачи и отзыва привилегий на объект имеет владелец этого
объекта (и суперпользователь).
Синтаксис команд GRANT и REVOKE достаточно сложен и позволяет
указывать как отдельные, так и все возможные привилегии; как
отдельные объекты, так и группы объектов, входящие в определенные
схемы и т. п.
12
public
Групповые роли
Включение роли в группу
роль1: GRANT группа TO роль2;
псевдороль public неявно включает
в себя все остальные роли
Исключение роли из группы
роль1: REVOKE группа FROM роль2;
роль1 роль2
группа
группа
роль2
роль1
Любая роль может рассматриваться не только как пользователь СУБД,
но и может включать в себя другие роли, т. е. выступать группой. Роль
может быть включена в другую роль подобно тому, как пользователь
Unix может быть включен в группу.
Возможно в том числе включение групповых ролей в другие групповые
роли (но циклы не допускаются). Вообще, PostgreSQL не делает
никакого различия между «обычными» и «групповыми» ролями.
Смысл включения состоит в том, что для роли становятся доступны
привилегии, которыми обладает групповая роль.
Возможно, удобнее думать о групповой роли как о заранее
сформированном наборе привилегий, который можно «выдать»
обычной роли точно так же, как выдается одиночная привилегия. Это
упрощает администрирование и управление доступом.
Существует псевдороль public, которая неявно включает в себя все
остальные роли. Если выдать какие-либо привилегии роли public, эти
привилегии получат вообще все роли.
Правом на включение и исключение других ролей в данную роль
обладают:
- сама эта роль,
- роль с атрибутом SUPERUSER (суперпользователь)
- роль с атрибутом CREATEROLE.
13
Суперпользователи
Кто входит в категорию
роли с атрибутом SUPERUSER
Права
полный доступ ко всем объектам — проверки не выполняются
В целом можно сказать, что доступ роли к объекту определяется
привилегиями. Но имеет смысл выделить три категории ролей и
рассмотреть их по отдельности.
Проще всего с ролями с атрибутом суперпользователя. Такие роли
могут делать все, что угодно — для них проверки разграничения
доступа не выполняются.
14
Владелец объекта
Кто входит в категорию
изначально — роль, создавшая объект (можно сменить)
а также роли, включенные в роль владельца
Права
изначально все привилегии для объекта (можно отозвать)
действия со своими объектами, не регламентируемые привилегиями,
например: удаление, выдача и отзыв привилегий и т. п.
У каждого объекта есть роль, владеющая этим объектом («владелец»).
Изначально это роль, создавшая объект, хотя потом владельца можно
сменить. Неочевидный момент: владельцем считается не только сама
роль-владелец, но и любая другая роль, включенная в нее.
Владелец объекта сразу получает полный набор привилегий для этого
объекта.
В принципе, эти привилегии можно отозвать, но владелец объекта
обладает также неотъемлемым правом совершать действия, не
регламентируемые привилегиями. В частности, он может выдавать и
отзывать привилегии (в том числе и себе самому), удалять объект
и т. п.
15
Остальные роли
Кто входит в категорию
все остальные (не суперпользователи и не владельцы)
Права
доступ в рамках выданных привилегий
обычно наследуют привилегии групповых ролей
(но атрибут NOINHERIT требует явного переключения роли)
Наконец, все остальные роли имеют доступ к объекту только в рамках
выданных им привилегий. В том числе учитываются и привилегии
групповых ролей, в которые эти роли входят (включая псевдороль
public, в которую неявно включены все остальные роли).
Обычно роль сразу обладает всеми «групповыми» полномочиями. Это
поведение можно изменить, указав роли атрибут NOINHERIT — тогда,
чтобы воспользоваться привилегиями групповых ролей, надо будет
явно переключиться с помощью SET ROLE.
Чтобы проверить, есть ли у роли необходимая привилегия в отношении
некоторого объекта, можно воспользоваться функциями has_*_privilege:
Выданные привилегии удобно показывают команды psql, описывающие
объект (см. раздаточный материал по системному каталогу).
17
Подпрограммы
Единственная привилегия для функций и процедур
EXECUTE выполнение
Характеристики безопасности
SECURITY INVOKER выполняется с правами вызывающего
(по умолчанию)
SECURITY DEFINER выполняется с правами владельца
Для функций и процедур есть единственная привилегия EXECUTE,
разрешающая выполнение этой подпрограммы.
Тонкий момент связан с тем, от имени какого пользователя будет
выполняться подпрограмма. Если подпрограмма объявлена как
SECURITY INVOKER (по умолчанию), она выполняется с правами
вызывающего пользователя. В этом случае операторы внутри
подпрограммы смогут обращаться только к тем объектам, к которым
у вызывающего пользователя есть доступ.
Если же указать фразу SECURITY DEFINER, подпрограмма работает
с правами создавшего ее пользователя. Это способ позволить другим
пользователям выполнять определенные действия над объектами,
к которым у них нет непосредственного доступа.