Użyj zarządzanej tożsamości na poziomie bazy danych z Azure SQL Database (podgląd)

Dotyczy:Azure SQL Database

Zarządzana tożsamość na poziomie bazy danych daje pojedynczej bazie danych w Azure SQL Database własną tożsamość zarządzaną przypisaną przez użytkownika (UAMI). Baza danych, która ma taką tożsamość, uwierzytelnia się w usłudze Azure Storage jako ona sama, a nie jako logiczny serwer, który ją hostuje.

Bez tożsamości na poziomie bazy danych każda baza danych na logicznym serwerze dzieli zarządzaną tożsamość tego serwera, więc wszystkie uzyskują dostęp do tej samej pamięci masowej. Tożsamość na poziomie bazy danych zawęża ten dostęp do jednej bazy, więc każdej bazie danych można przyznać tylko potrzebne jej miejsce.

Wybierasz tożsamość w poświadczeniu o zakresie bazy danych, tym samym, którego używa się w zapytaniach wirtualizacji danych do odczytu plików Parquet, CSV i Delta z Azure Blob Storage lub Azure Data Lake Storage (ADLS) Gen2. Wybierz jedną z dwóch wartości poświadczenia tożsamości:

Tożsamość poświadczeń	Użyj go, gdy
`DATABASE MANAGED IDENTITY`	Konto magazynu znajduje się w tym samym dzierżawcy Microsoft Entra co baza danych.
`DATABASE FEDERATED CLIENT IDENTITY`	Konto magazynu znajduje się w innej dzierżawie i jest dostępne za pośrednictwem poświadczenia federacyjnej tożsamości (FIC).

Note

Jako funkcja w wersji zapoznawczej technologia przedstawiona w tym artykule podlega dodatkowym warunkom użytkowania dla wersji zapoznawczych platformy Microsoft Azure.

Prerequisites

Azure SQL Database na serwerze logicznym. Wszystkie poziomy usług i wszystkie regiony Azure obsługują tę funkcję.
Zarządzana tożsamość przypisana przez użytkownika w tej samej subskrypcji. Dla tła, zobacz Managed identities in Microsoft Entra for Azure SQL.
Uprawnienia do przypisywania ról na docelowym koncie magazynu, takich jak Owner lub User Access Administrator.
Konto Azure Blob Storage lub ADLS Gen2, które przechowuje pliki, które chcesz przeszukiwać.

Important

Baza danych może mieć tylko jedną przypisaną przez użytkownika tożsamość zarządzaną na poziomie bazy, w przeciwieństwie do serwera logicznego, który może mieć kilka. Zaplanuj identyfikator na bazę danych przed jego przypisaniem.

Jeśli baza danych używa kluczy zarządzanych przez klienta na poziomie bazy, ma już tożsamość na poziomie bazy, a dla kluczy międzydzierżawców federowany identyfikator klienta. Ta funkcja korzysta z tych samych dwóch ustawień. Udziel istniejącej tożsamości lub aplikacji dostępu do pamięci masowej zamiast przypisywać nowe tożsamości lub aplikacje. Jeśli przypiszesz inną tożsamość lub aplikację, najpierw daj jej dostęp do klucza szyfrującego. W przeciwnym razie aktualizacja może się nie powiodować lub baza danych może stracić dostęp do swojego klucza.

Wybierz opcję z tym samym dzierżawcą lub między dzierżawcami

Oba przewodniki krok po kroku tworzą poświadczenie o zakresie bazy danych i wykonują zapytania do danych zewnętrznych. Różnią się sposobem, w jaki tożsamość dociera do konta magazynu.

Jeśli baza danych i konto magazynu są w tej samej dzierżawie, postępuj zgodnie z instrukcją Używanie tożsamości na poziomie bazy danych w tej samej dzierżawie.
Jeśli konto pamięci znajduje się w innej dzierżawie, stosuj Użyj federowanej tożsamości klienta między dzierżawcami.

