Используйте управляемое удостоверение на уровне базы данных для База данных SQL Azure (preview)

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

Управляемое удостоверение на уровне базы данных предоставляет отдельной базе данных в База данных SQL Azure собственное управляемое удостоверение (UAMI). База данных, имеющая собственную управляемую идентичность, аутентифицируется в служба хранилища Azure от собственного имени, а не как логический сервер, который её размещает.

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

Вы выбираете удостоверение в учетных данных уровня базы данных — тех же учетных данных, которые используют запросы виртуализации данных для чтения файлов Parquet, CSV и Delta из Хранилище BLOB-объектов Azure или Azure Data Lake Storage (ADLS) Gen2. Выберите одно из двух значений идентификатора учётных данных:

Идентификатор учетных данных	Используйте его, когда
`DATABASE MANAGED IDENTITY`	Учетная запись хранения находится в том же арендаторе Microsoft Entra, что и база данных.
`DATABASE FEDERATED CLIENT IDENTITY`	Аккаунт хранения находится в другом тенанте и доступен через учетные данные федеративного удостоверения (FIC).

Note

В отношении технологии (как предварительной версии функции), описанной в этой статье, действуют дополнительные условия использования предварительных версий Microsoft Azure.

Prerequisites

База данных База данных SQL Azure на логическом сервере. Все сервисные уровни и все регионы Azure поддерживают эту функцию.
Управляемый идентификатор, назначаемый пользователем в той же подписке. Для информации см. Managed identities in Microsoft Entra for Azure SQL.
Разрешение на назначение ролей на целевой учетной записи хранения, таких как Владелец или Администратор пользовательского доступа.
Учетная запись Хранилище BLOB-объектов Azure или ADLS Gen2, содержащая файлы, которые вы хотите запрашивать.

Important

База данных может иметь только одно управляемое удостоверение, назначенное пользователем на уровне базы данных, в отличие от логического сервера, который может иметь несколько. Планируйте свойство IDENTITY для каждой базы данных перед её назначением.

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

Выберите того же арендатора или кросс-арендатора

Оба пошаговых руководства создают учетные данные области базы данных и запрашивают внешние данные. Они различаются тем, как идентификатор попадает в аккаунт хранения.

Если база данных и аккаунт хранения находятся в одном тенанте, выполните инструкции из Использование удостоверения на уровне базы данных в том же тенанте.
Если учетная запись хранения находится в другом клиенте, следуйте инструкциям в Use a federated client identity across tenants.

Используйте удостоверение на уровне базы данных в том же клиенте

Шаг 1. Создайте управляемую учетную запись, назначенную пользователем

Создайте удостоверение и отметьте как Resource ID, так и Object (principal) ID. Вам нужен Resource ID, чтобы назначить управляемое удостоверение базе данных. Идентификатор объекта (principal) нужен только для межарендного пошагового руководства, где он идентифицирует субъект учетных данных федеративной идентификации.

az identity create \
    --name <identity-name> \
    --resource-group <resource-group> \
    --location <region>

Для других методов см. Управление управляемыми идентификаторами, назначенными пользователями.

Шаг 2: Назначить удостоверение базе данных

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

Чтобы назначить удостоверение в портале Azure:

Зайдите в свою базу данных SQL.
В разделе "Безопасность" выберите "Удостоверение".
В разделе управляемое удостоверение, назначаемое пользователем выберите Добавить.
Выберите созданное вами удостоверение личности, затем выберите Добавить.
Нажмите Сохранить.

Чтобы назначить удостоверение с помощью Azure CLI, используйте az sql db update:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id>

Чтобы присвоить его с помощью PowerShell, используйте Set-AzSqlDatabase:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId>

Идентификатор ресурса identity выглядит как /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Найдите его в разделе «Свойства» в управляемом удостоверении на портале Azure.

Шаг 3: Предоставить субъекту доступ к хранилищу

Предоставьте управляемой идентификации доступ на чтение к учетной записи хранения:

Перейдите к учетной записи хранения.
Выберите Управление доступом (IAM).
Нажмите кнопку Добавить>Добавить назначение ролей.
Выберите роль Storage Blob Data Reader, а затем выберите Next.
Чтобы назначить доступ, выберите управляемое удостоверение.
Выберите «Выбрать участников группы», выберите управляемую идентичность, назначенную пользователем, а затем выберите «Выбрать».
Выберите кнопку Проверить + назначить.

Для более детального разграничения доступа в ADLS Gen2 устанавливайте списки контроля доступа (ACL) для конкретных каталогов вместо назначения роли на уровне учетной записи. Для получения дополнительной информации см. списки контроля доступа в Azure Data Lake Storage.

