Контроль информации в базе на основе блокчейн

Публикация № 1120929

Технологии - Блокчейн

блокчейн контроль защита

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

В типовой конфигурации откройте "Администрирование"/"Дополнительные отчеты и обработки"

Нажмите кнопку: "Добавить из файла" и загрузите файл обработки.

Для запуска обработки, нажмите кнопку: "Выполнить"

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

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

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

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

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

Обработка тестировалась на платформе 1С:Предприятие 8.3 (8.3.13.1809)

Работает на управляемых формах

Более подробную информацию об использовании технологии блокчейн в 1С можно получить на ближайших вебинарах

//trueportal.ru/webinars/1179443/

//trueportal.ru/webinars/1179444/

Скачать файлы

Наименование Файл Версия Размер
Контроль информации в базе на основе блокчейн:
.epf 10,83Kb
24.01.20
0
.epf 10,83Kb Скачать

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Fox-trot 109 25.01.20 22:36 Сейчас в теме
имхо малость не хватает автоматизации процесса
а именно не хватает даты для автоматического закрытия периода, то есть автоматом создавать цепочку документов без участия оператора
или хотя бы при начальном создании образа
2. mkalimulin 382 26.01.20 11:53 Сейчас в теме
(1) Спасибо за замечание.
Да, я тоже думал о дате. И в итоге отказался от нее ради простоты решения. Но, в принципе, дата здесь уместна.
Действительно, можно при первом запуске включать в журнал не все документы, а только начиная с какой-то даты. Также проверка может идти не по всей базе, а только по "открытому" периоду. Надо только понимать, что это потребует более или менее серьезной доработки решения. К тому же, скорость работы на десятках и даже сотнях тысяч документов такова, что можно об этом не думать.
Не совсем понял насчет автоматизации. Контролера из процесса исключать нельзя, иначе теряется смысл.
3. DitriX 1781 26.01.20 17:16 Сейчас в теме
Направление то. Но реализация не очень. Мы используем эту технологию в реале, и там все выглядит по другому.
Например, при закрытии месяца - формируется хеш от хешей всех документов, а хеш документов берется только из значимых полей, например, комментарий - не значимое поле, сортировка в документе - не значимое событие и т.д.
И когда владельцу уходит отчет, то с ним же уходит и текущий хеш. И вот так, каждый день/месяц - владелец получает отчет с одной дополнительной строкой. И если, кто-то зади что-то поменяет из значимых вещей, в том числе - перенесет целиком документ в будущее или прошлое - система покажет что хешь отличается, и тогда начнутся вопросы - почему, кто менял и что произошло.
И ни в коем случае никаких секретов, абсолютно все знают что включена система чейнов, и что хрен что даже адми базы сможет сделать, так как в случае аудита, запускается обработка, и она тоже высчитывает все хеши, и если админ базы что то подмутил, то тогда он летит под все статьи, и об этом знает и знают все сотрудники.
Фишка чейна в том, что ВСЕ должны знать, но при этом НИКТО не может на это повлиять.
Terve!R; acanta; +2 Ответить
6. mkalimulin 382 26.01.20 18:19 Сейчас в теме
(3) Очень интересно. Где можно почитать о вашем проекте?
Насчет значимых полей - согласен. Но я специально так сделал, чтобы добиться максимальной простоты решения.
В моих предыдущих решениях была возможность настройки сериализации документов. Здесь же я решил, что нет особого смысла напрягать пользователя и заставлять его выбирать значимые поля. От того, что сериализоваться будут все сильно хуже не будет.
Насчет открытости, тоже полностью согласен. Когда я говорил о "секрете", я имел ввиду следующее.
Контролер может действовать двумя способами. Первый - он немного напрягается и записывает(или распечатывает) ключ. Натурально, на бумажку. А бумажку кладет в карман. Второй вариант - это когда ему лень возиться с запоминанием ключа. Тогда он "кладет в карман" не бумажку, а флэшку или внешний диск. "Секрет" так или иначе присутствует. Без него система не будет работать. И вашей системе он тоже есть.
4. vladimirmatancev 26.01.20 17:18 Сейчас в теме
Какая информация попадает в контроль? Реквизиты и ТЧ документа?
Как быть с записями в регистры?
5. mkalimulin 382 26.01.20 17:46 Сейчас в теме
(4) Реквизиты, ТЧ и движения.
7. ogidni 161 27.01.20 11:27 Сейчас в теме
Миша, в новых редакциях уже давно сущесвует мощная система версионирования.
Так что ваш "блокчейн" на штрих коде пачки беламорканала уже как бы не актуален.
8. mkalimulin 382 27.01.20 11:45 Сейчас в теме
(7) Версионирование - это такие же таблицы в базе данных. И защищены они точно так же, как и таблицы документов. Т. е. никак.
Fox-trot; +1 Ответить
9. mkalimulin 382 27.01.20 13:16 Сейчас в теме
(7) У вас каждый день 100 новых документов. И ещё 20 старых меняются. Чтобы отследить нарушения, вам потребуется СИСТЕМА контроля. Простая установка Версионирование вам не поможет. Как вы узнаете, где искать нарушение, используя Версионирование?
10. ogidni 161 27.01.20 13:19 Сейчас в теме
(9) Все ваши хеши - такие же таблицы. Пересчитать не проблема.
Ну я знаю вы это не когда не признаете - так как это вам не выгодно.
11. mkalimulin 382 27.01.20 14:29 Сейчас в теме
(10) Хеши - не таблицы. Криптоанархисту это должно быть известно)))
Таблицу можно поменять незаметно, а хэши нельзя.
13. ogidni 161 27.01.20 15:07 Сейчас в теме
(11) Если бы вы в этот хеш добавили ЭЦП.
1 .Скажем у вас есть закрытый пароль "123" хеш код этого пароля равен "304001" - это будет открытй ключ
2. Есть некая функция - к примеру:
z=3X(2)+xy+2y(2)-x-4y
3. экстремума этой функции будет Zmin = z(0;1) = -2
4. Зная открытый ключ можно узнать проверить валидность хеша(цепочки), имея лишь открытый ключ "304001 " используя функцию экстремума, но узнать содержимое нельзя
5. То что выше описал это подобие RSA, - если все это децентрализировать - будет блокчейн.
6. Если централизирвать будет Валидатор - или private chain

