Как стать автором
Обновить
12
3
Калимулин Михаил Игоревич @exwill

Vision developer

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

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

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

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

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

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

Информация

В рейтинге
1 040-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность