Восстановление базы данных реестра после незаконного изменения

  • Статья

Область применения: SQL Server 2022 (16.x) База данных SQL Azure Управляемый экземпляр SQL Azure

Как выполнить восстановление после незаконного изменения?

Самый простой способ восстановления после любого вида незаконного изменения — восстановить базу данных до последней резервной копии, которую можно проверить. Для этого можно восстановить базу данных до разных точек во времени и проверить реестр с использованием предыдущих дайджестов базы данных. Последний момент времени, который можно успешно проверить, является тем, который гарантированно не был незаконно изменен и может использоваться для продолжения обработки транзакций. По этой причине крайне важно, чтобы резервные копии создавались достаточно часто, чтобы быть максимально близкими к моменту незаконного изменения. Планирование резервного копирования выполняется автоматически для Базы данных SQL Azure. Хотя этот метод прост, у него есть важное предостережение: если какие-либо транзакции были выполнены после незаконного изменения, необходимо смириться с тем, что они будут потеряны. Либо необходимо вручную восстановить таблицу реестра путем повторного восстановления сведений для проверенных транзакций и повторного вычисления хэшей для этих новых транзакций, произошедших после первого события незаконного изменения в реестре базы данных.

Категории незаконных изменений

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

Незаконное изменение не повлияло на дальнейшие транзакции

Событие незаконного изменения изменило некоторые данные, хранящиеся в реестре, но не повлияло на дальнейшие транзакции. Это может быть связано с тем, что атака была обнаружена до того, как какие-либо транзакции будут работать с измененными данными, или потому, что атака затронула только данные, но не повлияла на новые транзакции. Например, если вы используете таблицу реестра для хранения сведений о банковских транзакциях, изменение сведений о существующих транзакциях не влияет на новые транзакции, которые будут работать с текущими остатками.

Так как незаконное изменение не повлияло на какие-либо транзакции, произошедшие после события незаконного изменения, новые выполнения транзакций и сформированные результаты являются правильными. На основании этого, вы, в идеале, должны привести реестр в согласованное состояние, не затрагивая эти транзакции.

Если злоумышленник не вмешивался в реестр уровня базы данных, это легко обнаружить и исправить. Реестр базы данных находится в согласованном состоянии со всеми созданными дайджестами базы данных, и все новые транзакции, добавленные к ней, были хэшированы с использованием допустимых хэшей предыдущих транзакций. Исходя из этого, все созданные дайджесты базы данных даже для транзакций после незаконного изменения по-прежнему действительны. Можно попытаться получить правильные полезные данные реестра таблиц для незаконно измененных транзакций из резервных копий, которые по-прежнему можно проверить на безопасность (с помощью проверки реестра) и восстановить рабочую базу данных, перезаписав измененные данные в реестре таблиц. При этом будет создана новая транзакция, записывающая транзакции для восстановления.

Незаконное изменение, затрагивающее данные, которые используют дальнейшие транзакциями

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

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

  1. Использование резервных копий для восстановления состояния для незаконно измененных транзакций.
  2. Проверка части реестра после последней транзакции, восстановленной из резервной копии, и до конца реестра. Для этого необходимо использовать дайджесты базы данных из ответвленной части цепочки. Хотя дайджесты базы данных не соответствуют исходной части реестра, она по-прежнему может проверить вилку части реестра не была изменена. Если они также указывают на незаконное изменение, это означает, что произошло несколько событий незаконного изменения, и процесс необходимо применить рекурсивно, чтобы восстановить различные части реестра из резервных копий.
  3. Вручную восстановите реестры таблиц путем повторного восстановления сведений о проверенных транзакциях и повторного вычисления хэшей для этих новых транзакций, произошедших после первого события незаконного изменения в реестре базы данных.

Связанный контент