Шаг 4. Создайте учетные данные уровня базы данных

Подключитесь к вашей базе данных пользователей, а не к master, и создайте учетные данные:

CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

Эти учетные данные не требуют секрета и мастер-ключа базы данных. Движок разрешает учетные данные, назначенные базе данных, во время выполнения запроса.

Эквивалент на уровне сервера использует другое значение идентификатора. Сравнить:

-- Server-level identity: every database on the logical server shares this access
CREATE DATABASE SCOPED CREDENTIAL MyServerIdentityCred
WITH IDENTITY = 'MANAGED IDENTITY';

-- Database-level identity: only this database has this access
CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

Полный синтаксис см. CREATE DATABASE SCOPED CREDENTIAL.

Шаг 5: Создайте внешний источник данных

Создайте внешний источник данных, который указывает на ваш контейнер, и прикрепите учетные данные. Используйте префикс, соответствующий вашему типу хранилища:

Тип хранилища	Префикс местоположения
Хранилище BLOB-объектов Azure (Азур Блоб Сторадж)	`abs://`
ADLS 2-го поколения	`adls://`

CREATE EXTERNAL DATA SOURCE MyExternalStorage
WITH (
    LOCATION = 'abs://<container>@<storage-account>.blob.core.windows.net',
    CREDENTIAL = MyDBIdentityCred
);

Шаг 6: Выполните запрос к данным

Выполняйте произвольные запросы к файлам с помощью OPENROWSET:

SELECT TOP 100 *
FROM OPENROWSET(
    BULK 'sales/2026/*.parquet',
    DATA_SOURCE = 'MyExternalStorage',
    FORMAT = 'parquet'
) AS externalData;

Или определите внешнюю таблицу для повторяющихся запросов:

CREATE EXTERNAL FILE FORMAT ParquetFormat
WITH (FORMAT_TYPE = PARQUET);

CREATE EXTERNAL TABLE dbo.Sales
(
    OrderId int,
    OrderDate date,
    Amount decimal(10, 2)
)
WITH (
    LOCATION = 'sales/2026/',
    DATA_SOURCE = MyExternalStorage,
    FILE_FORMAT = ParquetFormat
);

SELECT TOP 100 * FROM dbo.Sales;

Используйте федеративный идентификатор клиента в разных арендаторах

Используйте этот путь, когда ваша база данных находится в одном клиенте, а учетная запись хранения — в другом. Многоарендная регистрация приложения несёт в себе доверие между ними: UAMI базы данных является субъектом учетных данных федеративной идентификации в данном приложении, и арендатор хранилища предоставляет субъекту-службе приложения доступ к данным.

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

Шаг 1: Зарегистрируйте мультитенантное приложение

В арендаторе, который хранит базу данных, зарегистрируйте мультитенантное приложение в Microsoft Entra ID и укажите его идентификатор приложения (клиента).

Дополнительные сведения см. статью Зарегистрировать приложение на платформе Microsoft identity.

Шаг 2: Добавить учетные данные федеративного удостоверения личности

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

В регистрации приложения выберите Сертификаты и секреты>Федеративные учетные данные>Добавить учетные данные.
Для сценария федеративных учетных данных выберите Управляемое удостоверение.
Выберите управляемую идентификацию, которую вы создали на шаге 1 руководства для того же арендатора.
Проверьте, что автоматически заполняемый Issuer идентифицирует ваш тенант. Для публичного облака Azure эмитентом является https://login.microsoftonline.com/<tenant-id>/v2.0.
Убедитесь, что Audience имеет значение api://AzureADTokenExchange для общедоступного облака Azure.
Введите уникальное имя для учетных данных и сохраните его.

Субъектом учетных данных является ID объекта (субъекта-пользователя) управляемой идентичности, а не ее клиентский идентификатор. Если вы настроите учетные данные вручную, точно скопируйте идентификатор объекта (principal), потому что значение subject чувствительно к регистру. Microsoft Entra ID позволяет сохранить неправильные значения эмитента, субъекта или аудитории при сохранении учетных данных, но позже обмен токенами завершается сбоем.

Для получения дополнительной информации см. раздел «Настроить приложение для доверия управляемой идентичности».

У тенанта, который владеет учетной записью хранения:

Администратор предоставляет согласие для мультитенантного приложения, которое создает субъект-службу в этом тенанте.
Назначьте роль Storage Blob Data Reader этому субъекту-службе приложения в учетной записи хранения. Следуйте шагу 3: Предоставьте субъекту доступ к хранилищу, но для Назначить доступ выберите Пользователь, группа или субъект-служба, а затем выберите субъект-службу приложения.

