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

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

Сведения

Функциональность доступна только для редакций 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.

Особенности

Параметры подключения Pangolin Pooler к БД хранятся в защищенном хранилище. Все методы аутентификации, кроме scram-sha-256, ldap и radius, становятся недоступны к использованию без их указания в параметре enabled_extra_auth_methods. При включенном механизме защиты параметров управление целиком передается на сторону защищенного хранилища администраторам безопасности. Параметр enabled_extra_auth_methods считывается из хранилища секретов. Для администраторов безопасности методы аутентификации описываются в параметре enabled_sec_admin_extra_auth_methods. Параметр sec_admin_default_auth управляет методом аутентификации для виртуального правила подключения администраторов безопасности. Если значение параметра не пустое, то выполняется аутентификация в соответствии с методом аутентификации из виртуального правила. Если значение параметра пустое, виртуальное правило не создается, используется pg_hba.

При включенном механизме защиты параметров настройки параметров Pangolin Manager из конфигурационного файла добавляются в защищенное хранилище либо дублируются в локальном конфигурационном файле при использовании KMS-заменителя.

Настройка защищенного конфигурирования

Включение и выключение режима защищенного конфигурирования контролируется параметром secure_config:

• secure_config = on – система загружает из защищенного хранилища/KMS заданные администратором безопасности параметры;
• secure_config = off – параметры из хранилища секретов не учитываются (защита отключена).

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

Настроечные параметры СУБД

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

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

Параметры, выведенные из хранения в защищенном хранилище секретов

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

• pg_hba – методы аутентификации и подключения;
• shared_preload_libraries, jit_provider – подгружаемые PostgreSQL библиотеки;
• local_preload_libraries, session_preload_libraries – подгружаемые PostgreSQL библиотеки;
• dynamic_library_path – путь к динамически подгружаемым модулям;
• password_encryption – метод хеширования паролей пользователей.

Параметры, переданные на сторону защищенного хранилища секретов

Параметры, перемещенные в защищенное хранилище:

• allowed_servers – список разрешенных к использованию LDAP и RADIUS серверов;

• ssl – режим работы с SSL;

• encrypt_new_tablespaces – засекречивание новых табличных пространств;

  примечание

  Параметр действует только при запуске Pangolin и включенном TDE: is_tde_on = on/true.

  В случае, если в качестве значения параметра выбрано значение по умолчанию ddl, новые табличные пространства кодируются только при ручной установке опции is_encrypted = on, по умолчанию засекречивание не применяется.

  При выборе значения параметра always, опция is_encryped, передаваемая в команде, игнорируется, так как в этом случае на все таблицы пространства будет применено засекречивание.

• enabled_sec_admin_extra_auth_methods – список дополнительно разрешенных к использованию методов аутентификации для ролей администраторов безопасности;

• enabled_extra_auth_methods – список дополнительно разрешенных к использованию методов аутентификации для всех ролей;

  примечание

  По умолчанию доступны только методы аутентификации scram-sha-256, ldap, radius. Для применения изменений, достаточно выполнить reload (SIGHUP) Pangolin.

  Значения параметров применяются при аутентификации, так как это единственный этап, когда можно фактически определить принадлежность аутентифицируемой роли к администраторам безопасности. При использовании не разрешенного для роли метода аутентификации она будет завершена с сообщением: Authentication method "<auth_method>" isn't allowed for non security admin role "<username>". Соответствующая запись с аналогичным сообщением помещается в лог аудита как ошибка открытия соединения.

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

  примечание

  Значение по умолчанию - off. Для применения изменений, достаточно выполнить reload (SIGHUP) Pangolin.

• logical_replication_permission_policy – регулирует возможность чтения пользователем защищенных данных в логической репликации. Параметр может принимать значения:

  • protected - значение по умолчанию, когда читать репликацию можно только защищенным ролям;
  • any - любой пользователь может читать репликацию.

  Для применения изменений, достаточно выполнить команду reload (SIGHUP).

• logical_replication_policy – регулирует метод защиты сообщений, отправляемых по каналу связи. Этот параметр используется только при включенном TDE и управляется через KMS. Параметр принимает следующие значения:

  • DISABLED — запрещает логическую репликацию. Это значение по умолчанию;
  • USE_TLS — предписывает удостовериться, что установлено TLS-соединение, после чего сообщения передаются без дополнительного преобразования. При этом значении проверка наличия TLS-соединения осуществляется один раз — при попытке установить соединение для логической репликации. Если соединение не соответствует требованиям TLSv1.3, репликация завершается с ошибкой.

Параметры, внесенные под двойное управление

