F.69. pg_tde — Прозрачное шифрование данных для Tantor SE#

F.69. pg_tde — Прозрачное шифрование данных для Tantor SE
F.69. pg_tde — Прозрачное шифрование данных для Tantor SE
Назад НаверхПриложение F. Дополнительные поставляемые модули и расширенияНачало Далее

F.69. pg_tde — Прозрачное шифрование данных для Tantor SE #

F.69.1. Обзор
F.69.2. Быстрый старт
F.69.3. О прозрачном шифровании данных
F.69.4. Особенности
F.69.5. Алгоритмы шифрования
F.69.6. Настройка pg_tde
F.69.7. Обзор управления ключами
F.69.8. Конфигурация основного ключа по умолчанию
F.69.9. Примеры использования pg_tde
F.69.10. Настройка шифрования WAL
F.69.11. Техническая справка
F.69.12. Архитектура
F.69.13. Переменные GUC
F.69.14. Функции
F.69.15. Потоковая репликация с tde_heap
F.69.16. Обзор инструментов командной строки pg_tde
F.69.17. Инструкции
F.69.18. FAQ
F.69.19. Деинсталляция pg_tde

Версия: 0.4

F.69.1. Обзор #

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

F.69.2. Быстрый старт #

F.69.2.1. Установка #

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

shared_preload_libraries = 'pg_tde'

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

На Astra Linux пакет libgost-astra автоматически настраивает OpenSSL.

После установки перезапустите Tantor SE и выполните: 

CREATE EXTENSION pg_tde;

F.69.2.2. Создание Зашифрованных Таблиц #

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

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

  1. На основе файлов

  2. HashiCorp Vault

  3. Протокол KMIP

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

SELECT pg_tde_add_database_key_provider_file('file-provider', '/tmp/test-file-provider');

Создайте основной ключ: 

SELECT pg_tde_set_key_using_database_key_provider('test-key', 'file-provider');

Создайте зашифрованную таблицу: 

CREATE TABLE enc_tbl(x int) USING tde_heap;

Проверьте, зашифрована ли таблица: 

SELECT pg_tde_is_encrypted('enc_tbl');

Чтобы указать алгоритм шифрования, используйте параметр хранения: 

CREATE TABLE enc_tbl(x int) USING tde_heap WITH (encryptor='magma');

Проверьте используемый алгоритм: 

SELECT pg_tde_get_algorithm('enc_tbl');

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

  1. AES (по умолчанию)

  2. ChaCha20

  3. Magma (ГОСТ)

  4. Kuznyechik (ГОСТ)

Последние два требуют дополнительных модулей.

Пример: 

-- Register a file-based key provider
SELECT pg_tde_add_database_key_provider_file('file-provider', '/tmp/test-file-provider');
-- Create a principal key
SELECT pg_tde_set_key_using_database_key_provider('test-key', 'file-provider');
-- Create encrypted table
CREATE TABLE enc_tbl(x int) USING tde_heap;

F.69.2.3. Шифрование WAL #

Шаги аналогичны шифрованию таблицы.

Сначала создайте глобального поставщика ключей (используется специально для WAL): 

SELECT pg_tde_add_global_key_provider_file('global-provider', '/tmp/test-wal-file-provider');

Затем создайте основный ключ для WAL: 

SELECT pg_tde_set_server_key_using_global_key_provider('wal-key', 'global-provider');

Включите шифрование WAL: 

ALTER SYSTEM SET pg_tde.wal_encrypt = on;

Перезапустите сервер базы данных.

Предостережение

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

Все шаги: 

SELECT pg_tde_add_global_key_provider_file('global-provider', '/tmp/test-wal-file-provider');
SELECT pg_tde_set_server_key_using_global_key_provider('wal-key', 'global-provider');
ALTER SYSTEM SET pg_tde.wal_encrypt = on;
-- Restart Tantor SE

F.69.2.4. Шифрование существующих таблиц #

Если у вас есть незашифрованная таблица, вы можете зашифровать её с помощью:

  1. Изменения метода доступа: 

    ALTER TABLE sample_tbl SET ACCESS METHOD tde_heap;

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

  2. Создания новой зашифрованной таблицы и миграции данных: 

    BEGIN;
CREATE TABLE temp_tbl(x int) USING tde_heap;
LOCK tbl;
INSERT INTO temp_tbl SELECT * FROM tbl;
DROP TABLE tbl;
ALTER TABLE temp_tbl RENAME TO tbl;
COMMIT;

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

F.69.2.5. Шифрование всех таблиц #

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

ALTER SYSTEM SET default_table_access_method = tde_heap;

Примечание

AES будет использоваться, если не переопределено с помощью WITH выражения.

F.69.2.6. Ротация ключей #

В настоящее время поддерживается только ротация основного ключа. Ротация внутреннего ключа еще не реализована.

Ротация просто включает назначение нового основного ключа: 

SELECT pg_tde_set_key_using_database_key_provider('new-key');

Существующие внутренние ключи будут повторно зашифрованы; данные таблицы останутся без изменений.

Пример: 

SELECT pg_tde_add_database_key_provider_file('file-provider', '/tmp/test-file-provider');
SELECT pg_tde_set_key_using_database_key_provider('test-key-1', 'file-provider');
CREATE TABLE enc_tbl(x int) USING tde_heap;
INSERT INTO enc_tbl(x) VALUES (1), (2), (3), (4), (5);

-- Rotate the principal key
SELECT pg_tde_set_key_using_database_key_provider('test-key-2');

F.69.2.7. Репликация #

Физическая репликация полностью поддерживается. Записи WAL, связанные с TDE, воспроизводятся на реплике.

Примечание

Для шифрования по ГОСТ убедитесь, что необходимые модули установлены на реплике.

F.69.2.8. Конфигурация OpenSSL #

При запуске расширение загружает файл конфигурации OpenSSL. Используйте pg_tde.openssl_config, чтобы указать пользовательский путь. Если путь не указан, используется системный путь по умолчанию (например, /etc/ssl/openssl.cnf на Astra Linux).

Если пакет libgost-astra установлен, он настраивается автоматически.

Примечание

В нашем дистрибутиве модули GOST (gost.so, gostprov.so) находятся в /opt/tantor/db/{VERSION}/lib.

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

Формат: список, разделенный запятыми (как в shared_preload_libraries). Поддерживаются: aes, chacha20, kuznyechik, magma.

Пример: 

pg_tde.preinit_algs = 'aes,chacha20,kuznyechik'

F.69.3. О прозрачном шифровании данных #

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

Этот процесс выполняется прозрачно в фоновом режиме, с минимальным влиянием на операции базы данных.

F.69.3.1. Преимущества pg_tde #

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

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

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

  • Операционная простота: Работает прозрачно, не требуя значительных изменений в приложении.

  • Глубокая защита: Добавляет ещё один уровень защиты к существующим механизмам, таким как TLS (шифрование при передаче), контроль доступа и разрешения на основе ролей.

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

F.69.3.2. Как работает pg_tde #

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

  • Внутренние ключи шифрования для шифрования пользовательских данных. Они хранятся внутри, рядом с данными, которые они шифруют.

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

Примечание

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

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

Сам внутренний ключ зашифрован с использованием основного ключа. Основной ключ хранится внешне в хранилище управления ключами.

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

F.69.3.3. Влияние pg_tde на операции с базой данных #

Эта страница содержит краткое описание того, как pg_tde взаимодействует с основными операциями Tantor SE.

ОбластьDkbzybtПримечания / Действия
Резервные копииДаДля зашифрованных резервных копий требуются инструменты, поддерживающие pg_tde. См. Резервное копирование с включённым шифрованием WAL.
ВосстановлениеДаВосстановленные данные остаются зашифрованными; pg_tde прозрачно обрабатывает расшифровку. См. Восстановление зашифрованных резервных копий.
Потоковая репликацияЧастичноРеплики должны загружать общую библиотеку pg_tde (shared_preload_libraries = 'pg_tde'). Без этого реплика завершится с ошибкой при операциях, связанных с tde_heap.
Логическая репликацияНетНе затрагивается.
Мониторинг и статистикаНетНе затрагивается, включая pg_stat_monitor.
ПроизводительностьНезначительноеНебольшие затраты процессорного времени из-за включения шифрования, наиболее заметные при случайных операциях записи.

F.69.3.4. Область зашифрованных данных #

pg_tde шифрует следующие компоненты:

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

  • Временные таблицы, созданные во время выполнения запроса, для таблиц данных, созданных с использованием расширения.

  • Данные журнала предзаписи (WAL) для всего кластера базы данных. Сюда входят данные WAL в зашифрованных и незашифрованных таблицах.

  • Индексы на зашифрованных таблицах.

F.69.3.5. Методы доступа к таблицам и pg_tde #

Метод доступа к таблице — это способ, которым Tantor SE хранит данные в таблице. Метод доступа к таблице по умолчанию — heap. Tantor SE организует данные в структуре кучи, что означает отсутствие определённого порядка строк в таблице. Каждая строка хранится независимо и идентифицируется своим уникальным идентификатором строки (TID).

F.69.3.5.1. Как работает метод доступа к куче #

Вставка: Когда добавляется новая строка, Tantor SE находит свободное место в табличном пространстве и сохраняет там эту строку.

Удаление: Когда строка удаляется, Tantor SE помечает занимаемое строкой пространство как свободное, но данные остаются до тех пор, пока не будут перезаписаны новой вставкой.

Обновления: Tantor SE обрабатывает обновления, удаляя старую строку и вставляя новую строку с обновлёнными значениями.

F.69.3.5.2. Пользовательский метод доступа #

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

Пользовательские методы доступа обычно доступны с расширениями Tantor SE. Когда вы устанавливаете расширение и включаете его в Tantor SE, создаётся пользовательский метод доступа.

Примером такого подхода является метод доступа tde_heap. Он автоматически создаётся только для баз данных, в которых вы настроили pg_tde и сконфигурировали поставщика ключей, что позволяет вам шифровать данные.

Чтобы использовать пользовательский метод доступа, укажите предложение USING в команде CREATE TABLE: 

CREATE TABLE table_name (
    column1 data_type,
    column2 data_type,
    ...
) USING tde_heap;
F.69.3.5.2.1. Как tde_heap работает с pg_tde #

Метод доступа tde_heap работает поверх стандартного метода доступа heap и служит маркером для указания, какие таблицы требуют шифрования. Он использует пользовательский менеджер хранения TDE SMGR, который становится активным только после установки расширения pg_tde.

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