Шаг 4: Установите идентификатор федеративного клиента для базы данных

В клиенте, где находится база данных, назначьте управляемое удостоверение, назначаемое пользователем, для базы данных и установите идентификатор приложения (клиента) из шага 1 как Federated Client ID:

Зайдите в свою базу данных SQL.
В разделе "Безопасность" выберите "Удостоверение".
В разделе управляемая идентичность, назначаемая пользователем проверьте, отображается ли идентичность из Шага 1 инструкции для того же арендатора. Если нет, выберите Добавить, выберите учетную запись, а затем Добавить.
В разделе Federated client identity выберите приложение, а затем Сохранить.

Чтобы задать его с помощью Azure CLI:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id> \
    --federated-client-id <application-client-id>

Чтобы настроить это с помощью PowerShell:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId> -FederatedClientId <ApplicationClientId>

Шаг 5: Создайте учетные данные и запрос

CREATE DATABASE SCOPED CREDENTIAL MyCrossTenantCred
WITH IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY';

CREATE EXTERNAL DATA SOURCE PartnerStorage
WITH (
    LOCATION = 'adls://<container>@<storage-account>.dfs.core.windows.net',
    CREDENTIAL = MyCrossTenantCred
);

Затем создайте внешнюю таблицу или выполните OPENROWSET для PartnerStorage точно так же, как в Шаге 6: Запрос данных.

Сравните идентификаторы уровня сервера и уровня базы данных

Характеристика	Управляемое удостоверение на уровне сервера	Управляемое удостоверение на уровне базы данных
Область действия удостоверения личности	Логический сервер	Отдельная база данных
Синтаксис учетных данных	`IDENTITY = 'MANAGED IDENTITY'`	`IDENTITY = 'DATABASE MANAGED IDENTITY'`
Доступ к хранилищу между клиентами	Не поддерживается. Используйте подпись общего доступа (SAS) вместо этого	Федеративный идентификатор клиента, установленный в базе данных, используемый с `IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'`
Уровень детализации RBAC для хранилища	Один идентификатор для каждой базы данных на сервере	Одна учетная запись для каждой базы данных
Область воздействия	Каждая база данных на сервере имеет общий доступ	Только одна база данных
Типы удостоверений личности	назначенное системой или пользователем	Только назначенное пользователем
Требуется мастер-ключ базы данных	No	No

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

Гео-репликация и аварийное переключение

Вы присваиваете идентификатор базе данных, поэтому каждая реплика сохраняет своё собственное назначение идентификатора. Настройте гео-вторичную систему так же, как и основную, прежде чем выполнить переключение на резервный ресурс:

Назначить вторичной базе данных то же управляемое удостоверение, назначаемое пользователем, которое использует основная база.
Предоставьте этому удостоверению тот же доступ к хранилищу, описанный в Шаге 3: Предоставьте удостоверению доступ к хранилищу.
Для кросс-тенантного доступа установите тот же идентификатор Federated клиента на вторичной базе данных.

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

Та же конфигурация применима как для активной георепликации, так и для групп отработки отказа.

Limitations

Только База данных SQL Azure. Управляемый экземпляр SQL Azure, SQL Server и Azure Synapse Analytics не поддерживают эти идентификаторы учетных данных.
Только исходящая аутентификация. Эта функция не меняет способ, которым пользователи и приложения проходят аутентификацию в базе данных.
Не поддерживается в базе данных master. Создайте учетную запись в пользовательской базе данных.
Только управляемые удостоверения, назначаемые пользователем. Управляемое удостоверение, назначенное системой, ограничено логическим сервером, поэтому не может выступать в роли удостоверения на уровне базы данных.
Один управляемый идентификатор, назначенный пользователем, на каждую базу данных.
Этот превью охватывает только виртуализацию данных: CREATE EXTERNAL TABLE и OPENROWSET с DATA_SOURCE. Другие исходящие функции, такие как sp_invoke_external_rest_endpoint, не входят в область рассмотрения.

Troubleshoot

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

Идентификатор базы данных не настроен (ошибка 15858)

Вы можете создать учетные данные с помощью IDENTITY = 'DATABASE MANAGED IDENTITY' перед назначением управляемой идентичности, назначаемой пользователем, базе данных. Если запрос использует учетные данные, а база данных не имеет удостоверения для получения токена, запрос завершается с ошибкой 15858:

Cannot obtain a Microsoft Entra ID token to access storage. Error message: 'Azure SQL Server or Database identity is not configured. Please follow the steps in "Assign a Microsoft Entra managed identity to your Azure SQL" (https://aka.ms/SQLDBMSI)'.

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

