Перейти к основному содержимому

Защита данных от привилегированных пользователей

Функциональность предназначена для защиты пользовательских данных и критичных настроек безопасности от несанкционированного доступа со стороны привилегированных пользователей.

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

Описание​

Для предотвращения несанкционированного доступа к пользовательским данным в СУБД Pangolin реализован механизм защиты данных от привилегированных пользователей, построенный на принципе разделения ролей.

Функциональность позволяет предотвратить доступ к пользовательским данным, хранящимся в СУБД Pangolin, со стороны неавторизованных лиц, в том числе имеющих права:

  • суперпользователя, включая управление объектами баз данных, пользователями, ролями и ролями пользователей;
  • администратора операционной системы, включая управление файлами, процессами, пользователями и их правами на объекты файловой системы и операционной системы;
  • администратора безопасности, включая доступ к ключам засекречивания TDE и управление параметрами безопасности;
  • администратора резервного копирования, включая права на доступ к файлам резервных копий, снятие резервных копий Pangolin и подключение к слотам репликации.

Механизм включает два функциональных блока:

  • защиту параметров конфигурации, позволяющих реализовать угрозы раскрытия пользовательских данных;
  • защиту доступа к пользовательским данным в объектах БД.

Объекты, помещаемые под защиту​

Под защиту могут быть помещены следующие типы объектов:

  • Схема – на действия изменения, удаления;
  • Таблицы – на действия DML чтения, вставки, изменения и удаления, DDL - изменения и удаления, создания или изменения триггера по таблице, создания или изменения правила по таблице;
  • Партиции – на действия DML чтения, вставки, изменения и удаления, DDL - изменения и удаления;
  • Материализованные представления – на действия DML чтения, DDL - изменения и удаления;
  • Представления – на действия DML чтения, вставки, изменения и удаления, DDL - изменения и удаления, создания или изменения триггера по представлению, создания или изменения правила по представлению;
  • Функции – на вызов, изменение, удаление;
  • Роль – на действия удаления, изменения, выдачу роли-объекту, отзыв у роли-объекта, выдачу в качестве роли-объекта, отзыв в качестве роли-объекта, смену пароля, назначения текущей роли сессии.

Информация для ограничения доступа хранится в таблицах каталога безопасности, подробнее о данных таблицах в подразделе «Таблицы каталога безопасности» раздела «Таблицы» документа «Справочная информация».

Предупреждение!

Защита таблицы со ссылками на LOB или BFILE не действует, как защита самих объектов LOB или BFILE.

Администратор безопасности​

В СУБД Pangolin администраторы БД и администраторы ОС не имеют возможности самостоятельно управлять рядом параметров, а также перестают иметь полный доступ ко всем объектам БД.

В дополнение к роли суперпользователя, которая есть в свободно распространяемой версии PostgreSQL, в СУБД Pangolin добавлена специальная роль «Администратора безопасности». Администратор безопасности – независимый администратор, не обладающий особыми правами в операционной системе (в том числе не имеющий прав Linux-пользователя postgres) и не имеющий доступа к объектам БД.

Внимание!

Ни один из пользователей не может единолично получить доступ к конфиденциальным данным или изменять важные для безопасности настройки БД и права доступа.

Создание учетной записи администратора безопасности в СУБД Pangolin выполняется при запуске утилиты инициализации каталога безопасности.

Можно указать несколько создаваемых учетных записей администраторов безопасности при инициализации. Список задается в параметре -U через запятую. Соответствующие пароли либо запрашиваются у пользователя, для каждого логина отдельно, либо должны быть указаны в параметре -P как хеши через запятую. Количество переданных паролей/хешей паролей должно совпадать с количеством логинов.

Учетные записи администраторов безопасности также находятся под защитой и не могут быть изменены администратором БД.

примечание

Наделение привилегиями администратора безопасности выполняется только администраторами безопасности.

Администратор безопасности участвует в следующих процессах:

  • установка и настройка кластера;
  • создание и настройка записи администратора безопасности;
  • удаление учетной записи администратора безопасности;
  • создание политики защиты в БД;
  • удаление политики защиты в БД;
  • создание и настройка технической учетной записи (ТУЗ) приложения в БД через политику;
  • изъятие привилегий учетной записи ТУЗ приложения, выданных через политику, в БД;
  • удаление учетной записи ТУЗ приложения в БД;
  • изменение пароля защищаемой учетной записи в БД;
  • помещение объектов БД под защиту;
  • изъятие объектов БД из-под защиты.

Подробней об этом в разделе данного документа.

Управление доступом на основе ролей​

Механизм защиты данных управляется только администраторами безопасности.

