Pull to refresh
12
0.2
Калимулин Михаил Игоревич @exwill

Vision developer

Send message

Мне казалось, что я достаточно прозрачно описал схему в статье. Но, видимо, мне пока еще не хватает мастерства.

Попробую дать полное описание сеанса контроля.

  1. Последняя хеш-сумма в журнале сверяется с записанной на бумажке.

  2. Запускается программа контроля.

  3. Программа контроля создает новые записи в журнале (как для новых документов, так и для измененных или удаленных)

  4. Контролер записывает последний хеш на бумажку. И приступает к проверке документов по списку

Вам будет проще если вы от "санкционированное/несанкционированное" перейдете к рассмотрению "проверенное/непроверенное"

Вы поняли, что из журнала ничего не удаляется и в нем ничего не меняется? Записи туда только добавляются

Вы не могли бы на примере пояснить? Я вас не понимаю

На основании реальности. Проверка документа это сверка того, что в базе и того, что в реальности

В момент появления нового документа в системе тоже нет никаких данных о нем

Зачем откатывать всю базу? Вы хотите получить проверенное состояние одного документа, так получите его в копии и делайте с ним что хотите. Но даже это не является необходимым. Вам система говорит дословно следующее: вот этот вот документ следует еще раз обработать также, как вы его когда-то обрабатывали на входе

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

Если вам все же очень надо выяснить, что именно было изменено, тогда достаете проверенную версию документа из бэкапа и сравниваете. В чем вы здесь увидели проблему?

Предположим что бэкапы делаются раз в день и хранятся в течение года. В январе ввели документ. Контролер его проверил. Утром 5 декабря кто-то внес изменения в этот документ. Вечером при очередном сеансе контроля, контролер это обнаружил. У него на руках свыше 300 бэкапов, в каждом из которых хранится проверенная версия этого документа. Можно доставать из любого.

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

вот это мне вообще не понятно. О каких объектах речь? Об одних и тех же? Мы что-то проверили сегодня, а назавтра это изменили? Завтра это и обнаружим, в чем вопрос?

Нет. Система прямо гарантирует обнаружение изменений. И только косвенно, через гарантированное обнаружение изменений, соответствие реальности.

Контролеров может быть несколько. Но дело даже не в этом.

Есть природа информации. На нее и надо опираться. После того, как информация появилась в этом мире, вы не можете с уверенностью утверждать сколько копий у этой информации и где они находятся. Информация неуничтожима в принципе. "Рукописи не горят" - это не фигура речи. Это истина в некотором высшем смысле.

Вы, как хранитель базы данных, конечно можете проявить халатность и потерять информацию навсегда. Вы можете хранить бэкапы в неправильном месте и совершать другие ошибки. Но для атакующего все это не имеет значения. У него все равно никогда не будет 100% гарантии что он знает про всех хранителей базы и про все бэкапы. У атакующего на сегодня есть только один союзник. Отсутствие системы гарантированного обнаружения. У вас, как у хранителя базы данных, все на руках. Есть бэкапы, откуда можно запросто достать правильную информацию и заменить ею неправильную в оперативной базе. Но вы этого никогда не сделаете, потому что вы просто не знаете куда смотреть, что именно искать, где вам "собаку зарыли".

Поэтому не могу с вами согласиться. Система гарантированного обнаружения изменений - это не ложная безопасность, а самая настоящая

... либо записываете один хеш по результатам контроля

Скажите честно. Вы в самом деле не понимаете, как работает схема? Или вам просто хочется надо мной посмеяться?

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

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

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

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

Система проверяет. И на выходе выдает вашему старичку: "вот смотри, была такая транзакция, о которой ты еще ничего не знаешь"

А я ее скачаю непосредственно перед запуском. И запущусь на новом устройстве

Улучшайте, улучшайте вашу схему. В конце придете к моей )))

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

Оповещение и защищает. Такова природа информации. Главное - узнать куда смотреть

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

Все то же защищает. Удаление это всего лишь разновидность изменения

Information

Rating
2,607-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity