Použijte spravovanou identitu na úrovni databáze s Azure SQL Database (preview)

Týká se:Azure SQL Database

Spravovaná identita na úrovni databáze poskytuje jednotlivé databázi v Azure SQL Database vlastní uživatelem přiřazenou spravovanou identitu (UAMI). Databáze, která má spravovanou identitu, se autentizuje do Azure Storage jako ona sama, nikoli jako logický server, který ji hostuje.

Bez identity na úrovni databáze sdílí každá databáze na logickém serveru spravovanou identitu tohoto serveru, takže všechny dosahují stejného úložiště. Identita na úrovni databáze zužuje tento přístup na jednu databázi, takže můžete každé databázi přidělit pouze potřebné úložiště.

Identitu vyberete v pověření s rozsahem na databázi, stejném pověření, který používají dotazy virtualizace dat pro čtení souborů Parquet, CSV a Delta z Azure Blob Storage nebo Azure Data Lake Storage (ADLS) Gen2. Vyberte jednu ze dvou hodnot identity přihlašovacích údajů:

Identita přihlašovacích údajů Použijte ji, když
DATABASE MANAGED IDENTITY Úložný účet je ve stejném Microsoft Entra tenantu jako databáze.
DATABASE FEDERATED CLIENT IDENTITY Účet úložiště je v jiném tenantovi, ke kterému se dostanete prostřednictvím přihlašovacího údaje federované identity (FIC).

Note

Jako funkce ve verzi Preview platí, že technologie uvedená v tomto článku podléhá dodatečným podmínkám použití pro verze Microsoft Azure Preview.

Prerequisites

  • Databáze Azure SQL Database na logickém serveru. Všechny úrovně služeb a všechny Azure regiony tuto funkci podporují.
  • Uživatelem přiřazená spravovaná identita ve stejném předplatném. Pro kontext viz Managed identities in Microsoft Entra for Azure SQL.
  • Oprávnění přiřazovat role na cílovém účtu úložiště, například Owner nebo User Access Administrator.
  • Účet Azure Blob Storage nebo ADLS Gen2, který uchovává soubory, na které se chcete dotazovat.

Important

Databáze může mít na úrovni databáze přiřazenou pouze jednu uživatelem přiřazenou spravovanou identitu, na rozdíl od logického serveru, který jich může mít více. Naplánujte identitu pro jednotlivé databáze ještě před jejím přiřazením.

Pokud databáze používá klíče spravované zákazníkem na úrovni databáze, už má identitu na úrovni databáze a pro klíče pro více tenantů federované ID klienta. Tato funkce používá stejná dvě nastavení. Udělit přístup k úložišti existující identitě nebo aplikaci místo přiřazování nových. Pokud přiřadíte jinou identitu nebo aplikaci, nejprve jí udělte přístup ke šifrovacímu klíči. Jinak může aktualizace selhat, nebo databáze může ztratit přístup ke svému klíči.

Vyberte stejný tenant nebo tenant mezi tenanty

Oba názorné postupy vytvářejí přihlašovací údaje s rozsahem databáze a dotazují se na externí data. Liší se v tom, jak se identita dostane k účtu úložiště.

Použijte identitu na úrovni databáze ve stejném tenantu

Krok 1: Vytvoření spravované identity přiřazené uživatelem

Vytvořte identitu a poznamenejte jak její ID zdroje, tak ID objektu (principal). K přiřazení identity databázi potřebujete Resource ID. Objekt (principal) ID potřebujete pouze pro podrobný postup mezi tenanty, kde identifikuje subjekt přihlašovacího údaje federované identity.

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

Pro jiné metody viz Správa spravovaných identit přiřazených uživatelem.

Krok 2: Přiřaďte identitu databázi

Přiřaďte UAMI k databázi, ne k logickému serveru. Toto přiřazení využívá stejný mechanismus jako transparentní šifrování dat na úrovni databáze (TDE) s klíči spravovanými zákazníkem, popsaný v Klíče spravované zákazníkem na úrovni databáze. Pro kompletní sadu metod přiřazení viz Získat nebo nastavit spravovanou identitu pro databázi.

