Защита от привилегированных пользователей. Разграничение доступа к данным. Управление политиками безопасности

Описание

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

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

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

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

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

Включение механизма защиты данных от привилегированных пользователей в Platform V Pangolin возможно с использованием хранилища секретов в HashiCorp Vault или KMS-заменителя. Подробнее оба сценария рассматриваются в разделах «Включение механизма защиты данных от привилегированных пользователей с использованием хранилища секретов в HashiCorp Vault» и «Включение механизма защиты данных от привилегированных пользователей с использованием KMS-заменителя» соответственно.

Структура ролей

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

Начиная с версии СУБД Pangolin 5.4.0 конфигурирование ролевой модели вынесено из инсталлятора. Ее конфигурирование опционально и может быть выполнено с помощью инсталляционных скриптов конфигурирования ролевой модели (см. раздел «Конфигурирование ролевой модели»), включенных в состав дистрибутива. При необходимости данные скрипты могут быть модифицированы (например, в случае, если в какой-либо функциональности нет необходимости), либо заменены альтернативной ролевой моделью.

В рамках структуры ролей рассматриваются следующие типы:

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

При настройке ролевой модели создаются следующие групповые роли:

Групповая роль	Назначение
`db_admin`	Административная роль, обладающая привилегией `superuser`. Владелец TABLESPACE, DATABASE. Выдается администраторам для управления СУБД
`as_admin`	Административная роль — владелец схемы. Выдается администраторам АС. Используется для создания новых объектов в БД (таблиц, функций, последовательностей и т.п) и их изменения. Является владельцем пользовательской схемы. Также выдается доменным или локальным ТУЗ для инструментов автоматизации
`as_TUZ`	Прикладная роль для доступа к пользовательским данным. Имеет привилегии для совершения DML-операций с объектами схемы. Работает в пуле соединений с БД, а также подключается через Pangolin Pooler
`as_admin_read`	Административная роль, отличающаяся от `as_admin` тем, что предназначена только для просмотра
`all-sa-pam-group`	Выдается учетным записям, используемым для доступа через PAM (privileged access management). Используется исключительно для организации аутентификации, конфигурирования `pg_hba.conf`

Дополнительно создаются следующие специальные инфраструктурные ТУЗ:

Инфраструктурная роль	Назначение
`backup_user`	ТУЗ с локальной аутентификации для интеграции с СРК
`zabbix_oasubd`	ТУЗ с локальной аутентификацией для интеграции с системой мониторинга
`auditor`	ТУЗ с локальной аутентификацией для проведения аудита безопасности
`pangolin-pooler`	ТУЗ с локальной аутентификацией для подключения локальной службы Pangolin Pooler
`pangolin-manager`	ТУЗ с локальной аутентификацией для подключения локальной службы Pangolin Manager
`all-sa-pam19002`	ТУЗ с внешней аутентификацией для подключения через АС PAM администраторов БД
`all-sa-pam19002_ro`	ТУЗ с внешней аутентификацией для подключения через АС PAM администраторов систем с привилегиями только на чтение

Рекомендации по работе с УЗ для администраторов:

ежедневные задачи администрирования силами администраторов «вручную» должны осуществляться только под персонализированными УЗ;
права доступа для каждой УЗ/ТУЗ должны быть минимизированы, исходя из использования;
в руководство должно включаться рекомендуемое минимальное типовое конфигурирование ролевой модели (РМ);
при развертывании нового экземпляра СУБД Pangolin, минимальная рекомендуемая типовая РМ должна конфигурироваться автоматически.

Матрица несовместимости ролей

В таблице используются обозначения уровней совместимости:

Н - не совместимо;
Н/Ж - нежелательно;
С - совместимо.

	sec_admin_role (администратор безопасности)	superuser (администратор БД, включая `postgres`)	Роли RBAC PostgreSQL
`sec_admin_role` (администратор безопасности)		Н	Н
`superuser` (администратор БД, включая `postgres`)	Н		С
Роли RBAC PostgreSQL	Н	С

Операции, которые не должны выполняться одним лицом

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

Выполнение общих настроек, влияющих на возможность несанкционированного доступа к передаваемой или хранимой информации:
- настройки защиты сетевых соединений;
- настройки состава загружаемых модулей расширения;
- настройки состава доверенных серверов аутентификации;
- настройки включения прозрачного защитного преобразования данных (TDE).
Управление доступом к объектам баз данных, содержащих конфиденциальную или секретную информацию.

Внимание!

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

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

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

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

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

Связь ролей с объектами БД

При настройке ролевой модели создаются стандартные объекты БД и назначается привилегии для их использования. Такими объектами являются:

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

Табличное пространство создается в директории /pgdata/<номер мажорной версии продукта>/tablespaces/ (может различаться в зависимости от мажорной версии). Владельцем табличного пространства является db_admin, а права на доступ выдаются роли as_admin.

В дополнение к стандартным базам данных Postgresql (template0, template1, postgres) создается пользовательская БД. Владелец данной БД — db_admin. Права на использование (USAGE) и логин на данную БД есть по умолчанию у всех вновь создаваемых ролей.

Схема и объекты схемы

Владельцем пользовательской схемы является as_admin. Права на использование схемы выдаются роли as_TUZ.

Для использования схемы предоставляются две привилегии: USAGE и CREATE. Для создания новых объектов в схеме нужна привилегия CREATE. Для обращения к объектам схемы (при условии, что есть права на них) нужна привилегия USAGE. Привилегия CREATE есть только у роли as_admin.

Внутри схемы хранятся объекты БД (таблицы, индексы, функции, и т.п). Для каждого типа объекта существует свой набор привилегий. Владельцем объекта становится роль, активная в момент выдачи SQL-запроса на его создание. Так как требуется, чтобы владельцем объектов БД была групповая роль as_admin, то для обеспечения данного условия используются следующие механизмы:

При создании объектов администратор, выполняющий данную задачу, должен выдавать команду SET ROLE as_admin. Для автоматизации некоторых задач, а также в случае, когда другие роли данной УЗ не используются, можно один раз настроить УЗ для работы в роли as_admin, выдав ALTER ROLE <rolename> SET ROLE as_admin. В дальнейшем данная УЗ всегда будет работать как as_admin.
Владельцем объектов может быть только групповая роль, поэтому в УЗ администраторов, имеющих права на создание объектов отключена опция INHERIT. Для конечных пользователей БД (ТУЗ) отключать INHERIT не требуется — они не имеют привилегий на создание объектов, но зато автоматически наследуют все другие необходимые привилегии.

Роль as_admin, которая имеет привилегию на создание объектов, нельзя унаследовать (она имеет свойство NOINHERIT). Это связано с тем, что на момент инсталляции неизвестно, какие пользователи будут работать с БД в дальнейшем и какие привилегии им будут назначены. Групповые роли позволяют систематизировать пользовательскую структуру. А для того, чтобы владельцем объекта становилась именно роль as_admin, необходимо явно переключаться на нее с помощью запроса: SET ROLE as_admin.
После создания объекта роль as_admin предоставляет необходимую привилегию роли, использующей объект (это в первую очередь as_TUZ). Данный процесс можно облегчить, если назначить default privileges создающей роли (as_admin). С помощью default privileges права заранее предоставляются на объекты, которые будут создаваться в будущем в данной схеме.

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

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

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

Внимание!

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

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

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

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

Примечание:

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

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

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

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

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

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

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

Данная функциональность требует наличия установленного и интегрированного решения Key/Secret Management System (SecMan) и выделенной роли администратора безопасности. В продукте Platform V Pangolin реализована интеграция с KMS HashiCorp Vault.

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

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

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

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

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

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

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

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

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

Настройка

Первоначальная настройка

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

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

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

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

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

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

chown root:kmadmin_pg {{ PGHOME }}/bin/initprotection
#,где {{ PGHOME }} - пусть до инсталляционных файлов postgresql se (например: /usr/pgsql-se-05)

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

kmadmin_pg ALL = (postgres : kmadmin_pg) NOPASSWD: /bin/bash -c {{ PGHOME }}/bin/initprotection

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

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

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

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

{{ PGHOME }}/bin/initprotection -D {{ PGDATA }} -U sec_admin

Утилита позволяет создавать более одной учетной записи администраторов безопасности при инициализации механизма защиты. Учетные записи перечисляются в параметре -U, через запятую. Хеши паролей учетных записей перечисляются в параметре -P, в порядке соответствия логинам, либо же, если параметр отсутствует - запрашивается ввод пароля у пользователя. Количество хешей паролей, переданных с командной строки, должно соответствовать количеству переданных логинов. Принимаются только хеши паролей в формате scram-sha-256.

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

при запуске утилиты для экземпляра PostgreSQL с ранее инициализированным каталогом безопасности утилита выводит сообщение о том, что каталог безопасности находится не в ожидаемом состоянии;
создает групповую роль администраторов безопасности 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 хеша.

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

SELECT check_admin_protect_is_on();
 check_admin_protect_is_on
---------------------------
 t
(1 row)

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

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

Действия с политиками:
- 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 - удаление политики защиты.
Действия с пользователями:
- pm_get_assigned_policies - вывод списка политик, назначенных пользователю;
- pm_assign_policy_to_user - назначение политики пользователю;
- pm_unassign_policy_from_user - изъятие политики у пользователя.
Действия над объектами:
- pm_get_protected_objects - вывод списка объектов, находящихся под защитой;
- pm_protect_object - помещение объекта БД под защиту;
- pm_unprotect_object - снятие защиты с объекта БД;
- pm_get_object_access_path - получение информации об эффективных действующих для указанных объекте и роли ограничениях защиты и разрешениях на доступ к объекту под защитой.
Действия для администраторов безопасности:
- pm_create_security_admin - создание учетной записи администратора безопасности;
- pm_set_security_admin_password - изменение пароля учетной записи администратора безопасности;
- pm_grant_security_admin - назначение пользователя администратором безопасности;
- pm_revoke_security_admin - снятие с пользователя политики администратора безопасности;
- pm_unblock_security_admin - разблокировка заблокированной учетной записи администратора безопасности.

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

Управление

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

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

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

diag

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

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

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

Администратор безопасности изымает привилегии администратора безопасности у удаляемой учетной записи.
Администратор безопасности исключает роль удаляемой учетной записи из-под защиты.
Администратор PostgreSQL удаляет учетную запись из PostgreSQL.

diag

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

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

diag

Рисунок «Создание политики защиты»

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

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

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

diag

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

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

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

diag

Рисунок «Изъятие привилегий на данные ТУЗ»

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

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

diag

Рисунок «Удаление политики защиты»

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

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

diag

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

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

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

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

