32.3. Разграничение прав между привилегированными пользователями СУБД #

Конфигурация всех СУБД на основе PostgreSQL включает роль суперпользователя, применяемую для начальной загрузки базы данных. Однако дальнейшее использование этой роли для рутинных операций с СУБД несёт в себе риски для информационной безопасности. Поскольку учётная запись суперпользователя обладает широким набором прав в системе, она становится мишенью киберпреступников, что может привести к ряду неблагоприятных последствий, таких как:

  • Несанкционированный доступ к конфиденциальной информации.

  • Утечка данных.

  • Внесение опасных изменений в конфигурацию СУБД.

  • Сбои в работе СУБД.

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

32.3.1. Обзор #

Postgres Professional разработала и реализовала модель разделения обязанностей суперпользователя между двумя дополнительными административными ролями — администратором СУБД и администратором базы данных (Администратор БД). Кроме того, данная модель улучшает механизмы защиты от самостоятельного повышения привилегий и аудита действий всех пользователей.

Администратор СУБД отвечает за следующие действия:

  • Управление сервером.

  • Настройка репликации данных и резервного копирования.

  • Создание баз данных.

  • Настройка соединений с базой данных Postgres Pro.

  • Назначение администраторов БД.

Администратор БД отвечает за следующие действия:

  • Резервное копирование отдельной БД.

  • Создание таблиц и других объектов в рамках отдельной БД.

  • Создание пользователей БД.

  • Выдача пользователям прав доступа.

После делегирования большинства рутинных задач суперпользователя новым контролируемым администраторам организация может отказаться от активного использования этой роли, несущей большое количество рисков. Для этого администратору инфраструктуры достаточно внести в файл pg_hba.conf строки, запрещающие соединения для суперпользователя, а также заблокировать возможность изменения этого файла другими администраторами.

Если привилегии суперпользователя необходимо временно вернуть для решения некоторой редкой сложной задачи, безопасно это можно сделать в технологическом режиме (single mode) с привлечением администратора инфраструктуры. Для перевода СУБД в технологический режим её необходимо остановить и перезапустить командой:

  postgres --single -D DBMS_data_directory  other_options DB_name
  

Обратитесь к инструкции по установке дополнительно поставляемых модулей без участия суперпользователя в Разделе 17.2.

Расширение pg_proaudit, позволяющее регистрировать различные события, связанные с безопасностью, описано в Разделе F.49.

32.3.2. Создание дополнительных администраторов #

32.3.2.1. Создание роли администратора СУБД #

Данный раздел описывает создание роли и пользователя PGPRO_DBMS_ADMIN с соответствующими правами.

Данный скрипт создаёт роль PGPRO_DBMS_ADMIN и пользователя с этой ролью. Его запускает суперпользователь postgres. Обратите внимание, что скрипт использует следующие предопределённые роли:

  • pg_create_tablespace позволяет выполнять команду CREATE TABLESPACE без прав суперпользователя.

  • pg_manage_profiles позволяет выполнять команды CREATE PROFILE, ALTER PROFILE и DROP PROFILE без прав суперпользователя.

$ psql postgres
CREATE ROLE PGPRO_DBMS_ADMIN WITH CREATEDB CREATEROLE INHERIT LOGIN REPLICATION;
REVOKE ALL ON DATABASE postgres FROM PUBLIC;
GRANT CONNECT ON DATABASE postgres TO PGPRO_DBMS_ADMIN;
CREATE USER dbms_admin WITH CREATEDB CREATEROLE INHERIT LOGIN REPLICATION; -- Не забудьте установить первичный пароль
GRANT PGPRO_DBMS_ADMIN TO dbms_admin;
GRANT pg_read_all_settings TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
GRANT pg_read_all_stats TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
GRANT pg_stat_scan_tables TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
GRANT pg_monitor TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
GRANT pg_signal_backend TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
GRANT pg_checkpoint TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
GRANT pg_create_tablespace TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
GRANT pg_manage_profiles TO PGPRO_DBMS_ADMIN WITH ADMIN OPTION;
EXIT;

Разрешение для роли PGPRO_DBMS_ADMIN действий по управлению конфигурацией, а также записи в журнал и резервного копирования/восстановление выдаётся следующей командой от имени суперпользователя postgres.

$ psql postgres
GRANT EXECUTE ON FUNCTION pg_reload_conf TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_rotate_logfile TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_create_restore_point TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_backup_start TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_backup_stop TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_switch_wal TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_promote TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_wal_replay_pause TO PGPRO_DBMS_ADMIN;
GRANT EXECUTE ON FUNCTION pg_wal_replay_resume TO PGPRO_DBMS_ADMIN;
EXIT;

32.3.2.2. Создание роли администратора БД #

В рамках одной роли PGPRO_DB_DBNAME_ADMIN для одной БД может быть несколько пользователей. Также допускается, чтобы один пользователь включался в несколько разных ролей PGPRO_DB_DBNAME_ADMIN, если по должностным инструкциям он имеет право администрировать несколько разных БД.

Данный раздел описывает создание базы данных на примере БД под названием DB1, роли администратора БД для неё и пользователяDB1_ADMIN, наделённого соответствующими правами. На этом этапе для всех этих действий достаточно прав ранее созданного пользователя с ролью PGPRO_DBMS_ADMIN.

Данный скрипт создаёт базу данных DB1, роль PGPRO_DB_1_ADMIN и пользователя с этой ролью. Его запускает администратор СУБД:

$ psql postgres -U dbms_admin
SET ROLE PGPRO_DBMS_ADMIN;
CREATE ROLE PGPRO_DB_1_ADMIN WITH CREATEROLE INHERIT;
CREATE USER db1_admin WITH CREATEROLE INHERIT; -- Не забудьте установить первичный пароль
GRANT PGPRO_DB_1_ADMIN TO db1_admin;
GRANT PGPRO_DB_1_ADMIN TO PGPRO_DBMS_ADMIN;
GRANT pg_read_all_settings TO PGPRO_DB_1_ADMIN;
GRANT pg_read_all_stats TO PGPRO_DB_1_ADMIN;
GRANT pg_stat_scan_tables TO PGPRO_DB_1_ADMIN;
GRANT pg_monitor TO PGPRO_DB_1_ADMIN;
CREATE DATABASE db1 OWNER PGPRO_DB_1_ADMIN;
REVOKE CONNECT, TEMPORARY ON DATABASE db1 FROM PUBLIC;

32.3.3. Закрытие доступа для суперпользователя #

Чтобы запретить соединение для суперпользователя, администратор инфраструктуры вносит в 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

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

# chown root pg_hba.conf
# chmod 640 pg_hba.conf

В результате пользователь postgres не может самостоятельно вернуть себе возможность соединения с СУБД:

# ls -lh pg_hba.conf
-rw-r----- 1 root postgres .......... pg_hba.conf

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

# pg_ctl restart