Pro přiřazení identity v portálu Azure:

  1. Jděte do své SQL databáze.
  2. V části Zabezpečení vyberte Identita.
  3. V části spravovaná identita přiřazená uživatelem vyberte Přidat.
  4. Vyberte identitu, kterou jste vytvořili, a pak zvolte Přidat.
  5. Vyberte Uložit.

Pro přiřazení identity s Azure CLI použijte 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>

Pro přiřazení pomocí PowerShellu použijte Set-AzSqlDatabase:

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

Identitní Resource ID vypadá jako /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Najděte ho na stránce Vlastnosti spravované identity v Azure portálu.

Krok 3: Udělit identitě přístup k úložišti

Dejte spravované identitě přístup ke čtení pro účet úložiště:

  1. Přejděte do úložiště.
  2. Vyberte Řízení přístupu (IAM).
  3. Vyberte Přidat>Přidat úlohu.
  4. Vyberte roli Storage Blob Data Reader a poté zvolte Další.
  5. Pro přiřazení přístupu vyberte Spravovaná identita.
  6. Vyberte Vybrat členy, zvolte uživatelem přiřazenou spravovanou identitu a poté zvolte Vybrat.
  7. Vyberte Review + assign.

Pro jemnější řízení přístupu na ADLS Gen2 nastavte seznamy řízení přístupu (ACL) pro konkrétní adresáře místo přiřazování role na úrovni účtu. Pro více informací viz seznamy řízení přístupu v Azure Data Lake Storage.

Krok 4: Vytvořte pověření s rozsahem na databázi

Připojte se ke své uživatelské databázi, nikoli master, a vytvořte přihlašovací údaje:

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

Tento přihlašovací údaj nepotřebuje žádný tajný klíč ani hlavní klíč databáze. Engine určí identitu přiřazenou databázi během zpracování dotazu.

Serverový ekvivalent používá jinou hodnotu identity. Porovnat:

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

Pro úplnou syntaxi viz CREATE DATABASE SCOPED CREDENTIAL.

Krok 5: Vytvořte externí zdroj dat

Vytvořte externí zdroj dat, který ukazuje na váš kontejner, a připojte přihlašovací údaje. Použijte předponu, která odpovídá vašemu typu úložiště:

Typ úložiště Předpona umístění
Azure Blob Storage abs://
ADLS Gen2 adls:// 
CREATE EXTERNAL DATA SOURCE MyExternalStorage
WITH (
    LOCATION = 'abs://<container>@<storage-account>.blob.core.windows.net',
    CREDENTIAL = MyDBIdentityCred
);

Krok 6: Dotaz na data

Dotazujte soubory ad hoc pomocí OPENROWSET:

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

Nebo definujte externí tabulku pro opakované dotazy:

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;

Používejte federovanou identitu klienta napříč tenanty

Použijte tuto cestu, když je vaše databáze v jednom tenantu a úložný účet v jiném. Registrace multitenantní aplikace nese důvěru mezi nimi: UAMI databáze je subjektem přihlašovacího údaje federované identity v této aplikaci a tenant úložiště uděluje instančnímu objektu služby aplikace přístup k datům.

Vzor odpovídá klíčům spravovaným zákazníky napříč nájemci pro transparentní šifrování dat, takže nastavení vypadá povědomě, pokud tuto funkci již používáte.

Krok 1: Zaregistrujte multitenant aplikaci

V tenantovi, ve kterém je databáze umístěna, zaregistrujte multitenant aplikaci v Microsoft Entra ID a zaznamenejte její Application (klient) ID.

Další informace najdete v tématu Registrace aplikace na platformě Microsoft Identity Platform.

Krok 2: Přidejte přihlašovací údaje federované identity

