Проверка базы данных

  • Статья

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

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

Процесс проверки базы данных

В процессе проверки проверяются все таблицы реестра и журналов. Повторно вычисляются хэши SHA-256 для строк в них, а затем эти хэши сравниваются с файлами хэшей базы данных, переданными в хранимую процедуру проверки.

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

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

Примечание.

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

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

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

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

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

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

DECLARE @digest_locations NVARCHAR(MAX) = (SELECT * FROM sys.database_ledger_digest_locations FOR JSON AUTO, INCLUDE_NULL_VALUES);
SELECT @digest_locations as digest_locations;
BEGIN TRY
    EXEC sys.sp_verify_database_ledger_from_digest_storage @digest_locations;
    SELECT 'Ledger verification succeeded.' AS Result;
END TRY
BEGIN CATCH
    THROW;
END CATCH

Проверка базы данных, использующая хранение хэшей вручную

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

Приведенный ниже код является примером выполнения хранимой процедуры sp_verify_database_ledger для проверки двух хэшей.

EXECUTE sp_verify_database_ledger N'
[
    {
        "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"
    },
    {
        "database_name":  "ledgerdb",
        "block_id":  1,
        "hash":  "0xE5BE97FDFFA4A16ADF7301C8B2BEBC4BAE5895CD76785D699B815ED2653D9EF8",
        "last_transaction_commit_time":  "2020-11-12T18:39:35.6633333",
        "digest_time":  "2020-11-12T18:43:30.4701575"
    }
]';

Коды возврата для sp_verify_database_ledger и sp_verify_database_ledger_from_digest_storage — 0 (успешно) или 1 (неудачно).

Рекомендация

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

Планирование проверки базы данных в База данных SQL Azure можно выполнить с помощью заданий elastic или служба автоматизации Azure. Для планирования проверки базы данных в Управляемый экземпляр SQL Azure и SQL Server можно использовать агент SQL Server.

Разрешения

Для проверки базы данных требуется VIEW LEDGER CONTENT разрешение. Подробные сведения о разрешениях, связанных с таблицами реестра, см. в статье Разрешения.

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