Use a identidade gerida pelo sistema ao nível da base de dados com o Base de Dados SQL do Azure (pré-visualização)

Aplica-se a: Base de Dados SQL do Azure

A identidade gerida ao nível da base de dados dá a uma base de dados individual no Base de Dados SQL do Azure a sua própria identidade gerida atribuída pelo utilizador (UAMI). Uma base de dados que tem uma identidade gerida autentica-se no Armazenamento do Azure como ela própria, em vez de como o servidor lógico que a aloja.

Sem uma identidade ao nível da base de dados, todas as bases de dados num servidor lógico partilham a identidade gerida desse servidor, pelo que todas acedem ao mesmo armazenamento. Uma identidade ao nível da base de dados restringe esse acesso a uma única base de dados, por isso pode conceder a cada base apenas o armazenamento de que precisa.

Seleciona-se a identidade numa credencial com âmbito de base de dados, a mesma credencial que as consultas de virtualização de dados usam para ler ficheiros Parquet, CSV e Delta do Armazenamento de Blobs do Azure ou Azure Data Lake Storage (ADLS) Gen2. Escolha entre dois valores de identidade de credencial:

Identidade da credencial	Use-o quando
`DATABASE MANAGED IDENTITY`	A conta de armazenamento está no mesmo tenant Microsoft Entra que a base de dados.
`DATABASE FEDERATED CLIENT IDENTITY`	A conta de armazenamento está num tenant diferente, acedida através de uma credencial de identidade federada (FIC).

Note

Como funcionalidade de pré-visualização, a tecnologia apresentada neste artigo está sujeita aos Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure.

Prerequisites

Uma Base de Dados SQL do Azure num servidor lógico. Todos os níveis de serviço e todas as regiões do Azure suportam esta funcionalidade.
Uma identidade gerida atribuída pelo utilizador na mesma subscrição. Para contexto, veja Identidades geridas no Microsoft Entra para SQL do Azure.
Permissão para atribuir funções à conta de armazenamento alvo, como Owner ou User Access Administrator.
Uma conta Armazenamento de Blobs do Azure ou ADLS Gen2 que detém os ficheiros que pretende consultar.

Important

Uma base de dados pode ter apenas uma identidade gerida atribuída pelo utilizador ao nível da base de dados, ao contrário de um servidor lógico, que pode ter várias. Planeie a identidade por base de dados antes de a atribuir.

Se a base de dados usar chaves geridas pelo cliente ao nível da base de dados, já tem uma identidade ao nível da base de dados e, para chaves entre tenants, um ID federado do cliente. Esta funcionalidade utiliza as mesmas duas definições. Conceda acesso ao armazenamento à identidade ou aplicação existente em vez de atribuir novas identidades ou aplicações. Se atribuires uma identidade ou aplicação diferente, primeiro dá-lhe acesso à chave de encriptação. Caso contrário, a atualização pode falhar, ou a base de dados pode perder o acesso à sua chave.

Escolha mesmo tenant ou tenant cruzado

Ambos os walkthroughs criam uma credencial com âmbito de base de dados e consultam dados externos. Diferem na forma como a identidade chega à conta de armazenamento.

Se a base de dados e a conta de armazenamento estiverem no mesmo tenant, siga Use a database-level identity in the same tenant.
Se a conta de armazenamento estiver num tenant diferente, siga Use a identidade de cliente federada entre tenants.

Use uma identidade ao nível da base de dados no mesmo tenant

Passo 1: Criar uma identidade gerida atribuída pelo utilizador

Crie a identidade e anote tanto o seu ID de Recurso como o seu ID de Objeto (principal). Precisas do ID do Recurso para atribuir a identidade à base de dados. Precisas do ID do Objeto (principal) apenas para o guia passo a passo entre tenants, onde identifica o sujeito da credencial de identidade federada.

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

Para outros métodos, veja identidades geridas atribuídas pelo utilizador.

Passo 2: Atribuir a identidade à base de dados