Přidejte k této aplikaci přihlašovací údaj federované identity, aby důvěřovala uživatelem přiřazené spravované identitě databáze. Aplikace a spravovaná identita musí patřit ke stejnému tenantovi Microsoft Entra.

  1. Při registraci aplikace vyberte Certifikáty a tajemství>Federované přihlašovací údaje>Přidat přihlašovací údaje.
  2. Pro scénář federovaných přihlašovacích údajů vyberte Managed Identity.
  3. Vyberte spravovanou identitu, kterou jste vytvořili v kroku 1 postupu pro stejného tenanta.
  4. Ověřte, že automaticky vyplněný Issuer identifikuje vašeho tenanta. Pro veřejný cloud Azure je vydavatelem https://login.microsoftonline.com/<tenant-id>/v2.0.
  5. Ujistěte se, že Audience je api://AzureADTokenExchange, hodnota pro veřejný cloud Azure.
  6. Zadejte jedinečný název pro přihlašovací údaj a pak jej uložte.

Předmětem přihlašovacího údaje je Object (principal) ID spravované identity, nikoli ID klienta. Pokud konfigurujete přihlašovací údaje ručně, zkopírujte ID objektu (principal) přesně, protože subject rozlišuje velká a malá písmena. Microsoft Entra ID přijímá nesprávné hodnoty vydavatele, subjektu nebo publika při ukládání přihlašovacích údajů, ale výměna tokenů později selže.

Pro více informací viz Konfigurace aplikace tak, aby důvěřovala spravované identitě.

V tenantu, který obsahuje účet úložiště:

  1. Správce udělí souhlas víceklientské aplikaci, která v tomto tenantovi vytvoří instanční objekt služby.
  2. Přiřaďte roli Storage Blob Data Reader tomuto instančnímu objektu služby na účtu úložiště. Postupujte podle kroku 3: Udělte identitě přístup k úložišti, ale u možnosti Přiřadit přístup k vyberte uživatele, skupinu nebo instanční objekt služby a potom vyberte instanční objekt služby aplikace.

Krok 4: Nastavte federované ID klienta v databázi

V tenantovi, ve kterém je databáze, přiřaďte uživatelem přiřazenou spravovanou identitu databázi a nastavte Application (client) ID z kroku 1 jako Federated Client ID:

  1. Jděte do své SQL databáze.
  2. V části Zabezpečení vyberte Identita.
  3. V User-Assigned Managed Identity zkontrolujte, že je uvedena identita z kroku 1 postupu pro stejného tenanta. Pokud ne, vyberte Přidat, vyberte identitu a pak vyberte Přidat.
  4. V sekci Federovaná identita klienta vyberte aplikaci a poté zvolte Uložit.

Nastavit ho pomocí 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>

Pro nastavení pomocí PowerShellu:

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

Krok 5: Vytvořte přihlašovací údaj a dotaz

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

Poté vytvořte externí tabulku nebo spusťte OPENROWSET vůči PartnerStorage přesně tak, jak v kroku 6: Dotazujte se na data.

Porovnejte identity na úrovni serveru a na úrovni databáze

Charakteristika Spravovaná identita na úrovni serveru Spravovaná identita na úrovni databáze
Rozsah identity Logický server Jednotná databáze
Syntaxe přihlašovacích údajů IDENTITY = 'MANAGED IDENTITY' IDENTITY = 'DATABASE MANAGED IDENTITY'
Přístup k úložišti napříč tenanty Nepodporováno. Místo toho použijte Shared Access Signature (SAS) Federované ID klienta nastavené v databázi, použité s IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'
Podrobnost RBAC pro úložiště Jedna identita pro každou databázi na serveru Jedna identita pro každou databázi
Rozsah expozice Každá databáze na serveru má sdílený přístup Omezeno na jednu databázi
Typy identit Přiřazené systémem nebo přiřazené uživatelem Pouze přiřazené uživatelem
Vyžaduje se hlavní klíč databáze No No

Oba typy přihlašovacích údajů mohou koexistovat na stejném logickém serveru a v jeho databázích. Vyberte si přihlašovací údaj, který nejlépe odpovídá vašim bezpečnostním požadavkům.

Georeplikace a failover

Identitu přiřadíte databázi, takže každá replika má své vlastní přiřazení. Před failoverem nastavte geo-sekundární systém stejně jako primární:

  • Přiřaďte sekundární databázi stejnou uživatelem přiřazenou spravovanou identitu, jakou používá primární.
  • Udělte této identitě stejný přístup k úložišti jako v kroku 3: Udělte identitě přístup k úložištu.
  • Pro přístup mezi nájemci nastavte stejnou federovanou identitu klienta na sekundární databázi.

