Журнал "Information Security/ Информационная безопасность" #2, 2026

Контур использования 1С в нашем уни- верситете большой и неоднородный: около 20 тыс. студентов и порядка 3 тыс. сотруд- ников, распределенная структура с учеб- ными подразделениями (факультетами и институтами), научно-исследовательскими институтами, колледжами, лицеем и филиалами. Внутри – три ключевые систе- мы 1С, включая расчет заработной платы и кадровый учет, около 200 рабочих мест и интеграции с государственными систе- мами, в том числе с ГИИС УОФ "Элек- тронный бюджет". Общий объем данных, хранимых в СУБД – порядка 1,5 Тбайт. В такой конфигурации любая ошибка – это уже не локальный сбой, а остановка операционной деятельности. Требования для проекта перевода 1C на российскую СУБД Tantor Postgres были предельно прикладными. Данные нужно было перенести без потерь, не допустить простоев в рабочее время, сохранить или повысить производитель- ность и не сломать интеграции. При этом основной триггер проекта был, конечно, регуляторный – курс на импор- тозамещение и требование использовать СУБД из реестра отечественного ПО. Все остальные задачи – производные. Важно, что к моменту начала проекта у университета уже был опыт импорто- замещения на других слоях инфраструк- туры: использовались отечественные ОС, средства виртуализации, системы управления доступом и удаленных рабо- чих мест. Это снизило организационные риски, но не убрало технические. От сценария одномоментного пере- ключения мы отказались сразу – слиш- ком велики риски. Мы разбили перенос на этапы и шли от системы к системе последовательно. Каждую базу перено- сили в отдельное технологическое окно, как правило на выходных. Это позволяло не затрагивать рабочие процессы и лока- лизовать возможные проблемы. Миграцию 1,5 Тбайт данных разделили на несколько проходов. Сначала подни- мали целевую инфраструктуру, затем настраивали параметры СУБД под про- филь нагрузки 1С. В качестве базовой точки использовали преднастроенную кон- фигурацию для 1С, но практически сразу пришлось уходить в ручную настройку – под конкретные сценарии и объемы. После переноса мы проводили двой- ную проверку. Сначала – на уровне целостности данных. Затем – на уровне прикладного поведения. Прогоняли рас- чет зарплаты, кадровые операции, типо- вые отчеты, обмены с внешними систе- мами. Там, где появлялись отклонения по времени или результатам, возвра- щались к настройке. Переход оказался не равномерным по времени. На отдельных этапах при- ходилось откатываться, корректировать параметры и повторять прогоны. Это удлиняло сроки, но позволяло не пере- носить проблемы в промышленную экс- плуатацию. Границы ответственности До миграции роли 1С и СУБД в части безопасности и эксплуатации были не до конца разделены. После перехода их пришлось четко определить. 1С стала отвечать за прикладную логику: роли на уровне метаданных, ограничения в биз- нес-процессах и журнал регистрации действий пользователей. СУБД взяла на себя хранение данных, шифрование на диске, изоляцию сессий, сетевую аутентификацию и аудит изменений структуры. Часть функций безопасности была сознательно делегирована на сто- рону СУБД. В первую очередь это раз- граничение доступа между администра- торами БД и прикладными пользовате- лями, аудит подключений и контроль DDL-операций. Отдельно было включено шифрование остаточных данных. Такое разделение дало практический эффект. Контроль сместился ближе к данным, а не к прикладной логике. Появилась возможность проверять не только действия пользователя в 1С, но и то, что реально происходило в базе. Важным условием была согласован- ность ролей. За счет использования единой службы каталогов рассинхрони- зации между 1С и СУБД не возникло. При этом проблему избыточных прав в 1С пришлось решать отдельно: отказ от универсальных ролей, регулярный аудит назначений, использование встроенных инструментов анализа прав. Первый заметный эффект после запуска – изменение наблюдаемости. Стало проще отвечать на вопросы, кото- рые раньше требовали косвенных оце- нок. Мы начали видеть, какие именно запросы выполняются слишком долго, где возникают блокировки, какие таб- лицы создают нагрузку. В MS SQL часть этих возможностей была доступна из коробки. В новой кон- фигурации сопоставимый уровень диаг- ностики пришлось собирать самим. Использовали статистику запросов, рас- ширения для анализа блокировок и ожи- даний, логирование длительных операций. Вначале это воспринималось как услож- нение, но в процессе стало понятно, что гибкость настроек стала выше. Теперь мы смогли настроить диагностику под свои сценарии, а не под стандартную модель. Полезнейшим достижением стал сквозной аудит. Мы связали журнал 1С, логи СУБД и события ОС. Для этого использовали идентификаторы сессий и параметры подключения, включая передачу correlation_id через application_name. В результате появилась непрерывная цепочка: пользователь – действие – SQL-запрос – изменение данных. При инциденте мы идем по ней сверху вниз и расследуем всю картину. Технически это реализовано через сопоставление session_id в 1С, back- end_pid в СУБД и системных логах. Время восстановления всей цепочки – всего нескольких минут. Ранее на это уходили часы. 22 • СПЕЦПРОЕКТ 1С на новой СУБД с точки зрения безопасности и надежности ы входили в проект миграции высоконагруженных систем 1С с Microsoft SQL Server 2017 на российскую СУБД как в типовое импортозамещение. Изначально задача формули- ровалась как замена одного продукта другим в рамках требо- ваний регулятора. Но на практике проект изменил всю экс- плуатационную модель 1С и СУБД и дал нам возможность пересмотреть, как именно обеспечиваются их безопасность и надежность наших систем. М Петр Иванов, проректор по цифровому и технологическому развитию, Северо-Восточный федеральный университет имени М.К. Аммосова Фото: СВФУ