Учет, как особый, достаточно сложный и уважаемый вид человеческой деятельности действительно умер. Навсегда ушли те времена, когда человек, нашедший в себе силы освоить премудрости дебета и кредита, сразу становился обладателем магических перков. Он мог разговаривать с налоговой и следить за тем, чтобы не разворовали склад. При том, что не стоял день и ночь рядом со складом с ружьем, а использовал магию цифр, сидя в комфортном кабинете. Теперь с налоговой разговаривает программа 1С. И о чем они там перешептываются, похоже, скоро уже не будет знать никто. А на страже склада стоит чудесный алгоритм под названием «контроль отрицательных остатков» (плохо, правда, стоит, но это тема отдельного разговора). Человеку же остается всего лишь незавидная роль оператора по вводу данных. Да и то, пока. Совсем скоро программы окончательно научатся обмениваться данными без участия людей-операторов, и будет у нас самый настоящий и повсеместный «скайнет».
Нельзя сказать, что такого рода разговоры совсем оторваны от реальности, но в основе их все-таки лежит невежество. Технологии не портят жизнь людям. Да, они ее меняют. И, да, заставляют учиться новому. Но эта новая жизнь безусловно лучше старой. Технологии не ограничивают людей, а напротив, дают им новые, доселе невиданные возможности и способности. И я хочу показать это на одном, конкретном примере, связанном с учетом.
Представим себе человека и некоторую учетную систему. Для простоты, пусть это будет некий идеальный складской учет. Что-то на склад приходит, что-то уходит. Для каждой операции существует т.н. первичный документ. Данные первичных документов незамедлительно вводятся в базу. Задача человека организовать рациональный контроль за процессом, с целью не допустить расхождения между первичными документами и данными в учетной системе.
Человек принимает решение сверять каждый первичный документ с данными в системе. Но тут возникает проблема. Дело в том, что нельзя просто один раз сверить конкретный документ с данными системы. Потом отложить этот документ в сторону и забыть о нем навсегда. Данные в системе могут измениться и это потребует повторной сверки. А самое печальное заключается в том, что тот, кто изменил данные не обязательно будет гореть желанием сообщить вам об этом. Напротив, в его интересах будет чтобы никто никогда не узнал об изменении. Например, некто меняет в приходном документе "110 штук по цене 101 рубль" на "101 штука по цене 110 рублей". Присваивает себе 9 штук. И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят. Вы можете создать сколь угодно изощренную систему прав доступа. И не менее изощренную систему логирования изменений. Результатом ваших усилий будет всего лишь возросшее у вас же чувство уверенности. И это ровно то, что полностью устраивает того, кто увел у вас 9 штук. Это хорошо, скажет он себе, что они так уверены. Пусть и дальше будут уверены так же. Или еще сильнее. Надо им еще пару идей подкинуть. Нет никакого другого способа отследить изменения, кроме как производить каждый раз сверку абсолютно всех документов. Раньше такое решение даже и не приходило никому в голову. Или, по крайней мере, не задерживалось там дольше микросекунд. Это представлялось очевидно невозможным. Но... как совершенно верно подметил один русский поэт: невозможное возможно.
Допустим, все только начинается. Прошли несколько операций на складе. У человека есть несколько первичных документов, а в базе есть соответствующие им записи. Человек сверяет каждый документ с данными в базе и попутно проделывает следующее (чтобы текст был понятен непрограммистам, я воспользуюсь неким псевдоязыком программирования):
для каждого документа из документов в базе
превратим данные документа в строку
добавим к ней предыдущий ключ/хеш
получим новый ключ/хеш для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец
В этих шести строчках описана технология блокчейн в чистом виде. Под получением ключа/хеша подразумевается вычисление какой-либо хеш-функции, например SHA256. Сразу надо отметить, что человек может вести журнал в той же самой базе. Как мы уже говорили, данные в базе могут изменить. В том числе могут изменить сам журнал. Но человека это не волнует. Потому что, как вы увидите дальше, изменить журнал незаметно для человека не получится.
Вернемся к процессу. Первая порция документов сверена и занесена в журнал. Далее происходит самое важное действие. Человек переписывает последний ключ в какое-нибудь секретное место (например на бумагу, это будет самый надежный вариант; если использовать SHA256, это займет не более 2 минут, я проверял). Теперь сеанс сверки можно считать завершенным.
Через некоторое время на складе происходит еще какое-то количество событий и появляются новые первичные документы. Человек приступает к следующему сеансу. Первым делом он сверяет последний ключ в журнале с тем, что у него хранится в секретном месте. Здесь происходит самое интересное. Сверяя некоторое, не очень большое, количество символов, человек визуально контролирует неограниченный объем данных. Убедившись в том, что ключи совпадают, человек далее проделывает следующее:
для каждой записи из журнала
получим данные документа по ссылке и превратим их в строку
добавим к ней значение ключа из предыдущей записи
получим значение ключа для этой составной строки
сравним его с ключом, который записан в журнале
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
превратим данные документа в строку
добавим к ней предыдущий ключ
получим новый ключ для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец
Мы убедились, что документы внесенные в журнал не изменялись. После чего добавили в журнал новую порцию документов, попутно сверяя каждый с первичным документом. Теперь осталось определиться с тем, что делать когда обнаруживается изменение ранее введенного в систему документа. В принципе, это нормальный рабочий момент. Время от времени он имеет место быть. Поэтому, человек принимает следующее решение. При обнаружении изменения, делать повторную сверку с первичным документом, старую запись в журнале оставлять как есть, а в конец журнала добавлять новую запись. В старой записи указывать ссылку на новую, как на потомка. А в новой указывать ссылку на старую, как на предка. И, наконец, использовать указатель на предка при формировании ключа. Список действий в окончательном виде выглядит так:
для каждой записи из журнала
если запись не имеет потомка
получим данные документа по ссылке и превратим их в строку
добавим к ней значение ключа из предыдущей записи
добавим значение указателя на предка
получим значение ключа для этой составной строки
если вычисленный ключ не равен ключу в журнале
запишем в журнал новую запись с указанием предка
в старой записи дадим указание на потомка
конец
конец
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
превратим данные документа в строку
добавим к ней предыдущий ключ
получим новый ключ для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец
Разумеется, все это делается не в ручном режиме. Все действия, за исключением собственно сверки с первичными документами, выполняются программой, которая запускается при каждом сеансе контроля. Описанная здесь система представляет собой абсолютное "всевидящее око". Любое добавление или изменение будет обнаружено с помощью журнала. После чего правомерность операции может быть подтверждена путем сверки с первичным документом. В свою очередь сам журнал защищен от подмены технологией блокчейн и записью последнего ключа в секретное место.
Единственная теоретически возможная атака заключается в подмене программы. Действительно, есть такая максима, гласящая, что абсолютно доверять можно только той программе, которую написал сам. На самом деле, ее следовало бы перефразировать так: абсолютно доверять можно только той программе, которую ты прочитал сам непосредственно перед запуском. Представленная здесь программа настолько проста, что вполне удовлетворяет этому условию. В этих 19 строках просто негде спрятать закладку. Поэтому программу можно контролировать визуально. Впрочем, существуют еще и достаточно надежные способы контроля, основанные также на вычислении хеш-функции и сравнении результатов.
Используя эту, в общем не хитрую технологию, человек получает способность контролировать любые объемы данных. Причем, результат будет эквивалентен тому, который получился бы при сверке абсолютно всех документов в каждом сеансе контроля. Это дает возможность создавать абсолютно надежные системы контроля. В свою очередь, от человека требуется совсем не много. Всего лишь освоить тот или иной способ контроля над запускаемыми программами.
На этом простом примере я хотел показать, что технологии могут и должны быть гуманными. Не ограничивать человека, а напротив, открывать ему новые горизонты. Конечно, контроль данных - тема хотя и важная, но это далеко не все, что есть в учете. Я уверен, будут (или даже уже есть) и другие технологии, расширяющие возможности человека в области учета. Учет, как институт защиты интересов участников бизнеса, конечно же не умер. Просто он становится другим. Лучше и надежнее. При этом роль человека не уменьшается, а наоборот, по мере того, как растут возможности человека, растет и его роль в процессе.
amarao
Вам не нужен блокчейн тут. Поскольку администратор БД — централизованная сущность, достаточно подписи на каждый документ от сервиса аудита. Он же, заодно, и сохраняет операции.
exwill Автор
Администратор БД, или человек, повысивший свои привилегии до уровня администратора БД могут внести в базу изменения, которые никто без блокчейна не найдет
amarao
А что мешает переписать всю историю, если есть админские права? Суть блокчейна-то, что у нас подписи разных агентов в базе и каждый участник независимо валидирует всю цепочку.
Что "все агенты" и кто "все", кто валидирует? Если одинокий 1С-сервер, то это всё карго-культ. Если же это распределённая база, то кто её участники? Пикалки на складе? Ну и обнаружила эта пикалка расхождение, что она делать будет?
exwill Автор
Мешает запись последнего ключа на бумаге
amarao
Запись кем? И почему этот кто-то не может сделать новую бумажку после замены 100 айфонов по 1000 баксов на 1 айфон по 100000 баксов?
exwill Автор
Вы правы в том, что в результате мы имеем дело с человеческим фактором. Но если человек захочет, то используя эту технологию, он сможет получить абсолютный контроль над данными. А без этой технологии не сможет, даже если очень захочет
amarao
А чем абсолютный контроль над данными отличается от просто контроля над данными? Вот если у меня есть подписанные моим ключом транзакции (без блокчейна), то чем они менее надёжны, чем подписанные друг другом транзакции без моей подписи?
exwill Автор
Я убрал одну вашу транзакцию. Как вы это обнаружите?
lair
… а как вы обнаружите, какая конкретно транзакция была удалена, если злоумышленник пересчитал все хэши от начала времен?
exwill Автор
У меня есть последний ключ. С его помощью я обнаружу подмену журнала и восстановлю его.
lair
Я спросил, как вы обнаружите, какая конкретно транзакция была удалена.
(Чтобы восстановить, вам нужны все стартовые данные, а они у вас не обязательно есть.)
exwill Автор
Обнаружив подмену журнала, я восстановлю его из резервной копии.
lair
Если у злоумышленника есть доступ к этой копии, то ничего не изменится. Если нет, то вообще ничего не нужно: просто всегда сверяйте с этой копией.
exwill Автор
Если я не могу восстановить из одной копии, я восстановлю из другой, более ранней. Если злоумышленник уничтожил все копии и базу заодно, то так тому и быть. Но это не останется незамеченным. Предлагаю далее не обсуждать это направление. Давайте будем исходить из того, что злоумышленник стремится остаться незамеченным
lair
Подписи решают задачу предотвращения этого как минимум не хуже.
exwill Автор
Я может быть чего-то не понимаю. Если не прав, поправьте. Но с ЭЦП вам придется как-то решать вопрос сохранности ключа. Т.е. ключ должен хранится на отдельном устройстве. И в идеале это устройство связывается с основной базой только через посредника-человека. Человек руками вбивает данные документа на защищенном устройстве. Получает подпись. Затем опять руками вбивает подпись в основной базе. Есть какие-то другие безопасные способы подписания документа?
lair
А в чем проблема? Существующие системы прекрасно это решают.
Ну да, как минимум подписание на устройстве со сверкой контрольной фразы.
Но если вы не доверяете не только работникам, то и ПО, сделать нельзя ничего.
exwill Автор
Будет сверка контрольной фразы для каждого документа?
lair
Если вы хотите проверять, что каждый документ — это именно то, что вы видите, то да, каждого документа.
exwill Автор
А в блокчейне достаточно одной сверки на сеанс
lair
Тогда и здесь достаточно одной сверки на сеанс.
lair
Это утверждение неверно. Есть сильно больше одного способа получить контроль над данными без этой технологии, причем эти способы — более удобные.
exwill Автор
Например?
lair
Например, как вам предложили выше, подписать каждую транзакцию. По сравнению с вашим вариантом выгод как минимум две — не надо ничего вручную переписывать, и явно видно, какая транзакция была изменена.
(Защита от удаления транзакций тоже тривиальная: подписывается не только транзакция, но и сведенное "итого" на момент сверки, содержащее, помимо прочего, число транзакций. Идентификатор предыдущей транзакции тоже можно держать, но у этого есть свои недостатки.)
DrPass
Могут. Но
1. Что за мотивация у них должна быть менять цифры в исторических бухгалтерских документах, чтобы совершить подобное уголовное преступление?
2. И если вдруг настолько сильная мотивация нашлась, то что им мешает сделать это вечерком, заодно пересчитав хеш во всех последующих операциях?
exwill Автор
Вроде ведь описал в статье — что мешает. Запись последнего ключа на бумаге
DrPass
Но если ключ записывается на бумагу раз в день, то что мешает поменять документ до того, как ключ перепишут на бумагу? Что мешает всунуть поддельный документ или поддельную корректирующую строчку в «пакет следующего дня»? Вы предлагаете метод вида «для усиления безопасности повесить замок на дырявую картонную коробку»
exwill Автор
Куда всунуть? Если документа не будет в журнале, тогда он будет сверяться на следующий день наравне с другими новыми документами. А если вы его «всунете» в журнал после записи последнего ключа, тогда разойдутся ключи