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


Аудит База данных SQL Azure и Azure Synapse Analytics

Применимо к:База данных SQL AzureAzure Synapse Analytics

Аудит для База данных SQL Azure и Azure Synapse Analytics отслеживает события базы данных и записывает их в журнал аудита в учетной записи хранения Azure, рабочей области Log Analytics или Центрах событий.

Аудит также:

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

  • Обеспечивает и способствует соблюдению стандартов соответствия, хотя это не гарантирует их соблюдение. Дополнительные сведения см. в Microsoft Azure Центре управления безопасностью где можно найти самый актуальный список сертификатов соответствия базы данных SQL.

Примечание.

Сведения об аудите Управляемый экземпляр SQL Azure см. в статье Начало работы с аудитом Управляемый экземпляр SQL Azure.

Обзор

Используйте аудит базы данных SQL, чтобы выполнять следующие действия:

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

Внимание

Аудит для База данных SQL Azure, SQL пулов Azure Synapse Analytics и Управляемый экземпляр SQL Azure оптимизирован для доступности и производительности проверяемой базы данных или экземпляра. В периоды очень высокой активности или высокой сетевой нагрузки функция аудита может позволить транзакциям продолжаться без записи всех событий, помеченных для аудита.

Улучшения производительности, доступности и надежности в аудите сервера для База данных SQL Azure (июль 2025 г.)

  • Перепроектировали основные части аудита SQL, что привело к повышению доступности и надежности аудита сервера. В качестве дополнительного преимущества более тесное согласование функций с SQL Server и Управляемый экземпляр SQL Azure. Аудит базы данных остается неизменным.
  • Предыдущая структура аудита активирует аудит на уровне базы данных и выполняет один сеанс аудита для каждой базы данных на сервере. Новая архитектура аудита создает один расширенный сеанс событий на уровне сервера, который фиксирует события аудита для всех баз данных.
  • Новая конструкция аудита оптимизирует память и ЦП и соответствует принципу работы аудита в SQL Server и Управляемый экземпляр SQL Azure.

Изменения в результате переархитектуры аудита сервера

  • Изменение структуры папок для учетной записи хранения:
    • Одно из основных изменений касается изменения структуры папок для журналов аудита, которые хранятся в контейнерах учетных записей хранения. Ранее журналы аудита сервера были записаны в отдельные папки; по одному для каждой базы данных с именем базы данных, выступающей в качестве имени папки. При новом обновлении все журналы аудита сервера объединяются в одну папку с меткой master. Это поведение совпадает с Управляемый экземпляр SQL Azure и SQL Server.
  • Изменение структуры папок для реплик только для чтения:
    • Ранее журналы реплик баз данных только для чтения хранились в папке с доступом только для чтения. Теперь эти журналы записываются в папку master . Эти журналы можно получить, используя новый столбец is_secondary_replica_trueдля фильтрации.
  • Разрешения, необходимые для просмотра журналов аудита:
    • VIEW DATABASE SECURITY AUDIT разрешение в базе данных пользователей

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

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

Ограничения аудита

  • Включение аудита в приостановленном Azure Synapse пуле SQL не поддерживается. Чтобы включить аудит, возобновите Synapse SQL-пул.
  • Включение возможности аудита с помощью управляемого пользователем удостоверения (UAMI) не поддерживается в Azure Synapse.
  • В настоящее время управляемые удостоверения не поддерживаются для Azure Synapse, если учетная запись хранения не находится за виртуальной сетью или брандмауэром.

Примечание.

Для выполнения аудита в Azure Synapse Analytics для учетной записи службы хранения за виртуальной сетью требуется управляемое удостоверение, назначаемое системой , с ролью участника данных хранилища Blob . Назначаемые пользователем управляемые идентичности (UAMI) не поддерживаются для аудита Synapse. Если вам необходимо провести аудит в учетной записи хранения, использующей исключительно проверку подлинности Microsoft Entra, настройте управляемое удостоверение, назначаемое системой на сервере, и предоставьте ему роль "Сотрудник по данным хранилища Blob" на целевой учетной записи хранения. Дополнительные сведения см. в статье «Запись аудита в учетную запись хранения за VNet и брандмауэром».

  • Из-за ограничений производительности мы не проверяем tempdb и временные таблицы. Несмотря на то, что группа действий, завершенная пакетной обработкой, перехватывает инструкции во временных таблицах, она может неправильно заполнять имена объектов. Однако исходная таблица всегда проверяется, обеспечивая запись всех вставок из исходной таблицы во временные таблицы.

  • Аудит для пулов SQL Azure Synapse поддерживает только группы действий аудита по умолчанию.

  • При настройке аудита для сервера логического сервера в Azure или База данных SQL Azure с назначением журнала в качестве учетной записи хранения режим проверки подлинности должен соответствовать конфигурации этой учетной записи хранения. При использовании ключей доступа к хранилищу в качестве типа проверки подлинности целевая учетная запись хранения должна быть включена с доступом к ключам учетной записи хранения. Если учетная запись хранения настроена только для аутентификации с Microsoft Entra ID (ранее Azure Active Directory), аудит можно настроить для использования управляемых удостоверений для аутентификации.

  • Аудит не поддерживается в базах данных с именами, содержащими ? символ. Это относится как к уровню сервера, так и к уровню базы данных, так как базы данных с в их именах больше не поддерживаются в Azure.

  • База данных SQL Azure и Azure Synapse журналы аудита записывают до 4 000 символов в полях statement и data_sensitivity_information. Если выходные данные из действия, допускающего аудит, превышают это ограничение, все содержимое, превышающее первые 4000 символов, усечено и исключено из записи аудита.

