Проверка целостности файлов Битрикс: как найти изменённые и лишние файлы

Проверка целостности файлов Битрикс помогает понять, какие файлы ядра и шаблона изменены, а какие появились лишними. Практический результат — таблица сверки с путями, эталоном, статусом, датой и решением, собранная на копии сайта. Действовать на продакшене без резервной копии и плана возврата нельзя.

Прямой ответ и границы задачи

Проверка целостности файлов Битрикс — это сравнение текущего состояния файлов с эталоном. Эталоном может быть дистрибутив той же версии, ранее снятая копия или верификационный файл, собранный штатным инструментом контроля целостности. Сравнение показывает три категории: файлы без изменений, изменённые файлы и лишние файлы, которых в эталоне не было.

Задача владельца или руководителя проекта — получить доказательства и решения, а не «починить всё сразу». Границы диагностики: работать на копии, не править ядро на работающем сайте, не отключать защиту ради удобства проверки. Если сайт заражён или под подозрением на вмешательство, сначала изолируют копию, затем исследуют.

Штатный инструмент контроля целостности недоступен в редакциях «Старт» и «Начало». Если инструмент недоступен, эталон собирают вручную: копия дистрибутива, архив файлов из резервной копии, снимок из системы контроля версий, если проект вёлся в репозитории. Способ проверки выбирают по доступным данным и критичности сайта.

Результат проверки — не приговор, а карта. Изменённый файл может быть штатной доработкой, а лишний — забытым тестовым скриптом. Решение по каждому пункту принимает ответственный: разработчик, администратор или подрядчик, а утверждает владелец проекта. Устранение найденного — отдельный объём работ, который планируют после диагностики.

Исходные данные и ответственные

До начала проверки фиксируют входные данные. Без них сверка превращается в спор о том, что считать нормой.

• Версия продукта и редакция: от них зависит доступность штатного инструмента контроля целостности.
• Список доработок: какие файлы ядра и шаблона правились штатно, кем и когда.
• Резервная копия файлов и базы, снятая до начала работ.
• Доступ к копии сайта, а не к продакшену, для всех операций сравнения.
• Перечень сторонних модулей и решений, установленных из Marketplace.
• Журнал работ подрядчиков: даты, задачи, зоны изменений.

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

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

Варианты и критерии выбора

Способ проверки выбирают по ситуации. Ниже — сравнение вариантов, которое помогает принять решение до начала работ.

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

Предметная последовательность действий

Порядок работ строится так, чтобы не потерять данные и не создать новую проблему.

Сначала снимают резервную копию файлов и базы. Копию разворачивают в изолированном окружении, отдельно от продакшена. Все дальнейшие действия выполняют только на ней. Если копию развернуть нельзя, проверку откладывают до появления подходящего окружения.

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

Далее выполняют сравнение. Фиксируют путь, эталонное состояние, текущее состояние, дату изменения и предполагаемое решение. Спорные файлы не удаляют и не правят сразу — их помечают и передают на подтверждение.

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

Матрица проверок

Матрица помогает не пропустить зоны и заранее определить, что считать нормой.

Матрица не заменяет полную сверку, но задаёт рамки. По каждой зоне заранее договариваются, какие изменения считаются штатными. Если по зоне нет ответственного, её проверяют в последнюю очередь и помечают как зону риска.

Учебный пример

Учебный пример. Компания с условным сайтом на Битрикс после обновления и работ подрядчика замечает нестабильность. Данные о компании и количестве объектов условны.

Входные условия: есть резервная копия недельной давности, журнал доработок велся неполно, штатный инструмент контроля целостности недоступен в используемой редакции. Продакшен трогать нельзя. Ответственный — администратор, утверждает решения владелец проекта.

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

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

Проверка результата: таблица сверки передана владельцу, по каждому пункту есть ответственный и решение. Устранение запланировано отдельным этапом с тестом на копии и планом возврата. Продакшен не изменялся. Если бы обнаружились признаки вмешательства, работу продолжил бы специалист по безопасности.

Чек-лист приёмки

• Резервная копия файлов и базы снята и проверена на восстановление.
• Все операции сравнения выполнены на копии, а не на продакшене.
• Эталон зафиксирован: дистрибутив, архив или верификационный файл.
• Таблица сверки содержит путь, эталон, статус, дату и решение.
• Изменённые файлы ядра сопоставлены с журналом доработок.
• Лишние файлы описаны и изолированы, а не удалены без подтверждения.
• По каждому пункту назначен ответственный и решение.
• Устранение вынесено в отдельный этап с тестом и планом возврата.
• Отчёт с доказательствами передан владельцу проекта.
• Признаки вмешательства переданы специалисту по безопасности.

Ограничения и типичные ошибки

Первая ошибка — проверять продакшен напрямую. Любое сравнение и удаление на работающем сайте создаёт риск. Правильный порядок: копия, резервная копия, тест, план возврата.

Вторая ошибка — считать любое изменение вредоносным. Штатные доработки тоже меняют файлы. Без журнала работ и подтверждения разработчика нельзя отличить норму от отклонения.

Третья ошибка — удалять лишние файлы сразу. Сначала их описывают, изолируют и согласуют решение. Иначе можно сломать обмен, интеграцию или отложенную задачу.

Четвёртая ошибка — игнорировать ограничения редакции. Штатный инструмент контроля целостности доступен не везде, и это указано в документации. Если инструмента нет, выбирают другой способ сверки, а не отключают защиту.

Пятая ошибка — смешивать диагностику и устранение. Проверка целостности файлов Битрикс даёт картину, а исправление — отдельный объём с приоритетами и тестами. Если нужен более широкий взгляд на проект, полезен технический аудит сайта на 1С-Битрикс, а для приёмки работ подрядчика — Аудит кода Битрикс: как проверить проект и принять работу.

Как оформить таблицу сверки

Таблица сверки — главный артефакт проверки. Она должна читаться без пояснений и позволять принять решение по каждому пункту.

Колонки: путь к файлу, эталон, статус, дата изменения, решение, ответственный. Статусы: без изменений, изменён, лишний, требует уточнения. Решения: оставить, вернуть к эталону, изолировать, передать на анализ.

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

Что делать после проверки

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

Каждое действие выполняют на копии, проверяют и только потом переносят на продакшен по согласованному плану. План возврата готовят заранее: если после изменения сайт работает неверно, возвращаются к резервной копии.

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

Если проект сложный и затрагивает несколько зон, разумно опираться на Аудит сайта на Битрикс: как проходит и что вы получите как на общую рамку, а проверку целостности проводить как отдельный этап. При подборе исполнителя помогает понимание, какие вопросы задавать: Собеседование Битрикс-разработчика: вопросы, практические задания и критерии оценки описывает практические критерии оценки.

Как выбрать периодичность и ответственного

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

Ответственный — не обязательно один человек. Администратор готовит копию и доступы, разработчик выполняет сверку, владелец утверждает решения. Важно, чтобы у каждого пункта таблицы был один ответственный за закрытие.

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