All streams
Search
Write a publication
Pull to refresh
6
-5.5
Калимулин Михаил Игоревич @exwill

AI developer

Send message
Ну это же (гипотетически) закон. Платить должен тот, кто нарушает.
Но если вдуматься, имплементация такого закона приведет к сокращению расходов пользователей, а не к их росту. В описанном мною случае, пользователь заплатил за то, что ему создали ограничения
Так поделите. Жалко вам что ли? IEEE 754 разрешает
Какие это «другие методы»? Вы не могли бы озвучить?
Вы совершенно правы в том, что в конечном счете все упирается в доверие к ПО. А вернее в то, как нам заменить ДОверие на ПОСЛЕверие. Предложенная мной технология стягивает эту проблему в одну точку. Нам надо перед каждым сеансом сверки проверять наше ПО. И я свожу это ПО к абсолютному минимуму, который может быть быстро загружен и быстро проверен. В особо ответственных случаях, визуально. Пример в статье содержит 20 строк кода. Даже если мы добавим туда SHA256, мы все равно не выйдем за пределы 100 строк.

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

Ответ на вопрос: «что было изменено» можно будет найти в бэкапах. В автоматическом режиме, по ссылке на документ. Я продолжаю настаивать на том, что вопрос «было ли что-то изменено» — ключевой. Решив его, вы решите и все остальное. Не решив, не решите ничего.

Ложные срабатывания — это вообще не проблема. При ложном срабатывании пользователь откатится к предыдущему состоянию журнала и просто еще раз сверит документы прошлого сеанса. И то, это будет происходить только в том случае, когда проверяющий один. В большинстве случаев проверяющих будет не менее двух. И только если сам собственник решит не доверять никому этот процесс и будет заниматься сверкой самостоятельно, тогда возможны редкие ложные срабатывания с некритичными последствиями. Не вижу здесь проблемы
Спасибо всем, кто принял участие в обсуждении. Главный результат заключается в том, что предложенная мной схема с блокчейном — работает. Никто не увидел какой-либо явной «дыры». И это — хорошо. Все озвученные претензии можно свести к двум. Первая — с ЭЦП можно сделать все то же самое, но проще. Вторая претензия заключается в том, что я решаю выдуманную мною же проблему. Отвечу по порядку.
Перефразируя поэта, можно сказать, что «дело прочно, когда под ним струится пот». Строгое соответствие между данными учетной системы и реальностью не возникает само собой. Оно всегда есть результат некоего человеческого усилия. При работе с большими объемами данных, мы решаем задачу поиска минимально необходимых усилий для контроля. Чуть больше усилий, и они могут стать неподъемными из-за большого объема данных. Чуть меньше усилий, и контроль потерян. Наша задача — нащупать эту границу. И я утверждаю, что предложенная мной схема с блокчейном, как раз и находит эту границу. 2 минуты человеческих усилий на сеанс контроля — это, по видимому, абсолютный минимум. А что с ЭЦП? Там же можно просто нажать на красивую кнопочку «Подписать» и это будет еще быстрее? Будет. Но это будет уже по другую сторону границы. Там, где контроль уже утерян. У вас есть каналы связи между базой данных и вашим компьютером и между вашим компьютером и защищенным устройством в обе стороны. Просто нажав кнопочку «Подписать» вы полагаетесь на то, что на подпись будет отправлено именно то, что в базе, а также на то, что подпись, которая в результате уйдет в базу — это именно та подпись, что выдало вам защищенное устройство. Может быть и существует схема с ЭЦП, которая дает человеку возможность контролировать эти каналы. Поправьте меня, кто лучше знает. Но пока у меня большое подозрение, что реально надежная схема с ЭЦП потребует от человека не меньше, а больше усилий, чем схема с блокчейном. Чем еще хороша моя схема, так это тем, что канал там один — ручка, бумажка. Контроль над этим каналом со стороны человека абсолютно надежен. И это очевидно даже неспециалисту.
Что касается второй претензии. Каждый раз, когда вы говорите, что проблема надуманна, где-то хлопает в ладоши от радости человек, который проделал операцию 101х110=110х101. Подумайте, быть может это в вас говорит снобизм? Как так?! Меня, такого умного, объегорит какой-то кладовщик?! Ха-ха! Вот только все меняется очень быстро. Мы уже живем в мире, где все знают все (или, по крайней мере, движемся к этому с огромной скоростью). Что такое базы данных и как с ними обращаться уже сейчас доступно каждому со школьного возраста. Особо заинтересованные и мотивированные могут нагуглить известные дыры в популярных системах и способы повышения привилегий. Хороший пример здесь 1С. То, что пароль к базе данных хранится особо не скрывается. Но и дырка по тем или иным причинам тоже не закрывается уже чуть ли не третий десяток лет. Сколько в России и около учетных систем на базе 1С? Ну и, наконец, не стоит забывать, что в любой учетной системе количество людей, которые могут делать в ней все, что хотят всегда строго больше нуля. Традиционный способ решить проблему «человеческого фактора» в такой ситуации — это дублирование и взаимный контроль. Т.е. кто-то должен контролировать человека, который может все. И это — реальная проблема
Проблему соответствия данных учетной системы реальности
Системе для функционирования может быть и не нужен, но кто-то же его знает. И с этим фактом вы ничего не поделаете
Как необязательно? Если кто-то знает админский пароль к СУБД, то он может делать в системе все, что хочет. Разве не так?
В любой учетной системе количество людей, которые могут делать в ней все, что хотят, строго больше 0.
Я не понимаю вашу позицию. Вы считаете, что проблемы нет вообще? Или что проблема есть, но она имеет лучшие решения?
Но не чаше, чем раз в день?
Затем, что 1С так реализовала трехзвенную архитектуру. Платформа для коннекта не запрашивает пароль у пользователя, а использует сохраненный

Не понял. Поясните, пожалуйста

Деталь А поставляется в коробках по 11 штук, деталь Б в коробках по 17 штук. В процессе приемки на склад часть деталей возвращаются поставщику, как бракованные. Деталь А или деталь Б могут запороть при сборке и тогда ее спишут в отходы, а со склада запросят дополнительную деталь. В реальности почти ни у кого нет такого, что количество деталей совпадает. В любом случае не стоит надеяться на то, что кладовщик — дурак. И будет брать те детали, которые легко обнаружить
Отчет делается каждый день?
Админский пароль к СУБД хранится на кластере. Собственно самого словосочетания «пароль хранится» уже достаточно
Разумеется я заглядывал. И не раз за последние 25 лет )))
Легко и непринужденно
А кто нас держит в рамках платформы? Есть база данных. В ней есть таблицы и записи. И все это придумано в том числе и для того, чтобы легко и непринужденно менять
Кто мешает делать запись не в транзакции?
А в блокчейне достаточно одной сверки на сеанс
Будет сверка контрольной фразы для каждого документа?

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity