Контроль целостности конфигурации и объектов БД

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

Описание

Контроль целостности данных — это функциональность, которая обеспечивает проверку целостности:

• конфигурации СУБД;
• конфигураций отдельных баз данных;
• программного кода СУБД;
• хранимых процедур внутри баз данных.

Функциональность выполняется при запуске системы и во время ее работы. В случае нарушения целостности объектов контроля происходит:

• разрыв всех текущих сессии;
• блокировка доступа всех пользователей, кроме администратора СУБД;
• информирование администратора СУБД о нарушении целостности объектов контроля путем логирования.

Администратору СУБД доступен API, позволяющий:

• добавлять объекты под контроль (при добавлении генерируются контрольные суммы и данные добавляются в файл);
• проверять целостность объектов контроля.

API представлено в виде SQL-интерфейса (функций, встроенный в ядро PostgreSQL).

Также реализована автоматическая проверка целостности по расписанию.

Функции API

Для работы с функциональностью предусмотрен ряд функций:

Имя функции	Входные параметры	Возвращаемое значение	Поведение функции	Пример
pg_integrity_check()	-	true/false	Осуществляет полную проверку целостности объектов контроля	SELECT pg_integrity_check();
pg_integrity_add_catalog(db_name, catalog_name)	db_name text (имя БД), catalog_name text (имя системного каталога)	true/false	Подсчитывает контрольные суммы для объектов БД, добавляет в файл конфигурации и изменяет общую подпись файла конфигурации	SELECT pg_integrity_check('postgres','pg_catalog.pg_proc');
pg_integrity_add_file(file)	file_check text (абсолютный путь к файлу)	true/false	Подсчитывает контрольные суммы для объектов типа файл, добавляет в файл конфигурации и изменяет общую подпись файла конфигурации	SELECT pg_integrity_add_file('/etc/pangolin-manager/postgres.yml');
pg_remove_file(file)	file_check text (абсолютный путь к файлу)	true/false	Удаляет указанный файл	SELECT pg_remove_file('/etc/pangolin-manager/postgres.yml');
pg_remove_catalog(db_name, catalog_name)	db_name text (имя БД), catalog_name text (имя системного каталога)	true/false	Удаляет каталог в БД	SELECT pg_remove_catalog('postgres','pg_catalog.pg_proc');

Подробнее о данных функциях в разделе «Функции контроля целостности» документа «Справочная информация».

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

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

Имя параметра	Допустимые значения	Установка параметра	Описание параметра
integrity_check_delay	от 1 секунды до 24 часов	Требуется перезагрузка БД. В случае конфигурации с KMS-сервером смена параметров возможна только через KMS	Период проверки (время ожидания) целостности объектов контроля в БД
integrity_check_wait	от 1 секунды до 24 часов	Требуется перезагрузка БД. В случае конфигурации с KMS-сервером смена параметров возможна только через KMS	Время ожидания работы worker (если под контроль добавлен большой объем данных, то время на полную проверку ограничивается этим флагом). При превышении этого времени происходит блокировка пользователей
integrity_check_select_wait	от 1 секунды до 24 часов	Требуется перезагрузка БД. В случае конфигурации с KMS-сервером смена параметров возможна только через KMS	Период запуска автоматической проверки контроля целостности объектов

Хранение конфигурационных файлов

Конфигурационные файлы с перечнем контролируемых объектов хранятся в каталоге /pgdata/{version}/data/pg_integrity, путь к ним прописан в коде. Файлы должны быть доступны для изменения только средствами СУБД.

Контрольные суммы объектов (подписи) должны храниться в конфигурационных файлах.

Формат конфигурационных файлов

Конфигурационные файлы имеют формат JSON.

Каждая подструктура в файле конфигурации соответствует одному отслеживаемому объекту. Каждый тип объекта имеет свой конфигурационный файл: integrity_files.json для файлов и integrity_relations.json для объектов БД. Файлы создаются при запуске и содержат пустую структуру и подпись. В файле содержится информация об объекте (путь) и контрольная сумма.

