Миграция 1С на российскую СУБД: безопасность, надёжность и практические выводы
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС
Сайт: legascom.ru
Email: petukhov@legascom.ru
Переход 1С с Microsoft SQL Server 2017 на отечественную СУБД Tantor Postgres изначально задумывался как типовое импортозамещение по требованиям регулятора. Однако на практике проект трансформировал всю эксплуатационную модель: изменились подходы к безопасности, аудиту и обеспечению надёжности высоконагруженных систем.
Ключевые цели и подход к миграции
Основные требования к проекту были сугубо прикладными:
перенести 1,5 Тбайт данных без потерь;
избежать простоев в рабочее время;
сохранить или повысить производительность;
не нарушить действующие интеграции.
Чтобы минимизировать риски, от одномоментного переключения отказались. Перенос выполняли поэтапно: каждую базу перемещали в отдельное технологическое окно (чаще всего на выходных). Миграцию данных разбили на несколько проходов: сначала развернули целевую инфраструктуру, затем тонко настраивали параметры СУБД под профиль нагрузки 1С. Базовую конфигурацию для 1С дорабатывали вручную, адаптируя под реальные сценарии и объёмы.
После переноса проводили двойную проверку:
Целостность данных.
Прикладное поведение - прогоняли типовые операции (расчёт зарплаты, кадровые процессы, отчёты, обмены с внешними системами). При отклонениях возвращались к донастройке.
Разделение ролей и усиление безопасности
Важным результатом проекта стало чёткое разграничение зон ответственности:
1С отвечает за прикладную логику: роли на уровне метаданных, ограничения в бизнес‑процессах, журнал регистрации действий пользователей.
СУБД берёт на себя хранение данных, шифрование на диске, изоляцию сессий, сетевую аутентификацию, аудит изменений структуры.
На сторону СУБД сознательно делегировали часть функций безопасности: разграничение доступа между администраторами БД и прикладными пользователями, контроль DDL‑операций, аудит подключений, а также шифрование остаточных данных. Это позволило сместить контроль ближе к данным, а не к прикладной логике, и видеть не только действия пользователя в 1С, но и то, что реально происходило в базе.
Для исключения рассинхронизации использовали единую службу каталогов. Проблему избыточных прав в 1С решали отдельно: отказались от универсальных ролей, внедрили регулярный аудит назначений и инструменты анализа прав.
Сквозной аудит и наблюдаемость
Одним из главных достижений стал сквозной аудит: журнал 1С, логи СУБД и события ОС связали в единую цепочку через идентификаторы сессий и параметры подключения (в том числе correlation_id в application_name). Это даёт непрерывную связь «пользователь - действие - SQL‑запрос - изменение данных». Технически цепочка строится на сопоставлении session_id в 1С, backend_pid в СУБД и системных логах. Теперь расследование инцидента занимает несколько минут вместо часов.
Наблюдаемость системы заметно улучшилась: стало проще выявлять долгие запросы, блокировки, таблицы с высокой нагрузкой. Хотя часть этих возможностей в MS SQL была доступна «из коробки», в новой конфигурации сопоставимый уровень диагностики собрали самостоятельно - с помощью статистики запросов, расширений для анализа блокировок и ожиданий, логирования длительных операций. В результате получили более гибкую настройку под собственные сценарии.
Контроль доступа и защита от обходных сценариев
Критичным риском считался прямой доступ к данным в обход 1С: администратор БД мог подключиться к СУБД напрямую и выполнять операции с таблицами, минуя ограничения 1С. Для защиты на стороне СУБД:
настроили разграничение прав;
запретили неконтролируемые изменения таблиц;
включили аудит всех структурных изменений;
для чувствительных данных применили ограничения на уровне строк;
администраторов перевели на специальные учётные записи с полным логированием действий.
Таким образом, администратор сохраняет возможность управлять системой, но лишается неконтролируемого доступа к данным.
Обновления, уязвимости и операционные процессы
Процесс обновлений перестроили по регулярной схеме:
плановые - раз в квартал;
критические - в течение 48 часов после выхода.
Никакое обновление не попадает сразу в продакшен: сначала его тестируют на стенде, затем на одной из реплик, и только после этого выполняют переключение. Для крупных обновлений используют отдельный контур с нагрузочными тестами. Дополнительно ведут собственный репозиторий пакетов, чтобы заранее проверять совместимость с текущей конфигурацией.
Благодаря такому подходу среднее время закрытия уязвимостей сократилось примерно до двух недель (ранее составляло 30–60 дней). Ответственность разделили: ИБ отвечает за актуальность и приоритеты, ИТ - за внедрение и проверку системы.
Сложности при эксплуатации и их решение
После запуска под реальной нагрузкой проявились скрытые зависимости 1С от MS SQL: генерация идентификаторов, чувствительность к регистру при сравнении строк, механизмы анализа взаимных блокировок. Их адаптировали на стороне СУБД - через замену функций, настройку типов данных и подключение дополнительных инструментов диагностики.
Другие проблемные зоны:
Планировщик запросов. На сложных отчётах 1С выбирались неоптимальные планы выполнения, что кратно увеличивало время операций. Решали через анализ статистики, корректировку параметров и в отдельных случаях - через подсказки для фиксации стабильного плана.
Обслуживание СУБД. При интенсивной работе 1С растёт объём изменений в таблицах, и без настройки механизм очистки работает неэффективно: накапливается «мусор», растёт фрагментация, падает производительность. Параметры подбирали под реальную нагрузку и держали под постоянным контролем.
Индексы. Их объём оказался выше ожидаемого, а встроенных механизмов сжатия не хватало. Для поддержания структуры подключали дополнительные инструменты и выстроили регулярное обслуживание.
Мониторинг пересобрали под реальные потребности: отслеживают задержки репликации, блокировки, нагрузку на операции записи, состояние таблиц и процессы обслуживания. Пороговые значения и алерты настраивали не по рекомендациям, а по фактическому поведению системы.
Также пересмотрели операционные процессы:
ввели отдельную роль аудитора базы данных;
усилили регламент резервного копирования: помимо создания бэкапов, добавили регулярные тесты восстановления;
все изменения конфигурации теперь фиксируют и согласовывают - это упрощает разбор инцидентов.
Итоги и выводы
Проект нельзя рассматривать как простую замену СУБД. В результате система стала:
более прозрачной с точки зрения аудита;
управляемой по доступу;
устойчивой к сбоям.
В отдельных сценариях выросла производительность: например, массовые расчёты ускорились более чем на 15 %. При этом выросли требования к эксплуатации: система даёт больше контроля, но нуждается в высокой квалификации команды и постоянном внимании к настройке.
Если бы проект запускали заново, раньше подключили бы расширенный мониторинг, уделили больше времени нагрузочным тестам типовых сценариев 1С и сразу настраивали параметры обслуживания под реальную нагрузку.
Главный вывод: безопасность и надёжность 1С обеспечиваются не платформой по умолчанию, а правильно выстроенной архитектурой и дисциплиной в эксплуатации.
