Комментарии 167
Чтобы нельзя было поменять данные - подписывай поля, строки, таблицы цифровой подписью - криптография рулит (и без модных наворотов вроде блокчейна - это всего лишь частный случай)
Как минимум, это не защищает от удаления
таблицы цифровой подписью
В какой момент и что именно вы будете подписывать цифровой подписью относительно таблицы в целом? Количество записей?
Контрольная сумма строки = Конкатенация Контрольный сумм полей
Контрольная суммы таблицы = Конкатенация Контрольных сумм строк
Подпись таблицы = Персональный закрытый ключ применённый к Контрольной сумме таблицы
Это вообще-то базовые знания для специалиста пишущего в Информационную безопастность
Конкатенация - это не обязательно сцепление строк, можно контрольную сумму от контрольных сумм
И что? Вот проверили-подписали вы таблицу по вашей схеме. К моменту следующей проверки в таблице 5 записей добавили, 3 удалили, 8 изменили. Что вам даст подпись таблицы?
Если к моменту следующе проверки в таблице 5 записей добавили, 3 удалили, 8 изменили - то подпись не верна - что вы и хотели в самом начале разговора - проверить что данные не искажены.
Но если пойти ещё дальше - при каждом изменении все что изменилось пересчитывать и подписывать персональным сертификатом пользователя и это логировать - то брюки превращаются...превращаюся - в базу где всегда можно понять кто внёс изменения с возможностью обсуждать это в суде
Да, конечно, если каждую транзакцию подписывать ЭЦП, то... Но вы же сами понимаете, что такая схема нежизнеспособна в отличие от предложенной
Просто подсчитав контрольную сумму и не подписав её не установишь факт внесения изменений - злоумышленник имеющий возможность внести измения в данные также может сам пересчитать контрольную сумму и записать её поверх старой в логах (даже если ему придётся переписать всю историю лога)
Нет ресурсов - и не поднимай вопросы с безопастностью - это не дешёвое удовольствие
Но вы же сами понимаете, что такая схема нежизнеспособна в отличие от предложенной
Почему? Я вот не понимаю, чем она менее жизнеспособна.
Тем, что надо подписывать каждую транзакцию
Поясните что нежизнеспособного в подписывании каждой транзакции? Чем это хуже других программных действий? Да надо технику подороже, чтобы не тормозило, поднять инфраструктуру связанную с ЭЦП... это у вас нежизнеспособно - поскольку денег нет?
Я все еще не понимаю, что в этом менее жизнеспособного, чем хэширование каждой транзакции?
А хешировать может система. При условии, что на конце цепочки появляется все тот же человек с ручкой и бумажкой.
Предлагаю исключить из этой схемы бездушные железные машины, которые так легко обмануть. Оставим вахтера с бумажкой. И берданку ему дадим.
Электронные подписи тоже может генерить система. То, что изменено человеком - будет с его подписью, все остальное - с системной.
В вашем случае подпись ставится под каждым документом. В моем случае "подпись ставится" по сеансом контроля в целом. Поэтому мою схему можно реально внедрить, а вашу нет. Вашу схему можно атаковать. Как ни крути, а приватный ключ так или иначе оказывается в памяти устройства. В моем случае в памяти устройства ничего не указывается. Процесс "вывернут". Пользователь ничего не сообщает системе. Он записывает информацию на бумажку. И все. Дальше можно атаковать только бумажку
В моем случае "подпись ставится" по сеансом контроля в целом.
Непонятно, как вы это организуете технически, чтобы "сеанс контроля" захватывал все изменения в нем.
Как ни крути, а приватный ключ так или иначе оказывается в памяти устройства.
Вы про внешние аппаратные ключи не слышали?
Он записывает информацию на бумажку. И все.
Записать результат электронной подписи на бумажку, как ни странно, все еще возможно, так что эта часть не теряется.
Улучшайте, улучшайте вашу схему. В конце придете к моей )))
Как ни крути, а приватный ключ так или иначе оказывается в памяти устройства.
А вы хэш считаете в уме для каждой строки? Ваша программа для подсчета тоже в памяти устройства оказывается. И на нее тоже можно атаку устроить. И выводить результат какой угодно чтобы вы на бумажку писали.
А я ее скачаю непосредственно перед запуском. И запущусь на новом устройстве
Есть танцы с бубном в виде криптосерверов и неизвлекаемой памяти. Продают такие девайсы.
Мне кажется, вы тут, коллеги, изобретаете блокчейн.
от конца света не защитит
Гм... а что защищает? впрочем, и автор только в заголовке говорит о защите. А по тексту он всего лишь устанавливает факт внесения изменений.
А это и есть защита. Такова природа информации. Установив факт, я восстановлю информацию так или иначе
А что защищает от удаления?
Вообще, похоже, статья больше про оповещение, а не про защиту.
Организовать такую защиту технически несложно.
Как человек, который как-то участвовал в разработке системы, где объекты подписывались ЭЦП, хочу заметить, что "не сложно" - это некоторое, гм, упрощение. В реальности там достаточно много подводных камней, благодаря которым система получается громоздкая и медленная.
При минимальной осмотрительности можно гарантировать обнаружение любых изменений, даже тех, что сделаны пользователем с правами администратора базы данных.
Неа. Вы можете гарантировать обнаружение факта таких изменений, но далеко не всегда - самих изменений. Т.е. вы сможете сказать "у меня тут не сошлась подпись всего", но вот почему - не сможете.
PS А еще меня не покидает ощущение, что ровно про такую же схему, с записью кода на бумажку, на хабре уже обсуждали.
Допустим, Ваша схема работает. Мне надо поменять данные за 2000000 транзакций назад. Я меняю эти данные и пересчитываю все хеш-суммы по настоящее время (я же имею полный доступ к базе, так почему бы и да?). Последняя, естественно, с эталоном не совпадёт.
Теперь Вы достоверно знаете, что в базу влезли (Ваша королевская хеш-сумма не совпадает). И что? В какой именно записи сделано изменение? Вся последовательность пересчитана, и, не располагая копией базы без внесенных изменений установить это невозможно.
Вы даже не знаете, когда примерно произошло вторжение...
В этом случае я просто откатываюсь к предыдущей точке контроля. Да, неприятно. Но можно сделать контроль почаще.
Вы не учли, что если взять ту же торговую базу, где я таким образом украл 9 единиц товара (была продажа 1 шт за 10 руб, а я сделал 10 шт по рублю, а 9 "лишних", образовавшихся на складе - украл), то 2 миллиона транзакций - это запросто может быть и 2-3 года назад. Мне всё равно, когда править данные, лишь бы остаток на складе, указанный в базе, изменился. Вы будете откатываться на 3 года назад?
Нет. Вы не поняли. Я не буду откатывать базу. Я откачу журнал к предыдущему состоянию
К какому, и где вы его возьмете?
Из бэкапа
Так бэкап-то точно так же скомпроментирован, как и оригинал (и еще и не факт, что у вас есть инструмент это определить).
Кто вам мешает сделать надежный бэкап? Довольно давно я лично видел у одного моего клиента дневные бэкапы на неперезаписываемых лазерных дисках. Дешево и сердито. Сейчас в этом нет необходимости. Положили бэкап на тот же Яндекс-диск и все. Что вы с ним сделаете?
Кто вам мешает сделать надежный бэкапы?
А если никто мне не мешает сделать надежный бэкап, то мне не нужна ваша схема, я могу сверять данные с бэкапами.
Положили бэкап на тот же Яндекс-диск и все. Как вы его будете компрометировать?
Очень просто: запишу туда измененные данные. Вы же предполагаете полный админский доступ к БД, так почему вы не предполагаете такого же доступа к тем местам, где находится бэкап?
Нет. Вы не можете сверять данные с бэкапами. Потому что вы не знаете что и с чем сверять. Собственно описываемая мною схема и решает этот вопрос.
А дату записи вы тоже попросите поменять? У кого? У админов Яндекса?
Нет. Вы не можете сверять данные с бэкапами. Потому что вы не знаете что и с чем сверять.
Да нет, я как раз знаю: сверять надо все. В вашей схеме невозможно определить, что сверять, только факт, что надо запустить сверку.
А дату записи вы тоже попросите поменять? У кого? У админов Яндекса?
"Я не знаю, почему дата поменялась, спросите у Яндекса".
Сохранение бэкапа в Яндексе в принципе аналогично сохранение на неперезаписываемый лазерный диск. Что можно сделать с таким диском? Только сломать. Что можно сделать с бэкапом в Яндексе? Перезаписать? Это все равно, что сломать. Что бы вы ни делали, вы не сможете заставить меня воспользоваться непроверенными данными. В этом смысле моя защита абсолютна.
Сделать безопасное резервное копирование - это не проблема. Вы не туда смотрите. Сейчас большинство баз нормально "обэкаплены", грамотных админов достаточно. Сейчас другая проблема. Обнаружение. Кто-то взял и поменял данные. И постарался сделать так, чтобы никто не заметил. У вас все на руках. Есть бэкапы с правильными данными. Вы могли бы исправить ситуацию. Но для начала вам надо о ней хотя бы узнать
Что можно сделать с бэкапом в Яндексе? Перезаписать? Это все равно, что сломать.
Нет, не "все равно". У вас нет гарантированного способа отличить валидную перезапись от невалидной.
С чем конкретно вы будете сравнивать дату записи (это если предположить на мгновение, что Яндекс не позволяет ее спуфить)?
Сделать безопасное резервное копирование - это не проблема.
Если это не проблема, то не проблема и сравнить данные с бэкапом.
Кто-то взял и поменял данные. [...] Но для начала вам надо о ней хотя бы узнать
Если такая ситуация есть в модели угроз системы, то в системе есть механизм рутиннной автоматической сверки с данными в защищенном хранилище.
Точно так же как, например, в хороших системах хранения бэкапов есть механизм рутинной валидации, что бэкап не испортился.
Сравнить - проблема. В этом ваша ключевая ошибка.
Вот смотрите. Бухгалтерская база. Бэкапы делаются ежедневно и хранятся год. Сегодня у нас 8 декабря. 1 декабря кто-то поменял приходный документ от 20 июля. И сделал это так, что изменение не прошло ни по каким журналам транзакции. Теперь у нас что-то около 100 бэкапов с правильным документом и 6 или 7 бэкапов с неправильным.
А теперь расскажите, пожалуйста, как вы поймаете эту ситуацию? Конкретно?
А теперь расскажите, пожалуйста, как вы поймаете эту ситуацию?
Предположим, что у нас рутинная проверка раз в месяц, пятого числа (хотя на самом деле, не важно, какого). 5 декабря она сравнит данные за 20 июля с защищенным хранилищем и обнаружит несхождение.
Несхождение чего с чем? Документа в базе с документом в бэкапе? У нас таких много. В бухгалтерской базе постоянно меняются документы. И "задним числом" тоже. Как вы отличите документ, который правильно изменен от действий злоумышленника?
Я исхожу из того, что приходный документ идет по некоему процессу, этапы которого фиксируются, как и состояние документа на каждом процессе. Вот у нас был приходный документ, его сначала 20 июля ввели, а потом 25 - "провели" (на моем слуху термин "Released" либо "Posted"), не знаю, как это по-русски. После этого никакие его изменения невозможны, возможны только новые корректирующие документы. Это состояние фиксируется в защищенном хранилище, и с ним мы и сравниваем.
С 20 по 25 изменения в документе допускаются. Как вы отличите "правильные" от "неправильных"?
Никак, они все равно все будут проверены 25-го в момент фиксации документа.
Контролер поверил документ и зафиксировал. Сразу после проверки злоумышленник его изменил. Что с чем вы будете сравнивать?
Сразу после проверки, но до фиксации в защищенном хранилище? Тогда сравнивать не с чем. Если такой риск есть в модели угроз, и он считается значимым, фиксация в защищенное хранилище будет одновременно (и, предпочтительно, атомарно) с проверкой контролером.
А как предлагаемый вами подход решает эту проблему?
Атомарно - это хорошо. На каждый документ бэкап. 100 документов - 100 бэкапов. А что с чем сравниваться то будет? Первый бэкап, последний? Каждый? Сравниваться с чем? С первым? последним? каждым? А если не атомарно? Контролер сидит, проверяет 100 документов. Дело не быстрое. В тот момент, когда он добирается до 63 документа, кто-то подменяет 5. И что тогда? Мне ваша схема не понятна. Как мне кажется, она не работоспособна.
Я же вам обрисовал схему простую, прозрачную и работоспособную.
Контролер сверяет хеш-сумму журнала и свою запись
Контролер запускает программу проверки
Программа проверки достраивает журнал и на выходе дает новую хеш-сумму и список измененных объектов.
Контролер записывает новую хеш-сумму и уходит проверять документы по списку.
Видите? Здесь акт контроля происходит мгновенно, без зазора. Здесь просто некуда влезть.
На каждый документ бэкап. 100 документов - 100 бэкапов.
Эээ, откуда вы это взяли? Я очень аккуратно же писал: фиксация в защищенном хранилище. Это не бэкапы как таковые.
А что с чем сравниваться то будет?
Сравниваться будет зафиксированное в защищенном хранилище состояние документа с актуальным состоянием документа в БД.
В тот момент, когда он добирается до 63 документа, кто-то подменяет 5. И что тогда?
Пятый документ уже зафиксирован, акт его подмены будет обнаружен.
Контролер записывает новую хеш-сумму и уходит проверять документы по списку.
В этот момент кто-то подменяет один из документов. Что дальше?
Следующий сеанс контроля вынесет этот документ в список измененных.
Программа проверки, достраивая журнал, гарантировано добавит запись с этим документом.
Следующий сеанс контроля вынесет этот документ в список измененных.
Ну то есть никаких преимущество по сравнению с тем, что я описал.
Кроме того, что оно работает, а ваше нет. Если быть точным, скорее всего нет. Вы ведь так и не описали ваш алгоритм контроля по шагам
Если быть точным, скорее всего нет.
Если быть точным, вы не знаете.
Вы ведь так и не описали ваш алгоритм контроля по шагам
Нет никакого выделенного "контроля". Есть этап фиксации и рутинный процесс верификации. Фиксируется каждый документ, атомарно, человеком. Информация об этом - в момент фиксации - заносится в защищенное хранилище вместе с состоянием документа на этот момент. Дальше уже согласно регламенту (который зависит от того, сколько у нас ресурсов и насколько быстро мы хотим обнаруживать проблемы) система в автоматическом режиме сверяет состояние документа локально и в защищенном хранилище.
Это не будет работать. Я вам объясню почему. Вы правильно понимаете, что источником верификации является человеческое внимание. Но вы не понимаете, что при каждом акте контроля, человек должен верифицировать не отдельный документ атомарно, а всю базу в целом.
Атомарно означает, что кто-то другой может добавить "атом" к общей картине. И этот "атом" будет зафиксирован в хранилище строго по вашей схеме. И в дальнейшем будет проходить все проверки.
У конкретного человека должно быть на руках доказательство, что ничто не прошло мимо его внимания. "Его внимания" - ключевые слова.
У конкретного человека должно быть на руках доказательство, что ничто не прошло мимо его внимания. "Его внимания" - ключевые слова.
Вообще, конечно, именно в этот момент достается ассиметричная криптография, которая позволяет человеку гарантировать, что именно он совершил действие (фиксацию документа). Все документы, зафиксированные кем-то другим - невалидные. Что характерно, прекрасно масштабируется на ситуацию, когда контролеров много (у вас такой случай вообще не рассматривается, а для предприятий он весьма распространен).
Но если вы настолько против подписей, то можно сделать и на стороне защищенного хранилища, просто к API "зафиксировать состояние" добавится API "лично я просмотрел такой-то документ".
Здесь просто некуда влезть.
Вот вам еще один сценарий:
Контролер сверяет хеш-сумму журнала и свою запись
Атакующий подменяет документ
Контролер запускает программу проверки
Программа проверки достраивает журнал и на выходе дает новую хеш-сумму и список измененных объектов (хэш-сумма построена по измененному объекту)
Атакующий подменяет документ на валидный
Контролер записывает новую хеш-сумму и уходит проверять документы по списку (он видит валидный объект)
После проверки атакующий заменяет объект обратно, хэш-сумма сходится
Не все споры в интернете бесплодны. Спасибо за интересный сценарий! Есть над чем подумать
Хотел сразу же ответить, что контролер уйдет проверять с данными полученными с помощью журнала. В них он и будет смотреть в процессе контроля, а не в базу.
Но вы хорошо подметили, что контролировать надо не только присутствие, но и присутствие отсутствия.
Действительно процедуру контроля в последнем пункте:
Контролер записывает новую хеш-сумму и уходит проверять документы по списку.
надо описать подробнее. Контроль начинается с того, что контролер проверяет наличие в списке документов, которые он изменял в прошлый раз
Хотел сразу же ответить, что контролер уйдет проверять с данными полученными с помощью журнала.
То есть у вас программа журналирования каким-то неизвестным образом выдает все данные для проверки?
Контроль начинается с того, что контролер проверяет наличие в списке документов, которые он изменял в прошлый раз
Что такое "документы, которые он изменял в прошлый раз"? Откуда контролер их знает?
Просто я сосредоточился на гарантированном обнаружении изменений и сверки с реальностью. Упустил из виду, что после выявления расхождения с реальностью, происходит корректировка документа. И тут, да, есть возможность после исправления документа (приведения его в соответствии с реальностью), вернуть его к прежнему состоянию. Возникает зеркальная задача. Обнаружить не изменение, а отсутствие изменения. Журнал это позволяет сделать. Контролер протоколирует изменения, которые он делает сам, лично или поручает сделать. А на следующий день сверяется с этим протоколом.
Контролер протоколирует изменения, которые он делает сам, лично или поручает сделать. А на следующий день сверяется с этим протоколом.
Вот у вас и появилась новая точка атаки - "протокол изменений которые надо сделать".
Так что, повторюсь, вы по сути описываете систему с защищенным хранилищем, с которым ведется сверка, только зачем-то еще к этому защищенному хранилищу добавили контроль состояния этого хранилища (которое защищенное!) через бумажку. Ну... если хочется, то можно. Ничего радикально это уже не изменит.
Проблемы - они все равно будут раньше, на том этапе, где надо реализовать это самое защищенное хранилище и сверку с ним разумными ресурсами.
Протокол на бумаге. Его не атакуешь.
Во-первых, даже бумагу можно атаковать. Во-вторых, бумага - это неудобно, потому что теперь нужен принтер. В-третьих, начиная с определенного числа изменений это просто перестанет работать.
Собственно, "начиная с определенного числа" - это основной недостаток вашего подхода. Он не масштабируется.
Я вам как практик говорю. Эта схема работающая. В отличие от вашей, не обижайтесь. У вас максимум человеческих усилий. Каждую транзакцию надо подписать. Это означает ввод надежного пароля (и не через буфер обмена, а ручками).
А у меня контролер, по большей части, просто наблюдатель.
Я вам как практик говорю. Эта схема работающая.
На каком объеме данных?
Я же не говорю, что она не работает (хотя, скажем, вариант с распечаткой вы явно еще не могли проверить, вы его только что придумали). Я говорю, что она не масштабируется.
У вас максимум человеческих усилий. Каждую транзакцию надо подписать. Это означает ввод надежного пароля (и не через буфер обмена, а ручками).
Это с чего вы это взяли?
А у меня контролер, по большей части, просто наблюдатель.
Если он "просто наблюдатель", то он ничего не проверяет.
Объем тут не при чем. И в вашей и в моей схеме человек сверяет документы с реальностью. Этот объем работы одинаков для обоих схем. Вопрос в том, что дальше. Любой акт контроля со стороны человека требует усилий. Система сама себя не проконтролирует. Ваша схема требует дополнительных усилий от человека для каждой транзакции. А моя для сеанса. В вашей схеме придется каждый раз вводить не менее 12 знаков пароля. А в моей достаточно просто один раз сфотографировать хеш-сумму.
Этот объем работы одинаков для обоих схем.
С чего бы? В "моей" схеме (на самом деле, не моей, но не суть) сверяются только те документы, которые попадают на фиксацию, и они могут сверяться разными людьми. Как в вашей схеме работают несколько контролеров?
В вашей схеме придется каждый раз вводить не менее 12 знаков пароля.
Нет, не придется. С чего вы это взяли?
С того, что вы уже раз 100 сказали, что не придется. Но при этом не сказали как этого достичь. Пока ваши утверждения выглядят голословными.
Пока ваши утверждения выглядят голословными.
Извините за прямоту, но пока голословным выглядит ваше утверждение, что придется вводить не менее 12 знаков пароля.
Зачем их вводить? Куда?
Чтобы подписать транзакцию
Во-первых, я не говорил, что подпись транзакции обязательна. Если у вас система с обязательными подписями, тогда скорее всего можно обойтись без защищенного хранилища (хотя с ним все еще будет проще делать какие-то вещи).
А во-вторых, чтобы подписать транзакцию, даже если подпись обязательна, не обязательно вводить пароль, и уж тем более не обязательно его вводить каждый раз. Есть внешние носители ключа, есть биометрия, есть подтверждение через второй фактор.
А к внешнему носителю пароль не нужен?
Во-первых, не обязательно нужен. Во-вторых, его не обязательно вводить для каждой транзакции.
Как интересно. Воткнул флешку и получил миллион подписей. Очень удобно, действительно! Но почему вы на этом останавливаетесь? Можно же еще проще сделать. В момент ввода в эксплуатацию базы данных, сказать: "подписываю все!"
Это еще более удобно.
Контроль - это действие человека, приходящее в систему извне. Система сама себя не проконтролирует.
Воткнул флешку и получил миллион подписей. Очень удобно, действительно! Но почему вы на этом останавливаетесь?
Я на этом не останавливаюсь, потому что это не то, что я предлагаю. Не надо сражаться с пугалами.
Контроль - это действие человека, приходящее в систему извне.
Ну да, поэтому фиксация документа - это явное действие конкретного человека. То, какие меры принимает система для аутентификации этого человека - это вопрос рисков, которые были заложены при разработке системы, и компромиса защитных мер и удобства пользователя.
Вот поэтому я и предлагаю систему, которая не требует компромиссов.
Да нет, она тоже требует компромисса - вы получаете (неизвестное пока) увеличение безопасности в обмен на усилия пользователя (которому нужно переписывать и сверять коды с бумажкой).
Я уже спрашивал, но повторю еще раз: как ваша "бескомпромиссная" система будет работать, когда число документов, которые надо проверить, превысит то, которое может обработать один человек?
Ну сейчас у всех смартфоны. Щелкнул фото - считай переписал.
Объем работ тут не причем. Я не заставляю пользователя делать ничего сверх того, что он и так всегда делает (кроме фото ключа и сверки один раз за сеанс). Документы же все равно проверяются, "системно" или "бессистемно"
Ну сейчас у всех смартфоны. Щелкнул фото - считай переписал.
Вопрос не в том, чтобы записать. Вопрос в том, чтобы сверить.
Объем работ тут не причем. Я не заставляю пользователя делать ничего сверх того, что он и так всегда делает
Так я еще раз спрошу: как ваша система будет работать, когда проверяющих больше одного?
Каждый будет отвечать за свой кусок. В чем проблема? Как подменять людей в отпуске? Отправил сменщику фото со смартфона, считай тебя подменили
Каждый будет отвечать за свой кусок. В чем проблема?
Во-первых, как поделить куски?
Во-вторых, и это важнее - как гарантировать, что нет непроверенных документов "между" этими кусками?
В общем случае оба этих вопроса сводятся к "как одному человеку быть уверенным в том, что некий документ проверен другим человеком".
Ну так изменены данные стопицот точек контроля назад... а вы все старые-то бумажки с хэшами давно выбросили - ибо
для надежного контроля нам достаточно запомнить одну, последнюю.
Откатываться к началу времён, что ли? или под откатом вы разумеете полное восстановление из бэкапа? Тогда это не просто неприятно, это куда как хуже. Данных много, восстановление длинное, работа стоит, клиенты недовольны..
Получается, что основа защиты всё же лежит в административной плоскости. Строгий контроль за правами доступа, журналирование в независимое местоположение, исключение физического доступа и так далее..
Немного непонятно, что делать, если необходимо восстановить старое состояние измененного объекта. Для этого же нужно, чтобы в базу не вносились изменения с момента обнаружения изменения и до момента восстановления, или как?
Об этом автор видимо ещё не думал ;)
А зачем вам старое состояние объекта? Нужно ведь не "старое", а такое, которое соответствует реальности. Система фиксирует факт изменения и переводит объект в разряд требующих проверки. А контролер производит проверку. Процесс проверки означает сверку с первичными документами, а не с каким-то состоянием в базе данных
Обычно первичные документы хранятся лет пять (или по инструкции) - за пределами (а обычно и меньше) сверять уже нет с чем.
А ваша схема не отвечат на вопрос какое было изменение - вы в своём уме сравнивать ВСЕ документы? Это будет один из видов атаки от конкурента - заставить вас тратить свои ресурсы на сравнение ВСЕХ документов
Ну так старое же соответствовало реальности, ваша система же это гарантирует.
Нет. Система прямо гарантирует обнаружение изменений. И только косвенно, через гарантированное обнаружение изменений, соответствие реальности.
Хорошо, приведите алгоритм действий, как несанкционированно изменившийся документ будет приведён в соответствие с реальностью и как проверить, что объекты, созданные с момента обнаружения несанкционированного изменения, не были несанкционированно изменены.
Он просто будет скорректирован контролером в полном соответствии с реальностью. Для контролера нет никакой разницы работает он с новым документом или со старым. Поймите такую простую вещь. В системе появился новый документ. Контролер берет его и проверяет. Если находит ошибки, исправляет. В системе появился исправленный документ. Контролер берет его и проверяет. Если находит ошибки, исправляет.
Если вам все же очень надо выяснить, что именно было изменено, тогда достаете проверенную версию документа из бэкапа и сравниваете. В чем вы здесь увидели проблему?
Предположим что бэкапы делаются раз в день и хранятся в течение года. В январе ввели документ. Контролер его проверил. Утром 5 декабря кто-то внес изменения в этот документ. Вечером при очередном сеансе контроля, контролер это обнаружил. У него на руках свыше 300 бэкапов, в каждом из которых хранится проверенная версия этого документа. Можно доставать из любого.
и как проверить, что объекты, созданные с момента обнаружения несанкционированного изменения, не были несанкционированно изменены.
вот это мне вообще не понятно. О каких объектах речь? Об одних и тех же? Мы что-то проверили сегодня, а назавтра это изменили? Завтра это и обнаружим, в чем вопрос?
Вы поставьте условие что ручной контроль в том виде как вы его предлагаете - предполагает что количество изменений - не больше нескольких штук за сеанс "проверки". Тогда можно начинать рассуждать о ручных проверках и неспешных способах отката. Это очень узкая область применения.
Ваш контролер должен также обладать достаточно уникальными навыками чтобы иметь экспертизу в предметной области этих документов и иметь возможность оценивать их истинность. Например, измнился юридический документ в 120 страниц. Или бухгалтерский отчет.
Вот у меня есть небольшая база на 50Гб - в нее собираются данные каждый день по нескольку миллионов строк. Даже если бы я хотел внедрить какой-то контроль и защиту - о вашем способе я бы даже думать не стал.
И еще раз - ваш способ - это не защита, а просто способ индикации факта что что-то где-то когда-то кем-то было изменено. Обнаружить это конкретнее не представляется возможным. И единственный способ исправить - откатить всю базу из предыдущего бэкапа вместе с остальными изменениями. Я не встречал еще ни одного бизнеса который был бы такому рад. Не представляю как можно бы было продать такой способ "защиты" кому-то из технического руководства.
Зачем откатывать всю базу? Вы хотите получить проверенное состояние одного документа, так получите его в копии и делайте с ним что хотите. Но даже это не является необходимым. Вам система говорит дословно следующее: вот этот вот документ следует еще раз обработать также, как вы его когда-то обрабатывали на входе
Контролер берет его и проверяет.
На основании чего? Предположим, "документ" - это данные, вводимые оператором лично. Что с чем сверять будем?
У него на руках свыше 300 бэкапов, в каждом из которых хранится проверенная версия этого документа.
А чем гарантируется, что эти бэкапы не были изменены аналогично тому, как был изменен сам документ?
Хорошо, а теперь расскажите, что будет происходить после восстановления с вашим журналом хэшей, и как будет проверяться неизменность объектов, появившихся в БД с момента обнаружения несанкционированных изменений до момента их исправления.
Вы не могли бы на примере пояснить? Я вас не понимаю
Ладно, проехали, я могу отвечать только раз в час, такой формат неконструктивен, если мы с вами разговариваем на разных языках.
Вы поняли, что из журнала ничего не удаляется и в нем ничего не меняется? Записи туда только добавляются
Я не понял, что именно физически будет происходить с журналом после восстановления, какие хэши и когда запишет на бумажку контролер после обнаружения несанкционированных изменений и после их исправления.
Мне казалось, что я достаточно прозрачно описал схему в статье. Но, видимо, мне пока еще не хватает мастерства.
Попробую дать полное описание сеанса контроля.
Последняя хеш-сумма в журнале сверяется с записанной на бумажке.
Запускается программа контроля.
Программа контроля создает новые записи в журнале (как для новых документов, так и для измененных или удаленных)
Контролер записывает последний хеш на бумажку. И приступает к проверке документов по списку
Вам будет проще если вы от "санкционированное/несанкционированное" перейдете к рассмотрению "проверенное/непроверенное"
То есть контролер в любом случае должен проверить все изменённые объекты, получается?
Да. Вот это вот удивительный вопрос. А что, может быть какая-то другая рациональная организация процесса? Какая? Собирать в базу данных непроверенные данные? А зачем?
Так объект в процессе своего жизненного цикла после появления в БД может менять своë состояние десятки раз, и если таких объектов десятки тысяч в день, это сколько же контролёров нужно?
Ну вы же знаете, как работают бухгалтерские базы. Вот есть документ прихода на склад. Его при вводе в систему проверяют. А если его изменили "задним числом", тогда проверяют под лупой
Все равно непонятно что гарантирует такая система.
Есть старичок с ручкой и бумажкой, который раз в день делает обход и записывает хэши из каждой базы, ок..
Пусть база изменяется не очень сильно - допустим, сыплется в день миллион транзакций.
Кладовщик Степан, после ухода вахтера с бумажкой, меняет строчку в базе с количеством яблок и сьедает три яблока.
На следующее утро кто будет проверять весь этот миллион транзакций?
Через месяц ревизия обнаруживает недостачу трех яблок. Кого накажут и как его найдут?
Система проверяет. И на выходе выдает вашему старичку: "вот смотри, была такая транзакция, о которой ты еще ничего не знаешь"
В смысле не знаешь? Там миллион транзакций, о которых он не знает. Что с ними делать-то?
Хэш считается по известной формуле, Степан его посчитал и записал правильно.
Речь идет о привязке базы данных к реальности. Сделать это может только человек. Если у вас миллион транзакций в день, и их никто не проверяет, тогда нет предмета для разговора.
Но обычно в базах данных для бизнеса немного не так. Туда вносятся данные, назовем их документами. И каждый документ при вводе в базу проверяется на предмет соответствия реальности.
Задача, которую я решаю, заключается в том, чтобы гарантировать, что каждый документ хранится в базе данных ровно в том виде, в каком он был проверен и введен. А если документ изменяет это свое состояние, то он гарантировано переходит в категорию "не проверен" и при очередном контроле его снова проверят.
То есть документ изменяется один-два раза в день? Это уже не база данных, а справочник.
Обычно в базах данных "для бизнеса" на слово никому не верят. В вашей схеме сколько человек вот так "проверяют" всю базу и держат "на бумажке" хэш-код? Один? А кто он? А если он уходит в отпуск или увольняется? А если его еще год назад [уговорили, подкупили, запугали] или он когда-то давно пропустил и "одобрил" одно изменение в базе - что тогда?
Вам уже несколько раз указали что ваш хэш-код ничего не гарантирует. Нельзя доказать ни когда было изменение, ни изменение какой строки, ни кем. И восстановить тоже, естественно, нельзя.
Получается проверка ради проверки, ложная гарантия безопасности.
Контролеров может быть несколько. Но дело даже не в этом.
Есть природа информации. На нее и надо опираться. После того, как информация появилась в этом мире, вы не можете с уверенностью утверждать сколько копий у этой информации и где они находятся. Информация неуничтожима в принципе. "Рукописи не горят" - это не фигура речи. Это истина в некотором высшем смысле.
Вы, как хранитель базы данных, конечно можете проявить халатность и потерять информацию навсегда. Вы можете хранить бэкапы в неправильном месте и совершать другие ошибки. Но для атакующего все это не имеет значения. У него все равно никогда не будет 100% гарантии что он знает про всех хранителей базы и про все бэкапы. У атакующего на сегодня есть только один союзник. Отсутствие системы гарантированного обнаружения. У вас, как у хранителя базы данных, все на руках. Есть бэкапы, откуда можно запросто достать правильную информацию и заменить ею неправильную в оперативной базе. Но вы этого никогда не сделаете, потому что вы просто не знаете куда смотреть, что именно искать, где вам "собаку зарыли".
Поэтому не могу с вами согласиться. Система гарантированного обнаружения изменений - это не ложная безопасность, а самая настоящая
Деревья Меркле, реализация для БД с верификацией – immudb.
Спасибо за ссылки!
Может и полезно, но автора видимо интересует как натянуть сову на глобус...в смысле обеспечить контроль отсутствия вмешательства на обычных реляционных базах...типа ms sql, postgres, orale, mysql и тд...я сомневаюсь что автор слышал про другие типы баз....при этом автор знает что у базы есть лог, который можно откатить...попробуй откатить лог у dbf которого нет...но есть и наоборот...тотже биткоин блокчей можно рассмативать как базу состоящую из одного лога без физической записи таблиц
как базу состоящую из одного лога без физической записи таблиц
Не обязательно blockchain же, append-only b+tree – это прямо журнал транзакций, который и есть сама БД. Некоторые особо неубиваемые NoSQL-базы именно так данные и хранят.
А если прикрутить в добавляемые страницы иерархию хэшей и подписи, плюс запретить сжатие (удаление orphaned-страниц), как раз immudb и получится.
Отвлечённый комментарий: проблема habr в том, что в комментариях поносят авторов статей те люди, у которых есть некие баллы (некое право). Это право они получают за их активность: писал какую-то статью, поддержал кореша в комментариях и получил одобрение в ответ. Оставшаяся часть людей читают, но ничего не пишут: ни статей, ни комментариев. Как следствие, просто поддержать автора статьи, поставив "лайк" возможности нет. А вступать в дебаты с людьми, которые пишут псевдоакадемические статьи про преобразования Фурье в разных прикладных нишах на хабре (почему-то именно на хабре, а не в целевых научных форумах), никому не хочется. Мне лично после такого общения или прочтения комментариев руки помыть хочется.
Вот и получается, что хабр с каждым годом стимулирует появление сообщества, цель которого обосрать другого.
В защиту автора: в 2013 году с коллегой писал ИС для официального сервисного центра Xerox. Нужно было сделать так, чтобы контактную информацию клиентов нельзя было использовать, в случае проникновения (а у них уже были утечки ранее), и должен был быть контроль неизменчивости данных из-за внешних факторов. Нечто подобное было и сделано. Оно работает до сих пор.
Возможно, чтобы реализовать нечто подобное, нужно выбрать конкретный техн стек, чтобы всё получилось, и потратить деньги на железо (решение было комплексное), плюс, для адекватной защиты нужны ещё некоторые административные вещи, которые не позволят получить доступа к ресурсам просто. Но это уже тонкости.
Карму уже тысячу раз обсуждали. Может, не стоит снова начинать? Вкратце - да, вы правы - на хабре больший вес имеют те, кто написал более ценные (с точки зрения других участников) статьи. Это саморегулирование. Есть плюсы и минусы, но - здесь вот так.
Так может тогда тем, кто создаёт ценность для таких же как и они немного поучиться элементарной культуре? Хотя культура - это не то, ради чего существует хабр, я полагаю. Так как, наверняка, тоже это уже обсуждали, и наверняка пришли к выводу типа: "да пошли все на ***", верно?
PS странно, ко мне пришёл не автор, и не тот самый комментатор, а некто, с кем я даже не начинал разговор. Видимо, это тоже особенность хабр культуры, которую здоровым людям не постичь.
NB Как же меня весили сливы кармы... Как будь-то для здорового человека циферка в профиле соцсети имеет какую-то важность...
PS странно, ко мне пришёл не автор, и не тот самый комментатор, а некто,
с кем я даже не начинал разговор. Видимо, это тоже особенность хабр
культуры, которую здоровым людям не постичь.
Добро пожаловать в интернет! Теперь вы знаете что на публичный комментарий может ответить кто угодно!
NB Как же меня весили сливы кармы... Как будь-то для здорового человека циферка в профиле соцсети имеет какую-то важность...
Противоречие вижу здесь я. Карма вам не важна, но именно вы подняли именно эту тему в комментариях к совершенно не относящейся к этому статье. И, похоже, готовы это дальше обсуждать.
В интернете культура отличается от нормальной жизни? Любопытно. Буду знать. Правда, не понятно, почему хабр называется интернетом...
Смотрю, появился говор как у мастера Йоды. Видимо, кроме культуры, ещё и "русский язык знать хочешь ты". Хотя, какой русский язык? В интернете он тоже не нужен: главное больше желчи подливать между букв.
PS удивительно, но почему-то ты предыдущее сообщение не заминусовал? Чего так? Это же нормальный рефлекс любого "уважаемого автора в интернете" на другого, с кем он не согласен.
В интернете культура отличается от нормальной жизни?
Да нет, интернет - часть "нормальной жизни". Вот от других ее частей культура и правда может отличаться, и мне несколько странно даже, что что у вас это вызывает вопрос.
Она у тебя тут отличается исключительно потому, что здесь принято так, ибо хабр культивирует здесь такое "саморегулирование".
Гризитесь, поливайте желчью, унижайте - это же поведение здоровых людей, верно?
NB Ребята, нужно срочно снести мне карму, в этот момент вам любой психиатр скажет, что правильно сделали. Давайте, продолжайте.
Она у тебя тут отличается исключительно потому, что здесь принято так
Гм, культура разных частей общества отличается именно потому, что "здесь" (в этой части общества) "принято так". Собственно, "культура" - это и есть "принято так".
Повторюсь, мне странно, что в ваших комментариях читается удивление этому совершенно нормальному явлению.
А, то есть принято так. Понял.
Значит тебе и второму чукче позволительно писать здесь гадости к статье, которая описывает вполне себе рабочий механизм (моё мнение, допускаю, что для чукч сильно сложно написано)?
Видимо ты со вторым чукчей только писать комментарии умеешь, читать не аллё...
Как? Комфортно, когда я опустился до культуры вашего технологического притона?
Или таки вернёмся к разговору здоровых людей, где культура учитывается каждого участника, а не как в притоне принято?
А, то есть принято так.
Да, здесь так принято, что на любой комментарий может ответить любой участник сообщества.
Значит тебе и второму чукче позволительно писать здесь гадости к статье
Я что-то не помню, чтобы я писал гадости к статье, этой или какой-то другой.
Так попробуй свои комментарии дать почитать далёкому от ИТ человеку, и главное нелояльному тебе. Так много для себя откроешь... Возможно, получится понять, что пора проходить кризис среднего возраста, и свои "личные обиды" изливать на других - это очень плохо.
Вообще, хорошая рефлексия по тому, как ты общаешься с миром - это очень полезная штука. Вот с двумя сейчас бесплатно делюсь обратной связью о поведении, которое считается здесь "нормой".
У тебя вся риторика основана на утверждениях, не на уточнениях и вопросах. То есть, ты по-умолчанию считаешь всех глупыми, кроме себя и тех, которые сейчас солидарны.
И для сравнения, почитай комментарии автора статьи - земля и небо. Если бы я не знал возраст всех вас, ребята, то я бы предположил, что тебе, комментатору выше и самому первому лет так до 30ти, так как очень большой шлейф максимализма тянется во всех текстах.
Так попробуй свои комментарии дать почитать далёкому от ИТ человеку
...и он скажет "я тут ничего не понял". Я пробовал, да.
Вот с двумя сейчас бесплатно делюсь обратной связью о поведении, которое считается здесь "нормой".
Мне вот любопытно, вам никогда не говорили, что незапрошенная обратная связь не считается "нормой"?
У тебя вся риторика основана на утверждениях
Ну да, я утверждаю некоторые вещи на основании своего опыта.
То есть, ты по-умолчанию считаешь всех глупыми
Нет, я по умолчанию считаю, что я знаю некоторые вещи.
Странно, двойные стандарты. Хотя это норма для местной культуры, я почему-то в этом уверен.
Я тебя не звал в ветку, ты сам пришёл со своим мнением. И, видимо, тебя это так задевает, так как с тобой поступают ровно симметрично. Не кажется тебе это странным?
PS А по поводу "я тут ничего не понял", человек и не должен понимать смысл, но должен понять эмоциональную составляющую риторики. У нас мозг так устроен, что настроение можно уловить по любому тексту (читай Сапольского).
И, видимо, тебя это так задевает, так как с тобой поступают ровно симметрично.
Неа, меня это не задевает. Я просто демонстрирую вам, что вы пользуетесь той же нормой, которую только что критиковали.
человек и не должен понимать смысл, но должен понять эмоциональную составляющую риторики.
А эмоциональная составляющая там будет близкая к нейтральной. То, что это критика - будет читаться. Валидная ли это критика, понятно без знания предмета будет невозможно.
У нас мозг так устроен, что настроение можно уловить по любому тексту
Ммм, а эта риторика не построена на утверждениях?
Если я всё продолжаю видеть твои ответы, значит таки задевает?
Ну, да ладно. Мнение, что эмоциональная составляющая будет нейтральной - это конкретно твои утверждения. Опять же, продолжаешь утверждать, вместо того, чтобы спросить альтернативного мнения.
Критика - это когда "это некорректно, нужно делать вот так потому что", критиканство - это "это не будет работать, тут всё говно".
PS твои коллеги по притону продолжают сливать карму, теперь я не могу сразу отвечать тебе на комментарии. Уж прости, но отвечать буду до поры с большой задержкой :)
Искренне надеюсь, что уже сольют профиль, чтобы я уже перестал писать, да и читать статьи здесь. И так тут почти читать нечего, так ещё после каждой статьи хочется руки помыть.
Если я всё продолжаю видеть твои ответы, значит таки задевает?
Нет.
Опять же, продолжаешь утверждать, вместо того, чтобы спросить альтернативного мнения.
Так я его иногда спрашиваю. Удивительно, но это мнение не обязательно совпадает с вашим.
Критика - это когда "это некорректно, нужно делать вот так потому что",
Ну так я обычно и пишу, почему именно не работает.
Искренне надеюсь, что уже сольют профиль, чтобы я уже перестал писать, да и читать статьи здесь. И так тут почти читать нечего, так ещё после каждой статьи хочется руки помыть.
Так зачем же вы продолжаете читать?
Вот, теперь вижу рефлекс в карме. Умничка.
Очень интересно. Скажите, там у вас были контролеры? Имеются ввиду люди
Нет, контроллеров не было. Но были два независимых человека (один из которых был со-учредителем компании), которые имели доступ к раздельным частям решения: к серверу с информации, и к серверу со специальным железом, которое обеспечивало контроль информации, шифрование и дешифрование.
У нас контроль был автоматизирован. Повлиять на него могли только при одном условии: если доступ дадут два независимых человека одновременно, в этом случае можно было повлиять на работу системе в целом.
Есть легенда про одного менеджера, который в конце письма не написал «с уважением» и с этим хамлом больше никто не общался.
Существует ли абсолютная защита баз данных?