Аналогично, когда клиент выполняет запрос к базе данных, ядро Tantor SE отправляет запрос менеджеру буферов, который проверяет, находятся ли запрошенные данные уже в буферном кеше. Если их там нет, менеджер буферов запрашивает данные у менеджера хранения. Менеджер хранения с TDE считывает зашифрованные данные с диска, расшифровывает их и загружает в буферный кеш. Менеджер буферов отправляет запрошенные данные ядру Tantor SE, а затем клиенту.

Таким образом, шифрование выполняется на уровне менеджера хранения.

F.69.3.5.3. Изменение метода доступа к таблице по умолчанию #

Вы можете изменить метод доступа к таблице по умолчанию, чтобы каждая таблица во всём кластере базы данных создавалась с использованием пользовательского метода доступа. Например, вы можете включить шифрование данных по умолчанию, определив tde_heap в качестве метода доступа к таблице по умолчанию.

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

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

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

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

  1. Добавьте метод доступа в параметр default_table_access_method:

    через команду ALTER SYSTEM

    Используйте ALTER SYSTEM, для этого требуются права суперпользователя или привилегии ALTER SYSTEM. 

     ALTER SYSTEM SET default_table_access_method = tde_heap;

    через файл конфигурации

    Отредактируйте конфигурационный файл postgresql.conf и добавьте значение для параметра default_table_access_method. 

     default_table_access_method = 'tde_heap'

    через команду SET

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

    В отличие от изменения файла postgresql.conf или использования команды ALTER SYSTEM, изменения, внесённые с помощью команды SET, не сохраняются после завершения сессии.

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

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

     SET default_table_access_method = tde_heap;

  2. Перезагрузите конфигурацию, чтобы применить изменения: 

    SELECT pg_reload_conf();

F.69.3.6. Ограничения pg_tde #

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

  • Внутренние системные таблицы PostgreSQL, которые включают статистику и метаданные, не шифруются.

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

F.69.3.6.1. В настоящее время неподдерживаемые инструменты WAL #

В настоящее время следующие инструменты не поддерживаются с шифрованием WAL pg_tde:

  • pg_createsubscriber

  • pg_receivewal

  • Barman

  • pg_verifybackup по умолчанию завершает работу с ошибками несоответствия контрольной суммы или размера ключа WAL. В качестве обходного пути используйте -s (пропустить проверку контрольной суммы) и -n (--no-parse-wal), чтобы проверить резервные копии.

  • Асинхронная функция архивирования в pgBackRest.

Следующие инструменты и расширения были протестированы и подтверждены на работоспособность с шифрованием WAL pg_tde:

F.69.3.6.2. Поддерживаемые инструменты WAL #

Следующие инструменты были протестированы на совместимость с шифрованием WAL pg_tde:

F.69.4. Особенности #

Для расширения доступны следующие функции:

  • Шифрование таблицы включая:

    • Таблицы данных

    • Данные индекса для зашифрованных таблиц

    • TOAST таблицы

    • Временные таблицы

    Примечание

    Метаданные этих таблиц не зашифрованы.

F.69.5. Алгоритмы шифрования #

pg_tde поддерживает различные алгоритмы шифрования таблиц:

  • AES

  • ChaCha-20

  • Magma

  • Kuznyechik

Расширение использует openssl, поэтому если алгоритм поддерживается им, то он поддерживается и расширением.

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

  • aes для AES

  • chacha20 для ChaCha-20

  • magma для Magma

  • kuznyechik для Kuznyechik

Пример: 

CREATE TABLE users(
    name text
) USING tde_heap WITH (encryptor='kuznyechik');

Если алгоритм не указан, используется значение из GUC pg_tde.default_encryptor. По умолчанию его значение — aes, поэтому по умолчанию используется AES.

Примечание

Некоторые алгоритмы могут быть недоступны, поэтому вы не сможете их использовать. При запуске сервера расширение попытается инициализировать все доступные алгоритмы, и если некоторые из них не поддерживаются openssl, то в журнал будет записано сообщение WARNING.

F.69.6. Настройка pg_tde #

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

Расширение pg_tde требует дополнительной разделяемой памяти. Необходимо настроить Tantor SE для предварительной загрузки этого расширения при запуске.

Примечание

(Необязательно) Установите алгоритмы ГОСТ

pg_tde поддерживает различные алгоритмы шифрования, включая ГОСТ: Magma и Kuznyechik.

Если требуются алгоритмы ГОСТ (magma или kuznyechik), установите необходимые модули OpenSSL. Вы можете собрать их из исходных кодов или установить через пакеты.

Существует список известных пакетов для различных дистрибутивов, которые содержат модуль GOST для OpenSSL:

  • libgost-astra - Astra Linux

  • openssl-gost-engine - AltLinux

  • libengine-gost-openssl или libengine-gost-openssl1.1 — Debian/Ubuntu

  • openssl-gost-engine - RedOS

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

Когда модули GOST установлены, возможно, потребуется обновить конфигурацию OpenSSL. Некоторые пакеты (например, libgost-astra) делают это автоматически. Для других, возможно, потребуется обновить конфигурацию вручную.

  1. Настройте shared_preload_libraries

    Вы можете настроить параметр shared_preload_libraries двумя способами:

    • Добавьте следующую строку в файл postgresql.conf: 

      shared_preload_libraries = 'pg_tde'

    • Используйте команду ALTER SYSTEM. Выполните следующую команду в psql с правами суперпользователя: 

      ALTER SYSTEM SET shared_preload_libraries = 'pg_tde';

  2. Перезапустите кластер Tantor SE

    Перезапустите кластер postgresql, чтобы применить конфигурацию. 

    sudo systemctl restart tantor-CONF_EDITION_SHORT_NAME__-server-CONF_PG_MAJOR_VERSION__

  3. Создайте расширение

    После перезапуска Tantor SE подключитесь к psql как суперпользователь или владелец базы данных и выполните: 

    CREATE EXTENSION pg_tde;

    Смотрите CREATE EXTENSION для получения дополнительных сведений.

    Примечание

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

  4. (Необязательно) Включите pg_tde по умолчанию

    Чтобы автоматически включать pg_tde для всех новых баз данных, измените базу данных template1: 

    psql -d template1 -c 'CREATE EXTENSION pg_tde;'

    Примечание

    Рекомендуется использовать внешний поставщик ключей (KMS) для управления ключами шифрования.

F.69.7. Обзор управления ключами #

В производственных средах хранение ключей шифрования локально на сервере Tantor SE может создавать риски для безопасности. Для повышения безопасности pg_tde поддерживает интеграцию с внешними системами управления ключами (KMS) через интерфейс глобального поставщика ключей (Global Key Provider).

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

  1. Настройте поставщика ключей

  2. Установить Основной ключ по умолчанию

Примечание

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

Предупреждение

Не выполняйте ротацию ключей шифрования, пока работает pg_tde_basebackup. Резервные или отдельные кластеры, созданные из таких резервных копий, могут не запуститься во время воспроизведения WAL. Планируйте ротацию вне окон резервного копирования и выполняйте новую полную резервную копию после этого.

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

Поставщик KMS Описание Документация
KMIP Стандартный протокол взаимодействия систем управления ключами (Key Management Interoperability Protocol). Настройка KMIP
Vault Интеграция с HashiCorp Vault (KV v2 API, KMIP движок). Настройка Vault
Fortanix Управление ключами Fortanix DSM. Настройка Fortanix
Thales Thales CipherTrust Manager и DSM. Настройка Thales
OpenBao Сообщественный форк Vault с поддержкой KV v2. Настройка OpenBao
Akeyless Облачная платформа управления секретами для безопасного хранения и доступа к учетным данным и ключам шифрования. Настроить Akeyless
Файл связки ключей (не рекомендуется) Локальный файл ключа только для разработки/тестирования. Настройка файл связки ключей

F.69.7.1. Конфигурация KMIP #

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

Примечание

Вам нужен корневой сертификат сервера KMIP и пара ключ/сертификат клиента с разрешениями на создание и чтение ключей на сервере.

Рекомендуется ознакомиться с рекомендациями по настройке HashiCorp Vault Enterprise KMIP Secrets Engine, если вы используете Vault.

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

F.69.7.1.1. Пример использования #
SELECT pg_tde_add_global_key_provider_kmip(
    'provider-name',
    'kmip-IP', 
    'port',
    '/path_to/server_certificate.pem', 
    '/path_to/client_cert.pem',
    '/path_to/client_key.pem'
);
F.69.7.1.2. Описание параметров #

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

  • kmip-IP — IP-адрес или доменное имя сервера KMIP

  • port — порт для связи с сервером KMIP. Обычно используется порт 5696

  • server-certificate — путь к файлу сертификата для сервера KMIP

  • client_cert — путь к клиентскому сертификату.

  • client_key — путь к ключу клиента.

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

SELECT pg_tde_add_global_key_provider_kmip(
    'kmip','127.0.0.1', 
    5696, 
    '/tmp/server_certificate.pem', 
    '/tmp/client_cert_jane_doe.pem',
    '/tmp/client_key_jane_doe.pem'
);

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

Справочник по функциям pg_tde

F.69.7.2. Конфигурация сервера Fortanix KMIP #

pg_tde совместим с Fortanix Data Security Manager (DSM) через протокол KMIP. Полное руководство по настройке смотрите в документации по Fortanix KMIP.

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

F.69.7.3. Конфигурация Vault #

Вы можете настроить pg_tde для использования HashiCorp Vault в качестве глобального поставщика ключей для безопасного управления ключами шифрования. Поддерживаются как open source, так и корпоративная версии.

F.69.7.3.1. Пример использования #
SELECT pg_tde_add_global_key_provider_vault_v2(
    'provider-name',
    'url',
    'mount',
    'secret_token_path',
    'ca_path'
);
F.69.7.3.2. Пример использования глобального поставщика ключей #
SELECT pg_tde_add_global_key_provider_vault_v4(
    'provider-name',
    'url',
    'mount',
    'secret_token_path',
    'ca_path'
);
F.69.7.3.3. Описание параметров #

  • provider-name — имя для идентификации этого поставщика ключей

  • secret_token_path — путь к файлу, который содержит токен доступа с правами чтения и записи к указанной точке монтирования

  • url — URL-адрес сервера Vault

  • mount - это точка монтирования, где ключница должна хранить ключи

  • ca_path (необязательно) — это путь к файлу CA, используемому для проверки SSL

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

SELECT pg_tde_add_global_key_provider_vault_v2(
    'my-vault',
    'https://vault.vault.svc.cluster.local:8200',
    'secret/data',
    '/path/to/token_file',
    '/path/to/ca_cert.pem'
);

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

