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

Доступ и надежность При этом важно было учесть риск пря- мого доступа к данным в обход 1С. В таком сценарии администратор базы может под- ключиться к СУБД напрямую и выполнять операции с таблицами, не проходя через ограничения, заложенные в 1С. Этот риск мы закрывали на стороне самой СУБД. По сути, ограничили воз- можности прямой работы с данными: настроили разграничение прав, запре- тили неконтролируемые изменения таб- лиц и включили аудит всех структурных изменений. Для чувствительных данных дополнительно использовали ограниче- ния на уровне строк. Администраторов при этом перевели на работу через спе- циальные учетные записи с полным логи- рованием, чтобы любое действие можно было отследить. В результате админи- стратор управляет системой, но не имеет неконтролируемого доступа к данным. Пришлось выстраивать заново про- цесс обновлений. Мы перешли к регу- лярной схеме: плановые обновления – раз в квартал, критические – в течение 48 часов после выхода. При этом ни одно обновление не устанавливается сразу в продакшен. Сначала оно прохо- дит тестовый стенд, затем одну из реплик, и только после этого выпол- няется переключение. Для крупных обновлений используем отдельный кон- тур, чтобы заранее посмотреть, как система ведет себя под нагрузкой. Дополнительно мы ведем собственный репозиторий пакетов. Это позволяет проверять обновления на нашей конфи- гурации до внедрения и не зависеть от их готовности из коробки. В результате процесс стал более управляемым: мень- ше неожиданностей и понятнее, что именно меняется в системе. Вместе с этим изменилась и работа с уязвимостями. За счет более управляе- мого процесса обновлений среднее время их закрытия сократилось при- мерно до двух недель вместо прежних 30–60 дней. При этом ответственность разделена: ИБ следит за актуальностью и приоритетами, а ИТ внедряет обнов- ления и проверяет систему. Проверка эксплуатацией Основные сложности начали про- являться уже после запуска, когда систе- ма попала под реальную нагрузку. В первую очередь мы столкнулись со скрытыми зависимостями 1С от MS SQL. Они не мешали самой миграции, но влияли на поведение системы. Речь шла о вполне конкретных вещах: генерации идентификаторов, чувствительности к регистру при сравнении строк, механиз- мах анализа взаимных блокировок. Все это пришлось адаптировать на стороне СУБД – где-то через замену функций, где-то через настройку типов данных, где-то через подключение дополнитель- ных инструментов диагностики. Критич- ных несовместимостей, к счастью, у нас не оказалось, но все же разных нюансов накопилось достаточно много, и каждый из них требовал отдельного внимания. Следующий слой проблем был связан с планировщиком запросов. На части сложных отчетов 1С он выбирал не самые удачные планы выполнения, из- за чего время работы отдельных опера- ций могло вырасти кратно. Здесь уже приходилось разбираться глубже: ана- лизировать статистику, корректировать параметры и в отдельных случаях зада- вать подсказки, чтобы зафиксировать более стабильный вариант выполнения. Отдельной темой стал механизм обслуживания СУБД. При интенсивной работе 1С резко увеличивается количе- ство изменений в таблицах, и без допол- нительной настройки механизм очистки начинает работать неэффективно. В результате накапливается мусор, рас- тет фрагментация и проседает произво- дительность. Параметры пришлось под- бирать под реальную нагрузку и держать под постоянным контролем. Похожая ситуация возникла и с индек- сами. Их объем оказался больше ожи- даемого, а встроенных механизмов сжатия из коробки не нашлось. Для поддержания структуры в рабочем состоянии мы под- ключали дополнительные инструменты и выстраивали регулярное обслуживание. Наконец, пришлось заново собрать мони- торинг. Базового набора метрик оказалось недостаточно, поэтому сформировали свой: отслеживаем задержки репликации, бло- кировки, нагрузку на операции записи, состояние таблиц и процессы обслужива- ния. Пороговые значения и алерты настраи- вались уже не по рекомендациям, а по фактическому поведению системы. Вместе с архитектурой пришлось пере- собрать и операционные процессы. В первую очередь появилась отдельная роль аудитора базы данных – это позво- лило вынести контроль в самостоятель- ную функцию, а не размазать его между администраторами. Параллельно мы пересмотрели подход к резервному копи- рованию: ограничиваться созданием бэкапов оказалось недостаточно, поэто- му в регламент добавили регулярные тесты восстановления. Это сразу выяви- ло ряд нюансов, которые в обычной практике остались бы незаметными. Мы усилили контроль за обслужива- нием базы – в том числе за параметрами очистки и состоянием таблиц, поскольку именно эти аспекты напрямую влияют на стабильность под нагрузкой. Все изменения конфигурации теперь фиксируются и проходят через согласо- вание. Это добавило формальности, но заметно упростило разбор инцидентов: стало понятно, что и когда менялось, и какие последствия это могло вызвать. При этом ожидаемого конфликта между ИТ и ИБ не возникло. Скорее наоборот: ИБ получила реальные инстру- менты контроля, а ИТ – более предска- зуемую систему без скрытых ограниче- ний и неочевидного поведения. Итоги проекта Этот проект сложно назвать просто заменой СУБД. В результате система стала более прозрачной с точки зрения аудита, управляемой по доступу и устой- чивой к сбоям. В отдельных сценариях выросла и производительность – напри- мер, массовые расчеты ускорились более чем на 15%. При этом заметно выросли требования к эксплуатации. Система дает больше контроля, но требует более высокой квалификации команды и постоянного внимания к настройке. Даже без фактора импортозамещения такой переход выглядит оправданным – за счет про- зрачности, гибкости и возможности управлять безопасностью на уровне самой СУБД. Если бы мы повторяли проект, раньше подключили бы расширенный монито- ринг, уделили больше внимания нагру- зочным тестам типовых сценариев 1С и сразу настраивали бы параметры обслу- живания под реальную нагрузку. Главный вывод простой: безопасность и надежность 1С обеспечиваются не платформой по умолчанию, а правильно настроенной архитектурой и дисципли- ной в эксплуатации. l • 23 БЕЗОПАСНОСТЬ И НАДЕЖНОСТЬ 1С www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru Рисунок: архив СВФУ