Управление хэшами
Область применения:
SQL Server 2022 (16.x) База данных SQL Azure Управляемый экземпляр SQL Azure
Хэши базы данных
Хэш последнего блока в реестре базы данных называется хэшем базы данных. Он представляет состояние всех таблиц реестра в базе данных на момент создания блока. Генерирование хэша базы данных — эффективный процесс, так как для него достаточно вычислить только хэши добавленных недавно блоков.
Хэши базы данных могут создаваться либо автоматически системой, либо вручную пользователем. Затем их можно использовать для проверки целостности данных в базе данных.
Хэши базы данных генерируются в виде документа JSON, который содержит хэш последнего блока вместе с метаданными для идентификатора блока. Метаданные включают в себя время создания хэша и метку времени фиксации последней транзакции в этом блоке.
Процесс проверки и целостность базы данных зависят от целостности входных хэшей. Для этого хэши, извлекаемые из базы данных, должны находиться в надежных хранилищах, которые не могут быть незаконно изменены привилегированными пользователями или злоумышленниками в базе данных.
Автоматическое создание и хранение хэшей базы данных
Примечание.
Автоматическое создание и хранение дайджестов баз данных в SQL Server поддерживает только учетные записи служба хранилища Azure.
Реестр интегрируется с неизменяемым хранилищем BLOB-объектов Azure и Конфиденциальным реестром Azure. Эта интеграция предоставляет защищенные службы хранилища в Azure для защиты хэшей базы данных от потенциальных несанкционированных изменений. Такая интеграция обеспечивает простой и экономичный способ автоматизации управления хэшами, так что пользователям не приходится беспокоиться о доступности и географической репликации. Конфиденциальный реестр Azure гарантирует более надежную целостность для клиентов, которые могут быть обеспокоены доступом привилегированных администраторов к хэшу. В этой таблице сравнивается возможность неизменяемого хранилища для Хранилища BLOB-объектов Azure с конфиденциальным реестром Azure.
Настроить автоматическое создание и хранение хэшей базы данных можно на портале Azure либо с помощью PowerShell или Azure CLI. Дополнительные сведения см. в разделе Включение автоматического хранилища хэша. При настройке автоматического создания и хранения хэши базы данных создаются с предопределенным интервалом в 30 секунд и передаются в выбранную службу хранилища. Если в системе в 30-секундном интервале транзакции не происходят, то дайджест базы данных не будет создан и отправлен. Это гарантирует, что хэши генерируются только в случае обновления данных в базе данных. Если конечная точка является Хранилище BLOB-объектов Azure, логический сервер для База данных SQL Azure или Управляемый экземпляр SQL Azure создает новый контейнер с именем sqldbledgerdigests и использует шаблон именования, например: ServerName/DatabaseName/CreationTime Время создания необходимо, так как база данных с тем же именем может быть удалена и восстановлена, что позволяет создавать различные инкарнации базы данных под тем же именем. Дополнительные сведения см. в разделе "Рекомендации по управлению дайджестами".
Примечание.
Для SQL Server контейнер необходимо создать вручную пользователем.
Политика неизменяемости учетной записи служба хранилища Azure
Если вы используете учетную запись служба хранилища Azure для хранения дайджестов базы данных, настройте политику неизменяемости в контейнере после подготовки, чтобы убедиться, что дайджесты базы данных защищены от изменения. Убедитесь, что политика неизменяемости позволяет защищенным добавкам записывать большие двоичные объекты и блокировать политику.
разрешение учетной записи служба хранилища Azure
Если вы используете База данных SQL Azure или Управляемый экземпляр SQL Azure, убедитесь, что логический сервер или управляемый экземпляр (Системное удостоверение) имеет достаточно разрешений на основе ролей для записи дайджестов, добавив его в роль участника данных BLOB-объектов хранилища. Если вы используете активные георепликации или группы автоматической отработки отказа, убедитесь, что вторичные реплики имеют то же разрешение RBAC для учетной записи служба хранилища Azure.
При использовании SQL Server необходимо создать подписанный URL-адрес (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 Управляемый экземпляр SQL Azure для работы с конфиденциальным реестром Azure".
Создание и сохранение хэшей базы данных вручную
Вы также можете создать хэш базы данных по запросу, чтобы вручную сохранять хэш в любой службе или на любом устройстве, которые считаются надежными местами для хранения. Например, в качестве места назначения можно выбрать локальное устройство 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.
Активные георепликации и группы доступности AlwaysOn
Активные георепликации или группы автоматической отработки отказа можно настроить для База данных SQL Azure или Управляемый экземпляр SQL Azure. Репликация между географическими регионами по соображениям производительности выполняется асинхронно и, таким образом, позволяет базе данных-получателю немного отставать по сравнению с базой данных-источником. В случае географической отработки отказа все последние данные, которые еще не были реплицированы, будут потеряны. Реестр будет выдавать дайджесты базы данных только для тех данных, которые были реплицированы в географические базы данных-получатели, чтобы гарантировать, что хэши никогда не будут ссылаться на данные, которые могут быть потеряны в случае географической отработки отказа. Это применимо только к автоматическому созданию и хранению хэшей базы данных. В группе отработки отказа база данных-источник и база данных-получатель будут иметь одинаковый путь дайджеста. Даже при выполнении отработки отказа путь дайджеста не изменяется как для базы данных-источника, так и для базы данных-получателя.
Если группа отработки отказа удаляется или удаляется ссылка, обе базы данных будут работать как первичные базы данных. На этом этапе путь дайджеста предыдущей базы данных-получателя изменится, и мы добавим папку RemovedSecondaryReplica в путь.
Если база данных входит в группу доступности AlwaysOn или Управляемый экземпляр ссылку в SQL Server, используется тот же принцип, что и активная георепликация. Отправка дайджестов выполняется только в том случае, если все транзакции были реплицированы на вторичные реплики.