Управление доступом на основе ролей (Role Based Access Control, RBAC) — развитие политики избирательного управления доступом, когда права доступа субъектов системы на объекты группируются с учетом специфики их применения, формируя роли.

Информация для ограничения доступа к данным БД хранится в таблицах каталога безопасности. Инициализация каталога безопасности и создание учетной записи администратора безопасности выполняются утилитой инициализации каталога безопасности. Учетные записи администраторов безопасности также находятся под защитой и не могут быть изменены администратором СУБД. Наделение привилегиями администратора безопасности выполняется только администраторами безопасности.

Защита параметров конфигурации​

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

Механизм защиты параметров управляется дублируемыми параметрами в локальных конфигурационных файлах и защищенном хранилище.

При включении защищенного конфигурирования параметры конфигурации компонентов кластера высокой доступности, влияющие на безопасность, хранятся в защищенном хранилище и недоступны для изменения Администратором БД и Администратором ОС.

Администраторы БД и администраторы ОС теряют возможность самостоятельно управлять некоторыми параметрами и перестают иметь полный доступ ко всем объектам БД, администраторы БД также не имеют привилегий на действия над защищаемой учетной записью. Администраторы безопасности не имеют прав на выполнение действий над объектами схем приложений АС, на изменение локальных конфигурационных файлов, а также не имеют возможности изменить пароли ТУЗ или администратора БД.

Защита параметров требует наличия установленного и интегрированного решения хранилища секретов (KMS) и выделенной роли администратора безопасности. В продукте СУБД Pangolin реализована интеграция с хранилищем секретов HashiCorp Vault. Для тестирования настроек и соединения с хранилищем секретов используется плагин-заменитель KMS.

Настройка защиты данных​

Первоначальная настройка СУБД с активацией функциональности осуществляется следующим образом:

  1. Администратор БД выполняет установку СУБД Pangolin.
  2. Администратор БД выполняет запуск инициализации initdb СУБД.
  3. Администратор ОС выдает пользователю ОС (администратору безопасности) права на использование утилит засекречивания для доступа к хранилищу секретов и инициализации каталога безопасности СУБД.
  4. Администратор безопасности выполняет запуск утилиты инициализации каталога безопасности initprotection, задавая логин и пароль учетной записи администратора безопасности для кластера, и указывая табличное пространство для хранения каталога.
  5. Администратор безопасности выполняет запуск утилиты засекречивания setup_kms_credentials для доступа к хранилищу секретов, создавая файл с параметрами соединения с хранилищем.
  6. Администратор БД синхронизирует локальные параметры СУБД с параметрами хранилища секретов.
  7. Администратор БД выполняет запуск экземпляра СУБД.
  8. Администратор БД создает табличные пространства и базы данных кластера высокой доступности, защищенные прозрачным засекречиванием и механизмом защиты.
  9. Администратор безопасности помещает под защиту объекты БД, содержащие конфиденциальную информацию.

Для включения и последующей настройки механизма защиты данных от привилегированных пользователей в действующем кластере Pangolin необходимо выполнить шаги представленные в разделе «Подключение СЗИ».

Инициализация каталога безопасности​

Для включения механизма защиты данных от привилегированных пользователей, инициализации каталога безопасности необходимо выполнить запуск утилиты initprotection.

Инициализация каталога безопасности должна выполняться администратором безопасности (kmadmin_pg) на первом из серверов кластера высокой доступности.

Для защиты утилит настройки расширенной безопасности (encrypt_params_file, generate_encryption_key, setup_kms_credentials, initprotection) от использования DBA в ОС создается пользователь kmadmin_pg. Для утилиты initprotection устанавливается владелец kmadmin_pg и группа kmadmin_pg, группе выдается возможность выполнять и читать утилиту initprotection:

-r-xr-x--- 1 kmadmin_pg kmadmin_pg 376384 Oct 24 16:01 /usr/pangolin/bin/initprotection

В файл sudoers создается правило для пользователя kmadmin_pg:

kmadmin_pg ALL = (postgres : kmadmin_pg) NOPASSWD: /bin/bash -c /usr/pangolin/bin/initprotection

Где /usr/pangolin/bin – путь к директории с исполняемыми файлами СУБД Pangolin.

Pangolin Manager должен устанавливаться и настраиваться поверх существующего экземпляра Pangolin и не должен выполнять переинициализацию экземпляра СУБД.

Утилита инициализации каталога безопасности​

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

Утилита инициализации каталога безопасности принимает на вход следующие параметры:

  • путь к директории $PGDATA базы данных;
  • логин администратора безопасности;
  • пароль администратора безопасности;