Владелец ТУЗ или администратор безопасности инициирует процесс изменения пароля.
Администратор безопасности снимает политики, дающие учетной записи доступ к защищаемым данным.
Администратор безопасности изменяет pg_hba.conf в защищенном хранилище, отключая требование двухфакторной аутентификации для учетной записи.
Администратор безопасности исключает роль учетной записи из-под защиты механизма защиты данных.
Владелец ТУЗ устанавливает новый пароль: если изменение пароля ТУЗ было инициировано администратором безопасности, то сначала новый пароль устанавливает администратор PostgreSQL, затем – владелец ТУЗ.
Администратор безопасности изменяет pg_hba.conf в защищенном хранилище, включая требование двухфакторной аутентификации для учетной записи.
Администратор безопасности помещает роль учетной записи под защиту механизма защиты данных.
Администратор безопасности назначает политики, дающие учетной записи доступ к защищаемым данным.

diag

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

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

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

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

diag

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

Важно

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

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

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

diag

Рисунок «Изъятие объекта БД из-под защиты»

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

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

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

Возможность ротации секретов ТУЗ без недоступности

При смене пароля пользователь на определенное настройками время (grace-период) может подключаться к Pangolin по старому паролю. Это позволит реализовать автоматическую ротацию паролей ТУЗ, которые используют приложения, не ограничивая их доступность. После ротации паролей ТУЗ приложения продолжают работу с Pangolin, используя старый пароль, который необходимо обновить в течение заданного grace-периода.

Создание политик безопасности

В данном разделе описан процесс создания политик безопасности и применения их к различным объектам.

Предварительные шаги:

Откройте сессию под пользователем postgres:
```
psql
```

Создайте четыре новых пользователей от имени пользователя postgres:

postgres=# CREATE USER stas WITH LOGIN PASSWORD 'PASSWORD';
CREATE ROLE

postgres=# CREATE USER sveta WITH LOGIN PASSWORD 'PASSWORD';
CREATE ROLE

postgres=# CREATE USER sasha WITH LOGIN PASSWORD 'PASSWORD';
CREATE ROLE

postgres=# CREATE USER katya WITH LOGIN PASSWORD 'PASSWORD';
CREATE ROLE

Выйдите из-под пользователя postgres:
```
\q
```
Зайдите под пользователем sec_admin:
```
PGPASSWORD='PASSWORD' psql -U sec_admin
```
Назначьте двум созданным пользователям политики администраторов безопасности, тем самым добавив их в групповую роль sec_admin:
```
SELECT pm_grant_security_admin('stas');
pm_grant_security_admin
-------------------------
t
(1 row)

SELECT pm_grant_security_admin('sveta');
pm_grant_security_admin
-------------------------
t
(1 row)
```
Выйдите из-под пользователя sec_admin:
```
\q
```
Зайдите под пользователем postgres:
```
psql
```
Проверьте, что новые пользователи действительно входят в групповую роль администраторов безопасности:
```
SELECT member::regrole FROM pg_catalog.pg_auth_members WHERE roleid='sec_admin_role'::regrole;

    member
---------------------
sec_admin_backup
sec_admin
sec_admin_script
stas
sveta
(5 rows)
```
Создайте схему:
```
CREATE SCHEMA krasnay;
CREATE SCHEMA
```

Создайте две таблицы в схеме:

CREATE TABLE krasnay.table1(id INT, data TEXT,coeff VARCHAR(3));
CREATE TABLE

CREATE TABLE krasnay.table2(id INT, data TEXT,coeff VARCHAR(3));
CREATE TABLE

Дайте права на схему двум пользователям, не входящим в группу администраторов безопасности:
```
GRANT USAGE ON SCHEMA krasnay TO sasha;

postgres=# GRANT USAGE ON SCHEMA krasnay TO katya;
```
Выйдите из-под пользователя postgres:
```
\q
```

Создание политики безопасности на объекты через групповую роль (первый тестовый администратор безопасности)

Зайдите под первым тестовым администратором безопасности:
```
PGPASSWORD='PASSWORD' psql -U stas
```

Возьмите схему и тестовые таблицы под защиту:

SELECT pm_protect_object('schema','krasnay');
pm_protect_object
-------------------
t
(1 row)

SELECT pm_protect_object('table','krasnay.table1');
pm_protect_object
-------------------
t
(1 row)

postgres=> SELECT pm_protect_object('table','krasnay.table2');
pm_protect_object
-------------------
t
(1 row)

Создайте две парольные политики:

SELECT pm_make_policy('policy1');
pm_make_policy
----------------
t
(1 row)

SELECT pm_make_policy('policy11');
pm_make_policy
----------------
t
(1 row)

Наполните созданные политики разрешениями на действиями над первой таблицей:

SELECT pm_grant_to_policy('policy1', 'table', 'krasnay.table1', array['update', 'insert']::name[]);

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

SELECT pm_grant_to_policy('policy11', 'table', 'krasnay.table1', array['update', 'insert']::name[]);

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

Назначьте обычным тестовым пользователям по одной из созданных политик:

SELECT pm_assign_policy_to_user('sasha', 'policy1');
pm_assign_policy_to_user
--------------------------
t
(1 row)

