Använd hanterad identitet på databasnivå med Azure SQL Database (förhandsversion)

gäller för:Azure SQL Database

Databasnivå-managed identity ger en enskild databas i Azure SQL Database sin egen användartilldelade managed identity (UAMI). En databas som har en sådan autentiserar sig mot Azure Storage som sig själv, snarare än som den logiska servern som är värd för den.

Utan en databasnivåidentitet delar varje databas på en logisk server serverns hanterade identitet, så de når alla samma lagring. En identitet på databasnivå begränsar åtkomsten till en enda databas, så du kan ge varje databas endast den lagring den behöver.

Du väljer identiteten i autentiseringsuppgifter med databasomfång, samma autentiseringsuppgifter som frågor om datavirtualisering använder för att läsa Parquet-, CSV- och Delta-filer från Azure Blob Storage eller Azure Data Lake Storage (ADLS) Gen2. Välj mellan två värden för inloggningsuppgifter:

Autentiseringsuppgiftens identitet Använd den när
DATABASE MANAGED IDENTITY Lagringskontot finns i samma Microsoft Entra-tenant som databasen.
DATABASE FEDERATED CLIENT IDENTITY Lagringskontot finns i en annan tenant, som nås via en autentiseringsuppgift för federerad identitet (FIC).

Note

Som en förhandsgranskningsfunktion omfattas tekniken som presenteras i den här artikeln av kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.

Prerequisites

  • En Azure SQL Database på en logisk server. Alla tjänstenivåer och alla Azure-regioner stöder denna funktion.
  • En användartilldelad hanterad identitet i samma prenumeration. För bakgrund, se Managed identities i Microsoft Entra for Azure SQL.
  • Behörighet att tilldela roller på mållagringskontot, såsom Ägare eller Användaråtkomstadministratör.
  • Ett Azure Blob Storage- eller ADLS Gen2-konto som innehåller de filer du vill söka i.

Important

En databas kan endast ha en användartilldelad hanterad identitet på databasnivå, till skillnad från en logisk server som kan ha flera. Planera identiteten för varje databas innan du tilldelar den.

Om databasen använder kundhanterade nycklar på databasnivå har den redan en identitet på databasnivå, och för nycklar mellan klientorganisationer ett federerat klient-ID. Denna funktion använder samma två inställningar. Ge lagringsåtkomst till den befintliga identiteten eller applikationen i stället för att tilldela nya identiteter eller applikationer. Om du tilldelar en annan identitet eller applikation, ge den först tillgång till krypteringsnyckeln. Annars kan uppdateringen misslyckas, eller så kan databasen förlora åtkomst till sin nyckel.

Välj samma klientorganisation eller mellan klientorganisationer

Båda genomgångarna skapar en autentiseringsuppgift med databasscope och kör frågor mot externa data. De skiljer sig åt i hur identiteten når lagringskontot.

Använd en databasnivåidentitet i samma tenant

Steg 1: Skapa en användartilldelad hanterad identitet

Skapa identiteten och notera både dess resurs-ID och dess objekt-(principal-)ID. Du behöver Resource ID för att tilldela identiteten till databasen. Du behöver endast Object (principal) ID för cross-tenant-genomgången, där den identifierar subjektet för den federerade identitetslegitimationen.

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

För andra metoder, se Hantera användar-tilldelade hanterade identiteter.

Steg 2: Tilldela identiteten till databasen

Tilldela UAMI till databasen, inte till den logiska servern. Denna tilldelning använder samma mekanism som transparent datakryptering (TDE) på databasnivå med kundhanterade nycklar, som beskrivs i Kundhanterade nycklar på databasnivå. För hela uppsättningen av tilldelningsmetoder, se Hämta eller ange en hanterad identitet för en databas.

För att tilldela en identitet i Azure-portalen:

  1. Gå till din SQL-databas.
  2. Under Securityväljer du Identity.
  3. Under User-Assigned Managed Identity väljer du Lägg till.
  4. Välj den identitet du skapade och välj sedan Lägg till.
  5. Välj Spara.

För att tilldela identiteten med hjälp av Azure CLI, använd 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>

För att tilldela den med PowerShell, använd Set-AzSqlDatabase:

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

Identiteten resurs-ID ser ut som /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Hitta den under Egenskaper på den hanterade identiteten i Azure-portalen.

Steg 3: Ge identiteten tillgång till lagringen

Ge den hanterade identiteten läsbehörighet till lagringskontot:

  1. Gå till lagringskontot.
  2. Välj Åtkomstkontroll (IAM).
  3. Välj Lägg till>Lägg till rolltilldelning.
  4. Välj rollen Storage Blob Data Reader och välj sedan Nästa.
  5. För Tilldela åtkomst till väljer du Hanterad identitet.
  6. Välj Välj medlemmar, välj din användartilldelade hanterade identitet och välj sedan Välj.
  7. Välj Granska + tilldela.

