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

Прозрачное защитное преобразование данных (TDE)

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

В СУБД Pangolin при помощи TDE преобразование данные:

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

Описание​

Для преобразования данных применяется алгоритм AES, который реализован в рамках модуля Encryption support. Эта технология обеспечивает прозрачность для приложений, то есть засекречивание и декодирование данных происходят без необходимости внесения изменений в код приложений.

TDE интегрируется с системой управления ключами (Key Management System, KMS) HashiCorp Vault, которая отвечает за хранение секретов, таких как ключи API и пароли.

примечание

При прерывании процесса преобразования WAL-файлов в СУБД Pangolin на диске могут оставаться файлы $PGDATA/global/enc_keys.json и $PGDATA/global/enc_settings.cfg. Из-за данных файлов появляются ошибки чтения WAL-файлов утилитой pg_waldump. Необходимо удалить файлы вручную, если в дальнейшем не планируется повторный запуск включения TDE сразу после аварийного прерывания процесса преобразования WAL-файлов. Если запустить повторное засекречивание, то удалять файлы необязательно.

Настройка прозрачного защитного преобразования данных​

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

Настройка прозрачного защитного преобразования данных на сервере​

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

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

SHOW installer.cluster_type;

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

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

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

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

    примечание

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

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

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

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

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

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

    • остановите Pangolin Manager (сначала на Standby-узле, затем на Active-узле во избежание переключения Active-узла на Standby):

      $ sudo systemctl stop pangolin-manager

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

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

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

    • для редактирования конфигурационного файла выполните команду:
    $ vim /etc/pangolin-manager/postgres.yml

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

    is_tde_on: on

    # выйти из редактора, сохранив файл: нажмите **Esc**, введите :wq и нажмите **Enter**
    • в версии ниже 4.3.х проверьте наличие у пользователя postgres прав 700 (задайте при отсутствии) на директорию /etc/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-6.5.2/bin/):
    $ /usr/pangolin-6.5.2/bin/setup_kms_credentials

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

      • на сообщение с предложением выбрать, для какого домена задать идентификационные данные: KMS или Pangolin, выберите первый вариант, нажав 1:
      Choose credentials domain:
      1. KMS                         <-
      2. Pangolin
      1
      • укажите ID кластера (при добавлении параметров в KMS в качестве имени CLUSTER_ID указывается имя используемого кластера):
      Enter Pangolin cluster ID:
      KSG                            <-
      • укажите IP-адрес KMS:
      Enter IP address:
      <host IP>                    <-
      • далее необходимо указать порт KMS:
      Enter port:
      8200                           <-
      • на сообщение о выборе типа учетных данных и методе аутентификации выберите Userpass Auth Method, нажав 1:
      Choose credentials type:
      1. Userpass Auth Method        <-
      2. AppRole Auth Method
      1
      • введите логин и пароль администратора:
      Enter login:
      adminencryption                <-
      Enter password:
      ******                         <-
      Confirm password:
      ******                         <-
      • на сообщение о добавлении дополнительных учетных данных KMS, ответьте no:
      Do you want to add another KMS credentials? (yes/no)?:
      no                             <-
      • при успешном добавлении параметров появится сообщение:
      Credentials for KMS has been set successfully

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

      setup_kms_credentials --help
      • в результате создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg:
      -rw-rw-r-- 1 kmadmin_pg kmadmin_pg    176 Oct  5 07:55 enc_connection_settings.cfg

  4. Запустите кластер:

    • запустите кластер (сначала на Active-узле, затем на Standby-узле):
    $ sudo systemctl start pangolin-manager
    • проверьте состояние узлов кластера:
    $ patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME
    + Cluster: clustername (7151342043309644683)+--------------+---------+----+-----------+
    | Member          | Host                    | Role         | State   | TL | Lag in MB |
    +-----------------+-------------------------+--------------+---------+----+-----------+
    | <Адрес сервера> | <Адрес сервера>:<Порт>  | Sync Standby | running |  4 |         0 |
    | <Адрес сервера> | <Адрес сервера>:<Порт>  | Leader       | running |  4 |           |
    +-----------------+-------------------------+--------------+---------+----+-----------+

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

    • в хранилище ключей 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

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

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

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

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

Интерфейс коннектора KMS можно заменить на плагин-заменитель KMS, который использует локальные конфигурационные файлы вместо хранилища секретов. Этот плагин считывает данные из двух файлов:

  • /etc/postgres/kms_static_params.cfg: содержит постоянные параметры, засекреченные ключом, сгенерированным на основе настроек сервера;
  • /etc/postgres/kms_dynamic_params.cfg: включает изменяемые параметры, которые могут обновляться. Все изменения в этом файле должны быть одинаковыми на всех серверах кластера.

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

