Защитное преобразование данных потребляет значительную часть ресурсов процессора и усложняет процесс работы с технической поддержкой. В целях минимизации этих последствий Postgres Pro Enterprise позволяет преобразовывать лишь конфиденциальные данные путём перемещения их в специальное табличное пространство. Процесс защитного и обратного защитного преобразования происходит на лету и не приводит к недоступности СУБД для пользователей. Кроме того, он не влияет на приложения, работающие в СУБД, поскольку запросы к защищённым данным БД обрабатываются прозрачно, как если бы они не были защищены.

Для защитного и обратного защитного преобразования с помощью алгоритма AES pgpro_tde вызывает библиотеку OpenSSL. При этом используется OpenSSL, поставляемая в рамках сертифицированных ОС. Преобразование файлов данных происходит с помощью алгоритма симметричного ключа AES-256-GCM, что обеспечивает подлинность, целостность и конфиденциальность данных. Сегменты WAL же преобразовываются с помощью AES-256-CTR по LSN.

OpenSSL использует расширения к командам векторизации, например AVX-512 для GCM. Благодаря этому AES-256-GCM работает на порядок быстрее. Чтобы добиться такой высокой производительности при работе TDE, убедитесь, что ваше аппаратное и программное обеспечение по виртуализации поддерживает такие расширенные команды.

Postgres Pro Enterprise преобразовывает файлы отношений в специальном табличном пространстве с использованием соответствующих ключей защитного преобразования для этого табличного пространства, а файлы WAL — с использованием специальных ключей защитного преобразования WAL. Эти ключи — уникальная последовательность байтов, которая хранится в защищённом файле $PGDATA/pg_encryption/keys. При запуске система обращается к внешней защитной системе, чтобы обратно преобразовать этот файл, после чего хранит эти ключи в своей памяти.

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

Для каждого кластера существует один файл с набором ключей, который называется keys, он содержит все ключи защитного преобразования для табличного пространства и WAL. Файл хранится в каталоге $PGDATA/pg_encryption. При создании новых ключей (например, после ротации) в системе вызывается внешняя защитная система, которая преобразовывает новые ключи и затем добавляет в конец того же файла. Postgres Pro Enterprise никогда не хранит ключи в текстовом, непреобразованном виде.

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

SELECT pg_rotate_encryption_key(tablespace oid)

Или

select pg_rotate_encryption_key((select oid from pg_tablespace where spcname='my-encrypted-tablespace-name'))

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

В Postgres Pro Enterprise ключи хранятся в каталоге ${PGDATA}/pg_encryption/keys. В целях безопасности все ключи этого файла преобразованы с помощью главного ключа, хранящегося в HashiCorp Vault. Для настройки хранилища необходим адрес приёмника и токен экземпляра. Установка производится через переменные окружения, в качестве примера приведены VAULT_ADDR и VAULT_TOKEN:

echo VAULT_ADDR='http://127.0.0.1:8200' > /etc/env.d/99vault
echo VAULT_TOKEN="hvs.C77DySgOTjliYqmtp3yA4osP" >> /etc/env.d/99vault

Включить транзит с помощью HashiCorp Vault Transit Secrets Engine:

vault secrets enable transit

Создать новый ключ и задать ему новое уникальное имя:

vault write -f transit/keys/pg-tde-new-master-key

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

cat keys | vault write -field=plaintext transit/decrypt/pg-tde-master-key ciphertext=- | vault write -field=ciphertext transit/encrypt/pg-tde-new-master-key plaintext=- > keys

По умолчанию HashiCorp Vault работает с 256-битными ключам. При необходимости работы с другими ключами обратитесь к администратору сервера HashiCorp Vault для изменения конфигурации.

Для обновления ключей табличного пространства администратор СУБД должен вызывать функцию pg_rotate_encryption_key с oid табличного пространства для генерации нового ключа:

postgres=# \db+
                                                      List of tablespaces
    Name    |  Owner   |                 Location                 | Access privileges |     Options     |  Size  | Description
