Поделиться через

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

Применимо к: SQL Server 2022 (16.x) и более поздним версиям Azure SQL DatabaseAzure SQL Managed Instance

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

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

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

Схема архитектуры таблицы реестра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принцип работы

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

Корневые хэши в реестре базы данных, также называемые хэшем базы данных, содержат криптографически хэшированные транзакции и представляют состояние базы данных. Они могут периодически создаваться и храниться вне базы данных в защищенном от изменений хранилище, например Azure Blob Storage, настроенном с помощью политик неизменяемости, Azure Confidential Ledger или на локальных устройствах хранения Запись один раз, чтение многократно (WORM). Позже сводки базы данных используются для проверки целостности базы данных путем сравнения значения хэша в сводке с вычисленными хэшами в базе данных.

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

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

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

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

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

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

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

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

Таблицы бухгалтерской записи только для добавления данных

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

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

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

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

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

Дайджесты базы данных

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

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

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

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

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

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

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

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

  • Last updated on