Пример запуска утилиты инициализации:

sudo -i -u postgres -g kmadmin_pg /usr/pangolin/bin/initprotection

Где /usr/pangolin/bin – путь к директории с исполняемыми файлами СУБД Pangolin.

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

Утилита инициализации каталога безопасности initprotection выполняет следующие действия:

  • При запуске утилиты для экземпляра Pangolin с ранее инициализированным каталогом безопасности утилита выводит сообщение о том, что каталог безопасности находится не в ожидаемом состоянии;

  • Создает групповую роль администраторов безопасности sec_admin_role: роль помещается под защиту и не может быть явно выдана никак, иначе чем через специальные функции API администраторов безопасности;

  • Создает парольную политику для роли sec_admin_role:

    • время жизни пароля не ограничено;
    • УЗ не блокируется при попытках ввода неверного значения пароля;
    • сложность пароля для zxcvbn = 3;
    • минимальная длина пароля – 25;
    • остальные параметры парольных политик берутся из настроек по умолчанию;

  • Запрашивает пароль создаваемого администратора безопасности для ввода пользователем с консоли: прием параметра пароля администратора безопасности в переменной окружения или параметрах вызова утилиты запрещен в целях безопасности;

  • Задает параметр аудита для роли sec_admin_role: pgaudit.log = 'ALL';

  • Заполняет таблицы каталога безопасности согласно модели данных каталога безопасности;

  • Создает роль пользователя администратора безопасности с указанными логином и паролем, выдает ему права на чтение из общего каталога и из каталогов баз данных;

  • Создает функции интерфейса администратора безопасности;

  • Включает в защищаемые объекты роль администратора безопасности, таблицы каталога безопасности, функции интерфейса администратора безопасности;

  • Выдает создаваемым пользователям-администраторам безопасности роль sec_admin_role;

  • Создает предустановленную политику secAdminUser, включающая разрешение на переключение на роль sec_admin_role;

  • Выдает создаваемым пользователям-администраторам безопасности новую политику secAdminUser;

  • для созданных пользователей-администраторов безопасности устанавливается правило переключения на роль sec_admin_role при логине (ALTER ROLE .. SET ROLE sec_admin_role);

  • Ранее реализованная выдача политик на функции API администратора безопасности и каталоги безопасности непосредственно пользователю-администратору безопасности исключена;

  • Пароль создаваемого при инициализации механизма защиты пользователя заносится в pg_authid строго в виде scram-sha-256 хеша.

примечание

После включения механизма защиты загрузка дополнительных расширений через команду LOAD становится недоступна. Также игнорируются параметры local_pleload_libraries и session_preload_libraries.

Включение механизма защиты данных от привилегированных пользователей​

Активация функциональности доступна ручным и автоматизированным способом. Инструкция с шагами действий представлена в разделе «Подключение СЗИ» данного документа.

Мониторинг включения защиты данных от привилегированных пользователей​

Для возможности мониторинга включения защиты данных от привилегированных пользователей в СУБД Pangolin реализована функция проверки check_admin_protect_is_on:

SELECT check_admin_protect_is_on();

 check_admin_protect_is_on
---------------------------
 t
(1 row)

Функции интерфейса администратора безопасности​

Интерфейс администратора безопасности включает в себя следующие функции настройки механизма защиты от привилегированных пользователей:

  1. Действия с политиками:

    • pm_get_policies - вывод списка политик;
    • pm_get_policy_grants - вывод списка разрешений (правил) в составе политики;
    • pm_make_policy - создание политики;
    • pm_grant_to_policy - внесение в политику разрешения на действия над объектом;
    • pm_revoke_from_policy - исключение из политики разрешения на действия над объектом;
    • pm_revoke_all_actions_from_policy - исключение из политики всех ранее выданных разрешений для указанного объекта;
    • pm_suspend_object - приостановка действия политики защиты;
    • pm_resume_object - возобновление действия политики защиты;
    • pm_remove_policy - удаление политики защиты.

  2. Действия с пользователями:

    • pm_get_assigned_policies - вывод списка политик, назначенных пользователю;
    • pm_assign_policy_to_user - назначение политики пользователю;
    • pm_unassign_policy_from_user - изъятие политики у пользователя.

  3. Действия над объектами:

    • pm_get_protected_objects - вывод списка объектов, находящихся под защитой;
    • pm_protect_object - помещение объекта БД под защиту;
    • pm_unprotect_object - снятие защиты с объекта БД;
    • pm_get_object_access_path - получение информации об эффективных действующих, для указанных объектов и роли, ограничениях защиты и разрешениях на доступ к объекту под защитой.

  4. Действия над УЗ администраторов безопасности:

    • pm_create_security_admin - создание учетной записи администратора безопасности;
    • pm_set_security_admin_password - изменение пароля учетной записи администратора безопасности;
    • pm_grant_security_admin - назначение пользователя администратором безопасности;
    • pm_revoke_security_admin - снятие с пользователя политики администратора безопасности;
    • pm_unblock_security_admin - разблокировка заблокированной учетной записи администратора безопасности.