Użyj tożsamości na poziomie bazy danych w tej samej dzierżawie

Krok 1. Tworzenie tożsamości zarządzanej przypisanej przez użytkownika

Utwórz tożsamość i zanotuj zarówno jej identyfikator zasobu, jak i identyfikator obiektu (podmiotu zabezpieczeń). Potrzebujesz ID zasobu, aby przypisać tożsamość do bazy danych. Identyfikator obiektu (podmiotu zabezpieczeń) jest potrzebny tylko do przewodnika między dzierżawami, gdzie identyfikuje podmiot federowanego poświadczenia tożsamości.

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

W przypadku innych metod zobacz Zarządzanie zarządzanymi tożsamościami przypisanymi przez użytkownika.

Krok 2: Przypisz tożsamość do bazy danych

Przypisz UAMI do bazy danych, a nie do serwera logicznego. To zadanie wykorzystuje ten sam mechanizm co transparentne szyfrowanie danych na poziomie bazy danych (TDE) z kluczami zarządzanymi przez klienta, opisane w Klucze zarządzane przez klienta na poziomie bazy danych. Pełny zestaw metod przypisania można znaleźć w sekcji Uzyskiwanie lub ustawianie tożsamości zarządzanej dla bazy danych.

Aby przypisać tożsamość w portalu Azure:

Przejdź do swojej bazy danych SQL.
W obszarze Zabezpieczenia wybierz pozycję Tożsamość.
W sekcji User-Assigned Managed Identity wybierz Dodaj.
Wybierz utworzoną przez siebie tożsamość, a następnie wybierz Dodaj.
Wybierz Zapisz.

Aby przypisać tożsamość za pomocą Azure CLI, użyj 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>

Aby przypisać ją w PowerShell, użyj Set-AzSqlDatabase:

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

Identyfikator zasobu tożsamości wygląda jak /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Znajdź go w Właściwościach w tożsamości zarządzanej w portalu Azure.

Krok 3: Przyznaj tożsamości dostęp do pamięci masowej

Daj zarządzanej tożsamości dostęp do odczytu do konta magazynu:

Przejdź do konta przechowywania.
Wybierz Access Control (IAM).
Wybierz Dodaj>Dodaj przypisanie roli.
Wybierz rolę Storage Blob Data Reader , a następnie wybierz Następny.
W obszarze Przypisz dostęp do wybierz Tożsamość zarządzaną.
Wybierz Wybierz członków, wybierz przypisaną przez użytkownika tożsamość zarządzaną, a następnie wybierz Wybierz.
Wybierz Przejrzyj i przypisz.

Aby uzyskać bardziej szczegółowy dostęp na ADLS Gen2, ustaw listy kontroli dostępu (ACL) na konkretnych katalogach zamiast przypisywać rolę na poziomie konta. Więcej informacji można znaleźć w sekcji Access Control lists in Azure Data Lake Storage.

Krok 4: Utwórz poświadczenie w zakresie bazy danych

Połącz się z bazą danych użytkownika, a nie z master, i utwórz dane uwierzytelniające:

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

Te poświadczenia uwierzytelniające nie wymagają żadnego sekretu ani klucza głównego bazy danych. Silnik ustala tożsamość przypisaną bazie danych w czasie wykonywania zapytania.

Równoważnik na poziomie serwera używa innej wartości identyfikatora. Porównaj:

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

Pełną składnię można znaleźć w artykule CREATE DATABASE SCOPED CREDENTIAL.

Krok 5: Stwórz zewnętrzne źródło danych

Stwórz zewnętrzne źródło danych, które wskazuje na Twój kontener, i dołącz dane uwierzytelniające. Użyj prefiksu odpowiadającego typowi Twojej pamięci:

Typ magazynu	Prefiks lokalizacji
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: Wykonaj zapytanie do danych

Wysyłaj zapytania do plików ad hoc za pomocą OPENROWSET:

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