Параметр pg_ident_conf (карты сопоставления пользователей при авторизации) вносится под двойное управление – то есть прописывается одновременно и в хранилище секретов, и в локальном файле. При этом совпадение порядка слов не требуется.

Внимание!

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

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

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

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. Администратор безопасности (не владелец создаваемой записи) помещает объект БД, роль создаваемой учетной записи администратора безопасности, под защиту механизма защиты данных.

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

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

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

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

Создание политики защиты в СУБД 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 — действие не соответствует типу объекта

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

Для фиксации и подмены планов запросов в СУБД Pangolin используются расширения pg_outline и pg_hint_plan подробнее в подразделе «Управление планами запросов» раздела «Диагностика и планирование» документа «Руководство администратора».

Внимание!

Перед использованием расширения pg_outline рекомендуется настроить защиту от изменения таблицы outline.outlines и триггера предотвращения изменения таблицы (pg_outline_prevent_table_modification). Для этого нужно при включенной защите от привилегированных пользователей поместить под защиту таблицу outline.outlines.

Рекомендуемый набор команд для активации защиты от изменения таблицы outline.outlines:

• установите защиту таблицы:

  SELECT pm_protect_object('table', 'outline.outlines');

• создайте новую политику для предоставления доступа:

  SELECT pm_make_policy('outline_policy');

• разрешите любые изменения данных для политики. При этом прямой доступ к данным будет заблокирован триггером, который удалить нельзя:

  SELECT pm_grant_to_policy('outline_policy', 'table', 'outline.outlines', array['select','insert','update','delete']::name[]);

• примените созданную политику к роли, которая сможет задавать подмены (в данном случае — это as_admin):

  SELECT pm_assign_policy_to_user('as_admin', 'outline_policy');

  примечание

  В Pangolin по умолчанию на доступ к объектам расширения pg_hint_plan предоставлены права:

  • администратору приложения (as_admin):

    • на схемы hint_plan: USAGE,SELECT ON ALL SEQUENCES IN SCHEMA;
    • на таблицу hint_plan.hints: SELECT, INSERT, UPDATE, DELETE;

  • пользователям приложения (as_TUZ):

    • на схемы hint_plan: USAGE;
    • на таблицу hint_plan.hints: SELECT.

Поиск и исправление ошибочных записей в системных таблицах

Сведения

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

Консольное приложение admin_protection_corrector предназначено для автоматического поиска и удаления устаревших записей в системных таблицах СЗИ (система защиты информации), тем самым уменьшая потенциальное негативное влияние на работу функциональности «Защита данных от привилегированного пользователя».

Поддерживаемые аргументы

Обязательные аргументы:

-u, --username

Имя пользователя — администратора безопасности.

-w, --password

Пароль пользователя — администратора безопасности.

При отключенной функциональности «Защита данных от привилегированных пользователей» подключение происходит от суперпользователя.

-p, --port

Порт, на котором запущен экземпляр СУБД.

Сведения

По умолчанию имя пользователя, пароль и порт получаются из переменных окруженияPGUSER, PGPASSWORD и PGPORT.

Если аргументы не указаны, а переменные окружения отсутствуют, утилита запрашивает недостающие данные у пользователя.

Необязательные аргументы:

--force-fix-predef

Обновляет таблицы СЗИ и pg_proc в части функций защиты.

Сведения

Влияние аргумента--force-fix-predef:

• не влияет на отображение выводимых данных: выводятся предопределенные объекты и политики содержащие ошибки и зависимые от них гранты и правила;
• при указании аргумента происходит удаление ошибочных записей и зависимых от них грантов и правил;
• происходит обновление таблиц СЗИ pr_action и pr_object_kind и таблиц pg_proc (в части функций защиты) до текущей версии СУБД.

--force

Режим без запроса подтверждения.

--dry-run

Режим отображения невалидных записей без их фактического исправления.

--human-output

Выводит информацию о невалидных записях в человеко-читаемом формате.

Установка

Для работы с утилитой требуется установить rpm/deb-пакет компонента pangolin-security-utilities.

Сведения

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

SberLinux, РЕД ОС, CentOS

sudo dnf install pangolin-security-utilities-{product_version}-{OS}.x86_64.rpm

Astra Linux

sudo apt install pangolin-security-utilities-{product_version}_amd64.deb

Альт СП

sudo apt-get install pangolin-security-utilities-{product_version}-{OS}.x86_64.rpm

Подсказка

Пример заполненной команды:

cd distributive/utilities
sudo dnf install -y pangolin-security-utilities-6.7.6-sberlinux9.6.x86_64.rpm

Функциональные возможности

Приложение выполняет следующие действия:

