Сценарии администрирования#

Администрирование продукта СУБД Pangolin (PSQ) (далее – Pangolin) осуществляется средствами, которые описаны в этом разделе.

Реализация АРМ администратора#

Для администрирования системы используется утилита psql. Эта утилита представляет собой терминальный клиент для передачи запросов к СУБД и отображения результатов.

psql [параметр...] [имя_бд [имя_пользователя]]

Примечание:

Решение по обеспечению безопасности АРМ администратора должно исходить из окружения конечной АС.

Получение информации об используемой версии#

В данном разделе приведены примеры команд для получения используемой версии Pangolin. Примеры команд одинаковы для любой из используемых ОС.

Для клиентской части#

Чтобы получить название и версию клиентской части Pangolin, запустите любую команду с ключом --product_version, например:

Команда:

pg_ctl --product_version

Результат выполнения команды:

Platform V Pangolin {version}

где:

• Platform V Pangolin SE — альтернативное наименование продукта;

• {version} — версия продукта.

Чтобы получить название и версию PostgreSQL, запустите любую команду с ключом --version, например:

Команда:

pg_ctl --version

Результат выполнения команды:

pg_ctl (PostgreSQL) {PostgreSQL version}

Для серверной части#

Для получения названия и версии продукта серверной части подключитесь к серверу Pangolin, чтобы:

• узнать версию Pangolin:

  Команда:

  SELECT product_version();
  

  Результат выполнения команды:

      product_version
  ---------------------------
  Platform V Pangolin SE {version}
  (1 row)
  

• узнать версию PostgreSQL:

  Команда:

  SELECT version();
  

  Результат выполнения команды:

                                                  version
  ---------------------------------------------------------------------------------------------------------
  PostgreSQL {PostgreSQL version} on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
  (1 row)
  

  Примечание:

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

Получение информации о сборке продукта#

Чтобы получить информацию о сборке Pangolin, запустите любую команду с ключом --product_build_info, например:

Команда:

pg_ctl --product_build_info

Результат выполнения команды:

build 54 (22:27:09 05.02.2022) commit {хеш}

где:

• 54 — порядковый номер сборки продукта;

• 22:27:09 05.02.2022 — время и дата сборки продукта;

• {хеш} — хеш-сумма исходных кодов продукта (идентификатор коммита в git репозитории продукта).

Пример вывода информации о сборке продукта для psql:

Команда:

SELECT product_build_info();

Результат выполнения команды:

build 54 (22:27:09 05.02.2022) commit {хеш}

Примечание:

Вывод может отличаться, но будет сохранена структура и формат.

Получение хеш-суммы внутренней версии компонента продукта#

Для PostgreSQL можно получить хеш-сумму с помощью параметра --product_component_hash, например:

Команда:

pg_ctl --product_component_hash

Интерфейс администратора безопасности Pangolin#

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

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

  • pm_get_policies - вывод списка политик;

  • pm_get_policy_grants - вывод списка разрешений (правил) в составе политики;

  • pm_make_policy - создание политики;

  • pm_grant_to_policy - внесение в политику разрешения на действия над объектом;

  • pm_revoke_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 - разблокировка заблокированной учетной записи администратора безопасности.

Pangolin Pooler. Рекомендации по настройке и использованию#

Pangolin Pooler используется для снижения количества соединений с БД, потому что каждая сессия БД потребляет ресурсы ОЗУ и ЦПУ.

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

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

• Повышается утилизация ЦПУ и ОЗУ-сервера вплоть до OОM killer.

Оптимальное количество соединений с БД фиксируется параметром max_connections, и его значение должно определяться на этапе нагрузочного тестирования, исходя из профиля нагрузки и возможностей КТС.

Рекомендуется начинать со значения max_connections = GREATEST(4 x CPU cores, 100).

При проведении нагрузочного тестирования важно определить тот порог max_connections, после которого производительность СУБД перестает расти.

Pangolin Pooler рекомендуется использовать, когда приложение создает клиентских подключений больше, чем полученное на этапе тестирования значение max_connections (max_client_conn>max_connections) для оптимизации производительности СУБД и экономии ресурсов ОЗУ и ЦПУ-сервера.

Следует придерживаться следующих правил:

• Значение max_db_connections <= max_connections-superuser_reserved_connections-30.

• Выставление параметров min_pool_size = default_pool_size позволяет избежать накладных расходов на повторное открытие и закрытие соединений.

Пример хорошей конфигурации, когда один пользователь (ТУЗ) работает с одной БД:

• max_client_conn = 1000;

• pool_mode = transaction;

• min_pool_size = 200;

• default_pool_size = 200;

• max_db_connections = 200;

• max_user_connections = 200.

Стоит обратить внимание, что параметр default_pool_size задается для пары пользователь/БД, поэтому для каждой созданной БД или подключаемого пользователя потенциально может открываться default_pool_size * total databases * total users соединений. Это необходимо учитывать при настройке параметров max_db_connections и max_user_connections, которые задаются независимо от пользователя и БД соответственно. В таких случаях рекомендуется явно ограничивать количество подключений через параметр pool_size в секции databases для каждой созданной БД.

Pangolin Pooler является однопоточным приложением, поэтому важно следить за утилизацией ядра ЦПУ, на котором оно работает. Также не исключается взаимовлияние серверных процессов и Pangolin Pooler друг на друга в случае работы на одном ядре.

Работа через Pangolin Pooler замедляет отклик от БД в среднем на 5%, так как весь входящий и исходящий трафик проходит через него.

Pangolin Pooler не рекомендуется использовать:

• Когда ядро, на котором работает Pangolin Pooler нагружено более чем на 70%.

• В режимах работы pool_mode = session/statement.

• В режимах работы pool_mode = transaction, при OLTP нагрузках с требованиями более 1000-10000 tps и длительностью операции менее 1-10мс из-за накладных расходов при работе с сокетом, который диагностируются ростом sys_time на ЦПУ.

• В конфигурациях, когда количество клиентских подключений в пределе достигает количества подключений к БД (max_client_conn = max_db_connections при использовании одной БД).

• Для OLAP-нагрузок, требующих большого трафика через Pangolin Pooler.

Пример потенциально нежелательной конфигурации, когда один пользователь (ТУЗ) работает с одной БД:

• max_client_conn = 1000 и более;

• default_pool_size = 1000 и более;

• max_db_connections = 1000 и более;

• max_user_connections = 1000 и более.

Стоит обратить внимание, что перед настройкой параметров подключения Pangolin Pooler необходимо убедиться, что параметр СУБД max_connections обеспечивает требуемое количество подключений и в случае необходимости изменить его.

При создании подключений через HikariCP на стороне приложения в максимальном количестве менее, чем max_connections, рекомендуется подключаться напрямую к БД. Однако в случае, когда суммарное количество клиентских подключений превышает max_connections, рекомендуется использовать Pangolin Pooler с связке с HikariCP, предварительно настроив параметры групп соединений и таймаутов с двух сторон:

• Параметр max_client_conn должен превышать сумму всех возможных подключений с HikariCP = hosts*maximum-pool-size.

• Таймаут на подключение на клиенте должен быть выше, чем на Pangolin Pooler.

Парольные политики#

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

Основные функции механизма:

• расширение функциональности авторизации и смены пароля пользователя в части проверки пароля;

• создание транспортного (временного) пароля;

• хранение истории паролей роли;

• сбор и хранение статистической информации о пароле роли;

• назначение роли парольной политики;

• управление парольной политикой:

  • создание, удаление и изменение политики;

  • активация и деактивация политики;

  • создание, удаление и изменение алгоритма проверки пароля.

Настройка#

Настройки механизма хранятся в файле конфигурации и таблице pg_pp_policy (в приоритете заполненные параметры в таблице). В зависимости от типа конфигурации сервера, парольные политики хранятся в различных файлах:

• для standalone-конфигурации — в файле $PGDATA/postgresql.conf;

• для кластерной конфигурации — в файле /etc/pangolin-manager/postgres.yml.

Подробнее о параметрах в подразделе «Конфигурационные параметры» данного раздела.

Предполагается, что сами политики не имеют имени, поэтому отображается идентификатор (roloid) соответствующей роли (см. раздел «Таблицы»).

Зависимости#

Для работы механизма необходимы:

• библиотека OpenSSL;

• утилита проверки сложности пароля zxcvbn.

Примечание:

Указанное ПО включено в дистрибутив СУБД Pangolin.

Основные параметры#

Обязательные настройки парольной политики#

Обязательные настройки хранятся в таблице pg_pp_policy. Все настройки для парольной политики имеют аналог в конфигурационном файле, это необходимо для возможности задания значений по умолчанию при создании пользователя (см. подраздел «Конфигурационные параметры»). Приоритетными считаются значения в таблице pg_pp_policy (подробнее в разделе «Вычислении значений настроек для парольной политики пользователя»).

Конфигурационные параметры#

В данном разделе более подробно описаны параметры файла postgresql.conf/postgres.yml и их значения по умолчанию.

Настройка хранения паролей#

Время жизни пароля#

Поведение при неудачной аутентификации#

Синтаксические проверки пароля#

Проверка максимального времени неактивности пользователя#

Использование библиотеки zxcvbn#

Использование пользовательской функции проверки пароля#

Проверка вхождения пароля в черный список#

Настройка кеширования#

Параметры управления транспортными паролями#

Таблицы#

В механизме управления парольной политикой используются таблицы pg_pp_history, pg_pp_password, pg_pp_policy.

pg_pp_history#

Таблица ранее использованных паролей pg_pp_history:

pg_pp_password#

Таблица с информацией о текущем пароле pg_pp_password:

pg_pp_policy#

Таблица парольных политик pg_pp_policy:

Представления#

• pp_password_detailed — для мониторинга состояния ролей;

• pp_password — для просмотра кеша парольных политик.

Примечание:

В случае обращения к выводу view при отключенных парольных политиках (password_policies_enable = 'off') вернется пустая таблица, а также будет выведено предупреждение (WARNING).

pp_password_detailed#

Представление для мониторинга состояния ролей.

pp_password#

Представление для просмотра кеша парольных политик.

Функции#

Управление парольными политиками осуществляется соответствующими функциями:

• set_role_policies - создание парольной политики;

• enable_policy - активация парольной политики;

• disable_policy - деактивация парольной политики;

• recognize_password_policy - отображение парольных политик, примененных к роли;

• select_all_password_policies - отображение всех активных политик;

• unblock_role - разблокировка роли.

Описание функциий рассмотрено в документе «Список PL/SQL функций продукта», раздел «Парольные политики» (документ доступен в личном кабинете).

Транспортный пароль#

Транспортный (временный) пароль нужен для аутентификации пользователя с ограничениями на все действия, кроме:

• смены своего пароля;

• чтения из таблиц, расположенных в схемах pg_catalog и information_schema;

• вызовов функций, расположенных в pg_catalog и information_schema;

• использования SET;

• использования SET ROLE TO none;

• использования SET SESSION AUTHORIZATION;

• использования SHOW;

• использования LISTEN/UNLISTEN;

• использования PREPARE/EXECUTE.

Когда администратор меняет пароль пользователю, новый пароль автоматически отмечается как транспортный. При авторизации с транспортным паролем для снятия ограничений пользователь должен сменить пароль на постоянный (команда ALTER ROLE/USER ... WITH PASSWORD), при этом соединение должно быть открыто именно тем пользователем, которому меняется пароль. Такое условие нужно для того, чтобы суперпользователь не смог сменить пароль другому пользователю с транспортного на постоянный, переключившись на другого пользователя с помощью SET SESSION AUTHORIZATION или SET ROLE. При попытке любого другого действия выводится сообщение о запрете по причине авторизации с транспортным паролем. В таком случае необходимо сменить пароль на постоянный.

Схема блокировки запроса с транспортным паролем:

Пароль отмечается как транспортный или явным указанием при его задании, или автоматически при смене пароля другим пользователем. Возможность автоматической отметки определяется параметром (password_policy.transport_password_mark_automatic) конфигурации сервера БД.

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

Управление#

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

Создание парольной политики для пользователя происходит с помощью выполнения PL/pgSQL функции set_role_policies. При этом настройки не будут применены без их активации с помощью функции enable_policy.

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

1. Создайте пользователя:

    CREATE USER username_3 WITH ENCRYPTED PASSWORD <password>
   

   Вывод:

   CREATE ROLE
   

2. Создайте парольную политику для пользователя:

   Пример запроса:

   SELECT * FROM set_role_policies('username_2', check_syntax(1::boolean), min_length(12), alpha_numeric(3), min_special_chars(2), min_uppercase(2), policy_enable(1::boolean));
   

   Вывод:

   -[ RECORD 1 ]---------------------+-------
   roleid                            | username_2
   reuse_time                        |
   in_history                        |
   max_age                           |
   min_age                           |
   grace_login_limit                 |
   grace_login_time_limit            |
   expire_warning                    |
   lockout                           |
   lockout_duration                  |
   max_failure                       |
   failure_count_interval            |
   check_syntax                      | t
   min_length                        | 12
   illegal_values                    |
   alpha_numeric                     | 3
   min_alpha_chars                   |
   min_special_chars                 | 2
   min_uppercase                     | 2
   min_lowercase                     |
   max_rpt_chars                     |
   policy_enable                     | t
   track_login                       |
   max_inactivity                    |
   use_password_strength_estimator   |
   password_strength_estimator_score |
   custom_function                   |
   transport_password_life_time      |
   

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

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

Алгоритм вычисления парольной политики пользователя сводится к заполнению всех полей таблицы pg_pp_policy, за исключением поля roloid:

1. Из таблицы pg_pp_policy собираются все заданные настройки для конкретного пользователя (значение не NULL) по идентификатору.

2. Ищутся все роли, в которые входит данный пользователь.

   Примечание:

   Чтобы пользователь мог наследовать политики у родителей, он должен иметь настройку INHERIT.

3. Для каждой найденной роли по идентификатору роли из таблицы pg_pp_policy выбираются настройки по условию:

   • настройка не была выбрана на шаге 1;

   • значение настройки не NULL.

   Примечание:

   Исключение — все заданные значения параметра customfunction сохраняются в исходном порядке, формируя список функций на выполнение. Указанные функции будут последовательно применены в указанном параметре.