Lub zdefiniuj zewnętrzną tabelę dla powtarzających się zapytań:

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;

Użyj federowanej tożsamości klienta między dzierżawami

Używaj tej ścieżki, gdy twoja baza danych jest w jednym tenantze, a konto pamięci w innym. Rejestracja aplikacji wielodostępnej przenosi zaufanie między nimi: UAMI bazy danych jest podmiotem federacyjnego poświadczenia tożsamości w tej aplikacji, a dzierżawa magazynu udziela nazwie głównej usługi aplikacji dostępu do danych.

Wzorzec odpowiada kluczom zarządzanym przez klienta między dzierżawcami do transparentnego szyfrowania danych, więc konfiguracja wygląda znajomo, jeśli już korzystasz z tej funkcji.

Krok 1: Zarejestruj aplikację wielodzierżawczą

W dzierżawie, która zawiera bazę danych, zarejestruj aplikację wielodostępną w Microsoft Entra ID i zapisz jej identyfikator aplikacji (klienta).

Aby uzyskać więcej informacji, zobacz Rejestrowanie aplikacji przy użyciu Platforma tożsamości Microsoft.

Krok 2: Dodaj poświadczenie tożsamości federacyjnej

Dodaj poświadczenie federacyjne tożsamości do tej aplikacji, aby ufała tożsamości zarządzanej przypisanej przez użytkownika dla bazy danych. Aplikacja i tożsamość zarządzana muszą należeć do tego samego dzierżawcy Microsoft Entra.

W rejestracji aplikacji wybierz Certyfikaty i sekrety>Poświadczenia federacyjne>Dodaj poświadczenie.
W przypadku scenariusza Federated credential wybierz Managed Identity.
Wybierz tożsamość zarządzaną utworzoną w kroku 1 w przewodniku dla tego samego tenanta.
Sprawdź, czy automatycznie wypełniany Emitent identyfikuje Twoją dzierżawę. Dla chmury publicznej Azure emitentem jest https://login.microsoftonline.com/<tenant-id>/v2.0.
Upewnij się, że Audience ma wartość api://AzureADTokenExchange, dla publicznej chmury Azure.
Wprowadź unikalną nazwę dla danego poświadczenia i zapisz je.

Podmiotem poświadczenia jest identyfikator obiektu (podmiotu zabezpieczeń) tożsamości zarządzanej, a nie identyfikator klienta. Jeśli konfigurujesz poświadczenie ręcznie, skopiuj dokładnie Identyfikator obiektu (podmiotu zabezpieczeń), ponieważ temat rozróżnia wielkość liter. Microsoft Entra ID akceptuje błędne wartości emitenta, podmiotu lub audience po zapisaniu poświadczenia, ale wymiana tokenów później się nie udaje.

Więcej informacji można znaleźć w artykule Konfiguruj aplikację tak, aby ufała zarządzanej tożsamości.

W dzierżawie, która posiada konto magazynu:

Administrator wyraża zgodę na aplikację wielodostępną, która tworzy w tej dzierżawie jednostkę usługi.
Przypisz rolę Storage Blob Data Reader do tej jednostki usługi na koncie magazynu. Postępuj zgodnie z krokiem 3: Przyznaj tożsamości dostęp do pamięci masowej, ale dla przypisania dostępu wybierz Użytkownik, grupę lub jednostkę usługi, a następnie wybierz jednostkę usługi aplikacji.

Krok 4: Ustaw federowany identyfikator klienta w bazie danych

W tenantcie, który przechowuje bazę danych, przypisz do bazy tożsamość zarządzaną przypisaną przez użytkownika i ustaw identyfikator aplikacji (klienta) z kroku 1 jako Federated Client ID:

Wejdź do swojej bazy danych SQL.
W obszarze Zabezpieczenia wybierz pozycję Tożsamość.
W sekcji User-Assigned Managed Identity sprawdź, czy tożsamość z kroku 1 w instrukcji dla tej samej dzierżawy jest wymieniona. Jeśli nie, wybierz Dodaj, wybierz identyfikator, a następnie wybierz Dodaj.
W sekcji Federowana tożsamość klienta wybierz aplikację, a następnie wybierz Zapisz.

