Я вам как практик говорю. Эта схема работающая. В отличие от вашей, не обижайтесь. У вас максимум человеческих усилий. Каждую транзакцию надо подписать. Это означает ввод надежного пароля (и не через буфер обмена, а ручками).
А у меня контролер, по большей части, просто наблюдатель.
Просто я сосредоточился на гарантированном обнаружении изменений и сверки с реальностью. Упустил из виду, что после выявления расхождения с реальностью, происходит корректировка документа. И тут, да, есть возможность после исправления документа (приведения его в соответствии с реальностью), вернуть его к прежнему состоянию. Возникает зеркальная задача. Обнаружить не изменение, а отсутствие изменения. Журнал это позволяет сделать. Контролер протоколирует изменения, которые он делает сам, лично или поручает сделать. А на следующий день сверяется с этим протоколом.
Хотел сразу же ответить, что контролер уйдет проверять с данными полученными с помощью журнала. В них он и будет смотреть в процессе контроля, а не в базу.
Но вы хорошо подметили, что контролировать надо не только присутствие, но и присутствие отсутствия.
Действительно процедуру контроля в последнем пункте:
Контролер записывает новую хеш-сумму и уходит проверять документы по списку.
надо описать подробнее. Контроль начинается с того, что контролер проверяет наличие в списке документов, которые он изменял в прошлый раз
Это не будет работать. Я вам объясню почему. Вы правильно понимаете, что источником верификации является человеческое внимание. Но вы не понимаете, что при каждом акте контроля, человек должен верифицировать не отдельный документ атомарно, а всю базу в целом.
Атомарно означает, что кто-то другой может добавить "атом" к общей картине. И этот "атом" будет зафиксирован в хранилище строго по вашей схеме. И в дальнейшем будет проходить все проверки.
У конкретного человека должно быть на руках доказательство, что ничто не прошло мимо его внимания. "Его внимания" - ключевые слова.
Атомарно - это хорошо. На каждый документ бэкап. 100 документов - 100 бэкапов. А что с чем сравниваться то будет? Первый бэкап, последний? Каждый? Сравниваться с чем? С первым? последним? каждым? А если не атомарно? Контролер сидит, проверяет 100 документов. Дело не быстрое. В тот момент, когда он добирается до 63 документа, кто-то подменяет 5. И что тогда? Мне ваша схема не понятна. Как мне кажется, она не работоспособна.
Я же вам обрисовал схему простую, прозрачную и работоспособную.
Контролер сверяет хеш-сумму журнала и свою запись
Контролер запускает программу проверки
Программа проверки достраивает журнал и на выходе дает новую хеш-сумму и список измененных объектов.
Контролер записывает новую хеш-сумму и уходит проверять документы по списку.
Видите? Здесь акт контроля происходит мгновенно, без зазора. Здесь просто некуда влезть.
Несхождение чего с чем? Документа в базе с документом в бэкапе? У нас таких много. В бухгалтерской базе постоянно меняются документы. И "задним числом" тоже. Как вы отличите документ, который правильно изменен от действий злоумышленника?
Вот смотрите. Бухгалтерская база. Бэкапы делаются ежедневно и хранятся год. Сегодня у нас 8 декабря. 1 декабря кто-то поменял приходный документ от 20 июля. И сделал это так, что изменение не прошло ни по каким журналам транзакции. Теперь у нас что-то около 100 бэкапов с правильным документом и 6 или 7 бэкапов с неправильным.
А теперь расскажите, пожалуйста, как вы поймаете эту ситуацию? Конкретно?
Сохранение бэкапа в Яндексе в принципе аналогично сохранение на неперезаписываемый лазерный диск. Что можно сделать с таким диском? Только сломать. Что можно сделать с бэкапом в Яндексе? Перезаписать? Это все равно, что сломать. Что бы вы ни делали, вы не сможете заставить меня воспользоваться непроверенными данными. В этом смысле моя защита абсолютна.
Сделать безопасное резервное копирование - это не проблема. Вы не туда смотрите. Сейчас большинство баз нормально "обэкаплены", грамотных админов достаточно. Сейчас другая проблема. Обнаружение. Кто-то взял и поменял данные. И постарался сделать так, чтобы никто не заметил. У вас все на руках. Есть бэкапы с правильными данными. Вы могли бы исправить ситуацию. Но для начала вам надо о ней хотя бы узнать
Кто вам мешает сделать надежный бэкап? Довольно давно я лично видел у одного моего клиента дневные бэкапы на неперезаписываемых лазерных дисках. Дешево и сердито. Сейчас в этом нет необходимости. Положили бэкап на тот же Яндекс-диск и все. Что вы с ним сделаете?
Я вам как практик говорю. Эта схема работающая. В отличие от вашей, не обижайтесь. У вас максимум человеческих усилий. Каждую транзакцию надо подписать. Это означает ввод надежного пароля (и не через буфер обмена, а ручками).
А у меня контролер, по большей части, просто наблюдатель.
Протокол на бумаге. Его не атакуешь.
Просто я сосредоточился на гарантированном обнаружении изменений и сверки с реальностью. Упустил из виду, что после выявления расхождения с реальностью, происходит корректировка документа. И тут, да, есть возможность после исправления документа (приведения его в соответствии с реальностью), вернуть его к прежнему состоянию. Возникает зеркальная задача. Обнаружить не изменение, а отсутствие изменения. Журнал это позволяет сделать. Контролер протоколирует изменения, которые он делает сам, лично или поручает сделать. А на следующий день сверяется с этим протоколом.
Хотел сразу же ответить, что контролер уйдет проверять с данными полученными с помощью журнала. В них он и будет смотреть в процессе контроля, а не в базу.
Но вы хорошо подметили, что контролировать надо не только присутствие, но и присутствие отсутствия.
Действительно процедуру контроля в последнем пункте:
Контролер записывает новую хеш-сумму и уходит проверять документы по списку.
надо описать подробнее. Контроль начинается с того, что контролер проверяет наличие в списке документов, которые он изменял в прошлый раз
Совершенно верно
Это не будет работать. Я вам объясню почему. Вы правильно понимаете, что источником верификации является человеческое внимание. Но вы не понимаете, что при каждом акте контроля, человек должен верифицировать не отдельный документ атомарно, а всю базу в целом.
Атомарно означает, что кто-то другой может добавить "атом" к общей картине. И этот "атом" будет зафиксирован в хранилище строго по вашей схеме. И в дальнейшем будет проходить все проверки.
У конкретного человека должно быть на руках доказательство, что ничто не прошло мимо его внимания. "Его внимания" - ключевые слова.
Не все споры в интернете бесплодны. Спасибо за интересный сценарий! Есть над чем подумать
Кроме того, что оно работает, а ваше нет. Если быть точным, скорее всего нет. Вы ведь так и не описали ваш алгоритм контроля по шагам
Следующий сеанс контроля вынесет этот документ в список измененных.
Программа проверки, достраивая журнал, гарантировано добавит запись с этим документом.
Атомарно - это хорошо. На каждый документ бэкап. 100 документов - 100 бэкапов. А что с чем сравниваться то будет? Первый бэкап, последний? Каждый? Сравниваться с чем? С первым? последним? каждым? А если не атомарно? Контролер сидит, проверяет 100 документов. Дело не быстрое. В тот момент, когда он добирается до 63 документа, кто-то подменяет 5. И что тогда? Мне ваша схема не понятна. Как мне кажется, она не работоспособна.
Я же вам обрисовал схему простую, прозрачную и работоспособную.
Контролер сверяет хеш-сумму журнала и свою запись
Контролер запускает программу проверки
Программа проверки достраивает журнал и на выходе дает новую хеш-сумму и список измененных объектов.
Контролер записывает новую хеш-сумму и уходит проверять документы по списку.
Видите? Здесь акт контроля происходит мгновенно, без зазора. Здесь просто некуда влезть.
Контролер поверил документ и зафиксировал. Сразу после проверки злоумышленник его изменил. Что с чем вы будете сравнивать?
С 20 по 25 изменения в документе допускаются. Как вы отличите "правильные" от "неправильных"?
Несхождение чего с чем? Документа в базе с документом в бэкапе? У нас таких много. В бухгалтерской базе постоянно меняются документы. И "задним числом" тоже. Как вы отличите документ, который правильно изменен от действий злоумышленника?
Сравнить - проблема. В этом ваша ключевая ошибка.
Вот смотрите. Бухгалтерская база. Бэкапы делаются ежедневно и хранятся год. Сегодня у нас 8 декабря. 1 декабря кто-то поменял приходный документ от 20 июля. И сделал это так, что изменение не прошло ни по каким журналам транзакции. Теперь у нас что-то около 100 бэкапов с правильным документом и 6 или 7 бэкапов с неправильным.
А теперь расскажите, пожалуйста, как вы поймаете эту ситуацию? Конкретно?
Сохранение бэкапа в Яндексе в принципе аналогично сохранение на неперезаписываемый лазерный диск. Что можно сделать с таким диском? Только сломать. Что можно сделать с бэкапом в Яндексе? Перезаписать? Это все равно, что сломать. Что бы вы ни делали, вы не сможете заставить меня воспользоваться непроверенными данными. В этом смысле моя защита абсолютна.
Сделать безопасное резервное копирование - это не проблема. Вы не туда смотрите. Сейчас большинство баз нормально "обэкаплены", грамотных админов достаточно. Сейчас другая проблема. Обнаружение. Кто-то взял и поменял данные. И постарался сделать так, чтобы никто не заметил. У вас все на руках. Есть бэкапы с правильными данными. Вы могли бы исправить ситуацию. Но для начала вам надо о ней хотя бы узнать
Нет. Вы не можете сверять данные с бэкапами. Потому что вы не знаете что и с чем сверять. Собственно описываемая мною схема и решает этот вопрос.
А дату записи вы тоже попросите поменять? У кого? У админов Яндекса?
Кто вам мешает сделать надежный бэкап? Довольно давно я лично видел у одного моего клиента дневные бэкапы на неперезаписываемых лазерных дисках. Дешево и сердито. Сейчас в этом нет необходимости. Положили бэкап на тот же Яндекс-диск и все. Что вы с ним сделаете?
Никто нас не заставляет хранить в журнале абсолютно всю информацию. Количество и сумму храним а комментарий не храним, например
Из бэкапа
Очень интересно. Скажите, там у вас были контролеры? Имеются ввиду люди