För mer detaljerad åtkomststyrning på ADLS Gen2, ställ in åtkomstkontrollistor (ACL) på specifika kataloger i stället för att tilldela en roll på kontonivå. För mer information, se Access control lists i Azure Data Lake Storage.

Steg 4: Skapa den databasbegränsade autentiseringsuppgiften

Koppla upp dig mot din användardatabas, inte master, och skapa inloggningsuppgiften:

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

Denna autentiseringsuppgift kräver varken hemlig nyckel eller databashuvudnyckel. Komponenten fastställer vilken identitet som tilldelats databasen vid frågetillfället.

Servernivå-ekvivalenten använder ett annat identitetsvärde. Jämföra:

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

För fullständig syntax, se CREATE DATABASE SCOPED CREDENTIAL.

Steg 5: Skapa den externa datakällan

Skapa en extern datakälla som pekar på din container och bifoga autentiseringsuppgiften. Använd prefixet som matchar din lagringstyp:

Lagringstyp Platsprefix
Azure Blob Storage-lagringstjänst abs://
ADLS Gen2 adls:// 
CREATE EXTERNAL DATA SOURCE MyExternalStorage
WITH (
    LOCATION = 'abs://<container>@<storage-account>.blob.core.windows.net',
    CREDENTIAL = MyDBIdentityCred
);

Steg 6: Fråga data

Sök i filerna ad hoc med OPENROWSET:

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

Eller definiera en extern tabell för upprepade frågor:

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;

Använd en federerad klientidentitet i flera klientorganisationer

Använd den här sökvägen när din databas finns i en klientorganisation och lagringskontot i en annan. En multitenant-applikationsregistrering upprättar förtroendet mellan dem: databasens UAMI är föremål för en federerad autentiseringsuppgift på den applikationen, och lagringsklienten ger applikationens tjänsthuvudnamn tillgång till datan.

Mönstret matchar kundhanterade nycklar över flera klientorganisationer för transparent datakryptering, så uppsättningen ser bekant ut om du redan använder den funktionen.

Steg 1: Registrera en multitenant-applikation

I klientorganisationen som håller databasen, registrera en multitenant-applikation i Microsoft Entra ID och notera dess program-ID (klient-ID).

Mer information finns i Registrera ett program med Microsofts identitetsplattform.

Steg 2: Lägg till en autentiseringsuppgift för federerad identitet

Lägg till en federerad identitetslegitimation i den applikationen så att den upprättar en förtroenderelation till databasens användartilldelade hanterade identitet. Applikationen och den hanterade identiteten måste tillhöra samma Microsoft Entra-klientorganisation.

  1. I appens registrering, välj Certifikat & hemligheter>Federerade autentiseringsuppgifter>Lägg till autentiseringsuppgift.
  2. För scenariot med federerad autentiseringsuppgift, välj Managed Identity.
  3. Välj den hanterade identitet du skapade i steg 1 i genomgången för samma hyresgäst.
  4. Verifiera att den automatiskt ifyllda Issuer identifierar din tenant. För Azure:s publika moln är utgivaren https://login.microsoftonline.com/<tenant-id>/v2.0.
  5. Se till att målgruppen är api://AzureADTokenExchange, värdet för det offentliga Azure-molnet.
  6. Ange ett unikt namn för autentiseringsuppgiften och spara den sedan.

Behörighetens subjekt är den hanterade identitetens Object (principal) ID, inte dess klient-ID. Om du konfigurerar autentiseringsuppgiften manuellt, kopiera objekt-ID:t (principal) exakt, eftersom subjektet är skiftlägeskänsligt. Microsoft Entra ID accepterar felaktiga värden för utfärdare, ämne eller målgrupp när du sparar autentiseringsuppgiften, men tokenutbytet misslyckas senare.

För mer information, se Konfigurera en applikation så att den litar på en hanterad identitet.

I klientorganisationen som har lagringskontot:

  1. En administratör samtycker till multitenant-applikationen, som skapar en service principal i den tenanten.
  2. Tilldela rollen Storage Blob Data Reader till tjänstens huvudnamn på lagringskontot. Följ steg 3: Bevilja identiteten åtkomst till lagring, men för Tilldela åtkomst till väljer du Användare, grupp eller tjänstens huvudnamn och väljer sedan programmets tjänstens huvudnamn.

Steg 4: Sätt det federerade klient-ID:t på databasen

I den tenant som håller databasen, tilldela användartilldelad hanterad identitet till databasen och sätt applikations-ID:t (klient) från steg 1 som federerat klient-ID:

  1. Gå till din SQL-databas.
  2. Under Securityväljer du Identity.
  3. Under User-Assigned Managed Identity, kontrollera att identiteten från steg 1 i genomgången för samma klientorganisation finns listad. Om det inte är det, välj Lägg till, välj identiteten och välj sedan Lägg till.
  4. Under Federated client identity, välj applikationen och välj sedan Spara.

