Введение

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

Архитектурная специфика объекта исследования

Эффективность разработки алгоритмов поиска механизмов сокрытия движений в среде «1С:Предприятие» напрямую обусловлена корректным учетом архитектурных особенностей данного программного комплекса как объекта судебной компьютерно-технической экспертизы. Как было обосновано в предшествующем исследовании [1], архитектура «1С:Предприятие» представляет собой многоуровневую систему, состоящую из технологической платформы (исполнительной среды) и настраиваемых прикладных решений (конфигураций), что обусловливает ее уникальность среди иных объектов СКТЭ. При этом ключевое значение для выбора инструментария и методик экспертного исследования имеет двойственный характер развертывания информационных баз: файловый (данные содержатся в едином файле «1Сv8.1CD») и клиент-серверный (с использованием внешних СУБД, таких как Microsoft SQL Server или PostgreSQL) [1].

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

Этапы экспертного алгоритма

На основе обобщения существующих методических подходов и с учетом архитектурной специфики, охарактеризованной выше, предлагается трехуровневая структура экспертного алгоритма поиска механизмов сокрытия движений в информационных базах «1С:Предприятие». Данный алгоритм интегрируется в общую логику производства СКТЭ, этапы которой были детализированы в предшествующей работе: изучение материалов дела и поставленной задачи, первичный анализ объекта, исследование состава и структуры данных, проведение инструментального исследования, формирование экспертного заключения [1].

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

Второй этап — анализ журнала регистрации и восстановление хронологии событий — служит верификации выявленных аномалий и установлению временных параметров вмешательства. Журнал регистрации, содержащий хронологически упорядоченные записи о действиях пользователей и системных событиях, позволяет реконструировать последовательность операций, идентифицировать участников процессов, а также сопоставить фактические временные метки внесения изменений с заявленными (например, выявить факты проведения документов «задним числом»). При этом, как справедливо отмечалось в научной литературе, критически важным является принцип неизменности цифрового доказательства [2], что требует работы не с исходным носителем, а с его битовой копией.

Третий этап — инструментальный анализ низкоуровневой структуры данных — применяется для обнаружения следов, не фиксируемых журналом регистрации или замаскированных на уровне прикладного кода. В зависимости от варианта развертывания информационной базы (файловый или клиент-серверный) используются соответствующие инструментальные средства: для файловых баз — анализ внутренней структуры файла «1Сv8.1CD» с использованием специализированных утилит, позволяющих извлекать удаленные записи и восстанавливать историю изменений таблиц; для серверных баз — прямой анализ системных таблиц и логов транзакций СУБД. На данном этапе выявляются такие артефакты, как: наличие записей с некорректными или противоречащими бизнес-логике реквизитами, признаки прямого внесения изменений в таблицы баз данных в обход прикладного кода, а также следы массовой модификации или удаления учетных записей.

Практическая апробация алгоритмов поиска

Для иллюстрации предложенных в предыдущем алгоритмов рассмотрим фрагмент реальной конфигурации на платформе «1С:Предприятие» (документ «ЗаказНаряд» в учёте автосервиса). В штатном (не модифицированном) виде процедура «ОбработкаПроведения» модуля объекта выглядит следующим образом:

Рис. 1. Типовой вариант исполнения кода отражения движений объекта метаданных «Документ.ЗаказНаряд»

Логика работы такова: если статус документа не «Закрыт» — движения очищаются, проведение отменяется; в противном случае формируются движения по трём регистрам накопления, выполняется контроль остатков.

На основе анализа судебной практики выделены два типовых механизма сокрытия движений, реализуемых путём модификации данного кода.

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

Рис. 2. Пример реализации механизма «условного пропуска движений»

В результате для указанного контрагента документ формально проводится (статус «Закрыт»), однако движения в регистры не записываются. ТМЦ не списываются, выручка не отражается.

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

Рис. 3. Пример реализации механизма «прямое удаление движений»

Контроль остатков при этом уже выполнен (дефицит не выявлен), а затем записи удаляются, что приводит к исчезновению учётных данных.

Для выявления описанных закладок применяется трехуровневый алгоритм, предложенный в предыдущем разделе. На первом уровне (анализ метамодели и кода) эксперт с помощью конфигуратора выполняет сравнение текущей конфигурации с эталонной (типовой или резервной копией), фиксируя наличие недокументированных условных переходов или операций записи наборов записей с параметром «Ложь» после штатного проведения. На втором уровне (анализ журнала регистрации) эксперт проверяет наличие событий проведения документов при отсутствии записей о движениях по соответствующим регистрам, а также выявляет расхождения между временем выполнения процедуры проведения и моментом последней модификации данных. На третьем уровне (низкоуровневый анализ данных) в зависимости от варианта развертывания базы эксперт либо анализирует внутреннюю структуру файла «1Cv8.1CD» с использованием специализированных утилит, либо выполняет SQL-запросы к системным таблицам транзакций (например, fn_dblog для MS SQL Server) для обнаружения следов удаления записей по конкретному регистратору.

Апробация алгоритма на предоставленном коде показывает, что при наличии модификации первого типа эксперт фиксирует расхождение между статусом документа (проведён) и отсутствием записей в таблицах регистров при одновременном обнаружении в коде недокументированного условного возврата. При модификации второго типа в логах транзакций СУБД обнаруживаются операции LOP_DELETE_ROWS по объектам регистров с идентификатором транзакции, соответствующим записи набора. В совокупности с отсутствием документального обоснования внесённых изменений данные признаки позволяют эксперту сделать категорический вывод о наличии недекларированной возможности, целенаправленно обеспечивающей сокрытие учётных записей, что имеет прямое доказательственное значение при расследовании экономических преступлений (ст. 159.6, 201 УК РФ).

Литература:

1. Климович, Л. П. Актуальные вопросы судебной компьютерно-технической экспертизы информационных баз «1С:Предприятие» / Л. П. Климович, С. А. Чубарь // Бизнес. Образование. Право. — 2026. — № 1(74). — С. 183–192. — DOI 10.25683/VOLBI.2026.74.1527. — EDN LDUDHV.
2. Ботвина В. В., Караваева А. В. Принцип неизменности объекта исследования при производстве судебной компьютерно-технической экспертизы // Modern Science. 2021. № 12–3. С. 143–147.
3. Радченко М. Г., Хрусталева Е. Ю. 1C:Предприятие 8.3: практ. пособие разработчика. М.: Э, 2016. 926 с