Управление дайджестами
Область применения:
SQL Server 2022 (16.x) База данных SQL Azure Управляемый экземпляр SQL Azure
Дайджесты базы данных
Хэш последнего блока в реестре базы данных называется дайджестом базы данных. Он представляет состояние всех таблиц реестра в базе данных на момент создания блока. Генерирование хэша базы данных — эффективный процесс, так как для него достаточно вычислить только хэши добавленных недавно блоков.
Сводки базы данных могут создаваться либо автоматически системой, либо вручную пользователем. Затем их можно использовать для проверки целостности данных в базе данных.
Документы дайджеста базы данных создаются в формате JSON, который содержит хэш последнего блока вместе с метаданными для идентификатора блока. Метаданные включают в себя время создания дайджеста и метку времени фиксации последней транзакции в этом блоке.
Процесс проверки и целостность базы данных зависят от целостности входных хэшей. Для этого дайджесты базы данных, извлекаемые из неё, должны храниться в надёжных хранилищах, которые не могут быть изменены привилегированными пользователями или злоумышленниками, атакующими базу данных.
Автоматическое создание и хранение сводок базы данных
Примечание.
Автоматическое создание и хранение дайджестов баз данных в SQL Server поддерживает только учетные записи служба хранилища Azure.
Реестр интегрируется с неизменяемым хранилищем BLOB-объектов Azure и Конфиденциальным реестром Azure. Эта интеграция предоставляет защищенные службы хранилища в Azure для защиты хэшей базы данных от потенциальных несанкционированных изменений. Такая интеграция предоставляет простой и экономичный способ автоматизации управления дайджестами, избавляя пользователей от необходимости беспокоиться о доступности и географической репликации данных. Azure Confidential Ledger предоставляет более высокую гарантию целостности для клиентов, которые могут быть обеспокоены доступом привилегированных администраторов к дайджесту. В этой таблице сравнивается возможность неизменяемого хранилища для Хранилища BLOB-объектов Azure с конфиденциальным реестром Azure.
Настроить автоматическое создание и хранение хэшей базы данных можно на портале Azure либо с помощью PowerShell или Azure CLI. Дополнительные сведения см. в части Включение автоматического хранилища дайджестов. При настройке автоматического создания и хранения хэши базы данных создаются с предопределенным интервалом в 30 секунд и передаются в выбранную службу хранилища. Если в системе в 30-секундном интервале транзакции не происходят, то дайджест базы данных не будет создан и отправлен. Этот механизм гарантирует, что дайджесты генерируются только в случае обновления данных в вашей базе данных. Если конечная точка является BLOB-хранилище Azure, логический сервер для базы данных Azure SQL или управляемого экземпляра Azure SQL создает новый контейнер с именем sqldbledgerdigests и использует шаблон именования, например: ServerName/DatabaseName/CreationTime Время создания необходимо, так как база данных с тем же именем может быть удалена и восстановлена, что позволяет создавать различные инкарнации базы данных под тем же именем. Дополнительные сведения см. в разделе "Рекомендации по управлению дайджестами".
Примечание.
Для SQL Server контейнер необходимо создать вручную пользователем.
Политика неизменяемости учетной записи Azure хранилища
Если вы используете учетную запись Azure Storage для хранения дайджестов базы данных, настройте политику неизменяемости в контейнере после создания, чтобы убедиться, что дайджесты базы данных были защищены от подделки. Убедитесь, что политика неизменяемости позволяет защищенным добавкам записывать большие двоичные объекты и блокировать политику.
разрешение на учетную запись хранилища Azure
Если вы используете Azure SQL Database или Azure SQL Managed Instance, убедитесь, что ваш логический сервер или управляемый экземпляр (Системное удостоверение) имеет достаточное количество разрешений на основе ролей (RBAC) для записи дайджестов, добавив его в Участник данных BLOB-объектов хранилища роль. Если вы используете активную георепликацию или группы автоматического переключения при отказе, убедитесь, что вторичные реплики имеют то же разрешение RBAC для учетной записи хранилища Azure.
При использовании SQL Server необходимо создать общий доступ с использованием подписи доступа (SAS) в контейнере данных, чтобы разрешить SQL Server подключаться и проходить проверку подлинности в учетной записи хранилища Azure.
- Создайте контейнер в учетной записи службы хранилища Azure с именем sqldbledgerdigests.
- Создайте политику в контейнере с правами на чтение, добавление, создание, запись и перечисление, и создайте ключ подписанного URL-адреса.
- Для контейнера sqldbledgerdigests, используемого для хранения файлов дайджеста, создайте учетные данные SQL Server, имя которых совпадает с путем контейнера.
В следующем примере предполагается, что были созданы контейнер службы хранилища Azure, политика и ключ SAS. Это необходимо SQL Server для доступа к файлам дайджеста в контейнере.
В следующем фрагменте кода замените <your SAS key> ключом SAS. Ключ SAS выглядит следующим образом 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.
CREATE CREDENTIAL [https://ledgerstorage.blob.core.windows.net/sqldbledgerdigests]
WITH IDENTITY='SHARED ACCESS SIGNATURE',
SECRET = '<your SAS key>'
Разрешение конфиденциального реестра Azure
Если вы используете Базу данных SQL Azure или Управляемый экземпляр SQL Azure, убедитесь, что ваш логический сервер или управляемый экземпляр (системное удостоверение) имеет достаточно разрешений для записи дайджестов, добавив его в роль Участника. Для этого выполните действия по управлению пользователями конфиденциального реестра Azure.
Примечание.
Автоматическое создание и хранение дайджестов баз данных в SQL Server поддерживает только учетные записи служба хранилища Azure.
Настройка правил NSG для управляемого экземпляра SQL Azure для работы с конфиденциальным реестром Azure
Если вы используете Управляемый экземпляр SQL Azure, убедитесь, что правила виртуальной сети Управляемый экземпляр SQL Azure настроены для обмена данными с конфиденциальным реестром Azure. Дополнительные сведения см. в разделе Настройка правил NSG для управляемого экземпляра Azure SQL для работы с Azure Confidential Ledger.
Создание и сохранение дайджестов базы данных вручную
Вы также можете создать хэш базы данных по запросу, чтобы вручную сохранять хэш в любой службе или на любом устройстве, которые считаются надежными местами для хранения. Например, в качестве места назначения можно выбрать локальное устройство WORM (write once, read many). Создание хэша базы данных вручную выполняется с помощью хранимой процедуры sys.sp_generate_database_ledger_digest в SQL Server Management Studio или Azure Data Studio.
EXECUTE sp_generate_database_ledger_digest;
Возвращаемый результирующий набор представляет собой одну строку данных. Ее следует сохранить в надежном месте как документ JSON следующим образом.
{
"database_name": "ledgerdb",
"block_id": 0,
"hash": "0xDC160697D823C51377F97020796486A59047EBDBF77C3E8F94EEE0FFF7B38A6A",
"last_transaction_commit_time": "2020-11-12T18:01:56.6200000",
"digest_time": "2020-11-12T18:39:27.7385724"
}
Разрешения
Для создания дайджестов базы данных требуется GENERATE LEDGER DIGEST разрешение. Подробные сведения о разрешениях, связанных с таблицами реестра, см. в статье Разрешения.
Рекомендации по управлению дайджестами
Восстановление базы данных
Восстановление базы данных до более ранней точки во времени, также известной как восстановление до точки во времени, часто используется при возникновении ошибки, когда пользователям необходимо быстро вернуть состояние базы данных к более ранней точке во времени. При отправке созданных хэшей в службу хранилища Azure или конфиденциальный реестр Azure фиксируется время создания базы данных, с которой эти хэши сопоставляются. Каждый раз, когда база данных восстанавливается, она помечена новым временем создания, и этот метод позволяет хранить дайджесты в разных "инкарнациях" базы данных. Для SQL Server время создания — это текущее время по UTC, когда впервые включена отправка дайджеста. Реестр сохраняет сведения о времени выполнения операции восстановления, что позволяет процессу проверки использовать все соответствующие хэши в различных воплощениях базы данных. Кроме того, пользователи могут проверять все дайджесты на разные моменты создания, чтобы определить, когда была восстановлена база данных и на какое время назад она была восстановлена. Так как эти данные записываются в неизменяемое хранилище, эта информация также защищена.
Примечание.
Если вы выполняете восстановление нативной резервной копии базы данных в Управляемом экземпляре SQL Azure, необходимо вручную изменить путь дайджеста с помощью портала Azure, PowerShell или Azure CLI.
Активная георепликация и группы доступности «Always On»
Активная георепликация или группы автоматического переключения могут быть настроены для Базы данных Azure SQL или Управляемого экземпляра Azure SQL. Репликация между географическими регионами по соображениям производительности выполняется асинхронно и, таким образом, позволяет базе данных-получателю немного отставать по сравнению с базой данных-источником. В случае географического переключения все последние данные, которые еще не были реплицированы, будут утеряны. Реестр будет выдавать сводки базы данных только для тех данных, которые были реплицированы в географические вторичные системы, чтобы гарантировать, что сводки никогда не будут ссылаться на данные, которые могут быть потеряны в случае географического переключения. Это применимо только к автоматическому созданию и хранению дайджестов базы данных. В группе отработки отказа база данных-источник и база данных-получатель будут иметь одинаковый путь дайджеста. Даже при переключении после отказа путь дайджеста не изменяется как для основной, так и для вторичной базы данных.
Если будет удалена группа аварийного переключения или будет сброшена ссылка, обе базы данных будут работать как первичные. На этом этапе путь сводки предыдущей вторичной базы данных изменится, и в него будет добавлена папка RemovedSecondaryReplica.
Если база данных входит в группу доступности Always On или ссылку управляемого экземпляра в SQL Server, используется тот же принцип, что и активная георепликация. Отправка дайджестов выполняется только в том случае, если все транзакции были реплицированы на вторичные реплики.