Comments 84
Вам не нужен блокчейн тут. Поскольку администратор БД — централизованная сущность, достаточно подписи на каждый документ от сервиса аудита. Он же, заодно, и сохраняет операции.
А что мешает переписать всю историю, если есть админские права? Суть блокчейна-то, что у нас подписи разных агентов в базе и каждый участник независимо валидирует всю цепочку.
Что "все агенты" и кто "все", кто валидирует? Если одинокий 1С-сервер, то это всё карго-культ. Если же это распределённая база, то кто её участники? Пикалки на складе? Ну и обнаружила эта пикалка расхождение, что она делать будет?
Запись кем? И почему этот кто-то не может сделать новую бумажку после замены 100 айфонов по 1000 баксов на 1 айфон по 100000 баксов?
А чем абсолютный контроль над данными отличается от просто контроля над данными? Вот если у меня есть подписанные моим ключом транзакции (без блокчейна), то чем они менее надёжны, чем подписанные друг другом транзакции без моей подписи?
Я убрал одну вашу транзакцию. Как вы это обнаружите?
… а как вы обнаружите, какая конкретно транзакция была удалена, если злоумышленник пересчитал все хэши от начала времен?
У меня есть последний ключ. С его помощью я обнаружу подмену журнала и восстановлю его.
Я спросил, как вы обнаружите, какая конкретно транзакция была удалена.
(Чтобы восстановить, вам нужны все стартовые данные, а они у вас не обязательно есть.)
Если у злоумышленника есть доступ к этой копии, то ничего не изменится. Если нет, то вообще ничего не нужно: просто всегда сверяйте с этой копией.
Давайте будем исходить из того, что злоумышленник стремится остаться незамеченным
Подписи решают задачу предотвращения этого как минимум не хуже.
Но с ЭЦП вам придется как-то решать вопрос сохранности ключа.
А в чем проблема? Существующие системы прекрасно это решают.
Есть какие-то другие безопасные способы подписания документа?
Ну да, как минимум подписание на устройстве со сверкой контрольной фразы.
Но если вы не доверяете не только работникам, то и ПО, сделать нельзя ничего.
А без этой технологии не сможет, даже если очень захочет
Это утверждение неверно. Есть сильно больше одного способа получить контроль над данными без этой технологии, причем эти способы — более удобные.
Например?
Например, как вам предложили выше, подписать каждую транзакцию. По сравнению с вашим вариантом выгод как минимум две — не надо ничего вручную переписывать, и явно видно, какая транзакция была изменена.
(Защита от удаления транзакций тоже тривиальная: подписывается не только транзакция, но и сведенное "итого" на момент сверки, содержащее, помимо прочего, число транзакций. Идентификатор предыдущей транзакции тоже можно держать, но у этого есть свои недостатки.)
Администратор БД, или человек, повысивший свои привилегии до уровня администратора БД могут внести в базу изменения
Могут. Но
1. Что за мотивация у них должна быть менять цифры в исторических бухгалтерских документах, чтобы совершить подобное уголовное преступление?
2. И если вдруг настолько сильная мотивация нашлась, то что им мешает сделать это вечерком, заодно пересчитав хеш во всех последующих операциях?
. В свою очередь сам журнал защищен от подмены технологией блокчейн и записью последнего ключа в секретное место.
Тяжелое и неудобное решение практически несуществующей проблемы в бухгалтерском учёте. Вся первичка продублирована в бумажном виде, и в здравом уме в 1С её никто не подделывает. Вот ошибки при вводе, пересортица при отгрузке и т.п. — это причина 99.9% подобных проблем, и их никак блокчейн не решит.
Кроме того, расхождения выявляются не только по количеству. У вас есть и налоговые накладные, и платежи поставщикам, и одной правкой приходной накладной тут не обойтись. Так что вы реально придумали решение проблемы, которая находится совсем в другом месте.
1. Отношение стоимости единицы товара к стоимости партии должно быть крайне небольшим
2. Товароведы должны быть не слишком внимательными, не помнить остатков, не помнить себестоимости.
3. Злоумышленник должен иметь админский доступ к 1С, и владеть ей на уровне опытного разработчика, чтобы и документы подправить, и регистры.
4. Злоумышленник должен иметь доступ на склад
5. Должна быть возможность незаметно вынести товар со склада
6. Сверка с контрагентами если и будет проводиться, то только по суммам, не по количеству.
7. И при всём при этом мероприятие должно быть достаточно выгодным, чтобы рисковать.
Вы же, надеюсь, понимаете, что вероятность подобной атаки настолько ничтожна, что даже защита склада от падения метеорита — и то более прибыльное дело?
Я смотрю у вас продвинутые кладовщики — не имея админских прав ни в своей ОС, ни в сети, ни в 1С, ни на кластере 1С, ни в СУБД могут прям со своего рабочего места через веб-публикацию базы сделать Update в СУБД. Респект!
Админский пароль к СУБД хранится на кластере
… но зачем?
Не понял. Поясните, пожалуйста
Зачем у вас "на кластере" хранится админский пароль к СУБД?
А, ну то есть это конкретная болячка 1С, не имеющая ничего общего с принципиальными проблемами учетных систем.
Я не понимаю вашу позицию. Вы считаете, что проблемы нет вообще? Или что проблема есть, но она имеет лучшие решения?
В любой учетной системе количество людей, которые могут делать в ней все, что хотят, строго больше 0.
Совершенно не обязательно. Зачем?
Вы считаете, что проблемы нет вообще?
Какой конкретно проблемы?
Если кто-то знает админский пароль к СУБД, то он может делать в системе все, что хочет.
Если кто-то знает админский пароль к СУБД, он может делать с СУБД все, что хочет (но даже это не обязательно будет бесследно). Но, как я уже писал, нормальной системе совершенно не нужен админский пароль к СУБД для функционирования.
Почему вы смешиваете "пользователя, обладающего правами администратора в учетной системе" и "администратора СУБД"? У меня в соседнем окне открыта Asana, которая система учета задач в проекте. У меня в рамках моего набора проектов админские права, я могу делать что угодно (но на самом деле — нет, audit trails я подчищать не могу). Есть ли у меня админские права на СУБД? Нет. Есть ли у меня какие-то права на СУБД? Нет. Могу ли я их получить? Напрямую — точно нет, понадобится взлом, и он далеко не тривиален.
Платформа для коннекта не запрашивает пароль у пользователя, а использует сохраненный
Ээээ. Вы в курсе, да, что нормальной трехзвенной системе вообще не нужен пароль пользователя для работы с БД? И уж точно не нужно, чтобы у пользователя были администраторские права в БД?
Для MS SQL Server вообще можно сделать так, чтобы и пароль не нужно было хранить (смотрите Managed Service Account).
И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят.
Если эти 110 (101) штук получались от контрагента с единственной целью
Что же касается темы статьи, то 1С существует уже не первый десяток лет, но есть бухгалтер (а сколько Вам нужно?), а есть
Ну несет кто-то ответственность. И что? Как вы обнаружите, что тот, кто несет ответственность вынес 9 штук?
Довольно однобокое представление о современном учёте, видимо, связанное с российской спецификой названий. Он уже давно вышел за пределы функции финансового контроля. А бухгалтер давно перестал быть человеком, просто несущим ответственность за циферки в системе.
Перефразируя поэта, можно сказать, что «дело прочно, когда под ним струится пот». Строгое соответствие между данными учетной системы и реальностью не возникает само собой. Оно всегда есть результат некоего человеческого усилия. При работе с большими объемами данных, мы решаем задачу поиска минимально необходимых усилий для контроля. Чуть больше усилий, и они могут стать неподъемными из-за большого объема данных. Чуть меньше усилий, и контроль потерян. Наша задача — нащупать эту границу. И я утверждаю, что предложенная мной схема с блокчейном, как раз и находит эту границу. 2 минуты человеческих усилий на сеанс контроля — это, по видимому, абсолютный минимум. А что с ЭЦП? Там же можно просто нажать на красивую кнопочку «Подписать» и это будет еще быстрее? Будет. Но это будет уже по другую сторону границы. Там, где контроль уже утерян. У вас есть каналы связи между базой данных и вашим компьютером и между вашим компьютером и защищенным устройством в обе стороны. Просто нажав кнопочку «Подписать» вы полагаетесь на то, что на подпись будет отправлено именно то, что в базе, а также на то, что подпись, которая в результате уйдет в базу — это именно та подпись, что выдало вам защищенное устройство. Может быть и существует схема с ЭЦП, которая дает человеку возможность контролировать эти каналы. Поправьте меня, кто лучше знает. Но пока у меня большое подозрение, что реально надежная схема с ЭЦП потребует от человека не меньше, а больше усилий, чем схема с блокчейном. Чем еще хороша моя схема, так это тем, что канал там один — ручка, бумажка. Контроль над этим каналом со стороны человека абсолютно надежен. И это очевидно даже неспециалисту.
Что касается второй претензии. Каждый раз, когда вы говорите, что проблема надуманна, где-то хлопает в ладоши от радости человек, который проделал операцию 101х110=110х101. Подумайте, быть может это в вас говорит снобизм? Как так?! Меня, такого умного, объегорит какой-то кладовщик?! Ха-ха! Вот только все меняется очень быстро. Мы уже живем в мире, где все знают все (или, по крайней мере, движемся к этому с огромной скоростью). Что такое базы данных и как с ними обращаться уже сейчас доступно каждому со школьного возраста. Особо заинтересованные и мотивированные могут нагуглить известные дыры в популярных системах и способы повышения привилегий. Хороший пример здесь 1С. То, что пароль к базе данных хранится особо не скрывается. Но и дырка по тем или иным причинам тоже не закрывается уже чуть ли не третий десяток лет. Сколько в России и около учетных систем на базе 1С? Ну и, наконец, не стоит забывать, что в любой учетной системе количество людей, которые могут делать в ней все, что хотят всегда строго больше нуля. Традиционный способ решить проблему «человеческого фактора» в такой ситуации — это дублирование и взаимный контроль. Т.е. кто-то должен контролировать человека, который может все. И это — реальная проблема
Контроль над этим каналом со стороны человека абсолютно надежен.
Вы только забываете, что нет никакого контроля со стороны человека за расчетом ваших хэшей. Так что вся ваша надежность упирается все равно упирается в доверие ПО.
Ну и, наконец, не стоит забывать, что в любой учетной системе количество людей, которые могут делать в ней все, что хотят всегда строго больше нуля.
Это утверждение ложно. Вы забываете про аудит-трейлы.
Понимаете, проблема вашего подхода в том, что он отвечает только на один вопрос: было ли что-то изменено. Что было изменено, когда, кем — вы все равно не узнаете. А человеческий фактор в переписывании цифр на бумажку делает возможным еще и ложные срабатывания — когда человек ошибся в одной цифре, и теперь невозможно выяснить, кто же прав, его бумажка или система.
К чему вы вспомнили про аудит-трейлы? Если человек может делать в базе все, что хочет, значит он может вносить изменения мимо аудит-трейлов.
Ответ на вопрос: «что было изменено» можно будет найти в бэкапах. В автоматическом режиме, по ссылке на документ. Я продолжаю настаивать на том, что вопрос «было ли что-то изменено» — ключевой. Решив его, вы решите и все остальное. Не решив, не решите ничего.
Ложные срабатывания — это вообще не проблема. При ложном срабатывании пользователь откатится к предыдущему состоянию журнала и просто еще раз сверит документы прошлого сеанса. И то, это будет происходить только в том случае, когда проверяющий один. В большинстве случаев проверяющих будет не менее двух. И только если сам собственник решит не доверять никому этот процесс и будет заниматься сверкой самостоятельно, тогда возможны редкие ложные срабатывания с некритичными последствиями. Не вижу здесь проблемы
Даже если мы добавим туда SHA256, мы все равно не выйдем за пределы 100 строк.
Нет, выйдем. Рассчет хэша по сложному документу — это много кода, который надо весь проверять. А иначе можно случайно выяснить, что у вас в хэш не входит сумма.
Если человек может делать в базе все, что хочет, значит он может вносить изменения мимо аудит-трейлов.
Это совершенно не обязательно.
Ответ на вопрос: «что было изменено» можно будет найти в бэкапах.
… и в бэкапах будут те же данные, которые в измененной БД, потому что у вас есть человек, который может делать с БД все, в том числе и править бэкапы.
Решив его, вы решите и все остальное.
Нет, вы не решите остальное, в этом и проблема.
При ложном срабатывании пользователь откатится к предыдущему состоянию журнала
А где он его возьмет?
В большинстве случаев проверяющих будет не менее двух.
А зачем? Мы не доверяем никому, кроме себя.
Но, если честно — реально это всё нафиг не нужно. Можно реализовать не менее надежную систему и без блокчейна. Например, комбинация логов на удаленных серверах (куда есть доступ только у контролеров) + ЭЦП сработает даже лучше — можно довольно легко найти, какой конкретно документ и как был изменен. Или многие другие методы. И опять же — это обычно не делают, так как не очень надо.
Ценность в данном решении одна — повесить лапшу на уши доверчивому инвестору / владельцу, и попилить бабло на модном слове «блокчейн».
Учет умер, да здравствует учет