4. Если на шаге 3 для одной настройки было найдено несколько значений, то выбирается наиболее строгое ограничение. Ниже указаны параметры и способ определения строгости значения (от менее к более строгому):

   • reusetime;

   • inhistory;

   • minage;

   • expirewarning;

   • lockoutduration;

   • failurecountinterval;

   • minlength;

   • alphanumeric;

   • minalphachars;

   • minspecialchars;

   • minuppercase;

   • minlowercase;

   • passwordstrengthestimatorscore.

   От более к менее строгому:

   • maxage;

   • graceloginlimit;

   • gracelogintimelimit;

   • maxfailure;

   • maxrptchars;

   • maxinactivity.

   1. Если password_policy.deny_default=off, то:

      • Настройки, которые остались не заданы, заполняются значениями параметров из конфигурационного файла postgresql.conf/postgres.yml.

      • Настройки, которые остались не заданы, заполняются значениями по умолчанию для параметров из конфигурационного файла postgresql.conf/postgres.yml.

   2. Производится проверка на взаимозависимость настроек:

      Настройка	Условие, при котором не работают зависимые настройки	Зависимые настройки
      policyenable	= false	Все остальные
      reusetime	> 0	inhistory
      maxage	= NULL, = 0	graceloginlimit, gracelogintimelimit, expirewarning
      lockout	= NULL, = false	lockoutduration, maxfailure, failurecountinterval
      checksyntax	= NULL, = false	minlength, alphanumeric, minalphachars, minspecialchars, minuppercase, minlowercase, maxrptchars
      tracklogin	= NULL, = false	maxinactivity
      usepasswordstrengthestimator	= NULL, = false	passwordstrengthestimatorscore

5. Если password_policy.deny_default=on, то проверяется, что заданы все обязательные настройки.

Разблокировка пользователя#

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

psql: FATAL:  Role is blocked due to fail authentication attempts
FATAL:  Role is blocked due to fail authentication attempts

Для разблокировки пользователя, администратору потребуется воспользоваться функцией unblock_role.

Рассмотрим пример блокировки пользователя по причине неверно введенных паролей большего количества раз, чем указано в параметре password_policy.max_failure.

Действия по разблокировке пользователя:

1. Выведите текущее состояние пользователя:

   SELECT * FROM pp_password_detailed WHERE roloid = to_regrole('username');
   

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

     -[ RECORD 1 ]----------------------------+-----------------------------------
     roloid                                   | username
     failcounter                              | 6
     lastfailtime                             | 2022-07-19 06:00:05.097145+03
     gracesuccesscounter                      | 0
     lastsuccesstime                          | 2022-07-18 13:36:05.033878+03
     createtime                               | 2022-07-18 07:49:47.175947+03
     unblockexpirytime                        |
     istransportpassword                      | f
     is_auth_available                        | f
     is_blocked                               | t
     check_policy_for_max_age                 | t
     check_policy_for_max_age_text            | OK
     check_policy_for_lockout                 | t
     check_policy_for_lockout_text            | OK
     check_policy_for_inactivity_check        | t
     check_policy_for_inactivity_check_text   | OK
     check_policy_for_password_check          | t
     check_policy_for_password_check_text     | OK
     check_lockout                            | f
     check_lockout_text                       | Role was blocked with 6 fail authentification attempts. Last fail at 19.07.2022 06:00:05 Role wasnt unblocked.
     check_inactivity                         | t
     check_inactivity_text                    | OK. Inactivity check is off.
     check_password_age                       | t
     check_password_age_text                  | OK. Max_age check is off.
     check_policy_for_transport_password      | t
     check_policy_for_transport_password_text | OK
     check_transport_password_life_time       |
     check_transport_password_life_time_text  |
   

   Пользователь заблокирован, на это указывают поля:

   • failcounter=6;

   • lastfailtime=“2022-07-19 06:00:05.097145+03“;

   • is_blocked=“t“;

   • в поле check_lockout_text также сообщение о том, что роль была заблокирована в результате 6 неудачных попыток аутентификации.

2. Выполните разблокировку пользователя:

   SELECT unblock_role('username');
   

3. Проверьте состояние пользователя после разблокировки:

   SELECT * FROM pp_password_detailed WHERE roloid = to_regrole('username');
   

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

   -[ RECORD 1 ]----------------------------+-----------------------------------
   roloid                                   | username
   failcounter                              | 6
   lastfailtime                             | 2022-07-19 06:00:05.097145+03
   gracesuccesscounter                      | 0
   lastsuccesstime                          | 2022-07-18 13:36:05.033878+03
   createtime                               | 2022-07-18 07:49:47.175947+03
   unblockexpirytime                        | 2022-07-19 06:05:43.197962+03
   istransportpassword                      | f
   is_auth_available                        | t
   is_blocked                               | f
   check_policy_for_max_age                 | t
   check_policy_for_max_age_text            | OK
   check_policy_for_lockout                 | t
   check_policy_for_lockout_text            | OK
   check_policy_for_inactivity_check        | t
   check_policy_for_inactivity_check_text   | OK
   check_policy_for_password_check          | t
   check_policy_for_password_check_text     | OK
   check_lockout                            | t
   check_lockout_text                       | OK. Role was unblocked at 19.07.2022 06:05:43Role was blocked with 6 fail authentification attempts. 
   check_inactivity                         | t
   check_inactivity_text                    | OK. Inactivity check is off.
   check_password_age                       | t
   check_password_age_text                  | OK. Max_age check is off.
   check_policy_for_transport_password      | t
   check_policy_for_transport_password_text | OK
   check_transport_password_life_time       |
   check_transport_password_life_time_text  |
   

   Поле check_lockout_text содержит сообщение о том, что роль была разблокирована.

Замена транспортного пароля ТУЗ#

После окончания процесса развертывания СУБД Pangolin необходимо сменить транспортный пароль ТУЗ на постоянный.

Установить транспортный (temporary) пароль ТУЗ может пользователь с правами групповой роли db_admin.

1. Для этого необходимо выполнить вход Администратором в консоль и переключиться на роль db_admin:

   SET ROLE db_admin;
   

2. Выполнить команду для установки транспортного (temporary) пароля ТУЗ:

   ALTER USER 'name_tuz' WITH TEMPORARY PASSWORD '<password>';
   

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

   Пример подключения ТУЗ к БД и смена пароля:

   => psql -U 'name_tuz' -d 'name db' -p 5433
   

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

   Password for user 'name_tuz':
   psql (13.4)
   SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
   Type "help" for help.
   

   Смена пароля:

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

Диагностика ошибок#

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

Справочник журнальных сообщений#

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

Активация функциональности парольной политики#

1. Установите значение параметра password_policies_enable: 'on' в конфигурационном файле postgresql.conf/postgres.yml.

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

   pg_ctl restart
   

3. Создайте пользователя с простым паролем:

   CREATE USER username_1 WITH ENCRYPTED PASSWORD '123';
   

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

   ERROR:  Syntax check fail: minimum length for password is 16 Syntax check fail:
   minimum number of special characters for password is 1 Syntax check fail: minimum
   number of uppercase characters for password is 1
   

   В результате создания пользователя с паролем, возникла ошибка синтаксической проверки пароля на несоответствие парольным политикам:

   • минимальная длина пароля - 16 символов;

   • минимальное количество спецсимволов - 1 символ;

   • минимальное количество прописных букв - 1 буква.

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

4. Создайте пользователя с паролем, удовлетворяющим настройкам парольной политики:

   CREATE USER username_1 WITH ENCRYPTED PASSWORD 'd*ZGhpFA8jsH451b_';
   

   Вывод:

   CREATE ROLE
   

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

Создание и активация парольной политики для пользователя#

Пример создания парольной политики описан в разделе «Управление».

Просмотр примененных настроек парольной политики для пользователя#

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

1. Создайте пользователя:

    CREATE USER username_3 WITH ENCRYPTED PASSWORD <password>;
   

   Вывод:

   CREATE ROLE
   

