F.62. pg_tde#
F.62. pg_tde #
- F.62.1. Быстрый старт
- F.62.2. Что такое прозрачное шифрование данных (TDE)?
- F.62.3. Ротация ключей
- F.62.4. Особенности
- F.62.5. Настройка pg_tde
- F.62.6. Проверка шифрования с помощью pg_tde
- F.62.7. Настройка шифрования WAL (технический предварительный просмотр)
- F.62.8. Техническая справка
- F.62.9. Архитектура
- F.62.10. pg_tde CLI Tools
- F.62.11. Переменные GUC
- F.62.12. Функции
- F.62.13. Инструкции
- F.62.14. FAQ
- F.62.15. Деинсталляция pg_tde
pg_tde
расширение, которое обеспечивает Прозрачное Шифрование Данных (TDE) для защиты данных в состоянии покоя. pg_tde
гарантирует, что данные, хранящиеся на диске, зашифрованы, и никто не сможет их прочитать без соответствующих ключей шифрования, даже если они получат доступ к физическому носителю.
F.62.1. Быстрый старт #
F.62.1.1. Установка #
Расширение должно быть добавлено в shared_preload_libraries
.
Также необходимо перезапустить сервер после изменения shared_preload_libraries
.
shared_preload_libraries = 'pg_tde'
Затем вам следует установить расширение pg_tde
.
CREATE EXTENSION pg_tde;
Если требуются алгоритмы ГОСТ (magma или kuznyechik), установите необходимые модули OpenSSL. Вы можете собрать их из исходников или установить через пакеты.
Существует список известных пакетов для различных дистрибутивов, которые содержат модуль ГОСТ для OpenSSL:
libgost-astra
- Astra Linuxopenssl-gost-engine
- AltLinuxlibengine-gost-openssl
илиlibengine-gost-openssl1.1
- Debian/Ubuntuopenssl-gost-engine
- RedOS
Для других дистрибутивов вам нужно будет собрать его из исходного кода. Исходный код проекта находится в репозитории GitHub.
Когда установлены модули ГОСТ, возможно, потребуется обновить конфигурацию OpenSSL.
Некоторые пакеты (например, libgost-astra
) делают это автоматически.
Для других, возможно, придется обновить конфигурацию вручную.
F.62.1.2. Создание зашифрованной таблицы #
Зарегистрировать поставщика ключей:
SELECT pg_tde_add_database_key_provider_file('file-provider', '/tmp/test-file-provider');
Примечание
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'), pg_tde_get_algorithm('enc_tbl');
Создание зашифрованной таблицы с выбором алгоритма шифрования:
CREATE TABLE enc_tbl1(x int) USING tde_heap WITH (encryptor='magma');
F.62.2. Что такое прозрачное шифрование данных (TDE)? #
Прозрачное шифрование данных (TDE) защищает ваши данные в состоянии покоя, гарантируя, что даже если основное хранилище будет скомпрометировано, данные останутся нечитаемыми без правильных ключей шифрования. Это особенно важно для сред, работающих с конфиденциальной, регулируемой или ценной информацией.
Шифрование происходит прозрачно в фоновом режиме, с минимальным воздействием на операции базы данных.
F.62.2.1. Как работает TDE #
Для шифрования данных используются два типа ключей:
Внутренние ключи шифрования для шифрования пользовательских данных. Они хранятся внутри, рядом с данными, которые они шифруют.
Основной ключ для шифрования ключей базы данных. Он хранится отдельно от ключей базы данных и управляется внешне в хранилище управления ключами.
У вас есть следующие варианты для внешнего хранения и управления основными ключами:
Используйте сервер HashiCorp Vault. Поддерживается только бэкенд KV Secrets Engine - Версия 2 (API).
Используйте сервер, совместимый с KMIP.
pg_tde
был протестирован с PyKMIP сервером и движком секретов HashiCorp Vault Enterprise KMIP.
Процесс шифрования следующий:
Когда пользователь создает зашифрованную таблицу с использованием
pg_tde
, для этой таблицы внутренне генерируется новый случайный ключ,
который шифруется с использованием алгоритма шифрования AES-CBC-256. Этот ключ используется для шифрования всех данных, которые пользователь
вставляет в эту таблицу. В конечном итоге зашифрованные данные сохраняются
в базовом хранилище.
Внутренний ключ зашифрован с использованием основного ключа. Основной ключ хранится внешне в хранилище управления ключами.
Аналогично, когда пользователь выполняет запрос к зашифрованной таблице, главный ключ извлекается из хранилища ключей для расшифровки внутреннего ключа. Затем тот же уникальный внутренний ключ для этой таблицы используется для расшифровки данных, и незашифрованные данные возвращаются пользователю. Таким образом, фактически, каждая таблица TDE имеет уникальный ключ, и каждый ключ таблицы зашифрован с использованием главного ключа.
F.62.2.2. Область Зашифрованных Данных #
pg_tde
шифрует следующие компоненты:
Пользовательские данные в таблицах, использующих расширение, включая связанные данные TOAST. Метаданные таблицы (имена столбцов, типы данных и т.д.) не зашифрованы.
Данные журнала предзаписи (WAL) для всего кластера базы данных. Это включает данные WAL в зашифрованных и незашифрованных таблицах.
Индексы связанные с зашифрованными таблицами.
F.62.2.3. Методы доступа к таблицам и TDE #
Метод доступа к таблице - это способ, которым Tantor SE хранит данные
в таблице. Метод доступа к таблице по умолчанию -
heap
. Tantor SE организует данные в структуре кучи,
что означает отсутствие определенного порядка строк в
таблице. Каждая строка хранится независимо и идентифицируется
своим уникальным идентификатором строки (TID).
F.62.2.3.1. Как работает tde_heap #
Метод доступа tde_heap
работает поверх
метода доступа по умолчанию heap
и является
маркером для указания, какие таблицы требуют шифрования.
Данные в буферах хранятся незашифрованными. Шифрование и дешифрование происходит только при запросе на чтение или запись на диск.
Таким образом, отсутствуют издержки для внутренних операций.
F.62.2.3.2. Изменение метода доступа к таблице по умолчанию #
Вы можете изменить метод доступа к таблице по умолчанию, чтобы каждая
таблица во всем кластере базы данных создавалась с использованием
пользовательского метода доступа. Например, вы можете включить
шифрование данных по умолчанию, определив
tde_heap
как метод доступа к таблице по умолчанию.
Однако, учтите следующее перед внесением этого изменения:
Это глобальная настройка и применяется ко всему кластеру базы данных, а не только к одной базе данных. Мы рекомендуем устанавливать ее с осторожностью, так как все таблицы и материализованные представления, созданные без явного метода доступа в их операторе
CREATE
, будут по умолчанию использовать указанный метод доступа к таблице.Вы должны создать расширение
pg_tde
и настроить поставщик ключей для всех баз данных, прежде чем изменять конфигурацию. В противном случае Tantor SE не найдет указанный метод доступа и выдаст ошибку.
Вот как вы можете установить новый метод доступа к таблице по умолчанию:
Добавьте метод доступа в параметр
default_table_access_method
:Через SQL оператор
Используйте команду
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;
Перезагрузите конфигурацию, чтобы применить изменения:
SELECT pg_reload_conf();
F.62.2.4. Ограничения pg_tde #
Ключи в локальном файловом поставщике хранятся незашифрованными. Это не рекомендуется для использования в производственной среде. Для лучшей безопасности мы рекомендуем использовать другой KMS, например, HashiCorp Vault или KMIP.
Системные таблицы не зашифрованы. Это означает, что данные статистики и метаданные базы данных не зашифрованы.
Временные файлы, используемые в процессе работы (для сортировки или хеширования), не зашифрованы.
Некоторые инструменты, работающие с WAL, не будут работать, если он зашифрован. К ним относятся:
pg_rewind
,pg_resetwal
,pg_upgrade
.WAL-G не поддерживает отправку дельт WAL, если WAL зашифрован.
Таблицы шифруются с использованием блочного шифра. Это означает, что повреждение одного байта в конце страницы сделает всю страницу недействительной, и после расшифровки там будет мусор. Инструменты, которые ожидают работать с методом доступа
heap
, могут работать неправильно. Например,pg_amcheck
илиamcheck
могут не суметь восстановить страницы, потому что проверка страницы не пройдет (заголовок недействителен).
F.62.3. Ротация ключей #
В настоящее время поддерживается только ротация основного ключа.
Ротация просто включает назначение нового основного ключа:
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.62.3.1. Репликация #
Физическая репликация полностью поддерживается. Записи WAL, связанные с TDE, воспроизводятся на реплике.
Примечание
Для шифрования по ГОСТу убедитесь, что необходимые модули установлены на реплике.
F.62.3.2. Конфигурация OpenSSL #
При запуске расширение загружает файл конфигурации OpenSSL.
Используйте pg_tde.openssl_config
, чтобы указать пользовательский
путь. Если путь не указан, используется системный путь по умолчанию (например,
/etc/ssl/openssl.cnf
на Astra Linux).
Некоторые пакеты (например, libgost-astra
на Astra Linux) обновляют
конфигурацию автоматически.
Примечание
В нашем дистрибутиве модули ГОСТ
(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.62.4. Особенности #
Для расширения доступны следующие функции:
Шифрование таблиц, включая:
Таблицы данных
Данные индекса для зашифрованных таблиц
TOAST таблицы
Временные таблицы, создаваемые во время операций с базой данных
Метаданные этих таблиц не зашифрованы.
Глобальное шифрование журнала предзаписи (WAL) для данных как в зашифрованных, так и в незашифрованных таблицах
Несколько вариантов управления ключами
F.62.5. Настройка pg_tde #
Прежде чем вы сможете использовать pg_tde
для шифрования данных,
вы должны включить расширение и настроить Tantor SE для его загрузки
при запуске. Эта настройка гарантирует, что необходимые хуки и общая
память доступны для операций шифрования.
Расширение pg_tde
требует дополнительной общей
памяти. Вам нужно настроить Tantor SE для предварительной загрузки его при запуске.
Настройте shared_preload_libraries
Вы можете настроить
shared_preload_libraries
параметр двумя способами:Добавьте следующую строку в файл
shared_preload_libraries
:shared_preload_libraries = 'pg_tde'
Используйте команду
ALTER SYSTEM
. Выполните следующую команду вpsql
как суперпользователь:ALTER SYSTEM SET shared_preload_libraries = 'pg_tde';
Перезапустите кластер Tantor SE, чтобы применить конфигурацию.
Создайте расширение
После перезапуска Tantor SE подключитесь к
psql
как суперпользователь или владелец базы данных и выполните:CREATE EXTENSION pg_tde;
См. CREATE EXTENSION для получения более подробной информации.
Примечание
Расширение
pg_tde
создается только для текущей базы данных. Чтобы включить его для других баз данных, вы должны выполнить команду в каждой отдельной базе данных.(Необязательно) Включите pg_tde по умолчанию
Чтобы автоматически включать
pg_tde
для всех новых баз данных, измените базу данныхtemplate1
:psql -d template1 -c 'CREATE EXTENSION pg_tde;'
Примечание
Вы можете использовать внешние поставщики ключей для управления ключами шифрования. Рекомендуемый подход - использовать Хранилище Управления Ключами (KMS). См. следующий шаг о том, как настроить KMS.
F.62.5.1. Настройка управления ключами (KMS) #
В производственных средах хранение ключей шифрования локально на
сервере Tantor SE может представлять угрозу безопасности. Для повышения
безопасности pg_tde
поддерживает интеграцию с
внешними системами управления ключами (KMS) через интерфейс глобального
поставщика ключей.
Этот раздел описывает, как вы можете настроить
pg_tde
для использования локальных и внешних поставщиков ключей. Чтобы использовать внешнюю KMS с
pg_tde
, выполните следующие два шага:
Настройте поставщика ключей
Установите Глобальный основной ключ
Примечание
Хотя файлы ключей могут быть приемлемы для локальных или тестовых сред, интеграция с KMS является рекомендуемым подходом для развертывания в производственной среде.
F.62.5.2. Конфигурация KMIP #
Чтобы использовать сервер протокола совместимости управления ключами (KMIP)
с pg_tde
, вы должны настроить его в качестве
глобального поставщика ключей. Эта настройка позволяет
pg_tde
безопасно получать и управлять
ключами шифрования из централизованного устройства управления ключами.
Примечание
Вам нужен корневой сертификат сервера KMIP и пара ключ/сертификат клиента с разрешениями на создание и чтение ключей на сервере.
Рекомендуется ознакомиться с рекомендациями по настройке HashiCorp Vault Enterprise KMIP Secrets Engine, если вы используете Vault.
Для тестирования вы можете использовать легковесный сервер PyKMIP, который позволяет легко генерировать сертификаты и обеспечивает базовое поведение KMIP. Если вы используете сервер KMIP промышленного уровня, убедитесь, что вы получили действительные, доверенные сертификаты от устройства управления ключами.
F.62.5.2.1. Пример использования #
SELECT pg_tde_add_global_key_provider_kmip( 'provider-name', 'kmip-IP', 5696, '/path_to/server_certificate.pem', '/path_to/client_cert.pem', '/path_to/client_key.pem' );
F.62.5.2.2. Описание параметров #
provider-name
— это имя поставщика. Вы можете указать любое имя, чтобы идентифицировать поставщикаkmip-IP
— это IP-адрес или доменное имя сервера KMIPport
— это порт для связи с сервером KMIP. Обычно используется порт 5696server-certificate
— это путь к файлу сертификата для сервера KMIPclient_cert
— это путь к клиентскому сертификату.client_key
(необязательно) - это путь к ключу клиента. Если не указано, ключ сертификата должен содержать как сертификат, так и ключ.
Предупреждение
pg_tde_add_global_key_provider_kmip
в настоящее время принимает только объединенный клиентский ключ и клиентский
сертификат в качестве своего последнего параметра, называемого
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' );
Для получения дополнительной информации о связанных функциях, см. ссылку ниже:
F.62.5.3. Конфигурация Vault #
Вы можете настроить pg_tde
для использования HashiCorp
Vault в качестве глобального поставщика ключей для безопасного управления ключами шифрования.
Примечание
Это руководство предполагает, что ваш сервер Vault уже настроен и доступен. Конфигурация Vault выходит за рамки данного документа, см. официальную документацию Vault для получения дополнительной информации.
F.62.5.3.1. Пример использования #
SELECT pg_tde_add_global_key_provider_vault_v2( 'provider-name', 'secret_token_path', 'url', 'mount', 'ca_path' );
F.62.5.3.2. Описание параметров #
provider-name
— это имя для идентификации этого поставщика ключейsecret_token
является токеном доступа с правами на чтение и запись в вышеуказанную точку монтированияurl
— это URL-адрес сервера Vaultmount
- это точка монтирования, где ключница должна хранить ключиca_path
(необязательно) — это путь к файлу CA, используемому для проверки SSL
Следующий пример предназначен только для тестирования. Используйте безопасные токены и правильную проверку SSL в производственных средах:
SELECT pg_tde_add_global_key_provider_vault_v2( 'my-vault', '/path/to/token_file', 'http://vault.vault.svc.cluster.local:8200', 'secret/data', NULL );
Для получения дополнительной информации о связанных функциях, см. ссылку ниже:
F.62.5.4. Конфигурация файла ключей #
Эта настройка предназначена для разработки и хранит ключи незашифрованными в указанном файле данных.
Примечание
Хотя файлы ключей могут быть приемлемы для локальных или тестовых сред, интеграция с KMS является рекомендуемым подходом для развертывания в производственной среде.
SELECT pg_tde_add_global_key_provider_file( 'provider-name', '/path/to/the/keyring/data.file' );
Следующий пример используется только для тестирования:
SELECT pg_tde_add_global_key_provider_file( 'file-keyring', '/tmp/pg_tde_test_local_keyring.per' );
F.62.5.5. Конфигурация глобального основного ключа #
Вы можете настроить основной ключ по умолчанию, используя глобальный поставщик ключей. Этот ключ будет использоваться всеми базами данных, для которых не настроены собственные ключи шифрования.
F.62.5.5.1. Создайте основной ключ по умолчанию #
Выполните следующую команду:
SELECT pg_tde_set_default_key_using_global_key_provider( 'name-of-the-key', 'provider-name', 'ensure_new_key' );
F.62.5.5.2. Описание параметра #
name-of-the-key
— это имя основного ключа. Вы будете использовать это имя для идентификации ключа.provider-name
— это имя поставщика ключей, которое вы добавили ранее. Основной ключ будет связан с этим поставщиком.ensure_new_key
определяет, должен ли основной ключ быть уникальным. Значение по умолчаниюtrue
означает, что вы должны указать уникальный ключ во время ротации ключа. Значениеfalse
позволяет повторно использовать существующий основной ключ.
Этот пример предназначен только для тестирования. Замените имя ключа и имя поставщика на ваши значения:
SELECT pg_tde_set_key_using_global_key_provider( 'test-db-master-key', 'file-vault', 'ensure_new_key' );
Примечание
Ключ генерируется автоматически.
После этого все базы данных, для которых не настроено что-то другое, будут использовать этот вновь сгенерированный основной ключ.
F.62.6. Проверка шифрования с помощью pg_tde #
После включения расширения pg_tde
для базы данных, вы можете начать шифрование данных, используя метод доступа к таблице tde_heap
.
F.62.6.1. Создание зашифрованной таблицы #
Чтобы создать таблицу с включенным шифрованием, используйте метод доступа tde_heap следующим образом:
CREATE TABLE <table_name> (<field> <datatype>) USING tde_heap [ WITH (encryptor = aes | kuznyechik | grasshopper | magma | chacha20 ) ];
Вы также можете указать параметр хранения '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 = magma);
Чтобы проверить, зашифрованы ли данные, выполните следующую функцию:
SELECT pg_tde_is_encrypted('table_name');
Функция возвращает
t
, если таблица зашифрована, иf
- если нет.(Необязательно) Проведите ротацию основного ключа.
Чтобы повторно зашифровать данные с использованием нового ключа, см. Управление основными ключами.
F.62.6.2. Зашифровать существующую таблицу #
Вы можете зашифровать существующую таблицу. Это требует переписывания таблицы, поэтому для больших таблиц это может занять значительное количество времени.
Выполните следующую команду:
ALTER TABLE table_name SET ACCESS METHOD tde_heap;
Предостережение
Использование SET ACCESS METHOD
удаляет подсказочные биты, что может повлиять на производительность запросов. Чтобы восстановить производительность, выполните:
SELECT count(*) FROM table_name;
Это заставляет Tantor SE проверять каждую кортеж на видимость и сбрасывать подсказочные биты.
Подсказка
Хотите позже удалить шифрование? Узнайте, как расшифровать ваши данные.
F.62.7. Настройка шифрования WAL (технический предварительный просмотр) #
Прежде чем включить шифрование WAL, вы должны выполнить следующие шаги, чтобы создать свой первый основной ключ.
F.62.7.1. Создать основной ключ #
Создайте расширение
pg_tde
, если оно не существует:CREATE EXTENSION IF NOT EXISTS pg_tde;
Настройте поставщика ключей для шифрования WAL
С сервером KMIP
Убедитесь, что вы получили корневой сертификат для сервера KMIP и пару ключей для клиента. Клиентский ключ должен иметь разрешения на создание / чтение ключей на сервере. Найдите рекомендации по конфигурации для HashiCorp Vault Enterprise KMIP Secrets Engine.
Для тестирования вы можете использовать сервер PyKMIP, который позволяет настроить необходимые сертификаты. Чтобы использовать реальный сервер KMIP, убедитесь, что у вас есть действительные сертификаты, выданные устройством управления ключами.
SELECT pg_tde_add_global_key_provider_kmip('provider-name','kmip-addr', 5696, '/path_to/server_certificate.pem', '/path_to/client_cert.pem', '/path_to/client_key.pem');
где:
provider-name
— это имя поставщика. Вы можете указать любое имя, чтобы идентифицировать поставщика.kmip-addr
— это IP-адрес или доменное имя сервера KMIPport
— это порт для связи с сервером KMIP. Обычно используется порт 5696.server-certificate
— это путь к файлу сертификата для сервера KMIP.client-cert
— это путь к клиентскому сертификату.client-key
— это путь к ключу клиента.
Предупреждение
Этот пример предназначен только для тестирования:
SELECT pg_tde_add_key_using_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');
С HashiCorp Vault
SELECT pg_tde_add_global_key_provider_vault_v2('provider-name', 'secret_token_path', 'url', 'mount', 'ca_path');
где:
provider-name
— это имя, которое вы определяете для поставщика ключейurl
— это URL-адрес сервера Vaultmount
- это точка монтирования, где keyring должен хранить ключиsecret_token_path
— это путь к файлу, который содержит токен доступа с правами на чтение и запись к вышеуказанной точке монтированияca_path
(необязательно) — это путь к файлу CA, используемому для проверки SSL
С файлом ключей
Эта настройка не рекомендуется, так как она предназначена для разработки. Ключи хранятся незашифрованными в указанном файле данных.
SELECT pg_tde_add_global_key_provider_file('provider-name','/path/to/the/keyring/data.file');
Создайте основной ключ
SELECT pg_tde_set_server_key_using_global_key_provider('key', 'provider-name');
Включите шифрование уровня WAL с помощью команды
ALTER SYSTEM
. Для выполнения этой команды вам нужны привилегии суперпользователя:ALTER SYSTEM SET pg_tde.wal_encrypt = on;
Перезапустите сервер, чтобы применить изменения.
Теперь файлы WAL начинают шифроваться как для зашифрованных, так и для незашифрованных таблиц.
Для получения технической информации, связанной с архитектурой, переменными или функциями, см. Техническая справка.
F.62.8. Техническая справка #
Этот раздел охватывает внутренние компоненты и инструменты, которые обеспечивают работу
pg_tde
.
Используйте это, чтобы понять, как реализовано шифрование, точно настроить конфигурацию, использовать расширенные инструменты и функции CLI для диагностики и настройки.
F.62.9. Архитектура #
pg_tde
является
настраиваемым, полным расширением для шифрования данных в состоянии покоя для Tantor SE.
Давайте разберём, что это значит.
Настраиваемый означает, что
pg_tde
стремится поддерживать множество различных вариантов использования:
Шифрование либо каждой таблицы в каждой базе данных, либо только некоторых таблиц в некоторых базах данных
Ключи шифрования могут храниться на различных внешних серверах хранения ключей, включая Hashicorp Vault, KMIP серверы.
Использование одного ключа для всего или разных ключей для разных баз данных
Хранение каждого ключа в одном и том же хранилище ключей или использование различных хранилищ для разных баз данных
Обработка разрешений: кто может управлять разрешениями, специфичными для базы данных или глобальными разрешениями, кто может создавать зашифрованные или не зашифрованные таблицы
Полное означает, что
pg_tde
нацелен на шифрование данных в состоянии покоя.
Данные в состоянии покоя означает все, что записано на диск. Это включает следующее:
Файлы данных таблиц
Индексы
Последовательности
Временные таблицы
Журнал Предварительной Записи (WAL)
F.62.9.1. Архитектура шифрования #
F.62.9.1.1. Иерархия с двумя ключами #
pg_tde
использует два вида ключей для
шифрования:
Внутренние ключи для шифрования данных. Они хранятся в Tantor SE в каталоге данных под
$PGDATA/pg_tde
.Ключи более высокого уровня для шифрования внутренних ключей. Эти ключи называются “основными ключами”. Они хранятся внешне, в Системе Управления Ключами (KMS) с использованием API поставщика ключей.
pg_tde
использует один основной ключ для каждой базы данных.
Каждый внутренний ключ для данной базы данных зашифрован с использованием
этого основного ключа.
Внутренние ключи используются для конкретных файлов базы данных: каждый файл с различным Идентификатором объекта (OID) имеет различный внутренний ключ.
Это означает, что, например, таблица с 4 индексами будет иметь как минимум 5 внутренних ключей - один для таблицы и по одному для каждого индекса.
Если у таблицы есть дополнительные связанные отношения, такие как последовательности или TOAST-таблица, эти отношения также будут иметь отдельные ключи.
F.62.9.1.2. Алгоритм шифрования #
Для шифрования отношений pg_tde
использует следующие алгоритмы
шифрования:
AES-CBC-256
ChaCha20
ГОСТ 28147-89 Magma
ГОСТ Р 34.12-2015 Kuznyechik
Для шифрования WAL используется AES-CTR-256
.
Для шифрования внутренних ключей AES-GCM-256
. Это обеспечивает
аутентичность данных (целостность), поэтому на практике невозможно подделать ключи.
F.62.9.1.3. Рабочий процесс шифрования #
pg_tde
позволяет шифровать
всё или только некоторые таблицы в некоторых базах данных.
Чтобы поддерживать это без изменений метаданных, зашифрованные таблицы
помечаются маркером метода доступа tde_heap
.
Метод доступа tde_heap
такой же, как и
heap
. Он использует те же функции
внутренне без каких-либо изменений, но с другим именем
и идентификатором. Таким образом, pg_tde
знает, что
таблицы tde_heap
зашифрованы, а
таблицы heap
нет.
Первоначальное решение о том, что шифровать, принимается с использованием
механизма триггеров событий postgres
: если оператор
CREATE TABLE
или
ALTER TABLE
использует
клаузу tde_heap
, вновь созданные файлы данных
помечаются как зашифрованные. Затем операции с файлами шифруют или
расшифровывают данные.
Позднее решения принимаются, когда файл базы данных воссоздается с другим
relfilenode
в результате команды
TRUNCATE
или VACUUM FULL
,
вновь созданный файл наследует информацию о шифровании и
либо шифруется, либо нет.
F.62.9.1.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.62.9.1.5. Шифрование других методов доступа #
В настоящее время pg_tde
шифрует только
heap
таблицы и другие файлы, такие как
индексы, TOAST таблицы, последовательности, которые связаны с
heap
таблицами.
F.62.9.2. Управление ключами и поставщиками ключей #
F.62.9.2.1. Основная ротация ключей #
Вы можете менять основные ключи, чтобы соответствовать общим политикам и справляться с ситуациями с потенциально раскрытыми основными ключами.
Ротация означает, что pg_tde
генерирует новую
версию основного ключа и повторно шифрует связанные
внутренние ключи с использованием нового ключа. Старый основной ключ сохраняется
в том же месте, потому что он может все еще понадобиться для
расшифровки резервных копий или других баз данных.
F.62.9.2.2. Внутренняя регенерация ключа #
Внутренние ключи для таблиц, индексов и других файлов данных фиксируются после создания файла. Нет возможности повторно зашифровать файл.
Существуют обходные пути для этого, потому что операции, которые перемещают
данные таблицы в новый файл, такие как
VACUUM FULL
или
ALTER TABLE
, который переписывает файл,
создадут новый ключ для нового файла, по сути, меняя
внутренний ключ. Однако это означает установку эксклюзивной блокировки на
таблицу на время выполнения операции, что может быть
нежелательно для огромных таблиц.
Внутренние ключи WAL также фиксируются в соответствующих диапазонах. Чтобы сгенерировать новый ключ WAL, необходимо перезапустить базу данных.
F.62.9.2.3. Внутреннее хранение ключей #
Внутренние ключи и метаданные pg_tde
в
общем хранятся в едином каталоге $PGDATA/pg_tde
.
Этот каталог хранит отдельные файлы для каждой
базы данных, такие как:
Зашифрованные внутренние ключи и отображение внутренних ключей на таблицы
Информация о ключевых поставщиках
Также, в каталоге $PGDATA/pg_tde
есть
специальный глобальный раздел, помеченный OID
1664
, который включает глобальных поставщиков ключей
и глобальные внутренние ключи.
Глобальный раздел используется для шифрования WAL. Конкретные базы данных также могут использовать глобальный раздел в сценариях, когда пользователи настраивают индивидуальные ключи для баз данных, но используют одного и того же глобального поставщика ключей. Для этой цели вы должны включить наследование глобального поставщика.
Глобальный ключ по умолчанию использует специальный OID
1663
.
F.62.9.2.4. Поставщики ключей (основное хранилище ключей) #
Основные ключи хранятся внешне в Службах управления ключами (KMS). В pg_tde
KMS определяется как внешний поставщик ключей.
Поддерживаются следующие поставщики ключей:
HashiCorp Vault KV2 движок секретов
OpenBao реализация Vault
Серверы, совместимые с KMIP
Локальное файловое хранилище. Это хранилище предназначено только для разработки и тестирования и не рекомендуется для использования в производственной среде.
Для каждого поставщика ключей pg_tde
требуется
детальная конфигурация, включая адрес сервиса
и информацию для аутентификации.
С этими деталями pg_tde
выполняет
следующее на основе операций пользователя:
Загружает новый основной ключ после его создания
Извлекает основной ключ из службы, когда это необходимо для расшифровки
Извлечение основного ключа кэшируется, поэтому оно происходит только при необходимости.
F.62.9.2.5. Управление поставщиком ключей #
Конфигурация или расположение поставщика ключей могут измениться. Например, служба перемещается на новый адрес или основной ключ должен быть перемещен к другому типу поставщика ключей. pg_tde
поддерживает оба этих сценария, позволяя вам управлять основными ключами с помощью простых SQL функций.
В некоторых случаях вы не можете использовать SQL-функции для управления поставщиками ключей. Например, если поставщик ключей изменился, пока сервер не работал, и поэтому не осведомлен об этих изменениях. Запуск может завершиться неудачей, если требуется доступ к ключам шифрования.
Для таких ситуаций pg_tde
также предоставляет
инструменты командной строки
для восстановления базы данных.
F.62.9.2.6. Конфиденциальная информация о поставщике ключей #
Предостережение
Данные аутентификации для поставщиков ключей являются конфиденциальными и должны быть защищены.
Не храните эти учетные данные в каталоге $PGDATA
вместе с базой данных. Вместо этого убедитесь, что они хранятся в безопасном месте с жесткими разрешениями файловой системы, чтобы предотвратить несанкционированный доступ.
F.62.9.3. Пользовательский интерфейс #
F.62.9.3.1. Настройка pg_tde
#
Чтобы использовать pg_tde
, пользователи должны:
Добавьте
pg_tde
вshared_preload_libraries
вpostgresql.conf
Выполните
CREATE EXTENSION pg_tde
в базах данных, где они хотят использовать шифрованиеПри необходимости включите
pg_tde.wal_encrypt
вpostgresql.conf
При необходимости отключите
pg_tde.inherit_global_providers
вpostgresql.conf
(включено по умолчанию)
F.62.9.3.2. Добавление поставщиков #
Поставщики ключей могут быть добавлены либо в глобальную область, либо в область, специфичную для базы данных.
Если 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.62.9.3.3. Изменение поставщиков #
Чтобы изменить значение глобального поставщика:
pg_tde_change_global_key_provider_<TYPE>('provider_name', ... details ...)
Чтобы изменить значение поставщика, специфичного для базы данных:
pg_tde_change_database_key_provider_<TYPE>('provider_name', ... details ...)
Эти функции также позволяют изменять тип поставщика.
Однако функции не переносят данные. Ожидается, что они будут использоваться во время миграции инфраструктуры, например, когда изменяется адрес сервера.
Обратите внимание, что в этих функциях параметры не проверяются. Для
этого см. pg_tde_verify_key
.
F.62.9.3.4. Изменение поставщиков из командной строки #
Чтобы изменить поставщика из командной строки,
pg_tde
предоставляет
инструмент командной строки pg_tde_change_key_provider
.
Этот инструмент работает аналогично вышеуказанным функциям, с следующим синтаксисом:
pg_tde_change_key_provider <dbOid> <providerType> ... details ...
Обратите внимание, что поскольку этот инструмент предполагается использовать в автономном режиме, он обходит все проверки разрешений!
Это также причина, по которой требуется
dbOid
вместо имени, так как у него нет возможности
обработать каталог и искать имена.
F.62.9.3.5. Удаление поставщиков #
Поставщики могут быть удалены с использованием функций:
pg_tde_delete_database_key_provider(provider_name) pg_tde_delete_global_key_provider(provider_name)
Для поставщиков, специфичных для базы данных, функция сначала проверяет, используется ли поставщик или нет, и поставщик удаляется только если он не используется.
Для глобальных поставщиков функция проверяет, используется ли поставщик где-либо, WAL или в какой-либо конкретной базе данных, и возвращает ошибку, если это так.
Это несколько противоречит принципу, что
pg_tde
не должен взаимодействовать с другими
базами данных, кроме той, к которой подключен пользователь, но с другой
стороны, он выполняет этот поиск только во внутренней
метаданных pg_tde
, а не в каталогах postgres,
так что это серая зона. Выполнение этой проверки имеет больше смысла, чем
потенциальное создание недоступности некоторых баз данных.
F.62.9.3.6. Перечисление/запрос поставщиков #
pg_tde
предоставляет 2 функции для отображения
поставщиков:
pg_tde_list_all_database_key_providers()
pg_tde_list_all_global_key_providers()
Эти функции возвращают список имен поставщиков, типа и конфигурации.
F.62.9.3.7. Разрешения поставщика #
pg_tde
реализует контроль доступа на основе
прав выполнения административных функций.
Для управления ключами и поставщиками, он предоставляет две пары функций:
pg_tde_(grant/revoke)_database_key_management_to_role
F.62.9.3.8. Создание и ротация ключей #
Основные ключи могут быть созданы или изменены с помощью следующих функций:
pg_tde_set_key_using_(global/database)_key_provider('key-name', 'provider-name', ensure_new_key) pg_tde_set_server_key_using_(global/database)_key_provider('key-name', 'provider-name', ensure_new_key) pg_tde_set_default_key_using_(global/database)_key_provider('key-name', 'provider-name', ensure_new_key)
ensure_new_key
— это логический параметр,
по умолчанию равный false. Если он true
,
функция может вернуть ошибку вместо установки ключа, если
он уже существует у поставщика.
F.62.9.3.9. Основной ключ по умолчанию #
С помощью pg_tde.inherit_global_key_providers
также возможно настроить основной глобальный ключ по умолчанию,
который будет использоваться любой базой данных, в которой
включено расширение pg_tde
, но не настроен
основной ключ для конкретной базы данных с использованием
pg_tde_set_key_using_(global/database)_key_provider
.
С этой функцией возможно, чтобы весь сервер базы данных легко использовал один и тот же основной ключ для всех баз данных, полностью отключая многопользовательский режим.
Ключом по умолчанию можно управлять с помощью следующей функции:
pg_tde_set_default_key('key-name', 'provider-name', ensure_new_key)
Изменение ключа по умолчанию приведет к изменению шифрования внутренних ключей для всех баз данных, использующих текущий ключ по умолчанию.
F.62.9.3.10. Текущие ключевые детали #
pg_tde_key_info()
возвращает имя
текущего основного ключа и поставщика, который он использует.
pg_tde_server_key_info()
делает то же самое для
серверного ключа.
pg_tde_default_key_info()
делает то же самое для
ключа по умолчанию.
pg_tde_verify_key()
проверяет, что поставщик ключей доступен, что текущий основной ключ может быть загружен из него, и что он совпадает с текущим ключом, хранящимся в памяти - если любой из этих шагов не удается, он сообщает об соответствующей ошибке.
F.62.9.3.11. Ключевые разрешения #
Пользователи с правами управления для конкретной базы данных
(pg_tde_(grant/revoke)_(global/databse)_key_management_to_role)
могут изменять ключи для базы данных и использовать текущие функции ключей. Это включает создание ключей с использованием глобальных поставщиков,
если pg_tde.inherit_global_providers
включен.
Также функция
pg_tde_(grant/revoke)_database_key_management_to_role
касается только конкретного разрешения для вышеуказанной
функции: она позволяет пользователю изменять ключ для базы данных,
но не изменять конфигурацию поставщика.
F.62.9.3.12. Создание зашифрованных таблиц #
Чтобы создать зашифрованную таблицу или изменить существующую таблицу для шифрования, просто используйте USING tde_heap
в операторе CREATE
.
F.62.9.3.13. Изменение
pg_tde.inherit_global_keys
настройки #
Пользователи могут использовать pg_tde
с
inherit_global_keys = on
, ссылаться на глобальные
ключи / связки ключей в базах данных, а затем изменить эту настройку на
off
.
В этом случае существующие ссылки на глобальных поставщиков или глобальный ключ основного по умолчанию будут работать как раньше, но новые ссылки на глобальную область не могут быть созданы.
F.62.9.4. Типичные сценарии настройки #
F.62.9.4.1. Простое шифрование “одним основным ключом” #
Обновите файл конфигурации: загрузите расширение и включите шифрование WAL.
shared_preload_libraries = 'pg_tde' pg_tde.wal_encrypt = on
Выполните
CREATE EXTENSION pg_tde;
вtemplate1
Добавьте глобального поставщика ключей
Добавьте основной ключ по умолчанию с использованием того же глобального поставщика
Измените шифрование WAL для использования ключа основного принципала по умолчанию
При необходимости: установите
default_table_access_method
вtde_heap
, чтобы таблицы шифровались по умолчанию
Пользователям базы данных не нужны разрешения на какие-либо функции шифрования: шифрование управляется администраторами, обычным пользователям нужно только создавать таблицы с шифрованием, что не требует специальных разрешений.
F.62.9.4.2. Одно хранилище ключей, но разные ключи для каждой базы данных #
Обновите файл конфигурации: загрузите расширение и включите шифрование WAL.
shared_preload_libraries = 'pg_tde' pg_tde.wal_encrypt = on
Выполните
CREATE EXTENSION pg_tde;
вtemplate1
Добавьте глобального поставщика ключей
Измените шифрование WAL для использования правильного глобального поставщика ключей
Предоставьте пользователям, которые должны управлять ключами базы данных, разрешений на управление ключами, специфичными для базы данных, но не на управление поставщиком ключей, специфичным для базы данных: конкретные базы данных ДОЛЖНЫ использовать глобального поставщика ключей
Примечание
Установка
default_table_access_method
в
tde_heap
возможна, но вместо
ALTER SYSTEM
только для каждой базы данных с использованием
ALTER DATABASE
, после того как основной ключ
настроен для этой конкретной базы данных.
В качестве альтернативы возможна команда ALTER SYSTEM
, но
создание таблицы в базе данных завершится неудачей, если нет
основного ключа для базы данных, который должен быть создан первым.
F.62.10. pg_tde CLI Tools #
Расширение pg_tde
вводит новые
утилиты командной строки и расширяет некоторые существующие инструменты Tantor SE
для поддержки зашифрованных WAL и таблиц. К ним относятся:
F.62.10.1. pg_tde_change_key_provider #
Инструмент для изменения конфигурации поставщика ключей, возможно, также изменения его типа.
Этот инструмент редактирует файлы конфигурации напрямую, игнорируя
разрешения или запущенные процессы postgres
.
Его единственное предполагаемое использование - это исправление серверов, которые не могут запуститься из-за недоступных поставщиков ключей.
Например, вы восстанавливаете из старой резервной копии, и адрес поставщика ключей изменился за это время. Вы можете использовать этот инструмент для исправления конфигурации, что позволит серверу запуститься.
Предупреждение
Используйте этот инструмент
только когда сервер
отключен. Чтобы изменить конфигурацию поставщика ключей, когда
сервер работает, используйте
pg_tde_change_(global/database)_key_provider_<type>
SQL функции.
F.62.10.1.1. Пример использования #
Чтобы изменить конфигурацию поставщика ключей, укажите все параметры
в зависимости от типа поставщика так же, как вы это делаете при
использовании
pg_tde_change_(global/database)_key_provider_<type>
SQL функций.
Общий синтаксис выглядит следующим образом:
pg_tde_change_key_provider [-D <datadir>] <dbOid> <provider_name> <new_provider_type> <provider_parameters...>
F.62.10.1.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 <token_path> <url> <mount_path> [<ca_path>] pg_tde_change_key_provider [-D <datadir>] <dbOid> <provider_name> kmip <host> <port> <cert_path> <key_path> [<ca_path>]
F.62.10.2. pg_waldump #
pg_waldump это инструмент для отображения читаемого человеком представления журнала предзаписи (WAL) кластера базы данных Tantor SE.
Чтобы читать зашифрованные записи WAL, pg_waldump
поддерживает следующие дополнительные аргументы:
keyring_path
: каталог, где хранятся файлы конфигурации keyring для WAL. Эти файлы включают:pg_tde.map
pg_tde.dat
pg_tde_keyrings
Примечание
pg_waldump
не будет расшифровывать WAL, если keyring_path
не установлен.
F.62.11. Переменные GUC #
Расширение pg_tde
предоставляет переменные GUC для
настройки поведения расширения:
F.62.11.1. pg_tde.wal_encrypt #
Тип - boolean
По умолчанию - off
Переменная boolean
, которая контролирует, зашифрованы ли записи WAL или нет.
Изменение этой переменной требует перезапуска сервера и может быть установлено только на уровне сервера.
Шифрование WAL контролируется глобально. Если включено, все записи WAL шифруются во всем кластере Tantor SE.
Эта переменная контролирует только новые записи в WAL, она не влияет на существующие записи WAL.
pg_tde
всегда способен читать существующие
зашифрованные записи WAL, если ключи, использованные для
шифрования, все еще доступны.
Включение шифрования WAL требует настроенного глобального основного ключа. Обратитесь к документации по настройке шифрования WAL для получения дополнительной информации.
F.62.11.2. pg_tde.enforce_encryption #
Тип - boolean
По умолчанию - off
Переменная типа boolean
, которая контролирует,
разрешено ли создание новых, не зашифрованных таблиц.
Если включено, операторы CREATE TABLE
завершатся с ошибкой,
если они не используют метод доступа tde_heap
.
Аналогично,
ALTER TABLE <x> SET ACCESS METHOD
разрешено
только, если метод доступа
tde_heap
.
Другие операции DDL все еще разрешены. Например, другие
ALTER
команды разрешены на незашифрованных
таблицах, если метод доступа не изменяется.
Вы можете установить эту переменную на следующих уровнях:
глобальный - для всего кластера Tantor SE.
база данных - для конкретных баз данных.
пользователь - для конкретных пользователей.
сессия - для текущего сессии.
Установка или изменение значения требует прав суперпользователя.
F.62.11.3. pg_tde.inherit_global_providers #
Тип - boolean
По умолчанию - on
Переменная boolean
, которая контролирует, могут ли базы данных
использовать глобальные поставщики ключей для хранения основных ключей.
Если отключено, функции, которые изменяют поставщиков ключей, могут работать только с локальными поставщиками ключей базы данных.
В этом случае основной ключ по умолчанию, если он установлен, также отключен.
Вы можете установить эту переменную на следующих уровнях:
глобальный - для всего кластера Tantor SE.
база данных - для конкретных баз данных.
пользователь - для конкретных пользователей.
сессия - для текущего сессии.
Установка этой переменной не влияет на существующие использования глобальных ключей. Она только предотвращает создание новых основных ключей с использованием глобальных поставщиков.
F.62.11.4. pg_tde.default_cipher_algorithm #
Тип - строка
По умолчанию - 'aes'
Переменная string
, которая указывает, какой
алгоритм шифрования используется по умолчанию.
Он используется, когда параметр хранения шифратора не используется во время
CREATE TABLE
команды.
Еще один вариант использования - изменение алгоритма шифрования для уже
зашифрованной таблицы. Установите этот параметр на предпочитаемый алгоритм и
выполните ALTER TABLE ... SET ACCESS METHOD tde_heap
.
Вы можете установить этот параметр в значение любого поддерживаемого алгоритма:
aes
- AES-CBC 256-бит.chacha20
- ChaCha20.magma
- ГОСТ 28147-89 Магма.kuznyechik
- ГОСТ Р 34.12-2015 Кузнечик.
Этот параметр является локальным для пользователя и может быть изменен без административных привилегий или перезапуска базы данных.
F.62.11.5. pg_tde.preinit_algs #
Тип - строка
По умолчанию - 'aes,chacha20'
Переменная string
, которая хранит список
названий алгоритмов, разделенных запятыми. Эти алгоритмы загружаются
и инициализируются при запуске сервера.
Если какой-либо алгоритм недоступен, то ERROR
будет выдана, и сервер не запустится.
Это служит 2 целям:
Увеличение производительности за счет устранения необходимости для каждого бэкенда загружать и инициализировать алгоритмы самостоятельно.
Убедитесь, что желаемые алгоритмы доступны для использования.
Наилучшей практикой является установка этого параметра при запуске и не использование других алгоритмов. В противном случае, если желаемый алгоритм не поддерживается, вам придется обновить конфигурацию OpenSSL и перезапустить сервер. Используя этот параметр, вы можете быть уверены, что алгоритм доступен для будущего использования.
F.62.11.6. pg_tde.openssl_config #
Тип - строка
По умолчанию - NULL
Переменная string
, которая хранит путь к
файлу конфигурации OpenSSL, используемому для инициализации OpenSSL.
Если путь не установлен, то используется файл конфигурации по умолчанию.
На большинстве систем, основанных на Debian, это /etc/ssl/openssl.cnf
.
Используя эту опцию, вы можете задать пользовательскую конфигурацию OpenSSL и не вмешиваться в системный конфигурационный файл.
F.62.12. Функции #
Расширение pg_tde
предоставляет функции для
управления различными аспектами его работы:
F.62.12.1. Управление разрешениями #
По умолчанию, pg_tde
является ограничительным. Он не
позволяет выполнять какие-либо операции, пока пользователю не будут предоставлены разрешения.
Только суперпользователи могут создавать или изменять поставщиков ключей или изменять
объекты в глобальной области. Функции для просмотра ключей и для
установки основного ключа в локальном поставщике ключей базы данных, с другой стороны,
могут выполняться владельцем базы данных и делегироваться
обычным пользователям с помощью команд GRANT EXECUTE
и
REVOKE EXECUTE
.
Следующие функции также предоставляются для упрощения управления группами функциональности:
F.62.12.1.1. Управление локальными ключами базы данных #
Используйте эти функции для предоставления или отзыва разрешений на управление ключом текущей базы данных. Они включают или отключают все функции, связанные с ключом текущей базы данных:
pg_tde_grant_database_key_management_to_role(role)
pg_tde_revoke_database_key_management_from_role(role)
F.62.12.1.2. Управление ключами в глобальном масштабе #
Управление глобальной областью ограничено только суперпользователями.
F.62.12.1.3. Проверки #
Используйте эти функции для предоставления или отзыва использования функций запроса, которые не изменяют настройки шифрования:
pg_tde_grant_key_viewer_to_role(role)
pg_tde_revoke_key_viewer_from_role(role)
F.62.12.2. Управление поставщиком ключей #
Поставщик ключей — это система или служба, отвечающая за управление
ключами шифрования. pg_tde
поддерживает
следующих поставщиков ключей:
локальный файл (не для использования в производственной среде)
Hashicorp Vault / OpenBao
Поставщики, совместимые с KMIP
Управление поставщиком ключей включает в себя следующие операции:
создание нового поставщика ключей,
изменение существующего поставщика ключей,
удаление поставщика ключей,
перечисление ключевых поставщиков.
F.62.12.2.1. Добавление поставщика #
Вы можете добавить нового поставщика ключей, используя предоставленные функции, которые реализованы для каждого типа поставщика.
Существует две функции для добавления поставщика ключей: одна функция добавляет его для текущей базы данных, а другая - для глобальной области.
pg_tde_add_database_key_provider_<type>('provider-name', <параметры, специфичные для поставщика>)
pg_tde_add_global_key_provider_<type>('provider-name', <параметры, специфичные для поставщика>)
Когда вы добавляете нового поставщика, имя поставщика должно быть уникальным в пределах области. Но локальный поставщик базы данных и глобальный поставщик могут иметь одинаковое имя.
F.62.12.2.2. Изменение существующего поставщика #
Вы можете изменить существующего поставщика ключей, используя предоставленные функции, которые реализованы для каждого типа поставщика.
Существуют две функции для изменения существующих поставщиков: одна для изменения поставщика в текущей базе данных, и другая для изменения поставщика в глобальной области.
pg_tde_change_database_key_provider_<type>('имя-поставщика', <параметры, специфичные для поставщика>)
pg_tde_change_global_key_provider_<type>('имя-поставщика', <параметры, специфичные для поставщика>)
Когда вы меняете поставщика, указанное имя должно существовать в локальной базе данных или в глобальной области.
Функции change
требуют тех же
параметров, что и функции add
. Они
перезаписывают настройки для каждого параметра, кроме имени,
которое нельзя изменить.
Параметры, специфичные для поставщика, различаются для каждой реализации. Обратитесь к соответствующему подразделу для получения подробной информации.
Некоторые параметры, специфичные для поставщика, содержат конфиденциальную информацию, такую как пароли. Никогда не указывайте их напрямую, используйте вместо этого параметр удаленной конфигурации.
F.62.12.2.2.1. Добавление или изменение поставщиков Vault #
поставщик Vault подключается к серверу HashiCorp Vault или OpenBao и хранит ключи в хранилище ключ-значение версии 2.
Используйте следующие функции, чтобы добавить поставщика Vault:
SELECT pg_tde_add_database_key_provider_vault_v2( 'provider-name', 'secret_token_path', 'url','mount', 'ca_path' ); SELECT pg_tde_add_global_key_provider_vault_v2( 'provider-name', 'secret_token_path', 'url','mount', 'ca_path' );
Эти функции изменяют поставщика Vault:
SELECT pg_tde_change_database_key_provider_vault_v2( 'provider-name', 'secret_token_path', 'url', 'mount', 'ca_path' ); SELECT pg_tde_change_global_key_provider_vault_v2( 'provider-name', 'secret_token_path', 'url', 'mount', 'ca_path' );
где:
provider-name
— это имя поставщика ключейurl
— это URL-адрес сервера Vaultmount
- это точка монтирования на сервере Vault, где поставщик ключей должен хранить ключиsecret_token_path
— это путь к файлу, который содержит токен доступа с правами на чтение и запись к вышеуказанной точке монтирования[необязательно]
ca_path
— это путь к файлу CA, используемому для проверки SSL
F.62.12.2.2.2. Добавление или изменение поставщиков KMIP #
Поставщик KMIP использует удаленный сервер KMIP.
Используйте эти функции для добавления поставщика KMIP:
SELECT pg_tde_add_database_key_provider_kmip( 'provider-name', 'kmip-addr', 'port', '/path_to/server_certificate.pem', '/path_to/client_cert.pem', '/path_to/client_key.pem' ); SELECT pg_tde_add_global_key_provider_kmip( 'provider-name', 'kmip-addr', 'port', '/path_to/server_certificate.pem', '/path_to/client_certificate.pem', '/path_to/client_key.pem' );
Эти функции изменяют поставщика KMIP:
SELECT pg_tde_change_database_key_provider_kmip( 'provider-name', 'kmip-addr', 'port', '/path_to/server_certificate.pem', '/path_to/client_cert.pem', '/path_to/client_key.pem' ); SELECT pg_tde_change_global_key_provider_kmip( 'provider-name', 'kmip-addr', 'port', '/path_to/server_certificate.pem', '/path_to/client_certificate.pem', '/path_to/client_key.pem' );
где:
provider-name
— это имя поставщикаkmip-addr
— это IP-адрес или доменное имя сервера KMIPport
— это порт для связи с сервером KMIP. Большинство серверов KMIP используют порт 5696.server-certificate
— это путь к файлу сертификата для сервера KMIP.client-certificate
— это путь к клиентскому сертификату.client-key
— это путь к ключу клиента.
Примечание
Указанные параметры доступа требуют разрешения на чтение и запись ключей на сервере.
F.62.12.2.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.62.12.2.4. Удаление поставщика #
Эти функции удаляют существующего поставщика в текущей базе данных или в глобальной области:
pg_tde_delete_database_key_provider('provider-name')
pg_tde_delete_global_key_provider('provider-name')
Вы можете удалять только поставщиков ключей, которые в настоящее время не используются. Возвращается ошибка, если текущий основной ключ использует поставщика, которого вы пытаетесь удалить.
Если использование глобальных поставщиков ключей включено через
pg_tde.inherit_global
GUC, вы можете удалить
глобального поставщика ключей только в том случае, если он нигде не используется, включая
любые базы данных. Если он используется в какой-либо базе данных, вместо этого возвращается ошибка.
F.62.12.2.5. Перечисление поставщиков ключей #
Эти функции перечисляют детали всех ключевых поставщиков для текущей базы данных или для глобальной области, включая все значения конфигурации:
pg_tde_list_all_database_key_providers()
pg_tde_list_all_global_key_providers()
Предостережение
Все значения конфигурации включают в себя, возможно, конфиденциальные данные, такие как пароли. Никогда не указывайте их напрямую, используйте вместо этого опцию удаленной конфигурации.
F.62.12.3. Основное управление ключами #
Используйте эти функции для создания нового основного ключа для определенной области, такой как текущая база данных, глобальная или область по умолчанию. Вы также можете использовать их для начала использования другого существующего ключа для определенной области.
Основные ключи хранятся у поставщиков ключей под именем, указанным в этой функции - например, при использовании поставщика Vault, после создания ключа с именем “foo”, ключ с именем “foo” будет виден на сервере Vault в указанной точке монтирования.
F.62.12.3.1. pg_tde_set_key_using_database_key_provider #
Создает или изменяет основной ключ для текущей базы данных с использованием указанного поставщика ключей базы данных и имени ключа.
SELECT pg_tde_set_key_using_database_key_provider( 'name-of-the-key', 'provider-name', 'ensure_new_key' );
Параметр ensure_new_key
указывает функции, как обрабатывать основной ключ во время ротации ключей:
Если установлено значение
true
(по умолчанию), новый ключ должен быть уникальным. Если поставщик уже хранит ключ с таким именем, функция возвращает ошибку.Если установлено значение
false
, существующий основной ключ может быть повторно использован.
F.62.12.3.2. pg_tde_set_key_using_global_key_provider #
Создает или изменяет глобальный основной ключ, используя указанный глобальный поставщик ключей и имя ключа. Этот ключ используется для глобальных настроек, таких как шифрование WAL.
SELECT pg_tde_set_key_using_global_key_provider( 'name-of-the-key', 'provider-name', 'ensure_new_key' );
Параметр ensure_new_key
указывает функции, как обрабатывать основной ключ во время ротации ключей:
Если установлено значение
true
, новый ключ должен быть уникальным. Если поставщик уже хранит ключ с таким именем, функция возвращает ошибку.Если установлено значение
false
(по умолчанию), существующий основной ключ может быть повторно использован.
F.62.12.3.3. pg_tde_set_server_key_using_global_key_provider #
Создает или изменяет ключ основного сервера, используя указанного глобального поставщика ключей. Используйте эту функцию для установки основного ключа для шифрования WAL.
SELECT pg_tde_set_server_key_using_global_key_provider( 'name-of-the-key', 'provider-name', 'ensure_new_key' );
Параметр ensure_new_key
указывает функции, как обрабатывать основной ключ во время ротации ключей:
Если установлено значение
true
, новый ключ должен быть уникальным. Если поставщик уже хранит ключ с таким именем, функция возвращает ошибку.Если установлено значение
false
(по умолчанию), существующий основной ключ может быть повторно использован.
F.62.12.3.4. pg_tde_set_default_key_using_global_key_provider #
Создает или изменяет основной ключ по умолчанию для сервера с использованием указанного глобального поставщика ключей.
Ключ по умолчанию автоматически используется в качестве основного ключа для любой базы данных, у которой нет индивидуального поставщика ключей и конфигурации ключей.
SELECT pg_tde_set_default_key_using_global_key_provider( 'name-of-the-key', 'provider-name', 'ensure_new_key' );
Параметр ensure_new_key
указывает функции, как обрабатывать основной ключ во время ротации ключей:
Если установлено значение
true
, новый ключ должен быть уникальным. Если поставщик уже хранит ключ с таким именем, функция возвращает ошибку.Если установлено значение
false
(по умолчанию), существующий основной ключ может быть повторно использован.
F.62.12.4. Проверка статуса шифрования #
F.62.12.4.1. pg_tde_is_encrypted #
Сообщает, зашифровано ли отношение с использованием
расширения pg_tde
или нет. Возвращает
NULL
, если отношение не имеет хранилища, как
представления, внешние таблицы и секционированные таблицы и индексы.
Чтобы проверить, что таблица зашифрована, выполните следующий оператор:
SELECT pg_tde_is_encrypted( 'table_name' );
Вы также можете проверить, зашифрована ли таблица в пользовательской схеме. Передайте имя схемы для функции следующим образом:
SELECT pg_tde_is_encrypted( 'schema.table_name' );
Это также может быть использовано для проверки, что индексы и последовательности зашифрованы.
F.62.12.4.2. pg_tde_get_algorithm #
Сообщает, какой алгоритм используется для шифрования отношения. Возвращает
NULL
, если отношение не зашифровано.
Чтобы получить алгоритм шифрования для таблицы в текущей схеме, просто выполните:
SELECT pg_tde_get_algorithm( 'table_name' );
Это также работает для отношений в пользовательской схеме:
SELECT pg_tde_get_algorithm( 'schema.table_name' );
Обратите внимание, что алгоритм шифрования для индексов и TOASTs равен алгоритму шифрования, который используется для родительского отношения.
F.62.12.4.3. pg_tde_key_info #
Отображает информацию о основном ключе для текущей базы данных, если он существует.
SELECT pg_tde_key_info();
F.62.12.4.4. pg_tde_server_key_info #
Отображает информацию о основном ключе для области сервера, если он существует.
SELECT pg_tde_server_key_info();
F.62.12.4.5. pg_tde_default_key_info #
Отображает информацию о ключе по умолчанию, если он существует.
SELECT pg_tde_default_key_info();
F.62.12.4.6. pg_tde_verify_key #
Эта функция проверяет, что в текущей базе данных правильно настроено шифрование, что означает:
Поставщик ключей настроен
Поставщик ключей доступен с использованием указанной конфигурации
Существует основной ключ для базы данных
Основной ключ можно получить от удаленного поставщика ключей
Основной ключ, возвращаемый от поставщика ключей, такой же, как кэшированный в памяти сервера
Если любая из вышеуказанных проверок не проходит, функция сообщает об ошибке.
SELECT pg_tde_verify_key();
F.62.12.4.7. pg_tde_verify_server_key #
Эта функция проверяет, что в серверной области имеется правильно функционирующая настройка шифрования, что означает:
Поставщик ключей настроен
Поставщик ключей доступен с использованием указанной конфигурации
Существует основной ключ для глобальной области видимости
Основной ключ можно получить от удаленного поставщика ключей
Основной ключ, возвращаемый от поставщика ключей, такой же, как кэшированный в памяти сервера
Если любая из вышеуказанных проверок не проходит, функция сообщает об ошибке.
SELECT pg_tde_verify_server_key();
F.62.12.4.8. pg_tde_verify_default_key #
Эта функция проверяет, что ключ по умолчанию правильно настроен, что означает:
Поставщик ключей настроен
Поставщик ключей доступен с использованием указанной конфигурации
Существует основной ключ, который можно использовать для любого объема
Основной ключ можно получить от удаленного поставщика ключей
Основной ключ, возвращаемый от поставщика ключей, такой же, как кэшированный в памяти сервера
Если любая из вышеуказанных проверок не проходит, функция сообщает об ошибке.
SELECT pg_tde_verify_default_key();
F.62.13. Инструкции #
F.62.13.1. Удаление шифрования с зашифрованной таблицы #
F.62.13.1.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
, что означает, что таблица
больше не зашифрована.
Это также можно реализовать с использованием функции pg_tde_get_algorithm
. Не-NULL
вывод означает, что таблица зашифрована:
SELECT pg_tde_get_algorithm('mytable');
F.62.13.1.2. Метод 2. Создание новой незашифрованной таблицы на основе зашифрованной #
В качестве альтернативы, вы можете создать новую незашифрованную таблицу с
той же структурой и данными, что и исходная таблица. Например,
оригинальная зашифрованная таблица называется
EncryptedCustomers
. Используйте следующую
команду для создания новой таблицы Customers
:
CREATE TABLE Customers AS SELECT * FROM EncryptedCustomers;
Новая таблица Customers
наследует
структуру и данные от
EncryptedCustomers
.
(Необязательно) Если вам больше не нужна
EncryptedCustomers
таблица, вы можете удалить
её.
DROP TABLE EncryptedCustomers;
F.62.14. FAQ #
F.62.14.1. Зачем мне нужен TDE? #
Использование TDE предоставляет следующие преимущества:
Соответствие требованиям безопасности и правовым нормам, таким как Общий регламент по защите данных (GDPR), Стандарт безопасности данных индустрии платёжных карт (PCI DSS), Федеральный закон № 420-ФЗ от 30.11.2024 и другим.
Шифрование резервных копий. Даже если уполномоченное лицо получает физический доступ к резервной копии, шифрование гарантирует, что данные остаются нечитаемыми и защищенными.
Гранулярное шифрование конкретных наборов данных и снижение накладных расходов на производительность, которые приносит шифрование.
Дополнительный уровень безопасности к существующим мерам безопасности
F.62.14.2. Когда и как следует использовать TDE? #
Если вы имеете дело с персональными данными (ПД), шифрование данных имеет решающее значение. Особенно если вы работаете в областях с жесткими нормативами, такими как:
финансовые услуги, где TDE помогает соответствовать PCI DSS
здравоохранение и страхование - соответствие HIPAA, HITECH, CCPA
телекоммуникации, государственные учреждения и образование для обеспечения конфиденциальности данных.
Использование TDE помогает избежать следующих рисков:
Утечки данных
Кража личных данных, которая может привести к финансовому мошенничеству и другим преступлениям
Ущерб репутации, приводящий к потере доверия клиентов и бизнеса
Юридические последствия и финансовые потери за несоблюдение нормативных актов по защите данных
Внутренние угрозы из-за неправильного использования незашифрованных конфиденциальных данных
Если переводить конфиденциальные данные в файлы, хранящиеся в вашей базе данных, это пользовательские данные в таблицах, временные файлы, файлы WAL. TDE обеспечивает шифрование всех этих файлов.
pg_tde
не шифрует системные каталоги и временные файлы.
Это означает, что данные статистики и метаданные базы данных не зашифрованы.
F.62.14.3. Я использую шифрование на уровне диска. Почему мне стоит беспокоиться о 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.62.14.4. Достаточно ли TDE для обеспечения безопасности данных? #
Нет. Прозрачное шифрование данных (TDE) добавляет дополнительный уровень безопасности для данных в состоянии покоя. Вы также должны рассмотреть возможность реализации следующих дополнительных функций безопасности:
Контроль доступа и аутентификация
Сильная сетевая безопасность, такая как TLS
Шифрование диска
Регулярный мониторинг и аудит
Дополнительная защита данных для конфиденциальных полей (например, шифрование на уровне приложения)
F.62.14.5. Как pg_tde
обеспечивает безопасность моих данных? #
pg_tde
использует два ключа для шифрования данных:
Внутренние ключи шифрования для шифрования данных. Эти ключи хранятся внутри в зашифрованном формате, в едином
$PGDATA/pg_tde
каталоге.Основные ключи для шифрования внутренних ключей шифрования. Эти ключи хранятся внешне, в Системе Управления Ключами (KMS).
Вы можете использовать следующие KMS:
HashiCorp Vault.
pg_tde
поддерживает KV движок секретов v2 Vault.OpenBao реализация Vault
KMIP-совместимый сервер. KMIP - это стандартизированный протокол для обработки криптографических рабочих нагрузок и управления секретами
HashiCorp Vault также может выступать в роли сервера KMIP, управляя криптографическими ключами для клиентов, использующих протокол KMIP.
Давайте разобьем шифрование на две части:
F.62.14.5.1. Шифрование файлов данных #
Файлы данных зашифрованы с использованием внутренних ключей. Каждый файл, относящийся к зашифрованной таблице, имеет свой собственный внутренний ключ. Например, таблица с 4 индексами будет иметь 5 внутренних ключей - один для таблицы и по одному для каждого индекса.
Первоначальное решение о том, какой файл шифровать, основывается на методе доступа к таблице в Tantor SE. Когда вы выполняете оператор CREATE
или ALTER TABLE
с конструкцией USING tde_heap
, вновь созданные файлы данных помечаются как зашифрованные, и затем операции с файлами шифруют или дешифруют данные. Позже, если первоначальный файл воссоздается в результате команды TRUNCATE
или VACUUM FULL
, вновь созданный файл наследует информацию о шифровании и либо шифруется (т.е. для TRUNCATE
), либо нет (т.е. ALTER TABLE SET ACCESS METHOD heap
).
Основной ключ используется для шифрования внутренних ключей. Он хранится в хранилище управления ключами. Когда вы выполняете запрос к таблице, основной ключ извлекается из хранилища ключей для расшифровки таблицы. Затем внутренний ключ для этой таблицы используется для расшифровки данных.
Основной ключ извлекается из хранилища управления ключами только один раз, когда он впервые требуется, затем он кэшируется в памяти.
F.62.14.5.2. Шифрование WAL #
Шифрование WAL выполняется глобально для всего кластера базы данных. Все изменения в любой базе данных внутри кластера Tantor SE записываются в один и тот же WAL для поддержания согласованности и целостности данных и обеспечения возможности восстановления кластера Tantor SE до согласованного состояния. Поэтому WAL шифруется глобально.
Когда вы включаете шифрование WAL, pg_tde
шифрует все файлы WAL, начиная с первой записи WAL
после запуска сервера с включенным шифрованием.
Тот же подход с двумя ключами используется с WAL, как и с данными таблицы: страницы WAL сначала шифруются с использованием внутреннего ключа. Затем внутренний ключ шифруется с использованием глобального основного ключа.
Вы можете включать и выключать шифрование WAL, поэтому WAL может содержать как зашифрованные, так и незашифрованные данные. Переменная GUC шифрования WAL влияет только на записи.
Всякий раз, когда WAL читается (процессом восстановления или инструментами), решение о том, что должно быть расшифровано, основывается исключительно на метаданных ключей шифрования WAL.
F.62.14.6. Следует ли мне шифровать все мои данные? #
Это зависит от ваших бизнес-требований и чувствительности ваших данных. Шифрование всех данных является хорошей практикой, но это может повлиять на производительность.
Рассмотрите возможность шифрования только тех таблиц, которые хранят конфиденциальные данные. Вы можете решить, какие таблицы шифровать и каким ключом.
Мы советуем шифровать всю базу данных только в том случае, если все ваши данные являются конфиденциальными, например, ПД, или если нет другого способа соответствовать требованиям безопасности данных.
F.62.14.7. Какие механизмы шифрования используются
pg_tde
? #
pg_tde
может использовать 4 различных алгоритма шифрования:
AES-CBC-256, ChaCha20, Magma и Кузнечик. Сначала внутренние
ключи в файле данных шифруются с использованием главного ключа с
AES-CBC-256, затем сами данные файла снова шифруются с использованием
одного из вышеуказанных алгоритмов с внутренним ключом.
Для шифрования WAL используется AES-CTR-256.
Примечание
OpenSSL используется для шифрования/дешифрования, поэтому доступность поддержки алгоритмов в базе данных зависит от их поддержки в самом OpenSSL.
F.62.14.8. Поддерживается ли постквантовое шифрование? #
Нет, это пока не поддерживается. В нашей реализации мы полагаемся на библиотеки OpenSSL, которые еще не поддерживают постквантовое шифрование. Но все используемые алгоритмы шифрования работают только с 256-битными ключами, что позволяет достичь достаточного уровня безопасности.
F.62.14.9. Могу ли я зашифровать существующую таблицу? #
Да, вы можете зашифровать существующую таблицу. Выполните
команду ALTER TABLE
следующим образом:
ALTER TABLE table_name SET ACCESS METHOD tde_heap;
Поскольку команда SET ACCESS METHOD
удаляет
подсказочные биты, и это может повлиять на производительность, мы рекомендуем
выполнить команду SELECT count(*)
. Она проверяет
каждую кортеж на видимость и устанавливает ее подсказочные биты. Подробнее читайте в
разделе Изменение существующей таблицы.
Обратите внимание, что ALTER TABLE SET ACCESS METHOD
не позволяет
устанавливать параметры хранения в WITH
разделе, поэтому
вы можете захотеть изменить Раздел F.62.11.4
для пользовательского алгоритма шифрования.
F.62.14.10. Нужно ли перезапускать базу данных для шифрования данных? #
Вы должны перезапустить базу данных в следующих случаях, чтобы применить изменения:
после того как вы включили расширение
pg_tde
включить / выключить шифрование WAL
чтобы позволить базе данных использовать новые алгоритмы в OpenSSL после того, как вы внесли в него изменения
После этого перезапуск базы данных не требуется. Когда вы создаете или изменяете таблицу, используя метод доступа tde_heap
, файлы помечаются как требующие шифрования.
F.62.14.11. Что произойдет с моими данными, если я потеряю основной ключ? #
Если вы потеряете ключи шифрования, особенно основной ключ, данные будут утеряны. Поэтому крайне важно надежно сохранять резервные копии ваших ключей шифрования и использовать службу управления ключами для управления ключами.
F.62.14.12. Безопасны ли мои резервные копии? Могу ли я восстановить их? #
pg_tde
шифрует данные в состоянии покоя. Это означает, что
данные хранятся на диске в зашифрованной форме. Во время резервного копирования
уже зашифрованные файлы данных копируются с диска на
хранилище. Это обеспечивает безопасность данных в резервных копиях.
Поскольку шифрование происходит на уровне базы данных, это не имеет значения для ваших инструментов и приложений. Они работают с данными таким же образом.
Чтобы восстановить из зашифрованной резервной копии, у вас должен быть тот же основной ключ шифрования, который использовался для шифрования файлов в вашей резервной копии. Поэтому старайтесь хранить их как можно дольше, чтобы иметь возможность восстановиться в худшем случае, когда ваша резервная копия слишком старая.
F.62.15. Деинсталляция pg_tde #
Если вы больше не хотите использовать TDE в вашем развертывании, вы можете
удалить расширение pg_tde
. Для этого ваш
пользователь должен иметь привилегии суперпользователя или привилегии владельца базы данных, если вы хотите удалить его только из одной
базы данных.
Вот как это сделать:
Удалите расширение, используя команду
DROP EXTENSION
:DROP EXTENSION pg_tde;
Эта команда завершится неудачей, если в базе данных все еще есть зашифрованные таблицы.
В этом случае вы должны вручную удалить зависимые объекты. В качестве альтернативы, вы можете выполнить команду
DROP EXTENSION ... CASCADE
, чтобы автоматически удалить все зависимые объекты.Обратите внимание, что команда
DROP EXTENSION
не удаляет файлы данныхpg_tde
, связанные с базой данных.Выполните команду
DROP EXTENSION
в каждой базе данных, где вы включили расширениеpg_tde
, если цель состоит в том, чтобы полностью удалить расширение. Это также включает шаблонные базы данных, в случае еслиpg_tde
ранее было там включено.Удалите любые ссылки на переменные GUC
pg_tde
из файла конфигурации Tantor SE.Измените
shared_preload_libraries
и удалите из него ‘pg_tde’. Используйте командуALTER SYSTEM
для этой цели, или отредактируйте файл конфигурации.Предупреждение
Как только
pg_tde
удален изshared_preload_libraries
, чтение любых оставшихся зашифрованных файлов завершится неудачей. Удаление расширения изshared_preload_libraries
также возможно, если расширение все еще установлено в некоторых базах данных.Убедитесь, что на сервере нет зашифрованных файлов в его каталоге данных.
Запустите или перезапустите кластер Tantor SE, чтобы применить изменения.