------------+----------+------------------------------------------+-------------------+-----------------+--------+-------------
 encrypted  | postgres | /var/lib/pgpro/ent-17/meta/pg_encryption |                   | {encryption=on} | 68 kB  |
 pg_default | postgres |                                          |                   |                 | 22 MB  |
 pg_global  | postgres |                                          |                   |                 | 667 kB |
(3 rows)

postgres=# select * from pg_tablespace where spcname='encrypted';
  oid  |  spcname  | spcowner | spcacl |   spcoptions
-------+-----------+----------+--------+-----------------
 24587 | encrypted |       10 |        | {encryption=on}
(1 row)

postgres=# select pg_rotate_encryption_key(24587);
 pg_rotate_encryption_key
--------------------------
 t
(1 row)

В Postgres Pro Enterprise ключи хранятся в каталоге ${PGDATA}/pg_encryption/keys. В целях безопасности все ключи этого файла преобразованы с помощью главного ключа, хранящегося в HashiCorp Vault.

Для настройки хранилища необходим адрес приёмника и токен экземпляра. Установка производится через переменные окружения, в качестве примера приведены VAULT_ADDR и VAULT_TOKEN:

echo VAULT_ADDR='http://127.0.0.1:8200' > /etc/env.d/99vault

echo VAULT_TOKEN="hvs.C77DySgOTjliYqmtp3yA4osP" >> /etc/env.d/99vault

Включит транзит с помощью HashiCorp Vault Transit Secrets Engine:

vault secrets enable transit

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

vault write -f transit/keys/pg-tde-master-key

По умолчанию HashiCorp Vault работает с 256-битными ключам. При необходимости работы с другими ключами обратитесь к администратору сервера HashiCorp Vault для изменения конфигурации.

Чтобы убедиться в верности конфигурации, запустите экспресс-тесты:

Если всё настроено правильно, в >${PGDATA}/pg_encryption/encryption_keys будут такие данные:

vault:v1:rdaF+sSfkKn9HBzdalat7mnynRRR6b00FQS159PCUMGmMZJYMNm/hWxbFFIeV8C43nO3UV4dmgn7pxnJkwo4IYq2+sUHSWT/

Предполагается, что HashiCorp Vault уже интегрирован вашей компанией и управляется администраторами. Однако в целях тестирования может понадобится отдельный экземпляр сервера с хранилищем, которое настроено специально под работу с Postgres Pro Enterprise TDE.

apt-get install -y wget net-tools apt-transport-https

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor > /tmp/hashicorp.gpg

mv /tmp/hashicorp.gpg /etc/apt/trusted.gpg.d/

chown root:root /etc/apt/trusted.gpg.d/hashicorp.gpg

chmod ugo+r /etc/apt/trusted.gpg.d/hashicorp.gpg

chmod go-w /etc/apt/trusted.gpg.d/hashicorp.gpg

echo "deb https://apt.releases.hashicorp.com $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/hashicorp.list

apt-get update

apt-get install vault

Vault v1.15.6, built 2024-09-17T15:25:10Z

systemctl enable vault --now

systemctl status vault

typeset -x VAULT_SKIP_VERIFY=true

api_addr                = "https://127.0.0.1:8200"
cluster_addr            = "https://127.0.0.1:8210"
cluster_name            = "local-vault-cluster"
disable_mlock           = true
ui                      = true

backend "raft" {
        node_id = "local-vault-server"
        path = "/var/lib/vault"
}

listener "tcp" {
        address = "[::]:8200"
        cluster_address = "[::]:8210"
        tls_cert_file = "/var/lib/vault/cert.pem"
        tls_key_file  = "/var/lib/vault/key.pem"
}

listener "tcp" {
        address = "127.0.0.1:8201"
        cluster_address = "127.0.0.1:8210"
        tls_disable = 1
}

openssl req -x509 -newkey rsa:4096 -sha256 -days 365 \

    -nodes -keyout /var/lib/vault/key.pem -out /var/lib/vault/cert.pem \

    -subj "/CN=localhost" \

    -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

vault operator init -key-shares=1 -key-threshold=1

vault operator unseal key

vault login token