Když takto konfigurujete obě repliky, dotazy s pověřením s rozsahem databáze pokračují v práci i po failoveru. Požadavek odpovídá klíčům spravovaným zákazníkem na úrovni databáze, které také potřebují identitu přítomnou na každé replikě.

Stejná konfigurace platí jak pro aktivní geo-replikaci, tak pro skupiny pro failover.

Limitations

  • Pouze Azure SQL Database. Azure SQL Managed Instance, SQL Server a Azure Synapse Analytics tyto přihlašovací identity nepodporují.
  • Pouze odchozí autentizace. Tato funkce nemění způsob, jakým se uživatelé a aplikace autentizují do databáze.
  • V databázi master není podporováno. Vytvořte přihlašovací údaj v uživatelské databázi.
  • Pouze spravované identity přiřazené uživatelem. Systémově přiřazená spravovaná identita je zaměřena na logický server, takže nemůže fungovat jako identita na úrovni databáze.
  • Jedna uživatelem přiřazená spravovaná identita pro každou databázi.
  • Tento náhled pokrývá pouze virtualizaci dat: CREATE EXTERNAL TABLE a OPENROWSET s DATA_SOURCE. Jiné odchozí funkce, jako například sp_invoke_external_rest_endpoint, nespadají do rozsahu.

Troubleshoot

Vytvoření přihlašovacího údaje s rozsahem databáze nepotvrzuje, že identita databáze může získat token nebo přístup k úložišti. Chyby se objevují později, když vytvoříte externí zdroj dat nebo spustíte dotaz, který používá přihlašovací údaje.

Identita databáze není nakonfigurována (chyba 15858)

Přihlašovací údaje můžete vytvořit IDENTITY = 'DATABASE MANAGED IDENTITY' předtím, než přiřadíte k databázi spravovanou identitu přiřazenou uživatelem. Pokud dotaz poté použije přihlašovací údaje a databáze nemá žádnou identitu, pomocí které by získala token, dotaz selže s chybou 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)'.

Přiřaďte uživatelem přiřazenou spravovanou identitu databázi, jak je popsáno v kroku 2, dejte jí přístup k úložnému účtu a poté dotaz zkuste znovu. Přiřazení identity pouze logickému serveru nekonfiguruje identitu na úrovni databáze. Pokud je přiřazení databáze na místě a chyba přetrvává, kontaktujte podpora Microsoftu kvůli prověření zřizování identity databáze.

Note

Příznak trasování 4675 a krok mazání a znovuvytvoření v Backup and restore to URL pomocí spravovaných identit platí pro SQL Server na virtuálních počítačích Azure. Neplatí to pro spravovanou identitu na úrovni databáze v Azure SQL Database.

Přihlašovací údaj nelze najít ani na něj odkazovat (chyba 46516)

Když vytvoříte externí zdroj dat, Azure SQL Database kontroluje, zda přihlašovací údaje existují v aktuální databázi a zda máte oprávnění na něj odkazovat. Pokud některá z těchto kontrol selže, dostanete chybu 46516:

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

Vytvořte přihlašovací údaje v databázi, která obsahuje externí zdroj dat, zkontrolujte název přihlašovacích údajů a ujistěte se, že máte oprávnění k odkazování na přihlašovací údaje.

Získání tokenu selhává (chyba 15858)

Když databáze nemůže získat Microsoft Entra token a poskytovatel tokenu vrátí důvod, chyba 15858 tento důvod obsahuje:

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

Použijte vnořenou chybovou zprávu, abyste zjistili, proč požadavek na token selhal. Pro přístup mezi tenanty zkontrolujte aplikaci, souhlas správce v tenantovi úložiště a federované identifikační údaje, jak je popsáno v sekci Konfigurace aplikace tak, aby důvěřovala spravované identitě.