Замечания

  • События, инициированные SQLDBControlPlaneFirstPartyApp в журнале действий, являются внутренней функцией Azure уровня управления База данных SQL Azure. События, инициированные SQLDBControlPlaneFirstPartyApp, являются частью внутренней операции синхронизации между подсистемой SQL и Azure Resource Manager. Эти события являются обычной частью управления База данных SQL Azure и необходимы для правильного представления ресурсов и операций в Azure.
  • Хранилище класса Premium с BlockBlobStorage поддерживается. Поддерживается стандартное хранилище. Однако, чтобы аудит мог записывать в учетную запись хранения за виртуальной сетью или брандмауэром, необходимо иметь учетную запись хранения общего назначения версии 2. Если у вас есть учетная запись общего назначения v1 или Хранилище BLOB-объектов, обновите её до учетной записи хранения общего назначения v2. Для получения конкретных инструкций см. Запись аудита в учетной записи хранения за VNet и брандмауэром. Дополнительные сведения см. в разделе Типы учетных записей хранения.
  • Когда клиенты включают аудит SQL и настраивают ограничения исходящей сети, они должны добавить полные доменные имена своей учетной записи хранения аудита в список разрешенных, чтобы гарантировать, что события аудита могут успешно достигать пункта назначения. Если конечная точка хранилища не находится в белом списке, трафик аудита блокируется, что приводит к потере событий аудита. После добавления необходимых полных доменных имен учетной записи хранения в список разрешений клиенты должны повторно сохранить конфигурацию аудита, чтобы возобновить обычный поток событий аудита.
  • Иерархическое пространство имен поддерживается для всех типов стандартных учетных записей хранения и премиум-учетных записей хранения с BlockBlobStorage.
  • Журналы аудита записываются в Append Blobs в Хранилище BLOB-объектов Azure в вашей подписке Azure.
  • Журналы аудита находятся в формате Xel и могут быть открыты с помощью SQL Server Management Studio (SSMS).
  • Чтобы настроить неизменяемое хранилище журналов для событий аудита на уровне сервера или базы данных, выполните инструкции инструкции, предоставляемые служба хранилища Azure. При настройке неизменяемого хранилища BLOB-объектов для аудита убедитесь, что разрешено защищенное добавление установлено на добавление BLOB-объектов или блокировку и добавление BLOB-объектов. Параметр None не поддерживается. Для политик удержания данных на основе времени период удержания учетной записи хранения должен быть короче, чем параметр хранения аудита SQL. Конфигурации, в которых задана политика хранения, но срок хранения для аудита SQL — 0, не поддерживаются.
  • Журналы аудита можно записывать в учетную запись служба хранилища Azure за виртуальной сетью или брандмауэром.
  • Дополнительные сведения о формате журнала, иерархии папки хранения и соглашениях об именовании см. в статье Формат журнала аудита SQL Database.
  • Аудит Использование реплик только для чтения для распределения нагрузки запросов только для чтения включен автоматически. Дополнительные сведения об иерархии папок хранения, соглашениях об именовании и формате журнала см. в статье Формат журнала аудита базы данных SQL.
  • При использовании проверки подлинности Microsoft Entra записи не отображаются в журнале аудита SQL. Чтобы просмотреть записи аудита входа с ошибкой, необходимо посетить центр администрирования Microsoft Entra, в котором приводятся сведения об этих событиях.
  • Логины направляются шлюзом в конкретный экземпляр, в котором находится база данных. При использовании входов Microsoft Entra учетные данные проверяются перед попыткой использовать этого пользователя для входа в запрошенную базу данных. В случае сбоя доступ к запрашиваемой базе данных отсутствует, поэтому аудит не выполняется. При использовании имен входа SQL учетные данные аутентифицируются на запрошенных данных, поэтому в этом случае они могут быть подвергнуты аудиту. Успешные попытки входа, при которых удалось получить доступ к базе данных, проходят аудит в обоих случаях.
  • После настройки параметров аудита можно включить новую функцию обнаружения угроз и настроить адреса электронной почты для получения предупреждений системы безопасности. Использование функции обнаружения угроз позволяет настроить упреждающие оповещения об аномальной активности в базах данных, которая может указывать на потенциальные угрозы безопасности. Дополнительные сведения см. в разделе SQL Advanced Threat Protection.
  • После копирования базы данных с включенным аудитом на другой логический сервер может появиться сообщение электронной почты, уведомляющее вас о сбое аудита. Это известная проблема, и аудит должен работать как ожидается на заново скопированной базе данных.