2. Выведите информацию о примененной парольной политики для созданного пользователя:

   SELECT * FROM recognize_password_policy_detailed('username_3');
   

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

              policy_name            |  value   | source_type | source
   ----------------------------------+----------+-------------+--------
   reuse_time                        | 365 days | config      |
   in_history                        |          |             |
   max_age                           | 00:00:00 | config      |
   min_age                           | 00:00:00 | config      |
   grace_login_limit                 |          |             |
   grace_login_time_limit            |          |             |
   expire_warning                    |          |             |
   lockout                           | true     | config      |
   lockout_duration                  | 24:00:00 | config      |
   max_failure                       | 6        | config      |
   failure_count_interval            | 00:00:00 | config      |
   check_syntax                      | true     | config      |
   min_length                        | 16       | config      |
   illegal_values                    | true     | config      |
   alpha_numeric                     | 3        | config      |
   min_alpha_chars                   | 0        | config      |
   min_special_chars                 | 1        | config      |
   min_uppercase                     | 1        | config      |
   min_lowercase                     | 0        | config      |
   max_rpt_chars                     | 0        | config      |
   track_login                       | false    | config      |
   max_inactivity                    |          |             |
   use_password_strength_estimator   | true     | config      |
   password_strength_estimator_score | 3        | config      |
   custom_function                   | 0        | config      |
   transport_password_life_time      | 00:00:00 | config      |
   (26 rows)
   

   Поля source_type и source показывают, откуда берется значение для конкретной политики. В приведенном примере видно, что для пользователя применяются параметры парольной политики, взятые из конфигурационного файла (source_type=config).

Просмотр применения метки транспортного пароля#

При просмотре представления pp_password для пользователя с транспортным паролем значение поля istransportpassword равняется True:

SELECT * FROM pp_password WHERE roloid = to_regrole('user2');

-[ RECORD 1 ]-------+-----------------------------
roloid              | user2
failcounter         | 0
lastfailtime        |
gracesuccesscounter | 0
lastsuccesstime     |
createtime          | 2022-07-14 07:38:35.80058+03
unblockexpirytime   |
istransportpassword | t

Деактивация функциональности парольной политики#

1. Установите значение параметра password_policies_enable: 'off' в конфигурационном файле postgresql.conf/postgres.yml.

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

   pg_ctl restart
   

3. Создайте пользователя с простым паролем:

   CREATE USER username_2 WITH ENCRYPTED PASSWORD '123';
   

   Вывод:

   CREATE ROLE
   

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

Генерация и установка постоянного пароля пользователя (включая ТУЗ)#

Генерация пароля осуществляется функцией rotate_password в соответствии с парольной политикой.

Функция генерации пароля rotate_password создает новый пароль для выбранного пользователя и:

• возвращает его в качестве результата;

• изменяет его в БД.

Входные параметры функции rotate_password:

• (обязательный) Oid или имя пользователя;

• (не обязательный) длина пароля. При отсутствии будет сгенерирован по минимальной длине пароля согласно парольным политикам (случайная длина до 5 символов).

Выходной параметр: сгенерированный пароль.

Пример запроса генерации пароля для пользователя User1:

SELECT * FROM rotate_password('User1');

Настройка#

Функция генерации пароля доступна при установленном расширении psql_rotate_password.

1. Откройте конфигурационный файл postgersql.conf.

2. Добавьте или измените следующие параметры:

   • rotate_password_enable = 'on' — включение функции генерации пароля;

   • rotate_password_num_rounds:'20' — количество попыток генерации пароля;

   • rotate_password.valid_roles = 'user1, user2, user3' — список пользователей (через запятую), для которых разрешена генерация пароля.

3. При изменении параметров перечитайте конфигурацию (reload).

Диагностика ошибок#

При использовании функции могут возникать следующие ошибки:

• Исчерпано количество попыток: превышено значение параметра rotate_password_num_rounds;

• Пользователь не входит в список ролей: убедитесь, что пользователь указан в параметре rotate_password.valid_roles;

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

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

1. Установите значение („username“) параметра rotate_password.valid_roles в конфигурационном файле. Для применения изменений перечитайте конфигурацию (reload).

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

   SELECT *
   FROM
   set_role_policies('username',
   policy_enable(1::boolean),
   check_syntax(1::boolean),
   min_length(16),
   illegal_values(0::boolean), 
   alpha_numeric(5),
   min_alpha_chars(1),
   min_special_chars(1),
   min_uppercase(1),
   min_lowercase(1),
   max_rpt_chars(2),
   use_password_strength_estimator(0::boolean),
   transport_password_life_time('3 days'));
   

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

   -[ RECORD 1 ]---------------------+-------
   roleid                            | username
   reuse_time                        |
   in_history                        |
   max_age                           |
   min_age                           |
   grace_login_limit                 |
   grace_login_time_limit            |
   expire_warning                    |
   lockout                           |
   lockout_duration                  |
   max_failure                       |
   failure_count_interval            |
   check_syntax                      | t
   min_length                        | 16
   illegal_values                    | f
   alpha_numeric                     | 5
   min_alpha_chars                   | 1
   min_special_chars                 | 1
   min_uppercase                     | 1
   min_lowercase                     | 1
   max_rpt_chars                     | 2
   policy_enable                     | t
   track_login                       |
   max_inactivity                    |
   use_password_strength_estimator   | f
   password_strength_estimator_score |
   custom_function                   |
   transport_password_life_time      | 3 days
   

3. Сгенерируйте пароль для пользователя:

   SELECT *
   FROM rotate_password('username');
   

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

   rotate_password
   --------------------
   x3<2BTf?ma3P119_fs
   (1 row)
   

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

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

Настроечные параметры PostgreSQL#

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

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

Параметры, выведенные из хранения в защищенном хранилище/VAULT#

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

• pg_hba.conf – методы аутентификации и подключения;

• shared_preload_libraries, jit_provider – подгружаемые PostgreSQL библиотеки;

• local_preload_libraries, session_preload_libraries – подгружаемые PostgreSQL библиотеки;

• dynamic_library_path – путь к динамически подгружаемым модулям;

• password_encryption – метод хеширования паролей пользователей.

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

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

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

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

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

  Примечание:

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

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

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

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

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

  Примечание:

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

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

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

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

Внимание!

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

Генерация сертификатов#

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

Подготовка сертификатов не выполняется инсталлятором Pangolin. Ожидается, что на хосте уже есть сертификаты, которые будут переданы на вход инсталлятору. Инсталлятор сам разместит их в нужных директориях и выдаст права для служебных пользователей (например, etcd).

• Серверный сертификат (необходимо создать для каждого хоста в кластере):

  1. Сгенерируйте ключ:

     openssl genrsa -out server.key 2048
     

  2. Создайте файл конфигурации для создания запроса на подпись сертификата vim server.conf:

     [req]
     req_extensions = v3_req
     distinguished_name = req_distinguished_name
     [req_distinguished_name]
     [ v3_req ]
     basicConstraints = CA:FALSE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     subjectAltName = @alt_names
     [ ssl_client ]
     extendedKeyUsage = clientAuth, serverAuth
     basicConstraints = CA:FALSE
     subjectKeyIdentifier=hash
     authorityKeyIdentifier=keyid,issuer
     subjectAltName = @alt_names
     [ v3_ca ]
     basicConstraints = CA:TRUE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     subjectAltName = @alt_names
     authorityKeyIdentifier=keyid:always,issuer
     [alt_names]
     DNS.1 = <host> ## hostname with domain
     IP.1 = <IP-адрес> ## host ip address
     

  3. Экспортируйте файл конфигурации:

     CONFIG=`echo $PWD/server.conf`
     

  4. Создайте запрос на подпись сертификата. В CN необходимо указать полный hostname:

     openssl req -new -key server.key -out server.csr -subj "/CN=<host>" -config ${CONFIG}
     