Формат файла конфигурации:

• пустой файл:

  {
  "integrity" : null
  }

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

  • файла:

  {
  "integrity" : [
  {
  "hash" : "{hash}",
  "name" : "/home/postgres/file_test1.bin",
  "type" : "file"
  }
  ]
  }

  • системного каталога:

  {
  "integrity" : [
  {
  "db" : "db_name",
  "hash" : "{hash}",
  "name" : "catalog_name",
  "type" : "relation"
  }
  ]
  }

Настройка

Описание алгоритма работы

Начало работы

При первом запуске СУБД создаются файлы для хранения подконтрольных объектов. Далее администратор СУБД при необходимости определяет набор защищаемых объектов и добавляет их в эти файлы средствами СУБД. При повторных запусках СУБД файлы не пересоздаются, а используются прежние файлы, но, в случае их удаления, они будут созданы вновь. Также при удалении файла во время работы СУБД администратор может их создать путем вызова функциональности добавления объектов под контроль (необходимо будет заново указать набор защищаемых объектов).

Защищаемые объекты

Защите могут подлежать файлы и системные каталоги (pg_proc). Для каждого объекта сохраняется контрольная сумма, посчитанная с использованием алгоритма SHA256. Сохраненные данные считаются эталонными. Администратор СУБД может изменять подконтрольные объекты и принудительно пересчитать контрольные суммы объектов.

Постановка объектов под контроль

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

Проверка целостности данных

Периодический контроль (от 1 секунды до 24 часов) и контроль по требованию администратора производится в отдельном процессе IntCheckLauncher. Данный процесс стартует при запуске СУБД, создает файлы для контролируемых объектов (в случае их отсутствия) и запускает первую проверку контроля целостности данных. Далее в процессе работы он запускает проверки с заданным в конфигурационном файле периодом и проверки по требованию администратора СУБД.

Чтобы выполнить проверку, процесс IntCheckLauncher запускает последовательно процессы проверки контроля целостности данных (IntCheckWorker) для файлов и каталогов в каждой базе данных.

Если процесс IntCheckWorker находит несоответствие контрольной суммы, не находит подконтрольный объект или не обнаруживает файл с подконтрольными объектами, то происходит блокировка СУБД.

Если процесс IntCheckWorker по каким-то причинам не сообщает о завершении проверки, то происходит блокировка СУБД и принудительное завершение процесса через сигнал SIGTERM.

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

Разблокировка базы данных

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

• добавлен под контроль проблемный объект с пересчетом контрольной суммы;
• восстановлен подконтрольный объект, если он был удален;
• полностью пересозданы JSON-файлы после их удаления и добавления новых объектов;
• перезапуск проверки, если это был системный сбой, связанный с временем ожидания IntCheckWorker и IntCheckLauncher.

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

примечание

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

Генерация контрольных сумм

Особенности:

• права на выполнение функции по умолчанию предоставлены только суперпользователям superuser (отсутствуют права на функцию у роли public). Для делегирования прав на выполнение отдельным пользователям или ролям необходимо использовать команду:

  GRANT EXECUTE ON FUNCTION <function_name>(<type_parameter>) TO <username>;

• администратор СУБД всегда имеет доступ к функциям API;

• в случае защиты файлов требуется указывать абсолютный путь;

• в случае защиты файлов при расчете контрольной суммы учитывается и содержимое файла, и его атрибуты, например, -rw-r--r-- postgres postgres.

Управление

Кластерная конфигурация

Контроль целостности объектов на реплику работает независимо от мастера.

Обеспечение безопасности хранимых данных

В случае, если при обновлении подконтрольные объекты изменились, то произойдет отключение всех пользователей без прав суперпользователя. Требуется вмешательство администратора СУБД.

События аудита

При ошибках выводятся сообщения в лог аудита в соответствии с решением описанным в разделе «Журналирование и аудит».