Подробней о каждой функции в разделе «Функции интерфейса администратора безопасности» документа «Справочная информация».

Логирование использования данных функций, происходит с помощью класса событий аудита PROTECTION. Подробное описание формата и примеров логов приведено в разделе «Журналирование и аудит» данного документа.

Управление​

Создание и настройка учетной записи администратора безопасности​

Первая учетная запись администратора безопасности создается при инициализации механизма защиты:

  1. Администратор операционной системы создает учетную запись пользователя операционной системы.

  2. Администратор операционной системы наделяет созданного пользователя правами на запуск утилиты инициализации механизма защиты initprotection.

  3. Администратор безопасности заходит в систему как пользователь с правами на запуск утилиты initprotection и запускает ее.

  4. Утилита запрашивает логин и пароль для создания новой учетной записи администратора безопасности с указанными логином и паролем. В дальнейшем создание и настройка учетной записи администратора безопасности выполняются администратором СУБД и администратором безопасности:

    1. Администратор СУБД создает учетную запись администратора безопасности в Pangolin, задавая логин и пароль для подключения.
    2. Администратор СУБД выдает созданной учетной записи минимально необходимые права: общие права на подключение, вызов функций управления каталогом безопасности и доступ к общему системному каталогу.
    3. Администратор безопасности (владелец создаваемой учетной записи) подключается к Pangolin с заданными администратором СУБД логином и паролем и производит замену пароля на новый, известный только ему.
    4. Администратор безопасности (не владелец создаваемой записи) с помощью функции pm_grant_security_admin создает и применяет политики защиты данных, разрешающие доступ к роли и к функциям администратора безопасности для создаваемой учетной записи администратора безопасности.
    5. Администратор безопасности (не владелец создаваемой записи) помещает объект БД, роль создаваемой учетной записи администратора безопасности, под защиту механизма защиты данных.

Создание и настройка учетной записи sec_admin

Удаление учетной записи администратора безопасности​

Администратор Pangolin и администратор безопасности могут инициировать удаление учетной записи пользователя из системы. При этом администратор СУБД не может удалить учетную запись пользователя, которая находится под защитой механизма защиты данных (например, администратора) – этот процесс может запустить только администратор безопасности.

Удаление учетной записи происходит следующим образом:

  1. Администратор безопасности изымает привилегии администратора безопасности у удаляемой учетной записи.
  2. Администратор безопасности исключает роль удаляемой учетной записи из-под защиты.
  3. Администратор СУБД удаляет учетную запись.

Удаление учетной записи sec_admin

Создание политики защиты в СУБД Pangolin​

Политика защиты в СУБД Pangolin создается и наполняется разрешениями на действия над защищенными объектами БД администратором безопасности.

Создание политики защиты

Создание и настройка технической учетной записи приложения через политику​

Для управления доступом приложений к СУБД используются технические учетные записи (ТУЗ). Они создаются и настраиваются следующим образом:

  1. Администратор СУБД создает ТУЗ и задает исходные логин и пароль.
  2. Администратор СУБД выдает ТУЗ необходимые роли и разрешения на доступ к объектам БД в рамках системы прав СУБД.
  3. Владелец ТУЗ меняет пароль учетной записи.
  4. Администратор безопасности указывает необходимость двухфакторной аутентификации для ТУЗ в защищенном хранилище, редактируя pg_hba.conf.
  5. Администратор безопасности назначает ТУЗ ранее созданную политику с необходимыми приложению разрешениями.
  6. Администратор безопасности помещает объект роли ТУЗ под защиту.

Создание учетной записи ТУЗ приложени

Изъятие привилегий учетной записи ТУЗ приложения, выданных через политику​

Изъятие политики доступа ТУЗ осуществляется администратором безопасности.

Изъятие привилегий на данные ТУЗ

Удаление политики защиты в СУБД Pangolin​

Удаление политик механизма защиты данных выполняется администратором безопасности. Политики данных, связанные хотя бы с одной учетной записью, удалить невозможно.

Удаление политики защиты

Удаление технической учетной записи приложения​

Удаление ТУЗ выполняется администратором базы данных. При этом он не может самостоятельно удалить ТУЗ, находящиеся под защитой: для того, чтобы их удалить, администратор безопасности должен вывести эти ТУЗ из-под механизма защиты данных.

