Зачем откатывать всю базу? Вы хотите получить проверенное состояние одного документа, так получите его в копии и делайте с ним что хотите. Но даже это не является необходимым. Вам система говорит дословно следующее: вот этот вот документ следует еще раз обработать также, как вы его когда-то обрабатывали на входе
Он просто будет скорректирован контролером в полном соответствии с реальностью. Для контролера нет никакой разницы работает он с новым документом или со старым. Поймите такую простую вещь. В системе появился новый документ. Контролер берет его и проверяет. Если находит ошибки, исправляет. В системе появился исправленный документ. Контролер берет его и проверяет. Если находит ошибки, исправляет.
Если вам все же очень надо выяснить, что именно было изменено, тогда достаете проверенную версию документа из бэкапа и сравниваете. В чем вы здесь увидели проблему?
Предположим что бэкапы делаются раз в день и хранятся в течение года. В январе ввели документ. Контролер его проверил. Утром 5 декабря кто-то внес изменения в этот документ. Вечером при очередном сеансе контроля, контролер это обнаружил. У него на руках свыше 300 бэкапов, в каждом из которых хранится проверенная версия этого документа. Можно доставать из любого.
и как проверить, что объекты, созданные с момента обнаружения несанкционированного изменения, не были несанкционированно изменены.
вот это мне вообще не понятно. О каких объектах речь? Об одних и тех же? Мы что-то проверили сегодня, а назавтра это изменили? Завтра это и обнаружим, в чем вопрос?
Контролеров может быть несколько. Но дело даже не в этом.
Есть природа информации. На нее и надо опираться. После того, как информация появилась в этом мире, вы не можете с уверенностью утверждать сколько копий у этой информации и где они находятся. Информация неуничтожима в принципе. "Рукописи не горят" - это не фигура речи. Это истина в некотором высшем смысле.
Вы, как хранитель базы данных, конечно можете проявить халатность и потерять информацию навсегда. Вы можете хранить бэкапы в неправильном месте и совершать другие ошибки. Но для атакующего все это не имеет значения. У него все равно никогда не будет 100% гарантии что он знает про всех хранителей базы и про все бэкапы. У атакующего на сегодня есть только один союзник. Отсутствие системы гарантированного обнаружения. У вас, как у хранителя базы данных, все на руках. Есть бэкапы, откуда можно запросто достать правильную информацию и заменить ею неправильную в оперативной базе. Но вы этого никогда не сделаете, потому что вы просто не знаете куда смотреть, что именно искать, где вам "собаку зарыли".
Поэтому не могу с вами согласиться. Система гарантированного обнаружения изменений - это не ложная безопасность, а самая настоящая
Речь идет о привязке базы данных к реальности. Сделать это может только человек. Если у вас миллион транзакций в день, и их никто не проверяет, тогда нет предмета для разговора.
Но обычно в базах данных для бизнеса немного не так. Туда вносятся данные, назовем их документами. И каждый документ при вводе в базу проверяется на предмет соответствия реальности.
Задача, которую я решаю, заключается в том, чтобы гарантировать, что каждый документ хранится в базе данных ровно в том виде, в каком он был проверен и введен. А если документ изменяет это свое состояние, то он гарантировано переходит в категорию "не проверен" и при очередном контроле его снова проверят.
В вашем случае подпись ставится под каждым документом. В моем случае "подпись ставится" по сеансом контроля в целом. Поэтому мою схему можно реально внедрить, а вашу нет. Вашу схему можно атаковать. Как ни крути, а приватный ключ так или иначе оказывается в памяти устройства. В моем случае в памяти устройства ничего не указывается. Процесс "вывернут". Пользователь ничего не сообщает системе. Он записывает информацию на бумажку. И все. Дальше можно атаковать только бумажку
Мне казалось, что я достаточно прозрачно описал схему в статье. Но, видимо, мне пока еще не хватает мастерства.
Попробую дать полное описание сеанса контроля.
Последняя хеш-сумма в журнале сверяется с записанной на бумажке.
Запускается программа контроля.
Программа контроля создает новые записи в журнале (как для новых документов, так и для измененных или удаленных)
Контролер записывает последний хеш на бумажку. И приступает к проверке документов по списку
Вам будет проще если вы от "санкционированное/несанкционированное" перейдете к рассмотрению "проверенное/непроверенное"
Вы поняли, что из журнала ничего не удаляется и в нем ничего не меняется? Записи туда только добавляются
Вы не могли бы на примере пояснить? Я вас не понимаю
На основании реальности. Проверка документа это сверка того, что в базе и того, что в реальности
В момент появления нового документа в системе тоже нет никаких данных о нем
Зачем откатывать всю базу? Вы хотите получить проверенное состояние одного документа, так получите его в копии и делайте с ним что хотите. Но даже это не является необходимым. Вам система говорит дословно следующее: вот этот вот документ следует еще раз обработать также, как вы его когда-то обрабатывали на входе
Он просто будет скорректирован контролером в полном соответствии с реальностью. Для контролера нет никакой разницы работает он с новым документом или со старым. Поймите такую простую вещь. В системе появился новый документ. Контролер берет его и проверяет. Если находит ошибки, исправляет. В системе появился исправленный документ. Контролер берет его и проверяет. Если находит ошибки, исправляет.
Если вам все же очень надо выяснить, что именно было изменено, тогда достаете проверенную версию документа из бэкапа и сравниваете. В чем вы здесь увидели проблему?
Предположим что бэкапы делаются раз в день и хранятся в течение года. В январе ввели документ. Контролер его проверил. Утром 5 декабря кто-то внес изменения в этот документ. Вечером при очередном сеансе контроля, контролер это обнаружил. У него на руках свыше 300 бэкапов, в каждом из которых хранится проверенная версия этого документа. Можно доставать из любого.
вот это мне вообще не понятно. О каких объектах речь? Об одних и тех же? Мы что-то проверили сегодня, а назавтра это изменили? Завтра это и обнаружим, в чем вопрос?
Спасибо за ссылки!
Нет. Система прямо гарантирует обнаружение изменений. И только косвенно, через гарантированное обнаружение изменений, соответствие реальности.
Контролеров может быть несколько. Но дело даже не в этом.
Есть природа информации. На нее и надо опираться. После того, как информация появилась в этом мире, вы не можете с уверенностью утверждать сколько копий у этой информации и где они находятся. Информация неуничтожима в принципе. "Рукописи не горят" - это не фигура речи. Это истина в некотором высшем смысле.
Вы, как хранитель базы данных, конечно можете проявить халатность и потерять информацию навсегда. Вы можете хранить бэкапы в неправильном месте и совершать другие ошибки. Но для атакующего все это не имеет значения. У него все равно никогда не будет 100% гарантии что он знает про всех хранителей базы и про все бэкапы. У атакующего на сегодня есть только один союзник. Отсутствие системы гарантированного обнаружения. У вас, как у хранителя базы данных, все на руках. Есть бэкапы, откуда можно запросто достать правильную информацию и заменить ею неправильную в оперативной базе. Но вы этого никогда не сделаете, потому что вы просто не знаете куда смотреть, что именно искать, где вам "собаку зарыли".
Поэтому не могу с вами согласиться. Система гарантированного обнаружения изменений - это не ложная безопасность, а самая настоящая
... либо записываете один хеш по результатам контроля
Скажите честно. Вы в самом деле не понимаете, как работает схема? Или вам просто хочется надо мной посмеяться?
Речь идет о привязке базы данных к реальности. Сделать это может только человек. Если у вас миллион транзакций в день, и их никто не проверяет, тогда нет предмета для разговора.
Но обычно в базах данных для бизнеса немного не так. Туда вносятся данные, назовем их документами. И каждый документ при вводе в базу проверяется на предмет соответствия реальности.
Задача, которую я решаю, заключается в том, чтобы гарантировать, что каждый документ хранится в базе данных ровно в том виде, в каком он был проверен и введен. А если документ изменяет это свое состояние, то он гарантировано переходит в категорию "не проверен" и при очередном контроле его снова проверят.
Все это хорошо, но либо вы что называется ручками указываете пароль (и не 123, а настоящий) на каждую транзакцию, либо...
Система проверяет. И на выходе выдает вашему старичку: "вот смотри, была такая транзакция, о которой ты еще ничего не знаешь"
А я ее скачаю непосредственно перед запуском. И запущусь на новом устройстве
Улучшайте, улучшайте вашу схему. В конце придете к моей )))
В вашем случае подпись ставится под каждым документом. В моем случае "подпись ставится" по сеансом контроля в целом. Поэтому мою схему можно реально внедрить, а вашу нет. Вашу схему можно атаковать. Как ни крути, а приватный ключ так или иначе оказывается в памяти устройства. В моем случае в памяти устройства ничего не указывается. Процесс "вывернут". Пользователь ничего не сообщает системе. Он записывает информацию на бумажку. И все. Дальше можно атаковать только бумажку
Оповещение и защищает. Такова природа информации. Главное - узнать куда смотреть
Первичка хранится пять лет, а в оперативной базе два года. Что в принципе нормально. Не надо сравнивать все документы. Сравниваем только измененные
Все то же защищает. Удаление это всего лишь разновидность изменения