• Клиентский сертификат:

  1. Сгенерируйте ключ:

     openssl genrsa -out postgres.key 2048
     

  2. Создайте файл конфигурации для создания запроса на подпись сертификата vim client.conf:

     [req]
     req_extensions = v3_req
     distinguished_name = req_distinguished_name
     [req_distinguished_name]
     [ v3_req ]
     basicConstraints = CA:FALSE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     [ ssl_client ]
     extendedKeyUsage = clientAuth
     basicConstraints = CA:FALSE
     subjectKeyIdentifier=hash
     authorityKeyIdentifier=keyid,issuer
     [ v3_ca ]
     basicConstraints = CA:TRUE
     keyUsage = nonRepudiation, digitalSignature, keyEncipherment
     authorityKeyIdentifier=keyid:always,issuer
     

  3. Экспортируйте файл конфигурации:

     CONFIG=`echo $PWD/client.conf`
     

  4. Создайте запрос на подпись сертификата. В CN необходимо указать имя клиента/компонента (postgres, patroni, patronietcd, pgbouncer):

     openssl req -new -key postgres.key -out postgres.csr -subj "/CN=postgres" -config ${CONFIG}
     

  Примечание:

  При создании клиентских сертификатов, в поле subjectAltName можно указать IP-адрес или(и) DNS-имя машины (список машин), на которой(ых) будет использоваться сертификат. Также в этом поле можно указать адрес подсети.

Сгенерированные запросы на подпись сертификатов (файлы в формате *.csr) необходимо подписать удостоверяющем центре.

Полученные сертификаты необходимо перевести в формат PEM (например, командой openssl x509 -inform DER -outform PEM -in ./certificate.cer -out ./certificate.crt), расположить в одинаковых директориях на каждом хосте и выдать права - 600 для ключей и 644 для сертификатов, владелец — УЗ ОС postgres.

Наименование сертификатов, с которыми будет работать инсталлятор:

Поскольку в Pangolin можно указать только один корневой сертификат, а в нашем случае их два (один — УЦ непосредственно выпустивший сертификат, второй — УЦ выпустивший сертификат для УЦ и имеющий признак CA), необходимо объединить сертификаты корневого и промежуточного УЦ в один:

cat root.crt intermediate.crt > rootCA.crt

Все корневые сертификаты необходимо скопировать в папку /etc/pki/ca-trust/source/anchors и выполнить команду обновления хранилища доверенных корневых сертификатов:

sudo update-ca-trust

Настройка компонентов#

Внимание!

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

Произведите настройку компонентов на использование сертификатов (задача инструмента развертывания):

1. В файле postgres.conf (для стендов в конфигурации standalone-postgresql-pgbouncer). В данном случае необходимо указать путь к подписанным сертификатам для сервера БД:

   ssl = 'on'
   ssl_cert_file = '/home/postgres/ca/server.crt'
   ssl_key_file = '/home/postgres/ca/server.key'
   ssl_ca_file = '/home/postgres/ca/rootCA.crt'
   ssl_crl_file = 'путь к файлу со списком отозванных сертификатов'
   

2. В pangolin-pooler.ini добавьте секцию TLS-настроек. Между Pangolin Pooler и Pangolin настраивается обязательное SSL-соединение, между Pangolin Pooler и клиентом — по требованию клиента. В обоих случаях минимальная версия TLS 1.2 и соответствующие ему шифры (Cipher suites (TLS 1.2): ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384).

   #  TLS settings
   server_tls_protocols = secure
   server_tls_ciphers = secure
   server_tls_sslmode = verify-full
   server_tls_ca_file = /home/postgres/ca/rootCA.crt
   server_tls_cert_file = /home/postgres/ca/pgbouncer.crt
   server_tls_key_file = /home/postgres/ca/pgbouncer.key
   client_tls_protocols = secure
   client_tls_ciphers = secure
   client_tls_sslmode = prefer
   client_tls_ca_file = /home/postgres/ca/rootCA.crt
   client_tls_cert_file = /home/postgres/ca/server.crt
   client_tls_key_file = /home/postgres/ca/server.key
   

3. В etcd.conf значения http переведите в https и добавьте секцию настроек TLS. Аутентификация в БД etcd происходит по паролю, так же необходимо указать сертификат пользователя.

   ETCD_NAME="<hostname>"
   ETCD_LISTEN_CLIENT_URLS="https://<IP-адрес>:2379"
   ETCD_ADVERTISE_CLIENT_URLS="<hostname>:<порт>"
   ETCD_LISTEN_PEER_URLS="https://<IP-адрес>:2380"
   ETCD_INITIAL_ADVERTISE_PEER_URLS="<hostname>:<порт>"
   ETCD_INITIAL_CLUSTER_TOKEN="test"
   ETCD_INITIAL_CLUSTER="<hostname>:<порт>,<hostname>:<порт>,<hostname>:<порт>"
   ETCD_INITIAL_CLUSTER_STATE="new"
   ETCD_DATA_DIR="/var/lib/etcd"
   ETCD_ELECTION_TIMEOUT="5000"
   ETCD_HEARTBEAT_INTERVAL="1000"
   ETCD_ENABLE_V2="false"
   # TLS settings
   ETCD_CIPHER_SUITES="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
   ETCD_TRUSTED_CA_FILE="/home/postgres/ca/rootCA.crt"
   ETCD_CERT_FILE="/home/postgres/ca/server.crt"
   ETCD_KEY_FILE="/home/postgres/ca/server.key"
   ETCD_PEER_TRUSTED_CA_FILE="/home/postgres/ca/rootCA.crt"
   ETCD_PEER_CERT_FILE="/home/postgres/ca/server.crt"
   ETCD_PEER_KEY_FILE="/home/postgres/ca/server.key"
   ETCD_PEER_CLIENT_CERT_AUTH="true"
   ETCD_PEER_CRL_FILE="путь к файлу со списком отозванных сертификатов"
   

4. В файле конфигурации pangolin-manager postgres.yml внесите изменения в секции restapi, etcd3, postgres, pg_hba.

   1. restapi добавить параметры verify_client, cafile, certfile, keyfile - пути до сертификатов. Параметр verify_client: optional - означает, что все запросы «управления» PUT, POST, PATCH, DELETE требуют аутентификации по сертификатам. Параметры allowlist: [] allowlist_include_members: true - означают, что доступ к запросам «управления» есть только у членов кластера и хостов, которые перечислены в allowlist. Запросы GET (только получение сведений о кластере) будут возвращаться без аутентификации.

      restapi:
          listen: <IP-адрес>:8008
          connect_address: <hostname>:<порт>
          allowlist: []
          allowlist_include_members: true
          verify_client: optional
          cafile: /home/postgres/ca/rootCA.crt
          certfile: /home/postgres/ca/server.crt
          keyfile: /home/postgres/ca/server.key
          authentication:
              username: patroniyml
              password: <пароль>
      

   2. В секции etcd добавьте параметры protocol, cacert, cert, key. Соединение с etcd будет осуществляться по протоколу HTTPS.

      etcd:
          hosts: <hostname>:<порт>,<hostname>:<порт>,<hostname>:<порт>
          protocol: https
          cacert: /home/postgres/ca/rootCA.crt
          cert: /home/postgres/ca/patronietcd.crt
          key: /home/postgres/ca/patronietcd.key
          username: patronietcd
          password: <пароль>
      

