Модуль безопасного хранения QSS

QSS (Quantum Secure Storage), модуль безопасного хранения СУБД «Квант-Гибрид», позволяет создавать таблицы, которые шифруются с помощью криптоалгоритма «Кузнечик» (ГОСТ 34.1-2015) в режиме MGM (Р 1323565.1.026–2019) при записи на диск.



Описание

Шифрование осуществляет отдельное программное обеспечение — средство криптографической защиты (СКЗИ) Quantum Secure Storage (QSS).

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

Сервер QSS можно устанавливать как одновременно с QHB, так и после, т. е. QSS можно установить и начать использовать, когда QHB уже находится в эксплуатации.

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

Подробную информацию о том, как устанавливать, настраивать QSS и создавать в нем ключи, см. в документации к QSS.



Использование

Возможности

Шифрование происходит на уровне отдельных таблиц. Включение шифрования таблицы включает также шифрование индексов этой таблицы, связанной таблицы TOAST и сообщений WAL о действиях в этой таблице. Тем не менее столбцы определенных типов, хранящиеся не в основном файле таблицы и не в TOAST (например, большие объекты (LOB), тип rbytea), будут незашифрованными.

Информацию о том, как включить шифрование RBytea, см. в описании расширения Rbytea.

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

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

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

ВАЖНО!
Если у зашифрованной таблицы есть DEFAULT CONSTRAINT, то значение по умолчанию хранится в каталоге в незашифрованном виде. То же самое и для текста триггеров, заполняющих шифрованную таблицу.

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

Данные на диске и в кеше операционной системы зашифрованы (и это является преимуществом по сравнению с шифрованием на уровне диска), данные в памяти QHB не зашифрованы, так как к ним нужен оперативный доступ.

Не поддерживается копирование шифрованной таблицы из базы-шаблона в новую базу во время CREATE DATABASE; в частности, нельзя создавать шифрованные таблицы в базе template1.


Конфигурационные параметры

Настройки QSS находятся в отдельном конфигурационном файле qss2_config.toml; пример файла генерируется при инициализации кластера (при помощи расширения initdb).

  key = "key_name" # идентификатор ключа, существующего в QSS, которым будет производиться шифрование
  shmem = true # будет ли шифрование проводиться через разделяемую память
  provider = "compressed-append" # "compressed-append" или "two-phase" - способ хранения атрибутов nonce, tag шифрованных страниц в файлах QHB
  socket_address = "/run/qss/client.socket" # для связи с сервером qss; при установке QSS по умолчанию менять не будет необходимости

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

В основном конфигурационном файле использование QSS включается параметром

qss_mode = 2 # По историческим причинам это целочисленный параметр, допустимые значения 2 и 0
  • При запуске с qss_mode = 2 проверяется корректность настройки QSS, и если обнаруживаются какие-либо проблемы, то QHB не запускается.

  • Запуск с qss_mode = 0, когда есть зашифрованные таблицы, разрешен, но обратиться к зашифрованным таблицам будет невозможно.


Создание таблицы

При создании таблицы или материализованного представления нужно указать предложение using qss.

create table tab_qss(c1 int, c2 text) using qss;

create materialized view mat_view_qss using qss as
    select c1, string_agg(c2, ','), count(1) from tab_qss group by c1;

Превратить уже созданную таблицу в зашифрованную или наоборот (с помощью ALTER TABLE) нельзя.


RBytea

Модуль RBytea позволяет создавать столбцы типа RBytea.

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

Параметр

rbytea.filesystem_qss_mode = 2

При qss_mode = 0 значение этого параметра игнорируется.

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

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


Шифрование статистик

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

