Общие сведения о реестре

  • Статья

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

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

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

Управление финансами и историческими данными осуществляется прозрачно, что обеспечивает защиту без каких бы то ни было изменений приложения. Функция сохраняет исторические данные в реляционной форме для поддержки запросов SQL в целях аудита, судебного анализа и т. п. Реестр предоставляет гарантии целостности криптографических данных при поддержке мощности, гибкости и производительности Базы данных SQL.

Diagram of the ledger table architecture.

Варианты использования для реестра

Давайте рассмотрим некоторые преимущества использования реестра.

Рационализация аудита

Ценность любой производственной системы зависит от возможности доверять данным, используемым и производимым ею. Если данные в базе данных были злонамеренно изменены пользователем, это может привести к катастрофическим последствиями для бизнес-процессов, использующих эти данные.

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

Процессы аудита очень трудоемки. Аудит требует локальной инспекции внедренных практических рекомендаций, таких как просмотр журналов аудита, изучение проверки подлинности и исследование механизмов доступа. Хотя эти выполняемые вручную процессы могут выявить потенциальные пробелы в системе безопасности, они не могут предоставить подтвержденное доказательство того, что данные не были злонамеренно изменены.

Реестр обеспечивает криптографическую проверку целостности данных для аудиторов. Это может помочь оптимизировать процесс аудита. Кроме того, проверка обеспечивает неапеллируемость в отношении целостности данных системы.

Бизнес-процессы с несколькими участниками

В некоторых системах, таких как системы управления цепочкой поставок, несколько организаций должны обмениваться друг с другом данными из бизнес-процессов. В этих системах возникает проблема обмена данными и доверия к ним. Многие организации обращаются к традиционным блокчейнам, таким как Ethereum или Hyperledger Fabric, для цифрового преобразования своих бизнес-процессов с участием нескольких сторон.

Блокчейн — отличное решение для сетей с несколькими участниками, в которых недостаточно доверия между сторонами в сети. Многие из этих сетей представляют собой фундаментально централизованные решения, где доверие имеет большое значение, а полностью децентрализованная инфраструктура является тяжеловесным решением.

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

Успех клиента

Доверенное хранилище за пределами цепочки для блокчейн

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

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

Как это работает

Все строки, измененные транзакцией в таблице реестра, криптографически хэшируют SHA-256 с помощью структуры данных дерева Merkle, которая создает корневой хэш, представляющий все строки в транзакции. Транзакции, обрабатываемые базой данных, затем также хэшируются SHA-256 вместе с помощью структуры данных дерева Merkle. Результатом является корневой хэш, который формирует блок. Затем блок хэшируется SHA-256 с использованием корневого хэша блока вместе с корневым хэшем предыдущего блока в качестве входных данных для хэш-функции. Этот хэш формирует блокчейн.

Корневые хэши в реестре базы данных, также называемые хэшем базы данных, содержат криптографически хэшированные транзакции и представляют состояние базы данных. Их можно периодически создавать и хранить за пределами базы данных в хранилище, например в Хранилище BLOB-объектов Azure, настроенном с помощью политик неизменяемости, Конфиденциальном реестре Azure или локальной записи после чтения большого количества (WORM). Позже хэши базы данных используются для проверки целостности базы данных путем сравнения значения хэша в хэш-коде с вычисляемыми хэшами в базе данных.

Функции реестра вводятся в таблицы двумя способами:

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

Обновляемые таблицы реестра

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

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

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

Значения в обновляемой таблице реестра и соответствующей таблице журнала формируют хронику значений базы данных с течением времени. Для запроса хроники базы данных созданное системой представление реестра соединяет обновляемую таблицу реестра и таблицу журнала.

Дополнительные сведения об обновляемых таблицах реестра см. в статье Создание и использование обновляемых таблиц реестра.

Таблицы реестра только для добавления данных

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

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

Дополнительные сведения о таблицах только для добавления см. в статье Создание и использование таблиц реестра только для добавления.

База данных реестра

Базы данных реестра предоставляют простое решение для приложений, которым требуется обеспечить целостность всех защищаемых данных на все время существования базы данных. База данных реестра может содержать только таблицы реестра. Создание обычных таблиц (не таблиц реестра) не поддерживается. Каждая таблица по умолчанию создается как обновляемая таблица реестра с параметрами по умолчанию, что упрощает создание таких таблиц. База данных настраивается в качестве базы данных реестра при создании. После создания база данных реестра не может быть преобразована в обычную. Дополнительные сведения см. в разделе Настройка базы данных реестра.

Хэши базы данных

Хэш последнего блока в реестре базы данных называется хэшем базы данных. Он представляет состояние всех таблиц реестра в базе данных на момент создания блока.

После формирования блока связанный с ним хэш базы данных публикуется и сохраняется вне базы данных в хранилище, устойчивом к несанкционированному изменению. Так как хэши базы данных представляют состояние базы данных на момент создания, защита хэшей от несанкционированного доступа имеет первостепенное значение. Злоумышленник, имеющий доступ к изменению хэшей, сможет выполнять следующие действия:

  1. незаконно изменять данные в базе данных;
  2. формировать хэши, представляющие базу данных с несанкционированными изменениями;
  3. изменять хэши для представления обновленного хэша транзакций в блоке.

Реестр предоставляет возможность автоматического создания и хранения хэшей базы данных в неизменяемом хранилище или в Конфиденциальном реестре Azure в целях предотвращения несанкционированного изменения. Кроме того, пользователи могут вручную создавать хэши базы данных и хранить их в выбранном расположении. Хэши базы данных используются для последующей проверки того, что данные, хранящиеся в таблицах реестра, не были подвержены несанкционированному изменению.

Проверка реестра

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

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

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

См. также