С подробной информацией о KMS-заменителе можно ознакомиться в подразделе «KMS-заменитель» раздела «HashiCorp Vault и KMS-заменитель» документа «Инструкции и рекомендации».

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

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

  • нельзя менять главный ключ засекречивания (ротация мастер-ключа запрещена);
  • параметры кластера, сохраненные в KMS, можно изменять только тогда, когда база данных выключена.

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

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

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

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

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

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

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

  1. Администратор БД выводит кластер из обслуживания приложений и останавливает СУБД на Standby-узле, затем на Active-узле.
  2. Администратор БД подготавливает файлы со статическими и динамическими параметрами.
  3. Сотрудник ИБ (при наличии) запускает утилиту setup_kms_credentials (создает файл с параметрами соединения с KMS).
  4. Администратор устанавливает параметр is_tde_on = on в конфигурационном файле СУБД Pangolin (/etc/pangolin-manager/postgres.yml).
  5. Администратор БД включает заменитель KMS.
  6. Администратор БД запускает кластер.
  7. Администратор БД проверяет создание ключей засекречивания в кластере СУБД Pangolin в директории $PGDATA/global/.
  8. Администратор БД проверяет успешное включение TDE в кластере.

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

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

    • остановите Pangolin Manager (сначала на Standby-узле, затем на Active-узле во избежание переключения Active-узла на Standby):
    $ sudo systemctl stop pangolin-manager
    • проверьте состояние кластера:
     $ patronictl -c /etc/pangolin-manager/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 с правами 700 у владельца postgres):
    drwx------   2 postgres postgres   4096 Sep  1 08:31 postgres

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

  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-6.5.2/bin/):
    $ /usr/pangolin-6.5.2/bin/setup_kms_credentials

    • укажите в качестве имени кластера и credentials domain — KMS;

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

     Choose credentials domain:
     1. KMS                         <-
     2. Pangolin
        1
    • укажите имя своего кластера:
     Enter Pangolin cluster ID:
     KSG                            <-
    • далее и последующие параметры при работе с заменителем значения не имеют, укажите как в примере:
     Enter IP address:
     0.0.0.0                       <-
    • укажите порт KMS:
     Enter port:
     8200                           <-
    • на сообщение о выборе типа учетных данных метода аутентификации, выберите Userpass Auth Method, нажав 1:
     Choose credentials type:
     1. Userpass Auth Method        <-
     2. AppRole Auth Method
        1
    • введите логин и пароль администратора:
     Enter login:
     adminencryption                <-
     Enter password:
     ******                         <-
     Confirm password:
     ******                         <-
    • на сообщение о добавлении еще одних учетных данных KMS ответьте no:
    Do you want to add another KMS credentials? (yes/no)?:
    no                             <-
    • при успешном добавлении параметров появится сообщение:
    Credentials for KMS has been set successfully
    • если при установке возникли проблемы, воспользуйтесь командой:
    setup_kms_credentials --help
    • в результате создан файл с параметрами соединения с KMS /etc/postgres/enc_connection_settings.cfg:
    -rw-rw-r-- 1 kmadmin_pg kmadmin_pg    176 Oct  6 14:50 enc_connection_settings.cfg

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

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

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

    is_tde_on: on

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

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

    cd /usr/pangolin-6.5.2/lib

    # удаление /usr/pangolin-6.5.2/lib/libconnector_plugin.so

    rm /usr/pangolin-6.5.2/lib/libconnector_plugin.so

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

    ln -s /usr/pangolin-6.5.2/lib/plugins/libkms_substitute_plugin.so /usr/pangolin-6.5.2/lib/libconnector_plugin.so
    примечание

    В версиях 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-6.5.2/lib и /usr/pangolin-6.5.2/lib/plugins соответственно.

  6. Выполните запуск кластера:

    • выполните старт кластера (сначала на Active-узле, затем на Standby-узле):
    $ sudo systemctl start pangolin-manager
    • проверьте состояние узлов кластера:
     $ patronictl -c /etc/pangolin-manager/postgres.yml list $CLNAME
     + Cluster: clustername (7151342043309644683)+--------------+---------+----+-----------+
       | Member          | Host                    | Role         | State   | TL | Lag in MB |
       +-----------------+-------------------------+--------------+---------+----+-----------+
       | <Адрес сервера> | <Адрес сервера>:<Порт>  | Sync Standby | running |  4 |         0 |
       | <Адрес сервера> | <Адрес сервера>:<Порт>  | Leader       | running |  4 |           |
       +-----------------+-------------------------+--------------+---------+----+-----------+
    • в логе проверьте, что параметры 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/0{major_version}/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

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

    При первом старте БД после выполнения настройки прозрачного защитного преобразования данных будут созданы ключи кодирования в директории $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

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

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

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

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

