Безопасность
Защищенная схема
16
Авторские права
© Postgres Professional, 2023–2026
Авторы: Алексей Береснев, Илья Баштанов, Павел Толмачев, Игорь
Гнатюк
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
edu@postgrespro.ru
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Разделение ролей
Создание защищенной схемы
Предоставление доступа к защищаемым данным
Логическая копия защищенной схемы и ее восстановление
3
Разделение ролей
Администратор ОС
управление подключением суперпользователя
Суперпользователь
создание административных ролей
решение особых задач
Административные роли
управление СУБД
обеспечение работы пользователей
Пользователи
работа с объектами
При развертывании СУБД и на начальных этапах работы с ней активно
используется роль суперпользователя. Однако ее использование для
выполнения различных рутинных операций по обслуживанию системы в
дальнейшем является небезопасным.
Работая под учетной записью суперпользователя, можно создать
дополнительные административные роли и делегировать им большую
часть решаемых задач по обслуживанию СУБД и обеспечению работы
обычных пользователей, после чего отказаться от активного
использования роли суперпользователя.
Для этого администратор ОС может вообще запретить подключение
к серверу под учетной записью суперпользователя с помощью правил
в файле pg_hba.conf.
При этом в ряде случаев — при выполнении редких и сложных задач,
требующих суперпользовательского доступа — администратор ОС
может остановить и временно безопасно запустить СУБД в
однопользовательском (технологическом) режиме.
4
Защищенная схема
Зона повышенной безопасности на основе схемы
инициализируется суперпользователем
закрыт доступ для административных ролей
Администратор безопасности
выдает разрешения на доступ к объектам схемы
не может работать с объектами схемы
Владелец схемы
может работать с объектами
не может управлять доступом к объектам
Данные хранятся в таблицах, которые находятся в схемах баз данных.
По умолчанию административные роли имеют доступ к этим данным,
что может быть нежелательным. Для защиты чувствительных данных
Postgres Pro Enterprise позволяет поместить их в специально созданную
защищенную схему и определить правила доступа к ней.
У защищенной схемы есть владелец и выделенный администратор
безопасности. Администратор безопасности (менеджер прав доступа)
может лишь выдавать разрешения пользователям на доступ к объектам
схемы, но сам работать с объектами не может. Владелец схемы,
наоборот, может работать с объектами, но не может управлять правами
доступа к ним.
Предпочтительным является сценарий, когда владельца и
администратора безопасности создает суперпользователь. Для этого
администратор ОС временно разрешает вход для суперпользователя.
5
Роли
Суперпользователь
создает роли
Администратор ОС
запрещает доступ суперпользователя
db_admin
административная роль
v_owner
владелец защищаемых данных
v_admin
администратор безопасности
v_user
пользователь защищаемых данных
postgres
суперпользователь
Организацию схемы для размещения защищенных данных начнем
с создания ролей суперпользователем.
Роль db_admin будет служить для таких административных задач, как
создание баз данных.
Далее нам потребуются роли для владельца защищенной схемы
(v_owner) и для администратора безопасности этой схемы (v_admin).
Если эти роли были созданы некоторой административной ролью (не
суперпользователем), то у них будет право ADMIN OPTION, от которого
они сами отказаться не смогут. Чтобы исключить риски, связанные с
доверием к указанным ролям, суперпользователю следует это право
отозвать.
Наконец, роль v_user предназначена для обычного пользователя,
который должен обращаться к защищенным данным.
После создания ролей администратор ОС может запретить
суперпользовательское подключение к экземпляру СУБД.
7
База данных
v_owner
v_admin
db_admin
v_user
Суперпользователь
создает роли
Администратор ОС
запрещает доступ суперпользователя
Административная роль
создает базу
v_db
postgres
На следующем шаге административная роль создает базу данных.
8
Схема
Суперпользователь
создает роли
Администратор ОС
запрещает доступ суперпользователя
Административная роль
создает базу
Суперпользователь (временный доступ)
создает схему
назначает администратора безопасности
назначает владельца
v_owner
v_admin
db_admin
v_user
v_db
v_schema
postgres
Теперь уже можно создать зону повышенной безопасности —
защищенную схему. Мы будем показывать одну, но, конечно, таких схем
может быть несколько, и они могут принадлежать разным владельцам.
Команда ALTER SCHEMA … SECURITY OFFICER TO … устанавливает
для схемы атрибут — роль администратора безопасности. После
этого только указанная роль может управлять доступом к схеме и
объектам в ней — схема становится защищенной.
Атрибут можно сбросить командой ALTER SCHEMA … RESET
SECURITY OFFICER. Тогда схема снова станет незащищенной.
Эти действия выполняет суперпользователь, для чего администратор
ОС должен обеспечить ему временное подключение к экземпляру.
После назначения администратора безопасности можно передать
владение схемой выделенной роли, не являющейся
суперпользователем.
При организации зоны повышенной безопасности можно использовать
более простой подход: схему создает ее владелец, а
суперпользователь только назначает администратора безопасности.
Однако при этом появляется риск передачи привилегий на схему
другим ролям до того, как схема станет защищенной.
10
Защищаемые данные
Владелец схемы
размещает данные в схеме
v_owner
v_admin
db_admin
v_user
v_db
v_schema
v_tbl
postgres
Если между созданием схемы и преобразованием ее в защищенную
могли быть выполнены какие-либо команды, перед размещением
данных в ней нужно убедиться, что к схеме нет доступа у других ролей,
кроме владельца схемы и администратора безопасности.
Разместить данные в защищенной схеме можно двумя способами:
1. Владелец защищенной схемы может создать объект
непосредственно в этой схеме и затем наполнить его данными.
2. Можно перенести в защищенную схему уже существующий объект.
В этом случае нужно передать его владельцу этой схемы. Однако это
возможно, только если владелец объекта входит в роль владельца
схемы с параметром членства SET. Владелец же защищенной схемы
является независимым — у других административных ролей нет
с ним общей роли. Поэтому здесь снова потребуется действие от
имени суперпользователя.
11
Доступ к данным
Владелец схемы
размещает данные в схеме
Администратор безопасности
выдает разрешения пользователям
v_owner
v_admin
db_admin
v_user
v_db
v_schema
v_tbl
postgres
Далее разрешения на доступ к объектам защищенной схемы
пользователю выдает администратор безопасности.
Пользователи с доступом к зоне повышенной безопасности должны
быть защищены. У административных ролей не должно быть
параметра членства ADMIN в отношении этих пользователей. Если это
не так, параметр следует явно отключить.
13
Логическая копия
v_db
v_schema
права
доступа
Администратор
выгружает базу и все схемы, кроме защищенной
объект
объект
объект
схема
схема
схема
Логическая резервная копия базы с зоной повышенной безопасности
создается в несколько этапов без участия суперпользователя.
Сначала с помощью pg_dump администратор базы выгружает все
данные, кроме данных защищенной схемы. Для этого используется
параметр командной строки утилиты --exclude-schema.
14
Логическая копия
Администратор
выгружает базу и все схемы, кроме защищенной
Владелец схемы
выгружает данные защищенной схемы
v_db
v_schema
права
доступа
объект
объект
объект
схема
схема
схема
Затем владелец защищенной схемы выгружает данные зоны
повышенной безопасности, используя параметры --schema и --no-
privileges.
15
Логическая копия
Администратор
выгружает базу и все схемы, кроме защищенной
Владелец схемы
выгружает данные защищенной схемы
выгружает права на объекты защищенной схемы
v_db
v_schema
права
доступа
объект
объект
объект
схема
схема
схема
Далее владелец защищенной схемы выгружает права доступа
к объектам этой схемы. Для этого используются параметры --schema
и --privileges-only.
17
Восстановление
Администратор
восстанавливает базу и схемы, кроме защищенной
v_db
схема
схема
схема
Восстановление также выполняется в несколько этапов.
Сначала администратор СУБД восстанавливает базу со всеми
данными, кроме данных защищенной схемы.
18
Восстановление
Администратор
восстанавливает базу и схемы, кроме защищенной
Суперпользователь
создает защищенную схему
v_db
v_schema
схема
схема
схема
На следующем этапе потребуется участие суперпользователя: он
создает в новой базе схему и назначает для нее администратора
безопасности, что делает схему защищенной. После этого
суперпользователь назначает владельца защищенной схемы.
19
Восстановление
Администратор
восстанавливает базу и схемы, кроме защищенной
Суперпользователь
создает защищенную схему
Владелец схемы
восстанавливает данные защищенной схемы
v_db
v_schema
объект
объект
объект
схема
схема
схема
Далее владелец защищенной схемы восстанавливает объекты и
данные этой схемы.
20
Восстановление
Администратор
восстанавливает базу и схемы, кроме защищенной
Суперпользователь
создает защищенную схему
Владелец схемы
восстанавливает данные защищенной схемы
Администратор безопасности
восстанавливает права на объекты
защищенной схемы
v_db
v_schema
права
доступа
объект
объект
объект
схема
схема
схема
На завершающем этапе администратор безопасности восстанавливает
права доступа к объектам защищенной схемы.
Приведенный сценарий восстановления не является единственно
возможным. В зависимости от задачи можно изменить порядок
действий и состав вовлеченных административных ролей. Но в любом
случае необходимо участие суперпользователя, как минимум для
назначения администратора безопасности схемы.
Снова отметим, что назначение администратора безопасности
желательно выполнять раньше, чем назначение владельца схемы.
22
Итоги
Безопасная работа с данными подразумевает разделение
полномочий, в том числе административных
Защищенная схема снижает риски, которые не устраняются
стандартными возможностями PostgreSQL
При настройке защищенной схемы нужно строго соблюдать
порядок действий, чтобы исключить несанкционированный
доступ к данным
23
Практика
1. Исследуйте ситуацию, когда административная роль,
создавшая пользователя защищенных данных, сохраняет
членство в ней с параметром ADMIN. Устраните найденную
уязвимость.
2. Реализуйте сценарий переноса данных, созданных
пользователем, не имеющим доступа к защищенной схеме,
в уже существующую защищенную схему. Проверьте, что
после перемещения данных бывший владелец не будет иметь
к ним доступа.
3. Выключите защиту схемы. Убедитесь, что разделение ролей
для управления данными и доступа к ним у незащищенных
схем отсутствует.
1. Параметр членства ADMIN дает возможность включения в роль
других ролей с правом наследования доступа к объектам.
2. Перенесите таблицу, созданную в схеме public административной
ролью, не имеющей доступа к защищенной схеме.
