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

19.08.21

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

+6 –

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
Контроль информации в базе на основе блокчейн: .epf 10,83Kb 7	7	Скачать (1 SM)	Купить за 1 850 руб.

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

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

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

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

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

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

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

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

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

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

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

//infostart.ru/webinars/1179443/

//infostart.ru/webinars/1179444/

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

+6 –

См. также

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

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

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

1 стартмани

30.01.2024 3157 stopa85 12

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

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

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

19.10.2023 7544 user1959478 51

Математический тренажер через телеграмм (feat 1С)

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

Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.

2 стартмани

29.09.2023 3102 maksa2005 8

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

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

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

1 стартмани

09.06.2023 10896 7 SpaceOfMyHead 18

Мини-обзор разных решений задач

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

Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.

03.04.2023 4354 RustIG 9

Тестирование средств 1С для решения СЛАУ

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

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

23.11.2022 3519 gzharkoj 14

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

Информационная безопасность Системный администратор Программист Бесплатно (free)

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

13.05.2022 2696 mkalimulin 19

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

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

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

1 стартмани

21.03.2022 9041 7 kalyaka 11

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. Fox-trot 163 25.01.20 22:36 Сейчас в теме

имхо малость не хватает автоматизации процесса
а именно не хватает даты для автоматического закрытия периода, то есть автоматом создавать цепочку документов без участия оператора
или хотя бы при начальном создании образа

2. mkalimulin 1230 26.01.20 11:53 Сейчас в теме

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

3. DitriX 2101 26.01.20 17:16 Сейчас в теме

Направление то. Но реализация не очень. Мы используем эту технологию в реале, и там все выглядит по другому.
Например, при закрытии месяца - формируется хеш от хешей всех документов, а хеш документов берется только из значимых полей, например, комментарий - не значимое поле, сортировка в документе - не значимое событие и т.д.
И когда владельцу уходит отчет, то с ним же уходит и текущий хеш. И вот так, каждый день/месяц - владелец получает отчет с одной дополнительной строкой. И если, кто-то зади что-то поменяет из значимых вещей, в том числе - перенесет целиком документ в будущее или прошлое - система покажет что хешь отличается, и тогда начнутся вопросы - почему, кто менял и что произошло.
И ни в коем случае никаких секретов, абсолютно все знают что включена система чейнов, и что хрен что даже адми базы сможет сделать, так как в случае аудита, запускается обработка, и она тоже высчитывает все хеши, и если админ базы что то подмутил, то тогда он летит под все статьи, и об этом знает и знают все сотрудники.
Фишка чейна в том, что ВСЕ должны знать, но при этом НИКТО не может на это повлиять.

6. mkalimulin 1230 26.01.20 18:19 Сейчас в теме

(3) Очень интересно. Где можно почитать о вашем проекте?
Насчет значимых полей - согласен. Но я специально так сделал, чтобы добиться максимальной простоты решения.
В моих предыдущих решениях была возможность настройки сериализации документов. Здесь же я решил, что нет особого смысла напрягать пользователя и заставлять его выбирать значимые поля. От того, что сериализоваться будут все сильно хуже не будет.
Насчет открытости, тоже полностью согласен. Когда я говорил о "секрете", я имел ввиду следующее.
Контролер может действовать двумя способами. Первый - он немного напрягается и записывает(или распечатывает) ключ. Натурально, на бумажку. А бумажку кладет в карман. Второй вариант - это когда ему лень возиться с запоминанием ключа. Тогда он "кладет в карман" не бумажку, а флэшку или внешний диск. "Секрет" так или иначе присутствует. Без него система не будет работать. И вашей системе он тоже есть.

4. vladimirmatancev 22 26.01.20 17:18 Сейчас в теме

Какая информация попадает в контроль? Реквизиты и ТЧ документа?
Как быть с записями в регистры?

5. mkalimulin 1230 26.01.20 17:46 Сейчас в теме

(4) Реквизиты, ТЧ и движения.

7. Indgo 414 27.01.20 11:27 Сейчас в теме

Миша, в новых редакциях уже давно сущесвует мощная система версионирования.
Так что ваш "блокчейн" на штрих коде пачки беламорканала уже как бы не актуален.

8. mkalimulin 1230 27.01.20 11:45 Сейчас в теме

(7) Версионирование - это такие же таблицы в базе данных. И защищены они точно так же, как и таблицы документов. Т. е. никак.

9. mkalimulin 1230 27.01.20 13:16 Сейчас в теме

(7) У вас каждый день 100 новых документов. И ещё 20 старых меняются. Чтобы отследить нарушения, вам потребуется СИСТЕМА контроля. Простая установка Версионирование вам не поможет. Как вы узнаете, где искать нарушение, используя Версионирование?

10. Indgo 414 27.01.20 13:19 Сейчас в теме

(9) Все ваши хеши - такие же таблицы. Пересчитать не проблема.
Ну я знаю вы это не когда не признаете - так как это вам не выгодно.

11. mkalimulin 1230 27.01.20 14:29 Сейчас в теме

(10) Хеши - не таблицы. Криптоанархисту это должно быть известно)))
Таблицу можно поменять незаметно, а хэши нельзя.

13. Indgo 414 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 1230 27.01.20 15:58 Сейчас в теме

(13) Я не ставлю такую задачу. Проверять цепочку не зная ее содержимого. Зачем? Можете объяснить - где это может пригодиться в 1С?

16. mkalimulin 1230 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 414 27.01.20 17:43 Сейчас в теме

(16)

tography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data.

Дя я уж понял что вы все из википедии учите

18. mkalimulin 1230 27.01.20 18:28 Сейчас в теме

(17) Если вы знаете определение лучше, тогда дайте его сюда.

12. mkalimulin 1230 27.01.20 14:32 Сейчас в теме

(10) Я, кстати, никогда не отрицал, что хэши можно пересчитать. Я отрицал только то, что это можно сделать незаметно. Но вы слово "незаметно" игнорируете. Потому что вам это не выгодно)))

14. Indgo 414 27.01.20 15:14 Сейчас в теме

(12)

Потому что вам это не выгодно)))

Я по 990 рублей за халтуру не беру. И картошку под видом манго не впариваю папуасам, во избежания дегенерации подобно вашей.

19. bmf 30.01.20 07:06 Сейчас в теме

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

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

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

И немного фантазии на тему блокчейна (не для обсуждения, просто мысли): "Куда придем через 5-7 лет": валидатором будет государство (ФНС, ЦБ или новая структура). Документы по сделкам, оплатам, чекам и все остальное будет в блокчейне. Сделки, не подтвержденные блокчейном, будут недействительны. Налоги начислят Вам раньше чем Вы увидите деньги на своем расчетном счете. 1С, как платформа учета, очень возможно останется, но будет по сути лишь средством ввода информации в блокчейн и формирования отчетов.

20. mkalimulin 1230 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 1230 03.02.20 10:27 Сейчас в теме

(21) В случае с распределеным блокчейном речь идёт не о доверии, а о консенсусе. Их легко спутать, но это разные вещи. И самое главное - консенсус не всегда нужен. Если у вас один покупает, а другой продаёт, тогда - да, консенсус им необходим. А если у вас один кладовщик, а другой ревизор, то какой у них может быть консенсус?
Вебинары идут регулярно, несколько раз в месяц и в разное время. Надеюсь, вы сможете выбрать себе подходящее.

23. bmf 06.02.20 01:05 Сейчас в теме

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

24. mkalimulin 1230 06.02.20 11:04 Сейчас в теме

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