А что вы называете блокчейном - я не знаю
15. mkalimulin 382 27.01.20 15:58 Сейчас в теме
(13) Я не ставлю такую задачу. Проверять цепочку не зная ее содержимого. Зачем? Можете объяснить - где это может пригодиться в 1С?
16. mkalimulin 382 27.01.20 16:49 Сейчас в теме
(13) Wikipedia дает такое определение:

A blockchain, originally block chain, is a growing list of records, called blocks, that are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data.

У вас есть свой вариант?
17. ogidni 161 27.01.20 17:43 Сейчас в теме
(16)
tography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data.

Дя я уж понял что вы все из википедии учите
18. mkalimulin 382 27.01.20 18:28 Сейчас в теме
(17) Если вы знаете определение лучше, тогда дайте его сюда.
12. mkalimulin 382 27.01.20 14:32 Сейчас в теме
(10) Я, кстати, никогда не отрицал, что хэши можно пересчитать. Я отрицал только то, что это можно сделать незаметно. Но вы слово "незаметно" игнорируете. Потому что вам это не выгодно)))
14. ogidni 161 27.01.20 15:14 Сейчас в теме
(12)
Потому что вам это не выгодно)))

Я по 990 рублей за халтуру не беру. И картошку под видом манго не впариваю папуасам, во избежания дегенерации подобно вашей.
19. bmf 30.01.20 07:06 Сейчас в теме
Блокчейн это цепочка блоков, здесь же сравнивается хеш одного блока с его же хешем в прошлом. Тут до блокчейна, честно говоря, очень далеко.
Проверка неизменности предыдущих данных важна для контроля, какими средствами это делать вопрос другой. Наиболее ярко польза от блокчейна при открытости данных, где важно получить доверие к данным в истории, зависимости хеша блока от хеша предыдущего, сложности алгоритма расчета таких хешей и невозможности этот расчет повторить без значительных затрат.
Более того, при внедрении таких вещей важно наличие нескольких валидаторов и распределение блокчейна как такового по узлам.

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

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

И немного фантазии на тему блокчейна (не для обсуждения, просто мысли): "Куда придем через 5-7 лет": валидатором будет государство (ФНС, ЦБ или новая структура). Документы по сделкам, оплатам, чекам и все остальное будет в блокчейне. Сделки, не подтвержденные блокчейном, будут недействительны. Налоги начислят Вам раньше чем Вы увидите деньги на своем расчетном счете. 1С, как платформа учета, очень возможно останется, но будет по сути лишь средством ввода информации в блокчейн и формирования отчетов.
20. mkalimulin 382 30.01.20 09:37 Сейчас в теме
(19) Здесь используется именно цепочка блоков, в которой хеш очередного блока строится с учетом хеша предыдущего. И ровно это и называется блокчейном.
Когда я в декабре 2017-го делал первое решение, я использовал PoW по опыту биткоина. Но по результатам бурного обсуждения той разработки пришел к выводу, что это излишне. Точно так же, для обеспечения прозрачности не играет роли: будет ли ваша сеть состоять из многих узлов или только из одного.
Обо всем этом я подробно рассказываю на моих вебинарах:
https://infostart.ru/webinars/1179444/
https://infostart.ru/webinars/1185089/
https://infostart.ru/webinars/1185090/
21. bmf 03.02.20 07:36 Сейчас в теме
(20)
Точно так же, для обеспечения прозрачности не играет роли: будет ли ваша сеть состоять из многих узлов или только из одного

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