5. В секции postgres в подразделе аутентификации пользователя patroni добавьте параметры sslmode, sslkey, sslcert, sslrootcert и в разделе parameters укажите путь к серверному сертификату. sslmode устанавливается в значение verify-ca из-за особенностей локального подключения.

   postgresql:
       listen: <IP-адрес>:5433
       bin_dir: /usr/pgsql-se-05/bin
       connect_address: <hostname>:<порт>
       data_dir: /pgdata/0{major_version}/data/
       create_replica_methods:
           - basebackup
       basebackup:
           format: plain
           wal-method: fetch
       authentication:
           replication:
               username: patroni
               database: replication
               sslmode: verify-ca
               sslkey: /home/postgres/ca/patroni.key
               sslcert: /home/postgres/ca/patroni.crt
               sslrootcert: /home/postgres/ca/rootCA.crt
               sslcrl: "путь к файлу со списком отозванных сертификатов"
           superuser:
               username: patroni
               sslmode: verify-ca
               sslkey: /home/postgres/ca/patroni.key
               sslcert: /home/postgres/ca/patroni.crt
               sslrootcert: /home/postgres/ca/rootCA.crt
               sslcrl: "путь к файлу со списком отозванных сертификатов"
   
           ssl: 'on'
           ssl_cert_file: /home/postgres/ca/server.crt
           ssl_key_file: /home/postgres/ca/server.key
           ssl_ca_file: /home/postgres/ca/rootCA.crt
           ssl_crl_file: "путь к файлу со списком отозванных сертификатов"
   

6. В секции pg_hba смените метод подключения для УЗ patroni с host на hostssl:

   hostssl all patroni <IP-адрес>/32 scram-sha-256
   hostssl all patroni <IP-адрес>/32 scram-sha-256
   hostssl replication patroni <IP-адрес>/32 scram-sha-256
   hostssl replication patroni <IP-адрес>/32 scram-sha-256
   

7. Если какой-либо сертификат был просрочен или отозван, необходимо выпустить новый, согласно инструкции описанной в разделе «Генерация сертификатов», и, в случае изменения наименования сертификата, произвести настройку компонента, где данный сертификат был задействован. В случае сохранения имени сертификата, необходимо перезапустить сервисы компонентов после замены файлов сертификатов.

Использование сертификатов PKCS#12 в кластере Pangolin#

В версиях Pangolin до 5.3.0 сертификаты и закрытые ключи, используемые для установки TLS/SSL соединений, хранились в кластере Pangolin в формате, не предусматривающем предъявление секрета для доступа к сертификату и/или закрытому ключу. В версии Pangolin, начиная с 5.3.0, в целях повышения уровня информационной безопасности вводится авторизация для использования сертификатов и закрытых ключей на промышленных стендах.

Сертификаты и закрытые ключи, используемые в версии Pangolin 5.2.1, приведены в таблице ниже и используются для установления TLS-соединения между компонентами кластера Pangolin:

С версии Pangolin 5.3.0 данные сертификаты и закрытые ключи, за исключением root.crt и patronietcd.crt/patronietcd.key, хранятся в файловой системе в зашифрованных контейнерах PKCS#12, а парольные фразы для их расшифровки - в зашифрованном виде. Ключ для зашифровывания/расшифровывания парольных фраз генерируется на основе параметров сервера, поэтому файлы с парольными фразами не переносимы между узлами кластера Pangolin.

Примечание:

Следующая ключевая информация хранится в файловой системе в PEM-формате:

• Сертификаты и закрытые ключи etcd (etcd.crt/etcd.key, patronietcd.crt/patronietcd.key), так как этот компонент не поддерживается командой разработки Pangolin.

• Корневой сертификат, которым подписаны сертификаты etcd (может не совпадать с сертификатом, подписавшим сертификаты компонентов Pangolin, Pangolin Pooler и Pangolin Manager.).

• Корневой сертификат root.crt, которым подписаны сертификаты компонентов Pangolin, Pangolin Pooler и Pangolin Manager…

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

• в конфигурационном файле pangolin-manager postgresql.yml параметр pkcs12_config_path в секциях:

  • restapi:

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:authentication:replication/superuser/rewind:

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:parameters:

    • serverssl.pkcs12_config_path: example.p12.cfg;

• в конфигурационном файле СУБД Pangolin postgresql.conf параметр serverssl.pkcs12_config_path;

• в конфигурационном файле Pangolin Pooler pangolin-pooler.ini параметры client_tls_pkcs12_config_path и server_tls_pkcs12_config_path;

• в строке подключения psql:

  • pkcs12_config_path (переменная окружения PKCS12_CONFIG_PATH);

  • pkcs12_passphrase (переменная окружения PKCS12_PASSPHRASE) - используется для предоставления парольной фразы без ручного ввода в случае, если в файле .p12.cfg отсутствует поле passphrase. Парольная фраза может быть как в открытом, так и в зашифрованном виде. Парольная фраза зашифровывается утилитой pg_auth_password.

Формат конфигурационного файла .p12.cfg:

{
"pkcs12": "",      // Путь к контейнеру PKCS#12
"passphrase": ""   // Парольная фраза, зашифрованная ключом на параметрах сервера, либо в открытом виде
}

Для валидации сертификатов компонентов, выполняющих подключение, по умолчанию используется полная цепочка сертификатов в контейнере PKCS#12, если в конфигурационных файлах не прописаны прежние параметры для установки цепочки доверенных сертификатов:

• в конфигурационном файле Pangolin Manager postgresql.yml в секциях:

  • restapi:

    • cafile: /path/to/CAfile.pem;

    • capath: /path/to/CAdir (параметр введен в версии 5.3.0);

  • postgresql:authentication:replication/superuser/rewind:

    • sslrootcert: /path/to/CAfile.pem;

    • sslrootpath: /path/to/CAdir (параметр введен в версии 5.3.0);

  • postgresql:parameters:

    • ssl_ca_file: /path/to/CAfile.pem;

    • ssl_ca_path: /path/to/CAdir (параметр введен в версии 5.3.0);

• в конфигурационном файле СУБД Pangolin postgresql.conf:

  • ssl_ca_file = '/path/to/CAfile.pem';

  • ssl_ca_path = '/path/to/CAdir' (параметр введен в версии 5.3.0);

• в конфигурационном файле Pangolin Pooler pangolin-pooler.ini:

  • client_tls_ca_file = /path/to/CAfile.pem;

  • server_tls_ca_file = /path/to/CAfile.pem;

  • client_tls_ca_path = /path/to/CAdir (параметр введен в версии 5.3.0);

  • server_tls_ca_path = /path/to/CAdir (параметр введен в версии 5.3.0);

• в строке подключения psql:

  • sslrootcert = /path/to/CAfile.pem (переменная окружения PGSSLROOTCERT);

  • sslrootpath = /path/to/CAdir (переменная окружения PGSSLROOTPATH (параметр введен в версии 5.3.0)).

Если один из этих параметров указан, то он будет использоваться для инициализации цепочки доверенных сертификатов для проверки сертификатов: со стороны сервера - клиентского сертификата, со стороны клиента - серверного сертификата. В дополнение к приведенным вариантам поиска доверенных сертификатов добавлен поиск среди доверенных сертификатов операционной системы. Настроечный параметр для этого не требуется.

Примечание:

Клиентские компоненты кластера (psql) используют полную цепочку сертификатов в контейнере PKCS#12 для валидации сертификатов, если в строке подключения параметр sslmode установлен в verify-ca или verify-full.

Порядок поиска доверенных сертификатов:

• если не используются параметры, указывающие на файл, либо директорию с сертификатами: сначала в полной цепочке сертификатов из контейнера PKCS#12, затем в директории ОС, указанной по умолчанию;

