КОНТРОЛЬ ФИЗИЧЕСКОЙ ЦЕЛОСТНОСТИ ДАННЫХ КОРПОРАТИВНЫХ БАЗ ДАННЫХ ПОСРЕДСТВОМ МЕТОДОВ УДАЛЁННОГО АУДИТА

АННОТАЦИЯ

В статье описывается процесс разработки веб-приложения для удалённого мониторинга физической целостности данных в корпоративных системах управления базами данных. Рассмотрены уровни целостности данных в реляционных СУБД, обоснован выбор физического уровня контроля и комбинированного метода аудита, объединяющего механизмы real-time обнаружения изменений на основе паттерна Publisher-Subscriber с периодической сверкой. Представлена архитектура приложения, реализованного на языке Go с поддержкой алгоритмов SHA-256 и отечественного Стрибог (ГОСТ 34.11-2018), а также пользовательский интерфейс на HTML/CSS/JavaScript. Приложение обеспечивает независимый аудит целостности по модели Zero Trust, поддерживает интеграцию с корпоративными системами оповещения через email и webhook, а также адаптировано для применения в среде с требованиями информационной безопасности ФСТЭК.

Ключевые слова: целостность данных, физическая целостность, мониторинг баз данных, PostgreSQL, LISTEN/NOTIFY, хэширование, Стрибог, SHA-256, Zero Trust, корпоративная ИТ-инфраструктура.

Введение

В современных корпоративных ИТ-инфраструктурах системы управления базами данных (СУБД) выступают фундаментальным элементом, от надёжности и корректности работы которого зависит функционирование всего предприятия. Любое несанкционированное или непредвиденное изменение данных может привести к серьёзным последствиям — от финансовых потерь до юридических рисков и ущерба репутации. Несмотря на широкое разнообразие встроенных механизмов обеспечения целостности в современных СУБД, они функционируют на логическом уровне и не обеспечивают независимого внешнего контроля. В условиях растущих требований к информационной безопасности, особенно в контексте модели доверия Zero Trust, возникает необходимость в создании независимых систем мониторинга целостности данных.

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

Обзор уровней целостности данных

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

• Целостность сущностей гарантирует уникальность каждой записи в таблице посредством первичного ключа (Primary Key).
• Ссылочная целостность обеспечивает корректность связей между таблицами через внешний ключ (Foreign Key), предотвращая появление «сиротских» записей.
• Доменная целостность контролирует тип данных и допустимые значения столбцов.
• Транзакционная целостность основана на принципе ACID — атомарности, согласованности, изоляции и надёжности транзакций, обеспечивая корректность изменений даже при параллельном выполнении и системных сбоях.
• Пользовательская целостность (бизнес-логика) описывает правила, специфичные для конкретной предметной области.
• Физическая целостность защищает данные на уровне устройств хранения посредством механизмов репликации, контрольных сумм и упреждающего журналирования (Write-Ahead Logging).

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

Обоснование выбора методов аудита

Для удалённого аудита целостности данных был рассмотрен паттерн Publisher-Subscriber (Издатель-Подписчик), реализованный в PostgreSQL через механизмы LISTEN и NOTIFY. Клиентская сессия отправляет команду LISTEN, регистрируя интерес к именованному каналу. При возникновении события, триггер или процедура внутри СУБД выполняет NOTIFY, рассылая текстовое уведомление всем подписанным сессиям. Этот подход обеспечивает реакцию в реальном времени при минимальной нагрузке на базу данных.

Вместе с тем, механизм LISTEN/NOTIFY имеет ограничения: уведомления не сохраняются, и при недоступности сервиса в момент события информация может быть утеряна. Для компенсации этого недостатка в приложении реализован комбинированный подход, объединяющий мониторинг в реальном врменеи через триггеры и NOTIFY с периодическим опросом для регулярной сверки хэш-значений отслеживаемых таблиц. Если один из механизмов даёт сбой, другой компенсирует этот недостаток, обеспечивая максимальную надёжность.

Архитектура приложения

Приложение «Контролёр БД» построено по принципу клиент-сервер и состоит из бэкенда на языке Go и фронтенда на HTML/CSS/JavaScript.

Бэкенд реализует четыре ключевых модуля:

1. Модуль интеграции, который добавляет в БД необходимые триггеры или процедуры для вычисления хэш-значений. Он поддерживает два алгоритма: SHA-256 — универсальный алгоритм, повсеместно поддерживаемый различным программным обеспечением; и Стрибог (ГОСТ 34.11-2018) — отечественный алгоритм для соответствия требованиям ФСТЭК.
2. Модуль прослушивания асинхронно обрабатывает уведомления NOTIFY от отслеживаемых таблиц.
3. Модуль периодического аудита по настраиваемому таймеру запрашивает и сравнивает хэши всех отслеживаемых таблиц.
4. Модуль уведомлений доставляет оповещения о нарушениях через email (SMTP) и webhook (HTTP).

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

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

Результаты и практическое применение

Разработанное приложение обеспечивает независимый контроль физической целостности данных по модели Zero Trust, не завися от встроенных механизмов самой СУБД. Комбинированный подход мониторинга — в реальном времени через триггеры и LISTEN/NOTIFY с периодическим опросом — позволяет выявлять нарушения с минимальной задержкой и при этом обнаруживать инциденты, которые могли быть пропущены при сбое одного из механизмов. Поддержка обоих алгоритмов хэширования, SHA-256 и Стрибог, делает приложение применимым как в универсальных, так и в средах, с повышенными требованиями к информационной безопасности.

Практическое применение решения охватывает контроль целостности критически важных корпоративных баз данных, мониторинг рассинхронизации реплик, а также обеспечение соответствия требованиям ФСТЭК в организациях, работающих под регуляторным контролем.

Заключение

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

Список литературы:

1. Цветков, Н. В. PostgreSQL. Руководство разработчика / Н. В. Цветков. — СПб.: Питер, 2021. — 608 с.
2. Столлингс, К. Криптография и безопасность сетей / К. Столлингс. — 7-е изд. — М.: Вильямс, 2020. — 960 с.
3. ГОСТ Р 34.11-2018. Информационная технология. Криптографическая. Алгоритм хеширования «Стрибог» Текст. — М.: Стандартинформ, 2019. — 12 с.
4. Кондалков, А. А. Транзакции и восстановление в базах данных: принципы ACID Текст / А. А. Кондалков. — Новосибирск: Сибирское научное издание, 2021. — 180 с.
5. Макивора, Д. Построение распределённых систем на языке Go / Д. Макивора, Э. Бондаренко. — СПб.: Питер, 2022. — 384 с.
6. PostgreSQL Documentation: LISTEN and NOTIFY Электронный ресурс. — Режим доступа: https://www.postgresql.org/docs/current/sql-listen.html