Удаление учетной записи ТУЗ приложения

Изменение пароля защищаемой учетной записи​

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

Если владелец технической учетной записи хочет изменить ее пароль, выполняются следующие шаги:

  1. Владелец ТУЗ или администратор безопасности инициирует процесс изменения пароля.
  2. Администратор безопасности снимает политики, дающие учетной записи доступ к защищаемым данным.
  3. Администратор безопасности исключает роль учетной записи из-под защиты механизма защиты данных.
  4. Владелец ТУЗ устанавливает новый пароль: если изменение пароля ТУЗ было инициировано администратором безопасности, то сначала новый пароль устанавливает администратор СУБД, затем – владелец ТУЗ.
  5. Администратор безопасности помещает роль учетной записи под защиту механизма защиты данных.
  6. Администратор безопасности назначает политики, дающие учетной записи доступ к защищаемым данным.

Изменение пароля учетной записи

Помещение объектов БД под защиту​

Объекты базы данных помещаются под защиту администратором безопасности.

При этом новые объекты базы данных могут создаваться только администратором СУБД.

Помещение объекта БД под защиту

Важно

Для выполнения операций UPDATE view поставленных под защиту объектов необходимо также выдавать право SELECT для таблиц/столбцов и представлений (view), данные/значения которых считываются в условии.

Изъятие объектов БД из-под защиты​

Изъятие объектов базы данных из-под защиты осуществляется администратором безопасности. При этом администратор безопасности может также выключить все разрешения доступа к объекту.

Изъятие объекта БД из-под защиты

Доступ к данным, содержащимся в защищаемых объектах БД​

Доступ к защищаемым объектам базы данных осуществляется по следующему алгоритму:

  1. Поступает запрос на обращение к объекту базы данных.
  2. Если объект базы данных находится под защитой, выполняется проверка разрешений на доступ к этому объекту: если объект базы данных не находится под защитой, возвращается результат запроса.
  3. Если запрос соответствует хотя бы одному разрешению, возвращается результат запроса: если запрос не соответствует ни одному разрешению, возвращается ошибка.

Защита переноса объектов между табличными пространствами​

Выдача прав на перенос объектов между табличными пространствами осуществляется для:

  • таблиц:

    • ALTER TABLE {имя} SET TABLESPACE '{целевое пространство}';
    • ALTER TABLE ALL IN TABLESPACE '{исходное пространство}' SET TABLESPACE '{целевое пространство}';
    • перемещение таблицы между табличными пространствами при использовании расширения pg_squeeze;
    • перемещение любого из индексов таблицы между ТП в pg_squeeze;

  • материализованных представлений:

    • ALTER MATERIALIZED VIEW {имя} SET TABLESPACE '{целевое пространство}';
    • ALTER MATERIALIZED ALL IN TABLESPACE '{исходное пространство}' SET TABLESPACE '{целевое пространство}'.

Пример:

SELECT pm_grant_to_policy('{имя политики}', '{база}', 'table', '{полное имя таблицы}', array['move']::name[]);
SELECT pm_grant_to_policy('{имя политики}', '{база}', 'matview', '{полное имя мат. представления}', array['move']::name[]);

Вызов данной функции предполагает, что объект уже под защитой, а политика уже создана. В противном случае будет получена ошибка выполнения функции:

ERROR: objects not found — если объект не найден среди защищенных
ERROR: policy not found — нет политики с указанным именем

Попытка задать правило move для других объектов также приведет к ошибке:

ERROR: error in the actions list — действие не соответствует типу объекта

Сценарии использования​

Помещение объекта БД под защиту/снятие защиты с объекта​

В данном разделе приведены примеры использования помещения под защиту/снятие защиты с объекта базы данных.

Помещение объекта БД (на примере таблицы) под защиту​