Atribua o UAMI à base de dados, não ao servidor lógico. Esta atribuição utiliza o mesmo mecanismo que a encriptação transparente de dados (TDE) ao nível da base de dados com chaves geridas pelo cliente, descrito em Chaves geridas pelo cliente ao nível da base de dados. Para o conjunto completo de métodos de atribuição, veja Obter ou definir uma identidade gerida para uma base de dados.

Para atribuir a identidade no portal Azure:

Vai à tua base de dados SQL.
Em Segurança, selecione Identidade.
Em Identidade Gerida Atribuída pelo Utilizador, selecione Adicionar.
Selecione a identidade que criou e depois selecione Adicionar.
Selecione Guardar.

Para atribuir a identidade com a CLI do Azure, use 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>

Para o atribuir com PowerShell, use Set-AzSqlDatabase:

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

A identidade ID de Recurso é semelhante a /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Encontre-o em Propriedades na identidade gerida no portal Azure.

Passo 3: Conceder à identidade acesso ao armazenamento

Dê à identidade gerida acesso de leitura à conta de armazenamento:

Aceda à conta de armazenamento.
Selecione Controlo de Acesso (IAM).
Selecione Adicionar>Adicionar atribuição de função.
Selecione a função Leitor de Dados de Blobs de Armazenamento e, em seguida, selecione Seguinte.
Em Atribuir acesso a, selecione Identidade gerenciada.
Selecione Selecionar membros, escolha a sua identidade gerida atribuída pelo utilizador e depois selecione Selecionar.
Selecione Verificar + atribuir.

Para acesso mais detalhado na ADLS Gen2, defina listas de controlo de acesso (ACLs) em diretórios específicos em vez de atribuir um papel ao nível da conta. Para mais informações, consulte listas de controlo de acesso no Azure Data Lake Storage.

Passo 4: Criar a credencial com âmbito de base de dados

Liga-te à tua base de dados de utilizadores, não master, e cria a credencial:

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

Esta credencial não precisa de segredo nem de chave mestra de base de dados. O motor determina a identidade atribuída à base de dados no momento da consulta.

O equivalente ao nível do servidor usa um valor de identidade diferente. Comparar:

-- 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';

Para a sintaxe completa, consulte CREATE DATABASE SCOPED CREDENTIAL.

Passo 5: Criar a fonte de dados externa

Crie uma fonte de dados externa que aponte para o seu contentor e anexe a credencial. Utilize o prefixo que corresponda ao seu tipo de armazenamento:

Tipo de armazenamento	Prefixo de localização
Armazenamento de Blobs do Azure	`abs://`
ADLS Gen2	`adls://`

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

Passo 6: Consultar os dados

Consulta os ficheiros de forma ad hoc com OPENROWSET:

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

Ou defina uma tabela externa para consultas repetidas:

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;

Use uma identidade federada de cliente entre os locatários

Use este caminho quando a sua base de dados estiver num tenant e a conta de armazenamento noutra. Um registo de aplicação multitenant detém a confiança entre eles: o UAMI da base de dados é o sujeito de uma credencial de identidade federada nessa aplicação, e o inquilino de armazenamento concede ao principal de serviço da aplicação acesso aos dados.

O padrão corresponde a chaves geridas pelo cliente entre locatários para encriptação transparente de dados, por isso a configuração parece familiar se já usar essa funcionalidade.

Passo 1: Registar uma aplicação multitenant

No tenant que contém a base de dados, registe uma aplicação multitenant no Microsoft Entra ID e anote o seu ID de aplicação (cliente).

Para obter mais informações, consulte Registrar um aplicativo com a plataforma de identidade da Microsoft.

Passo 2: Adicionar uma credencial de identidade federada

Adicione uma credencial de identidade federada a essa aplicação para que confie na identidade gerida atribuída pelo utilizador da base de dados. A aplicação e a identidade gerida devem pertencer ao mesmo tenant Microsoft Entra.

