Управление доступом
Политики защиты строк
13
Авторские права
© Postgres Professional, 2015‒2022
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Что такое политики защиты строк
Условия применения политик
Несколько политик на одной таблице
3
Политика защиты строк
Определяет видимость и изменяемость строк таблицы
предикат вычисляется для каждой строки с правами вызывающего
клиенту доступны только те строки, для которых предикат истинен
Предикат для существующих строк (USING)
используется операторами SELECT, UPDATE, DELETE
при нарушении политики не возникает ошибка
(если только не сброшен параметр row_security)
Предикат для новых строк (WITH CHECK)
используется операторами INSERT, UPDATE
если не задан, используется первый предикат
при нарушении политики возникает ошибка
Политики защиты строк (row-level security, RLS) позволяют управлять
доступом к таблице на уровне отдельных строк. Другое название этого
инструмента — Fine Grained Access Control.
Политики являются дополнительным механизмом: роль по-прежнему
должна иметь доступ к таблице, предоставленный привилегиями.
Политика определяет возможность выборки или изменения строк
таблицы с помощью двух предикатов (логических выражений), которые
вычисляются для каждой строки запроса. Результаты говорят о том,
может ли пользователь видеть или менять строку.
Первый предикат вычисляется для существующих строк и
используется операторами SELECT, UPDATE, DELETE. Если для какой-
то строки предикат не принимает истинное значение (то есть дает ложь
или NULL), строка не попадает в итоговую выборку. Упрощенно можно
считать, что предикат просто «дописывается» к условию WHERE —
хотя на самом деле все значительно сложнее.
Если установлено row_security = off, при ложном значении предиката
хотя бы для одной строки будет зафиксирована ошибка. Это полезно
при изготовлении логической резервной копии, чтобы гарантировать,
что в нее попали все строки всех таблиц.
Второй предикат определяет видимость новых строк. Он проверяется
командами INSERT и UPDATE; при нарушении политики возникает
ошибка.
4
Условия применения
Политика применяется
к таблице, для которой включена защита
для указанных ролей и для указанных операторов
(SELECT, INSERT, UPDATE, DELETE)
Политика не применяется
при проверке ограничений целостности
для суперпользователей и ролей с атрибутом BYPASSRLS
для владельца (если не включить принудительно)
Чтобы политики защиты строк начали работать, нужно явно включить
этот механизм для каждой таблицы.
При создании политики можно также задать, для каких ролей она будет
работать (по умолчанию — для всех) и для каких операторов
(по умолчанию — также для всех).
Политики не применяются при проверке ограничений целостности —
независимо от настроенных политик СУБД гарантирует целостность
данных.
Политики не применяются для суперпользователей (для них, как
обычно, никакие проверки безопасности не выполняются) и для ролей
с атрибутом BYPASSRLS.
Для владельца таблицы политики не работают по умолчанию, но
специальной командой можно включить защиту и для владельца.
6
Несколько политик
Разрешительные политики
видимость должна предоставить хотя бы одна разрешительная политика
если не определена ни одна политика, строка не видима
Ограничительные политики
видимость должны предоставить все ограничительные политики,
если они определены
На одной таблице можно определить несколько политик. В этом случае
будут учитываться все предикаты.
По умолчанию создаются разрешительные (permissive) политики.
Чтобы строка была доступна, достаточно, чтобы хотя бы один из
предикатов этих политик был истинен.
Но если на таблице включена защита строк, и при этом не определено
ни одной разрешительной политики, не будет доступна ни одна строка.
Дополнительно можно создать и ограничительные (restricted)
политики. Если они заданы, то все их предикаты должны быть истинны.
Иными словами, если определены только разрешительные политики
с предикатами P
1
,...,P
N
, то для каждой строки вычисляется выражение
P
1
OR … OR P
N
.
А если к тому же определены ограничительные политики с предикатами
R
1
,…, R
M
, то для каждой строки будет вычисляться выражение
(P
1
OR … OR P
N
) AND R
1
AND … AND R
M
.
То есть доступ должны предоставить хотя бы одна разрешительная и
все ограничительные политики.
8
Итоги
Привилегии управляют доступом к таблицам и столбцам,
политики защиты строк — к строкам
Политики настраиваются проще и работают эффективнее,
чем реализация с помощью представлений и триггеров
9
Практика
1. Продолжая пример из демонстрации, создайте роль для
Чарли и назначьте ему два отдела в таблице пользователей.
2. Определите политики защиты строк таким образом, чтобы:
- роли видели строки только тех отделов, с которыми связаны;
- роли, связанные с одним отделом, могли добавлять строки с суммой
- в пределах 100 рублей;
- роли, связанные с несколькими отделами, могли добавлять строки
- с любой суммой.
3. Проверьте корректность настроенных политик.
4. Оцените накладные расходы на политики защиты строк,
выполнив один и тот же запрос от имени обычной
и суперпользовательской ролей.
