← На главную

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

Однако, так ли надежна эта схема в условиях, когда у владельца базы остаются полные административные права на СУБД и саму платформу 1С? Проанализируем технические нюансы этой задачи, разберем ключевые уязвимости "однобазового" приватного блокчейна и выясним, какими способами владелец может незаметно изменить данные в обход любой проверяющей программы.

Уязвимость №1: Разделение документов и записей регистров (движений)

Для начала разберем, как платформа 1С строит отчеты и балансы. Абсолютное большинство отчетов (оборотно-сальдовые ведомости, взаиморасчеты, остатки на складах) формируются не по реквизитам документов, а по записям в регистрах накопления, регистрах сведений или регистрах бухгалтерии. Документ в данном случае выступает лишь в роли регистратора.

Если алгоритм блокчейна хэширует только реквизиты и табличные части самих документов, то злоумышленник с полными правами может легко обойти эту защиту:

1. Создается внешняя обработка, которая получает доступ к наборам записей регистров (например, через РегистрыБухгалтерии.Хозрасчетный или РегистрыНакопления.ВзаиморасчетыСКонтрагентами).
2. Для конкретного документа-регистратора напрямую изменяются движения: корректируются суммы, даты, счета или аналитика (субконто).
3. При этом сам объект документа (его реквизиты в таблицах СУБД) остается нетронутым. Его реквизиты Проведен, Дата, Номер и табличные части не меняются.

Выясним причину, почему проверяющая программа не заметит подлога. Программа считывает данные документа, вычисляет хэш — он совпадает с сохраненным в блокчейне. Однако реальные движения, влияющие на баланс предприятия и расчет пени или долгов, изменены. Блокчейн-журнал остается валидным ("зеленым"), а финансовый результат в базе уже другой.

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

Уязвимость №2: Косвенное изменение данных через Справочники (UUID vs Наименования)

Рассмотрим подробнее, как хранятся ссылки в документах 1С. Любой реквизит типа "СправочникСсылка" (например, Контрагент, Номенклатура или Договор) физически представляет собой уникальный идентификатор (GUID/UUID) — шестнадцатеричную строку. В документ записывается именно этот UUID, а не текстовое наименование "ООО Поставщик".

Если при формировании хэша документа используется этот идентификатор, то возникает критическая уязвимость:

1. В базе создается документ поступления товаров от "ООО Поставщик" (UUID: 12345678-abcd-ef01-...). Документ хэшируется, блок закрывается.
2. Спустя время владелец базы открывает карточку контрагента "ООО Поставщик" и переименовывает его в "ООО Рога и Копыта". Также меняются ИНН, КПП и банковские реквизиты в самом справочнике.
3. Сам документ поступления при этом не открывается и не перезаписывается. Его реквизит Контрагент по-прежнему ссылается на UUID 12345678-abcd-ef01-....

При очередной проверке программа считает данные документа. Ссылка на справочник осталась неизменной, хэш-сумма сойдется на 100%. Однако в любых отчетах, печатных формах и актах сверки вместо надежного поставщика теперь будет фигурировать совершенно другое юридическое лицо. Данные подменены без нарушения цепочки блокчейна.

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

Уязвимость №3: Ручные корректирующие операции ("Сторно")

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

Схема обхода выглядит следующим образом:

1. Есть первичный документ "Реализация товаров и услуг" от 01.07.2019 на сумму 100 000 рублей. Он внесен в блокчейн, его хэш проверен.
2. Владелец базы хочет уменьшить сумму этой операции до 10 000 рублей задним числом.
3. Вместо редактирования исходного документа, владелец создает новый документ ОперацияБух текущей датой (например, 05.08.2019). В движениях этой операции он делает сторнирующую запись на сумму -90 000 рублей, указывая в качестве аналитики тот самый исходный документ реализации.
4. Для проверяющей программы этот документ ОперацияБух выглядит как абсолютно новая транзакция текущего периода. Цепочка блокчейна не нарушена, старые хэши сходятся.

Однако конечный итог взаиморасчетов за июль поменялся. Проверяющий, ориентируясь на то, что "старые документы не менялись", пребывает в ложной уверенности, что июльские данные в безопасности. На самом деле их экономический смысл был полностью перекрыт новой операцией, которую легко пропустить в потоке новых документов.

Уязвимость №4: Административный доступ к СУБД и полный пересчет цепочки

Главный концептуальный недостаток приватного блокчейна в рамках одной базы данных — отсутствие распределенного консенсуса. В отличие от публичных сетей (Bitcoin, Ethereum), где блоки валидируются тысячами независимых узлов (нод), здесь база находится под полным контролем одного субъекта — владельца.

Если у владельца есть доступ уровня sa (System Administrator) к Microsoft SQL Server или PostgreSQL, на котором крутится база 1С, он может выполнить любую манипуляцию:

1. Владелец меняет дату или сумму в старом документе прямо в таблицах СУБД.
2. Поскольку хэш этого блока и всех последующих теперь "поплывет", запускается специальный SQL-скрипт (или обработка 1С), которая последовательно пересчитывает хэши всей цепочки, начиная с измененного документа и до самого последнего актуального блока.
3. Все новые хэши записываются в таблицу блокчейн-журнала.

Как отреагирует проверяющая программа? При следующем запуске она обнаружит, что последний хэш (ключ Y), сохраненный ею при предыдущей проверке, теперь не совпадает с тем, что находится в базе. Казалось бы, подлог обнаружен. Но у владельца базы всегда есть весомый административный контраргумент:

"Вчера произошел сбой оборудования (или отключение питания/сбой СУБД). База данных повредилась. Мы были вынуждены восстановить её из бэкапа трехдневной давности и заново перепровести документы за эти дни. Естественно, хэши пересчитались. Вот официальный лог технической службы."

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

Уязвимость №5: Атака "Фальсификация окружения" (динамическая подмена через API)

Проверяющая программа не работает с "воздухом", она должна считывать данные из базы владельца. Обычно это происходит через HTTP/веб-сервисы, COM-соединение или прямое чтение таблиц СУБД. Владелец, контролирующий инфраструктуру, может настроить систему так, чтобы она отдавала проверяющему "виртуальную реальность":

1. Владелец изменяет реальный документ в рабочей базе 1С.
2. Оригинальная (старая) версия документа и его правильный хэш сохраняются в скрытой служебной таблице.
3. На веб-сервере (IIS или Apache), через который программа проверки обращается к 1С, настраивается проксирование запросов. Как только система распознает запрос от IP-адреса проверяющего или от его учетной записи, код веб-сервиса подменяет измененные данные старыми значениями из скрытой таблицы.

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

Резюме и выводы

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

Чтобы сделать систему действительно прозрачной, необходимо:

• Использовать полноценную децентрализацию (копии базы данных должны одновременно храниться и синхронизироваться как у владельца, так и у проверяющего).
• Применять обязательное подписание каждого документа квалифицированной электронной цифровой подписью (ЭЦП) обеих сторон в момент совершения операции.
• Хэшировать не просто плоские таблицы документов, а полное состояние связанных регистров и срезы используемых справочников на момент проведения транзакции.