Для того чтобы поставить объект под защиту необходимо:

  • создать политику;
  • поместить объект БД под защиту;
  • внести в политику разрешение на действия над объектом;
  • назначить созданную политику пользователю.

  1. Создайте таблицу test_table в БД First_db.

  2. Создайте политику защиты test_policy администратором безопасности с помощью функции pm_make_policy:

    SELECT pm_make_policy('test_policy');

     pm_make_policy
    ----------------
    t
    (1 row)

  3. Поместите объект под защиту с помощью функции pm_protect_object:

    SELECT pm_protect_object('table','ext.test_table');

     pm_protect_object
    -------------------
    t
    (1 row)

  4. Внесите в политику разрешение на действия SELECT и INSERT в таблице с помощью функции pm_grant_to_policy:

    SELECT pm_grant_to_policy('test_policy', 'table', 'ext.test_table', array['select','insert']::name[]);

     pm_grant_to_policy
    --------------------
    t
    (1 row)

  5. Назначьте созданную политику пользователю user_test с помощью функции pm_assign_policy_to_user:

    SELECT pm_assign_policy_to_user('user_test', 'test_policy');

     pm_assign_policy_to_user
    --------------------------
    t
    (1 row)

  6. Выполните следующие операции от пользователя user_test.

  7. Добавьте записи в таблицу (INSERT):

    INSERT INTO test_table VALUES (444, 'WWWWW');

    INSERT 0 1

  8. Выполните просмотр таблицы:

    SELECT * FROM test_table;

     id  |   a
    -----+-------
     444 | WWWWW
    (1 row)

  9. Выполните действие над таблицей, которое не разрешено (например, UPDATE):

    UPDATE test_table SET a='QQQQ' WHERE id=444;

    ERROR:  Action for relation is forbidden
    HINT:  Action "update" must be granted for relation "test_table"

    В результате будет выведено сообщение о том, что данное действие запрещено.

    Также данное событие отражено в журнале сообщений:

    2022-11-20 08:59:29 MSK [16913]: [4-1] app=psql,user=user_test,db=First_db,client=<IP-Address>,type=client backend ERROR:  Action for relation is forbidden
    2022-11-20 08:59:29 MSK [16913]: [5-1] app=psql,user=user_test,db=First_db,client=<IP-Address>,type=client backend HINT:  Action "update" must be granted for relation "test_table"

  10. Если данное действие добавить в список разрешенных в политику защиты, то действие будет разрешено. Под администратором безопасности добавьте разрешение на действия UPDATE в политику защиты:

    SELECT pm_grant_to_policy('test_policy', 'table', 'ext.test_table', array['update']::name[]);

     pm_grant_to_policy
    --------------------
    t
    (1 row)

  11. Под пользователем user_test выполните операцию UPDATE:

    UPDATE test_table SET a='QQQQ' WHERE id=444;

    UPDATE 1

    После внесения изменений в политику защиты данная операция пользователю разрешена и при выполнении ошибок не возникает.

Помещение роли под защиту​

Для управления доступом приложений к СУБД используются технические учетные записи (ТУЗ). Они создаются и настраиваются следующим образом:

  1. Администратор БД создает ТУЗ, задает исходные логин и пароль (транспортный), выдает ТУЗ необходимые роли и разрешения.
  2. Владелец ТУЗ меняет пароль учетной записи.
  3. Администратор безопасности создает политику защиты.
  4. Администратор безопасности помещает роль ТУЗ под защиту механизма защиты данных.
  5. Администратор безопасности вносит в политику разрешения на действия над защищаемой ролью.
  6. Администратор безопасности назначает ранее созданную политику пользователю (Администратору БД).

