Администратор инфраструктуры root вносит в pg_hba.conf строки, разрешающие соединения для суперпользователя с локальной консоли:

TYPE    DATABASE    USER      ADDRESS       METHOD
local   all         postgres                peer
host    all         postgres  127.0.0.1/32  reject
host    all         postgres  ::1/128       reject

Чтобы новые ограничения вступили в силу требуется перезапуск сервера СУБД:

# pg_ctl restart

Процедура создания выделенного владельца (менеджера) зоны повышенной безопасности DV_OWNER и администратора безопасности (менеджера прав доступа) DV_SEC_OFFICER требует привлечения суперпользователя. Это вызвано тем, что, в случае создания учётных записей этих пользователей от имени администратора СУБД или администратора БД, у этих администраторов останется право ADMIN OPTION, от которого они даже не могут отказаться.

Чтобы исключить риски, связанные как с доверием к администраторам, у которых сохранилась бы возможность управлять DV_OWNER и DV_SEC_OFFICER, так и на случай доступа к их учётными записям злоумышленника, операция выполняется от имени суперпользователя.

В целях демонстрации в данном примере предполагается, что зона повышенной безопасности будет создаваться в базе данных DB1.

$ psql postgres
CREATE USER DV_OWNER WITH LOGIN; -- Не забудьте установить первичный пароль
CREATE USER DV_SEC_OFFICER WITH LOGIN; -- Не забудьте установить первичный пароль
GRANT CONNECT ON DATABASE db1 TO DV_SEC_OFFICER;
GRANT CONNECT ON DATABASE db1 TO DV_OWNER;
EXIT;

Создание зоны повышенной безопасности является крайне важным шагом и возможно только с участием суперпользователя, которому временно разрешён вход в базу.

Чтобы создать объект, владельцем которого будет другая роль, или назначить другой роли права владения уже существующим объектом, необходимо иметь право SET ROLE для этой роли. В противном случае команды ALTER ... OWNER TO или CREATE DATABASE ... OWNER выдадут ошибку, как описано в GRANT.

В силу независимости DV_OWNER доступ к этой роли через SET ROLE со стороны администратора СУБД или администратора БД предоставляться не должен, поэтому не рекомендуется выдавать им права владения SQL-объектами. Поэтому наилучшим вариантом является создание зоны повышенной безопасности от имени суперпользователя.

Обратите внимание на изменённый синтаксис команды ALTER SCHEMA. Предложения SECURITY OFFICER и RESET SECURITY OFFICER соответственно задают или удаляют администратора безопасности схемы. Когда задаётся администратор безопасности, схема становится схемой vault, как описано в ALTER SCHEMA.

$ psql db1 -U postgres
CREATE SCHEMA vault;
GRANT ALL ON SCHEMA vault TO DV_OWNER;
GRANT USAGE ON SCHEMA vault to DV_SEC_OFFICER;
ALTER SCHEMA vault OWNER TO DV_OWNER;
ALTER SCHEMA vault SECURITY OFFICER TO DV_SEC_OFFICER;
EXIT;

Пользователи с доступом к зоне повышенной безопасности должны быть надёжно защищены. У администратора СУБД или администраторов БД не должно быть права ADMIN OPTION в отношении этих пользователей, иначе у администраторов может возникнуть возможность получить несанкционированный доступ к данным зоны повышенной безопасности.

Для исключения данной уязвимости требуется лишить других пользователей права ADMIN OPTION на пользователей зоны повышенной безопасности при помощи команды REVOKE ADMIN OPTION. Рассмотрим это на примере пользователя vault_user, которого создадим ролью PGPRO_DB_1_ADMIN:

$ psql db1 -U db1_admin
CREATE USER vault_user; -- Не забудьте установить пароли
GRANT CONNECT ON DATABASE db1 TO vault_user;
EXIT;

Сначала необходимо проверить, кто имеет право ADMIN OPTION на пользователя vault_user:

$ psql db1 -U postgres
SELECT rn.rolname "role", mn.rolname member, gn.rolname grantor, am.admin_option
FROM pg_auth_members am
JOIN pg_roles rn ON rn.oid = am.roleid
JOIN pg_roles mn ON mn.oid = am.member
JOIN pg_roles gn ON gn.oid = am.grantor
WHERE rn.rolname = 'vault_user' AND am.admin_option = true
ORDER BY member;

В данном примере такие права есть у роли db1_admin:

    role    |      member      |     grantor      | admin_option
------------+------------------+------------------+--------------
 vault_user | db1_admin        | postgres         | t
(1 row)

Теперь суперпользователь postgres отзовёт у роли db1_admin такие права:

$ psql db1 -U postgres
REVOKE ADMIN OPTION FOR vault_user FROM db1_admin CASCADE;

После чего необходимо ещё раз убедиться, что не осталось лишних пользователей с правом ADMIN OPTION на пользователя vault_user:

$ psql db1 -U postgres
SELECT rn.rolname "role", mn.rolname member, gn.rolname grantor, am.admin_option
FROM pg_auth_members am
JOIN pg_roles rn ON rn.oid = am.roleid
JOIN pg_roles mn ON mn.oid = am.member
JOIN pg_roles gn ON gn.oid = am.grantor
WHERE rn.rolname = 'vault_user' AND am.admin_option = true
ORDER BY member;

    role    |      member      |     grantor      | admin_option
------------+------------------+------------------+--------------
(0 rows)

Чтобы запретить соединение для суперпользователя, администратор инфраструктуры вносит в pg_hba.conf следующие строки:

TYPE     DATABASE  USER       ADDRESS       METHOD
local    all       postgres                 reject
host     all       postgres   127.0.0.1/32  reject
host     all       postgres   ::1/128       reject

Чтобы новые ограничения вступили в силу, требуется перезапуск сервера СУБД:

# pg_ctl restart