No registo da aplicação, selecione Certificados & Segredos>Credenciais federadas>Adicionar credencial.
Para o cenário de credencial federada, selecione Identidade Gerida.
Selecione a identidade gerida que criou no Passo 1 do procedimento guiado do mesmo diretório.
Verifique se o Issuer preenchido automaticamente identifica o seu tenant. Para a cloud pública do Azure, o emissor é https://login.microsoftonline.com/<tenant-id>/v2.0.
Certifique-se de que o Audience é api://AzureADTokenExchange, o valor para a cloud pública do Azure.
Introduza um nome único para a credencial e depois guarde-a.

O sujeito da credencial é o ID de Objeto (principal) da identidade gerida, não o seu ID de cliente. Se configurares a credencial manualmente, copia exatamente o ID do Objeto (principal), porque o identificador distingue maiúsculas de minúsculas. O Microsoft Entra ID aceita valores incorretos do emissor, sujeito ou audiência quando guarda a credencial, mas a troca de tokens falha mais tarde.

Para mais informações, consulte Configurar uma aplicação para confiar numa identidade gerida.

No tenant que detém a conta de armazenamento:

Um administrador dá consentimento à aplicação multitenant, que cria um service principal nesse tenant.
Atribuir o papel Storage Blob Data Reader a esse principal de serviço na conta de armazenamento. Siga o Passo 3: Conceda à identidade acesso ao armazenamento, mas para Atribuir acesso a, selecione Utilizador, grupo ou principal de serviço, e depois selecione o principal de serviço da aplicação.

Passo 4: Definir o ID federado do cliente na base de dados

No tenant que contém a base de dados, atribua a identidade gerida atribuída pelo utilizador à base de dados e defina o ID da Aplicação (cliente) do Passo 1 como o ID do Cliente Federado:

Vai à tua base de dados SQL.
Em Segurança, selecione Identidade.
Em Identidade Gerida Atribuída pelo Utilizador, verifique se a identidade do Passo 1 do walkthrough do mesmo tenant está listada. Se não estiver, selecione Adicionar, selecione a identidade e depois selecione Adicionar.
Na identidade federada do cliente, selecione a aplicação e depois selecione Guardar.

Para o definir com a CLI do Azure:

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>

Para configurar com o PowerShell:

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

Passo 5: Criar a credencial e fazer a consulta

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
);

Depois crie uma tabela externa ou execute OPENROWSET em PartnerStorage exatamente como no Passo 6: Consultar os dados.

Comparar identidades ao nível do servidor e ao nível da base de dados

Caraterística	Identidade gerida ao nível do servidor	Identidade gerida ao nível da base de dados
Âmbito da identidade	Servidor lógico	Base de dados única
Sintaxe das credenciais	`IDENTITY = 'MANAGED IDENTITY'`	`IDENTITY = 'DATABASE MANAGED IDENTITY'`
Acesso entre locatários ao armazenamento	Não suportadas. Utilize antes uma assinatura de acesso partilhada	ID de cliente federado definido na base de dados, usado com `IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'`
Granularidade do RBAC de armazenamento	Uma identidade para cada base de dados no servidor	Uma identidade por base de dados
Âmbito de exposição	Todas as bases de dados no servidor partilham acesso	Limitado à base de dados
Tipos de identidade	Atribuído pelo sistema ou pelo utilizador	Atribuído apenas ao utilizador
Chave mestra da base de dados necessária	No	No

Ambos os tipos de credenciais podem coexistir no mesmo servidor lógico e dentro das suas bases de dados. Escolha a credencial que melhor se adequa aos seus requisitos de segurança.

Geo-replicação e failover

Atribuis a identidade a uma base de dados, por isso cada réplica tem a sua própria identidade atribuída. Configura a geo-secundária da mesma forma que a primária antes de executares o failover:

Atribuir à base de dados secundária a mesma identidade gerida atribuída pelo utilizador que a base de dados primária utiliza.
Atribua a essa identidade o mesmo acesso ao armazenamento descrito no Passo 3: Conceda à identidade acesso ao armazenamento.
Para acesso entre locatários, defina a mesma Identidade de cliente federado na base de dados secundária.