• если используются параметры, указывающие на файл и/или директорию с сертификатами: сначала в файле, содержащем один или несколько доверенных сертификатов, затем в директории, если установлена, и, если в них не удалось найти нужный сертификат, то - в директории ОС, указанной по умолчанию.

Возможность конфигурирования сертификатов через PEM-файлы сохранена.

Реализация интерфейса получения контейнера PKCS#12 и парольной фразы к нему выполнена в виде плагинов (подключаемых модулей). В директории установки Pangolin созданы символические ссылки на плагины:

/usr/pangolin-{version}/lib/libpkcs12_exporter_plugin_link.so -> plugins/libpkcs12_exporter_plugin.so
/usr/pangolin-{version}/lib/libpkcs12_passphrase_plugin_link.so -> plugins/libpkcs12_passphrase_plugin.so

Для контроля сроков действия сертификатов и проверки подписи локальным корневым сертификатом в контейнерах PKCS#12 предоставляется утилита pkcs12_cert_info. По умолчанию поиск корневого сертификата также ведется в системных директориях по умолчанию. Утилита принимает на вход аргументы: путь к конфигурационному файлу со стратегией получения контейнера PCKS#12 и парольной фразы –pkcs12_config_path (-p), параметр включения проверки подписи –verify (-v), опционально путь к корневому сертификату –CAfile (-f), опционально путь к директории с корневым сертификатом –CApath (-d), опциональный параметр отключения поиска в директориях по умолчанию –no-CApath (-n).

Справка по использованию утилиты:

$ pkcs12_cert_info -h
Usage:
pkcs12_cert_info <option>...
Options:
--help                   [-h]     This help
--pkcs12_config_path     [-p]     Path to config file with info how to get PKCS#12 file
--verify                 [-v]     Check that PKCS#12 certificate trusted by anchor
--CAfile                 [-f]     Path to root/intermediate certificate file
--CApath                 [-d]     Path to root/intermediate certificate directory
--no-CApath              [-n]     Do not use the default directory of trusted certificates.

Pangolin product version information:
--product_version        prints product name and version
--product_build_info     prints product build number, date and hash
--product_component_hash prints component hash string

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

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

$ pkcs12_cert_info -p /pg_ssl/server.p12.cfg
Certificate:
Issuer: CN=Pangolin_intermediate_CA
Validity
Not Before: Nov  8 10:52:13 2022 GMT
Not After : Nov  5 10:52:13 2032 GMT
Subject: CN=srv-0-154

Private key exists

Certificate chain:
Certificate #1:
Issuer: CN=Pangolin_CA
Validity
Not Before: Nov  8 10:52:13 2022 GMT
Not After : Nov  5 10:52:13 2032 GMT
Subject: CN=Pangolin_intermediate_CA
Certificate #2:
Issuer: CN=Pangolin_CA
Validity
Not Before: Nov  8 10:52:12 2022 GMT
Not After : Nov  5 10:52:12 2032 GMT
Subject: CN=Pangolin_CA

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

• в конфигурационном файле Pangolin Manager postgresql.yml параметр pkcs12_config_path в секциях:

  • restapi;

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:authentication:replication/superuser/rewind;

    • pkcs12_config_path: example.p12.cfg;

  • postgresql:parameters;

    • serverssl.pkcs12_config_path: example.p12.cfg;

• в конфигурационном файле СУБД Pangolin postgresql.conf параметр serverssl.pkcs12_config_path;

• в конфигурационном файле Pangolin Pooler pangolin-pooler.ini параметры client_tls_pkcs12_config_path и server_tls_pkcs12_config_path.

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

Если для подключения к СУБД Pangolin требуется предоставить сертификат, и кластер настроен с использованием контейнеров PKCS#12, хранящихся в файловой системе, то в строке подключения psql необходимо указать параметр pkcs12_config_path с путем до конфигурационного файла .p12.cfg, содержащего путь к контейнеру PKCS#12 и парольную фразу в зашифрованном виде.

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

# В файле /pg_ssl/client.p12.cfg установлена парольная фраза.
$ psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg"

# В файле /pg_ssl/client.p12.cfg установлена парольная фраза. Путь к /pg_ssl/client.p12.cfg указан через переменную окружения.
$ PKCS12_CONFIG_PATH=/pg_ssl/client.p12.cfg psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full"

# В файле /pg_ssl/client.p12.cfg парольная фраза не установлена. Парольная фраза передается в строке подключения в зашифрованном виде.
$ psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg pkcs12_passphrase=$enc$+tsiUlhEuNw4ASyvN6ta0A==$sys$mKb2BejR/MLUBzZQ2PaFs+zXGHDRljMWqX46w0CMmDWtjPDzwbxwNSfDAmVTT3Wu"

# В файле /pg_ssl/client.p12.cfg парольная фраза не установлена. Парольная фраза передается через переменную окружения в зашифрованном виде.
$ PKCS12_PASSPHRASE='$enc$+tsiUlhEuNw4ASyvN6ta0A==$sys$mKb2BejR/MLUBzZQ2PaFs+zXGHDRljMWqX46w0CMmDWtjPDzwbxwNSfDAmVTT3Wu' psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg"

# В файле /pg_ssl/client.p12.cfg парольная фраза не установлена. Требуется ручной ввод парольной фразы.
$ psql "host=$(hostname -f) port=5433 dbname=postgres user=postgres sslmode=verify-full pkcs12_config_path=/pg_ssl/client.p12.cfg"
Enter passphrase for PKCS#12 file:
***

Внимание!

В режиме защищенного конфигурирования (secure_config = on) управление параметром СУБД Pangolin serverssl.pkcs12_config_path выполняется на стороне хранилища секретов.

Если для валидации сертификатов не подходит полная цепочка сертификатов в контейнере PKCS#12, предоставляется возможность использования существующих параметров для установки путей к файлам с полными цепочками доверенных сертификатов или введенных в текущей работе новых параметров для установки директории с доверенными сертификатами:

• в конфигурационном файле Pangolin Manager. postgresql.yml в секциях:

  • restapi;

    • cafile: /path/to/CAfile.pem;

    • capath: /path/to/CAdir;

  • postgresql:authentication:replication/superuser/rewind;

    • sslrootcert: /path/to/CAfile.pem;

    • sslrootpath: /path/to/CAdir;

  • postgresql:parameters;

    • ssl_ca_file: /path/to/CAfile.pem;

    • ssl_ca_path: /path/to/CAdir;

• в конфигурационном файле СУБД Pangolin postgresql.conf:

  • ssl_ca_file = '/path/to/CAfile.pem';

  • ssl_ca_path = '/path/to/CAdir';

• в конфигурационном файле Pangolin Pooler pangolin-pooler.ini:

  • client_tls_ca_file = /path/to/CAfile.pem;

  • server_tls_ca_file = /path/to/CAfile.pem;

  • client_tls_ca_path = /path/to/CAdir;

  • server_tls_ca_path = /path/to/CAdir;

• в строке подключения psql:

  • sslrootcert = /path/to/CAfile.pem (переменная окружения PGSSLROOTCERT);

  • sslrootpath = /path/to/CAdir (переменная окружения PGSSLROOTPATH).

Поиск доверенных сертификатов также выполняется среди доверенных сертификатов операционной системы. Настроечный параметр для этого не требуется.

Пример подготовки директории с доверенными сертификатами:

# Добавление корневого сертификата в директорию с доверенными сертификатами
cp /path/to/panglolin.crt /pg_ssl/root_dir
c_rehash /pg_ssl/root_dir