För att ställa in det med 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>

För att ställa in det med PowerShell:

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

Steg 5: Skapa behörigheten och frågan

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

Skapa sedan en extern tabell eller kör OPENROWSET mot PartnerStorage exakt som i steg 6: Fråga datan.

Jämför servernivå- och databasnivåidentiteter

Egenskap Servernivå-hanterad identitet Hanterad identitet på databasnivå
Identitetsområde Logisk server Enkel databas
Behörighetssyntax IDENTITY = 'MANAGED IDENTITY' IDENTITY = 'DATABASE MANAGED IDENTITY'
Åtkomst till lagring mellan flera klientorganisationer Stöds inte. Använd i stället en shared access signature Federerad klient-ID inställd för databasen, använd med IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'
RBAC-granularitet för lagring En identitet för varje databas på servern En identitet per databas
Exponeringens omfattning Varje databas på servern har samma åtkomst Begränsad till en enda databas
Identitetstyper Systemtilldelad eller användartilldelad Endast tilldelad användare
Databasens huvudnyckel krävs No No

Båda typerna av autentiseringsuppgifter kan samexistera på samma logiska server och i dess databaser. Välj den inloggningsuppgift som bäst passar dina säkerhetsbehov.

Geo-replikering och failover

Du tilldelar identiteten till en databas, så varje replika bär med sig sin egen tilldelning. Konfigurera geo-sekundären på samma sätt som primären innan du växlar över:

  • Tilldela samma användartilldelade hanterade identitet som den primära använder till den sekundära databasen.
  • Ger den identiteten samma lagringsåtkomst som beskrivs i steg 3: Ger identiteten åtkomst till lagringen.
  • För åtkomst mellan klientorganisationer, sätt samma Federated client identity på den sekundära databasen.

När du konfigurerar båda replikerna på detta sätt fortsätter frågor som använder en autentiseringsuppgift med databasomfång att fungera efter en failover. Kravet matchar kundhanterade nycklar på databasnivå, som också kräver att identiteten är konfigurerad på varje replik.

Samma konfiguration gäller både för aktiv geo-replikering och failover-grupper.

Limitations

  • Endast Azure SQL Database. Azure SQL Managed Instance, SQL Server och Azure Synapse Analytics stöder inte dessa autentiseringsuppgifter.
  • Endast utgående autentisering. Denna funktion förändrar inte hur användare och applikationer autentiserar sig mot databasen.
  • Stöds inte i master databasen. Skapa autentiseringsuppgiften i en användardatabas.
  • Endast användar-tilldelade hanterade identiteter. En systemtilldelad hanterad identitet är begränsad till den logiska servern, så den kan inte agera som en databasnivåidentitet.
  • En användartilldelad hanterad identitet per databas.
  • Denna förhandsgranskning täcker endast datavirtualisering: CREATE EXTERNAL TABLE och OPENROWSET med DATA_SOURCE. Andra utgående funktioner, såsom sp_invoke_external_rest_endpoint, omfattas inte.

Troubleshoot

Att skapa en database-scoped credential bekräftar inte att databasidentiteten kan hämta en token eller få åtkomst till lagring. Fel dyker upp senare, när du skapar en extern datakälla eller kör en fråga som använder autentiseringsuppgifterna.

Databasidentiteten är inte konfigurerad (fel 15858)

Du kan skapa en autentiseringsuppgift med IDENTITY = 'DATABASE MANAGED IDENTITY' innan du tilldelar en användartilldelad hanterad identitet till databasen. Om en fråga sedan använder inloggningsuppgifterna och databasen inte har någon identitet för att hämta en token med, misslyckas frågan med felet 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)'.

Tilldela databasen en användartilldelad hanterad identitet, som beskrivs i steg 2, ge den tillgång till lagringskontot och försök sedan på nytt med frågan. Att tilldela en identitet endast till den logiska servern konfigurerar inte en databasnivåidentitet. Om databastilldelningen finns på plats och felet kvarstår, kontakta Microsoft Support för att undersöka databasidentitetsprovisionering.

Note

Trace-flagga 4675 och steget för att ta bort och återskapa i Backup and restore to URL med managed identities gäller för SQL Server på Azure-VM:ar. De gäller inte för databashanterad identitet på databasnivå i Azure SQL Database.

Inloggningsuppgift kan inte hittas eller refereras (fel 46516)

När du skapar en extern datakälla kontrollerar Azure SQL Database att autentiseringsuppgiften finns i den aktuella databasen och att du har behörighet att referera till den. Om någon av kontrollerna misslyckas får du fel 46516:

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

