Цифровые репозитории научных публикаций — критически важный элемент инфраструктуры поддержки современной науки. Используемая тысячами организаций популярная открытая платформа DSpace претерпевает сегодня кардинальную модернизацию, вызванную необходимостью устранения критических уязвимостей безопасности [1] и замены устаревших зависимостей. Однако рекомендуемые сообществом стандартные процедуры обновления требуют прямого вмешательства в основную базу данных с использованием деструктивных операций. Для инфраструктур с высокими требованиями к доступности такой подход несет неприемлемые риски — любая ошибка оператора может привести к потере связей между объектами и невозможности быстрого возврата к рабочей версии. Более того, без полной пересборки текстовых индексов в системе будут сохраняться старые файлы, созданные еще уязвимой версией библиотеки Apache Tika, что оставляет возможность атаки даже после обновления ПО.

Требуется инструмент, исключающий влияние человеческого фактора при выполнении миграции, гарантирующий проверку целостности данных и автоматически устраняющий угрозы безопасности. Подход, основанный на подготовке изолированного контура, автоматической сверки хеш-сумм таблиц с принудительной регенерацией текстовых индексов позволяет нейтрализовать угрозы класса XXE (XML External Entity, внедрение внешних сущностей в XML), возникающие из-за уязвимостей в компонентах анализа контента (Apache Tika) и способные привести к несанкционированному доступу к файлам.

Архитектурная трансформация платформы DSpace

Платформа DSpace представляет собой сложную распределенную систему [2], архитектура которой базируется на двух критических компонентах. Первым из них является реляционная СУБД PostgreSQL [3] — единый источник сведений для всех метаданных и структуры коллекций. Жизненный цикл схемы — процесс изменения структуры базы данных (добавление новых таблиц, изменение типов полей, создание индексов), происходящий при обновлении платформы до новых версий, — контролируется системой управления версиями Flyway. Эта система гарантирует, что при переходе со старой версии на новую все изменения применяются строго последовательно и корректно. Физические файлы хранятся отдельно, а ссылки на них фиксируются в базе данных. Второй критический компонент архитектуры DSpace — поисковая подсистема Apache Solr, создающая инвертированные индексы для метаданных и содержимого документов.

Управление процессами осуществляет сервер на Java, а пользовательский интерфейс реализован как отдельное приложение на фреймворке Angular [4]. Обработка загруженных файлов, включая создание миниатюр и извлечение текста, выполняется с помощью библиотеки Apache Tika [1].

В сообществе пользователей DSpace стандарт де-факто — методика, предполагающая линейное выполнение вручную операций экспорта, очистки целевой среды и импорта данных [5], во время которых работа DSpace полностью прекращается. На целевом сервере выполняется операция очистки схемы базы данных командой database clean, которая безвозвратно удаляет все таблицы, подготавливая среду к восстановлению. Затем производится импорт дампа и запуск утилиты миграции схемы.

Для малых систем такая простая реализация имеет преимущества, однако при масштабировании до уровней корпоративной инфраструктуры этот метод имеет фундаментальные недостатки: длительное время простоя, так как экспорт, передача, очистка, импорт и миграция выполняются последовательно в период единовременной остановки сервиса; отсутствие возможности безопасного отката из-за необратимости операции очистки схемы. В случае сбоя система вообще оказывается в неработоспособном состоянии без возможности быстрого возврата. Сервис становится полностью недоступным для пользователей на время всех операций, что нарушает режим непрерывного доступа к научным данным: пользователи теряют возможность скачивания публикаций и загрузки новых материалов на весь период проведения работ. Кроме того, имеется риск скрытой потери целостности данных из-за отсутствия механизмов автоматической криптографической проверки после трансформации схемы, что позволяет ошибкам проникнуть в продуктивную среду. Серьезным упущением является и пассивный подход к безопасности в DSpace, при котором ранее сгенерированные текстовые представления, потенциально содержащие вредоносный код, сохраняются в системе при простом переносе дампа. Все эти риски усугубляются действием человеческого фактора — оператор может пропустить шаг проверки, ошибиться в команде или не заметить диагностические сообщения в логах.

Автоматическая миграция

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

Изолированный контур — это независимое вычислительное окружение (физический сервер или виртуальная машина) без связи с пользовательской сетью до момента финального ввода в эксплуатацию, использующее собственные диски и базы данных, изолированные от файлов работающей системы. Данное окружение служит полигоном (песочницей), на котором выполняются все рискованные операции: восстановление больших объемов информации, трансформация структуры базы данных, принудительная очистка файловых объектов и перестройка поисковых индексов. Деструктивные команды (очистка схемы, пересоздание таблиц) применяются только к копии данных внутри контура, оставляя нетронутой оригинальную базу данных репозитория. Ввод новой системы в промышленную эксплуатацию осуществляется путем переключения сетевого адреса только после успешного прохождения всех этапов контроля (сравнение количества записей в базе данных и документов в индексе Solr, проверка доступности документов по HTTP-запросам и корректности отображения метаданных).

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

Процесс миграции начинается с этапа инициализации: считывается конфигурационный файл, содержащий параметры подключения к источнику и цели, пути к хранилищам данных и настройки журналирования. Далее создается защищенный файл журнала, в котором фиксируется каждое действие системы с временной меткой. Затем формируется эталон на стороне источника: устанавливается соединение с базой данных действующей системы, выполняется выборка ключевых таблиц (метаданных, файловых объектов, структуры коллекций) и для каждой из них вычисляется агрегированная контрольная сумма по криптографическому алгоритму SHA-256, обладающему высокой стойкостью к коллизиям. Полученные значения сохраняются в структурированный JSON-файл — «Эталон целостности».

На этапе переноса данных приложение инициирует кратковременную остановку действующей системы (источника данных) — единственный этап, требующий простоя, — создает полный упакованный дамп базы данных и копирует каталог файлового хранилища. Затем дамп, файлы и ранее созданный «Эталон целостности» передаются в изолированный контур по защищенному каналу SSH.

Внутри контура программа автоматически устанавливает необходимое системное окружение и библиотеки (зависимости) платформы DSpace, создает пустую базу данных и загружает в нее данные из полученного дампа. Сразу после этого запускается утилита Flyway, которая приводит схему базы данных в соответствие с требованиями новой версии платформы.

На следующем шаге автоматически проверяется целостность — выполняется повторное вычисление контрольных сумм тех же таблиц в обновленной базе данных и их сверка с данными, зафиксированными в Эталоне, и при несовпадении хешей процесс прерывается: ошибка фиксируется в журнале, инициируется процедура отката (полное удаление созданной базы данных в изолированном контуре) и работа завершается с кодом ошибки.

Только после успешной проверки целостности запускается процедура очистки от уязвимостей класса XXE. Данная операция необходима для устранения следов вредоносного кода, который мог проникнуть в структуру документов на предыдущих этапах эксплуатации, когда файлы обрабатывались уязвимой версией библиотеки Apache Tika. Выполняется принудительная регенерация исключительно текстовых содержимых — все ранее извлеченные текстовые данные, сгенерированные уязвимой версией библиотеки Apache Tika, удаляются и заново формируются с использованием ее обновленной, безопасной версии. Данная процедура является разовой и выполняется только в момент перехода на новую версию платформы, она гарантирует полную очистку всего массива накопленных данных от потенциальных угроз. Такой подход позволяет исключить ресурсоемкую пересборку графических миниатюр, ограничив обработку только текстом, что существенно уменьшает время простоя. После этого производятся полная очистка поискового индекса Solr и его перестройка с нуля на основе верифицированных данных.

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

Безопасная миграция цифровых репозиториев
Схема алгоритма автоматизированной миграции

Апробация

Приложение использовалось при выполнении миграции репозитория ОИЯИ, попутно обнаружив и предотвратив нарушение целостности, выявив несовпадение контрольной суммы таблицы метаданных. После успешной миграции полное совпадение контрольных сумм подтвердило отсутствие потерь метаданных и разрывов связей между объектами. Принудительная регенерация текстовых файлов гарантировала устранение рисков, связанных с уязвимостями библиотеки Apache Tika. Обновленная версия платформы продемонстрировала прирост скорости выполнения поисковых запросов по сравнению с предыдущей версией, что было обусловлено использованием более производительной поисковой подсистемы и оптимизированными алгоритмами индексации в новом релизе DSpace.

***

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

Литература

1. CVE-2025-54988. Apache Tika XXE Vulnerability Details. — URL: https://nvd.nist.gov/vuln/detail/CVE-2025-54988 (дата обращения: 05.03.2026).

2. Бондяков А. С., Кондратьев А. О. Архитектура цифрового репозитория публикаций на платформе DSpace. Современные информационные технологии и ИТ-образование, [S.l.], v. 20, n. 3, p. 602–608, oct. 2024. ISSN 2411-1473. DOI: 10.25559/SITITO.020.202403.602-608.

3. Марк Ривкин. СУБД для высоконагруженных систем // Открытые системы.СУБД. — 2023. — № 2. — С. 17–23. URL: https://www.osp.ru/os/2023/02/13057166 (дата обращения: 05.06.2026).

4. Алексей Бондяков, Андрей Кондратьев. Визуализация данных цифрового репозитория // Открытые системы.СУБД. — 2025. — № 3. — С. 42–44. URL: https://www.osp.ru/os/2025/03/13059984 (дата обращения: 15.06.2026).

5. DSpace Documentation. Upgrading DSpace [Электронный ресурс]. — URL: https://wiki.lyrasis.org/display/DSDOC9x/Upgrading+DSpace (дата обращения: 05.03.2026).

Алексей Бондяков (aleksey@jinr.ru) — старший научный сотрудник, Андрей Кондратьев (kondratyev@jinr.ru) — младший научный сотрудник, Объединенный институт ядерных исследований (Дубна).

DOI: 10.51793/OS.2026.27.53.003