Aby ustawić go z 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>

Aby ustawić to w PowerShell:

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

Krok 5: Utwórz dane uwierzytelniające i zapytanie

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

Następnie stwórz zewnętrzną tabelę lub uruchom OPENROWSET względem PartnerStorage dokładnie tak, jak w kroku 6: Wykonaj zapytanie względem danych.

Porównaj tożsamości na poziomie serwera i bazy danych

Charakterystyka	Zarządzana tożsamość na poziomie serwera	Zarządzana tożsamość na poziomie bazy danych
Zakres tożsamości	Serwer logiczny	Pojedyncza baza danych
Składnia danych logowania	`IDENTITY = 'MANAGED IDENTITY'`	`IDENTITY = 'DATABASE MANAGED IDENTITY'`
Dostęp do pamięci masowej między locatariuszami	Niewspierane. Zamiast tego użyj sygnatury dostępu współdzielonego	Federowany identyfikator klienta ustawiony w bazie danych, używany z `IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'`
Poziom szczegółowości RBAC dla magazynu	Jedna tożsamość dla każdej bazy danych na serwerze	Jedna tożsamość dla każdej bazy danych
Zakres ekspozycji	Każda baza danych na serwerze ma ten sam dostęp	Ograniczone do jednej bazy danych
Typy tożsamości	Przypisana przez system lub użytkownika	Przypisane tylko użytkownikowi
Wymagany jest główny klucz bazy danych	No	No

Oba typy poświadczeń mogą współistnieć na tym samym logicznym serwerze i w jego bazach danych. Wybierz poświadczenie, które najlepiej odpowiada Twoim wymaganiom bezpieczeństwa.

Georeplikacja i przełączanie awaryjne

Przypisujesz identyfikator bazie danych, więc każda replika ma własne przypisanie. Skonfiguruj geo-secondary tak samo jak pierwotny przed przełączeniem awaryjnym:

Przypisz tę samą tożsamość zarządzaną przypisaną przez użytkownika, której używa podstawowa baza danych, do bazy wtórnej.
Przyznaj tej tożsamości ten sam dostęp do pamięci masowej opisany w kroku 3: Przyznaj tożsamości dostęp do pamięci masowej.
Dla dostępu między dzierżawcami ustaw tę samą federacyjną tożsamość klienta w pomocniczej bazie danych.

Gdy konfigurujesz obie repliki w ten sposób, zapytania korzystające z poświadczenia o zakresie bazy danych nadal działają po przełączeniu awaryjnym. Wymóg ten odpowiada kluczom zarządzanym przez klienta na poziomie bazy danych, które również wymagają tożsamości na każdej replice.

Ta sama konfiguracja dotyczy zarówno aktywnej georeplikacji, jak i grup failover.

Limitations

Tylko Azure SQL Database. Azure SQL Managed Instance, SQL Server i Azure Synapse Analytics nie obsługują tych tożsamości poświadczenia.
Tylko uwierzytelnianie wychodzące. Ta funkcja nie zmienia sposobu uwierzytelniania użytkowników i aplikacji do bazy danych.
Nie jest obsługiwany w bazie danych master. Utwórz poświadczenie w bazie danych użytkownika.
Tylko tożsamości zarządzane przypisane przez użytkownika. Zarządzana tożsamość przypisana systemowi jest przypisana do serwera logicznego, więc nie może działać jako tożsamość na poziomie bazy danych.
Jedna tożsamość zarządzana przypisana przez użytkownika na bazę danych.
Ten podgląd obejmuje wyłącznie wirtualizację danych: CREATE EXTERNAL TABLE oraz OPENROWSET z DATA_SOURCE. Inne funkcje wychodzące na zewnątrz, takie jak sp_invoke_external_rest_endpoint, nie są objęte zakresem.