Quando configuras ambas as réplicas desta forma, as consultas que usam uma credencial com âmbito de base de dados continuam a funcionar após um failover. O requisito corresponde às chaves geridas pelo cliente ao nível da base de dados, que também necessitam da identidade em cada réplica.

A mesma configuração aplica-se tanto a grupos de geo-replicação ativa como a grupos de failover.

Limitations

Base de Dados SQL do Azure apenas. Azure SQL Managed Instance, SQL Server e Azure Synapse Analytics não suportam estas identidades de credenciais.
Apenas autenticação de saída. Esta funcionalidade não altera a forma como os utilizadores e as aplicações se autenticam na base de dados.
Não é suportado na master base de dados. Crie a credencial numa base de dados de utilizadores.
Apenas identidades geridas atribuídas pelo utilizador. Uma identidade gerida atribuída pelo sistema está associada ao servidor lógico, pelo que não pode funcionar como uma identidade ao nível da base de dados.
Uma identidade gerida atribuída pelo utilizador por cada base de dados.
Esta pré-visualização abrange apenas virtualização de dados: CREATE EXTERNAL TABLE e OPENROWSET com DATA_SOURCE. Outras funcionalidades de saída, como sp_invoke_external_rest_endpoint, não estão dentro do âmbito.

Troubleshoot

Criar uma credencial com âmbito de base de dados não confirma se a identidade da base de dados pode obter um token ou aceder ao armazenamento. Os erros surgem mais tarde, quando cria uma fonte de dados externa ou executa uma consulta que utiliza a credencial.

A identidade da base de dados não está configurada (erro 15858)

Pode criar uma credencial com IDENTITY = 'DATABASE MANAGED IDENTITY' antes de atribuir uma identidade gerida atribuída pelo utilizador à base de dados. Se uma consulta usar a credencial e a base de dados não tiver identidade para obter um token, a consulta falha com o erro 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)'.

Atribuir uma identidade gerida atribuída pelo utilizador à base de dados, conforme descrito no Passo 2, dar-lhe acesso à conta de armazenamento e depois tentar novamente a consulta. Atribuir uma identidade apenas ao servidor lógico não configura uma identidade ao nível da base de dados. Se a atribuição da base de dados estiver em funcionamento e o erro persistir, contacte o Suporte da Microsoft para investigar o provisionamento da identidade da base de dados.

Note

A flag de rastreio 4675 e a etapa de eliminar e recriar em Backup e restaurar para URL usando identidades geridas aplicam-se ao SQL Server nas VMs do Azure. Não se aplicam à identidade gerida ao nível da base de dados no Base de Dados SQL do Azure.

Credencial não pode ser encontrada nem referenciada (erro 46516)

Quando crias uma fonte de dados externa, o Base de Dados SQL do Azure verifica se a credencial existe na base de dados atual e se tens permissão para a referenciar. Se algum dos testes falhar, recebe o erro 46516:

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

Crie a credencial na base de dados que contém a fonte de dados externa, verifique o nome da credencial e certifique-se de que tem permissão para a referenciar.

Falha na aquisição de tokens (erro 15858)

Quando a base de dados não consegue obter um token Microsoft Entra e o fornecedor de tokens devolve uma razão, o erro 15858 inclui essa razão:

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

Use a mensagem de erro aninhada para descobrir porque é que o pedido do token falhou. Para acesso entre inquilinos, verifique a aplicação, o consentimento do administrador no tenant de armazenamento e a credencial de identidade federada, conforme descrito em Configurar uma aplicação para confiar numa identidade gerida.

Para ler dados externos, a identidade também necessita de uma função de dados de armazenamento. Para acesso no mesmo tenant, conceda o Storage Blob Data Reader no contentor ou na conta de armazenamento à identidade gerida atribuída pelo utilizador da base de dados. Para acesso entre locatários, conceda-o ao principal de serviço da aplicação no locatário de armazenamento. Para obter mais informações, veja Atribuir uma função do Azure para acesso aos dados de blobs.