F.69.7.3.4. Требуемые разрешения #

Экземпляру Tantor SE необходимы следующие возможности API Vault для управления и чтения ключей шифрования:

  • sys/mounts/<mount>/* - разрешение на чтение

  • <mount>/data/* - разрешения на создание и чтение

  • <mount>/metadata/* - разрешение на просмотр

Примечание

Для получения дополнительной информации о разрешениях Vault смотрите документацию Vault.

F.69.7.4. Конфигурация сервера Thales KMIP #

pg_tde совместим с Thales CipherTrust Manager через протокол KMIP. Полное руководство по настройке смотрите в документации Thales.

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

F.69.7.5. Конфигурация сервера Akeyless KMIP #

pg_tde совместим с Akeyless CipherTrust Manager через протокол KMIP. Полное руководство по настройке см. в документации Akeyless.

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

F.69.7.6. Использование OpenBao в качестве поставщика ключей #

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

Примечание

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

F.69.7.6.1. Пример использования #

Чтобы зарегистрировать сервер OpenBao в качестве глобального поставщика ключей: 

SELECT pg_tde_add_global_key_provider_vault_v2(
    'provider-name',
    'url',
    'mount',
    'secret_token_path',
    'ca_path',
    'namespace'
);
F.69.7.6.2. Описание параметров #

  • provider-name — имя для идентификации этого поставщика ключей

  • secret_token_path — путь к файлу, который содержит токен доступа с правами чтения и записи к указанной точке монтирования

  • url — это URL-адрес сервера OpenBao

  • mount - это точка монтирования, где ключница должна хранить ключи

  • ca_path (необязательно) — это путь к файлу CA, используемому для проверки SSL

  • [необязательно] namespace — это пространство имён внутри сервера OpenBao. Подробнее о поддержке пространств имён в OpenBao (ПРИМЕЧАНИЕ: Вы можете использовать пространство имён без ca_path. В этом случае укажите NULL в качестве значения ca_path)

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

SELECT pg_tde_add_global_key_provider_vault_v2(
    'my-openbao-provider',
    'https://openbao.example.com:8200',
    'secret/data',
    '/path/to/token_file',
    '/path/to/ca_cert.pem'
);

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

Справочник по функциям pg_tde

F.69.7.7. Конфигурация файла Keyring #

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

Примечание

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

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

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

  1. Создайте поставщика ключей, ограниченного базой данных (file-keyring в этом примере), в файле /tmp/pg_tde_test_local_keyring.per: 

    SELECT pg_tde_add_database_key_provider_file(
    'file-keyring',
    '/tmp/pg_tde_test_local_keyring.per'
);

  2. Создайте ключ (my_default_key в этом примере) внутри только что созданного поставщика file-keyring: 

    SELECT pg_tde_create_key_using_database_key_provider(
    'my_default_key',
    'file-keyring'
);

  3. Установите ключ (my_default_key) от поставщика ключей (file-keyring): 

    SELECT pg_tde_set_key_using_database_key_provider(
    'my_default_key',
    'file-keyring'
);

    Подсказка

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

     ```sql
 SELECT pg_tde_default_key_info();
 ```

  4. Теперь создайте таблицу, используя tde_heap: 

    CREATE TABLE customer_table (a INT) USING tde_heap;

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

    Подсказка

    Чтобы проверить, зашифрована ли созданная вами таблица с помощью tde_heap, выполните: 

     \d+ test1

    Если Access method: tde_heap, то ваша таблица зашифрована.

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

             postgres=# \d+ test1
                                             Table "public.test1"
         Column |  Type   | Collation | Nullable | Default | Storage | Compression | Stats target | Description
         --------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
         a      | integer |           |          |         | plain   |             |              |
         Access method: tde_heap

F.69.8. Конфигурация основного ключа по умолчанию #

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

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

F.69.8.1. Добавление глобального поставщика ключей #

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

F.69.8.2. Создайте основной ключ по умолчанию #

Примечание

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

Чтобы создать глобальный основной ключ, выполните: 

SELECT pg_tde_create_key_using_global_key_provider(
    'key-name',
    'global_vault_provider'
);

Пример: 

postgres=# SELECT pg_tde_create_key_using_global_key_provider(
    'keytest1',
    'file-keyring'
);
 pg_tde_create_key_using_global_key_provider
---------------------------------------------

 (1 row)

F.69.8.3. Установка основного ключа по умолчанию #

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

SELECT pg_tde_set_default_key_using_global_key_provider(
    'key-name',
    'global_vault_provider'
);

Пример: 

postgres=# SELECT pg_tde_set_default_key_using_global_key_provider(
    'keytest1',
    'file-keyring'
);
 pg_tde_set_default_key_using_global_key_provider 
--------------------------------------------------

 (1 row)

F.69.8.4. Описание параметра #

  • key-name — имя, под которым основной ключ хранится у поставщика.

  • global_vault_provider — имя глобального поставщика ключей, который вы настроили ранее.

Примечание

Если сообщение об ошибке отсутствует, значит действие выполнено успешно.

F.69.8.5. Как работает генерация ключей #

Ключевой материал (фактический криптографический ключ) автоматически генерируется pg_tde и надежно хранится настроенным поставщиком.

Примечание

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

F.69.9. Примеры использования pg_tde #

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

F.69.9.1. Зашифровать данные в новой таблице #

  1. Создайте таблицу в базе данных, для которой вы настроили pg_tde, используя метод доступа tde_heap следующим образом: 

    CREATE TABLE <table_name> (<field> <datatype>) USING tde_heap;

    Предупреждение

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

    CREATE TABLE albums (
    album_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    artist_id INTEGER,
    title TEXT NOT NULL,
    released DATE NOT NULL
) USING tde_heap;

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

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

    CREATE TABLE albums (
    album_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    artist_id INTEGER,
    title TEXT NOT NULL,
    released DATE NOT NULL
) USING tde_heap WITH (encryptor='chacha20');

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

  2. Чтобы проверить, зашифрованы ли данные, выполните следующую функцию: 

    SELECT pg_tde_is_encrypted('table_name');

    Функция возвращает true или false.

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

    SELECT pg_tde_get_algorithm('table_name');

  3. (Необязательно) Проведите ротацию основного ключа.

Чтобы повторно зашифровать данные с использованием нового ключа, смотрите Управление основными ключами.

F.69.9.2. Зашифровать существующую таблицу #

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

Выполните следующую команду: 

ALTER TABLE table_name SET ACCESS METHOD tde_heap;

Предостережение

Использование SET ACCESS METHOD сбрасывает подсказочные биты, что может повлиять на производительность запросов. Чтобы восстановить производительность, выполните: 

SELECT count(*) FROM table_name;

Это заставляет Tantor SE проверять каждую кортеж на видимость и сбрасывать подсказочные биты.

Подсказка

Хотите позже удалить шифрование? Узнайте, как расшифровать ваши данные.

F.69.10. Настройка шифрования WAL #

Шифрование WAL требует основной ключ. Вы можете выполнить это требование одним из следующих способов:

F.69.10.1. Вариант 1: Использовать основной ключ по умолчанию #

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

Если вы еще не настроили основной ключ по умолчанию, смотрите раздел Настройка основного ключа по умолчанию.

F.69.10.2. Вариант 2: Настройка выделенного серверного основного ключа для WAL #

Примечание

Для получения полного списка поддерживаемых инструментов шифрования WAL в pg_tde смотрите раздел Ограничения pg_tde.

  1. Создайте расширение pg_tde, если оно не существует: 

    CREATE EXTENSION IF NOT EXISTS pg_tde;

  2. Настройка глобального поставщика ключей

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

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

    Серверный ключ (также называемый основным ключом) — это ключ, используемый Tantor SE для шифрования данных WAL. Смотрите pg_tde_create_key_using_global_key_provider для более подробных инструкций.

  4. Установите серверный (основной) ключ

    Этот шаг устанавливает ранее созданный серверный (основной) ключ в качестве активного ключа, используемого Tantor SE для шифрования WAL. Смотрите pg_tde_set_server_key_using_global_key_provider для более подробных инструкций.

  5. Включите шифрование WAL с помощью команды ALTER SYSTEM. Для выполнения этой команды требуются привилегии суперпользователя: 

    ALTER SYSTEM SET pg_tde.wal_encrypt = on;

  6. Перезапустите сервер, чтобы применить изменения. 

    sudo systemctl restart tantor-CONF_EDITION_SHORT_NAME__-server-CONF_PG_MAJOR_VERSION__

  7. (Необязательно) Проверьте, что шифрование WAL включено: 

    SHOW pg_tde.wal_encrypt;

Теперь файлы WAL начинают шифроваться как для зашифрованных, так и для незашифрованных таблиц.

F.69.11. Техническая справка #

Этот раздел охватывает внутренние компоненты и инструменты, которые обеспечивают работу pg_tde.

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

F.69.12. Архитектура #

pg_tde — это расширение для шифрования данных в состоянии покоя для Tantor SE.

Данные в состоянии покоя означают всё, что записано на диск. Это включает в себя следующее:

  • Файлы данных таблиц

  • Индексы

  • Последовательности

  • Временные таблицы

  • Журнал Предварительной Записи (WAL)

F.69.12.1. Основные компоненты #

Основные компоненты pg_tde следующие:

  • Изменения в ядре сервера сосредоточены на повышении расширяемости сервера, что позволяет основной логике pg_tde оставаться отдельной, в виде расширения. Изменения в ядре также добавляют поддержку шифрования для некоторых командных инструментов, которые должны работать напрямую с зашифрованными таблицами или зашифрованными файлами WAL — они реализованы как отдельные версии стандартных бинарных файлов, поэтому если вы не используете шифрование, то никакого дополнительного накладного расхода на операции нет.

  • pg_tde расширение само по себе реализует код шифрования, используя точки расширения, добавленные в результате изменений в ядре, а также уже существующие точки расширения в сервере Tantor SE. Всеми функциями можно управлять с помощью GUC переменных и SQL-операторов, аналогично другим расширениям.

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

F.69.12.2. Архитектура шифрования #

F.69.12.2.1. Иерархия с двумя ключами #

pg_tde использует два вида ключей для шифрования:

  • Внутренние ключи для шифрования данных. Они хранятся в каталоге данных Tantor SE по пути $PGDATA/pg_tde.

  • Ключи более высокого уровня для шифрования внутренних ключей. Эти ключи называются основными ключами. Они хранятся вне системы, в системе управления ключами (KMS) с использованием API поставщика ключей.

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

Внутренние ключи используются для определённых файлов базы данных: каждый файл с разным идентификатором объекта (OID) имеет разный внутренний ключ.

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

Если у таблицы есть дополнительные связанные отношения, такие как последовательности или TOAST-таблица, эти отношения также будут иметь отдельные ключи.

F.69.12.2.2. Алгоритм шифрования #

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

  • AES-128-CBC

  • ChaCha20

  • Magma

  • Kuznyechik

Для шифрования WAL используется AES-128-CTR.

Для шифрования внутренних ключей используется AES-128-GCM.

F.69.12.2.3. Рабочий процесс шифрования #

pg_tde позволяет шифровать всё или только некоторые таблицы в некоторых базах данных.

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

Метод доступа tde_heap такой же, как и heap. Он использует те же функции внутренне без каких-либо изменений, но с другим именем и идентификатором. Таким образом, pg_tde знает, что таблицы tde_heap зашифрованы, а таблицы heap нет.

Первоначальное решение о том, что шифровать, принимается с использованием механизма триггеров событий postgres: если в инструкции CREATE TABLE или ALTER TABLE используется предложение tde_heap, вновь созданные файлы данных помечаются как зашифрованные. Затем файловые операции шифруют или расшифровывают данные.

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

F.69.12.2.4. Шифрование WAL #

Шифрование WAL контролируется глобально через глобальную переменную GUC pg_tde.wal_encrypt, которая требует перезапуска сервера.

Ключи WAL также содержат LSN первой записи WAL после создания ключа. Это позволяет pg_tde определять, какие диапазоны WAL зашифрованы, а какие нет, и с каким ключом.

Этот параметр управляет только операциями записи, поэтому при включённом шифровании WAL шифруются только записи в WAL. Это означает, что файлы WAL могут содержать как зашифрованные, так и незашифрованные данные, в зависимости от значения этой переменной в момент записи данных.

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

С этой информацией код считывателя WAL может определить, нужно ли расшифровывать конкретную запись WAL или нет, и какой ключ следует использовать для её расшифровки.

F.69.12.3. Управление ключами и поставщиками ключей #

F.69.12.3.1. Основная ротация ключей #

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

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

F.69.12.3.2. Внутренняя регенерация ключа #

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

Существуют обходные пути для этого, потому что операции, которые перемещают данные таблицы в новый файл, такие как VACUUM FULL или ALTER TABLE, который переписывает файл, создадут новый ключ для нового файла, по сути, меняя внутренний ключ. Однако это означает установку эксклюзивной блокировки на таблицу на время выполнения операции, что может быть нежелательно для огромных таблиц.

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

F.69.12.3.3. Внутреннее хранение ключей #

Внутренние ключи и метаданные pg_tde в общем хранятся в едином каталоге $PGDATA/pg_tde. Этот каталог хранит отдельные файлы для каждой базы данных, такие как:

  • Зашифрованные внутренние ключи и отображение внутренних ключей на таблицы

  • Информация о ключевых поставщиках

Также, в каталоге $PGDATA/pg_tde есть специальный глобальный раздел, помеченный OID 1664, который включает глобальных поставщиков ключей и глобальные внутренние ключи.

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

Глобальный ключ по умолчанию использует специальный OID 1663.

F.69.12.3.4. Поставщики ключей (основное хранилище ключей) #

Основные ключи хранятся внешне в Службах управления ключами (KMS). В pg_tde KMS определяется как внешний поставщик ключей.

Поддерживаются следующие поставщики ключей:

  • Движок секретов HashiCorp Vault KV2

  • OpenBao реализация Vault

  • Серверы, совместимые с KMIP

  • Локальное файловое хранилище. Это хранилище предназначено только для разработки и тестирования и не рекомендуется для использования в производственной среде.

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

С этими деталями pg_tde выполняет следующее на основе операций пользователя:

  • Загружает новый основной ключ после его создания

  • Извлекает основной ключ из службы, когда это необходимо для расшифровки

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

F.69.12.3.5. Управление поставщиком ключей #

Конфигурация или расположение поставщика ключей может измениться. Например, сервис может быть перемещён на новый адрес, или основной ключ должен быть перенесён к другому типу поставщика ключей. pg_tde поддерживает оба этих сценария, позволяя управлять основными ключами с помощью простых SQL-функций.

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

Для таких ситуаций pg_tde также предоставляет инструменты командной строки для восстановления базы данных.

F.69.12.3.6. Конфиденциальная информация о поставщике ключей #

Предостережение

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

F.69.12.4. Пользовательский интерфейс #

F.69.12.4.1. Настройка pg_tde #

Чтобы начать работу с pg_tde, выполните следующие шаги:

  • Добавьте pg_tde в shared_preload_libraries в postgresql.conf, так как это необходимо для расширений SMGR

  • Выполните CREATE EXTENSION pg_tde в базах данных, где необходимо использовать шифрование

  • При необходимости включите pg_tde.wal_encrypt в postgresql.conf

  • При необходимости отключите pg_tde.inherit_global_providers в postgresql.conf (по умолчанию эта опция включена)

F.69.12.4.2. Добавить поставщиков #

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

Если pg_tde.inherit_global_providers установлено в on, глобальные поставщики видны для всех баз данных и могут быть использованы. Если pg_tde.inherit_global_providers установлено в off, глобальные поставщики используются только для шифрования WAL.

Чтобы добавить глобального поставщика: 

pg_tde_add_global_key_provider_<TYPE>('provider_name', ... details ...)

Чтобы добавить поставщика, специфичного для базы данных: 

pg_tde_add_database_key_provider_<TYPE>('provider_name', ... details ...)
F.69.12.4.3. Сменить поставщиков #

Чтобы изменить значение глобального поставщика: 

pg_tde_change_global_key_provider_<TYPE>('provider_name', ... details ...)

Чтобы изменить значение поставщика, специфичного для базы данных: 

pg_tde_change_database_key_provider_<TYPE>('provider_name', ... details ...)

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

F.69.12.4.4. Изменение поставщиков из командной строки #

Чтобы изменить поставщика из командной строки, pg_tde предоставляет инструмент командной строки pg_tde_change_key_provider.

Этот инструмент работает аналогично вышеуказанным функциям, с следующим синтаксисом: 

pg_tde_change_key_provider <dbOid> <providerType> ... details ...

Примечание

Поскольку ожидается, что этот инструмент будет работать офлайн, он обходит все проверки разрешений. Это также причина, по которой ему требуется dbOid вместо имени, так как у него нет возможности обработать каталог и найти имена.

Этот инструмент не проверяет никакие параметры.

F.69.12.4.5. Удалить поставщиков #

Поставщики могут быть удалены с помощью следующих функций: 

pg_tde_delete_database_key_provider(provider_name)
pg_tde_delete_global_key_provider(provider_name)

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

Для глобальных поставщиков функция проверяет, используется ли поставщик где-либо, WAL или в какой-либо конкретной базе данных, и возвращает ошибку, если это так.

F.69.12.4.6. Список/запрос поставщиков #

pg_tde предоставляет 2 функции для отображения поставщиков:

  • pg_tde_list_all_database_key_providers()

  • pg_tde_list_all_global_key_providers()

Эти функции возвращают список имен поставщиков, типа и конфигурации.

F.69.12.4.7. Разрешения поставщика #

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

Для управления ключами и поставщиками, он предоставляет две пары функций: 

pg_tde_GRANT_database_key_management_TO_role
pg_tde_REVOKE_database_key_management_FROM_role
F.69.12.4.8. Создание и ротация ключей #

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

pg_tde_create_key_using_(global/database)_key_provider('key-name', 'provider-name')

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

pg_tde_set_key_using_(global/database)_key_provider('key-name', 'provider-name')
pg_tde_set_server_key_using_(global/database)_key_provider('key-name', 'provider-name')
pg_tde_set_default_key_using_(global/database)_key_provider('key-name', 'provider-name')
F.69.12.4.9. Основной ключ по умолчанию #

С помощью pg_tde.inherit_global_key_providers также возможно настроить глобальный основной ключ по умолчанию, который будет использоваться любой базой данных, в которой включено расширение pg_tde, но не настроен основной ключ для конкретной базы данных с использованием pg_tde_set_key_using_(global/database)_key_provider.

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

F.69.12.4.9.1. Управление ключом по умолчанию #

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

  • pg_tde_create_key_using_global_key_provider('key-name','provider-name')

  • pg_tde_set_default_key_using_global_key_provider('key-name','provider-name')

  • pg_tde_delete_default_key()

Примечание

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

F.69.12.4.9.2. Удалить ключ #

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

Примечание

Ключи WAL нельзя сбросить, так как ключи сервера управляются отдельно.

F.69.12.4.10. Текущие ключевые детали #

pg_tde_key_info() возвращает имя текущего основного ключа и поставщика, который он использует.

pg_tde_server_key_info() делает то же самое для серверного ключа.

pg_tde_default_key_info() делает то же самое для ключа по умолчанию.

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

F.69.12.4.11. Ключевые разрешения #

Пользователи с правами управления для конкретной базы данных (pg_tde_(grant/revoke)_(global/databse)_key_management_(to/from)_role) могут изменять ключи для базы данных и использовать функции текущего ключа. Это включает создание ключей с использованием глобальных поставщиков, если pg_tde.inherit_global_providers включён.

Также функция pg_tde_(grant/revoke)_database_key_management_to_role касается только конкретного разрешения для вышеуказанной функции: она позволяет пользователю изменять ключ для базы данных, но не изменять конфигурацию поставщика.

F.69.12.4.12. Создание зашифрованных таблиц #

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

CREATE TABLE t1(a INT) USING tde_heap;
ALTER TABLE t1 SET ACCESS METHOD tde_heap;
F.69.12.4.13. Изменение параметра pg_tde.inherit_global_keys #

Можно использовать pg_tde с inherit_global_keys = on, обращаться к глобальным ключам или связкам ключей в базах данных, а затем изменить этот параметр на off.

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

F.69.13. Переменные GUC #

Расширение pg_tde предоставляет переменные GUC для настройки поведения расширения:

F.69.13.1. pg_tde.wal_encrypt #

Тип - boolean

По умолчанию — выкл.

Переменная boolean, которая контролирует, зашифрованы ли записи WAL или нет.

Изменение этой переменной требует перезапуска сервера и может быть установлено только на уровне сервера.

Шифрование WAL контролируется глобально. Если включено, все записи WAL шифруются во всем кластере Tantor SE.

Эта переменная контролирует только новые записи в WAL, она не влияет на существующие записи WAL.

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

Включение шифрования WAL требует настройки глобального основного ключа. Дополнительную информацию смотрите в разделе Настройка шифрования WAL.

Предупреждение

Функция шифрования WAL в настоящее время находится в стадии бета-тестирования и не действует, если явно не включена. Она еще не готова к работе. Не включайте эту функцию в производственных средах.

F.69.13.2. pg_tde.enforce_encryption #

Тип - boolean

По умолчанию — выкл.

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

Если включено, операторы CREATE TABLE завершатся с ошибкой, если они не используют метод доступа tde_heap.

Аналогично, ALTER TABLE <x> SET ACCESS METHOD разрешено только, если метод доступа tde_heap.

Другие операции DDL всё ещё разрешены. Например, другие ALTER команды разрешены на незашифрованных таблицах, если метод доступа не изменён.

Вы можете установить эту переменную на следующих уровнях:

  • глобальный — для всего кластера Tantor SE

  • база данных — для конкретных баз данных

  • пользователь — для конкретных пользователей

  • сеанс — для текущего сеанса

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

F.69.13.3. pg_tde.inherit_global_providers #

Тип - boolean

По умолчанию - включено

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

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

В этом случае основной ключ по умолчанию, если он установлен, также отключен.

Вы можете установить эту переменную на следующих уровнях:

  • глобальный — для всего кластера Tantor SE

  • база данных — для конкретных баз данных

  • пользователь — для конкретных пользователей

  • сеанс — для текущего сеанса

Примечание

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

F.69.13.4. pg_tde.default_encryptor #

Тип - строка

По умолчанию - 'aes'

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

Используется, когда параметр хранения encryptor не используется в команде CREATE TABLE.

Еще один вариант использования — изменение алгоритма шифрования для уже зашифрованной таблицы. Установите этот параметр на предпочитаемый алгоритм и выполните ALTER TABLE … SET ACCESS METHOD tde_heap.

Вы можете установить этот параметр в значение любого поддерживаемого алгоритма:

  • aes - AES-CBC 256-бит.

  • chacha20 - ChaCha20.

  • magma - ГОСТ 28147-89 Magma.

  • kuznyechik - ГОСТ Р 34.12-2015 Kuznyechik.

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

F.69.14. Функции #

Расширение pg_tde предоставляет функции для управления различными аспектами его работы:

Примечание

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

F.69.14.1. Управление поставщиком ключей #

Поставщик ключей — это система или сервис, отвечающий за управление ключами шифрования. Для получения дополнительной информации о поставщиках ключей, поддерживаемых pg_tde, смотрите раздел Обзор управления ключами.

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

F.69.14.1.1. Добавить поставщика ключей #

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

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

  • pg_tde_add_database_key_provider_<type>('provider-name', <параметры, специфичные для поставщика>)

  • pg_tde_add_global_key_provider_<type>('provider-name', <параметры, специфичные для поставщика>)

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

F.69.14.1.2. Изменение существующего поставщика #

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

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

  • pg_tde_change_database_key_provider_<type>('provider-name', <параметры, специфичные для поставщика>)

  • pg_tde_change_global_key_provider_<type>('provider-name', <параметры, специфичные для поставщика>)

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

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

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

Примечание

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

F.69.14.1.2.1. Добавить или изменить поставщика Vault #

Поставщик Vault подключается к серверу HashiCorp Vault или OpenBao и хранит ключи в хранилище ключ-значение версии 2.

Используйте следующие функции, чтобы добавить поставщика Vault: 

SELECT pg_tde_add_database_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path'
);

SELECT pg_tde_add_global_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path'
);

SELECT pg_tde_add_database_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path',
  'namespace'
);

SELECT pg_tde_add_global_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path',
  'namespace'
);

Эти функции изменяют поставщика Vault: 

SELECT pg_tde_change_database_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path'
);

SELECT pg_tde_change_global_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path'
);
SELECT pg_tde_change_database_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path',
  'namespace'
);

SELECT pg_tde_change_global_key_provider_vault_v2(
  'provider-name',
  'url',
  'mount',
  'secret_token_path',
  'ca_path',
  'namespace'
);

где:

  • provider-name — имя поставщика ключей

  • url — URL-адрес сервера Vault

  • mount - это точка монтирования на сервере Vault, где поставщик ключей должен хранить ключи

  • secret_token_path — путь к файлу, который содержит токен доступа с правами на чтение и запись к указанной выше точке монтирования

  • [необязательно] ca_path — путь к файлу CA, используемому для проверки SSL

  • [namespace] namespace — это путь пространства имён при использовании Vault с пространствами имён

F.69.14.1.2.2. Добавить или изменить поставщиков KMIP #

Поставщик KMIP использует удаленный сервер KMIP.

Используйте эти функции для добавления поставщика KMIP: 

SELECT pg_tde_add_database_key_provider_kmip(
  'provider-name',
  'kmip-addr',
  port,
  '/path_to/client_cert.pem',
  '/path_to/client_key.pem',
  '/path_to/server_certificate.pem'
);

SELECT pg_tde_add_global_key_provider_kmip(
  'provider-name',
  'kmip-addr',
  port,
  '/path_to/client_certificate.pem',
  '/path_to/client_key.pem',
  '/path_to/server_certificate.pem'
);

Эти функции изменяют поставщика KMIP: 

SELECT pg_tde_change_database_key_provider_kmip(
  'provider-name',
  'kmip-addr',
  port,
  '/path_to/client_cert.pem',
  '/path_to/client_key.pem',
  '/path_to/server_certificate.pem'
);

SELECT pg_tde_change_global_key_provider_kmip(
  'provider-name',
  'kmip-addr',
  port,
  '/path_to/client_certificate.pem',
  '/path_to/client_key.pem',
  '/path_to/server_certificate.pem'
);

где:

  • provider-name — имя поставщика

  • kmip-addr — IP-адрес или доменное имя сервера KMIP

  • port — порт для связи с сервером KMIP. Большинство серверов KMIP используют порт 5696.

  • server-certificate — путь к файлу сертификата для сервера KMIP.

  • client-certificate — путь к клиентскому сертификату.

  • client-key — путь к ключу клиента.

Примечание

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

F.69.14.1.3. Добавление или изменение локальных поставщиков файлов ключей #

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

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

Предостережение

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

Добавьте локального поставщика файлов ключей: 

SELECT pg_tde_add_database_key_provider_file(
  'provider-name',
  '/path/to/the/key/provider/data.file'
);

SELECT pg_tde_add_global_key_provider_file(
  'provider-name',
  '/path/to/the/key/provider/data.file'
);

Изменить локального поставщика ключевых файлов: 

SELECT pg_tde_change_database_key_provider_file(
  'provider-name',
  '/path/to/the/key/provider/data.file'
);

SELECT pg_tde_change_global_key_provider_file(
  'provider-name',
  '/path/to/the/key/provider/data.file'
);

где:

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

  • /path/to/the/key/provider/data.file — путь к файлу поставщика ключей.

F.69.14.1.4. Удаление поставщика #

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

  • pg_tde_delete_database_key_provider('provider-name')

  • pg_tde_delete_global_key_provider('provider-name')

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

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

F.69.14.1.5. Перечисление поставщиков ключей #

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

  • pg_tde_list_all_database_key_providers()

  • pg_tde_list_all_global_key_providers()

F.69.14.2. Основное управление ключами #

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

Основные ключи хранятся у поставщиков ключей под именем, указанным в этой функции — например, при использовании поставщика Vault, после создания ключа с именем «foo», ключ с именем «foo» будет виден на сервере Vault в указанной точке подключения.

F.69.14.2.1. pg_tde_create_key_using_database_key_provider #

Создаёт основной ключ с использованием локального поставщика ключей базы данных с указанным именем. Используйте этот ключ позже с pg_tde_set_key_using_database_key_provider(). 

SELECT pg_tde_create_key_using_database_key_provider(
  'key-name',
  'provider-name'
);
F.69.14.2.2. pg_tde_create_key_using_global_key_provider #

Создаёт основной ключ у глобального поставщика ключей с указанным именем. Используйте этот ключ позже с серией функций pg_tde_set_*. 

SELECT pg_tde_create_key_using_global_key_provider(
  'key-name',
  'provider-name'
);
F.69.14.2.3. pg_tde_set_key_using_database_key_provider #

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

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

SELECT pg_tde_set_key_using_database_key_provider(
  'key-name',
  'provider-name'
);
F.69.14.2.4. pg_tde_set_key_using_global_key_provider #

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

SELECT pg_tde_set_key_using_global_key_provider(
  'key-name',
  'provider-name'
);
F.69.14.2.5. pg_tde_set_server_key_using_global_key_provider #

Устанавливает или изменяет основной ключ сервера с использованием указанного глобального поставщика ключей. Используйте эту функцию для установки основного ключа для шифрования WAL. 

SELECT pg_tde_set_server_key_using_global_key_provider(
  'key-name',
  'provider-name'
);
F.69.14.2.6. pg_tde_set_default_key_using_global_key_provider #

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

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

SELECT pg_tde_set_default_key_using_global_key_provider(
  'key-name',
  'provider-name'
);
F.69.14.2.7. pg_tde_delete_key #

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

SELECT pg_tde_delete_key();
F.69.14.2.8. pg_tde_delete_default_key #

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

SELECT pg_tde_delete_default_key();

F.69.14.3. Проверка статуса шифрования #

F.69.14.3.1. pg_tde_is_encrypted #

Сообщает, зашифровано ли отношение с использованием расширения pg_tde или нет. Возвращает NULL, если отношение не имеет хранилища, как представления, внешние таблицы и секционированные таблицы и индексы.

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

SELECT pg_tde_is_encrypted(
  'table_name'
);

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

SELECT pg_tde_is_encrypted(
  'schema.table_name'
);

Это также может быть использовано для проверки, что индексы и последовательности зашифрованы.

F.69.14.3.2. pg_tde_get_algorithm #

Указывает, какой алгоритм шифрования используется для отношения. Возвращает NULL, если отношение не зашифровано. 

SELECT pg_tde_get_algorithm(
    'table_name'
);
F.69.14.3.3. pg_tde_key_info #

Отображает информацию об основном ключе для текущей базы данных, если он существует. 

SELECT pg_tde_key_info();
F.69.14.3.4. pg_tde_server_key_info #

Отображает информацию об основном ключе для области сервера, если он существует. 

SELECT pg_tde_server_key_info();
F.69.14.3.5. pg_tde_default_key_info #

Отображает информацию о ключе по умолчанию, если он существует. 

SELECT pg_tde_default_key_info();
F.69.14.3.6. pg_tde_verify_key #

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

  • Поставщик ключей настроен

  • Поставщик ключей доступен с использованием указанной конфигурации

  • Существует основной ключ для базы данных

  • Основной ключ можно получить от удаленного поставщика ключей

  • Основной ключ, возвращаемый от поставщика ключей, такой же, как кэшированный в памяти сервера

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

SELECT pg_tde_verify_key();
F.69.14.3.7. pg_tde_verify_server_key #

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

  • Поставщик ключей настроен

  • Поставщик ключей доступен с использованием указанной конфигурации

  • Существует основной ключ для глобальной области видимости

  • Основной ключ можно получить от удаленного поставщика ключей

  • Основной ключ, возвращаемый от поставщика ключей, такой же, как кэшированный в памяти сервера

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

SELECT pg_tde_verify_server_key();
F.69.14.3.8. pg_tde_verify_default_key #

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

  • Поставщик ключей настроен

  • Поставщик ключей доступен с использованием указанной конфигурации

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

  • Основной ключ можно получить от удаленного поставщика ключей

  • Основной ключ, возвращаемый от поставщика ключей, такой же, как кэшированный в памяти сервера

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

SELECT pg_tde_verify_default_key();

F.69.15. Потоковая репликация с tde_heap #

Этот раздел описывает, как настроить потоковую репликацию Tantor SE, когда на основном сервере включено расширение pg_tde, а именно метод доступа tde_heap.

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

Примечание

Вам не нужно выполнять CREATE EXTENSION на резервном сервере. Это будет реплицировано автоматически.

F.69.15.1. Настройка основного сервера #

F.69.15.1.1. Создать основной ключ #

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

F.69.15.1.2. Создайте роль репликации #

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

CREATE ROLE example_replicator WITH REPLICATION LOGIN PASSWORD 'example_password';
F.69.15.1.3. Настройка pg_hba.conf #

Чтобы разрешить реплике подключаться к основному серверу, добавьте следующую строку в pg_hba.conf: 

host  replication  example_replicator  standby_ip/32  scram-sha-256

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

SELECT pg_reload_conf();

F.69.15.2. Настройка резервного сервера #

F.69.15.2.1. Выполнить резервное копирование базы данных #

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

export PGPASSWORD='example_password'
pg_tde_basebackup \
  -h primary_ip \
  -D /var/lib/pgsql/data \
  -U example_replicator \
  --wal-method=stream \
  --slot=tde_slot \
  -C \
  -c fast \
  -v -P
F.69.15.2.2. Настройка postgresql.conf #

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

shared_preload_libraries = 'pg_tde'

F.69.15.3. Запустите и проверьте репликацию #

Предполагая, что основной и резервный серверы работают на отдельных хостах, запустите службу Tantor SE: 

sudo systemctl start tantor-CONF_EDITION_SHORT_NAME__-server-CONF_PG_MAJOR_VERSION__

Предупреждение

Требуется согласованность управления ключами для репликации

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

Например:

  • Если вы настраиваете Vault с путем к секрету: /path/to/secret.file, то этот файл должен существовать по тому же пути как на основном, так и на резервном сервере.

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

  • На основном сервере: 

SELECT client_addr, state FROM pg_stat_replication;

  • На резервном сервере: 

SELECT
    pg_is_in_recovery()          AS in_recovery,
    pg_last_wal_receive_lsn()    AS receive_lsn,
    pg_last_wal_replay_lsn()     AS replay_lsn;

Подсказка

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

SELECT pg_tde_is_encrypted('your_encrypted_table');

F.69.16. Обзор инструментов командной строки pg_tde #

Расширение pg_tde предоставляет набор утилит командной строки, специально предназначенных для работы с зашифрованными данными и кластерами. Эти утилиты существуют параллельно со стандартными утилитами Tantor SE, но вы обязаны использовать их при работе с данными, зашифрованными с помощью pg_tde.

Примечание

Стандартные инструменты Tantor SE не могут работать с WAL или таблицами, зашифрованными с помощью pg_tde.

F.69.16.1. Новые инструменты, специфичные для `pg_tde` #

Эти инструменты введены исключительно pg_tde для поддержки рабочих процессов ротации ключей и шифрования WAL:

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

  • pg_tde_archive_decrypt: расшифровывает WAL перед архивированием

  • pg_tde_restore_encrypt: специальная команда восстановления для обеспечения шифрования восстановленного WAL

F.69.16.2. Инструменты для работы с данными, зашифрованными с помощью `pg_tde` #

Эти инструменты являются модифицированными версиями стандартных утилит Tantor SE, которые включают поддержку pg_tde. Вы должны использовать варианты pg_tde_* при работе с зашифрованными WAL или таблицами:

  • pg_tde_checksums: проверяет контрольные суммы данных (только для нешифрованных файлов)

  • pg_tde_waldump: просматривает и расшифровывает файлы WAL

  • pg_tde_basebackup: создает базовые резервные копии, включающих зашифрованные данные

  • pg_resetwal: сбрасывает WAL для кластеров, использующих pg_tde

  • pg_rewind: перематывает кластеры, использующие зашифрованный WAL

F.69.16.3. pg_tde_change_key_provider #

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

Этот инструмент редактирует файлы конфигурации напрямую, игнорируя разрешения или запущенные процессы postgres.

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

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

Предупреждение

Используйте этот инструмент только когда сервер выключен. Для изменения конфигурации поставщика ключей при работающем сервере используйте SQL-функции pg_tde_change_(global/database)_key_provider_<type>.

F.69.16.3.1. Пример использования #

Чтобы изменить конфигурацию поставщика ключей, укажите все параметры в зависимости от типа поставщика таким же образом, как и при использовании SQL-функций pg_tde_change_(global/database)_key_provider_<type>.

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

pg_tde_change_key_provider [-D <datadir>] <dbOid> <provider_name> <new_provider_type> <provider_parameters...>
F.69.16.3.2. Описание параметра #

  • [необязательно] <datadir> — каталог данных. pg_tde использует переменную окружения $PGDATA, если это не указано

  • <provider_name> — имя, которое вы присвоили поставщику ключей

  • <new_provider_type> может быть file, vault или kmip

  • <dbOid>

В зависимости от типа поставщика, дополнительные параметры: 

pg_tde_change_key_provider [-D <datadir>] <dbOid> <provider_name> file <filename>
pg_tde_change_key_provider [-D <datadir>] <dbOid> <provider_name> vault-v2 <url> <mount_path> <token_path> [<ca_path>]
pg_tde_change_key_provider [-D <datadir>] <dbOid> <provider_name> kmip <host> <port> <cert_path> <key_path> [<ca_path>]

F.69.16.4. pg_tde_archive_decrypt #

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

Подсказка

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

Этот инструмент часто используется вместе с pg_tde_restore_encrypt для поддержки архивации WAL.

F.69.16.4.1. Как это работает #

  1. Расшифровывает сегмент WAL во временный файл на RAM-диске (/dev/shm)

  2. Заменяет %p и %f в команде архивации на путь и имя расшифрованного файла

  3. Выполняет команду архивации

Примечание

Для обеспечения безопасности зашифруйте файлы, хранящиеся в вашем архиве WAL, с помощью таких инструментов, как PgBackRest.

F.69.16.4.2. Использование #
pg_tde_archive_decrypt [OPTION]
pg_tde_archive_decrypt DEST-NAME SOURCE-PATH ARCHIVE-COMMAND
F.69.16.4.3. Описание параметров #

  • DEST-NAME: имя файла WAL, который нужно отправить в архив

  • SOURCE-PATH: путь к исходному зашифрованному WAL-файлу

  • ARCHIVE-COMMAND: архивная команда для обёртывания. %p и %f заменяются соответственно на путь к расшифрованному файлу WAL и имя файла WAL.

F.69.16.4.4. Опции #

  • -V, --version: показать информацию о версии, затем выйти

  • -?, --help: показать справочную информацию, затем выйти

Примечание

Любой параметр %f или %p в ARCHIVE-COMMAND должен быть экранирован как %%f или %%p соответственно, если используется как archive_command в postgresql.conf.

F.69.16.4.5. Примеры #
F.69.16.4.5.1. Использование cp #
archive_command='pg_tde_archive_decrypt %f %p "cp %%p /mnt/server/archivedir/%%f"'
F.69.16.4.5.2. Использование PgBackRest #
archive_command='pg_tde_archive_decrypt %f %p "pgbackrest --stanza=your_stanza archive-push %%p"'

Предупреждение

При использовании PgBackRest с шифрованием WAL отключите контрольные суммы данных Tantor SE. В противном случае PgBackRest может засыпать журнал сообщениями об ошибках, а в некоторых сборках пакетов такая запись в журнал может привести к сбоям.

Предупреждение

Асинхронное архивировани PgBackRest не работает с зашифрованным WAL.

F.69.16.5. pg_tde_restore_encrypt #

Инструмент pg_tde_restore_encrypt оборачивает обычную команду восстановления из архива WAL и записывает их на диск в формате, совместимом с pg_tde.

Примечание

Эта команда часто используется вместе с pg_tde_archive_decrypt.

F.69.16.5.1. Как это работает #

  1. Заменяет %f и %p в команде восстановления на имя файла WAL и путь к временному файлу (в /dev/shm)

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

  3. Шифрует временный файл и записывает его в целевой путь в каталоге данных Tantor SE

F.69.16.5.2. Использование #
pg_tde_restore_encrypt [OPTION]
pg_tde_restore_encrypt SOURCE-NAME DEST-PATH RESTORE-COMMAND
F.69.16.5.3. Описание параметров #

  • SOURCE-NAME: имя файла WAL, который нужно получить из архива

  • DEST-PATH: путь, по которому должен быть записан зашифрованный WAL-файл

  • RESTORE-COMMAND: команда восстановления для обёртывания; %p и %f заменяются соответственно на имя файла WAL и путь для записи нешифрованного WAL

F.69.16.5.4. Опции #

  • -V, --version: показать информацию о версии, затем выйти

  • -?, --help: показать справочную информацию, затем выйти

Примечание

Любой параметр %f или %p в RESTORE-COMMAND должен быть экранирован как %%f или %%p соответственно, если используется как restore_command в postgresql.conf.

F.69.16.5.5. Примеры #
F.69.16.5.5.1. Использование cp #
restore_command='pg_tde_restore_encrypt %f %p "cp /mnt/server/archivedir/%%f %%p"'
F.69.16.5.5.2. Использование PgBackRest #
restore_command='pg_tde_restore_encrypt %f %p "pgbackrest --stanza=your_stanza archive-get %%f \"%%p\""'

Предупреждение

При использовании PgBackRest с шифрованием WAL отключите контрольные суммы данных Tantor SE. В противном случае PgBackRest может засыпать журнал сообщениями об ошибках, а в некоторых сборках пакетов такая запись в журнал может привести к сбоям.

Предупреждение

Асинхронное архивировани PgBackRest не работает с зашифрованным WAL.

F.69.16.6. pg_tde_checksums #

pg_checksums — это утилита командной строки Tantor SE, используемая для включения, отключения или проверки контрольных сумм данных в каталоге данных Tantor SE. Однако она не может вычислять контрольные суммы для зашифрованных файлов.

Зашифрованные файлы пропускаются, и это отображается в выводе.

Примечание

Убедитесь, что вы включили контрольные суммы страниц перед установкой pg_tde

F.69.16.7. pg_tde_waldump #

pg_tde_waldump отображает читаемое человеком представление журнала предзаписи (WAL) для кластера базы данных Tantor SE.

Чтобы читать зашифрованные записи WAL, pg_tde_waldump поддерживает следующие дополнительные аргументы:

  • -k, --keyring-path=PATH — это путь к каталогу, содержащему файлы конфигурации связки ключей WAL. Обычно это каталог pg_tde/ внутри каталога данных Tantor SE. Включены следующие файлы:

    • wal_keys

    • 1664_providers

Примечание

pg_tde_waldump не расшифровывает WAL, если не установлен keyring_path.

F.69.16.8. pg_tde_basebackup #

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

Для чтения зашифрованных WAL-записей pg_tde_basebackup поддерживает следующие дополнительные аргументы:

  • encrypt-wal флаг указывает, что инструмент должен шифровать передаваемый WAL. Для этого у вас уже должен быть настроен ключ шифрования WAL.

F.69.16.9. pg_tde_resetwal #

pg_tde_resetwal — это инструмент для сброса журнала предзаписи (write-ahead log) и другой управляющей информации кластера базы данных Tantor SE.

Инструменты будут искать каталог $PGDATA/pg_tde, чтобы получить ключи шифрования WAL.

F.69.16.10. pg_tde_rewind #

pg_tde_rewind — это инструмент для синхронизации каталога данных базы данных с другим каталогом данных, который был создан на его основе.

Инструменты будут искать каталог $PGDATA/pg_tde, чтобы получить ключи шифрования WAL.

F.69.17. Инструкции #

F.69.17.1. Обеспечение шифрования #

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

F.69.17.1.1. Что делает принудительное применение? #

Когда включено, принудительное шифрование:

  • Предотвращает создание незашифрованных таблиц или индексов

  • Обеспечивает единообразное использование шифрования между арендаторами, базами данных или пользователями

  • Может быть задано глобально, для отдельной базы данных или для роли

F.69.17.1.2. Принудительное использование шифрования #

Используйте следующие методы для обеспечения безопасного использования pg_tde.

F.69.17.1.2.1. Принудительное использование шифрования на всём сервере #

Чтобы обеспечить шифрование на уровне всего кластера, установите переменную pg_tde.enforce_encryption в файле postgresql.conf: 

pg_tde.enforce_encryption = on

Примечание

Только суперпользователи могут устанавливать или изменять эту переменную.

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

F.69.17.1.2.2. Принудительное шифрование для конкретной базы данных #

Чтобы применить принудительное шифрование только внутри определённой базы данных, выполните: 

ALTER DATABASE example_db SET pg_tde.enforce_encryption = on;

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

F.69.17.1.2.3. Принудительное шифрование для конкретного пользователя #

Вы также можете принудительно включить шифрование для конкретного пользователя, выполните: 

ALTER USER example_user SET pg_tde.enforce_encryption = on;

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

F.69.17.1.2.4. Переопределение принудительного применения для доверенных сессий #

Суперпользователи могут переопределить переменную на уровне сессии: 

SET pg_tde.enforce_encryption = off;

Это позволяет временно создавать незашифрованные таблицы в особых случаях, например:

  • Загрузка доверенных, общедоступных эталонных наборов данных

  • Тестирование производительности и тестовые среды

  • Промежуточная миграция перед повторным шифрованием

Примечание

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

F.69.17.2. Удаление шифрования с зашифрованной таблицы #

F.69.17.2.1. Метод 1. Изменение метода доступа #

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

ALTER TABLE mytable SET ACCESS METHOD heap;

Обратите внимание, что команда SET ACCESS METHOD сбрасывает подсказочные биты, и это может повлиять на производительность. Выполнение простой команды SELECT count(*) или VACUUM на всей таблице проверит каждый кортеж на видимость и установит их подсказочные биты. Поэтому после выполнения команды ALTER TABLE выполните простой count(*) на ваших таблицах: 

SELECT count(*) FROM mytable;

Проверьте, что таблица не зашифрована: 

SELECT pg_tde_is_encrypted('mytable');

Вывод возвращает f, что означает, что таблица больше не зашифрована.

F.69.17.2.2. Метод 2. Создание новой незашифрованной таблицы на основе зашифрованной #

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

CREATE TABLE Customers AS SELECT * FROM EncryptedCustomers;

Новая таблица Customers наследует структуру и данные от EncryptedCustomers.

(Необязательно) Если вам больше не нужна EncryptedCustomers таблица, вы можете удалить её. 

DROP TABLE EncryptedCustomers;

F.69.17.3. Резервное копирование с включённым шифрованием WAL #

Примечание

Если ваш кластер базы данных использует шифрование, то вы должны использовать инструмент pg_tde_basebackup вместо pg_basebackup.

Чтобы создать резервную копию с включённым шифрованием WAL:

  1. Скопируйте каталог pg_tde из каталога данных исходного сервера, например /var/lib/postgresql/data/pg_tde/, включая файлы wal_keys и 1664_providers, в целевой каталог резервного копирования, куда pg_tde_basebackup будет записывать резервную копию.

Также скопируйте все внешние файлы, на которые ссылается ваша конфигурация поставщика (такие как файлы сертификатов или ключей), в те же относительные пути в каталоге назначения резервной копии, чтобы они были обнаружены и проверены с помощью pg_tde_basebackup -E.

  1. Выполнить: 

    pg_tde_basebackup -D /path/to/backup -E

    Где:

    • -D /path/to/backup указывает место для резервного копирования, куда необходимо скопировать pg_tde.

    • -E (или --encrypt-wal) включает шифрование WAL и проверяет, что скопированные файлы pg_tde и поставщика присутствуют, а серверный ключ доступен (обязательно).

Примечание

  • Флаг -E работает только с опцией -X stream (по умолчанию). Он несовместим с -X none или -X fetch.

    Флаг -E поддерживается только с обычным форматом вывода (-F p). Он не может использоваться с форматом вывода tar (-F t).

F.69.17.3.1. Ротация ключей во время резервного копирования #

Предупреждение

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

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

Например, вы можете увидеть такие ошибки, как: 

FATAL: failed to retrieve principal key "database_keyXXXX" from key provider "providerYYYY"
CONTEXT: WAL redo at ... ROTATE_PRINCIPAL_KEY ...

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

F.69.17.3.2. Восстановление резервной копии, созданной с шифрованием WAL #

Когда вы хотите восстановить резервную копию, созданную с помощью pg_tde_basebackup -E:

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

  2. Запустите Tantor SE с восстановленным каталогом данных.

F.69.17.3.3. Совместимость методов резервного копирования с шифрованием WAL #

Формат tar (-F t):

  • Работает с -X fetch.

  • Не поддерживает -X stream, когда включено шифрование WAL. Использование pg_tde_basebackup -F t -X stream приведет к созданию некорректной реплики.

Потоковый режим (-X stream):

  • Необходимо указать -E (--encrypt-wal).

  • Без -E резервные копии могут содержать расшифрованный WAL, пока wal_encryption=on остается в postgresql.conf и pg_tde/wal_keys скопированы. Это приводит к ошибкам запуска и компрометации данных в резервной копии.

Режим выборки (-X fetch):

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

Нет (-X none):

  • Исключает WAL из резервной копии и не зависит от шифрования WAL.

Примечание

Если на исходном сервере есть pg_tde/wal_keys, запуск pg_tde_basebackup с параметрами -X none или -X fetch вызывает предупреждения, например: 

pg_tde_basebackup: warning: the source has WAL keys, but no WAL encryption configured for the target backups
pg_tde_basebackup: detail: This may lead to exposed data and broken backup
pg_tde_basebackup: hint: Run pg_tde_basebackup with -E to encrypt streamed WAL

Вы можете безопасно игнорировать предупреждения с -X none или -X fetch, поскольку потоковая передача WAL не происходит.

F.69.17.4. Восстановление зашифрованных резервных копий #

Чтобы восстановить зашифрованную резервную копию, созданную с использованием предыдущего ключа, убедитесь, что ключ всё ещё доступен в вашей системе управления ключами (KMS). Резервная копия остается зашифрованной на диске, pg_tde использует правильный ключ для прозрачного доступа к данным.

F.69.17.4.1. Как pg_tde использует старые ключи для загрузки резервных копий #

  • KMS: хранит основной ключ или ключи, которые были активны на момент создания резервной копии.

  • Зашифрованная резервная копия: содержит данные, зашифрованные с использованием ключа, доступного в тот момент.

  • Текущий сервер: pg_tde автоматически загружает резервную копию, если ключ доступен через KMS.

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

Примечание

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

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

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

F.69.18. FAQ #

F.69.18.1. Зачем мне нужен TDE? #

Использование TDE предоставляет следующие преимущества:

  • Соответствие требованиям безопасности и юридическим нормативам, таким как Общий регламент по защите данных (GDPR), Международный стандарт безопасности данных платёжных карт (PCI DSS), Федеральный закон № 420-ФЗ от 30.11.2024 и другие

  • Шифрование резервных копий. Даже если уполномоченное лицо получает физический доступ к резервной копии, шифрование гарантирует, что данные остаются нечитаемыми и защищенными.

  • Гранулярное шифрование конкретных наборов данных и снижение накладных расходов на производительность, которые приносит шифрование.

  • Дополнительный уровень безопасности к существующим мерам безопасности

F.69.18.2. Когда и как следует использовать TDE? #

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

  • финансовые услуги, где TDE помогает соответствовать PCI DSS

  • здравоохранение и страхование - соответствие HIPAA, HITECH, CCPA

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

Использование TDE помогает избежать следующих рисков:

  • Утечки данных

  • Кража личных данных, которая может привести к финансовому мошенничеству и другим преступлениям

  • Ущерб репутации, приводящий к потере доверия клиентов и бизнеса

  • Юридические последствия и финансовые потери за несоблюдение нормативных актов по защите данных

  • Внутренние угрозы из-за неправильного использования незашифрованных конфиденциальных данных

Если переводить конфиденциальные данные в файлы, хранящиеся в вашей базе данных, это пользовательские данные в таблицах, временные файлы, файлы WAL. TDE обеспечивает шифрование всех этих файлов.

pg_tde пока не шифрует системные каталоги. Это означает, что статистические данные и метаданные базы данных не шифруются.

F.69.18.3. Будет ли логическая репликация работать с pg_tde? #

Да, логическая репликация работает с зашифрованными таблицами.

F.69.18.4. Сохраняет ли логическая репликация данные зашифрованными на подписчиках? #

Логическая репликация не сохраняет состояние шифрования. Если на стороне публикации используется pg_tde, а на стороне подписчика — нет, то реплицируемые данные будут храниться в открытом виде на подписчике.

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

Примечание

Это означает, что зашифрованные публикации не гарантируют зашифрованные логические реплики.

F.69.18.5. Я использую шифрование на уровне диска. Почему мне стоит беспокоиться о TDE? #

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

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

Еще один момент, который следует учитывать, это соответствие PCI DSS для шифрования персональных номеров счетов (PAN).

  • Стандарты PCI DSS 3.4.1 могут считать шифрование диска достаточным для соответствия, если вы выполняете эти требования:

    • Отделите логический доступ к данным от аутентификации операционной системы.

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

    Обратите внимание, что PCI DSS 3.4.1 прекращает действие 31 марта 2025 года. Поэтому рассмотрите возможность перехода на PCI DSS 4.0.

  • Стандарты PCI DSS 4.0 считают использование только шифрования на уровне диска и раздела недостаточным для обеспечения защиты PAN. Требуется дополнительный уровень безопасности, который может обеспечить pg_tde.

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

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

F.69.18.6. Достаточно ли TDE для обеспечения безопасности данных? #

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

  • Контроль доступа и аутентификация

  • Сильная сетевая безопасность, такая как TLS

  • Шифрование диска

  • Регулярный мониторинг и аудит

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

F.69.18.7. Как pg_tde обеспечивает безопасность моих данных? #

pg_tde использует два ключа для шифрования данных:

  • Внутренние ключи шифрования для шифрования данных. Эти ключи хранятся внутри в зашифрованном формате, в едином $PGDATA/pg_tde каталоге.

  • Основные ключи для шифрования внутренних ключей шифрования. Эти ключи хранятся внешне, в Системе Управления Ключами (KMS).

Вы можете использовать следующие KMS:

  • HashiCorp Vault. pg_tde поддерживает движок секретов KV v2 в Vault, для получения дополнительной информации смотрите раздел Конфигурация Vault.

  • OpenBao реализация Vault

  • Совместимые с KMIP серверы, KMIP — это стандартизованный протокол для обработки криптографических задач и управления секретами, для получения дополнительной информации смотрите раздел Настройка KMIP.

Примечание

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

Давайте разобьём шифрование на две части:

F.69.18.7.1. Шифрование файлов данных #

Сначала файлы данных шифруются с помощью внутренних ключей. Каждый файл, который имеет разный идентификатор объекта (OID), имеет внутренний ключ. Например, таблица с 4 индексами будет иметь 5 внутренних ключей — один для таблицы и по одному для каждого индекса.

Первоначальное решение о том, какой файл шифровать, основывается на методе доступа к таблице в Tantor SE. Когда вы выполняете оператор CREATE или ALTER TABLE с использованием предложения USING tde_heap, вновь созданные файлы данных помечаются как зашифрованные, и затем операции с файлами шифруют или дешифруют данные. Позже, если первоначальный файл воссоздается в результате команды TRUNCATE или VACUUM FULL, вновь созданный файл наследует информацию о шифровании и либо шифруется, либо нет.

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

F.69.18.7.2. Шифрование WAL #

Шифрование WAL выполняется глобально для всего кластера базы данных. Все изменения в любой базе данных внутри кластера Tantor SE записываются в один и тот же WAL для поддержания согласованности и целостности данных и обеспечения возможности восстановления кластера Tantor SE до согласованного состояния. Поэтому WAL шифруется глобально.

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

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

Вы можете включать и выключать шифрование WAL, поэтому WAL может содержать как зашифрованные, так и незашифрованные данные. Переменная GUC шифрования WAL влияет только на записи.

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

F.69.18.8. Следует ли мне шифровать все мои данные? #

Это зависит от ваших бизнес-требований и чувствительности ваших данных. Шифрование всех данных является хорошей практикой, но это может повлиять на производительность.

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

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

F.69.18.9. Какие механизмы шифрования используются в pg_tde? #

pg_tde в настоящее время использует алгоритм AES-CBC-128. Сначала внутренние ключи в файле данных шифруются с использованием основного ключа с AES-CBC-128, затем данные файла снова шифруются с использованием AES-CBC-128 с внутренним ключом.

Для шифрования WAL используется AES-CTR-128.

F.69.18.10. Поддерживается ли постквантовое шифрование? #

Нет. Постквантовое шифрование в настоящее время не поддерживается.

F.69.18.11. Могу ли я зашифровать существующую таблицу? #

Да, вы можете зашифровать существующую таблицу. Выполните команду ALTER TABLE следующим образом: 

ALTER TABLE table_name SET ACCESS METHOD tde_heap;

Поскольку команда SET ACCESS METHOD сбрасывает подсказочные биты (hint bits), что может повлиять на производительность, мы рекомендуем выполнить команду SELECT count(*). Она проверяет каждый кортеж на видимость и устанавливает её подсказочные биты. Подробнее читайте в разделе Изменение существующей таблицы.

F.69.18.12. Нужно ли перезапускать базу данных для шифрования данных? #

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

  • после того как вы включили расширение pg_tde

  • при включении шифрования WAL

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

F.69.18.13. Что произойдет с моими данными, если я потеряю основной ключ? #

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

F.69.19. Деинсталляция pg_tde #

Если вы больше не хотите использовать прозрачное шифрование данных (TDE) в своем развертывании, вы можете удалить расширение pg_tde.

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

  • Права суперпользователя (для удаления расширения глобально) или

  • Привилегии владельца базы данных (чтобы удалить её только из конкретной базы данных)

Для удаления pg_tde выполните следующие шаги.

F.69.19.1. Шаг 1. Удалите pg_tde из всех баз данных #

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

  1. Перезапишите зашифрованные таблицы:

Чтобы переписать зашифрованную таблицу обратно на её метод хранения по умолчанию: 

ALTER TABLE <table_name> SET ACCESS METHOD heap;

  1. Удалите расширение после того, как все зашифрованные таблицы были переписаны или удалены: 

DROP EXTENSION pg_tde;

Примечание

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

Повторите шаг 1 для каждой базы данных в вашем кластере.

F.69.19.2. Шаг 2. Отключите шифрование WAL #

Если вы используете шифрование WAL, необходимо отключить его перед тем, как удалять библиотеку pg_tde:

  1. Выполнить: 

ALTER SYSTEM SET pg_tde.wal_encrypt = off;

  1. Перезапустите кластер Tantor SE, чтобы применить изменения: 

sudo systemctl restart tantor-CONF_EDITION_SHORT_NAME__-server-CONF_PG_MAJOR_VERSION__

F.69.19.3. Шаг 3. Удалите pg_tde из shared library #

Предупреждение

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

Примечание

Зашифрованные страницы WAL не будут расшифрованы, поэтому для любого кластера postgres, которому необходимо их читать, потребуется загрузить библиотеку pg_tde, а также чтобы ключи шифрования WAL были доступны и использовались.

На этом этапе pg_tde в shared library всё ещё загружена, но больше не активно. Чтобы полностью удалить pg_tde, выполните следующие шаги.

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

Например: 

postgres=# SHOW shared_preload_libraries;
        shared_preload_libraries
-----------------------------------------
pg_stat_statements,pg_tde,auto_explain
 (1 row)

postgres=#

  1. Удалите pg_tde из списка и примените новое значение с помощью ALTER SYSTEM SET shared_preload_libraries=<ваш список библиотек>.

Например: 

postgres=# ALTER SYSTEM SET shared_preload_libraries=pg_stat_statements,auto_explain;
ALTER SYSTEM
postgres=#

Примечание

Ваш список библиотек, скорее всего, будет отличаться от приведённого выше примера. Будьте осторожны, чтобы не удалить другие необходимые расширения. Удаляйте из списка только pg_tde.

Если pg_tde — единственная в списке shared library, и она была установлена через postgresql.conf, вы не можете отключить её с помощью команды ALTER SYSTEM SET .... Вместо этого:

  1. Удалите строку shared_preload_libraries из postgresql.conf

  2. Выполните ALTER SYSTEM RESET shared_preload_libraries;

  1. Перезапустите кластер Tantor SE, чтобы применить изменения: 

    sudo systemctl restart tantor-CONF_EDITION_SHORT_NAME__-server-CONF_PG_MAJOR_VERSION__

F.69.19.4. Шаг 4. (Необязательно, но рекомендуется) Очистите конфигурацию #

На этом этапе можно безопасно удалить все настройки, связанные с pg_tde из postgresql.conf и postgresql.auto.conf. Найдите все параметры конфигурации с префиксом pg_tde. и удалите их или закомментируйте, если это необходимо.

F.69.19.5. Устранение неполадок: PANIC: контрольная точка не найдена при перезапуске #

Это может произойти, если шифрование WAL не было корректно отключено перед удалением pg_tde из shared_preload_libraries, либо если сервер Tantor SE не был перезапущен после отключения шифрования WAL (смотрите шаг 3.c).

Вы можете увидеть это при перезапуске кластера Tantor SE: 

2025-04-01 17:12:50.607 CEST [496385] PANIC:  could not locate a valid checkpoint record at 0/17B2580

Эта ошибка означает, что Tantor SE пытается прочитать зашифрованный WAL без загруженного pg_tde.

Чтобы решить эту проблему, выполните следующие шаги:

  1. Снова добавьте pg_tde в shared_preload_libraries

  2. Перезапустите кластер Tantor SE

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

Примечание

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

  • Для отключения шифрования WAL

  • Для удаления библиотеки pg_tde

Назад Наверх Далее
F.68. pg_surgery — выполнять низкоуровневые операции с данными отношений Начало F.70. pg_throttle — расширение, добавляющее функцию ограничения скорости выполнения запросов