Установка#

Pangolin — система управления базами данных, основанная на PostgreSQL. В данном руководстве описываются аспекты Pangolin, связанные с установкой системы.

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

Примечание:

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

Состав дистрибутива#

Единый дистрибутив PSQ-\<версия Pangolin\>-distrib.tar.gz содержит все перечисленные ниже компоненты дистрибутива для запуска установки/обновления:

Диаграмма процесса развертывания Pangolin#

Внимание!

В установке standalone-версии продукта участвуют две машины. Первая – откуда производится запуск ansible-установщика, вторая – целевая, куда разворачивается продукт.

Диаграмма процесса развертывания Pangolin:

Выбор способа установки#

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

• целевая автоматизированная установка Pangolin;

• опциональная ручная установка Pangolin.

Подготовка окружения#

Рекомендуется запускать установку продукта Pangolin в виртуальной среде Python, созданной с помощью инструмента — virtualenv. Создание изолированной среды позволяет избежать конфликтов с уже предустановленными пакетами и не затрагивать существующую среду на текущей машине.

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

Пример для ОС Red Hat Enterprise Linux:

sudo yum install sshpass
sudo yum install python3-pip
sudo python3 -m pip install pip==9.0.0 # или sudo python3 -m pip install --index-url=https://testurl --trusted-host=<trusted-host> pip==9.0.0
sudo python3 -m pip install virtualenv==20.3.1 # или sudo python3 -m pip install --index-url=https://testurl --trusted-host=<trusted-host> virtualenv==20.3.1
virtualenv pg_se_venv --python=python3
source pg_se_venv/bin/activate
pip3 install cffi==1.15.0 cryptography==3.3.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==21.3 pycparser==2.21 pyparsing==3.0.6 PyYAML==6.0 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0 dnspython==2.2.0 # или pip3 install --index-url=https://pypi.org/simple --trusted-host=<trusted-host> cffi==1.15.0 cryptography==3.3.1 Jinja2==2.11.2 jmespath==0.9.4 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==20.9 pycparser==2.21 pyparsing==3.0.6 PyYAML==5.3 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0 dnspython==2.2.0

Пример для РЕД ОС:

sudo dnf reinstall python3-pip
sudo dnf install python3-virtualenv
sudo ln /usr/bin/virtualenv-3 /usr/bin/virtualenv
pip3 install cffi==1.15.0 cryptography==3.3.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==21.3 pycparser==2.21 pyparsing==3.0.6 PyYAML==6.0 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0

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

Закончив работу в виртуальной среде, можно отключить ее, выполнив консольную команду:

deactivate

Перед началом установки сформируйте единый дистрибутив Pangolin из zip-пакета:

1. Получите архив zip-пакета и выполните команду распаковки:

   unzip -q <имя zip-пакета>.zip
   

2. Перейдите в каталог с распакованным zip-пакетом и выполните запуск скрипта по формированию единого дистрибутива:

   sh PSQ-<version>-unpacker-distrib.sh
   

Результатом выполнения будет единый дистрибутив в формате tar.gz (пример: PSQ-<version>-distrib.tar.gz), предназначенный для установки Pangolin.

Ручная установка Pangolin#

Внимание!

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

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

• настройки конфигурационных файлов (postgresql.conf, pg_hba.conf);

• настройки кластерной конфигурации;

• будут отсутствовать компоненты Pangolin (etcd, patroni, pgbouncer, и другие);

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

• настройки расширений;

• настройки ротации журналов;

• и другие.

Установка на ОС Альт СП 8#

1. Создайте директорию с дистрибутивом Pangolin.

   mkdir distrib
   

2. Поместите дистрибутив Pangolin в директорию distrib.

3. Распакуйте дистрибутив Pangolin.

   tar -xf docker-builds-altsp8-1638-distrib.tar.gz
   

4. Установите пакет platform-v-pangolin-dbms-05.005.00-rhel7.9.x86_64.rpm.

   sudo apt-get install platform-v-pangolin-dbms-05.005.00-altlinux8.2.x86_64.rpm
   

5. Создайте директорию $PGDATA и /pgerrorlogs.

   sudo mkdir -p /pgdata/05/
   sudo chown -R postgres:postgres /pgdata/05/
   sudo mkdir -p /pgerrorlogs/05
   sudo chown postgres:postgres /pgerrorlogs/05
   

6. Переключитесь на пользователя postgres (если такого нет, то создайте).

   sudo su - postgres
   

7. Добавьте строку окружения в ~/.bash_profile.

   vim ~/.bash_profile
   umask 022
   export LD_LIBRARY_PATH=/usr/pangolin-5.5.0/lib
   export PATH=$PATH:/usr/pangolin-5.5.0/bin
   export PG_PLUGINS_PATH=/usr/pangolin-5.5.0/lib
   export PGHOME=/usr/pangolin-5.5.0
   export PGDATABASE=postgres
   export PGUSER=postgres
   export PGHOST=<IP-адрес>
   export PGPORT=<Порт>
   export PGCLIENTENCODING=UTF8
   export CLNAME=clustername
   export PGSSLCERT=/pg_ssl/client.crt
   export PGSSLKEY=/pg_ssl/client.key
   export PGSSLROOTCERT=/pg_ssl/root.crt
   NOW=$(date +"%Y-%m-%d")
   export PGDATA=/pgdata/05/data
   export MANPATH=$MANPATH:$PGHOME/share/man
   
   . ~/.bash_profile
   

8. Разверните СУБД.

   initdb -k -D /pgdata/05/data/
   

9. Отредактируйте файл параметров vim $PGDATA/postgresql.conf.

   listen_addresses = '*'
   port = 5433
   max_connections = 100
   superuser_reserved_connections = 3
   
   enabled_extra_auth_methods = 'peer, trust'
   

10. Отредактируйте файл параметров vim $PGDATA/pg_hba.conf.

    local   all             all                                     peer
    host    all             all             0.0.0.0/0               trust
    

11. Запустите экземпляр Pangolin.

    pg_ctl -D /pgdata/05/data/ -l /pgerrorlogs/05/postgresql.log start
    

12. Выполните команду:

    [16:41:22  postgres@srv-0-211 ~]$ psql
    psql (13.4)
    Type "help" for help.
    
    postgres=#
    

Установка на ОС Red Hat Enterprise Linux 7#

1. Создайте директорию с дистрибутивом Pangolin.

   mkdir distrib
   

2. Поместите дистрибутив Pangolin в директорию distrib.

3. Распакуйте дистрибутив Pangolin.

   tar -xf docker-builds-rhel7-1654-distrib.tar.gz
   

4. Установите пакет platform-v-pangolin-dbms-05.005.00-rhel7.9.x86_64.rpm.

   sudo yum -y install platform-v-pangolin-dbms-05.005.00-rhel7.9.x86_64.rpm
   

5. Создайте директорию $PGDATA и /pgerrorlogs.

   sudo mkdir -p /pgdata/05/data
   sudo chown -R postgres:postgres /pgdata/05/
   sudo mkdir /pgerrorlogs
   sudo chown postgres:postgres /pgerrorlogs/05
   

6. Переключитесь на пользователя postgres (если такого нет, то создайте).

   sudo su - postgres
   

7. Добавьте строку окружения в ~/.bash_profile.

   vim ~/.bash_profile
   export PATH=$PATH:/usr/pangolin-5.5.0/bin
   export MANPATH=$MANPATH:/usr/pangolin-5.5.0/share/man
   . ~/.bash_profile
   

8. Разверните СУБД.

   initdb -k -D /pgdata/05/data/
   

9. Отредактируйте файл параметров vim $PGDATA/postgresql.conf.

   listen_addresses = '*'
   port = <Порт>
   max_connections = 100
   superuser_reserved_connections = 3
   
   enabled_extra_auth_methods = 'peer, trust'
   

10. Отредактируйте файл параметров vim $PGDATA/pg_hba.conf.

    local   all             all                                     peer
    host    all             all             0.0.0.0/0               trust
    

11. Запустите экземпляр Pangolin.

    pg_ctl -D /pgdata/05/data/ -l /pgerrorlogs/05/postgresql.log start
    

12. Выполните команду:

    [16:41:22  postgres@srv-0-211 ~]$ psql
    psql (13.4)
    Type "help" for help.
    
    postgres=#
    

Автоматизированная установка Pangolin#

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

• развертывание Pangolin без дополнительных настроек (playbook_install.yaml);

• развертывание ролевой модели, пользовательской БД, схем и расширений (installer/scripts_external/configure_roles/playbook_configure_roles.yaml);

• развертывание пакетов для системы резервного копирования (СРК) (installer/scripts_external/SRC/playbook_SRC.yaml);

• развертывание rsyslog (installer/scripts_external/rsyslog/playbook_rsyslog.yaml);

• настройка monitoring (installer/scripts_external/monitoring/playbook_monitoring.yaml).

Настоящий способ предусматривает установку Pangolin с помощью инсталлятора, поставляемого в составе дистрибутива. Установка может быть произведена как с отдельного хоста, так и с master/replica планируемого кластера. Поддерживается установка cluster и standalone конфигурации.

Шаги выполнения установки#

Подготовьте хост для установки:

1. Установите виртуальное окружение:

   python3 -m venv install_venv #install_venv здесь и далее - имя venv. Может быть любым.
   

2. Активируйте venv и установите необходимые библиотеки:

   source install_venv/bin/activate
   pip3 install cffi==1.15.0 cryptography==3.3.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==21.3 pycparser==2.21 pyparsing==3.0.6 PyYAML==6.0 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0
   pip3 install ansible==4.10.0 # Желательно устанавливать отдельно, так как в процессе пакетной установки предыдущей командой возможны ошибки
   

3. Скачайте дистрибутив из Nexus и распакуйте его:

   wget --user <username> --ask-password <distribuitive_url>
   tar -xvf <distriburive.tar.gz> -C ./distrib/
   cd distrib
   

Подготовьте конфигурационные файлы:

1. Заполните inventory-файл в зависимости от имеющейся конфигурации.

   Файл hosts.ini заполняется в соответствии с шаблоном:

   • standalone (installer/inventories/standalone/hosts.ini);

   • cluster (installer/inventories/cluster/hosts.ini).

   Файл hosts.ini состоит из нескольких групп (имена определены в скобках), которые используются для классификации и определения того, какие хосты будут использоваться. Для установки необходимо заполнить переменные группы postgres_nodes и arbiter_nodes (для claster):

   • ansible_host — в случае установки по ip-адресу указываем ip_address, в случае установки по имени DNS укажите hostname;

   • ansible_user — имя пользователя для использования при подключении к хосту. Должен иметь права для эскалации до root, то есть должен иметь возможность выполнять все команды от имени root;

   • переменная ansible_password должна содержать пароль пользователя в чистом виде или имя переменной, которая будет содержать зашифрованный с помощью ansible-vault пароль.

   Обратите внимание!

   Пароль пользователя следует указывать в кавычках для того, чтобы избежать конфликтов при цитировании специальных символов. Пользователь, указанный в файле hosts.ini, должен обладать правами sudo + nologin.

   Внимание!

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

   Ниже представлены шаблоны файла hosts.ini для standalone и cluster архитектур.

   hosts.ini для standalone:

   [standalone:children]
   postgres_group
   
   [postgres_group:children]
   postgres_nodes
   
   [postgres_group:vars]
   ansible_connection=ssh
   
   [postgres_nodes]
   master  ansible_host=<IP-адрес>  ansible_user=sbt_user   ansible_password="user_passw"
   

   hosts.ini для cluster:

   [cluster:children]
   postgres_group
   arbiter_group
   
   [postgres_group:children]
   postgres_nodes
   
   [arbiter_group:children]
   arbiter_nodes
   
   [postgres_group:vars]
   ansible_connection=ssh
   
   [arbiter_group:vars]
   ansible_connection=ssh
   
   [postgres_nodes]
   master   ansible_host=<IP-адрес> ansible_user=sbt_user  ansible_password=”user_passw”      
   replica  ansible_host=<IP-адрес> ansible_user=sbt_user ansible_password=”user_passw”
   
   [etcd_nodes]
   etcd  ansible_host=<IP-адрес>  ansible_user=sbt_user ansible_password=”user_passw”
   

   Внимание!

   Если в файле hosts.ini переменная ansible_password содержит ansible-vault, то пароль необходимо зашифровать. Ниже приведен пример шифрования текста passwordtest с помощью ansible-vault:

   ansible-vault encrypt_string passwordtest
   New Vault password:
   Confirm New Vault password:
   !vault |
       $ANSIBLE_VAULT;1.1;AES256
       {хеш-1}
       {хеш-2}
       {хеш-3}
       {хеш-4}
       3038
   Encryption successful
   

   В случае, когда пароли для хостов групп postgres_group и arbiter_group совпадают, достаточно вывод команды ansible-vault поместить в inventory-файл сluster.yml/standalone.yml, расположенный в каталоге inventories/(standalone/cluster)/group_vars. Аналогичным образом необходимо перешифровать пароли в файле custom_file_sample.yml пример файла тем же ключом, которым был зашифрован пароль для учетной записи в текущем шаге.

   Примечание:

   Узнать подробнее о Ansible inventory можно в документации Ansible.

2. Заполните настраиваемый конфигурационный файл custom_config_sample.yml.

   Пример конфигурационного файла custom_config_sample.yml, который можно использовать для развертывания продукта со значениями по умолчанию или с минимальными корректировками, находится в каталоге installer/templates/custom_config_sample.yml.

   Поскольку custom_config_sample.yml является примером и вариантом готового решения, некоторые секции и параметры были перенесены в custom_config_initial.yml - конфигурационный файл, содержащий все динамически настраиваемые параметры СУБД Pangolin. При необходимости их можно переопределить в файле custom_config_sample.yml.

   Пример:

   #для конфигурации с применением хранилища ETCD
   patroni_yml:
   etcd:
   hosts: [ <IP-адрес>, <IP-адрес>, <IP-адрес>] #укажите ipv4 хостов кластера ETCD. Обычно для dev-контура это master, replica, arbiter.                                              
   port: 2379 #укажите порт.
   

   Внимание!

   Для etcd по умолчанию рекомендовано использовать порт 2379.