Если к книге есть доверие изначально, то тогда да, смысла плодить узлы нет. Только если узел один и, допустим, есть плавающий баг или просто модуль оперативки даже не ECC и что-то неправильно считается, то где гарантия что данные корректны?

Как обеспечить корректность данных, прозрачность и доверие к ним без повторного пересчета книги при условии сохранения той же коммерческой тайны и прочих персональных данных, - всего того, что в 1с обычно есть? Решение простое: повторный пересчет хешей данных внутри системы и сравнение с данными в книге хешей (блокчейна), распределенной между независимыми валидаторами... Это в идеале.

Впрочем, я далек от эспертного уровня в этом вопросе. Вебинар Ваш, скорее всего, даже физически не смогу посетить/послушать. Но вопрос доверия к данным - это основное, что может и должен решать блокчейн как цепочка блоков.
Если доверие есть по умолчанию, остается функция контроля истории изменений. Хеши по сути только упрощают сравнение, на крупных массивах данных эта экономия может и выстрелит. Хеш все равно пересчитывается. Если алгоритм хеширования проще сравнения напрямую, то да, это быстрее. Если нужен ответ что конкретно изменилось, все равно придется сравнивать части блоков...
22. mkalimulin 382 03.02.20 10:27 Сейчас в теме
(21) В случае с распределеным блокчейном речь идёт не о доверии, а о консенсусе. Их легко спутать, но это разные вещи. И самое главное - консенсус не всегда нужен. Если у вас один покупает, а другой продаёт, тогда - да, консенсус им необходим. А если у вас один кладовщик, а другой ревизор, то какой у них может быть консенсус?
Вебинары идут регулярно, несколько раз в месяц и в разное время. Надеюсь, вы сможете выбрать себе подходящее.
23. bmf 06.02.20 01:05 Сейчас в теме
(22) распределенную книгу подделать сложнее, поэтому к ней доверия больше.
Если один кладовщик, другой ревизор, то консенсус они легко достигнут списав запасы организации, а бонус с этого поделить. Задача обеспечить доверие к данным собственника этих запасов. Собственнику консенсус не очень нужен, ему бы правду.
Доверие к данным - вообще краеугольный камень любой учетной системы. Сколько работаю с предпринимателями - столько слышу про "это ваша программа не так считает". Разбираемся и смотрим где да что. Постепенно и доверие растет к программе и данным в ней. А тут хеши, цепочки и блоки... Собственник только одно спросит: данные правильные? И на основании этих данных примет решение. А если данные "ну вроде правильные, но по факту все могли пересчитать после вмешательства в блок и так -то перепроверять надо..." - относится к ним будут соответствующе.
24. mkalimulin 382 06.02.20 11:04 Сейчас в теме
(23) Правильно говорите. Доверие рождается из знания. Как только собственник разберется в несложном по большому счету процессе получения хэш-сумм, сам получит 32 байта, сам их распечатает и положит в карман, как только он это проделает, он навсегда забудет о распределенных реестрах. Зачем они ему? Никакой дополнительной безопасности они не дают. Хэш-суммы сверять надо и там и там. Плюс за публичный реестр придется платить, что немаловажно в данном вопросе.
Оставьте свое сообщение

См. также

1C и защищенное хранение данных на блокчейне: модуль интеграции от Acryl Platform

Инструменты и обработки Программист Расширение (cfe) v8 1cv8.cf Абонемент ($m) Защита и шифрование Блокчейн Расширения Прочие инструменты разработчика

Модуль интеграция 1С и блокчейн платформы "Acryl Platform" без использования внешних компонент. Под катом реализация механизмов Base58, Blake2b, Keccak, Curv25519 (the elliptic curve Diffie–Hellman) в подсистеме "Crypt", примеры генерации ключей, адресов, подписи транзакций, запись данных в блокчейн, чтение и восстановление данных из блокчейн. Код открыть. Лицензия MIT.

1 стартмани

21.01.2020    1902    ArtemSerov    9       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Пример реализации технологии Блокчейн в 1С 8.3

Отчеты и формы Программист Архив с данными v8 Абонемент ($m) Практика программирования Блокчейн

Конфигурация предназначена для простого и понятного описания технологии блокчейн. Имеется 2 вида документов: Приходная накладная и Расходная накладная. Их постоянно кто-то создает и пробует изменить. В документе Блокчейн хранится контрольная сумма каждого документа, и их тоже какое-то чужое лицо может изменить и поправить. Так в базе 1С хранится информация с нулевым уровнем доверия.

10 стартмани

26.01.2018    8369    astracrypt    2