Note

Флаг трассировки 4675 и этап удаления и повторного создания в Резервное копирование и восстановление по URL с использованием управляемых идентификаторов применяются к SQL Server на виртуальных машинах Azure. Они не применяются к управляемому удостоверению на уровне базы данных в База данных SQL Azure.

Удостоверение не удается найти или сослаться на него (ошибка 46516)

При создании внешнего источника данных База данных SQL Azure проверяет, существуют ли учётные данные в текущей базе данных и есть ли у вас разрешение ссылаться на них. Если одна из проверок не проходит, появляется ошибка 46516:

The specified credential cannot be found or the user does not have permission to perform this action.

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

Не удалось получить токен (ошибка 15858)

Когда база данных не может получить токен Microsoft Entra, а поставщик токена возвращает причину, ошибка 15858 включает эту причину:

Cannot obtain a Microsoft Entra ID token to access storage. Error message: '<details>'.

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

Для чтения внешних данных удостоверению личности также требуется роль данных хранилища. Для доступа в пределах одного арендатора назначьте роль Storage Blob Data Reader на контейнер или учетную запись хранения управляемому удостоверению базы данных, назначаемому пользователем. Для доступа между арендаторами предоставьте его субъекту-службе приложения в арендаторе хранилища. Дополнительные сведения см. в статье Назначение роли Azure для доступа к данным BLOB-объектов.

Файл отсутствует или недоступен (ошибка 4860)

Если файл отсутствует или его нельзя прочитать, появляется ошибка 4860:

Cannot bulk load. The file "<path>" does not exist or you don't have file access rights. See https://go.microsoft.com/fwlink/?LinkId=2374938 for more information.

Проверьте, существует ли файл в заданном месте. Затем проверьте, что субъект безопасности, используемый запросом, может получить доступ к нему через роль хранения данных или, для ADLS Gen2, списки контроля доступа (ACL) на этом пути.

Доступ к сети заблокирован (ошибки 42121 и 16539)

Когда логический сервер связан с сетевым периметром безопасности, который не допускает исходящий трафик на аккаунт хранилища, вы получаете ошибку 42121:

The operation could not be completed because attempts to connect were denied by the configured Network Security Perimeter.

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

Когда исходящая сеть ограничена на логическом сервере, а учетная запись хранения данных отсутствует в правилах исходящего межсетевого экрана сервера, появляется ошибка 16539:

Operation failed since the external data source '<external-data-source>' has underlying storage account that is not in the list of Outbound Firewall Rules on the server. Please add this storage account to the list of Outbound Firewall Rules on your server and retry the operation.

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

Конфигурация между арендаторами отсутствует или некорректна (ошибки 16561 и 16562)

Межарендный запрос может завершиться с одной из этих ошибок или с ошибкой 4860:

External table '<table-name>' is not accessible because content of directory cannot be listed.

External table '<table-name>' is not accessible because location does not exist or it is used by another process.

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

Предоставить соответствующую роль для данных хранилища.
Разрешите сетевой доступ к учетной записи хранения.
Включите контейнер в расположение внешнего источника данных.
Используйте DATABASE FEDERATED CLIENT IDENTITY, и установите Federated Client ID в базе данных, как описано в шаге 4.
Убедитесь, что значение subject учетных данных федеративного удостоверения точно совпадает с объектом (principal) ID управляемой идентичности.

Запросы не работают после аварийного переключения

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

Часто задаваемые вопросы

Могут ли учетные данные уровня сервера и уровня базы данных сосуществовать на одном сервере?

Да, на том же логическом сервере и в той же базе данных. Значение IDENTITY каждых учетных данных определяет, какую учетную запись использует запрос: MANAGED IDENTITY использует учетную запись сервера, а DATABASE MANAGED IDENTITY использует учетную запись базы данных.

Могу ли я использовать управляемое удостоверение, назначенное системой?

No. Управляемая идентичность, назначенная системой, принадлежит логическому серверу, поэтому вы не можете ограничить её одной базой данных. Используйте управляемую идентичность, назначенную пользователем.

Какие уровни сервиса и регионы поддерживают эту предварительную версию?

Все уровни служб База данных SQL Azure во всех регионах Azure.

Нужен ли мне мастер-ключ базы данных?

No. Ни DATABASE MANAGED IDENTITY, ни DATABASE FEDERATED CLIENT IDENTITY не принимает секрет, поэтому мастер-ключ не требуется.

Работает ли эта функция с sp_invoke_external_rest_endpoint?

Недоступно в этом превью. Предварительная версия включает виртуализацию данных.

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-10-30