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

19.08.21

Разработка - Математика и алгоритмы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

//infostart.ru/webinars/1179443/

//infostart.ru/webinars/1179444/

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

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    1753    stopa85    12    

33

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    4416    user1959478    50    

34

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

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

1 стартмани

09.06.2023    7458    4    SpaceOfMyHead    17    

56

Блокчейн и безопасность данных в 1С

Информационная безопасность Бесплатно (free)

Безопасность данных – обширная тема со множеством задач. О том, как избежать подмены данных и с помощью технологии блокчейн контролировать изменения в системе, на митапе «Безопасность в 1С» рассказал Михаил Калимулин.

13.05.2022    2345    mkalimulin    19    

12

Модель распределения суммы по базе

Математика и алгоритмы Платформа 1С v8.3 Россия Абонемент ($m)

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

1 стартмани

21.03.2022    7855    7    kalyaka    11    

44

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021    4444    fishca    13    

36

Интересная задача на Yandex cup 2021

Математика и алгоритмы Бесплатно (free)

Мое решение задачи на Yandex cup 2021 (frontend). Лабиринт. JavaScript.

12.10.2021    8834    John_d    73    

46
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Fox-trot 156 25.01.20 22:36 Сейчас в теме
имхо малость не хватает автоматизации процесса
а именно не хватает даты для автоматического закрытия периода, то есть автоматом создавать цепочку документов без участия оператора
или хотя бы при начальном создании образа
2. mkalimulin 1148 26.01.20 11:53 Сейчас в теме
(1) Спасибо за замечание.
Да, я тоже думал о дате. И в итоге отказался от нее ради простоты решения. Но, в принципе, дата здесь уместна.
Действительно, можно при первом запуске включать в журнал не все документы, а только начиная с какой-то даты. Также проверка может идти не по всей базе, а только по "открытому" периоду. Надо только понимать, что это потребует более или менее серьезной доработки решения. К тому же, скорость работы на десятках и даже сотнях тысяч документов такова, что можно об этом не думать.
Не совсем понял насчет автоматизации. Контролера из процесса исключать нельзя, иначе теряется смысл.
3. DitriX 2091 26.01.20 17:16 Сейчас в теме
Направление то. Но реализация не очень. Мы используем эту технологию в реале, и там все выглядит по другому.
Например, при закрытии месяца - формируется хеш от хешей всех документов, а хеш документов берется только из значимых полей, например, комментарий - не значимое поле, сортировка в документе - не значимое событие и т.д.
И когда владельцу уходит отчет, то с ним же уходит и текущий хеш. И вот так, каждый день/месяц - владелец получает отчет с одной дополнительной строкой. И если, кто-то зади что-то поменяет из значимых вещей, в том числе - перенесет целиком документ в будущее или прошлое - система покажет что хешь отличается, и тогда начнутся вопросы - почему, кто менял и что произошло.
И ни в коем случае никаких секретов, абсолютно все знают что включена система чейнов, и что хрен что даже адми базы сможет сделать, так как в случае аудита, запускается обработка, и она тоже высчитывает все хеши, и если админ базы что то подмутил, то тогда он летит под все статьи, и об этом знает и знают все сотрудники.
Фишка чейна в том, что ВСЕ должны знать, но при этом НИКТО не может на это повлиять.
TerveRus; acanta; +2 Ответить
6. mkalimulin 1148 26.01.20 18:19 Сейчас в теме
(3) Очень интересно. Где можно почитать о вашем проекте?
Насчет значимых полей - согласен. Но я специально так сделал, чтобы добиться максимальной простоты решения.
В моих предыдущих решениях была возможность настройки сериализации документов. Здесь же я решил, что нет особого смысла напрягать пользователя и заставлять его выбирать значимые поля. От того, что сериализоваться будут все сильно хуже не будет.
Насчет открытости, тоже полностью согласен. Когда я говорил о "секрете", я имел ввиду следующее.
Контролер может действовать двумя способами. Первый - он немного напрягается и записывает(или распечатывает) ключ. Натурально, на бумажку. А бумажку кладет в карман. Второй вариант - это когда ему лень возиться с запоминанием ключа. Тогда он "кладет в карман" не бумажку, а флэшку или внешний диск. "Секрет" так или иначе присутствует. Без него система не будет работать. И вашей системе он тоже есть.
4. vladimirmatancev 26.01.20 17:18 Сейчас в теме
Какая информация попадает в контроль? Реквизиты и ТЧ документа?
Как быть с записями в регистры?
5. mkalimulin 1148 26.01.20 17:46 Сейчас в теме
(4) Реквизиты, ТЧ и движения.
7. Indgo 338 27.01.20 11:27 Сейчас в теме
Миша, в новых редакциях уже давно сущесвует мощная система версионирования.
Так что ваш "блокчейн" на штрих коде пачки беламорканала уже как бы не актуален.
8. mkalimulin 1148 27.01.20 11:45 Сейчас в теме
(7) Версионирование - это такие же таблицы в базе данных. И защищены они точно так же, как и таблицы документов. Т. е. никак.
Fox-trot; +1 Ответить
9. mkalimulin 1148 27.01.20 13:16 Сейчас в теме
(7) У вас каждый день 100 новых документов. И ещё 20 старых меняются. Чтобы отследить нарушения, вам потребуется СИСТЕМА контроля. Простая установка Версионирование вам не поможет. Как вы узнаете, где искать нарушение, используя Версионирование?
10. Indgo 338 27.01.20 13:19 Сейчас в теме
(9) Все ваши хеши - такие же таблицы. Пересчитать не проблема.
Ну я знаю вы это не когда не признаете - так как это вам не выгодно.
11. mkalimulin 1148 27.01.20 14:29 Сейчас в теме
(10) Хеши - не таблицы. Криптоанархисту это должно быть известно)))
Таблицу можно поменять незаметно, а хэши нельзя.
13. Indgo 338 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

А что вы называете блокчейном - я не знаю
o.kovalev; +1 Ответить
15. mkalimulin 1148 27.01.20 15:58 Сейчас в теме
(13) Я не ставлю такую задачу. Проверять цепочку не зная ее содержимого. Зачем? Можете объяснить - где это может пригодиться в 1С?
16. mkalimulin 1148 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. Indgo 338 27.01.20 17:43 Сейчас в теме
(16)
tography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data.

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

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

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

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

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