32.4. Ограничение доступа администратора СУБД к данным #
- 32.4.1. Обзор
- 32.4.2. Создание администраторов и менеджеров зоны повышенной безопасности
- 32.4.3. Создание таблицы в зоне повышенной безопасности
- 32.4.4. Перенос таблицы в зону повышенной безопасности
- 32.4.5. Разрешение доступа к защищённой таблице
- 32.4.6. Проверка доступа: наполнение защищённой таблицы данными
- 32.4.7. Изменения в программе создания резервных копий
- 32.4.8. Изменения в программе проверки целостности
- 32.4.2. Создание администраторов и менеджеров зоны повышенной безопасности
На основе технологии разграничения прав между привилегированными пользователями СУБД был создан механизм, запрещающий администраторам СУБД и БД доступ к данным, включая просмотр, при сохранении возможности заниматься администрированием, таким как резервное копирование и восстановление, диагностика, настройка БД, создание и удаление БД.
32.4.1. Обзор #
Конфиденциальная информация хранится в таблицах, которые, в свою очередь, находятся в схемах БД. По умолчанию администратор СУБД и администраторы всех соответствующих БД имеют к ней доступ, что может привести к несанкционированному доступу. Для защиты данных Postgres Pro Enterprise необходимо зарегистрировать зону повышенной безопасности, что удобно сделать на уровне схемы, и определить правила доступа к ней.
Такая схема описана в Подразделе 5.9.3. Она имеет выделенного владельца и администратора безопасности. Это должны быть разные пользователи БД:
Администратор безопасности, или менеджер прав доступа, сможет только выдавать разрешения пользователям на доступ к объектам зоны, но работа с объектами будет для него недоступна: он не сможет их создавать, просматривать или изменять.
Владелец зоны сможет работать с объектами зоны.
Владельца и администратора безопасности зоны повышенной безопасности создаёт суперпользователь. Для целей их создания и назначения привилегий доверенный администратор инфраструктуры временно и подконтрольно разрешает вход для суперпользователя, переведя СУБД в технологический режим.
32.4.2. Создание администраторов и менеджеров зоны повышенной безопасности #
32.4.2.1. Временное открытие для суперпользователя postgres
входа в базу с локальной консоли #
Администратор инфраструктуры 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
32.4.2.2. Создание управляющих зоны повышенной безопасности #
Процедура создания выделенного владельца (менеджера) зоны повышенной безопасности 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;
32.4.2.3. Создание зоны повышенной безопасности #
Создание зоны повышенной безопасности является крайне важным шагом и возможно только с участием суперпользователя, которому временно разрешён вход в базу.
Чтобы создать объект, владельцем которого будет другая роль, или назначить другой роли права владения уже существующим объектом, необходимо иметь право 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;
32.4.2.4. Защита пользователей зоны повышенной безопасности от администраторов #
Пользователи с доступом к зоне повышенной безопасности должны быть надёжно защищены. У администратора СУБД или администраторов БД не должно быть права 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)
32.4.2.5. Закрытие доступа к зоне повышенной безопасности для суперпользователя #
Чтобы запретить соединение для суперпользователя, администратор инфраструктуры вносит в 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
32.4.3. Создание таблицы в зоне повышенной безопасности #
Поскольку только менеджер (владелец) зоны может работать с её объектами, таблицы создаётся от имени DV_OWNER
:
$ psql db1 -U dv_owner CREATE TABLE vault.vault_table (user_name TEXT, balance DECIMAL(10,2)); EXIT;
32.4.4. Перенос таблицы в зону повышенной безопасности #
Предположим, что администратор БД создал таблицу, которую позже было решено перенести в зону повышенной безопасности:
$ psql db1 -U db1_admin CREATE TABLE working_table(id INT, info TEXT);
Этот пользователь может также наполнить таблицу данными:
INSERT INTO working_table(id, info) VALUES (1, 'Number One');
В дальнейшем может понадобиться передать владение этой таблицей к DV_OWNER
, чтобы он перенёс её в зону повышенной безопасности. В PostgreSQL существует требование-ограничение: пользователь может передать владение своей таблицей другому пользователю, только если у него с этим пользователем есть общая роль:
ALTER TABLE working_table OWNER TO DV_OWNER; ERROR: must be able to SET ROLE "DV_OWNER"
Поэтому передачу прав владения и перемещение таблицы в зону повышенной безопасности должен проводить суперпользователь postgres
. Для этого необходимо временно разрешить ему доступ в СУБД:
$ psql db1 -U postgres ALTER TABLE working_table OWNER TO DV_OWNER;
После выполнения этой команды доступ суперпользователю postgres
в СУБД необходимо снова закрыть.
Теперь DV_OWNER
может переместить таблицу в зоны повышенной безопасности:
$ psql db1 -U dv_owner ALTER TABLE working_table SET SCHEMA vault;
32.4.5. Разрешение доступа к защищённой таблице #
Поскольку только администратор безопасности (менеджер прав доступа) зоны может выдавать разрешения пользователям на работу с объектами зоны, управление привилегиями осуществляется от имени DV_SEC_OFFICER
. Данные будут доступны только явно указанным пользователям. Все прочие не будут иметь к ним доступа, включая администратора СУБД и администратора БД. Соответствующие команды GRANT
должны выглядеть так:
$ psql db1 -U dv_sec_officer GRANT USAGE ON SCHEMA vault TO vault_user; GRANT INSERT,UPDATE,DELETE,SELECT,TRUNCATE ON vault.vault_table TO vault_user; GRANT INSERT,UPDATE,DELETE,SELECT,TRUNCATE ON vault.working_table TO vault_user; EXIT;
32.4.6. Проверка доступа: наполнение защищённой таблицы данными #
Подключившись к БД db1
от имени пользователя, которому предоставлен доступ к зоне повышенной безопасности, можно убедиться, что его прав для доступа к данным в этой зоне достаточно:
$ psql db1 -U vault_user INSERT INTO vault.vault_table( user_name, balance) VALUES( 'Ann', 200); INSERT INTO vault.vault_table( user_name, balance) VALUES( 'Bob', 3000); SELECT * FROM vault.vault_table; SELECT * FROM vault.working_table; EXIT;
32.4.7. Изменения в программе создания резервных копий #
При восстановлении зоны повышенной безопасности понадобятся два разных администратора, поскольку один из них не сможет восстановить права доступа, а другой — объекты зоны. Поэтому в программе для создания резервных копий базы данных pg_dump предусмотрена раздельная выгрузка структуры и данных, а также прав доступа зоны повышенной безопасности. Для этого следует воспользоваться специальными ключами --no-privileges
и --privileges-only
.
Выгрузка данных с помощью pg_dump выполняется в следующем порядке:
Администратор БД выгружает все данные, кроме данных зоны повышенной безопасности, используя параметр
--exclude-schema
.DV_OWNER
выгружает данные зоны повышенной безопасности, используя параметры--schema
и--no-privileges
.DV_OWNER
выгружает права доступа, используя параметры--schema
и--privileges-only
.
Загружать данные с помощью pg_restore необходимо в следующем порядке:
Администратор БД восстанавливает все данные, кроме данных зоны повышенной безопасности.
DV_OWNER
восстанавливает данные зоны повышенной безопасности.DV_SEC_OFFICER
восстанавливает права доступа в зону повышенной безопасности.
32.4.8. Изменения в программе проверки целостности #
В утилиту для проверки целостности pg_integrity_check внесены следующие изменения:
С помощью ключа
-C
можно выбрать, каталог какой именно базы нужно проверять (в данном случае, той, где создана зона повышенной безопасности).С помощью параметра
--syslog
теперь можно организовать запись результатов проверки контрольных сумм вsyslog
.pg_integrity_check записывает как информацию об успешных проверках с уровнем важности
Information
, так и о неуспешных проверках с уровнем важностиCritical
.