Пример управления доверенными сертификатами операционной системы CentOS 7.9:

# Добавление корневого сертификата с именем Pangolin_CA в хранилище доверенных сертификатов ОС
sudo cp /path/to/panglolin.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
trust list|grep Pangolin_CA
# Удаление корневого сертификата с именем Pangolin_CA из хранилища доверенных сертификатов ОС
sudo rm /etc/pki/ca-trust/source/anchors/panglolin.crt
sudo update-ca-trust extract
trust list|grep Pangolin_CA

Для контроля сроков действия сертификатов в контейнерах PKCS#12 предоставляется утилита pkcs12_cert_info. Утилита принимает на вход один аргумент: путь к конфигурационному файлу со стратегией получения контейнера PCKS#12 и парольной фразы. Вывод утилиты включает статус наличия закрытого ключа в контейнере, сроки действия сертификата и атрибуты, идентифицирующие сертификат (имя издателя и общее имя сертификата), а также сроки действия полной цепочки сертификатов.

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

• Контейнер PKCS#12, помимо сертификата и закрытого ключа, может содержать полную цепочку сертификатов, включая корневой, которыми подписан сертификат. Для упрощения настройки доверенных SSL/TLS сертификатов в кластере предоставляется возможность использовать цепочку сертификатов из контейнера в качестве доверенных, установив параметр pkcs12_use_ca_chain_from_container в true.

  # Флаг определяет, использовать ли полную цепочку сертификатов в контейнере PKCS#12 в качестве доверенной.
  # Если флаг true, то использовать полную цепочку доверенных сертификатов в контейнере, если есть, в качестве доверенной, иначе - false.
  pkcs12_use_ca_chain_from_container: true
  

• Если вариант с использованием полной цепочки сертификатов из контейнера PKCS#12 не подходит для настройки доверенных SSL/TLS сертификатов, предоставляется возможность установки доверенных сертификатов через следующие параметры:

  pg_certs_pwd:
  root_ca_file: "{{ '' | default('/pg_ssl/root.crt', true) }}" # Использовать PEM файл, который может содержать один или несколько доверенных сертификатов
  root_ca_path: "{{ '' | default('/pg_ssl/root_dir', true) }}" # Использовать подготовленную директорию с доверенными сертификатами
  

• Параметры для поддержки использования сертификатов и закрытых ключей из контейнеров PKCS#12, расположенных в файловой системе:

  # Активация получения контейнера PKCS#12 и парольной фразы к нему из файловой системы.
  # Если флаг true, то устанавливаются плагины libpkcs12_passphrase_plugin.so и libpkcs12_exporter_plugin.so.
  # Если флаг false, то используется прежний подход для получения ключевой информации: из файлов в PEM формате. Плагин не устанавливается.
  pkcs12_plugin_enable: true
  
  pg_certs_pwd:
  # Установка параметра p12_path обязательна при активации флага pkcs12_plugin_enable.
  server_p12:
  p12_path: "{{ '' | default('/home/postgres/ssl/server.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с серверной ключевой парой и цепочкой доверенных сертификатов.
  p12_pass: "{{ '' | default('', true) }}" # Парольная фраза для доступа к контейнеру PKCS#12 (server.p12), зашифрованная средствами Ansible Vault (в ходе установки парольная фраза расшифровывается и сохраняется в файл по пути p12_config_path (см. ниже) в зашифрованном виде на ключе, сгенерированном на параметрах сервера). Параметр обязателен в случае установки параметра p12_path.
  p12_config_path: "{{ '' | default('/home/postgres/ssl/server.p12.cfg', true) }}" # Путь к файлу в JSON-формате, содержащему параметр ("passphrase") для получения парольной фразы для доступа к контейнеру PKCS#12, зашифрованную на ключе, сгенерированном на параметрах сервера, и параметр ("pkcs12") для получения контейнера PKCS#12. Параметр обязателен при установке флага pkcs12_plugin_enable в true.
  
  postgres_p12:
  p12_path: "{{ '' | default('/home/postgres/ssl/client.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с клиентской ключевой парой пользователя postgres и цепочкой доверенных сертификатов
  p12_pass: "{{ '' | default('', true) }}"
  p12_config_path: "{{ '' | default('/home/postgres/ssl/client.p12.cfg', true) }}"
  
  pgbouncer_p12:
  p12_secman_integration: true
  p12_path: "{{ '' | default('/home/postgres/ssl/pgbouncer.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с клиентской ключевой парой Pangolin Pooler и цепочкой доверенных сертификатов для подключения к СУБД Pangolin
  p12_pass: "{{ '' | default('', true) }}"
  p12_config_path: "{{ '' | default('/home/postgres/ssl/pgbouncer.p12.cfg', true) }}"
  
  patroni_p12:
  p12_path: "{{ '' | default('/home/postgres/ssl/patroni.p12', true) }}" # Путь в файловой системе к контейнеру PKCS#12 с клиентской ключевой парой и цепочкой доверенных сертификатов для подключения Pangolin Manager к СУБД Pangolin
  p12_pass: "{{ '' | default('', true) }}"
  p12_config_path: "{{ '' | default('/home/postgres/ssl/patroni.p12.cfg', true) }}"
  
  etcd_cert: "{{ '' | default('/home/postgres/ssl/etcd.crt', true) }}" # Путь к сертификату для взаимодействия экземпляров ETCD. Может быть подписан сертификатом, отличным от сертификата, подписавшего сертификаты компонентов Pangolin, Pangolin Pooler, Pangolin Manager. Тогда потребуется указать путь к корневому сертификату в параметре etcd_root_ca.
  etcd_key: "{{ '' | default('/home/postgres/ssl/etcd.key', true) }}" # Путь к приватному ключу для взаимодействия экземпляров ETCD
  etcd_root_ca: "{{ '' | default('/home/postgres/ssl/root_etcd.crt', true) }}" # Корневой сертификат для проверки действительности сертификатов ETCD
  

  Примечания к ключам словаря pg_certs_pwd:

  • p12_path - путь в файловой системе к контейнеру PKCS#12 с ключевой парой и цепочкой доверенных сертификатов.

  • p12_pass - парольная фраза для доступа к контейнеру PKCS#12, зашифрованная средствами Ansible Vault. В ходе установки парольная фраза расшифровывается и сохраняется в файл по пути p12_config_path в зашифрованном виде на ключе, сгенерированном на параметрах сервера.

  • p12_config_path - путь к файлу в JSON-формате .p12.cfg, содержащему поле «passphrase» с парольной фразой для доступа к контейнеру PKCS#12 и поле pkcs12 с путем до контейнера PKCS#12. Файл формируется инсталлятором: в поле pkcs12 прописывается путь к контейнеру PKCS#12 (из параметра p12_path), в поле passphrase помещается парольная фраза перешифрованная ключом, сгенерированном на основе параметров сервера (из параметра p12_pass). Формат файла:

    {
    "pkcs12": "",      // Путь к контейнеру PKCS#12
    "passphrase": ""   // Парольная фраза, зашифрованная ключом на параметрах сервера, либо в открытом виде
    }
    

  • etcd_root_ca - путь к корневому сертификату ETCD. Параметр является обязательным при настройке SSL между узлами etcd.

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

  # Флаг, определяющий способ хранения парольной фразы к контейнеру PKCS#12.
  # Если флаг true, то парольная фраза зашифровывается ключом, генерируемым на основе параметров сервера, иначе - парольная фраза в открытом виде.
  pkcs12_encrypt_passphrase: true