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