В качестве примера выполните последовательно данные действия.

  1. Создайте пользователя (например, tuz_test) в БД с транспортным паролем, выдайте необходимые привилегии.

    CREATE USER tuz_test WITH TEMPORARY PASSWORD '<password>';
    CREATE ROLE

  2. Выполните вход под созданной учетной записью и смените транспортный пароль на постоянный:

    ALTER USER tuz_test WITH ENCRYPTED PASSWORD '<password>';
    ALTER ROLE

  3. Создайте политику защиты администратором безопасности с помощью функции pm_make_policy:

    SELECT pm_make_policy('tuz_policy_test');

     pm_make_policy
    ----------------
    t
    (1 row)

  4. Поместите созданного пользователя ТУЗ под защиту администратором безопасности с помощью функции pm_protect_object:

    SELECT pm_protect_object('role','tuz_test');

     pm_protect_object
    -------------------
    t
    (1 row)

  5. Администратором безопасности внесите необходимые разрешения на выполнение операций (например, ALTER_PASSWORD) над защищаемой ролью с помощью функции pm_grant_to_policy:

    SELECT pm_grant_to_policy('tuz_policy_test', 'role', 'tuz_test', array['alter_password']::name[]);

     pm_grant_to_policy
    --------------------
    t
    (1 row)

  6. Администратором безопасности назначьте ранее созданную политику (в случае если назначается групповая роль, то не разрешенные действия будут запрещены всем пользователям с привилегиями этой роли, либо можно назначить конкретному пользователю) роли db_admin с помощью функции pm_assign_policy_to_user:

    SELECT pm_assign_policy_to_user('db_admin', 'tuz_policy_test');

     pm_assign_policy_to_user
    --------------------------
    t
    (1 row)

  7. Совершите администратором БД (с правами db_admin) разрешенные и неразрешенные действия с пользователем tuz_test (разрешенные ALTER_PASSWORD и не разрешенные DROP, GRANT):

    1. Выполните вход администратором БД:

      $ psql -U admin_test

    2. Проверьте, с какой ролью подключился администратор:

      SELECT current_user, current_role;

       current_user | current_role
      --------------+--------------
       db_admin     | db_admin
      (1 row)

    3. Выполните операцию смены пароля ALTER ... PASSWORD ...:

      ALTER USER tuz_test WITH ENCRYPTED PASSWORD '<password>';

      ALTER ROLE

      Операция ALTER_PASSWORD политикой защиты разрешена, ошибок не возникает.

    4. Выполните операции, которые не разрешены, например DROP, GRANT:

      DROP ROLE tuz_test;
      GRANT db_admin TO tuz_test;
      ERROR:  Deletion of the role is forbidden
      ERROR:  Granting to the role is forbidden

      Сообщения об ошибке ERROR: ... the role is forbidden говорят о том, что данные действия запрещены. Также эти ошибки отражены в журнале сообщений:

      2022-11-20 12:25:44 MSK [27593]: [6-1] app=psql,user=admin_test,db=postgres,client=<IP-Address>,type=client backend STATEMENT:  DROP ROLE tuz_test;
      2022-11-20 12:25:44 MSK [27593]: [7-1] app=psql,user=admin_test,db=postgres,client=<IP-Address>,type=client backend LOG:  AUDIT: SESSION,2,1,ROLE,DROP ROLE,,,DROP ROLE tuz_test;,<not logged>,ERROR: Deletion of the role is forbidden
      2022-11-20 12:26:02 MSK [27593]: [9-1] app=psql,user=admin_test,db=postgres,client=<IP-Address>,type=client backend STATEMENT:  GRANT db_admin TO tuz_test;
      2022-11-20 12:26:02 MSK [27593]: [10-1] app=psql,user=admin_test,db=postgres,client=<IP-Address>,type=client backend LOG:  AUDIT: SESSION,3,1,ROLE,GRANT ROLE,,,GRANT db_admin TO tuz_test;,<not logged>,ERROR: Granting to the role is forbidden

  8. Внесите разрешение в политику защиты администратором безопасности:

    SELECT pm_grant_to_policy('tuz_policy_test', 'role', 'tuz_test', array['grant_to']::name[]);

     pm_grant_to_policy
    --------------------
    t
    (1 row)

  9. Выведите список разрешенных действий в политике защиты:

    SELECT * FROM pm_get_policy_grants('tuz_policy_test');
     db_oid | db_name | namespace_oid | object_oid | object_name | object_kind |  action
    --------+---------+---------------+------------+-------------+-------------+----------
            |         |               |      19175 | tuz_test    | role        | alter_password
            |         |               |      19175 | tuz_test    | role        | grant_to
    (2 rows)

  10. Выполните добавленные действия над ролью:

    GRANT db_admin TO tuz_test;
    GRANT ROLE

    Ошибок не возникло, так как действие разрешено.

Изъятие объектов БД из-под защиты​

Изъятие объектов базы данных из-под защиты осуществляется администратором безопасности.

Снятие защиты с объекта БД (таблицы)​