3. Сгенерируйте сертификаты, в случае, если в настраиваемом конфигурационном файле выше было выставлено значение для параметра: mtls_support: true и/или pkcs12_plugin_enable: true.

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

   Если активирован параметр pkcs12_plugin_enable: true, то сертификаты должны быть сгенерированы в формате PKCS#12 или будут получены из Secret Management System (далее – SecMan), в зависимости от заполненных значений в пользовательском конфигурационном файле. Подробнее читайте в документе «Руководстве по системному администрированию», раздел «Использование сертификатов PKCS#12 в кластере Pangolin».

   Для поиска или генерации сертификата в SecMan необходимо активировать параметр use_remote_pki: true и заполнить атрибуты в разделе p12_secman: для каждого сертификата.

   При включенном параметре (mtls_support: true) скрипты развертывания и обновления продукта определяют расположение сертификатов по путям из параметров соответствующего компонента (параметры из секции 3.2.SECURITY SETTINGS (SSL) - pg_certs_pwd) и проверяют их наличие.

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

   "{{ control_name }}.FAIL__Файл сертификата 'root.crt' не найден на хосте. Проверьте наличие файла и значение в пользовательском конфигурационном файле - 'custom_config_sample.yml'__{{ control_name }}.FAIL"
   

   Ниже приведен пример скрипта для генерации сертификатов и распространения их на указанные виртуальные машины:

   #!/bin/sh
   # IP/DNS-записи хостов.
   hosts_list=(127.0.0.1 127.0.0.2 127.0.0.3)
   # Пароль пользователя с root правами.
   ssh_password=(TestPassword!)
   # Пользователь с root-правами.
   ssh_user=(admin_dev)
   mkdir ssl
   cd ssl
   
   openssl req -new -nodes -text -out ./root.csr -keyout ./root.key -subj "/CN=PGSEdevCA"
   openssl x509 -req -in ./root.csr -text -days 3650  -extfile /etc/pki/tls/openssl.cnf -extensions v3_ca -signkey ./root.key -out ./root.crt
   openssl req -new -nodes -text -out ./client.csr -keyout ./client.key -subj "/CN=postgres"
   openssl x509 -req -in ./client.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./client.crt
   openssl req -new -nodes -text -out ./patroni.csr -keyout ./patroni.key -subj "/CN=patroni"
   openssl x509 -req -in ./patroni.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./patroni.crt
   openssl req -new -nodes -text -out ./patronietcd.csr -keyout ./patronietcd.key -subj "/CN=patronietcd"
   openssl x509 -req -in ./patronietcd.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./patronietcd.crt
   openssl req -new -nodes -text -out ./pgbouncer.csr -keyout ./pgbouncer.key -subj "/CN=pgbouncer"
   openssl x509 -req -in ./pgbouncer.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./pgbouncer.crt
   rm *.csr
   
   ######Copy_certs_on_nodes_and_generate_server_cert
   for host in ${hosts_list[@]}
   do
   sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo rm -rf /pg_ssl && sudo mkdir /pg_ssl && sudo chown $(whoami):$(whoami) /pg_ssl'
   sshpass -p ${ssh_password} scp ./* ${ssh_user}@${host}:/pg_ssl
   sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cat << EOT >> /pg_ssl/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]
   EOT'
   
   sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cd /pg_ssl && echo DNS.1 = $(hostname -f) >> server.conf && echo IP.1 = $(hostname -i) >> server.conf && openssl req -new -nodes -text -out ./server.csr -keyout ./server.key -subj "/CN=$(hostname -f)" -config $(echo ./server.conf)'
   sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cd /pg_ssl && openssl x509 -req -in ./server.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./server.crt -extensions ssl_client -extfile $(echo ./server.conf)'
   sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo chmod 0600 /pg_ssl/*.key && sudo chmod 0644 /pg_ssl/*.crt'
   
   ###/etc/pki/ca-trust/source/anchors/ - 'RedHat' /etc/pki/tls/openssl.cnf\ - 'Altlinux' ###
   sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo cp /pg_ssl/root.crt /etc/pki/ca-trust/source/anchors/ && sudo update-ca-trust'
   done
   

   Данные сертификаты не будут подписаны, но будут являться минимальными требуемыми для установки. После установки продукта Pangolin необходимо подписать данные сертификаты в удостоверяющем центре (подробнее о генерации сертификатов смотрите в документе «Руководство администратора», раздел «Генерация сертификатов»).

   Примечание:

   Скрипты развертывания не осуществляют проверку валидности сертификатов.

4. Выполните ansible-сценарий playbook_install.yaml. Заполните параметры, заключенные в < >.

    ansible-playbook -vvv playbook_install.yaml \
    -i inventories/<cluster||standalone>/hosts.ini \
    -t always,<configuration>  \
    -e '{"as_TUZ":['tuz_1']}' \
    --flush-cache \
    --extra-vars 'local_distr_path=<path_to_distributive> \
    installation_type=<cluster||standalone> \
    PGPORT=5433 \
    PGDATA=/pgdata/<major_version>/data \
    PGLOGS=/pgerrorlogs/<major_version> \
    tag=<configuration>\
    clustername=clustername \
    custom_config=templates/custom_config_sample.yml \
    pangolin_license_path=/home/sbt_user/license_trial.json \
    nolog=true' \
   

   Пример команды для cluster:

   ansible-playbook -vvv playbook_install.yaml \
   -i inventories/cluster/hosts.ini \
   -t always,cluster-patroni-etcd-pgbouncer  \
   -e '{"as_admins":['admin_1', 'admin_2']}' \
   -e '{"as_TUZ":['tuz_1']}' \
   --flush-cache \
   --extra-vars 'local_distr_path=/home/pprb_dev/distrib \ #каталог, в который распакован дистрибутив.
   installation_type=cluster \
   PGPORT=5433 \
   PGDATA=/pgdata/06/data \
   PGLOGS=/pgerrorlogs/06 \
   tablespace_name=tbl_name \
   tablespace_location=/pgdata/06/tablespaces \
   schema_name=shema \
   tag=cluster-patroni-etcd-pgbouncer \
   db_name=first_db \
   clustername=clustername \
   custom_config=templates/custom_config_sample.yml \
   nolog=true \
   pangolin_license_path=/home/sbt_user/license_trial.json' \ #путь к файлу лицензии
   

   Примечание:

   pangolin_license_path — полный путь к файлу лицензии, например, pangolin_license_path=/home/admin/license_trial.json. Имя файла значения не имеет.

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

   • license_standard_1C;

   • license_standard;

   • license_enterprise_1C;

   • license_enterprise;

   • license_trial;

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

   • standalone-postgresql-only;

   • standalone-postgresql-pgbouncer;

   • standalone-patroni-etcd-pgbouncer;

   • cluster-patroni-etcd-pgbouncer;

   Запуск установки осуществляется из каталога installer. Ниже приведены шаблоны ansible-сценариев для установки standalone и cluster решений:

   • Установка standalone решения Pangolin с Pangolin Pooler:

     ansible-playbook playbook_install.yaml \
     -i inventories/standalone/hosts.ini \
     -t always,standalone-postgresql-pgbouncer \
     -vv \
     -e '{"as_admins":['test_admin']}' \
     -e '{"as_TUZ":['test_tuz']}' \
     --extra-vars 'local_distr_path=${} \
     installation_type=standalone \
     tag=standalone-postgresql-pgbouncer \
     segment=${} \
     custom_config=${}' \
     --ask-vault-pass
     

   • Установка кластерного решения Pangolin с Pangolin Manager, etcd и Pangolin Pooler:

     ansible-playbook playbook_install.yaml \
     - i inventories/cluster/hosts.ini \
     -t always,cluster-patroni-etcd-pgbouncer \
     -vv \
     -e '{"as_admins":['test_admin']}' \
     -e '{"as_TUZ":['test_tuz']}' \
     --extra-vars 'local_distr_path=${} \
     installation_type=cluster \
     tag=cluster-patroni-etcd-pgbouncer \
     segment=${} \
     pangolin_license_path=${} \
     custom_config=${}' \
     --ask-vault-pass
     

Примеры ansible-сценариев#

Далее будут рассмотрены примеры:

1. Ansible-сценарий для установки кластерного решения Pangolin с Pangolin Manager, etcd, Pangolin Pooler:

   ansible-playbook playbook_install.yaml \
   -i inventories/cluster/hosts.ini \
   -t always,cluster-patroni-etcd-pgbouncer \
   -vv \
   -e '{"as_admins":['admin_1', 'admin_2']}' \
   -e '{"as_TUZ":['tuz_1']}' \
   --extra-vars 'local_distr_path=${} \
   installation_type=cluster \
   tag=cluster-patroni-etcd-pgbouncer \
   segment={segment} \
   pangolin_license_path=/home/admin/license_trial.json \
   custom_config=templates/custom_config_sample.yml' \
   --ask-vault-pass
   

   Внимание!

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

   • /pgdata/data -> /pgdata/05;

   • /usr/pangolin -> /usr/pangolin-5.5.4.

   Значения используемых в команде запуска Ansible ключей:

   • -i — путь к inventory-файлу;

   • -t — теги для запуска;

   • -vv — уровень логирования Ansible. Может быть, как пустым, так и -vvvvvv, где запуск без v - минимальное логирование;

   • -e, --extra-vars — переменные, которые по приоритету важнее переменных из inventory;

   • --ask-vault-pass или --vault-password-file — расшифровка зашифрованных файлов во время выполнения.

   Внимание!

   Для зашифровки паролей в примерах выше, использовался следующий ansible-vault пароль: postgreSQL_SE_654321.

   Используемые переменные:

   • as_admins — Active Directory логин или логины будущих администраторов АС. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_admins":['admin, test_admin]}';

   • as_TUZ — логины ТУЗ, которые будут созданы в результате установки. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_TUZ":['tuz, test_tuz]}';

   • local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;

   • segment — сегмент сети;

   • custom_config — абсолютный путь к файлу конфигурации custom_config_sample.yml.

   Внимание!

   Параметр инсталлятора stand, ранее отвечавший за настройку DEV-стенда, с версии 5.5.0 исключен. Настройка DEV-стендов инсталлятором не производится.

   Внимание!

   В случае, если все пароли указывались в открытом виде, параметр --ask-vault-pass и --vault-password-file=название_файла_с_ключем добавлять не нужно!

   Внимание!

   В случае, если вам необходимо развернуть стенд с дополнительными настройками ролевой модели, пользовательской БД, схемами и расширениями необходимо отдельно запустить playbook_configure_roles.yaml или sh-скрипт run_configure.sh развертывания ролевой модели, который располагается в компоненте installer по пути scripts_external/configure_roles/configure_roles/templates/role_BASIC/run_configure.sh. Ролевая модель и скрипты ее настройки описаны в документе «Руководство администратора», раздел «Ролевая модель и права доступа».

2. Ansible-сценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью ansible-роли:

   ansible-playbook playbook_configure_roles.yaml \
   -i inventories/cluster/hosts.ini \
   -t always,cluster-patroni-etcd-pgbouncer \
   -vv \
   -e '{"as_admins":['test_admin']}' \
   -e '{"as_TUZ":['test_tuz']}' \
   --extra-vars 'local_distr_path=${} \
   PGPORT=${} \
   PGDATA=${} \
   PGLOGS=${} \
   tablespace_name=${} \
   tablespace_location=${} \
   schema_name=${} \
   tag=cluster-patroni-etcd-pgbouncer \
   db_name=${} \
   custom_config=${}' \
   --ask-vault-pass
   

   Используемые переменные:

   • as_admins — Active Directory логин или логины будущих администраторов АС. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_admins":['admin, test_admin]}';

   • as_TUZ — логины ТУЗ, которые будут созданы в результате установки. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_TUZ":['tuz, test_tuz]}';

   • local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;

   • PGPORT — порт для взаимодействия с базой данных Pangolin;

   • PGDATA — полный путь к каталогу, где будет расположена инициализированная база данных;

   • PGLOGS — полный путь к каталогу, где будут расположены логирующие файлы;

   • pangolin_license_path — задает путь к директории, которая содержит лицензии или путь к конкретному файлу лицензии. Данная переменная окружения используется самим сервером и его утилитами для получения данных об используемой лицензии. По умолчанию используется директория /opt/pangolin_license;

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

   • tablespace_location — полный путь к каталогу, где будет расположено созданное табличное пространство;

   • schema_name — имя схемы, которая будет создана в результате установки;

   • db_name — имя базы данных, которая будет создана в результате установки;

   • custom_config — абсолютный путь к файлу конфигурации custom_config_sample.yml;

   Внимание!

   В случае, если не планируется использовать custom_config, есть возможность настройки параметров запуска через файл variables.yml, расположенный в роли configure_roles (scripts_external/configure_roles/group_vars/variables.yml).

3. Сценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью запускаемого bash-скрипта:

   sh ./role_BASIC/run_configure.sh -d First_db -s Sch1 -t Tbl_t -l /pgdata/06/tablespaces -m <IP-адрес> -r <IP-адрес> -p <Порт> -a 'user1 user2' -u 'user3 user4' -w /home/postgres/role_BASIC -c "0,30 * * * *" -g  "'as_admin_pass':SCRAM-SHA-256$4096:2H6ypfV3DJP0LUZLrSnPsA==$yOIhGySEsNiY9p91PkJ5a2/kUQhxAwzUAQcjwCHov3A=:gd7X+KDJ+4GY44H9Xelan5dkhLwLLyDZLrhw4LhmDo8= 'as_tuz_pass':SCRAM-SHA-256$4096:TTysuRbQcMM3tOQAoR7LWg==$t89DzT7Y92HXMQxolmGXxG8AGQPvu/yDWV4leOAXiO0=:0vZGdq40uKFLLzfzB2JJ9SD1Ei8rxSObHUlPUcdHByM=" -f "'pg_profile':True 'rotate_password':True 'psql_lockmon_is_enable':True"  -e 'infinity' -v 'TEMPORARY' -k 'backup_user' -z false -o 'en_US.UTF-8' -n 'postgres'
   

   Используемые параметры:

   • d, dbname – имя пользовательской БД;

   • s, schname – имя пользовательской схемы;

   • t, tsname – имя пользовательского табличного пространства;

   • l, tsloc - путь к табличному пространству;

   • m, mhost - ip-адрес хоста мастера (данный параметр является обязательным, так как используется для настройки расписания pg_cron);

   • r, rhost ip-адрес хоста реплики (данный параметр является обязательным, так как используется для настройки расписания pg_cron);

   • p, port - порт PostgreSQL;

   • a, asadm – список ТУЗ as_admin;

   • u, astuz - список ТУЗ as_TUZ;

   • w, way - путь к папке со скриптами конфигурирования (данный параметр является обязательным);

   • c, cronp - период времени для cron job pg_profile;

   • g, grpas - список паролей для УЗ (передается в виде словаря, например: as_admin_pass':passwd1 'zabbix_pass':passwd2);

   • f, fchlst - список включаемой функциональности при развертывании (передается в виде словаря, например: 'pg_profile':True 'rotate_password':False);

   • e, expdt - параметр времени жизни УЗ (expire date);

   • v, vrpas - флаг, указывающий на использование временных паролей;

   • k, backusname - имя пользователя для резервного копирования (по умолчанию backup_user);

   • z, tdeadm - включить/выключить TDE;

   • o, locale - параметр для определения locale при создании пользовательской БД (должен совпадать с параметром, установленным при развертывании);

   • n, prdbname - имя пользовательской БД, где будет создан pg_profile;

Действия, которые необходимо выполнить, в случае неудачной установки#

В случае, если установка прошла неудачно:

• Перед началом новой установки необходимо очистить КТС. Для этого выполните:

  sudo systemctl stop patroni; sudo systemctl stop pgbouncer; sudo systemctl stop etcd; sudo systemctl stop confd; sudo yum remove python-psycopg2 -y; sudo pip uninstall psycopg2-binary -y; sudo yum remove postgresql-sber-edition -y; sudo yum remove etcd -y; sudo pip uninstall patroni -y; sudo yum remove confd -y; sudo yum remove haproxy -y; sudo rm -rf /usr/local/pgsql/; sudo rm -rf /usr/pgsql-se-04.003.00/; sudo rm -rf /usr/pgsql-se-04/; sudo rm -rf /usr/pgsql-se-05/; sudo yum remove -y etcd postgresql-sber-edition; sudo su -c "rm -rf /pgsql/"; etcdctl rm service/clustername/initialize; sudo rm -rf /etc/etcd; sudo rm -rf /etc/confd; sudo rm -rf /etc/pgbouncer; sudo rm -rf /etc/patroni; sudo rm -rf /pgdata/; sudo rm -rf /pgerrorlogs/; sudo rm -rf /pgbackup/; sudo yum remove pg_probackup-11 -y; sudo rm -rf /pgarclogs/; sudo userdel -r postgres; sudo rm -rf /home/postgres/; sudo rm -rf /var/lib/etcd/; sudo sed -i '/\/usr\/local\/sbin\/dynmotd.sh/d' /etc/profile; sudo sed -i '/# Dynamic motd/d' /etc/profile; sudo sed -i '/postgres ALL=(ALL) NOPASSWD: \/usr\/bin\/systemctl stop postgresql/d' /etc/sudoers; sudo rm -rf /etc/postgres/*; sudo rm -rf /usr/patroni/; sudo rm -rf /opt/confd; sudo rm -rf /tmp/PGSE/; sudo yum remove -y rh-python36-python; sudo rm -rf /etc/postgres/; sudo rm -f /etc/systemd/system/confd.service; sudo rm -f /etc/systemd/system/etcd.service; sudo rm -f /etc/systemd/system/patroni.service; sudo rm -f /etc/systemd/system/pgbouncer.service; sudo rm -f /etc/systemd/system/postgresql.service; sudo rm -f /etc/systemd/system/haproxy.service; sudo rm -rf /usr/pgsql-se-old/; sudo rm -rf /usr/pangolin-5.5.0/; sudo systemctl stop pangolin_reencrypt@kmadmin_pg; sudo systemctl stop pangolin_reencrypt@postgres; sudo rm -f /etc/systemd/system/pangolin_reencrypt@.service; sudo rm -rf /var/run/pangolin_reencrypt; sudo systemctl daemon-reload; sudo userdel -r kmadmin_pg; sudo rm -f /usr/local/bin/pgbouncer; sudo rm -rf /opt/pangolin-common; sudo rm -rf /usr/pangolin*;
  

• Необходимо очистить файл ./installer/cache.json, а также добавить ключ --flush-cache при повторном запуске установки (см. пункт 6 раздела «Автоматическая установка»).

etcd#

В кластере Pangolin для хранения информации о состоянии кластера patroni используется хранилище etcd версии 3.3.11 (устанавливается инсталлятором).

sudo systemctl yum install etcd

Настройка etcd#

Для настройки сервиса откройте файл параметров etcd.service и укажите в нем следующие параметры:

Sudo vi /etc/systemd/system/etcd.service

[Unit]
Description=etcd Server
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
User=etcd
### set GOMAXPROCS to number of processors
ExecStart=/bin/bash -c "GOMAXPROCS=$(nproc) /usr/bin/etcd"

Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
node-1 /etc/etcd/etcd.conf
[pprb_dev@tkle-pprb0100 ~]$ sudo cat /etc/etcd/etcd.conf | grep -v ^#
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_NAME="node-01"
ETCD_HEARTBEAT_INTERVAL="1000"
ETCD_ELECTION_TIMEOUT="5000"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${HOST_VM1}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${HOST_VM1}:2379"
ETCD_INITIAL_CLUSTER="node-01=http://${HOST_VM1}:2380,node-02=http://${HOST_VM2}:2380,node-03=http://${HOST_VM3}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
node-02 /etc/etcd/etcd.conf
[pprb_dev@tkle-pprb0095 ~]$ sudo cat /etc/etcd/etcd.conf | grep -v ^#
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_NAME="node-02"
`ETCD_HEARTBEAT_INTERVAL`="1000"
ETCD_ELECTION_TIMEOUT="5000"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${HOST_VM2}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${HOST_VM2}:2379"
ETCD_INITIAL_CLUSTER="node-01=http://${HOST_VM1}:2380,node-02=http://${HOST_VM2}:2380,node-03=http://${HOST_VM3}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
node-03 /etc/etcd/etcd.conf
[pprb_dev@tkle-pprb0081 ~]$ sudo cat /etc/etcd/etcd.conf | grep -v ^#
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_NAME="node-03"
ETCD_HEARTBEAT_INTERVAL="1000"
ETCD_ELECTION_TIMEOUT="5000"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${HOST_VM3}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${HOST_VM3}:2379"
ETCD_INITIAL_CLUSTER="node-01=http://${HOST_VM1}:2380,node-02=http://${HOST_VM2}:2380,node-03=http://${HOST_VM3}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"

Описание параметров etcd.service:

• ETCD_LISTEN_PEER_URLS — список ссылок, с которых собирается трафик одноранговых узлов;

• ETCD_LISTEN_CLIENT_URLS — список ссылок, с которых собирается трафик клиентов;

• ETCD_HEARTBEAT_INTERVAL — время (мс) периода проверки (heartbeat);

• ETCD_ELECTION_TIMEOUT — время (в мс) тайм-аута алгоритма выбора;

• ETCD_INITIAL_ADVERTISE_PEER_URLS — список ссылок пиров этого элемента кластера для передачи другим элемента кластера;

• ETCD_ADVERTISE_CLIENT_URLS — список ссылок клиентов этого элемента кластера для публичной передачи. Передаваемые ссылки клиентов будут доступны системам, взаимодействующим с кластером etcd. Клиентские библиотеки обрабатывают эти ссылки для подключения к кластеру etcd;

• ETCD_INITIAL_CLUSTER — исходная конфигурация кластера для начальной загрузки;

• ETCD_INITIAL_CLUSTER_STATE — исходное состояние кластера (new или existing);

• ETCD_INITIAL_CLUSTER_TOKEN — исходный токен кластера etcd во время начальной загрузки. При использовании нескольких кластеров позволяет избежать непреднамеренного взаимодействия между ними.

Обязательно рекурсивно смените владельца директории. Для этого выполните:

sudo chown -R etcd:etcd /var/lib/etcd/

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

sudo systemctl daemon-reload
sudo systemctl start etcd.service
sudo systemctl status etcd.service
sudo journalctl -xe

Полезные функции#

Для быстрого просмотра проблем с кластером:

etcdctl cluster-health

Для просмотра структуры хранилища:

etcdctl ls --recursive --sort -p /service/clustername

где clustername - имя кластера базы.

Для просмотра всей структуры:

etcdctl ls --recursive /

Пример:

[pprb_dev@tkle-pprb0066 ~]$ etcdctl ls -r /
/service
/service/clus
/service/clus/members
/service/clus/members/pg02
/service/clus/members/pg01
/service/clus/initialize
/service/clus/config
/service/clus/optime
/service/clus/optime/leader
/service/clus/history
/service/clus/leader

Для получения значения из параметра:

etcdctl -o extended get /service/clustername/leader
etcdctl -o extended get /service/clustername/members/

Автоматическое подключение СЗИ с помощью external-скрипта#

Подключить набор СЗИ можно отдельно от общего сценария установки СУБД. Механизм подключения вынесен в независимый external-скрипт внутри общих скриптов развертывания/обновления, к которым относятся:

• playbook_configure_ist.yaml - осуществляет запуск сценария подключения СЗИ;

• custom_configure_ist.yml - пользовательский конфигурационный слой для настройки входных параметров.

Ansible-роль (configure_ist) для запуска процесса подключения СЗИ выглядит следующим образом:

• tasks:

  • check.yml - файл с задачами для проверки состояния стенда, влияющими на успешное подключение СЗИ, проверка входных параметров;

  • common_check.yml - файл с задачами для общей проверки состояния стенда. Проверки путей до конфигурационных файлов, путей до сертификатов;

  • define_current_master.yml - файл с задачами для определения текущей конфигурации. В случае со стендом с patroni, определение текущего master;

  • install.yml - файл с задачами по подключению СЗИ;

  • main.yml - файл с задачами, включает в себя вызов всех файлов в текущем каталоге;

  • switch.yml - файл с задачами по остановке/запуску БД;

• group_vars:

  • all.yml - переменные, используемые в данной роли по умолчанию;

  • message.yml - переменные для вывода информации (INFO)/ошибок (FAIL);

• inventory:

  • cluster:

    • host.ini - обеспечивает возможность передачи параметров подключения к хостам. Содержит файлы для кластерной конфигурации;

    • inventory.py - скрипт, обеспечивающий возможность заполнять inventory-файлы в автоматическом режиме;

  • standalone:

    • host.ini - обеспечивает возможность передачи параметров подключения к хостам. Содержит файлы для конфигурации standalone;

    • inventory.py - скрипт, обеспечивающий возможность заполнять inventory-файлы в автоматическом режиме;

    • filter_plugins:

      • common_filters.py - скрипт для обработки входных данных;

    • library:

    • yedit - скрипт для работы с конфигурационным файлом patroni. Поставляется в скомпилированном виде;

    • pangolin_protect_init.py - скрипт для работы с утилитами setup_kms_credentials, initprotection.

Особенности логики работы некоторых параметров пользовательского конфигурационного файла:

• параметр secure_config контролирует включение защиты конфигурации. Значение по умолчанию true;

• параметр admin_protection подразумевает подключение только защиты от привилегированных пользователей. Значение по умолчанию true.

Вышеупомянутые параметры располагаются в блоке TYPE IST.

Примечание:

Утилиты initprotection/setup_kms_credentials в external-скрипте обернуты в Python-модуль. Это позволяет исключить возможные зависания при передаче некорректного значения и организацией вызова утилиты initprotection от linux-пользователя администратора безопасности.

Организована возможность передать имя пользователя с привилегиями на запуск инициализации механизма защиты данных и запуск инициализации подключения к защищенному хранилищу; контролируется параметром target_linux_user, значение по умолчанию: kmadmin_pg. Располагается в блоке SETTINGS INIT PROCESS. Скрипты по подключению СЗИ не вносят изменения в файл sudoers для данного пользователя и не корректируют права владельца на запуск утилит initprotection и setup_kms_credentials. Все необходимые права на запуск должны быть выданы до старта скриптов по подключению СЗИ.

Тип объединенного параметра адреса узла и порта VAULT VAULT_HOST_PORT соответствует list. Ограничений в количестве элементов списка нет. Располагаются в блоке CONNECTION VAULT PARAMETERS.

Параметр add_connection_string_to_hba отвечает за добавление строк подключения для созданных в процессе инициализации механизма защиты данных пользователей. Значение по умолчанию true. Располагается в блоке ADMIN PROTECTION SETTINGS. В случае, если параметр будет принимать значение false, в конфигурационный файл pg_hba.conf будет добавлен следующий комментарий:

# The connection string for security administrators is formed implicitly

Внимание!

С версии 5.5.0 параметры, которые в более ранних версиях задавали правила подключения для admin_protection_users.sec_admin (sec_admin_hba_rule.connection, sec_admin_hba_rule.databases, sec_admin_hba_rule.network, sec_admin_hba_rule.auth) и параметр sec_admin_backup_networks (список хостов к подключению admin_protection_users.sec_admin_backup) были исключены.

Тип параметра sec_admin_hba_rule.network изменен с str на list.

Для каждой УЗ администратора безопасности можно задать индивидуальные правила подключения в параметре admin_protection_users. Параметры настройки располагаются в блоке ADMIN PROTECTION SETTINGS.

Параметр pg_encryption_keys_capacity задает настройку БД при подключении TDE; располагается в блоке CONFIGURATION PARAMETERS. Параметры dynamic_shared_memory_type и mkeychecker_delay в локальную конфигурацию не включены.

Запуск скрипта для подключения СЗИ#

Выполните шаги:

1. Перед запуском скрипта установите обязательные для работы скрипта пакеты:

   python3 -m venv venv
   source venv/bin/activate
   pip3 install PyYAML==5.3 jinja2==2.11.2 cryptography==3.3.1 ansible==4.10.0 pexpect==4.8.0 dnspython==2.2.0
   

2. Запустите external-скрипт подключения СЗИ, для этого выполните ansible-playbook playbook_configure_ist.yaml.

   • пример запуска для конфигурации standalone:

     ansible-playbook playbook_configure_ist.yaml -i inventories/standalone/hosts.ini --extra-vars "custom_config=<Путь к пользовательскому конфигурационному файлу> utility_path=<Путь к каталогу с утилитами; входит в состав дистрибутива>" --flush-cache -vv
     

   • пример запуска для кластерной конфигурации:

     ansible-playbook playbook_configure_ist.yaml -i inventories/cluster/hosts.ini --flush-cache -vv
     

Проверки и информационные сообщения процесса подключения СЗИ#

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

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

• custom_config - путь к пользовательскому конфигурационному файлу инсталлятора;

• utility_path - путь к каталогу utilities/, входящего в состав дистрибутива.

В случае ошибки выводится следующее сообщение:

"FAIL__Один из обязательных входных параметров: custom_config, utility_path не был задан при старте. Скорректируйте строку запуска ansible и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка пользователей#

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

"FAIL__На хосте {{ ansible_fqdn }} не был обнаружен пользователь {}. На текущий момент подключение СЗИ невозможно, необходимо выполнить проверку корректного заполнения параметра target_linux_user в пользовательском конфигурационном файле '{}' или произвести создание пользователя. После произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка актуального master-узла#

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

"FAIL__Текущий мастер в СУБД не соответствует значению, полученному из SM. На текущий момент подключение СЗИ невозможно, необходимо выполнить switchover__.FAIL"

Проверка файлов сертификатов#

Если файлы сертификатов отсутствуют, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Файл сертификата {} не найден на хосте {{ ansible_fqdn }}. Проверьте наличие файла.__FAIL"

Проверка переданного пути к конфигурационному файлу инсталлятора на корректность#

В случае ошибки выводится следующее сообщение:

"FAIL__Путь к конфигурации '{}' не должен зависеть от текущего каталога. Скорректируйте значение для параметра custom_file в строке запуска ansible и произведите повторный запуск скрипта по подключению СЗИ__FAIL"

Проверка наличия конфигурационного файла на управляющем узле#

При наличии файла выводится подсказка с информацией о расположении файла:

"INFO__Файл конфигурации '{}' найден.__INFO"

В случае, когда файл не найден, выводится сообщение вида:

"FAIL__Файл конфигурации '{}' не найден. Строка запуска ansible должна содержать параметр custom_file с корректным путем к пользовательскому конфигурационному файлу custom_file. Скорректируйте строку запуска ansible и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Роль получает текущее значение следующих переменных:

Проверка наличия переменных окружения#

Переменные окружения, которые необходимо проверить:

• PGDATA;

• PGHOME;

• CLNAME;

• PGPORT.

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

"FAIL__{PARAM} на хосте {{ ansible_fqdn }} отсутствует. Актуализируйте значение '{PARAM}' в файле /home/postgres/.bash_profile.__FAIL"

Проверка запуска СУБД#

Если СУБД Pangolin не запущена, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__СУБД Pangolin не запущена. Произведите проверку состояния СУБД Pangolin на сервере.__FAIL"

Проверка запуска patroni#

Если служба patroni не запущена, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Служба Patroni не запущен. Произведите проверку состояния службы patroni на сервере.__FAIL"

Проверка установки параметров в true#

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

"FAIL__Не удалось сформировать список СЗИ к подключению. Скорректируйте значения в пользовательском конфигурационном слое.__FAIL"

Проверка символьных ссылок#

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

"FAIL__Подключение СЗИ на стенде возможно только с физическим(ими) сервером(ами) VAULT. Произведите проверку символьной ссылки до плагина: {}.__FAIL"

Проверка плагинов setup_kms_credentials/initprotection#

Если на стенде не был обнаружен плагин setup_kms_credentials или initprotection, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Плагин '{}' на стенде не обнаружен.__FAIL"

Проверка доступности серверов#

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

"Не удалось установить успешное подключение ни к одному из сервера(ов) VAULT. Проверьте корректность переданных параметров подключения к защищенному(ым) хранилищу(щам) VAULT в конфигурационном файле' {}'. После произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка списка УЗ администраторов#

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

"FAIL__Проверка входных параметров для инициализации механизма защиты данных не дала ожидаемый результат. Параметры УЗ администраторов безопасности были переданы неверно или не в полном объеме. Скорректируйте параметры в пользовательском конфигурационном файле '{}', относящиеся к конфигурированию УЗ администраторов безопасности и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка метода шифрования паролей УЗ администраторов безопасности#

Если пароли для УЗ администраторов безопасности были заданы не методом SCRAM-SHA-256, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Проверка входных параметров для инициализации механизма защиты данных не дала ожидаемый результат. Пароли УЗ администраторов безопасности не были переданы в виде SCRAM-SHA-256. Скорректируйте параметры паролей для УЗ администраторов безопасности в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ. __FAIL"

Проверка получения параметров VAULT_CLUSTER_ID, VAULT_LOGIN, VAULT_PASSWORD#

Роль получает на вход параметры:

• VAULT_CLUSTER_ID;

• VAULT_LOGIN;

• VAULT_PASSWORD;

• VAULT_HOST_PORT.

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

"FAIL__Проверка входных параметров для инициализации подключения к защищенному(ым) хранилищу(ам) VAULT не дала ожидаемый результат. Значение для параметра '{}' не должно быть пустым. Скорректируйте параметры '{}' в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка значение параметра VAULT_HOST_PORT#

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

"FAIL__Проверка входных параметров для инициализации подключения к защищенному(ым) хранилищу(ам) VAULT не дала ожидаемый результат. Значение для параметра '{}' указано в неверном формате. Скорректируйте параметры '{}' в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка наличия VAULT_CLUSTER_ID на защищенном хранилище VAULT#

В случае отсутствия выводится ошибка вида:

"FAIL__cluster id - '{}' в защищенном хранилище VAULT '{}' не обнаружен. Дальнейшее подключение невозможно. Произведите проверку на предмет корректно сконфигурированого id на сервере VAULT и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка значение параметра VAULT_CLUSTER_ID#

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

"FAIL__Проверка входных параметров для инициализации подключения к защищенному(ым) хранилищу(ам) VAULT не дала ожидаемый результат. Значение для параметра '{}' не должно начинаться или заканчиваться кавычками. Скорректируйте параметры '{}' в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Получение общего списка параметров из защищенного хранилища VAULT#

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

"FAIL__В процессе получения списка параметров из защищенного хранилища VAULT возникли ошибки: {}. Произведите проверку состояния VAULT сервера(ов) и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка корректного значения для параметра secure_config на защищенном хранилище VAULT#

Значение on устанавливается, если планируется подключение защиты параметров конфигурации; значение off используется, если подключение защиты параметров конфигурации не планируется.

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

"FAIL__Для подключения выбранных СЗИ значение для параметра secure_config должен быть выставлено в {} на защищенном хранилище VAULT. Скорректируйте значение для параметра на защищенном хранилище VAULT и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка корректного значения для параметра is_tde_on на защищенном хранилище VAULT#

Если планируется подключение TDE, ожидается значение on/true. В случае, когда подключение TDE не планируется, устанавливается значение off/false.

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

"FAIL__Для подключения выбранных СЗИ значение для параметра is_tde_on должен быть выставлено в {} на защищенном хранилище VAULT. Скорректируйте значение для параметра на защищенном хранилище VAULT и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка идентичности значений pg_ident на защищенном хранилище VAULT и в локальном конфигурационном файле#

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

"FAIL__Для подключения выбранных СЗИ значение для параметра pg_ident на защищенном хранилище VAULT должно соответствовать значению в локальном конфигурационном файле '{}/pg_ident.conf'. Синхронизируйте значения и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка готовности защищенного хранилища VAULT к последующему подключению выбранных СЗИ посредством secret_storage_client#

Утилита secret_storage_client входит в состав дистрибутива и располагается в папке utilities/secret_storage_client_bundle/bin/. На вход скрипты, использующие данную утилиту для проверки, ожидают корректно переданный путь к каталогу с утилитами utilities/ в переменную utility_path в строку запуска ansible. При отсутствии утилиты по переданному пути в лог будет выведено предупреждающее сообщение. Процесс подключения при этом не останавливается.

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

"WARNING__По преданному пути '{}' утилита secret_storage_client не обнаружена. Проверки готовности защищенного хранилища VAULT к подключению выбранных СЗИ будет пропущена.__WARNING"

Сообщения об успешном прохождении проверок#

"INFO__Список СЗИ к подключению успешно сформирован. В процессе работы скрипта будет подключено: {}.__INFO"

"INFO__Проверка плагина подключения к защищенному(ым) хранилищу(ам) VAULT завершилась успешно.__INFO"

"INFO__Проверка доступности VAULT сервера(ов) прошла успешно.__INFO"

Проверки и информационные сообщения после подключения выбранного списка СЗИ#

Проверка наличия конфигурационного файла VAULT после работы утилиты setup_kms_credentials#

В случае, когда файл не был найден, будет выведена ошибка:

"FAIL__Конфигурационный файл VAULT '{}' не был обнаружен. Причина может быть в некорректной работе утилиты setup_kms_credentials. Лог работы утилиты: {}__FAIL"

Проверка успешного подключения#

Если после работы утилиты setup_kms_credentials не удалось установить ни одного успешного подключения, то выводится следующее сообщение в лог:

"FAIL__Не удалось установить ни одного успешного подключения. Проверьте доступность сервера(ов) VAULT и корректность переданных параметров в пользовательском конфигурационном файле.__FAIL"

Проверка работа утилиты initprotection#

Если работа утилиты initprotection завершилась неудачей, то выводится следующее сообщение в лог:

"FAIL__В процессе инициализация механизма защиты данных возникли ошибки: '{}'.__FAIL"

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

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

"FAIL__В процессе работы скриптов что-то пошло не так. TDE на текущем стенде не включено. Произведите проверку параметра по включению TDE в конфигурационном файле или на сервере(ах) VAULT.__FAIL"

"FAIL__В процессе работы скриптов что-то пошло не так. Защита конфигурации на текущем стенде не включена. Произведите проверку параметра secire_config на сервере(ах) VAULT.__FAIL"

"FAIL__В процессе работы скриптов что-то пошло не так. Защита от привилегированных пользователей на текущем стенде не включена.__FAIL"

Сообщения об успешном прохождении проверок#

"INFO__Проверка наличия конфигурации VAULT прошла успешно.__INFO"

"INFO__Инициализация механизма защиты данных выполнена успешно.__INFO"

"INFO__Итоговая проверка подключения TDE завершилась успешно.__INFO"

"INFO__Итоговая проверка подключения защиты конфигурации завершилась успешно.__INFO"

"INFO__Итоговая проверка подключения защиты от привилегированных пользователей завершилась успешно.__INFO"

Ручное подключение СЗИ#

В Pangolin реализована интеграция с KMS HashiCorp Vault и с локальным файловым хранением секретов. В данном разделе рассматривается ручное подключение таких функциональностей, как защита от привилегированных пользователей, TDE и защита конфигурации.

Внимание!

Подключение СЗИ осуществляется от пользователя с правами sudo, пользователя postgres и пользователя администратора безопасности (в качестве примера взят kmadmin_pg).

Инструкция рассчитана на подключение СЗИ в СУБД Pangolin, начиная с версии 5.4.0.

Ручное подключение СЗИ с локальным файловым хранением секретов#

Общие подготовительные действия#

Выключите БД на время ручного подключения СЗИ:

• Если конфигурация standalone:

  sudo su - postgres
  /usr/pangolin/bin/pg_ctl stop -D /pgdata/05/data
  

  Ожидаемый результат:

  waiting for server to shut down....
  done
  server stopped
  

• Если конфигурация кластерная:

  sudo su - postgres
  sudo systemctl stop patroni
  

  Действие сначала производится на реплике, затем на мастере.

  Ожидаемый результат:

  sudo su - postgres
  list
  
  + Cluster: clustername (7258206222218039502) ----+---------+---------+----+-----------+
  | Member              | Host                     | Role    | State   | TL | Lag in MB |
  +---------------------+--------------------------+---------+---------+----+-----------+
  | <Адрес>         | <Адрес>:<Порт>         | Replica | stopped |    |   unknown |
  | <Адрес>          | <Адрес>:<Порт>          | Replica | stopped |    |   unknown |
  +---------------------+--------------------------+---------+---------+----+-----------+
  

Локальное конфигурирование#

Примечание:

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

Выполните шаги:

1. Создайте каталог для расширенной конфигурации, если такого нет. В кластерной конфигурации повторите это действие на реплике:

   sudo su
   mkdir /etc/postgres
   chown postgres:kmadmin_pg /etc/postgres
   chmod 0731 /etc/postgres
   

   Ожидаемый результат:

   ls -la /etc | grep postgres
   
   drwx-wx--x    2 postgres kmadmin_pg   4096 Jul 21 18:00 postgres
   

2. Создайте файлы для хранения статических и динамических параметров. В кластерной конфигурации повторите это действие на реплике:

   sudo su
   touch /etc/postgres/kms_dynamic_params.cfg
   touch /etc/postgres/kms_static_params.cfg
   chown kmadmin_pg:postgres /etc/postgres/kms_dynamic_params.cfg
   chown kmadmin_pg:postgres /etc/postgres/kms_static_params.cfg
   chmod 0640 /etc/postgres/kms_dynamic_params.cfg
   chmod 0640 /etc/postgres/kms_static_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres
   
   -rw-r-----    1 kmadmin_pg postgres   0 Jul 21 18:05 kms_dynamic_params.cfg
   -rw-r-----    1 kmadmin_pg postgres   0 Jul 21 18:06 kms_static_params.cfg
   

   Файл со статическими параметрами имеет простой текстовый формат, каждая строка содержит пару: <имя ключа> = <значение для данного ключа>. Файл может содержать следующие параметры:

• ключ actual_master_key – метка актуального мастер-ключа;

• wal_key – значение ключа шифрования WAL кластера;

• master_key_value_<timestamp> – значение мастер-ключа, <timestamp> – дата и время в формате ГГГГММДД_ЧЧммСС, где ГГГГ – год, ММ – месяц, ДД – день, ЧЧ – час в формате 24 часа, мм – минута, СС – секунда.

3. Сгенерируйте ключи с помощью утилиты generate_encryption_key. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   /usr/pangolin/bin/generate_encryption_key
   

   Ожидаемый результат:

   Key was generated successfully. Key: {ключ}
   

4. Заполните файл со статическими параметрами. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   vim /etc/postgres/kms_static_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres/kms_static_params.cfg
   
   actual_master_key = {ключ}
   master_key_value_00000000_000000_000 = {ключ}
   wal_key = {ключ}
   

5. Зашифруйте файл со статическими параметрами. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   /usr/pangolin/bin/encrypt_params_file
   

   Ожидаемый результат:

   Start to encrypt file: /etc/postgres/kms_static_params.cfg
   File /etc/postgres/kms_static_params.cfg was encrypted successfully
   

6. Создайте файл с динамическими параметрами. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   vim /etc/postgres/kms_dynamic_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres/kms_dynamic_params.cfg
   
   secure_config = off
   is_tde_on = off
   allowed_servers =
   enabled_sec_admin_extra_auth_methods = cert
   encrypt_new_tablespaces = ddl
   masking_mode = disabled
   password_encryption = scram-sha-256
   password_policies_enable = on
   password_policy.allow_hashed_password = on
   password_policy.alpha_numeric = 3
   password_policy.check_syntax = on
   password_policy.custom_function =
   password_policy.deny_default = off
   password_policy.expire_warning = 7 days
   password_policy.failure_count_interval = 0
   password_policy.grace_login_limit = 0
   password_policy.grace_login_time_limit = 3 days
   password_policy.illegal_values = on
   password_policy.in_history = 4
   password_policy.lockout = on
   password_policy.lockout_duration = 24 hours
   password_policy.max_age = 0
   password_policy.max_failure = 6
   password_policy.max_inactivity = 0
   password_policy.max_rpt_chars = 0
   password_policy.min_age = 0
   password_policy.min_alpha_chars = 0
   password_policy.min_length = 16
   password_policy.min_lowercase = 0
   password_policy.min_special_chars = 1
   password_policy.min_uppercase = 1
   password_policy.password_strength_estimator_score = 3
   password_policy.reuse_time = 365 days
   password_policy.track_login = 0
   password_policy.transport_password_life_time = 0
   password_policy.transport_password_mark_automatic = off
   password_policy.use_password_strength_estimator = on
   performance_insights.masking = on
   psql_encrypt_password = on
   ssl = on
   pg_ident_conf +=
   

7. Переопределите символьную ссылку плагина на заменитель. В кластерной конфигурации повторите это действие на реплике.

   sudo su - postgres
   ln -s /usr/pangolin/lib/plugins/libkms_substitute_plugin.so /usr/pangolin/lib/libconnection_plugin.so
   

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

Инициализируйте механизм защиты от привилегированных пользователей только на мастере. Пароль передайте в открытом виде:

sudo su - kmadmin_pg
sudo -iu postgres -g kmadmin_pg /usr/pangolin/bin/initprotection
Enter PGDATA directory [/pgdata/05/data]: /pgdata/05/data
Enter security administrator names (comma-separated):sec_admin,sec_admin_backup
Enter new security admin password for user "sec_admin":
Enter it again:
Enter new security admin password for user "sec_admin_backup":
Enter it again:

Ожидаемый результат:

Protection mechanism is initialized.
syncing data to disk

Подключение TDE#

Внимание!

Пропустите действия в этом разделе, если не планируется подключение защиты конфигурации.

Выполните шаги:

1. Измените значение параметра is_tde_on на on в файле динамических параметров. В кластерной конфигурации действие повторите на реплике:

   sudo su - kmadmin_pg
   vim /etc/postgres/kms_dynamic_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres/kms_dynamic_params.cfg
   
   is_tde_on = on
   

2. Измените значение параметра is_tde_on на on в локальной конфигурации. В кластерной конфигурации действие повторите на реплике:

   sudo su - postgres
   # Для конфигурации standalone
   vim /pgdata/05/data/postgresql.conf
   # Для кластерной конфигурации
   vim /etc/patroni/postgres.yml
   

   Ожидаемый результат:

   • Для standalone-конфигурации:

   cat /pgdata/05/data/postgresql.conf | grep is_tde_on
   is_tde_on = 'on'
   

   • Для cluster-конфигурации:

   cat /etc/patroni/postgres.yml | grep is_tde_on
   is_tde_on: on
   

Подключение защиты конфигурации#

Чтобы подключить защиту конфигурации, измените значение параметра secure_config на on в файле динамических параметров. В кластерной конфигурации действие повторите на реплике:

sudo su - kmadmin_pg
vim /etc/postgres/kms_dynamic_params.cfg

Ожидаемый результат:

ls -la /etc/postgres/kms_dynamic_params.cfg
secure_config = on

Общие завершающие действия#

Включите БД:

• Если конфигурация standalone:

  sudo su - postgres
  /usr/pangolin/bin/pg_ctl start -D /pgdata/05/data
  

  Ожидаемый результат:

  done
  server started
  

• Если конфигурация кластерная. Действие сначала производится на мастере, затем на реплике:

  sudo su - postgres
  sudo systemctl start patroni
  

  Ожидаемый результат:

  sudo su - postgres
  list
  
  + Cluster: clustername {cluster_name} 
  ----+--------------+---------+----+-----------+
  | Member              | Host                     | Role         | State   | TL | Lag in MB |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  | <IP-адрес>
  
  t | <IP-адрес>:<Порт> | Sync Standby | running |  2 |         0 |
  | <IP-адрес>  | <IP-адрес>:<Порт> | Leader       | running |  2 |           |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  

  Ожидаемый результат в логе БД:

  LOG:  The initialization of KMS substitute completed successfully.
  

Ручное подключение СЗИ с KMS HashiCorp Vault#

Примечание:

В скриптах развертывания/обновления также реализован внешний скрипт по автоматическому подключению СЗИ.

Общие подготовительные действия#

Выключите БД на время ручного подключения СЗИ:

• Если конфигурация standalone:

  sudo su - postgres
  /usr/pangolin/bin/pg_ctl stop -D /pgdata/05/data
  

  Ожидаемый результат:

  waiting for server to shut down....
  done
  server stopped
  

• Если конфигурация кластерная, действие сначала производится на реплике, затем на мастере:

  sudo su - postgres
  sudo systemctl stop patroni
  

  Ожидаемый результат:

  sudo su - postgres
  list
  
  + Cluster: clustername (7258206222218039502) ----+---------+---------+----+-----------+
  | Member              | Host                     | Role    | State   | TL | Lag in MB |
  +---------------------+--------------------------+---------+---------+----+-----------+
  | <IP-адрес> | <IP-адрес>:<Порт> | Replica | stopped |    |   unknown |
  | <IP-адрес>  | <IP-адрес>:<Порт>  | Replica | stopped |    |   unknown |
  +---------------------+--------------------------+---------+---------+----+-----------+
  

Конфигурирование KMS HashiCorp Vault#

Выполните шаги:

1. Выполните аутентификацию пользователя на сервере Vault. Для аутентификации используйте клиентский токен:

   

2. Зайдите в хранилище kv и нажмите Create secret (1) для создания уникального CLUSTER_ID.

   

   Заполните следующие поля:

   1. В поле Path for this secret (2) укажите путь к параметру: postgresql/<CLUSTER_ID>/postgresql/<param>, где:

   • <CLUSTER_ID> - имя кластера. Должно быть уникальным для каждого кластера;

   • <param> - наименование параметра, например secure_config.

   2. В поле Version data (3, 4) укажите имя параметра - value, значение - off.

   3. Сохраните, нажав кнопку Save (5).

      

   4. Повторите действие по созданию остальных параметров из списка:

      is_tde_on = off
      allowed_servers =
      enabled_sec_admin_extra_auth_methods = cert
      encrypt_new_tablespaces = ddl
      masking_mode = disabled
      password_encryption = scram-sha-256
      password_policies_enable = on
      password_policy.allow_hashed_password = on
      password_policy.alpha_numeric = 3
      password_policy.check_syntax = on
      password_policy.custom_function =
      password_policy.deny_default = off
      password_policy.expire_warning = 7 days
      password_policy.failure_count_interval = 0
      password_policy.grace_login_limit = 0
      password_policy.grace_login_time_limit = 3 days
      password_policy.illegal_values = on
      password_policy.in_history = 4
      password_policy.lockout = on
      password_policy.lockout_duration = 24 hours
      password_policy.max_age = 0
      password_policy.max_failure = 6
      password_policy.max_inactivity = 0
      password_policy.max_rpt_chars = 0
      password_policy.min_age = 0
      password_policy.min_alpha_chars = 0
      password_policy.min_length = 16
      password_policy.min_lowercase = 0
      password_policy.min_special_chars = 1
      password_policy.min_uppercase = 1
      password_policy.password_strength_estimator_score = 3
      password_policy.reuse_time = 365 days
      password_policy.track_login = 0
      password_policy.transport_password_life_time = 0
      password_policy.transport_password_mark_automatic = off
      password_policy.use_password_strength_estimator = on
      performance_insights.masking = on
      psql_encrypt_password = on
      ssl = on
      pg_ident_conf +=
      

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

Выполните команды инициализации механизма защиты от привилегированных пользователей (только на мастере). Пароль передайте в открытом виде:

sudo su - kmadmin_pg
sudo -iu postgres -g kmadmin_pg /usr/pangolin/bin/initprotection
Enter PGDATA directory [/pgdata/05/data]: /pgdata/05/data
Enter security administrator names (comma-separated):sec_admin,sec_admin_backup
Enter new security admin password for user "sec_admin":
Enter it again:
Enter new security admin password for user "sec_admin_backup":
Enter it again:

Ожидаемый результат:

Protection mechanism is initialized.
syncing data to disk

Подключение TDE#

Примечание:

Подробная информация о настройке прозрачного шифрования хранимых данных в Pangolin приведена в разделе «Настройки параметров безопасности».

Выполните шаги:

1. Действие необходимо пропустить, если не планируется подключение защиты конфигурации. Измените значение параметра is_tde_on на on на сервере VAULT, нажав кнопку Create new version:

   

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

   • Для конфигурации standalone:

     sudo su - postgres
     vim /pgdata/05/data/postgresql.conf
     

   • Для кластерной конфигурации:

     sudo su - postgres
     vim /etc/patroni/postgres.yml
     

   Ожидаемый результат:

   • Для конфигурации standalone:

     cat /pgdata/05/data/postgresql.conf | grep is_tde_on
     is_tde_on = 'on'
     

   • Для кластерной конфигурации:

     cat /etc/patroni/postgres.yml | grep is_tde_on
     is_tde_on: on
     

Подключение защиты конфигурации#

Для подключения защиты конфигурации измените значение параметра secure_config на on на сервере VAULT, нажав кнопку Create new version:

Общие завершающие действия#

1. Включите БД:

   • Если конфигурация standalone:

     sudo su - postgres
     /usr/pangolin/bin/pg_ctl start -D /pgdata/05/data
     

     Ожидаемый результат:

     done
     server started
     

   • Если конфигурация кластерная, действие сначала производится на мастере, затем на реплике:

     sudo su - postgres
     sudo systemctl start patroni
     

     Ожидаемый результат:

     sudo su - postgres
     list
     
     + Cluster: clustername (7258206222218039502) ----+--------------+---------+----+-----------+
     | Member              | Host                     | Role         | State   | TL | Lag in MB |
     +---------------------+--------------------------+--------------+---------+----+-----------+
     | <IP-адрес> | <IP-адрес>:<Порт> | Sync Standby | running |  2 |         0 |
     | <IP-адрес>  | <IP-адрес>:<Порт>  | Leader       | running |  2 |           |
     +---------------------+--------------------------+--------------+---------+----+-----------+
     

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

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

В обязанности администратора безопасности входит настройка соединения со службой управления ключами (KMS). Настройка соединения с KMS осуществляется через утилиту setup_kms_credentials. Подробная инструкция по настройке описана в текущем разделе.

Прозрачное шифрование#

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

Алгоритм, процессы и концептуальная архитектура Pangolin при реализации прозрачного шифрования описаны в разделе «Прозрачное шифрование (Transparent Data Encryption)».

В данном разделе представлены инструкции по настройке прозрачного шифрования хранимых данных (TDE) в Pangolin. Настройка возможна с использованием хранилища секретов в HashiCorp Vault или с использованием хранилища KMS-заменителя.

Настройка прозрачного шифрования хранимых данных (TDE) в Pangolin с использованием хранилища секретов в Hashi Corp Vault#

Решение HashiCorp Vault используется в качестве защищенного хранилища ключей шифрования и настроек, а также как система управления ключами.

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

1. Установите и настройте HashiCorp Vault (см. «Установка и настройка HashiCorp Vault».

2. Добавьте параметры в KMS (см. «Добавление параметров в KMS».

3. Включите и настройте прозрачное шифрование хранимых данных в Pangolin на сервере (см. ниже).

Обновление HashiCorp Vault описано в инструкции «Установка и настройка дополнительных компонентов системы, не входящих в состав дистрибутива Pangolin».

Список параметров, настраиваемых через KMS по ссылке.

Включение и настройка прозрачного шифрования хранимых данных в Pangolin#

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

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

SHOW installer.cluster_type;

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

1. Администратор выводит кластер из обслуживания приложений и останавливает СУБД на Standby-узле, затем на Active-узле.

2. Администратор устанавливает параметр is_tde_on = on в конфигурационном файле Pangolin (/etc/patroni/postgres.yml).

3. При наличии выделенной учетной записи для сотрудника ИБ он запускает утилиту setup_kms_credentials и создает файл с параметрами соединения с KMS.

   При необходимости сотрудник ИБ устанавливает мастер-ключ в KMS вручную.

   Примечание:

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

4. Администратор запускает кластер.

5. Администратор проверяет создание ключей в KMS и в кластере.

6. Администратор проверяет включение TDE в кластере.

Подробное описание каждого шага:

1. Выведите кластер из обслуживания приложений и остановите СУБД, для этого:

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

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

     $ patronictl -c /etc/patroni/postgres.yml list $CLNAME
     + Cluster: clustername {cluster_name}
     +---------+---------+----+-----------+
     | Member          | Host                    | Role    | State   | TL | Lag in MB |
     +-----------------+-------------------------+---------+---------+----+-----------+
     | <Адрес сервера> | <Адрес сервера>:<Порт>  | Replica | stopped |    |   unknown |
     | <Адрес сервера> | <Адрес сервера>:<Порт>  | Replica | stopped |    |   unknown |
     +-----------------+-------------------------+---------+---------+----+-----------+
     

2. Установите параметр is_tde_on = on в конфигурационном файле Pangolin (сначала на Active-узле, затем на Standby-узле), для этого:

   • для входа в режим редактирования конфигурационного файла выполните команду:

     $ vim /etc/patroni/postgres.yml
     
     # перейдите в режим редактирования текста вводом символа i
     # измените значение параметра is_tde_on
     
     is_tde_on: on  
     
     # сохраните файл при выходе из режима редактирования, для этого: нажмите **Esc**, введите :wq и нажмите **Enter**
     

   • в версиях ниже 4.3.х проверьте наличие директории /etc/postgres (создайте при отсутствии) с правами (chmod 700, владелец postgres):

     drwx------   2 postgres postgres   4096 Sep  1 08:31 postgres
     

3. При наличии выделенной учетной записи для сотрудника ИБ он запускает утилиту setup_kms_credentials для настройки соединения с KMS (в результате будет создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg) (сначала на Active-узле, затем на Standby-узле):

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

     $ su - kmadmin_pg
     

   • запустите утилиту setup_kms_credentials (утилита расположена в версиях 4.х.х-5.1.0 /usr/pgsql-se-0x/bin, начиная с версии 5.2.0 в директории /usr/pangolin-5.2.0/bin/):

     $ /usr/pangolin-5.2.0/bin/setup_kms_credentials
     

   Заполните параметры:

   1. На сообщение с предложением выбрать, для какого домена задать идентификационные данные: KMS или Pangolin, выберите первый вариант, нажав 1:

      Choose credentials domain:
      1. KMS                         <-
      2. Pangolin
      1
      

   2. Укажите ID кластера (CLUSTER_ID):

      Enter Pangolin cluster ID:
      KSG                            <-
      

   3. Укажите IP address KMS:

      Enter IP address:
      <host IP>                      <-
      

      Примечание:

      IP-адрес и порт KMS приведены для примера.

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

      Enter port:
      8200                           <-
      

   5. На сообщение о выборе типа учетных данных и методе аутентификации выберите Userpass Auth Method, нажав 1:

      Choose credentials type:
      1. Userpass Auth Method        <-
      2. AppRole Auth Method
      1
      

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

      Enter login:
      adminencryption                <-
      Enter password:
      ******                         <-
      Confirm password:
      ******                         <-
      

   7. На сообщение о добавлении еще одних учетных данных KMS, ответьте no:

      Do you want to add another KMS credentials? (yes/no)?:
      no                             <-
      

   8. При успешном добавлении параметров появится сообщение:

      Credentials for KMS has been set successfully
      

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

      setup_kms_credentials --help
      

   9. В результате создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg:

      -rw-rw-r-- 1 kmadmin_pg kmadmin_pg    176 Oct  5 07:55 enc_connection_settings.cfg
      

4. Запустите кластер (сначала на Active узле, затем на Standby узле):      $ sudo systemctl start patroni    

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

    ```
    $ patronictl -c /etc/patroni/postgres.yml list $CLNAME
    + Cluster: clustername {cluster_name}
    +-----------------+-------------------------+--------------+---------+----+-----------+
    | Member          | Host                    | Role         | State   | TL | Lag in MB |
    +-----------------+-------------------------+--------------+---------+----+-----------+
    | <Адрес сервера> | <Адрес сервера>:<Порт>  | Sync Standby | running |  4 |         0 |
    | <Адрес сервера> | <Адрес сервера>:<Порт>  | Leader       | running |  4 |           |
    +-----------------+-------------------------+--------------+---------+----+-----------+
    ```
   

6. Проверьте создание ключей в KMS и в кластере.

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

   • в хранилище ключей KMS на сервере HashiCorp Vault;

   • в кластере Pangolin в директории $PGDATA/global/:

     $ cd $PGDATA/global/  
     
     # файл $PGDATA/global/enc_settings.cfg с меткой актуального мастер-ключа
     
     -rw------- 1 postgres postgres    84 Oct  6 05:21 enc_settings.cfg  
     
     # файл $PGDATA/global/enc_keys.json с ключами шифрования табличных пространств, отношений и журналов WAL
     
     -rw------- 1 postgres postgres   228 Oct  6 05:21 enc_keys.json
     

7. Проверьте успешное включение TDE в кластере.

   Для проверки включения прозрачного шифрования хранимых данных (Transparent Data Encryption) воспользуйтесь функцией проверки check_tde_is_on():

   postgres=# SELECT * FROM check_tde_is_on();
   check_tde_is_on
   -----------------
   t
   (1 row)
   

   Возврат функциией значения t (true) означает, что прозрачное шифрование хранимых данных в СУБД включено.

Настройка прозрачного шифрования хранимых данных (TDE) в Pangolin с использованием KMS-заменителя#

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

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

• первый файл /etc/postgres/kms_static_params.cfg содержит статические параметры. Файл со статическими параметрами зашифрован ключом, генерируемым из параметров сервера;

• второй файл /etc/postgres/kms_dynamic_params.cfg содержит динамические параметры. Файл с динамическими параметрами может меняться. При внесении изменений необходимо обеспечить идентичность файлов с динамическими параметрами на кластере.

Если файлы /etc/postgres/kms_static_params.cfg и /etc/postgres/kms_dynamic_params.cfg не обнаружены или в некорректном формате, система будет считать, что используется реальный KMS, но учетные данные для подключения к нему не найдены.

Ограничения для KMS-заменителя#

При использовании KMS-заменителя ротация мастер-ключа запрещена.

Изменение параметров кластера, хранящихся в KMS, можно проводить только в выключенном режиме.

Чтобы инициализация базы данных с подключенным заменителем KMS выполнилась, необходимо, чтобы файлы /etc/postgres/enc_connection_settings.cfg, kms_static_params.cfg и kms_dynamic_params.cfg либо все присутствовали, либо все отсутствовали.

Если в исходные файлы c настройками KMS вносятся правки, то измененные файлы должны быть скопированы на все серверы кластера и на каждом сервере зашифрованы со статическими параметрами с помощью утилиты шифрования encrypt_params_file.

При включении в кластер нового сервера актуальные файлы параметров KMS должны быть таким же образом скопированы на него и зашифрованы.

Статические параметры#

Файл со статическими параметрами /etc/postgres/kms_static_params.cfg представляет собой простой текстовый документ, каждая строка которого содержит пару:

<имя ключа (параметра на KMS)> = <значение для данного ключа>

В файл со статическими параметрами должны быть помещены:

• меткa мастер-ключа TDE;

• сгенерированный мастер-ключ TDE;

• сгенерированный ключ шифрования WAL TDE.

Пример файла со статическими параметрами:

actual_master_key = {ключ}
  
master_key_value = {ключ}
  
wal_key = {ключ}

Сгенерировать собственный мастер-ключ возможно с помощью утилиты /usr/pangolin-5.2.0/bin/generate_encryption_key.

Для этого поместите файл /etc/postgres/kms_static_params.cfg на все узлы кластера во время настройки перед запуском утилиты setup_kms_credentials. С помощью утилиты шифрования /usr/pangolin-5.2.0/bin/encrypt_params_file подготовленный файл со статическими параметрами зашифруйте на каждом узле кластера.

Примечание:

Утилиты генерации ключей generate_encryption_key и шифрования encrypt_params_file расположены в версиях 4.х.х-5.1.0 /usr/pgsql-se-0x/bin, начиная с версии 5.2.0 в директории /usr/pangolin-5.2.0/bin/.

Динамические параметры#

Файл с динамическими параметрами может содержать все параметры, которые могут изменяться администратором безопасности на KMS, т.е. в файл можно поместить все настройки, которые могут быть на реальном KMS.

Файл с динамическими параметрами /etc/postgres/kms_dynamic_params.cfg представляет собой простой текстовый документ, каждая строка которого содержит пару:

<имя ключа (параметра на KMS)> = <значение для данного ключа>

Пример файла с динамическими параметрами для настройки TDE:

secure_config = off

Настройка TDE в кластере с использованием KMS-заменителя#

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

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

SHOW installer.cluster_type;

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

1. Администратор выводит кластер из обслуживания приложений и останавливает СУБД на Standby-узле, затем на Active-узле.

2. Администратор подготавливает файлы со статическими и динамическими параметрами.

3. При наличии выделенной учетной записи для сотрудника ИБ он запускает утилиту setup_kms_credentials (создает файл с параметрами соединения с KMS).

4. Администратор устанавливает параметр is_tde_on = on в конфигурационном файле Pangolin (/etc/patroni/postgres.yml).

5. Администратор включает заменитель KMS.

6. Администратор запускает кластер.

7. Администратор проверяет создание ключей шифрования в кластере Pangolin в директории $PGDATA/global/.

8. Администратор проверяет успешное включение TDE в кластере.

Подробное описание каждого шага:

1. Выведите кластер из обслуживания приложений и остановите СУБД:

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

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

     $ patronictl -c /etc/patroni/postgres.yml list $CLNAME
     + Cluster: clustername (7151342043309644683)+---------+---------+----+-----------+
     | Member          | Host                    | Role    | State   | TL | Lag in MB |
     +-----------------+-------------------------+---------+---------+----+-----------+
     | <Адрес сервера> | <Адрес сервера>:<Порт>  | Replica | stopped |    |   unknown |
     | <Адрес сервера> | <Адрес сервера>:<Порт>  | Replica | stopped |    |   unknown |
     +-----------------+-------------------------+---------+---------+----+-----------+
     

   • в версии ниже 4.3.х проверьте наличие (создайте при отсутствии) директории /etc/postgres с правами (chmod 700, владелец postgres):

     drwx------   2 postgres postgres   4096 Sep  1 08:31 postgres
     

2. Подготовьте файлы со статическими и динамическими параметрами:

   • сгенерируйте мастер-ключ с помощью утилиты generate_encryption_key:

     # генерация мастер-ключа
     $ /usr/pangolin-5.2.0/bin/generate_encryption_key
     
     Key was generated successfully. Key: 5QIDlBFANJhWkbz7pawwCG1rp43xDHgiG/lfG8l30WE=
     
     # генерация ключа шифрования для WAL
     $ /usr/pangolin-5.2.0/bin/generate_encryption_key
     
     Key was generated successfully. Key: 7aOQcVN7XkLOLBbJuO5WrqtmmSBZ5f/tQc7kKB6hjBw=
     

   • cоздайте файл со статическими параметрами /etc/postgres/kms_static_params.cfg (метку мастер-ключа укажите именно master_key_value_00000000_000000_000):

     # создание файла
     $ touch /etc/postgres/kms_static_params.cfg
     
     # добавление сгенерированного на предыдущем шаге мастер-ключа и ключа шифрования для WAL журналов
     $ vim /etc/postgres/kms_static_params.cfg
     
     actual_master_key = master_key_value_00000000_000000_000
     master_key_value_00000000_000000_000 = 5QIDlBFANJhWkbz7pawwCG1rp43xDHgiG/lfG8l30WE=
     wal_key = 7aOQcVN7XkLOLBbJuO5WrqtmmSBZ5f/tQc7kKB6hjBw=
     

   • cоздайте файл с динамическими параметрами /etc/postgres/kms_dynamic_params.cfg:

     # создание файла
     $ touch /etc/postgres/kms_dynamic_params.cfg  
     
     # добавление параметра secure_config = off
     $ vim /etc/postgres/kms_dynamic_params.cfg
     
     secure_config = off
     

   • выполните копирование подготовленных файлов на Standby-узел:

     scp /etc/postgres/kms_*.cfg postgres@<host IP>:/etc/postgres
     

   • выдайте права kmadmin_pg на файлы со статическими и динамическими параметрами (на Active-узле, затем на Standby-узле) (при наличии выделенной учетной записи для сотрудника ИБ):

     chown kmadmin_pg:kmadmin_pg /etc/postgres/kms_static_params.cfg
     chown kmadmin_pg:kmadmin_pg /etc/postgres/kms_dynamic_params.cfg
     

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

     $ su - kmadmin_pg
     

   • зашифруйте файл со статическими параметрами (на Active-узле, затем на Standby-узле), в результате должно быть получено сообщение об успешном шифровании (File /etc/postgres/kms_static_params.cfg was encrypted successfully):

     $ /usr/pangolin-5.2.0/bin/encrypt_params_file
     
     Start to encrypt file: /etc/postgres/kms_static_params.cfg
     File /etc/postgres/kms_static_params.cfg was encrypted successfully
     

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

     $ cat /etc/postgres/kms_static_params.cfg
     
     "�|$�����j�'#��^-�3D%��w�k^���ɉ��N��1Ǹ�GQ�f�&p��q<�e���R��J4?/l��F@:����
     �h^���V�!x?�
     L��?4Y���_OP��R��*
     

3. При наличии выделенной учетной записи для сотрудника ИБ он выполняет запуск утилиты setup_kms_credentials для настройки соединения с KMS (в результате будет создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg) (сначала на Active-узле, затем на Standby-узле):

   • запустите под администратором ИБ утилиту setup_kms_credentials (утилита расположена в версиях 4.х.х-5.1.0 /usr/pgsql-se-0x/bin, начиная с версии 5.2.0 в директории /usr/pangolin-5.2.0/bin/):

     $ /usr/pangolin-5.2.0/bin/setup_kms_credentials
     

   Далее заполните необходимые параметры (при использовании KMS-заменителя достаточно указать имя кластера и credentials domain. Остальные параметры при работе с заменителем указывать не требуется (заменитель работает с локальными файлами, адрес для подключения не требуется). Заполните, как в примере):

   1. На сообщение с предложением выбрать, для какого домена задать идентификационные данные: KMS или Pangolin, выберите первый вариант, нажав 1:

      Choose credentials domain:
      1. KMS                         <-
      2. Pangolin
      1
      

   2. Укажите ID кластера (укажите имя своего кластера):

      Enter Pangolin cluster ID:
      KSG                            <-
      

   3. Последующие параметры при работе с заменителем значения не имеют, можно указать как в примере, IP address:

      Enter IP address:
      0.0.0.0                        <-
      

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

      Enter port:
      8200                           <-
      

   5. На сообщение о выборе типа учетных данных метода аутентификации, выберите Userpass Auth Method, нажав 1:

      Choose credentials type:
      1. Userpass Auth Method        <-
      2. AppRole Auth Method
      1
      

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

      Enter login:
      adminencryption                <-
      Enter password:
      ******                         <-
      Confirm password:
      ******                         <-
      

   7. На сообщение о добавлении еще одних учетных данных KMS ответьте no:

      Do you want to add another KMS credentials? (yes/no)?:
      no                             <-
      

   8. При успешном добавлении параметров появится сообщение:

      Credentials for KMS has been set successfully
      

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

      setup_kms_credentials --help
      

   9. В результате создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg:

      -rw-rw-r-- 1 kmadmin_pg kmadmin_pg    176 Oct  6 14:50 enc_connection_settings.cfg
      

4. Установите параметр is_tde_on = on в конфигурационном файле Pangolin (/etc/patroni/postgres.yml) на Active-узле, затем на Standby-узле:

   $ vim /etc/patroni/postgres.yml
   
   # перейдите в режим редактирования, введя i
   # изменить параметр is_tde_on
   
   is_tde_on: on  
   
   # выйдите из редактора, сохранив файл: нажмите **Esc**, введите :wq и нажмите **Enter**
   

5. Включите заменитель KMS. Для этого необходимо создать символьную ссылку на библиотеку /usr/pangolin-5.2.0/lib/libkms_substitute_plugin.so (на Active-узле, затем на Standby-узле):

   Примечание:

   В версиях 4.х.х-5.1.0 библиотека libconnector_plugin.so расположена в директории /usr/pgsql-se-04/lib, библиотека libkms_substitute_plugin.so в директории /usr/pgsql-se-04/lib/plugins, начиная с версии 5.2.0 в директориях /usr/pangolin-5.2.0/lib и /usr/pangolin-5.2.0/lib/plugins соответственно.

   cd /usr/pangolin-5.2.0/lib
   
   # удалите /usr/pangolin-5.2.0/lib/libconnector_plugin.so
   
   rm /usr/pangolin-5.2.0/lib/libconnector_plugin.so
   
   # создайте символьную ссылки на библиотеку
   
   ln -s /usr/pangolin-5.2.0/lib/plugins/libkms_substitute_plugin.so /usr/pangolin-5.2.0/lib/libconnector_plugin.so
   

6. Запустите кластера:      $ sudo systemctl start patroni    

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

    ```
    $ patronictl -c /etc/patroni/postgres.yml list $CLNAME
    + Cluster: clustername {cluster_name}+--------------+---------+----+-----------+
    | Member          | Host                    | Role         | State   | TL | Lag in MB |
    +-----------------+-------------------------+--------------+---------+----+-----------+
    | <Адрес сервера> | <Адрес сервера>:<Порт>  | Sync Standby | running |  4 |         0 |
    | <Адрес сервера> | <Адрес сервера>:<Порт>  | Leader       | running |  4 |           |
    +-----------------+-------------------------+--------------+---------+----+-----------+
    ```
   

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

    ```
    2022-10-09 14:56:35 MSK [5775]: [20-1] app=,user=,db=,client=,type=postmaster LOG:  Keyring initialization is started.
    2022-10-09 14:56:35 MSK [5775]: [21-1] app=,user=,db=,client=,type=postmaster LOG:  Master key initialization is started.
    2022-10-09 14:56:35 MSK [5775]: [22-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter 'initial_mk_create_mode' is not set in config. Default value is: TRUE.
    2022-10-09 14:56:35 MSK [5775]: [23-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-10-09 14:56:35 MSK [5775]: [24-1] app=,user=,db=,client=,type=postmaster LOG:  KmsSubstituteConnector::GetValue domain: postgresql clusterId: KSG subdomain: keys key: actual_master_key parameter type: Static
    2022-10-09 14:56:35 MSK [5775]: [25-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter value successfully loaded
    2022-10-09 14:56:35 MSK [5775]: [26-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-10-09 14:56:35 MSK [5775]: [27-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter value successfully loaded
    2022-10-09 14:56:35 MSK [5775]: [28-1] app=,user=,db=,client=,type=postmaster LOG:  Master key initialization is completed successfully.
    2022-10-09 14:56:35 MSK [5775]: [29-1] app=,user=,db=,client=,type=postmaster LOG:  KmsSubstituteConnector::GetValue domain: postgresql clusterId: KSG subdomain: keys key: wal_key parameter type: Static
    2022-10-09 14:56:35 MSK [5775]: [30-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter value successfully loaded
    2022-10-09 14:56:35 MSK [5775]: [31-1] app=,user=,db=,client=,type=postmaster LOG:  Keyring initialization is completed successfully.
    2022-10-09 14:56:35 MSK [5775]: [32-1] app=,user=,db=,client=,type=postmaster LOG:  WAL file is found: "/pgdata/05/data/pg_wal/000000010000000000000001".
    2022-10-09 14:56:35 MSK [5775]: [33-1] app=,user=,db=,client=,type=postmaster LOG:  WAL is not encrypted.
    2022-10-09 14:56:35 MSK [5775]: [34-1] app=,user=,db=,client=,type=postmaster LOG:  Initial WAL encryption is started...
    2022-10-09 14:56:35 MSK [5775]: [35-1] app=,user=,db=,client=,type=postmaster LOG:  The first WAL file is found: "pg_wal/000000010000000000000001"
    2022-10-09 14:56:35 MSK [5775]: [36-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/19AF230).
    2022-10-09 14:56:35 MSK [5775]: [48-1] app=,user=,db=,client=,type=postmaster LOG:  Initial WAL encryption is successfully completed.
    2022-10-09 14:56:35 MSK [5785]: [2-1] app=mkeychecker,user=,db=,client=[bgworker],type=mkeychecker LOG:  KmsSubstituteConnector::GetValue domain: postgresql clusterId: KSG subdomain: keys key: actual_master_key parameter type: Static
    2022-10-09 15:01:58 MSK [5785]: [9-1] app=mkeychecker,user=,db=,client=[bgworker],type=mkeychecker LOG:  Parameter value successfully loaded
    2022-10-09 14:56:58 MSK [5775]: [52-1] app=,user=,db=,client=,type=postmaster LOG:  KmsSubstituteConnector::GetValue domain: postgresql clusterId: KSG subdomain: postgresql key: secure_config parameter type: Dynamic
    2022-10-09 14:56:58 MSK [5775]: [53-1] app=,user=,db=,client=,type=postmaster LOG:  Parameter value successfully loaded. Value: off
    ```
   

9. Проверьте создание ключей в кластере.

   При первом старте БД, с учетом настроек прозрачного шифрования данных, ключи шифрования будут созданы в директории $PGDATA/global:

   $ cd $PGDATA/global/  
   
   # файл $PGDATA/global/enc_settings.cfg с меткой актуального мастер-ключа  
   
   -rw------- 1 postgres postgres    84 Oct  9 14:56 enc_settings.cfg
   
   # файл $PGDATA/global/enc_keys.json с ключами шифрования табличных пространств, отношений и журналов WAL  
   
   -rw------- 1 postgres postgres   228 Oct  9 14:56 enc_keys.json
   

10. Проверьте успешное включение TDE в кластере.

    Для проверки включения прозрачного шифрования хранимых данных (Transparent Data Encryption) воспользуйтесь функцией проверки check_tde_is_on():

    postgres=# SELECT * FROM check_tde_is_on();
    check_tde_is_on
    -----------------
    t
    (1 row)
    

    Возврат функцией значения t (true) означает, что прозрачное шифрование хранимых данных в СУБД включено.

Прозрачное шифрование (Transparent Data Encryption)#

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

Для шифрования данных используется алгоритм шифрования AES, реализованный в рамках модуля Encryption support. Encryption support — модуль, который обеспечивает прозрачное шифрование данных (TDE). С его помощью шифруются данные, хранящиеся в файлах данных, журналах изменений, резервных копиях и временных файлах баз данных, а также данные, передаваемые по каналам связи в ходе физической и логической репликации.

Ключи шифрования организуются в двухуровневую иерархию, корнем которой является мастер-ключ, который регулярно изменяется. Мастер-ключ используется для шифрования ключей второго уровня (ключей шифрования объектов баз данных). Ключи шифрования второго уровня не ротируются, поэтому при смене мастер-ключа перешифровывать данные не требуется. Ротация мастер-ключа инициируется и выполняется на главном сервере СУБД PostgreSQL.

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

Концептуальная архитектура Pangolin при реализации прозрачного шифрования:

Помимо указанных на схеме, Encryption support включается также в следующие процессы и утилиты:

• WAL Sender и WAL Receiver

• pg_recvlogical

• pg_resetwal

• pg_probackup

• pg_rewind

• pg_waldump

• checkpointer

Работа с системой шифрования#

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

• Изменение параметров соединения с KMS и шифрования учетных данных (credentials) для соединения с KMS. Доступ к этой функции осуществляется через утилиту настройки соединения с KMS на СУБД PostgreSQL.

• Ротация мастер-ключа. SQL-запрос:

  SELECT * from rotate_master_key();
  

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

• Установка мастер-ключа. SQL-запрос:

  SELECT * from set_master_key('{ключ}');
  

  где {ключ}– ключ, закодированный по стандарту base64.

  Эта процедура аналогична ротации мастер-ключа, но в этом случае ключ устанавливает администратор безопасности.

• Перешифрование ключей текущим мастер-ключом. SQL-запрос:

    SELECT * from reencrypt_keys();
  

• Восстановление ключей шифрования при сбое перешифрования. SQL-запрос:

    SELECT * from restore_keys();
  

• Включение или выключение шифрования табличных пространств. Это параметр табличного пространства, он задается при создании пространства следующей DDL-командой:

    CREATE tablespace <Имя табличного пространства> LOCATION <расположение табличного пространства> with (is_encrypted = on);
  

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

• Создание зашифрованных отношений. Чтобы создаваемое отношение было зашифрованным, необходимо явно создать его в зашифрованном табличном пространстве. Если этого не сделать, то отношение будет создано в табличном пространстве по умолчанию, а оно может быть не зашифрованным. Однако если сама база данных создана в зашифрованном табличном пространстве, дополнительно указывать зашифрованное табличное пространство при создании отношения не требуется.

Описание процессов#

Первоначальная настройка шифрования для сервера СУБД Pangolin#

Алгоритм первоначальной настройки шифрования:

1. Администратор БД выводит сервер из обслуживания приложений и останавливает СУБД.

2. Администратор БД выполняет настройку параметра в конфигурационном файле Pangolin для включения шифрования.

3. При наличии выделенной учетной записи для сотрудника ИБ он запускает утилиту setup_kms_credentials и создает файл с параметрами соединения с KMS.

4. При необходимости сотрудник ИБ устанавливает мастер-ключ в KMS вручную.

   Примечание:

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

5. СУБД перезапускается (или запускается, если была остановлена на шаге 1 и возвращается в работу).

Для настройки шифрования требуется наличие установленного и интегрированного решения Key/Secret Management System, которое отвечает за хранение и управление секретами, либо реализация KMS-заменителя на сервере Pangolin: вместо хранилища секретов KMS в HashiCorp Vault используются локальные конфигурационные файлы.

Смена мастер-ключа шифрования#

Смена мастер-ключа шифрования:

1. При наличии выделенной учетной записи для сотрудника ИБ он инициирует процесс установки нового мастер-ключа шифрования БД в KMS.

   Примечание:

   Если новый мастер-ключ не был указан, то он генерируется автоматически.

2. Новый мастер-ключ устанавливается в KMS.

3. Резервная копия предыдущего мастер-ключа сохраняется в KMS для использования в процедурах восстановления данных.

4. Метка мастер-ключа устанавливается в KMS.

5. Ключи шифрования перешифровываются новым ключом.

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

Восстановление шифрования БД при сбое процесса перешифрования БД#

При сбое процесса перешифрования БД выполняется алгоритм восстановления шифрования:

1. Система или администратор БД инициируют восстановление шифрования.

2. Из KMS выгружаются актуальный и предыдущие мастер-ключи в следующем порядке:

   • по локальной метке текущего мастер-ключа;

   • по локальной метке предыдущего мастер-ключа (если существует);

   • по метке текущего мастер-ключа в KMS;

   • по метке предыдущего мастер-ключа в KMS (если существует).

3. Ключи шифрования расшифровываются. Для расшифровки ключей шифрования мастер-ключи применяются в том же порядке, в котором они выгружались. Если ключи шифрования не удалось расшифровать ни одним из извлеченных ключей, система выдает ошибку «Не найден подходящий мастер-ключ».

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

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

Шифрование БД и объектов БД#

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

1. Администратор БД создает зашифрованное табличное пространство, которое будет использоваться создаваемой шифруемой БД по умолчанию. Для создаваемого табличного пространства автоматически создается ключ шифрования.

2. Если необходимо отдельное зашифрованное временное табличное пространство (пространство, в котором будут создаваться временные объекты - временные таблицы и индексы временных таблиц), администратор БД создает его. Для временного табличного пространства автоматически создается ключ шифрования.

3. Если необходимо отдельное зашифрованное табличное пространство для данных, администратор БД создает его. Для этого табличного пространства автоматически создается ключ шифрования.

4. Администратор БД создает шифруемую базу данных, размещаемую в одном из созданных табличных пространств. При этом создаются отношения системного каталога БД и для них автоматически генерируются ключи шифрования.

5. Администратор создает объекты базы данных с указанием табличных пространств для их размещения или с размещением в табличном пространстве по умолчанию для этой БД. Для создаваемых отношений БД автоматически генерируются ключи шифрования.

Создание резервной копии БД, содержащей зашифрованные данные#

Создание резервной копии БД с зашифрованными данными происходит следующим образом:

1. Администратор БД запускает процедуру создания резервной копии.

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

   • если необходим SQL-скрипт заполнения БД без шифрованных данных, то выгружается такой скрипт. Для этого используются утилиты pg_dump и pg_dumpall.

Восстановление из бинарной резервной копии БД#

Восстановление из бинарного файла резервной копии БД происходит по следующему алгоритму:

1. Администратор БД выводит БД Pangolin из обслуживания приложений и останавливает СУБД.

2. Администратор БД очищает каталог с данными БД (PGDATA).

3. Администратор БД запускает утилиту восстановления БД из резервной копии. При этом указывается файл резервной копии, содержащий зашифрованные данные, системный каталог с зашифрованными ключами шифрования и метка мастер-ключа, актуального на момент создания резервной копии.

4. По завершении восстановления администратор запускает экземпляр СУБД.

5. Система извлекает информацию о метке мастер-ключа, актуального на момент создания резервной копии.

6. По этой метке запрашивается из KMS мастер-ключ, актуальный на момент создания резервной копии.

7. Система запрашивает из KMS актуальный мастер-ключ.

8. Выгружаются ключи шифрования из резервной копии.

9. Если мастер-ключ резервной копии и актуальный мастер-ключ не совпадают, система перешифровывает ключи шифрования из резервной копии.

10. СУБД запускается в штатном режиме.

11. Администратор СУБД возвращает сервер в обслуживание приложений.

Репликация между серверами СУБД Pangolin, содержащими зашифрованные данные#

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

1. В результате запроса к Active-узлу СУБД на нем происходит изменение данных.

2. Запись об изменениях на Active-узле заносится в WAL в зашифрованном виде.

3. Выполняется репликация содержимого файла WAL. Репликация может быть потоковой и логической. Тип репликации выбирает администратор БД.

Потоковая репликация:

1. Блоки с изменениями из зашифрованного файла WAL передаются узлу-получателю.

2. На узле-получателе блоки принимаются и записываются в файл WAL.

3. Файл WAL расшифровывается с помощью ключа шифрования из KMS.

   • если файл WAL удалось расшифровать, изменения из него применяются;

   • если файл WAL не удалось расшифровать, система пытается найти нужную запись в архиве и применить ее:

     • если запись найдена, она применяется;

     • если запись не найдена или архивирование не настроено, система снова пытается расшифровать WAL.

Логическая репликация:

1. Из зашифрованного журнала WAL Active-узла считываются изменения в зашифрованном виде.

2. Изменения расшифровываются ключом WAL.

3. Расшифрованные изменения декодируются и преобразуются в сообщения формата CopyEncryptedData.

4. Сообщения формата CopyEncryptedData шифруются ключом WAL.

5. Зашифрованные сообщения CopyEncryptedData отправляются узлу-получателю в соответствии с подписками.

6. Принятые сообщения расшифровываются ключом шифрования WAL.

7. Из расшифрованных сообщений извлекаются записи изменений WAL.

8. Извлеченные записи изменений применяются к WAL узла-получателя.

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

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

• таблицы на действия:

  • 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.

Защита данных от привилегированных пользователей (администраторов баз данных)#

Создание и настройка экземпляра PostgreSQL в составе кластера высокой доступности#

Первоначальная настройка экземпляра PostgreSQL осуществляется следующим образом:

1. Администратор PostgreSQL производит установку ПО СУБД PostgreSQL.

2. Администратор ОС выдает права администратору безопасности на запуск утилит инициализации безопасности PostgreSQL, в том числе шифрования секрета для доступа к системе управления ключами доступа (KMS).

3. Администратор безопасности выполняет утилиту шифрования секрета для доступа к KMS и создает файл с зашифрованным секретом.

4. Если это первый в этом кластере экземпляр PostgreSQL:

   1. Администратор PostgreSQL выполняет инициализацию экземпляра PostgreSQL с помощью утилиты initdb.

   2. Администратор PostgreSQL выполняет настройку параметров экземпляра PostgreSQL, которые не относятся к безопасности или дублируют параметры безопасности, и указывает идентификатор кластера в конфигурационном файле.

   3. Администратор PostgreSQL выполняет запуск экземпляра PostgreSQL.

   4. Администратор PostgreSQL останавливает экземпляр PostgreSQL.

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

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

   7. Администратор PostgreSQL создает табличные пространства и рабочие базы данных PostgreSQL, защищенные прозрачным шифрованием и механизмом защиты.

5. Администратор PostgreSQL устанавливает и настраивает параметры Patroni и pgBouncer, не относящиеся к безопасности или дублирующие параметры настроек безопасности.

6. Администратор PostgreSQL запускает утилиту шифрования секрета, шифрует пары логин/пароль, используемые Patroni и pgBouncer для подключения к PostgreSQL, и вносит зашифрованные пары в их конфигурационные файлы.

7. Администратор PostgreSQL запускает сконфигурированные компоненты кластера высокой доступности в составе кластера.

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

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

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

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

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

4. Утилита запрашивает логин и пароль и создает новую учетную запись администратора безопасности с указанными логином и паролем.

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

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

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

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

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

5. Администратор безопасности (не владелец создаваемой записи) помещает объект БД – роль создаваемой учетной записи администратора безопасности – под защиту механизма защиты данных.

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

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

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

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

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

3. Администратор PostgreSQL удаляет учетную запись из PostgreSQL.

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

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

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

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

1. Администратор PostgreSQL создает ТУЗ и задает исходные логин и пароль.

2. Администратор PostgreSQL выдает ТУЗ необходимые роли и разрешения на доступ к объектам БД в рамках системы прав PostgreSQL.

3. Владелец ТУЗ меняет пароль учетной записи.

4. Администратор безопасности указывает необходимость двухфакторной аутентификации для ТУЗ в pg_hba.conf в защищенном хранилище.

5. Администратор безопасности назначает ТУЗ ранее созданную политику с необходимыми приложению разрешениями.

6. Администратор безопасности помещает объект роли ТУЗ под защиту механизма защиты данных.

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

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

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

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

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

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

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

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

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

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

1. Владелец ТУЗ или администратор безопасности инициирует процесс изменения пароля.

2. Администратор безопасности снимает политики, дающие учетной записи доступ к защищаемым данным.

3. Администратор безопасности изменяет pg_hba.conf в защищенном хранилище, отключая требование двухфакторной аутентификации для учетной записи.

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

5. Владелец ТУЗ устанавливает новый пароль:

   1. Если изменение пароля ТУЗ было инициировано администратором безопасности, то сначала новый пароль устанавливает администратор PostgreSQL, затем – владелец ТУЗ.

6. Администратор безопасности изменяет pg_hba.conf в защищенном хранилище, включая требование двухфакторной аутентификации для учетной записи.

7. Администратор безопасности помещает роль учетной записи под защиту механизма защиты данных.

8. Администратор безопасности назначает политики, дающие учетной записи доступ к защищаемым данным.

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

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

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

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

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

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

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

1. Поступает запрос на обращение к объекту базы данных.

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

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

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

   1. Если запрос не соответствует ни одному разрешению, возвращается ошибка.

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

Для целей соблюдения лицензионных условий применяется файл, содержащий параметры лицензии и подписанный цифровой подписью с использованием приватного ключа, хранимого в закрытом репозитории СУБД Pangolin. Реализация цифровой подписи основана на RSA-шифровании, предоставляемом библиотекой OpenSSL:

openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Примечание:

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

Для работы с лицензиями реализуется библиотека, предоставляющая возможность проверки наличия лицензии, ее тип и срок действия. Данная библиотека статически подключается к продукту и его утилитам для проверки доступности лицензируемой функциональности. Файл лицензии хранится и обрабатывается в формате JSON. Электронная цифровая подпись хранится в самом файле. Подписывается секция license, содержащая следующие поля:

• end_date - дата окончания в формате <year>-<month>-<day> <hour>:<minute>:<second>;

• licensee - лицо, имеющее право использования лицензией;

• type - тип лицензии в строковом представлении, отображающемся в перечисление LicenseType:

  typedef enum
  {
     LICTYPE_EnterpriseWith1C,
     LICTYPE_Trial,
     LICTYPE_Enterprise,
     LICTYPE_StandardWith1C,
     LICTYPE_Standard,
     LICTYPE_Undefined
  } LicenseType;
  

• features - список дополнительной функциональности в строковом представлении, отображающемся в перечисление LicensedFeature:

  typedef enum
  {
     LIC_TDE,
     LIC_AuthEncryption,
     LIC_Protection,
     LIC_SecuredConfig,
     LIC_Masking,
     LIC_CertPKCS12,
     LIC_PerformanceInsights,
     LIC_RelBlock,
     LIC_DateMotidification,
     LIC_ConnectionQuota,
     LIC_OutlineQuery,
     LIC_Support1C,
     LIC_PreparedStatements,
     LIC_NativePartitioning,
     LIC_DiagnosticTool,
     LIC_GraceAuth,
     LIC_ResourceConsumptionLimits,
     LIC_JsonTable,
     LIC_GI,
     LIC_Tracing,
     LIC_COUNT
  } LicensedFeature;
  

• total_CPUs - количество ядер процессора, которые может использовать запущенный продукт СУБД Pangolin (в случае отсутствия поля процессам доступны все ядра);

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

Пример файла лицензии:

{
   "license" : {
      "end_date" : "2023-07-01 12:00:00",
      "features" : [ ],
      "licensee" : "Pangolin internal tests", 
      "total_CPUs" : 6,
      "total_mem": 3221225472,
      "type" : "EnterpriseWith1C"
   },
   "sign" : "XvfXFnSWqws/6S1tVehdq4o5lO1s4LEYkhlkPVtINm6KLBb3xI43EYaTT2eVHqAAnSnjxtLyn0/dzCg+waLQdk5OLK2ezGGK2iFVey3H167C5hXUxFvXGMbhnXvEHZILHFnsKrF6FUlnbt3kOlKjLLX2qetpm/i280FTjeSk52CdB3JeJwzL8tEzyq8j9ZimeA9N985fKHdpwOG4kCRFjJ1dmdmNZmQjqNQyv4aF1DL5yb4OU+1jHvfSaQ7Mg/ap8Nsc4cYQ7Yj3VDB7Upr35l1FnQdXEzoL7Ln9vMTkUktka4WDWdqlxOeOdxxdt/4usMRd8vwqE6JRQ6x8SJN06A=="
}  

Внимание!

На данный момент возможность расширения типа лицензии дополнительной функциональностью отключена макросом SUPPORT_FEATURE_LICENSING. Поэтому перечисление дополнительной функциональности в секции features не влияет на содержание лицензии.

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

Особенности при смене лицензии Enterprise (Trial) на Standard#

При изменении типа лицензии:

• В случае ранее настроенного шифрования данных зашифрованные данные остаются доступны, но дальнейшее шифрование не осуществляется.

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

• В рамках обновления продукта с использованием утилиты pg_upgrade каталоги безопасности обновлены не будут.

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

• Обновление с версий до 5.3.1 возможно двумя способами:

  • обновление кластера до версии 5.5.4 с использованием лицензии Trial -> отключение шифрования -> переход на регулярную версию Standard;

  • обновление кластера до версии 5.3.1 -> отключение шифрования -> обновление до 5.5.4 с лицензией Standard.

• В ОС РЕД ОС использование механизма контрольных групп для приведения сервера к условиям лицензии в части доступных ресурсов не поддерживается.

Добавляемые утилиты#

Помимо описанных выше, реализована утилита, подписывающая лицензии, а также утилита, осуществляющая проверку ранее подписанной лицензии - psql_rsa_sign и psql_rsa_verify соответственно.

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

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

• --key, -k  <path> - расположение файла, содержащего приватный RSA-ключ (обязательный параметр);

• --out, -o <path> - расположение подписанного файла лицензии (опциональный параметр, в случае отсутствия подпись будет добавлена ко входному файлу);

• --version, -V - версия продукта, в составе которой была собрана данная утилита;

• --help, -? - вывод справки о способах запуска утилиты.

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

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

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

• --json, -j - флаг, указывающий о необходимости вывода данных о верификации, а также параметров лицензии в формате JSON (используется для автоматизации установки);

• --key, -k <path> - расположение файла, содержащего публичный RSA-ключ (в случае отсутствия данного параметра для верификации используется прекомпилированный ключ продукта);

• --version, -V - версия продукта, в составе которой была собрана данная утилита;

• --help, -? - вывод справки о способах запуска утилиты.

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

Использование подписанного файла лицензии сервером#

Загрузка лицензии#

Файл подписанной лицензии располагается на машине установки экземпляра продукта. Переменная окружения pangolin_license_path задает путь к директории, которая содержит лицензии или путь к конкретному файлу лицензии. Данная переменная окружения используется самим сервером и его утилитами для получения данных об используемой лицензии. По умолчанию используется директория /opt/pangolin_license. В директории единовременно могут находиться несколько лицензий. Модуль загрузки лицензий выбирает лицензию с валидным сроком действия, руководствуясь следующей системой приоритетов по доступной функциональности (от высокого к низкому):

• EnterpriseWith1C;

• Trial;

• Enterprise;

• StandardWith1C;

• Standard.

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

Ограничение лицензируемой функциональности под управлением конфигурационного параметра#

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

Ограничение лицензируемой функциональности, не имеющей управляющих параметров#

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

• нативное интервальное партиционирование;

• маскирование паролей;

• квотирование подключений;

• шифрование пользовательских данных.

Функциональность шифрования данных после включения не может быть отключена через параметр конфигурации is_tde_on из-за наличия шифрования не только пользовательских данных, но и служебной информации WAL и CHECKPOINT. Поэтому данная лицензируемая функциональность при лицензии Standard и включенном параметре is_tde_on осуществляет шифрование служебной информации, но не пользовательских данных. Параметр конфигурации сервера не переопределяется на старте, однако, в лог пишется предупреждение о невозможности использования шифрованных табличных пространств. На работающем экземпляре продукта проверка доступности данной функциональности должна проверяться с помощью функции мониторинга check_tde_is_on(), а не через прямое чтение параметра конфигурации.

Проверка времени действия лицензии#

При запуске основного процесса СУБД создается процесс, контролирующий время жизни лицензии. Данный процесс осуществляет мониторинг текущего времени на предмет соответствия времени действия лицензии. Если время действия лицензии закончилось, производится попытка перечитать лицензию, чтобы загрузить новые данные при обновлении лицензии, после чего процесс мониторинга продолжает штатное функционирование с новыми данными. В противном случае серверу посылается сигнал SIGINT для завершения работы продукта.

Лицензия может быть перезагружена без ожидания окончания времени действия текущей лицензии. Для этого необходимо выполнить перезагрузку (reload) СУБД. Если при обновлении лицензии ее тип изменился на более широкую по функциональности лицензию, то процесс контролирующий время действия лицензии будет использовать новое время для проверки актуальности. Ограничения функциональности будут определяться первоначальной лицензией. Это связано с тем, что большинство параметров конфигурации лицензируемой функциональности могут быть изменены только при запуске продукта. При этом в логе после загрузки новой лицензии будет получено предупреждение о том, что для использования новой лицензии в полном объеме необходима перезагрузка СУБД. В случае, если при обновлении лицензии загружена лицензия с меньшим набором функциональности, продукт будет остановлен автоматически, так как при конфигурации продукта СУБД Pangolin с оркестратором patroni последний автоматически перезапустит СУБД с новой лицензией.

Для предотвращения попытки остановить процесс проверки лицензии сигналом SIGSTOP основной процесс отслеживает состояние процесса данной проверки и в случае остановки самостоятельно посылает ему сигнал SIGCONT для возобновления процесса.

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

Проверка лицензии в утилитах#

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

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