SELECT pm_assign_policy_to_user('katya', 'policy11');
pm_assign_policy_to_user
--------------------------
t
(1 row

Выйдите из-под первого тестового администратора безопасности:
```
\q
```

Создание политики безопасности на объекты через групповую роль (второй тестовый администратор безопасности)

Зайдите под вторым тестовым администратором безопасности:
```
PGPASSWORD='PASSWORD' psql -U sveta
```

Создайте две парольные политики:

SELECT pm_make_policy('policy2');
pm_make_policy
----------------
t
(1 row)

SELECT pm_make_policy('policy22');
pm_make_policy
----------------
t
(1 row)

Наполните созданные политики разрешениями на действия над второй тестовой таблицей:

SELECT pm_grant_to_policy('policy2', 'table', 'krasnay.table2', array['update', 'insert']::name[]);

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

SELECT pm_grant_to_policy('policy22', 'table', 'krasnay.table2', array['update', 'insert']::name[]);

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

Назначьте обычным тестовым пользователям по одной из созданных политик:

SELECT pm_assign_policy_to_user('sasha', 'policy2');
pm_assign_policy_to_user
--------------------------
t
(1 row)

SELECT pm_assign_policy_to_user('katya', 'policy22');
pm_assign_policy_to_user
--------------------------
t
(1 row)

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

SELECT pm_get_policies();

pm_get_policies
----------------------------
(securityFunctionsAdmin,t)
(securityCatalogAdmin,t)
(secAdminUser,t)
(policy1,f)
(policy11,f)
(policy2,f)
(policy22,f)
(7 rows)

Просмотрите права в каждой политике:

SELECT pm_get_policy_grants('policy1');

        pm_get_policy_grants
------------------------------------------------------
(5,postgres,27434,27435,krasnay.table1,table,update)
(5,postgres,27434,27435,krasnay.table1,table,insert)
(2 rows)

SELECT pm_get_policy_grants('policy11');
        pm_get_policy_grants
------------------------------------------------------
(5,postgres,27434,27435,krasnay.table1,table,update)
(5,postgres,27434,27435,krasnay.table1,table,insert)
(2 rows)

SELECT pm_get_policy_grants('policy22');
        pm_get_policy_grants
------------------------------------------------------
(5,postgres,27434,27440,krasnay.table2,table,update)
(5,postgres,27434,27440,krasnay.table2,table,insert)
(2 rows)

SELECT pm_get_policy_grants('policy2');
        pm_get_policy_grants
------------------------------------------------------
(5,postgres,27434,27440,krasnay.table2,table,update)
(5,postgres,27434,27440,krasnay.table2,table,insert)
(2 rows)

Просмотрите политики каждого обычного тестового пользователя:

SELECT pm_get_assigned_policies('sasha');
pm_get_assigned_policies
--------------------------
(27448,policy1)
(27458,policy2)
(2 rows)

SELECT pm_get_assigned_policies('katya');
pm_get_assigned_policies
--------------------------
(27449,policy11)
(27459,policy22)
(2 rows)

Выйдите из-под второго тестового администратора безопасности:
```
\q
```

Изменение политики от основного администратора безопасности

Зайдите под основным администратором безопасности:
```
PGPASSWORD='PGPASSWORD' psql -U sec_admin
```

Измените одну из политик безопасности:

SELECT pm_grant_to_policy('policy22', 'table', 'krasnay.table2', array['update']::name[]);

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

Содержание политики изменилось:

SELECT pm_get_policy_grants('policy22');

        pm_get_policy_grants
------------------------------------------------------
(5,postgres,27434,27440,krasnay.table2,table,update)
(5,postgres,27434,27440,krasnay.table2,table,insert)
(2 rows)

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

SELECT pm_get_object_access_path('table', 'krasnay.table1', 'sasha');

              pm_get_object_access_path
------------------------------------------------------------------------------------
(table,krasnay.table1,sasha,move,0,revoked,,,,)
(table,krasnay.table1,sasha,move,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,move,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,drop_trigger,0,revoked,,,,)
(table,krasnay.table1,sasha,drop_trigger,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,drop_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,drop_rule,0,revoked,,,,)
(table,krasnay.table1,sasha,drop_rule,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,drop_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,select,0,revoked,,,,)
(table,krasnay.table1,sasha,select,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,select,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,insert,0,granted,,,,)
(table,krasnay.table1,sasha,insert,1,granted,policy1,,,active)
(table,krasnay.table1,sasha,insert,2,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,insert,3,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,update,0,granted,,,,)
(table,krasnay.table1,sasha,update,1,granted,policy1,,,active)
(table,krasnay.table1,sasha,update,2,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,update,3,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,delete,0,revoked,,,,)
(table,krasnay.table1,sasha,delete,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,delete,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,alter,0,revoked,,,,)
(table,krasnay.table1,sasha,alter,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,alter,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,drop,0,revoked,,,,)
(table,krasnay.table1,sasha,drop,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,drop,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,create_trigger,0,revoked,,,,)
(table,krasnay.table1,sasha,create_trigger,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,create_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,alter_trigger,0,revoked,,,,)
(table,krasnay.table1,sasha,alter_trigger,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,alter_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,create_rule,0,revoked,,,,)
(table,krasnay.table1,sasha,create_rule,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,create_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,alter_rule,0,revoked,,,,)
(table,krasnay.table1,sasha,alter_rule,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,alter_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,sasha,all,0,revoked,,,,)
(table,krasnay.table1,sasha,all,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,sasha,all,2,revoked,,schema,krasnay,active)
(44 rows)

SELECT pm_get_object_access_path('table', 'krasnay.table2', 'sasha');
              pm_get_object_access_path
------------------------------------------------------------------------------------
(table,krasnay.table2,sasha,move,0,revoked,,,,)
(table,krasnay.table2,sasha,move,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,move,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,drop_trigger,0,revoked,,,,)
(table,krasnay.table2,sasha,drop_trigger,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,drop_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,drop_rule,0,revoked,,,,)
(table,krasnay.table2,sasha,drop_rule,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,drop_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,select,0,revoked,,,,)
(table,krasnay.table2,sasha,select,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,select,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,insert,0,granted,,,,)
(table,krasnay.table2,sasha,insert,1,granted,policy2,,,active)
(table,krasnay.table2,sasha,insert,2,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,insert,3,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,update,0,granted,,,,)
(table,krasnay.table2,sasha,update,1,granted,policy2,,,active)
(table,krasnay.table2,sasha,update,2,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,update,3,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,delete,0,revoked,,,,)
(table,krasnay.table2,sasha,delete,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,delete,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,alter,0,revoked,,,,)
(table,krasnay.table2,sasha,alter,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,alter,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,drop,0,revoked,,,,)
(table,krasnay.table2,sasha,drop,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,drop,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,create_trigger,0,revoked,,,,)
(table,krasnay.table2,sasha,create_trigger,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,create_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,alter_trigger,0,revoked,,,,)
(table,krasnay.table2,sasha,alter_trigger,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,alter_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,create_rule,0,revoked,,,,)
(table,krasnay.table2,sasha,create_rule,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,create_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,alter_rule,0,revoked,,,,)
(table,krasnay.table2,sasha,alter_rule,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,alter_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,sasha,all,0,revoked,,,,)
(table,krasnay.table2,sasha,all,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,sasha,all,2,revoked,,schema,krasnay,active)
(44 rows)

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

SELECT pm_get_object_access_path('table', 'krasnay.table1', 'katya');
              pm_get_object_access_path
------------------------------------------------------------------------------------
(table,krasnay.table1,katya,move,0,revoked,,,,)
(table,krasnay.table1,katya,move,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,move,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,drop_trigger,0,revoked,,,,)
(table,krasnay.table1,katya,drop_trigger,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,drop_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,drop_rule,0,revoked,,,,)
(table,krasnay.table1,katya,drop_rule,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,drop_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,select,0,revoked,,,,)
(table,krasnay.table1,katya,select,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,select,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,insert,0,granted,,,,)
(table,krasnay.table1,katya,insert,1,granted,policy11,,,active)
(table,krasnay.table1,katya,insert,2,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,insert,3,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,update,0,granted,,,,)
(table,krasnay.table1,katya,update,1,granted,policy11,,,active)
(table,krasnay.table1,katya,update,2,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,update,3,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,delete,0,revoked,,,,)
(table,krasnay.table1,katya,delete,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,delete,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,alter,0,revoked,,,,)
(table,krasnay.table1,katya,alter,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,alter,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,drop,0,revoked,,,,)
(table,krasnay.table1,katya,drop,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,drop,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,create_trigger,0,revoked,,,,)
(table,krasnay.table1,katya,create_trigger,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,create_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,alter_trigger,0,revoked,,,,)
(table,krasnay.table1,katya,alter_trigger,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,alter_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,create_rule,0,revoked,,,,)
(table,krasnay.table1,katya,create_rule,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,create_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,alter_rule,0,revoked,,,,)
(table,krasnay.table1,katya,alter_rule,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,alter_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table1,katya,all,0,revoked,,,,)
(table,krasnay.table1,katya,all,1,revoked,,table,krasnay.table1,active)
(table,krasnay.table1,katya,all,2,revoked,,schema,krasnay,active)
(44 rows)

SELECT pm_get_object_access_path('table', 'krasnay.table2', 'katya');
                 pm_get_object_access_path
------------------------------------------------------------------------------------
(table,krasnay.table2,katya,move,0,revoked,,,,)
(table,krasnay.table2,katya,move,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,move,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,drop_trigger,0,revoked,,,,)
(table,krasnay.table2,katya,drop_trigger,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,drop_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,drop_rule,0,revoked,,,,)
(table,krasnay.table2,katya,drop_rule,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,drop_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,select,0,revoked,,,,)
(table,krasnay.table2,katya,select,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,select,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,insert,0,granted,,,,)
(table,krasnay.table2,katya,insert,1,granted,policy22,,,active)
(table,krasnay.table2,katya,insert,2,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,insert,3,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,update,0,granted,,,,)
(table,krasnay.table2,katya,update,1,granted,policy22,,,active)
(table,krasnay.table2,katya,update,2,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,update,3,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,delete,0,revoked,,,,)
(table,krasnay.table2,katya,delete,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,delete,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,alter,0,revoked,,,,)
(table,krasnay.table2,katya,alter,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,alter,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,drop,0,revoked,,,,)
(table,krasnay.table2,katya,drop,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,drop,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,create_trigger,0,revoked,,,,)
(table,krasnay.table2,katya,create_trigger,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,create_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,alter_trigger,0,revoked,,,,)
(table,krasnay.table2,katya,alter_trigger,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,alter_trigger,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,create_rule,0,revoked,,,,)
(table,krasnay.table2,katya,create_rule,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,create_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,alter_rule,0,revoked,,,,)
(table,krasnay.table2,katya,alter_rule,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,alter_rule,2,revoked,,schema,krasnay,active)
(table,krasnay.table2,katya,all,0,revoked,,,,)
(table,krasnay.table2,katya,all,1,revoked,,table,krasnay.table2,active)
(table,krasnay.table2,katya,all,2,revoked,,schema,krasnay,active)
(44 rows)

Переназначение прав для непривилегированных пользователей

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

Описание сервиса

Параметр systemctl_unit_on_user конфигурационного файла утилиты установки отвечает за расположение unit-файлов компонентов Pangolin в пользовательской директории postgres и kmadmin_pg. Если данный параметр будет включен, то установка unit-файлов компонентов производится в директорию /home/user_name/.config/systemd/user. В случае, когда параметр выключен, установка производится в системную директорию сервисов /etc/systemd/system/, а для редактирования и управления файлами необходимы права привилегированного пользователя.

После создания пользователей kmadmin_pg и postgres необходимо вызвать команды:

loginctl enable-linger postgres
loginctl enable-linger kmadmin_pg

Запуск будет осуществляться за счет добавления в .bash_profile пользовательских окружений postgres и kmadmin_pg следующих переменных:

export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

Для запуска/остановки/перезагрузки службы при вызове systemctl утилиты требуется дополнительный аргумент --user:

systemctl --user start postgresql
systemctl --user stop postgresql
systemctl --user restart postgresql

В зависимости от включения функциональности видоизменяется unit-файл компонентов.

Пример включенной функциональности с расположением unit-файла в пользовательском каталоге:

[Unit]
Description=Runners to orchestrate a high-availability PostgreSQL
After=syslog.target network.target

[Service]
Type=simple

# Read in configuration file if it exists, otherwise proceed

Environment="PG_LICENSE_PATH=/opt/pangolin_license"
Environment="PG_LD_LIBRARY_PATH=/opt/pangolin-dbms/lib"
Environment="PG_PLUGINS_PATH=/opt/pangolin-dbms/lib"
Environment="PATRONI_PLUGINS_PATH=/opt/pangolin-manager/lib/postgresql_se_libs"
Environment="LD_LIBRARY_PATH=/opt/pangolin-manager/lib/postgresql_se_libs"
Environment="PYTHONPATH=/opt/pangolin-manager/lib/python3/site-packages:/opt/pangolin-manager/lib64/python3/site-packages:/opt/pangolin-manager/lib/python3.6/site-packages:/opt/pangolin-manager/lib64/python3.6/site-packages"
LimitNOFILE=65536

# Pre-commands to start watchdog device
# Uncomment if watchdog is part of your patroni setup
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /run/user/1004/postgresql
ExecStartPre=/bin/chown -R postgres:postgres /run/user/1004/postgresql
ExecStartPre=-/bin/mkdir -p /run/user/1004/pangolin-dbms
ExecStartPre=/bin/chown -R postgres:postgres /run/user/1004/pangolin-dbms
ExecReload=/bin/kill -HUP $MAINPID

WorkingDirectory=/opt/pangolin-manager
ExecStart=/opt/pangolin-manager/bin/pangolin-manager-bin/pangolin-manager.bin /etc/pangolin-manager/postgres.yml
Restart=on-failure
KillMode=process

# Disable restart limits
StartLimitInterval=0

[Install]
WantedBy=default.target

Пример файла sudoerc при включенной функциональности:

postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl daemon-reload
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status rsyslog -l
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status rsyslog --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable rsyslog
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status etcd -l
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status etcd --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable etcd
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u etcd

Файл sudoerc при выключенной функциональности:

postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl daemon-reload
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status rsyslog -l
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status rsyslog --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable rsyslog
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable rsyslog
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u rsyslog
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl reload pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pg_certs_rotate_agent --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable pg_certs_rotate_agent
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pg_certs_rotate_agent -l
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin_reencrypt@postgres --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable pangolin_reencrypt@postgres
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin_reencrypt@postgres -l
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl reload pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pgbouncer --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pgbouncer -l
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u pgbouncer
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl reload pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin-pooler --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin-pooler -l
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u pangolin-pooler
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl reload pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin-manager -l
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status pangolin-manager --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u pangolin-manager
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl stop etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl start etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl restart etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status etcd -l
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl status etcd --no-pager --full
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl enable etcd
postgres ALL=(ALL) NOPASSWD:  /usr/bin/systemctl disable etcd
postgres ALL=(ALL) NOPASSWD:  /bin/journalctl -u etcd

Главное отличие журнала sudoerc при выключенной функциональности относительно выключенного состояния является меньшее количество команд, требующих прав привилегированного пользователя, как следствие меньший объем журнала. Это связано с тем, что при включенной функциональности unit-файлы находятся в пользовательском каталоге, для которого дополнительные привилегии не требуются.

Изменения в .bash_profile:

alias members='ETCDCTL_API=3 etcdctl --endpoints=<server_name>:<port> --cert="/pg_ssl/etcd.crt" --key="/pg_ssl/etcd.key" --cacert="/pg_ssl/root.crt" member list -w table'
alias elist='ETCDCTL_API=3 etcdctl --endpoints=<server_name>:<port> --cert="/pg_ssl/etcd.crt" --key="/pg_ssl/etcd.key" --cacert="/pg_ssl/root.crt" endpoint status -w table --cluster'
alias elog='journalctl --user-unit etcd'
alias health='ETCDCTL_API=2 etcdctl --endpoints https://<server_name>:<port> --cert-file /pg_ssl/etcd.crt --key-file /pg_ssl/etcd.key --ca-file /pg_ssl/root.crt cluster-health 2>&1'

export PG_LICENSE_PATH=/opt/pangolin_license
export LD_LIBRARY_PATH=/usr/pangolin-6.5.0/lib
export PATH=$PATH:/usr/pangolin-6.5.0/bin
export PG_PLUGINS_PATH=/usr/pangolin-6.5.0/lib
export PGHOME=/usr/pangolin-6.5.0
export PGDATABASE=postgres
export PGUSER=postgres
export PGHOST={IP-адрес}
export PGPORT={Порт}
export PGCLIENTENCODING=UTF8
NOW=$(date +"%Y-%m-%d")
export PGDATA=/pgdata/6.5.0/data
export MANPATH=$MANPATH:$PGHOME/share/man
alias errors="ls -t /pgerrorlogs/6.5.0/postgresql-$NOW*.log | head -1 | xargs tail -F | grep -E 'WARNING|ERROR|FATAL|ПРЕДУПРЕЖДЕНИЕ|ОШИБКА|ВАЖНО'"
alias hba='vim $PGDATA/pg_hba.conf'
alias pglog='ls -t /pgerrorlogs/6.5.0/postgresql-$NOW*.log | head -1 | xargs tail -300'
alias pgver="psql -c 'select version();' | sed \"s| on | (\$(psql --single-line --no-align -c 'select product_version();' | sed '2q;d' )) on |\""
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
export PATH=$PATH:/opt/pangolin-manager/bin/
umask 022
export PATH=$PATH:/opt/pangolin-manager/bin/
export CLNAME=clustername
alias fail='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml failover $CLNAME'
alias hist='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml history $CLNAME'
alias list='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list $CLNAME'
alias pgconfig='curl -s -m 3 https://<server_name>:<port>/config | jq'
alias ptlog='journalctl --user-unit pangolin-manager.service'
alias ptver="pangolin-manager-ctl version"
alias reload='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml reload $CLNAME'
alias restart='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml restart $CLNAME'
alias status='sudo systemctl status pangolin-manager --no-pager --full'
alias switch='pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml switchover $CLNAME'

При установке вне утилиты развертывания Pangolin через отдельные rpm-пакеты компонентов используется параметр environment SYSTEMD_UNIT_IN_USER, который по умолчанию имеет значение false, что равноценно параметру утилиты развертывания systemctl_unit_on_user. Cервисный файл pangolin-manager будет расположен в пользовательской директории postgres и будет готов к запуску.

Пример включения функциональности:

sudo SYSTEMD_UNIT_IN_USER=true yum install pangolin-manager-venv
sudo SYSTEMD_UNIT_IN_USER=true yum install pangolin-manager

Для pangolin-manager журнал логирования из journalctl перенаправляется в файл, а также добавляется ротация удаления данных файлов. Путь к хранимым логам будет расположен по пути логирования pangolin-dbms:

log:
  dir: /pgerrorlogs/major_version/
  file_size: 26214400
  file_num: 4

Ограничения

Ограничения функциональности:

Для некоторых файлов владелец (owner) не сможет быть изменен на postgres:postgres (например, для /etc/postgres/enc_util.cfg, так как данный файл отвечает за хранилище паролей и не может быть изменен пользователем).
Функциональность не применима при работе с RHEL 7, так как в данной версии ОС используется старая версия утилиты systemd, где отсутствуют параметры --user.
В процессе обновления продукта до конечной версии, сервисные файлы не будут переноситься в пользовательский каталог при включении параметра systemd_unit_on_user. Их расположение не изменится.
Для чтения журнала journalctl нужно будет отдельно от утилиты установки/обновления Pangolin добавлять пользовательскую группу systemd-journal:
- usermod -aG systemd-journal postgres;
- usermod -aG systemd-journal kmadmin_pg.
Расположение pid-файлов компонентов ограничено пользовательской директорией /var/run/user/$(id -u)/.
Компонент etcd не будет изменять расположение службы.

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

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

таблиц:
- 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.

Удаление тестовых объектов

Под пользователем sec_admin изъять политики у обычных тестовых пользователей:

SELECT pm_unassign_policy_from_user('sasha', 'policy1');

SELECT pm_unassign_policy_from_user('sasha', 'policy2');

SELECT pm_unassign_policy_from_user('katya', 'policy11');

SELECT pm_unassign_policy_from_user('katya', 'policy22');

После выполнения каждого запроса выводится сообщение:
```
pm_unassign_policy_from_user
------------------------------
t
(1 row)
```

Удалите политики безопасности:

SELECT pm_remove_policy('policy1');

SELECT pm_remove_policy('policy2');

SELECT pm_remove_policy('policy11');

SELECT pm_remove_policy('policy22');

После выполнения каждого запроса выводится сообщение:
```
pm_remove_policy
------------------
t
(1 row)
```
Снимите с тестовых администраторов безопасности политики администратора безопасности:
```
SELECT pm_revoke_security_admin('stas');

SELECT pm_revoke_security_admin('sveta');
```
После выполнения каждого запроса выводится сообщение:
```
pm_revoke_security_admin
--------------------------
t
(1 row)
```

Снимите защиту со схемы, обеих таблиц и бывших администраторов безопасности:

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

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

SELECT pm_unprotect_object('table','krasnay.table1');

SELECT pm_unprotect_object('table','krasnay.table2');

SELECT pm_unprotect_object('schema','krasnay');

После выполнения каждого запроса выводится сообщение:
```
pm_unprotect_object
---------------------
t
(1 row)
```
Убедитесь, что пользователей, тестовых таблиц и схемы нет в списке объектов, находящихся под защитой:
```
SELECT pm_get_protected_objects();
```
Завершите сеанс, начатый из-под администратора безопасности:
```
\q
```
Зайдите под пользователем postgres:
```
psql
```
Исключите права на тестовую схему для тестовых пользователей:
```
REVOKE ALL ON SCHEMA test_admin_sch FROM sasha;

REVOKE ALL ON SCHEMA test_admin_sch FROM katya;
```

Удалите тестовых пользователей:

DROP USER stas;
DROP ROLE

DROP USER sveta;
DROP ROLE

DROP USER sasha;
DROP ROLE

DROP USER katya;
DROP ROLE

Удалите тестовую схему:
```
DROP SCHEMA krasnay CASCADE;
DROP SCHEMA
```

Настройка хранилища паролей для пользователя Pangolin Manager

В данном разделе производится настройка хранилища паролей для пользователя pangolin-manager.

Если текущий пароль pangolin-manager неизвестен, то задается новый пароль, а затем он записывается в хранилища паролей на мастере и реплике. Если текущий пароль pangolin-manager известен - достаточно выполнить только пункт 4.3.2 на реплике.

Примечание:

Хранилище паролей (файл /etc/postgres/enc_utils_auth_settings.cfg) создается автоматически при установке Pangolin.

Пользователь pangolin-manager используется, как служебный пользователь кластера Pangolin, использующийся, в частности, для репликации (детали можно найти в /etc/pangolin-manager/postgres.yml).

Изменение пароля

Действие выполняется на основном узле.

Чтобы измените пароль на основном узле, выполните:

## ALTER USER "patroni" WITH ENCRYPTED PASSWORD '{{ patroni_pass }}';

Запись пароля в хранилище паролей

Действие выполняется на основном узле и реплике.

Выполните запись пароля в хранилище паролей (пароль запрашивается при выдаче команды pg_auth_config add):

sudo su - postgres
pg_auth_config show

pg_auth_config  remove -s -h localhost -p 5433 -U patroni -d postgres
pg_auth_config  remove -s -h localhost -p 5433 -U patroni -d replication
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U patroni -d postgres
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U patroni -d replication
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U patroni -d postgres
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U patroni -d replication

pg_auth_config  add -s -h localhost -p 5433 -U patroni -d postgres
pg_auth_config  add -s -h localhost -p 5433 -U patroni -d replication
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U patroni -d postgres
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U patroni -d replication
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U patroni -d postgres
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U patroni -d replication

pg_auth_config show

Настройка хранилища паролей для пользователя backup_user

В данном разделе производится настройка хранилища паролей для пользователя backup_user.

Если текущий пароль backup_user неизвестен, то задается новый пароль, а затем он записывается в хранилища паролей на основном узле и реплике. Если текущий пароль backup_user известен - достаточно выполнить только пункт 4.4.2 на реплике.

Изменение пароля

Действие выполняется на основном узле.

Чтобы изменить пароль на основном узле, выполните:

## ALTER USER "backup_user" WITH PASSWORD '{{ backup_user_pass }}';

Запись пароля в хранилище паролей

Действие выполняется на основном узле и реплике.

Выполните запись пароля в хранилище паролей:

sudo su - postgres
pg_auth_config show

pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h {{ master_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h {{ replica_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h localhost -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h 127.0.0.1 -p 5433 -U backup_user -d postgres

pg_auth_config  add -s -h {{ master_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h {{ master_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h {{ replica_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h localhost -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h 127.0.0.1 -p 5433 -U backup_user -d postgres

pg_auth_config show

Настройка хранилища паролей для пользователя profile_tuz

В данном разделе производится настройка хранилища паролей для пользователя profile_tuz.

Если текущий пароль profile_tuz неизвестен, то задается новый пароль, а затем он записывается в хранилища паролей на мастере и реплике. Если текущий пароль profile_tuz известен - достаточно выполнить запись пароля в хранилище паролей на реплике.

Изменение пароля

Действие выполняется на основном узле.

Измените пароль в СУБД на основном узле:

## ALTER USER "profile_tuz" WITH PASSWORD '{{ profile_tuz_pass }}';

Запись пароля в хранилище паролей

Действие выполняется на основном узле и реплике.

Выполните запись пароля в хранилище паролей:

sudo su - postgres
pg_auth_config show

pg_auth_config  remove -s -h localhost -p 5433 -U profile_tuz -d postgres
pg_auth_config  remove -s -h localhost -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U profile_tuz -d "First_db"

pg_auth_config  add -s -h localhost -p 5433 -U profile_tuz -d postgres
pg_auth_config  add -s -h localhost -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U profile_tuz -d "First_db"

pg_auth_config show

Установка пароля для пользователя kmadmin_pg

Действие выполняется на основном узле и реплике.

Если на основном узле существует пользователь kmadmin_pg, то следует установить пароль на реплике соответственно:

sudo su - {{ USER }}
sudo passwd kmadmin_pg

Конфигурирование ролевой модели

Установка ролевой модели

Порядок установки:

Измените правила в файле pg_hba.conf:

pg_hba.conf
[hostssl|hostgss] postgres        admin_dbms <ip_cidr> <auth_method>
[hostssl|hostgss] database_name   admin_db   <ip_cidr> <auth_method>
[hostssl|hostgss] replication     admin_db   <ip_cidr> <auth_method>
[hostssl|hostgss] database_name   user_db    <ip_cidr> <auth_method>
host              all             admin_dbms 0.0.0.0/0 reject
host              all             admin_db   0.0.0.0/0 reject
host              all             user_db    0.0.0.0/0 reject
local             all             admin_dbms 0.0.0.0/0 reject
local             all             admin_db   0.0.0.0/0 reject
local             all             user_db    0.0.0.0/0 reject

В случае использования нескольких учетных записей для каждой роли - учетные записи указываются через запятую для каждой БД.

В случае использования нескольких БД - желательно группировать записи в pg_hba.conf в разрезе ролей и баз данных. Допустимо указывать роли через запятую для каждой из БД.

Примените изменения в конфигурационном файле pg_hba.conf с помощью команды:
```
psql -Xc 'SELECT pg_reload_conf()'
```
Убедитесь в соответствии конфигурационных параметров lc_ctype, lc_collate ожидаемой локали создаваемой БД (в postgresql.conf). В случае изменения параметров — перезапустите сервис СУБД.

Запустите скрипты создания ролей от имени пользователя postgres операционной системы в следующем порядке:

Создайте пользователя роли Администратор СУБД (пример выполнения команды):

$ psql -Xf addrole_admin_dbms.sql
Connected to СУБД Pangolin 6.5.0 build 216 (12:05:55 19.02.2024) commit {хеш} (PostgreSQL 15.5)
-- This script is a part of FSTEC Role Model
-- [1/3] This script intended TO ADD RDBMS OWNER ROLE AND must be running FIRST
Enter RDBMS OWNER role name:admin_dbms
Enter DATABASE name:database_name
-- Starting adding database owner at Thu Apr  4 14:49:38 MSK 2024
SET
Time: 0.954 ms
SET
Time: 0.529 ms
DO
Time: 4.498 ms
Adding user admin_dbms
psql:addrole_admin_dbms.sql:75: NOTICE:  Success: User admin_dbms added. Do not forget to set password
DO
Time: 5.553 ms
Ending adding database owner at Thu Apr  4 14:49:38 MSK 2024

Создайте пользователя роли Администратор БД (пример выполнения команды):

$ psql -Xf addrole_admin_db.sql
Connected to СУБД Pangolin 6.5.0 build 216 (12:05:55 19.02.2024) commit {хеш} (PostgreSQL 15.5)
-- This script is a part of FSTEC Role Model
-- [2/3] This script intended to add DB ADMIN role and must be running AFTER addrole_admin_dbms.sql
Enter DB ADMIN role name: admin_db
Enter DATABASE name: database_name
-- Starting adding database admin at Thu Apr  4 14:50:39 MSK 2024
SET
Time: 0.897 ms
SET
Time: 0.531 ms
psql:addrole_admin_db.sql:76: WARNING:
# $PGDATA/pg_hba.conf must contain
[hostssl|hostgssenc] database_name admin_db <ip>/<mask> <auth_method>

DO
Time: 4.918 ms
Adding user admin_db
psql:addrole_admin_db.sql:93: NOTICE:  Success: User admin_db added. Do not forget to set password
DO
Time: 5.273 ms
CREATE DATABASE
Time: 76.350 ms
Time: 1.428 ms
-- Ending adding database admin at Thu Apr  4 14:50:39 MSK 2024

Создание пользователя роли Пользователя БД (пример выполнения команды)

$ psql -Xf addrole_user_db.sql
Connected to СУБД Pangolin 6.5.0 build 216 (12:05:55 19.02.2024) commit {хеш} (PostgreSQL 15.5)
-- This script is a part of FSTEC Role Model
-- [3/3] This script intended to add DB USER role and must be running AFTER addrole_admin_db.sql
Enter DB USER role name: user_db
Enter DATABASE name: database_name
-- Starting adding database user at Thu Apr  4 14:53:05 MSK 2024
SET
Time: 0.918 ms
SET
Time: 0.530 ms
psql:addrole_user_db.sql:66: WARNING:
# $PGDATA/pg_hba.conf must contain
[hostssl|hostgssenc] database_name user_db <ip>/<mask> <auth_method>

DO
Time: 5.107 ms
Adding user user_db
psql:addrole_user_db.sql:83: NOTICE:  Success: User user_db added. Do not forget to set password
DO
Time: 5.401 ms
Time: 0.520 ms
SET
Time: 0.462 ms
GRANT ROLE
Time: 2.791 ms
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, compression: off)
You are now connected to database "database_name" as user "postgres".
SET
Time: 0.910 ms
ALTER ROLE
Time: 4.032 ms
GRANT
Time: 3.367 ms
GRANT
Time: 3.881 ms
GRANT
Time: 0.973 ms
ALTER DEFAULT PRIVILEGES
Time: 3.418 ms
ALTER DEFAULT PRIVILEGES
Time: 2.869 ms
ALTER DEFAULT PRIVILEGES
Time: 2.739 ms
ALTER DEFAULT PRIVILEGES
Time: 2.836 ms
ALTER DEFAULT PRIVILEGES
Time: 2.809 ms
RESET
Time: 0.313 ms
SET
Time: 0.479 ms
SET
Time: 0.414 ms
SET
Time: 0.420 ms
psql:addrole_user_db.sql:121: NOTICE:  Fixing permissions on trusted languages
psql:addrole_user_db.sql:121: NOTICE:  End fixing permissions on trusted languages
DO
Time: 6.045 ms
-- Ending adding database user at Thu Apr  4 14:53:05 MSK 2024

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

При этом, Администратор БД не может быть добавлен раньше Администратора СУБД, Пользователь БД раньше Администратора БД (в разрезе конкретной БД).

Внимание!

Ограничения:

соответствие имен роли и БД маске: первая буква – латиница (смешанный регистр), вторая и последующие – латиница (смешанный регистр), цифры, символ подчеркивания. Минимальная длина — 1 символ;

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

отсутствие БД при создании роли Пользователь БД будет считаться ошибкой.

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

Структура скриптов конфигурирования ролевой модели

Скрипты конфигурирования ролевой модели делятся на:

запускаемые пользователем bash-скрипты;
SQL-скрипты, вызываемые bash-скриптами с помощью psql;
ansible-скрипты.

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

Примеры запуска скриптов настройки ролевой модели приведены в документе «Руководство по установке», раздел «Установка».

Запускаемые скрипты

Запускаемые скрипты конфигурирования ролевой модели находятся в директории дистрибутива: installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/.

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

Комментарии в теле скриптов содержат:

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

В дистрибутив включены следующие запускаемые bash-скрипты:

Имя скрипта	Назначение
`run_configure.sh`	Основной скрипт, выполняющий конфигурирование ролевой модели
`password_space_settings.sh`	Скрипт, выполняющий конфигурирование хранилища паролей для пользователей profile_tuz и backup_user

Параметры скрипта run_configure.sh:

Имя параметра	Назначение
`database_name`	Имя пользовательской базы данных
`tablespace_name`	Имя пользовательского табличного пространства
`tablespace_location`	Имя директории, содержащей табличное пространство
`schema_name`	Имя пользовательской схемы
`pg_port`	Порт в настройках pg_profile
`fqdn_master`	Имя хоста мастера в настройках pg_profile
`fqdn_replica`	Имя хоста реплики в настройках pg_profile
`stats_periods`	Период запуска задания cron в настройках pg_profile
`expire_date`	Срок действия пароля конечных пользователей
`user_for_backup`	Имя пользователя резервного копирования для использования в manage_backup.sh
`as_adms`	Список конечных пользователей, создаваемых в группе as_admin
`as_tuzs`	Список конечных пользователей, создаваемых в группе as_TUZ
`temp_pass`	Флаг, указывающий на задание временных паролей
`tde_admin_protection`	Флаг включения TDE
`path_to_scripts`	Путь, по которому размещается данный скрипт (требуется только при запуске с помощью ansible)
`psql_path`	Путь, по которому размещается запускаемый модуль psql
`password_list`	Словарь паролей ТУЗов. В случае задания пароля в виде SCRAM-SHA-256 - хеш должен быть предварительно вычислен
`feature_list`	Словарь для задания списка функций, которые необходимо включить
`locale`	Значение locale с которой будет создана пользовательская БД
`prdbname`	Имя пользовательской БД в которой будет установлен pg_profile

Скрипт run_configure.sh, запущенный с опцией -h или --help, выводит сообщение-подсказку о доступных опциях командной строки и после этого останавливается.

При запуске скрипта run_configure.sh выводится список актуальных значений параметров и выполняется ряд проверок.

SQL-скрипты

SQL-скрипты вызываются bash-скриптами, являющимися в данном ключе оркестраторами. SQL-скрипты находятся в директориях:

installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/sql_scripts;
installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/sql_scripts/extensions;
installer/scripts_external/configure_roles/configure_roles/templates/role_BASIC/sql_scripts/pg_profile.

SQL-скрипты предназначены для настройки отдельных функциональных блоков ролевой модели и в качестве параметров принимают значения из bash-скриптов, которыми они были вызваны. Скрипты выполняются целиком, как отдельная транзакция, и откатываются, если какой-либо оператор завершился с ошибкой.

В дистрибутив включены следующие SQL-скрипты:

Имя скрипта	Назначение
`create_db_and_ts.sql`	Выполняет создание пользовательского табличного пространства и базы данных. В качестве шаблона при создании базы данных берется стандартная системная база template1
`create_end_as_admin_user.sql`	Выполняет создание конечных пользователей группы as_admin
`create_end_as_TUZ_user.sql`	Выполняет создание конечных пользователей группы as_TUZ
`create_roles.sql`	Выполняет создание групповых ролей и служебных пользователей
`create_user_schema.sql`	Выполняет создание пользовательской схемы
`functions.sql`	Выполняет настройку прав доступа пользовательским функциям
`get_role_passwd.sql`	Выполняет настройку функции get_role_passwd
`grants_common_db.sql`	Выполняет общие для всех баз данных настройки привилегий
`grants_only_postgres_db.sql`	Выполняет настройки привилегий в базе данных postgres
`grants_only_user_db.sql`	Выполняет настройки привилегий в пользовательской базе данных
`revoke_public_template0.sql`	Выполняет настройки привилегий роли public в базе данных template0.sql
`setting_pp_for_users.sql`	Выполняет настройки парольных политик
`create_1c_extentions.sql`	Выполняет установку расширений, используемых в 1C
`create_common_extensions.sql`	Выполняет настройки расширений, общие для всех баз данных
`create_ext_only_postgres_db.sql`	Выполняет настройки расширений в базе данных postgres
`create_pg_hint_plan.sql`	Выполняет настройку расширения pg_hint_plan
`create_pg_outline.sql`	Выполняет настройку расширения pg_outline
`create_pg_stat_kcache.sql`	Выполняет настройку расширения pg_stat_kcache
`create_psql_rotate_password.sql`	Выполняет настройку расширения psql_rotate_password
`create_schema_for_extensions.sql`	Выполняет настройку схемы 'ext'
`create_pg_profile_ext.sql`	Выполняет настройку расширения pg_profile
`users_db_grants_profile_tuz.sql`	Выполняет настройку прав доступа для расширения pg_profile
`change_owner_for_profile_tables.sql`	Выполняет настройку владельца функций расширения pg_profile
`common_grants_profile_tuz.sql`	Выполняет настройку общих прав доступа для расширения pg_profile
`pg_audit_settings.sql`	Выполняет настройку pgaudit.log для пользователей из ролевой модели

Ansible-скрипты

Для упрощения развертывания ролевой модели была реализована ansible-роль configure_roles, которая выполняет настройку ролевой модели, пользовательской БД и расширений автоматически. Выполнение данной роли предполагается после выполнения развертывания СУБД Pangolin с использованием playbook_configure_roles.yaml. В данном случае будет выполнена настройка ролевой модели, пользовательской БД и расширений после чистой установки Pangolin. Данная роль располагается в дистрибутиве по пути installer/scripts_external/configure_roles.

Роль configure_roles полностью автономна, может быть запущена вне компонента installer и имеет следующую структуру:

Файл/директория	Назначение
`playbook_configure_roles.yaml`	Основной ansible-скрипт, выполняющий развертывание ролевой модели
`filter_plugins`	Директория, содержащая фильтры для использования внутри роли `configure_roles`
`templates`	Директория, содержащая запускаемые SQL-скрипты (раздел «SQL-скрипты» данного руководства) для развертывания ролевой модели, пользовательской БД и расширений
`tasks`	Директория, содержащая yml-скрипты для развертывания ролевой модели
`group_vars`	Директория, содержащая переменные, используемые ролью для развертывания ролевой модели
`library`	Директория, содержащая бинарный файл генератора паролей `password_generator`

Структура файлов с переменными имеет следующий вид:

Файл	Назначение
`all.yml`	Файл с общими параметрами для роли `configure_roles`
`message.yml`	Файл с сообщениями, которые используются в процессе выполнения роли `configure_roles`
`variables.yml`	Файл с переменными, используемыми для корректировки настраиваемой ролевой модели

Ansible-роль configure_roles используется при инсталляции для настройки ролевой модели.

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

Предусловия:

установить и настроить HashiCorp Vault;
добавить параметры в Хранилище секретов;

Инструкции по данным действиям приведены в разделе «Установка и настройка HashiCorp Vault» документа «Инструкции и рекомендации».

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

В случае настройки конфигурации с Pangolin Manager все действия аналогичны, проводятся только на одном лидирующем узле. В случае настройки для стандартной конфигурации параметр is_tde_on = on устанавливается в конфигурационном файле $PGDATA/postgresql.conf, стоп/старт СУБД выполняется командами: pg_ctl stop/start.

Определить конфигурацию кластера можно командой psql:

SHOW installer.cluster_type;

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

postgres=# select check_password_policy_is_on();
 check_password_policy_is_on
-----------------------------
 t
(1 row)

postgres=# select check_pg_audit_is_on();
 check_pg_audit_is_on
----------------------
 t
(1 row)

postgres=# select check_tde_is_on();
 check_tde_is_on
-----------------
 f
(1 row)

postgres=# select check_admin_protect_is_on();
 check_admin_protect_is_on
---------------------------
 f
(1 row)

Для включения и последующей настройки механизма защиты данных от привилегированных пользователей в действующем кластере Pangolin необходимо выполнить следующие шаги (в данном случае рассматривается пример включения защиты параметров и защиты данных):

Администратор выводит кластер из обслуживания приложений, останавливает СУБД.
Администратор устанавливает параметр is_tde_on = on в конфигурационном файле СУБД Pangolin (для включения засекречивания данных).
Сотрудник безопасности (пользователь ОС kmadmin_pg) запускает утилиту инициализации каталога безопасности initprotection (для включения защиты данных).
Сотрудник безопасности (пользователь ОС kmadmin_pg) запускает утилиту setup_kms_credentials и создает файл с параметрами соединения с KMS.
При необходимости сотрудник ИБ устанавливает мастер-ключ KMS вручную. Если мастер-ключ не задан, используется мастер-ключ, автоматически созданный при первом старте БД.
Администратор запускает кластер на Active-узле.
Администратор выполняет очистку данных каталога PGDATA на Standby-узле.
Администратор запускает кластер на Standby-узле.
Сотрудник ИБ (при наличии) включает защиту данных от привилегированных пользователей в HashiCorp Vault (для включения защиты параметров).
Администратор перезапускает кластер на Active узле для применения нового значения параметра secure_config.
Администратор проверяет включение защиты данных в кластере.

Параметры команд:

Параметр	Описание	Пример
`{{ PGHOME }}`	директория с бинарными файлами для работы БД	`/usr/pangolin-6.5.0`
`{{ PGDATA }}`	директория БД	`/pgdata/0{major_version}/data`
`{{ sec_admin }}`	имя создаваемого администратора безопасности при инициализации	`sec_admin`

Шаги:

Остановите Pangolin Manager (сначала на Standby-узле, затем на Active-узле во избежание переключения Active-узла на Standby-режим):
```
$ sudo systemctl stop pangolin-manager
```

Проверьте состояние кластера:

$ patronictl -c /etc/panglin-manager/postgres.yml list $CLNAME
+ Cluster: clustername (7151342043309644683) ----+---------+---------+----+-----------+
| Member              | Host                     | Role    | State   | TL | Lag in MB |
+---------------------+--------------------------+---------+---------+----+-----------+
| <server_name>       | <server_name>:<port>     | Replica | stopped |    |   unknown |
| <server_name>       | <server_name>:<port>     | Replica | stopped |    |   unknown |
+---------------------+--------------------------+---------+---------+----+-----------+

В случае необходимости включения засекречивания данных (TDE) установите параметр is_tde_on = on в конфигурационном файле (сначала на Active-узле, затем на Standby-узле):

$ vim /etc/pangolin-manager/postgres.yml

# перейти в режим редактирования: введите i
# изменить параметр is_tde_on

is_tde_on: on

# выйти из редактора, сохранив файл: нажмите **Esc**, введите :wq и нажмите **Enter**

В версии ниже 4.3.х проверьте наличие (создайте при отсутствии) директории /etc/postgres с правами 700 у владельца postgres):
```
drwx------   2 postgres postgres   4096 Sep  1 08:31 postgres
```
Выполните вход администратором ИБ:
```
$ su - kmadmin_pg
```

Запустите утилиту initprotection:

$ sudo -i -u postgres -g kmadmin_pg {{ PGHOME }}/bin/initprotection

-- Введите директорию БД PGDATA, имя администратора безопасности, пароль с подтверждением
Enter PGDATA directory [/pgdata/0{major_version}/data]: {{ PGDATA }}
Enter security administrator names (comma-separated):{{ sec_admin }}
Enter new security admin password for user "sec_admin":
Enter it again:

В случае успешного завершения получите сообщение:
```
Protection mechanism is initialized.
syncing data to disk ...
```
Сотрудник безопасности (пользователь ОС kmadmin_pg) запускает утилиту setup_kms_credentials (утилита находится в директории {{ PGHOME }}/bin). Необходимо наличие библиотеки libjsoncpp.so версии не менее 1.8.4 для настройки соединения с KMS (в результате будет создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg). Запуск сначала на Active-узле, затем на Standby-узле):
```
{{ PGHOME }}/bin/setup_kms_credentials
```
Укажите ID кластера (при добавлении параметров в KMS в поле CLUSTER_ID необходимо указать имя кластера):
```
Enter Pangolin cluster ID:
clustername                    <-
```
Далее укажите файл или директорию с корневым центром сертификации, чтобы проверить Secret storage server:
```
Enter root CA folder or file or leave empty:
/pg_ssl                        <-
```
Укажите suffix для доступа к хранилищу:
```
Enter suffix or leave empty:
postgresql                      <-
```

Укажите IP-address KMS (Secret storage):

Enter IP address or Domain Name of Secret storage:
<IP-address>                     <-

Укажите порт KMS:

Enter port:
8200                           <-

На сообщение о выборе протокола для взаимодействия с секретным хранилищем выберите https (2):
```
Choose protocol type or leave empty to use default (https):
1. http
2. https                        <-
2
```
На сообщение об указании префикса для доступа к хранилищу, нажмите enter, чтобы использовать значение по умолчанию (kv):
```
Enter secrets prefix or leave empty to use default (kv):
enter                          <-
```
На сообщение об указании пространства имен для взаимодействия с секретным хранилищем, нажмите enter:
```
Enter Secret storage namespace or leave empty:
enter                          <-
```
На сообщение о выборе типа учетных данных методе аутентификации выберите Userpass Auth Method, нажав 1:
```
Choose credentials type:
1. Userpass Auth Method        <-
2. AppRole Auth Method
1
```
На сообщение о вводе точки авторизации, нажмите enter:
```
Enter auth point or leave empty to use default (userpass):
enter                          <-
```

Далее необходимо ввести логин и пароль администратора:

Enter login:
adminencryption                <-

Enter password:
******                         <-
Confirm password:
******                         <-

На сообщение о добавлении еще одних учетных данных KMS ответьте no:
```
Do you want to add another Secret storage credentials? (yes/no)?:
no                             <-
```
При успешном добавлении параметров появится сообщение:
```
Credentials for Secret storage has been set successfully
```
Если при установке возникли проблемы, воспользуйтесь командой:
```
setup_kms_credentials --help
```
В результате создан файл с параметрами KMS-соединения /etc/postgres/enc_connection_settings.cfg:
```
-rw-rw-r-- 1 kmadmin_pg kmadmin_pg  176 Nov  3 0{major_version}:49 enc_connection_settings.cfg
```

Запустите кластер на Active-узле. Запустите Pangolin Manager:

sudo systemctl start pangolin-manager

Проверьте состояние узлов кластера:

patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME

+ Cluster: KSG (71613900{major_version}1636086813)--------+---------+----+-----------+
| Member              | Host                     | Role   | State   | TL | Lag in MB |
+---------------------+--------------------------+--------+---------+----+-----------+
| <server_name>       | <server_name>:<port>     | Leader | running |  5 |           |
+---------------------+--------------------------+--------+---------+----+-----------+

На Standby-узле oчистите данные каталога PGDATA:
```
$ rm -rf /pgdata/*
```

Запустите кластер на Standby-узле. Запустите Pangolin Manager:

$ sudo systemctl start pangolin-manager

Проверьте состояние узлов кластера:

patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME

| Member              | Host                     | Role    | State            | TL | Lag in MB |
+---------------------+--------------------------+---------+------------------+----+-----------+
| <server_name>       | <server_name>:<port>     | Replica | creating replica |    |   unknown |
| <server_name>       | <server_name>:<port>     | Leader  | running          |  5 |           |
+---------------------+--------------------------+---------+------------------+----+-----------+

-- после выполнения репликации

$ patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME

+ Cluster: KSG (71613900{major_version}1636086813) -------------+---------+----+-----------+
| Member              | Host                     | Role         | State   | TL | Lag in MB |
+---------------------+--------------------------+--------------+---------+----+-----------+
| <server_name>       | <server_name>:<port>     | Sync Standby | running |  5 |         0 |
| <server_name>       | <server_name>:<port>     | Leader       | running |  5 |           |
+---------------------+--------------------------+--------------+---------+----+-----------+

После проверки работоспособности кластера включите защиту данных от привилегированных пользователей в HashiCorp Vault (создайте новую версию параметра secure_config = on). Для этого выберите параметр secure_config, затем нажмите Create new version:
В поле Version data укажите имя параметра = value, значение = on. Сохраните, нажав кнопку Save:

Для применения нового значения параметра secure_config выполните перезапуск кластера на Active-узле:

-- перечитайте конфигурацию
$ patronictl -c /etc/pangolin-manager/postgres.yml reload $CLNAME

+ Cluster: KSG (71613900{major_version}1636086813) +--------------+---------+----+-----------+
  | Member              | Host                     | Role         | State   | TL | Lag in MB |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  | <server_name>       | <server_name>:<port>     | Sync Standby | running |  5 |         0 |
  | <server_name>       | <server_name>:<port>     | Leader       | running |  5 |           |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  Are you sure you want to reload members <server_name>, <server_name>? [y/N]: y
  Reload request received for member <server_name> and will be processed within 10 seconds
  Reload request received for member <server_name> and will be processed within 10 seconds

-- перезапустите кластер
$ patronictl -c /etc/panglin-manager/postgres.yml restart $CLNAME
+ Cluster: KSG (71613900{major_version}1636086813) +--------------+---------+----+-----------+
  | Member              | Host                     | Role         | State   | TL | Lag in MB |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  | <server_name>       | <server_name>:<port>     | Sync Standby | running |  5 |         0 |
  | <server_name>       | <server_name>:<port>     | Leader       | running |  5 |           |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  When should the restart take place (e.g. 2022-11-03T08:22)  [now]:
  Are you sure you want to restart members <server_name>, <server_name>? [y/N]: y
  Restart if the PostgreSQL version is less than provided (e.g. 9.5.2)  []:
  Success: restart on member <server_name>
  Success: restart on member <server_name>

-- проверьте состояние узлов кластера
$ patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME
+ Cluster: KSG (71613900{major_version}1636086813) +--------------+---------+----+-----------+
  | Member              | Host                     | Role         | State   | TL | Lag in MB |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  | <server_name>       | <server_name>:<port>     | Sync Standby | running |  5 |         0 |
  | <server_name>       | <server_name>:<port>     | Leader       | running |  5 |           |
  +---------------------+--------------------------+--------------+---------+----+-----------+

Проверьте успешное включение защиты данных от привилегированных пользователей и TDE в кластере:
```
postgres=# select check_tde_is_on();
check_tde_is_on
-----------------
t
(1 row)

postgres=# select check_admin_protect_is_on();
check_admin_protect_is_on
---------------------------
t
(1 row)
```
Возвращаемое значение функции t (true) означает, что прозрачное защитное преобразование данных (TDE) в СУБД и защита данных от привилегированных пользователей включены.

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

Предусловие:

настроить KMS-заменитель;
подготовить файлы со статическими и динамическими параметрами.

Оба действия подробно описаны в разделах «Настройка KMS-заменителя» и «Подготовка файлов со статическими и динамическими параметрами» раздела «HashiCorp Vault и KMS-заменитель» в документе «Инструкции и рекомендации».

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

Далее рассматривается пример настройки механизма защиты данных от привилегированных пользователей в СУБД Pangolin с кластерной конфигурацией. В случае настройки конфигурации с Pangolin Manager все действия аналогичны, проводятся только на одном лидирующем узле. В случае настройки стандартной конфигурации параметр is_tde_on = on устанавливается в конфигурационном файле $PGDATA/postgresql.conf, стоп/старт СУБД выполняется командами: pg_ctl stop/start.

Определить конфигурацию кластера можно командой psql:

SHOW installer.cluster_type;

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

postgres=# select check_password_policy_is_on();
 check_password_policy_is_on
-----------------------------
 t
(1 row)

postgres=# select check_pg_audit_is_on();
 check_pg_audit_is_on
----------------------
 t
(1 row)

postgres=# select check_tde_is_on();
 check_tde_is_on
-----------------
 f
(1 row)

postgres=# select check_admin_protect_is_on();
 check_admin_protect_is_on
---------------------------
 f
(1 row)

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

Администратор выводит кластер из обслуживания приложений, останавливает СУБД.
Сотрудник безопасности (пользователь ОС kmadmin_pg) запускает утилиту инициализации каталога безопасности initprotection (для включения защиты данных).
Сотрудник безопасности (пользователь ОС kmadmin_pg) запускает утилиту setup_kms_credentials (создает файл с параметрами соединения с KMS).
Администратор устанавливает параметр is_tde_on = on в конфигурационном файле СУБД Pangolin (для включения засекречивания данных).
Администратор включает заменитель KMS.
Администратор запускает кластер на Active-узле.
Администратор выполняет очистку данных каталога PGDATA на Standby-узле.
Администратор запускает кластер на Standby-узле.
Администратор проверяет включение защиты данных в кластере.

Параметры команд:

Параметр	Описание	Пример
`{{ PGHOME }}`	директория с бинарными файлами для работы БД	`/usr/pangolin-5.2.1`
`{{ PGDATA }}`	директория БД	`/pgdata/0{major_version}/data`
`{{ sec_admin }}`	имя создаваемого администратора безопасности при инициализации	`sec_admin`

Остановите Pangolin Manager (сначала на Standby-узле, затем на Active-узле во избежание переключения Active-узла на Standby):
```
$ sudo systemctl stop pangolin-manager
```

Проверьте состояние кластера:

$ patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME
+ Cluster: KSG (7163115110{major_version}46408677) --------+---------+----+-----------+
| Member              | Host                     | Role    | State   | TL | Lag in MB |
+---------------------+--------------------------+---------+---------+----+-----------+
| <server_name>       | <server_name>:<port>     | Replica | stopped |    |   unknown |
| <server_name>       | <server_name>:<port>     | Replica | stopped |    |   unknown |
+---------------------+--------------------------+---------+---------+----+-----------+

В версиях ниже 4.3.х проверьте наличие (создайте при отсутствии) директории /etc/postgres с правами 700 у пользователя postgres):
```
drwx------   2 postgres postgres   4096 Sep  1 08:31 postgres
```
Выполните вход пользователем ОС kmadmin_pg (сотрудник безопасности):
```
$ su - kmadmin_pg
```

Запустите утилиту initprotection (утилита находится в директории {{ PGHOME }}/bin):

$ sudo -i -u postgres -g kmadmin_pg {{ PGHOME }}/bin/initprotection

-- Введите директорию БД PGDATA, имя администратора безопасности, пароль с подтверждением
Enter PGDATA directory [/pgdata/0{major_version}/data]: {{ PGDATA }}
Enter security administrator names (comma-separated): {{ sec_admin }}
Enter new security admin password for user "sec_admin":
Enter it again:

В случае успешного завершения, получите сообщение:

Protection mechanism is initialized.
syncing data to disk ...

Запустите под пользователем ОС kmadmin_pg утилиту setup_kms_credentials (утилита расположена в директории {{ PGHOME }}/bin):
```
$ {{ PGHOME }}/bin/setup_kms_credentials
```
Укажите ID кластера (укажите имя своего кластера):
```
Enter Pangolin cluster ID:
clustername                    <-
```
Далее необходимо указать файл или директорию с корневым центром сертификации, чтобы проверить Secret storage server:
```
Enter root CA folder or file or leave empty:
/pg_ssl
```
Далее необходимо указать suffix для доступа к хранилищу:
```
Enter suffix or leave empty:
postgresql
```
Последующие параметры при работе с заменителем значения не имеют, можно использовать предлагаемые. IP-адрес:
```
Enter IP address or Domain Name of Secret storage:
{Предлагаемый IP-адрес}                        <-
```
Порт KMS:
```
Enter port:
{Предлагаемый порт}                           <-
```
На сообщение о выборе протокола для взаимодействия с Хранилищем секретов выберите https, нажав 2:
```
Choose protocol type or leave empty to use default (https):
1. http
2. https                        <-
2
```
На сообщение об указании префикса для доступа к Хранилищу нажмите enter, чтобы использовать значение по умолчанию (kv):
```
Enter secrets prefix or leave empty to use default (kv):
enter                          <-
```
На сообщение об указании пространства имен для взаимодействия с Хранилищем секретов, нажмите enter:
```
Enter Secret storage namespace or leave empty:
enter                          <-
```
На сообщение о выборе типа учетных данных методе аутентификации выберите Userpass Auth Method, нажав 1:
```
Choose credentials type:
1. Userpass Auth Method        <-
2. AppRole Auth Method
1
```
На сообщение о вводе точки авторизации, нажмите enter:
```
Enter auth point or leave empty to use default (userpass):
enter                          <-
```

Далее необходимо ввести логин и пароль администратора:

Enter login:
adminencryption                <-

Enter password:
******                         <-
Confirm password:
******                         <-

На сообщение о добавлении еще одних учетных данных KMS ответьте no:
```
Do you want to add another Secret storage credentials? (yes/no)?:
no                             <-
```
При успешном добавлении параметров появится сообщение:
```
Credentials for Secret storage has been set successfully
```
Если при установке возникли проблемы, воспользуйтесь командой:
```
setup_kms_credentials --help
```
В результате создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg:
```
-rw-rw-r-- 1 kmadmin_pg kmadmin_pg    176 Oct  6 14:50 enc_connection_settings.cfg
```
В случае необходимости включения засекречивания данных (TDE) установите параметр is_tde_on = on в конфигурационном файле /etc/pangolin-manager/postgres.yml сначала на Active-узле, затем на Standby-узле:
```
$ vim /etc/pangolin-manager/postgres.yml

# перейти в режим редактирования: введите i
# изменить параметр is_tde_on

is_tde_on: on

# выйти из редактора, сохранив файл: нажмите **Esc**, введите :wq и нажмите **Enter**
```
Включите заменитель KMS. Для этого необходимо создать символьную ссылку на библиотеку {{ PGHOME }}/lib/libkms_substitute_plugin.so (сначала на Active-узле, затем на Standby-узле):
```
cd {{ PGHOME }}/lib

# удаление {{ PGHOME }}/lib/libconnector_plugin.so

rm {{ PGHOME }}/lib/libconnector_plugin.so

# создание символьной ссылки на библиотеку

ln -s {{ PGHOME }}/lib/plugins/libkms_substitute_plugin.so {{ PGHOME }}/lib/libconnector_plugin.so
```
Примечание:

Библиотека libconnector_plugin.so расположена в директории {{ PGHOME }}/lib, библиотека libkms_substitute_plugin.so в директории {{ PGHOME }}/lib/plugins.
Выполните запуск Pangolin Manager на Active-узле:
```
$ sudo systemctl start pangolin-manager
```

Проверьте состояние узлов кластера:

$ patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME

+ Cluster: KSG (7163115110{major_version}46408677) ------------+--------+---------+----+-----------+
  | Member              | Host                     | Role   | State   | TL | Lag in MB |
  +---------------------+--------------------------+--------+---------+----+-----------+
  | <server_name>       | <server_name>:<port>     | Leader | running |  4 |           |
  +---------------------+--------------------------+--------+---------+----+-----------+

В логе проверьте, что параметры KMS успешно загружены:

2022-11-07 08:24:02 MSK [27218]: [153-1] app=,user=,db=,client=,type=postmaster LOG:  Keyring initialization is started.
2022-11-07 08:24:02 MSK [27218]: [154-1] app=,user=,db=,client=,type=postmaster LOG:  Master key initialization is started.
2022-11-07 08:24:02 MSK [27218]: [155-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter 'initial_mk_create_mode' is not set in config. Default value is: TRUE.
2022-11-07 08:24:02 MSK [27218]: [156-1] app=,user=,db=,client=,type=postmaster LOG:  No active master key Id, in config file. Master key will be checked on KMS. If there is no master key on KMS and flag InitialMkCreateMode is set, it will be generated and loaded to KMS.
2022-11-07 08:24:02 MSK [27218]: [157-1] app=,user=,db=,client=,type=postmaster LOG:  KmsSubstituteConnector::GetValue domain: postgresql clusterId: KSG subdomain: keys key: actual_master_key parameter type: Static
2022-11-07 08:24:02 MSK [27218]: [158-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter value successfully loaded
2022-11-07 08:24:02 MSK [27218]: [159-1] app=,user=,db=,client=,type=postmaster LOG:  KmsSubstituteConnector::GetValue domain: postgresql clusterId: KSG subdomain: keys key: master_key_value_00000000_000000_000 parameter type: Static
2022-11-07 08:24:02 MSK [27218]: [160-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter value successfully loaded
2022-11-07 08:24:02 MSK [27218]: [161-1] app=,user=,db=,client=,type=postmaster LOG:  Master key initialization is completed successfully.
2022-11-07 08:24:02 MSK [27218]: [162-1] app=,user=,db=,client=,type=postmaster LOG:  KmsSubstituteConnector::GetValue domain: postgresql clusterId: KSG subdomain: keys key: wal_key parameter type: Static
2022-11-07 08:24:02 MSK [27218]: [163-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter value successfully loaded
2022-11-07 08:24:02 MSK [27218]: [164-1] app=,user=,db=,client=,type=postmaster LOG:  Keyring initialization is completed successfully.
2022-11-07 08:24:02 MSK [27218]: [165-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file is found: "/pgdata/0{major_version}/data/pg_wal/000000010000000000000001".
2022-11-07 08:24:02 MSK [27218]: [166-1] app=,user=,db=,client=,type=postmaster LOG:  WAL is not encrypted.
2022-11-07 08:24:02 MSK [27218]: [167-1] app=,user=,db=,client=,type=postmaster LOG:  Initial WAL encryption is started...
2022-11-07 08:24:02 MSK [27218]: [168-1] app=,user=,db=,client=,type=postmaster LOG:  The first WAL file is found: "pg_wal/000000010000000000000001"
2022-11-07 08:24:02 MSK [27218]: [169-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000010000000000000001" is encrypted (the end of WAL records is reached). Switch to the next timeline (LSN: 0/19AF228).
2022-11-07 08:24:02 MSK [27218]: [170-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000020000000000000001" is encrypted (the end of WAL file is reached). Switch to the next segment (LSN: 0/2000000)
2022-11-07 08:24:02 MSK [27218]: [171-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000020000000000000002" is encrypted (the end of WAL file is reached). Switch to the next segment (LSN: 0/3000000)
2022-11-07 08:24:02 MSK [27218]: [172-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000020000000000000003" is encrypted (the end of WAL file is reached). Switch to the next segment (LSN: 0/4000000)
2022-11-07 08:24:02 MSK [27218]: [173-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000020000000000000004" is encrypted (the end of WAL records is reached). Switch to the next timeline (LSN: 0/4127948).
2022-11-07 08:24:02 MSK [27218]: [174-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000030000000000000004" is encrypted (the end of WAL file is reached). Switch to the next segment (LSN: 0/5000000)
2022-11-07 08:24:02 MSK [27218]: [175-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000030000000000000005" is encrypted (the end of WAL file is reached). Switch to the next segment (LSN: 0/6000000)
2022-11-07 08:24:02 MSK [27218]: [176-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/00000003000000000000000{major_version}" is encrypted (the end of WAL file is reached). Switch to the next segment (LSN: 0/7000000)
2022-11-07 08:24:02 MSK [27218]: [177-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000030000000000000007" is encrypted (the end of WAL file is reached). Switch to the next segment (LSN: 0/8000000)
2022-11-07 08:24:02 MSK [27218]: [178-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file "pg_wal/000000030000000000000008" is encrypted (the end of WAL records is reached).
2022-11-07 08:24:02 MSK [27218]: [179-1] app=,user=,db=,client=,type=postmaster LOG:  Initial WAL encryption is successfully completed.

На Standby-узле oчистите данные каталога PGDATA:
```
$ rm -rf /pgdata/*
```
Запустите Pangolin Manager на Standby-узле:
```
$ sudo systemctl start pangolin-manager
```

Проверьте состояние узлов кластера:

$ patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME

+ Cluster: KSG (7163115110{major_version}46408677) +--------------+---------+----+-----------+
  | Member              | Host                     | Role         | State   | TL | Lag in MB |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  | <server_name>       | <server_name>:<port>     | Sync Standby | running |  4 |         0 |
  | <server_name>       | <server_name>:<port>     | Leader       | running |  4 |           |
  +---------------------+--------------------------+--------------+---------+----+-----------+

Проверьте успешное включение защиты данных от привилегированных пользователей и TDE в кластере:
```
postgres=# select check_tde_is_on();
check_tde_is_on
-----------------
t
(1 row)

postgres=# select check_admin_protect_is_on();
check_admin_protect_is_on
---------------------------
t
(1 row)
```
Возврат значения t (true) означает, что прозрачное защитное преобразование данных (TDE) в СУБД и защита данных от привилегированных пользователей включены.

Диагностика

При работе с HashiCorp Vault может возникнуть состояние Sealed, препятствующее дальнейшей работе. Подробная инструкция для восстановления и разблокировки приведена в блоке «Возможные проблемы и их решение при работе HashiCorp Vault» раздела «HashiCorp Vault и KMS-заменитель» документа «Инструкции и рекомендации».

Описание​

Структура ролей​

Матрица несовместимости ролей​

Операции, которые не должны выполняться одним лицом​

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

Связь ролей с объектами БД​

Схема и объекты схемы​

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

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

Настройка​

Первоначальная настройка​

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

Управление​

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

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

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

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

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

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

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

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

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

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

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

Возможность ротации секретов ТУЗ без недоступности​

Создание политик безопасности​

Создание политики безопасности на объекты через групповую роль (первый тестовый администратор безопасности)​

Создание политики безопасности на объекты через групповую роль (второй тестовый администратор безопасности)​

Изменение политики от основного администратора безопасности​

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

Описание сервиса​

Ограничения​

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

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

Удаление тестовых объектов​

Настройка хранилища паролей для пользователя Pangolin Manager​

Изменение пароля​

Запись пароля в хранилище паролей​

Настройка хранилища паролей для пользователя backup_user​

Изменение пароля​

Запись пароля в хранилище паролей​

Настройка хранилища паролей для пользователя profile_tuz​

Изменение пароля​

Запись пароля в хранилище паролей​

Установка пароля для пользователя kmadmin_pg​

Конфигурирование ролевой модели​

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

Структура скриптов конфигурирования ролевой модели​

Запускаемые скрипты​

SQL-скрипты​

Ansible-скрипты​

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

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

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

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

Диагностика​

Описание

Структура ролей

Матрица несовместимости ролей

Операции, которые не должны выполняться одним лицом

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

Связь ролей с объектами БД

Схема и объекты схемы

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

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

Настройка

Первоначальная настройка

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

Управление

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

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

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

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

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

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

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

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

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

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

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

Возможность ротации секретов ТУЗ без недоступности

Создание политик безопасности

Создание политики безопасности на объекты через групповую роль (первый тестовый администратор безопасности)

Создание политики безопасности на объекты через групповую роль (второй тестовый администратор безопасности)

Изменение политики от основного администратора безопасности

Переназначение прав для непривилегированных пользователей

Описание сервиса

Ограничения

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

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

Удаление тестовых объектов

Настройка хранилища паролей для пользователя Pangolin Manager

Изменение пароля

Запись пароля в хранилище паролей

Настройка хранилища паролей для пользователя backup_user

Изменение пароля

Запись пароля в хранилище паролей

Настройка хранилища паролей для пользователя profile_tuz

Изменение пароля

Запись пароля в хранилище паролей

Установка пароля для пользователя kmadmin_pg

Конфигурирование ролевой модели

Установка ролевой модели

Структура скриптов конфигурирования ролевой модели

Запускаемые скрипты

SQL-скрипты

Ansible-скрипты

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

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

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

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

Диагностика