После этого статистики помещаются вместо таблиц каталога pg_statistic, pg_statistic_ext_data в аналогичные шифрованные таблицы qss_statistic, qss_statistic_ext_data. Статистики нешифрованных таблиц тоже будут храниться там.

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

  • запустить VACUUM ANALYZE;
  • подождать, пока тоже самое сделает автовакуум (т.е. если ничего не делать, то статистики соберутся "сами");
  • скопировать имеющиеся статистики запросом, чтобы не ждать VACUUM ANALYZE:
    delete from qss_statistic;
    insert into qss_statistic select * from pg_statistic;
    delete from qss_statistic_ext_data;
    insert into qss_statistic_ext_data select * from pg_statistic_ext_data;
    
    (При выключении qss_encrypt_statistic копирование в обратную сторону.)

После включения шифрования статистик рекомендуется удалить нешифрованные

delete from pg_statistic;
delete from pg_statistic_ext_data;

ВНИМАНИЕ
Таблицу pg_statistic_ext трогать не надо ни в каких сценариях!



Обслуживание

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

Примечание
К данным операциям применимы общие рекомендации по ETL (Extract, Transform, Load — извлечение, преобразование, загрузка).

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


Смена ключа

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

  1. Расшифруйте все данные.
  2. Убедитесь в отсутствии зашифрованных таблиц.
  3. Если использовались зашифрованные статистики, то эти данные надо удалить: выключить qss_encrypt_statistic, потом выполнить:
    truncate table qss_statistic;
    truncate table qss_statistic_ext_data;
    
    (truncate table можно делать шифрованным таблицам и при выключенном QSS).
  4. Создайте другой ключ в QSS, запишите этот ключ в файл qss2_config.toml и перезапустите QHB.
  5. Снова зашифруйте таблицы.
  6. Опционально включить шифрование статистик.

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


Миграция с QSS 1.0

Миграция с QSS версии 1.0 будет производиться одновременно с миграцией на другую версию QHB. Нужно расшифровать все таблицы, провести миграцию, затем снова зашифровать таблицы.


Создание резервной копии

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

Резервную копию рекомендуется создавать с помощью утилиты qbackup. При этом резервная копия создается обычным способом, однако не рекомендуется использовать потоковое резервное копирование с указанием wal-method=stream. Для формирования зашифрованной потоковой резервной копии требуется наличие непрерывной архивации WAL и потокового резервного копирования в режиме wal-method=fetch или wal-method=none.

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

Подробную информацию см. в документацию по QSS.


Репликация

На каждом узле необходим свой сервер QSS. У каждого узла будет свой ключ, при этом имена ключей могут совпадать, поскольку сами они все равно будут разными. Это позволит иметь на всех узлах идентичные файлы qss2_config.toml.

Допустимы следующие варианты (см. раздел Сравнение различных решений) репликации:

  • Потоковая репликация (синхронная и асинхронная)
  • Логическая репликация
  • Репликация основной-резервный на основе триггеров
  • Репликация на основе SQL в ПО промежуточного слоя (через репитер запросов и т. п.)

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

  • На разделяемых дисках (сетевой диск или репликация на уровне FS)
  • Доставка журналов упреждающей записи

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

ВАЖНО!
Подключить узел к потоковой репликации можно, только пока нет зашифрованных таблиц. В том числе не должно быть включено шифрование статистик, таблицы qss_statistic и qss_statistic_ext_data пустые.



Особенности и ограничения шифрования в QHB

  • Отсутствие возможности зашифровать и расшифровать (с помощью команды ALTER TABLE) уже созданную таблицу.

  • При шифровании RBytea нельзя хранить данные этого типа в единственном экземпляре для нескольких узлов кластера на сетевом хранилище.

  • Перешифрование возможно только путем расшифрования и повторного шифрования.

  • Отсутствие возможности загружать данные в зашифрованные таблицы с помощью модуля QDL.

  • Восстановление резервной копии возможно только на тот же хост, с которого она была сделана.

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

  • Отсутствие возможности зашифровать партиционированные таблицы.

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

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

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

  • База, в которой есть шифрованные таблицы, не может быть использована как шаблон в CREATE DATABASE.