1. Осуществляет проверки и составляет списки:

   1. Объектов, поставленных под защиту, при этом сами объекты отсутствуют в БД.
   2. Грантов на политики, назначенных отсутствующим пользователям.
   3. Грантов на политики, для которых отсутствует политика (также учитываются политики, которые будут удалены при выполнении работы приложения).
   4. Атрибутов объектов pr_object_attr, отсутствующих в pr_object.
   5. Защищенных объектов, для которых отсутствует pr_object_kind.
   6. Действий (pr_action), для которых отсутствует pr_object_kind.
   7. Правил (pr_rule), для которых отсутствует действие (pr_action) (также учитываются действия, которые будут удалены при выполнении работы приложения).
   8. Правил (pr_rule), для которых отсутствует политика (pr_policy) (также учитываются политики, которые будут удалены при выполнении работы приложения).
   9. Правил (pr_rule), для которых отсутствует защищенный объект (pr_object) (также учитываются объекты, которые будут удалены при выполнении работы приложения).
   10. Атрибутов политик pr_policy_attr, для которых отсутствует политика.
   11. Политик pr_policy, для которых отсутствуют атрибуты pr_policy_attr.
   12. Объектов pr_object, для которых отсутствуют атрибуты pr_object_attr.
   13. Объектов pr_object, для которых отсутствует БД datoid, при этом 0 — валидный OID.
   14. Объектов, для которых атрибут staterole содержит OID удаленной роли.
   15. Политик, для которых атрибут staterole содержит OID удаленной роли.
   16. Недостающие записи в таблице pr_action.
   17. Недостающие записи в таблице pr_object_kind.
   18. Недостающие записи в таблице pg_proc (только функции защиты).

2. Формирует список найденных ошибок и выводит его:

   • по умолчанию — в формате JSON;
   • при использовании --human-output — в альтернативном, человеко-читаемом виде.

3. При использовании аргумента --dry-run выполнение приложения завершается.

4. Приложение запрашивает подтверждение для удаления ошибочных записей (при использовании аргумента --force подтверждение не запрашивается).

5. Приложение вызывает функции:

   1. pm_get_protection_errors для получения недостающих записей в pr_action, pr_object_kind и pg_proc.
   2. pm_remove_orphaned_entry для найденных записей (пункты 1.1 – 1.13). При этом проверяется аргумент --force-remove-predef. Если аргумент не установлен, тогда для записей, у которых поле ispredef = true, функция не вызывается.
   3. pm_fix_orphaned_object_state для найденных записей (пункт 1.14).
   4. pm_fix_orphaned_policy_state для найденных записей (пункт 1.15).
   5. pm_upgrade_protection для найденных записей (пункты 1.16 – 1.18) при условии, что указан аргумент --force-fix-predef.

6. Приложение завершает работу. Решение не требует перезапуска СУБД.

Поддерживаемые функции

В приложении реализованы следующие функции защиты:

• pm_remove_orphaned_entry(name table_name, oid entry_oid, bool force_remove_predef) – удаляет из таблицы защиты table_name запись с oid entry_oid. Если параметр force_remove_predef равен false и table_name является pr_object, pr_object_attr или pr_policy, производится дополнительная проверка поля ispredef. Если ispredef равен true, запись не удаляется.
• pm_fix_orphaned_object_state(Oid entry_oid) – устанавливает в таблице pr_object_attr поля state и staterole в 0 при условии, что поле staterole содержит oid удаленного пользователя.
• pm_fix_orphaned_policy_state(Oid entry_oid) – устанавливает в таблице pr_policy_attr поля state и staterole в 0 при условии, что поле staterole содержит oid удаленного пользователя.
• pm_get_protection_errors - отображает недостающие записи из таблицы table_name. Функция работает только с таблицами pr_action, pr_object_kind и pg_proc (только функции защиты).
• pm_upgrade_protection - восстанавливает отсутствующие записи для таблиц pr_action, pr_object_kind и pg_proc (только функции защиты).

Формат вывода результатов

Результат работы приложения выводится в формате JSON.

Пример

{
	"mode": "dry-run",
	"status": "fail",
	"run_status": "success",
	"error_message": "orphaned entries found",
	"repair_required": "yes",
	"repair_level_force_required": "yes",
	"total_errors": 3,
	"errors":
	{
		"orphaned_objects": 1,
		"orphaned_policies": 0,
		"orphaned_grants": 0,
		"orphaned_object_attributes": 0,
		"orphaned_actions": 0,
		"orphaned_rules": 0,
		"orphaned_policy_attributes": 0,
		"not_existing_actions": 1,
		"not_existing_object_kinds": 1
	},
	"not_existing_object_kinds":
	[
		{
			"oid": 9966,
			"name": "view"
		}
	],
	"not_existing_actions":
	[
		{
			"oid": 9933,
			"name": "delete",
			"object_kind": 9969
		}
	],
	"orphaned_objects":
	{
		"db2":
		[
			{
				"oid": 9879,
				"kind": "function",
				"proname": "pm_disable_protection",
				"error": "not exists"
			}
		]
	}
}