Управление​

Первоначальная настройка защитного преобразования для сервера СУБД Pangolin​

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

  • администратор БД останавливает СУБД Pangolin и выводит сервер из эксплуатации;
  • администратор БД настраивает параметр в конфигурационном файле СУБД Pangolin для включения засекречивания;
  • сотрудник службы безопасности запускает утилиту setup_kms_credentials и создает файл с параметрами подключения к KMS;
  • при необходимости сотрудник службы безопасности устанавливает мастер-ключ в KMS вручную. Если ключ не установлен, используется автоматически сгенерированный при первом запуске БД;
  • администратор БД перезапускает СУБД Pangolin и возвращает в эксплуатацию.

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

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

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

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

Смена мастер-ключа защитного преобразования​

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

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

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

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

Восстановление защитного преобразования БД при сбое процесса перекодирования БД​

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

  1. Система или администратор инициируют процедуру восстановления.

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

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

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

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

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

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

Администратор запускает процедуру резервного копирования:

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

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

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

  1. Администратор БД останавливает СУБД и выводит сервер из эксплуатации.
  2. Администратор БД очищает каталог с данными БД (PGDATA).
  3. Администратор БД запускает утилиту восстановления из резервной копии, указывая файл с засекреченными данными, системный каталог с ключами кодирования и метку мастер-ключа на момент создания копии.
  4. После завершения восстановления Администратор БД запускает экземпляр СУБД Pangolin.
  5. СУБД Pangolin получает информацию о метке мастер-ключа из резервной копии и запрашивает соответствующие ключи из KMS.
  6. Если мастер-ключи отличаются, СУБД Pangolin перекодирует ключи из резервной копии.
  7. Администратор БД запускает СУБД Pangolin в обычном режиме, и сервер возвращается в эксплуатацию.

Прозрачное защитное преобразование данных и объектов базы данных​

Прозрачное защитное преобразование базы данных и ее объектов в СУБД Pangolin происходит следующим образом:

  1. Администратор БД создает засекреченное табличное пространство для новой базы данных, при этом автоматически создается ключ кодирования.
  2. Администратор БД затем создает саму засекреченную базу данных, размещенную в одном из созданных табличных пространств. При этом автоматически генерируются ключи кодирования для системного каталога базы данных.
  3. Администратор БД далее создает объекты базы данных (например, таблицы), указав табличные пространства для их размещения. Для новых объектов автоматически генерируются свои ключи кодирования. Чтобы объекты были закодированы, их следует размещать в специально созданном закодированном табличном пространстве.
  4. Для создания засекреченных табличных пространств используется команда с опцией WITH (is_encrypted = on), которая задается только при их создании. Изменять значение этой опции запрещено, поскольку это потребует повторного защитного преобразования или рассекречивания всех данных в данном пространстве.

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