Troubleshoot

Utworzenie poświadczenia o zakresie bazy danych nie potwierdza, że tożsamość bazy danych może otrzymać token lub uzyskać dostęp do pamięci masowej. Błędy pojawiają się później, gdy tworzysz zewnętrzne źródło danych lub uruchamiasz zapytanie korzystające z tego poświadczenia.

Tożsamość bazy danych nie jest skonfigurowana (błąd 15858)

Możesz utworzyć dane uwierzytelniające za pomocą IDENTITY = 'DATABASE MANAGED IDENTITY' przed przypisaniem do bazy danych przypisanej przez użytkownika tożsamości zarządzanej. Jeśli zapytanie następnie używa danych uwierzytelniających, a baza danych nie ma tożsamości, za pomocą której można uzyskać token, zapytanie kończy się błędem 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)'.

Przypisz do bazy danych przypisaną przez użytkownika tożsamość zarządzaną, jak opisano w kroku 2, daj jej dostęp do konta pamięci, a następnie ponownie spróbuj zapytanie. Przypisanie tożsamości tylko serwerowi logicznemu nie konfiguruje tożsamości na poziomie bazy danych. Jeśli przypisanie bazy danych jest skonfigurowane, a błąd nadal występuje, skontaktuj się z pomocą techniczną firmy Microsoft w celu zbadania aprowizacji tożsamości bazy danych.

Note

Flaga Trace 4675 oraz krok usuwania i odtwarzania w Backup and restore to URL za pomocą zarządzanych tożsamości dotyczą SQL Server na maszynach wirtualnych Azure. Nie dotyczą one zarządzanej tożsamości na poziomie bazy danych w Azure SQL Database.

Dane uwierzytelniające nie są dostępne ani nie można się do nich odwołać (błąd 46516)

Gdy tworzysz zewnętrzne źródło danych, Azure SQL Database sprawdza, czy poświadczenie istnieje w bieżącej bazie danych i czy masz uprawnienia do odwoływania się do niego. Jeśli którykolwiek z tych testów się nie powiedzie, pojawia się błąd 46516:

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

Utwórz poświadczenie w bazie danych zawierającej zewnętrzne źródło danych, sprawdź nazwę poświadczenia i upewnij się, że masz uprawnienia do odwołania się do poświadczenia.

Pozyskanie tokena nie powiodło się (błąd 15858)

Gdy baza danych nie może uzyskać tokena Microsoft Entra, a dostawca tokena zwraca powód, błąd 15858 zawiera ten powód:

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

Użyj zagnieżdżonego komunikatu o błędzie, aby dowiedzieć się, dlaczego żądanie uzyskania tokenu nie powiodło się. Aby uzyskać dostęp między tenantami, sprawdź aplikację, zgodę administratora w tenantze magazynu oraz poświadczenie federacyjne tożsamości, jak opisano w sekcji Configure an application to trust a managed identity.

Aby odczytać dane zewnętrzne, tożsamość potrzebuje także roli danych magazynu. Aby uzyskać dostęp w ramach tego samego tenanta, nadaj rolę Storage Blob Data Reader dla kontenera lub konta magazynu tożsamości zarządzanej przypisanej przez użytkownika dla bazy danych. Aby uzyskać dostęp między dzierżawcami, przyznaj go nazwie głównej usługi aplikacji w dzierżawie magazynu. Aby uzyskać więcej informacji, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych blob.

Plik nie istnieje lub nie można do niego uzyskać dostępu (błąd 4860)

Gdy plik brakuje lub nie da się go odczytać, pojawia się błąd 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.

Sprawdź, czy plik istnieje w skonfigurowanej lokalizacji. Następnie sprawdź, czy tożsamość używana przez żądanie może uzyskać do niego dostęp poprzez rolę danych magazynowych lub, w przypadku ADLS Gen2, listy kontroli dostępu (ACL) na ścieżce.