Описание полей:

• mode – содержит информацию, в каком режиме запущена утилита: dry-run или full;

• status – состояние БД:

  • success – БД функционирует корректно;
  • fail – БД требует обслуживания утилитой admin_protection_corrector;
  • unknown – статус неизвестен, так как процесс отменен пользователем или завершился неудачей;

• run_status – состояние работы утилиты:

  • success – выполняется успешно;
  • fail – завершено неудачей, либо отменено пользователем;

• error_message - сообщение о завершении выполнения. Может содержать ошибки подключения к БД, ошибки выполнения функций, а также:

  • orphaned_entries_found - найдены ошибки в таблицах СЗИ;
  • cancelled by user - отменена пользователем;
  • orphaned entries corrected - ошибочные записи исправлены;
  • non predefined orphaned entries corrected - ошибочные записи исправлены, кроме предопределенных. К предопределенным записям также относятся записи в таблицах pr_action, pr_object_kind, pg_proc (с признаком ispredef) и pr_policy (с признаком ispredef);

• repair_required – требуется коррекция данных (yes / no);

• repair_level_force_required – для полной коррекции (с обновлением pr_action, pr_object_kind, pg_proc и коррекцией предопределенных объектов) требуется использование аргумента --force-fix-predef (yes / no);

• total_errors - содержит общее количество ошибок;

• errors - содержит количество ошибок по типам.

Описание полей ошибок:

• orphaned_objects – содержит базы данных и соответствующие им массивы записей защищенных объектов с найденными ошибками. Такие записи содержат поля таблицы pr_object:

  • oid – oid запись таблицы pr_object;

  • kind – тип объекта из таблицы pr_object_kind;

  • ispredef – признак, что объект/политика предопределены (из таблицы pr_object_attr);

  • proname – имя функции, которая отсутствуют в pg_proc;

  • error – содержится информация, чего именно не хватает для того, что бы запись была корректной:

    • object – в БД отсутствует защищаемый объект;
    • database – отсутствует БД в которой должен находиться защищаемый объект;
    • attribute – в таблице pr_object_attr отсутствует соответствующая запись;
    • kind – в таблице pr_object_kind отсутствует соответствующий тип объекта;

• orphaned_policies – содержит список политик (pr_policy), для которых не найдены соответствующие записи в pr_policy_attr;

• orphaned_grants – содержит список грантов (pr_grant), для которых обнаружены несоответствия:

  • role – указана несуществующая роль;
  • policy – указана несуществующая политика;

• orphaned_object_attributes – содержит ошибочные записи в таблице pr_object_attr:

  • role - указан отсутствующий пользователь;

  Если объект содержит только oid записи – отсутствует соответствующая запись в pr_object.

• orphaned_actions – содержит записи pr_action для которых указаны несуществующие записи pr_object_kind;

• orphaned_rules – содержит записи, для которых найдены следующие несоответствия:

  • policy – указана несуществующая политика;
  • object – указан несуществующий объект;
  • action – указано несуществующее действие;

• orphaned_policy_attributes – содержит записи для которых:

  • role - указана несуществующая роль.

  Если объект содержит только oid записи – отсутствует соответствующая запись в pr_policy.

• not_existing_object_kinds – отсутствующие записи в таблице pr_object_kind:

  • oid – oid запись таблицы pr_object_kind;
  • name – тип объекта;

• not_existing_actions – отсутствующие записи в таблице pr_action:

  • oid – oid запись pr_action;
  • name – действие;
  • object_kind – oid типа объекта.

Режимы работы

Поддерживаемые режимы:

• --dry-run – отображает ошибки, не меняет данные.
• --force – выполняет исправления без запроса подтверждения.
• --human-output – отображает ошибки в человеко-понятном формате, вместо JSON.

Примеры использования

Выполнение в режиме отображения ошибки, без изменения данных:

admin_protection_corrector -u sec_admin -p 5433 --dry-run

Выполнение с подавлением запроса подтверждения:

admin_protection_corrector -u sec_admin -w password -p 5433 --force

Выполнение с аргументом --force-predef-remove:

admin_protection_corrector -u sec_admin -p 5433 --force-predef-remove

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

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

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

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

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

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

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)