Таблица БД test_table схемы ext находится под защитой, в состав политики защиты test_policy включены разрешенные действия над таблицей test_table.

  1. Выполните администратором безопасности просмотр списка объектов, находящихся под защитой, с условием:

    SELECT * FROM pm_get_protected_objects() WHERE object_name='test_table';

     db_oid | db_name  | object_oid | object_name | object_kind | is_protected | ispredef | state | staterole
    --------+----------+------------+-------------+-------------+--------------+----------+-------+-----------
      16401 | First_db |      17928 | test_table  | table       | t            | f        |     0 |         0
    (1 row)

    Поле is_protected='t' говорит о том, что объект находится под защитой.

    Поле state=0 — защита действует.

  2. Выполните просмотр разрешений в составе политики test_policy:

    SELECT * FROM pm_get_policy_grants('test_policy');

     db_oid | db_name  | namespace_oid | object_oid |   object_name   | object_kind | action
    --------+----------+---------------+------------+-----------------+-------------+--------
      16401 | First_db |         16404 |      17928 | ext.test_table  | table       | select
      16401 | First_db |         16404 |      17928 | ext.test_table  | table       | insert
    (2 rows)

  3. Для исключения объекта из-под защиты необходимо воспользоваться функцией pm_unprotect_object:

    SELECT pm_unprotect_object('table', 'ext.test_table');

     pm_unprotect_object
    ---------------------
     t
    (1 row)

    Действие снятия защиты с объекта отражается в журнале сообщений:

    2025-10-30 13:30:52 MSK [3882782]: [26-1] app=psql,user=<sec_admin>,db=<DB>,client=<IP-Address>,type=client backend LOG:  AUDIT: SESSION,7,1,READ,SELECT,,,"SELECT pm_unprotect_object('table', 'ext.test_table');",<not logged>
    2025-10-30 13:30:52 MSK [3882782]: [27-1] app=psql,user==<sec_admin>,db=<DB>,client=<IP-Address>,type=client backend LOG:  AUDIT: SESSION,7,2,PROTECTION,UNPROTECT,TABLE,ext.test_table,"Un-protect object 'table' 'ext.test_table'",<ID>,HIGH
    2025-10-30 13:30:52 MSK [3882782]: [28-1] app=psql,user==<sec_admin>,db=<DB>,client=<IP-Address>,type=client backend LOG:  AUDIT: SESSION,7,2,PROTECTION,UNPROTECT,TABLE,ext.test_table,"Un-protect object 'table' 'ext.test_table'",SUCCESS,<ID>,HIGH

  4. При исключении объекта из-под защиты все связанные с ним разрешения в составе политики также удаляются.

    Выполните просмотр разрешений в составе политики test_policy:

    SELECT * FROM pm_get_policy_grants('test_policy');

     db_oid | db_name | namespace_oid | object_oid | object_name | object_kind | action
    --------+---------+---------------+------------+-------------+-------------+--------
    (0 rows)
Снятие защиты с роли БД​

Пользователь БД tuz_test находится под защитой, в состав политики защиты tuz_policy_test включены разрешенные действия (alter, grant_to).

  1. Выполните администратором безопасности просмотр списка объектов, находящихся под защитой, с условием:

    SELECT * FROM pm_get_protected_objects() WHERE object_name='tuz_test';

     db_oid |  db_name  | object_oid | object_name | object_kind | is_protected | ispredef | state | staterole
    --------+-----------+------------+-------------+-------------+--------------+----------+-------+-----------
            |           |      17939 | tuz_test    | role        | t            | f        |     0 |         0
    (1 row)

    Присутствие записи с object_name='tuz_test', а также полей is_protected='t' и state=0 говорит о том, что объект находится под защитой и защита активна.

  2. Выполните просмотр разрешений в составе политики tuz_policy_test:

    SELECT * FROM pm_get_policy_grants('tuz_policy_test');

     db_oid | db_name | namespace_oid | object_oid | object_name | object_kind |  action
    --------+---------+---------------+------------+-------------+-------------+----------
            |         |               |      17939 | tuz_test    | role        | alter_password
            |         |               |      17939 | tuz_test    | role        | grant_to
    (2 rows)

  3. Для исключения пользователя из-под защиты необходимо воспользоваться функцией pm_unprotect_object:

    SELECT pm_unprotect_object('role', 'tuz_test');

     pm_unprotect_object
    ---------------------
     t
    (1 row)

    Действие снятия защиты с объекта отражается в журнале сообщений:

    2025-10-30 13:37:00 MSK [3882782]: [38-1] app=psql,user=<sec_admin>,db=<DB>,client=<IP-Address>,,type=client backend LOG:  AUDIT: SESSION,11,1,READ,SELECT,,,"SELECT pm_unprotect_object('role', 'tuz_test');",<not logged>
    2025-10-30 13:37:00 MSK [3882782]: [39-1] app=psql,user==<sec_admin>,db=<DB>,client=<IP-Address>,,type=client backend LOG:  AUDIT: SESSION,11,2,PROTECTION,UNPROTECT,ROLE,tuz_test,"Un-protect object 'role' 'tuz_test'",<ID>,HIGH
    2025-10-30 13:37:00 MSK [3882782]: [40-1] app=psql,user==<sec_admin>,db=<DB>,client=<IP-Address>,,type=client backend LOG:  AUDIT: SESSION,11,2,PROTECTION,UNPROTECT,ROLE,tuz_test,"Un-protect object 'role' 'tuz_test'",SUCCESS,<ID>,HIGH

  4. При исключении пользователя из-под защиты все связанные с ним разрешения в составе политики также удаляются.

    Выполните просмотр разрешений в составе политики tuz_policy_test:

    SELECT * FROM pm_get_policy_grants('tuz_policy_test');

     db_oid | db_name | namespace_oid | object_oid | object_name | object_kind | action
    --------+---------+---------------+------------+-------------+-------------+--------
    (0 rows)