Dostęp do sieci jest zablokowany (błędy 42121 i 16539)

Gdy serwer logiczny jest powiązany z obwodem bezpieczeństwa sieciowego, który nie pozwala na ruch wychodzący do konta magazynu, pojawia się błąd 42121:

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

Dodaj regułę dostępu wychodzącego dla nazwy hosta konta magazynu do profilu perymetru lub powiąż konto magazynu z tym samym perymetrem. Więcej informacji można znaleźć w artykule Network Security Perimeter for Azure SQL Database.

Gdy sieć wychodząca jest ograniczona na serwerze logicznym, a konto pamięci nie znajduje się w regułach zapory wychodzącej serwera, pojawia się błąd 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.

Dodaj regułę zapory wychodzącej dla dokładnej nazwy hosta magazynu danych w lokalizacji zewnętrznego źródła danych. Więcej informacji można znaleźć w artykule Outbound firewall rules for Azure SQL Database oraz Azure Synapse Analytics.

Brak lub nieprawidłowa konfiguracja między dzierżawcami (błędy 16561 i 16562)

Zapytanie między dzierżawcami może zakończyć się niepowodzeniem przy każdym z tych błędów lub przy błędzie 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.

Te błędy oznaczają, że zapytanie nie mogło dotrzeć do plików. Tożsamość może nie mieć wymaganej roli usługi Storage, dostęp do sieci może być zablokowany, lokalizacja magazynu może nie być rozpoznawana lub token może być dla niewłaściwego tenanta. Aby rozwiązać ten problem:

Nadaj odpowiednią rolę danych magazynu.
Zezwól na dostęp sieciowy do konta magazynu.
Umieść kontener w zewnętrznej lokalizacji źródła danych.
Użyj DATABASE FEDERATED CLIENT IDENTITY, i ustaw Federated Client ID w bazie danych, jak opisano w kroku 4.
Potwierdź, że podmiot federowanego poświadczenia tożsamości dokładnie odpowiada identyfikatorowi obiektu (principal) tożsamości zarządzanej.

Zapytania kończą się niepowodzeniem po przełączeniu awaryjnym

Jeśli zapytania nie powiodą się z błędami tokena lub autoryzacji po awaryjnym przełączaniu, nowy główny obiekt może nie mieć tej samej tożsamości zarządzanej przypisanej przez użytkownika, której używał oryginalny główny obiekt. Albo ta tożsamość może nie mieć przypisania roli na koncie magazynu danych. Przypisz tę samą tożsamość obu replikom i przyznaj tej tożsamości dostęp do pamięci masowej, jak opisano w Geo-replikacja i przełączanie awaryjne.

Często zadawane pytania

Czy dane uwierzytelniające na poziomie serwera i bazy danych mogą współistnieć na tym samym serwerze?

Tak, na tym samym logicznym serwerze i w tej samej bazie danych. Wartość IDENTITY każdego poświadczenia decyduje o tym, której tożsamości używa zapytanie: MANAGED IDENTITY używa tożsamości serwera, a DATABASE MANAGED IDENTITY używa tożsamości bazy danych.

Czy mogę użyć zarządzanej tożsamości przypisanej przez system?

No. Zarządzana tożsamość przypisana przez system należy do serwera logicznego, więc nie można jej ograniczyć do jednej bazy danych. Używaj zarządzanej tożsamości przypisanej przez użytkownika.

Które poziomy usług i regiony obsługują tę wersję zapoznawczą?

Wszystkie Azure SQL Database service tiers, we wszystkich regionach Azure.

Czy potrzebuję klucza głównego bazy danych?

No. Ani DATABASE MANAGED IDENTITY, ani DATABASE FEDERATED CLIENT IDENTITY nie przyjmują sekretu, więc nie jest potrzebny klucz główny.

Czy ta funkcja działa z sp_invoke_external_rest_endpoint?

Nie w tym podglądzie. Podgląd obejmuje wirtualizację danych.

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2026-10-30