Skapa autentiseringsuppgiften i databasen som innehåller den externa datakällan, kontrollera namnet på autentiseringsuppgiften och se till att du har behörighet att referera till autentiseringsuppgiften.

Tokenförvärv misslyckas (fel 15858)

När databasen inte kan få en Microsoft Entra-token och tokenleverantören returnerar en anledning, inkluderar fel 15858 den anledningen:

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

Använd det nästlade felmeddelandet för att ta reda på varför tokenförfrågan misslyckades. För åtkomst mellan klientorganisationer kontrollerar du applikationen, administratörssamtycket i lagringsklientorganisationen och den federerade identitetsautentiseringsuppgiften, enligt beskrivningen i Konfigurera en applikation så att den litar på en hanterad identitet.

För att läsa extern data behöver identiteten också en lagringsdataroll. För åtkomst inom samma klientorganisation, ge Storage Blob Data Reader på containern eller lagringskontot till databasens användartilldelade hanterade identitet. För åtkomst mellan klientorganisationer, ge den till applikationens tjänsthuvudnamn i lagringsklientorganisationen. Mer information finns i Tilldela en Azure-roll för åtkomst till blobdata.

Filen existerar inte eller kan inte nås (fel 4860)

När en fil saknas eller inte kan läsas får du fel 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.

Kontrollera att filen finns på den konfigurerade platsen. Kontrollera sedan att identiteten som förfrågan använder kan komma åt den, via en lagringsdataroll eller, för ADLS Gen2, åtkomstkontrolllistor (ACL) på sökvägen.

Nätverksåtkomst blockeras (fel 42121 och 16539)

När den logiska servern är kopplad till en nätverkssäkerhetsperimeter som inte tillåter utgående trafik till lagringskontot, får du fel 42121:

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

Lägg till en utgående åtkomstregel för lagringskontots värdnamn till perimeterprofilen, eller koppla lagringskontot till samma perimeter. För mer information, se Network security perimeter for Azure SQL Database.

När utgående nätverk är begränsat på den logiska servern och lagringskontot inte finns med i serverns utgående brandväggsregler, får du felmeddelande 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.

Lägg till en utgående brandväggsregel för det exakta lagringsvärdnamnet i den externa datakällans platsangivelse. För mer information, se Outbound firewall rules for Azure SQL Database och Azure Synapse Analytics.

Cross-tenant-konfigurationen saknas eller är felaktig (fel 16561 och 16562)

En cross-tenant-fråga kan misslyckas med något av dessa fel, eller med fel 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.

Dessa fel innebär att frågan inte kunde nå filerna. Identiteten kanske inte har den nödvändiga lagringsrollen, nätverksåtkomst kan vara blockerad, lagringsplatsen kanske inte kan matchas, eller tokenen kan vara för fel klientorganisation. Så här åtgärdar du det:

  • Tilldela rätt lagringsdataroll.
  • Tillåt nätverksåtkomst till lagringskontot.
  • Inkludera containern i platsen för den externa datakällan.
  • Använd DATABASE FEDERATED CLIENT IDENTITY, och ställ in Federated Client ID i databasen, som beskrivs i steg 4.
  • Bekräfta att subjektet för den federerade identitetslegitimationen exakt matchar den hanterade identitetens objekt-ID (principal-ID).

Frågekörningar misslyckas efter en failover

Om frågor misslyckas med token- eller auktoriseringsfel efter en redundansväxling, kan den nya primära inte ha samma användartilldelade hanterade identitet som den ursprungliga primära använde. Eller så kanske den identiteten inte har någon rolltilldelning på lagringskontot. Tilldela samma identitet till båda replikerna och ge dem lagringsåtkomst, som beskrivs i Geo-replikering och failover.

Vanliga frågor och svar

Kan autentiseringsuppgifter på servernivå och databasnivå samexistera på samma server?

Ja, på samma logiska server och i samma databas. Varje autentiseringsuppgifts IDENTITY-värde avgör vilken identitet en fråga använder: MANAGED IDENTITY använder serverns identitet och DATABASE MANAGED IDENTITY använder databasens identitet.

Kan jag använda en systemtilldelad hanterad identitet?

No. En systemtilldelad hanterad identitet tillhör den logiska servern, så du kan inte begränsa den till en databas. Använd en användar-tilldelad hanterad identitet.

Vilka tjänstenivåer och regioner stöder denna förhandsvisning?

Alla Azure SQL Database-tjänstenivåer, i alla Azure-regioner.

Behöver jag en huvudnyckel för databasen?

No. Varken DATABASE MANAGED IDENTITY eller DATABASE FEDERATED CLIENT IDENTITY använder en hemlighet, så ingen masternyckel krävs.

Fungerar den här funktionen med sp_invoke_external_rest_endpoint?

Inte i denna förhandsvisning. Förhandsvisningen täcker datavirtualisering.

Relaterat innehåll

  • Uppdaterades senast