Пример защитного преобразования объектов БД​

  1. Создайте директорию для засекреченного табличного пространства /pgdata/0{major_version}/tablespaces/tde_on и директорию для незасекреченного пространства /pgdata/0{major_version}/tablespaces/tde_off (на всех узлах):

    $ mkdir /pgdata/0{major_version}/tablespaces/tde_on
    $ mkdir /pgdata/0{major_version}/tablespaces/tde_off

  2. Создайте засекреченное и незасекреченное табличные пространства:

    CREATE TABLESPACE tde_on LOCATION '/pgdata/0{major_version}/tablespaces/tde_on' WITH (is_encrypted = on);

    CREATE TABLESPACE tde_off LOCATION '/pgdata/0{major_version}/tablespaces/tde_off';

  3. Проверьте созданные табличные пространства:

    SELECT * FROM pg_tablespace;
    oid  |  spcname   | spcowner |                  spcacl                   |    spcoptions
    -------+------------+----------+-------------------------------------------+-------------------
    1663 | pg_default |       10 |                                           |
    1664 | pg_global  |       10 |                                           |
    16400 | Tbl_t      |    16387 | {db_admin=C/db_admin,as_admin=C/db_admin} |
    17823 | tde_on     |       10 |                                           | {is_encrypted=on}
    17824 | tde_off    |       10 |                                           |
    (5 rows)

    # в директории /pgdata/0{major_version}/tablespaces

    drwx------ 3 postgres postgres 4096 Oct  6 04:53 Tbl_t
    drwx------ 3 postgres postgres 4096 Oct  6 08:51 tde_off
    drwx------ 3 postgres postgres 4096 Oct  6 08:50 tde_on

  4. Выдайте привилегии групповой роли as_admin на созданные табличные пространства:

    => GRANT ALL PRIVILEGES ON TABLESPACE tde_on TO as_admin;

    => GRANT ALL PRIVILEGES ON TABLESPACE tde_off TO as_admin;

  5. Выполните вход пользователем в БД с групповой ролью as_admin, создайте таблицы в засекреченном и незасекреченном табличных пространствах, добавьте в них данные:

    => CREATE TABLE table_tde_on (id int, a text) TABLESPACE tde_on;

    => INSERT INTO table_tde_on VALUES (1, 'Matrena');

    => CREATE TABLE table_tde_off (id int, a text) TABLESPACE tde_off;

    => INSERT INTO table_tde_off VALUES (1, 'Fedora');

  6. Выполните контрольную точку:

    # checkpoint;

  7. Выполните поиск ранее добавленных записей в таблицы по файлам данных в директориях БД /pgdata/0{major_version}/data/base, /pgdata/0{major_version}/data/pg_wal, /pgdata/0{major_version}/tablespaces:

    cd /pgdata/0{major_version}
    $ grep -R 'Matrena' /pgdata/0{major_version}/data/base
    $ grep -R 'Matrena' /pgdata/0{major_version}/data/pg_wal
    $ grep -R 'Matrena' /pgdata/0{major_version}/tablespaces

    $ grep -R 'Fedora' /pgdata/0{major_version}/data/base
    $ grep -R 'Fedora' /pgdata/0{major_version}/data/pg_wal
    $ grep -R 'Fedora' /pgdata/0{major_version}/tablespaces
    Binary file /pgdata/0{major_version}/tablespaces/tde_off/PG_13_20220{major_version}301/13604/17892 matches

    # Файлы данных засекречены: засекреченные данные в открытом виде не обнаружены ни на Active, ни на Standby узлах. Обнаружены только данные, созданные в незасекреченной таблице.

  8. Выполните просмотр файла с ключами $PGDATA/global/enc_keys.json:

    $ cat $PGDATA/global/enc_keys.json
    [
    {
    "controlBlock" : "{хеш}",
    "dataBaseId" : 13604,
    "encryptionKey" : "HYn0fSBsRPJREiWxvqJRpu03BljT+/bebkkvQXHWD9U=",
    "objectId" : 17889,
    "pgObjectType" : "R"
    },
    {
    "controlBlock" : "{хеш}",
    "dataBaseId" : 13604,
    "encryptionKey" : "dtKDJsZ+chGC+wQ+BzQwsyNNY993MCPq84JoBlLWK58=",
    "objectId" : 17886,
    "pgObjectType" : "R"
    },
    {
    "controlBlock" : "{хеш}",
    "dataBaseId" : 13604,
    "encryptionKey" : "o5c4NcB/gBxgMwZ8L1Q5yujMeNYn/DHZnrBftCu/6JM=",
    "objectId" : 17891,
    "pgObjectType" : "R"
    },
    {
    "controlBlock" : "{хеш}",
    "dataBaseId" : 0,
    "encryptionKey" : "odxycdKwJNbsC+YJMlx4225FbXlD//oeFeFZhsSNG40=",
    "objectId" : 17884,
    "pgObjectType" : "T"
    },
    {
    "controlBlock" : "{хеш}",
    "encryptionKey" : "XKrK2pskc9IcaM5Kpx0rGaKuITxr7+RsiLBYbqRVM4c=",
    "pgObjectType" : "W"
    }

    В файле отражены засекреченные объекты:

    • с типом объекта R (отношение): таблица table_tde_on (objectId=17886), toast-таблица pg_toast_17886 (objectId=17889), индекс к ней pg_toast_17886_index (objectId=17891):
    # SELECT oid,relname FROM pg_class WHERE oid in ('17889','17886','17891');
    oid  |       relname
    -------+----------------------
    17889 | pg_toast_17886
    17891 | pg_toast_17886_index
    17886 | table_tde_on
    (3 rows)
    • с типом объекта T (табличное пространство): созданное табличное пространство tde_on:
    # SELECT * FROM pg_tablespace WHERE oid='17884';
    oid  | spcname | spcowner |                  spcacl                   |    spcoptions
    -------+---------+----------+-------------------------------------------+-------------------
    17884 | tde_on  |       10 | {postgres=C/postgres,as_admin=C/postgres} | {is_encrypted=on}
    (1 row)
    • с типом объекта W (WAL) — objectId для WAL - null.

Логическая репликация при прозрачном защитном преобразовании данных (TDE)​

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

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

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

Внимание!
  • логическая репликация с TDE-сервера отключена по умолчанию;
  • стороны должны установить TLS-соединение версии 1.3;
  • при использовании настройки USE_TLS запрещена репликация через посредников, так как с их стороны отсутствует гарантия TDE;
  • запрещена репликация на сторонние сервисы, так как с их стороны отсутствует гарантия TDE.
Внимание!

Параметр logical_replication_policy управляет логической репликацией только при включенном TDE на публикующем сервере.

Внимание!

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

Внимание!

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

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

  1. Репликация через TLS.

  1. Репликация запрещена.

Настройка логической репликации​

Для реализации двух вариантов конфигурации сервера-подписчика и публикующего сервера (Publisher с поддержкой TDE, Subscriber с поддержкой TDE / Publisher с поддержкой TDE, Subscriber без поддержки TDE), предложена следующая схема:

Шаги по настройке логической репликации:

  1. Настройте TLS-соединение между публикующим сервером и сервером-подписчиком (администратор СУБД):

    1. В конфигурационном файле публикующего сервера pg_hba.conf добавьте подписчиков, указав тип соединения hostssl.

    2. Включите ssl на серверах:

      ALTER SYSTEM SET ssl TO on;

      SELECT pg_reload_conf();

      SHOW ssl;

    3. Если репликация уже настроена, удостоверьтесь, что используются ssl-соединения:

      SELECT pg_stat_ssl.pid, datname, usename, ssl, client_addr
      FROM pg_stat_ssl
      JOIN pg_stat_activity
      ON pg_stat_ssl.pid = pg_stat_activity.pid;

    4. При необходимости выключите процесс с небезопасным соединением, чтобы произошло переподключение:

      SELECT pg_stpg_terminate_backend(<pid>);

  2. Через веб-интерфейс хранилища секретов установите в KMS значение logical_replication_policy равным USE_TLS (администратор безопасности).

  3. Удостоверитесь, что параметр logical_replication_policy задан верно. Для этого необходимо перезагрузить базу данных (администратор СУБД):

    pg_ctl reload
    SHOW logical_replication_policy;

  4. Настройте логическую репликацию как в Postgresql (администратор СУБД):

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

      CREATE ROLE subscriber REPLICATION LOGIN;
      GRANT SELECT ON TABLE <replication_table> TO subscriber;
      GRANT USAGE ON SCHEMA <table_schema> TO subscriber;

    2. На публикующем сервере создайте публикацию реплицируемых таблиц:

      CREATE PUBLICATION <publication_name>
      FOR TABLE <replication_table>;

    3. На публикующем сервере удостоверитесь что wal_level имеет значение logical. При необходимости исправьте. В зависимости от конфигурации кластера способы могут быть разными. Например, в случае standalone экземпляра можно исправить значение в postgresql.conf и перезапустить базу данных.

      SHOW wal_level;

    4. На сервере-подписчике создайте соответствующие таблицы с такими же схемами.

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

      CREATE SUBSCRIPTION <subscription_name>
      CONNECTION 'user=subscriber host=<host> port=<port> dbname=<dbname>'
      PUBLICATION <publication_name>;

Отмена логической репликации​

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

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

Шаги по отмене логической репликации:

  1. Через веб-интерфейс хранилища секретов установите в KMS значение logical_replication_policy равным DISABLED (администратор безопасности).

  2. Перезагрузите конфигурацию сервера, например (администратор СУБД публикующего сервера):

    pg_ctl reload

  3. Удалите публикацию (администратор СУБД публикующего сервера):

    DROP PUBLICATION <publication_name>;

  4. Удалите подписку (администратор СУБД сервера-подписчика):

    1. Когда на публикующем сервере установлен параметр logical_replication_policy равным DISABLED, все соединения, созданные для логической репликации, будут отклоняться. Подписчик при попытке удалить подписку столкнется с ошибкой:

      DROP SUBSCRIPTION <subscription_name>;
      FATAL:  Logical replication from the server with enabled TDE is prohibited by the logical_replication_policy option: DISABLED.
      HINT:  Use ALTER SUBSCRIPTION ... DISABLE to disable the subscription, and then use ALTER SUBSCRIPTION ... SET (slot_name = NONE) to disassociate it from the slot.

    2. Воспользуйтесь подсказкой:

      ALTER SUBSCRIPTION <subscription_name> DISABLE;
      ALTER SUBSCRIPTION <subscription_name> SET ( slot_name = NONE );
      DROP SUBSCRIPTION <subscription_name>;