O ficheiro não existe ou não pode ser acedido (erro 4860)

Quando um ficheiro está em falta ou não pode ser lido, recebe o erro 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.

Verifique se o ficheiro existe na localização configurada. Depois, verifique se a identidade utilizada pelo pedido pode aceder a ele, através de uma função de dados de armazenamento ou, para ADLS Gen2, listas de controlo de acesso (ACLs) no caminho.

O acesso à rede está bloqueado (erros 42121 e 16539)

Quando o servidor lógico está associado a um perímetro de segurança de rede que não permite tráfego de saída para a conta de armazenamento, recebe o erro 42121:

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

Adicione uma regra de acesso de saída para o nome do host da conta de armazenamento ao perfil do perímetro, ou associe a conta de armazenamento ao mesmo perímetro. Para mais informações, consulte o perímetro de segurança de rede para Base de Dados SQL do Azure.

Quando a conectividade de saída está restrita no servidor lógico e a conta de armazenamento não está nas regras de firewall de saída do servidor, obtém-se o erro 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.

Adicione uma regra de firewall de saída para o nome exato do host de armazenamento na localização da fonte de dados externa. Para mais informações, consulte Regras de firewall Outbound para Base de Dados SQL do Azure e Azure Synapse Analytics.

A configuração entre tenants está em falta ou está incorreta (erros 16561 e 16562)

Uma consulta entre locatários pode falhar com qualquer um destes erros, ou com o erro 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.

Estes erros significam que a query não conseguiu aceder aos ficheiros. A identidade pode não ter o papel de armazenamento necessário, o acesso à rede pode ser bloqueado, a localização de armazenamento pode não ser resolvida, ou o token pode ser do tenant errado. Para corrigi-lo:

Conceda a função adequada de dados de armazenamento.
Permitir o acesso de rede à conta de armazenamento.
Inclua o contentor na localização da origem de dados externa.
Utilize DATABASE FEDERATED CLIENT IDENTITY, e defina o ID Federado do Cliente na base de dados, conforme descrito no Passo 4.
Confirme que o subject da credencial de identidade federada corresponde exatamente ao ID de Objeto (principal) da identidade gerida.

As consultas falham após um failover

Se as consultas falharem com erros de token ou autorização após um failover, o novo primário pode não ter a mesma identidade gerida atribuída pelo utilizador que o primário original usou. Ou essa identidade pode não ter uma atribuição de função na conta de armazenamento. Atribuir a mesma identidade a ambas as réplicas e conceder-lhe acesso ao armazenamento, conforme descrito em Geo-replicação e failover.

Perguntas mais frequentes

Podem as credenciais ao nível do servidor e ao nível da base de dados coexistir no mesmo servidor?

Sim, no mesmo servidor lógico e na mesma base de dados. O valor de IDENTITY de cada credencial decide qual a identidade que uma consulta utiliza: MANAGED IDENTITY utiliza a identidade do servidor e DATABASE MANAGED IDENTITY utiliza a identidade da base de dados.

Posso usar uma identidade gerida atribuída pelo sistema?

No. Uma identidade gerida atribuída pelo sistema pertence ao servidor lógico, por isso não a pode limitar a uma única base de dados. Use uma identidade gerida atribuída pelo utilizador.

Que níveis de serviço e regiões suportam esta pré-visualização?

Todos os níveis de serviço do Base de Dados SQL do Azure, em todas as regiões do Azure.

Preciso de uma chave mestra da base de dados?

No. Nenhum DATABASE MANAGED IDENTITY deles nem DATABASE FEDERATED CLIENT IDENTITY aceita um segredo, por isso não é necessária uma chave mestra.

Esta funcionalidade funciona com sp_invoke_external_rest_endpoint?

Não nesta pré-visualização. A pré-visualização abrange a virtualização de dados.

Comentários

Esta página foi útil?

Última atualização a 2026-10-30