Pro čtení externích dat je pro identitu potřeba také role pro data v úložišti. Pro přístup v rámci stejného tenanta udělte Storage Blob Data Reader pro kontejner nebo účet úložiště uživatelem přiřazené spravované identitě databáze. Pro přístup mezi tenanty jej udělte instančnímu objektu služby aplikace v tenantovi úložiště. Další informace najdete v tématu Přiřazení role Azure pro přístup k datům objektů blob.

Soubor neexistuje nebo není přístupný (chyba 4860)

Když chybí nebo nelze přečíst soubor, zobrazí se chyba 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.

Zkontrolujte, že soubor existuje na nakonfigurovaném místě. Poté zkontrolujte, zda identita, kterou požadavek používá, k němu může přistupovat prostřednictvím role datových úložišť nebo, u ADLS Gen2, seznamů řízení přístupu (ACL) na cestě.

Síťový přístup je blokován (chyby 42121 a 16539)

Když je logický server spojen s bezpečnostním perimetrem sítě, který neumožňuje odchozí provoz na úložný účet, dostanete chybu 42121:

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

Přidejte pravidlo odchozího přístupu pro hostitelské jméno úložného účtu do profilu perimetru, nebo přiřaďte úložný účet ke stejnému perimetru. Pro více informací viz Síťový bezpečnostní perimetr pro Azure SQL Database.

Když je odchozí síťová komunikace na logickém serveru omezena a úložný účet není v pravidlech odchozího firewallu serveru, dostanete chybu 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.

Přidejte pravidlo odchozího firewallu pro přesné jméno hostitele úložiště v lokalitě externího datového zdroje. Další informace najdete v článku Pravidla odchozí brány firewall pro Azure SQL Database a Azure Synapse Analytics.

Konfigurace mezi nájemci chybí nebo je nesprávná (chyby 16561 a 16562)

Dotaz mezi tenanty může selhat s jednou z těchto chyb nebo s chybou 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.

Tyto chyby znamenají, že dotaz se nemohl dostat k souborům. Identita nemusí mít požadovanou roli úložiště, síťový přístup může být blokován, místo úložiště se nemusí vyřešit nebo token může být pro špatného tenanta. Aby bylo možné to opravit:

  • Přidělte příslušnou roli pro data úložiště.
  • Povolte síťový přístup k úložnému účtu.
  • Zahrňte kontejner do místa externího zdroje dat.
  • Použijte DATABASE FEDERATED CLIENT IDENTITY a nastavte u databáze Federované ID klienta, jak je popsáno v kroku 4.
  • Ověřte, že subjekt přihlašovacího údaje federované identity přesně odpovídá ID objektu (principal) spravované identity.

Dotazy selžou po failoveru

Pokud dotazy selžou s chybami tokenu nebo autorizace po failoveru, nový primární nemusí mít stejnou uživatelem přiřazenou spravovanou identitu, jakou původní primární používal. Nebo ta identita nemusí mít přiřazenou roli k účtu úložiště. Přiřaďte stejnou identitu oběma replikám a udělte jim přístup k úložišti, jak je popsáno v geografické replikaci a převzetí služeb při selhání.

Časté dotazy

Mohou serverové a databázové přihlašovací údaje koexistovat na stejném serveru?

Ano, na stejném logickém serveru a ve stejné databázi. Hodnota IDENTITY každého přihlašovacího údaje rozhoduje, kterou identitu dotaz použije: MANAGED IDENTITY používá identitu serveru a DATABASE MANAGED IDENTITY používá identitu databáze.

Mohu použít systémově přiřazenou spravovanou identitu?

No. Systémově přiřazená spravovaná identita patří logickému serveru, takže ji nelze omezit na jednu databázi. Použijte uživatelem přiřazenou spravovanou identitu.

Které úrovně služeb a regiony podporují tento náhled?

Všechny úrovně služeb Azure SQL Database ve všech oblastech Azure.

Potřebuji master key databáze?

No. Ani DATABASE MANAGED IDENTITY, ani DATABASE FEDERATED CLIENT IDENTITY nepřijímá tajný klíč, takže není potřeba hlavní klíč.

Funguje tato funkce s sp_invoke_external_rest_endpoint?

V tomto náhledu není k dispozici. Náhled se věnuje virtualizaci dat.

Související obsah

  • Poslední aktualizace v