Azure SQL Veritabanı ile veritabanı düzeyinde yönetilen kimliği kullanma (önizleme)

Şunlar için geçerlidir:Azure SQL Veritabanı

Veritabanı düzeyinde yönetilen kimlik, Azure SQL Veritabanı'deki bireysel bir veritabanına kendi kullanıcı tarafından atanan yönetilen kimliğini (UAMI) atar. Kimliği olan bir veritabanı, Azure Depolama'a, onu barındıran mantıksal sunucu olarak değil, kendisi olarak kimlik doğrulaması yapar.

Veritabanı düzeyinde bir kimlik olmadan, mantıksal bir sunucudaki her veritabanı o sunucunun yönetilen kimliğini paylaşır, böylece hepsi aynı depolamaya ulaşır. Veritabanı düzeyinde bir kimlik, erişimi tek bir veritabanına daraltıyor, böylece her veritabanına yalnızca ihtiyaç duyduğu depolamayı verebilirsiniz.

Kimlik tanımını, veri sanallaştırma sorgularının Azure Blob Depolama veya Azure Data Lake Storage (ADLS) Gen2'den Parquet, CSV ve Delta dosyalarını okumak için kullandığı veritabanı kapsamındaki bir kimlik bilgisinde seçersiniz. İki kimlik bilgisi kimlik değeri arasından birini seçin:

Kimlik bilgisi	Şu durumlarda kullanın:
`DATABASE MANAGED IDENTITY`	Depolama hesabı, veritabanıyla aynı Microsoft Entra kiracısında bulunuyor.
`DATABASE FEDERATED CLIENT IDENTITY`	Depolama hesabı farklı bir tenant'ta olup, federated identity credential (FIC) üzerinden ulaşılır.

Note

Önizleme özelliği olarak, bu makalede sunulan teknoloji Microsoft Azure Önizlemeleri için Ek Kullanım Koşulları'na tabidir.

Prerequisites

Mantıksal bir sunucuda Azure SQL Veritabanı. Tüm hizmet katmanları ve tüm Azure bölgeleri bu özelliği destekler.
Aynı abonelikte kullanıcı tarafından atanan yönetilen bir kimlik. Arka plan için bkz. Microsoft Entra for Azure SQL'de Managed identities.
Hedef depolama hesabında Sahip veya Kullanıcı Erişim Yöneticisi gibi roller atama izni.
Sorgulamak istediğiniz dosyaları tutan Azure Blob Depolama veya ADLS Gen2 hesabı.

Important

Bir veritabanı, veritabanı düzeyinde yalnızca bir kullanıcı tarafından atanan yönetilen kimliğe sahip olabilir; mantıksal bir sunucunun ise birden fazla kimliği olabilir. Atamadan önce veritabanı başına kimliği planlayın.

Veritabanı veritabanı düzeyinde müşteri tarafından yönetilen anahtarları kullanıyorsa, zaten veritabanı düzeyinde bir kimliğe sahiptir ve çapraz kiracı anahtarlar için federasyona dayalı bir istemci kimliği vardır. Bu özellik aynı iki ayarı kullanır. Yeni kimlik atamak yerine mevcut kimlik veya uygulamaya depolama erişimi verin. Farklı bir kimlik veya uygulama atarsanız, önce ona şifreleme anahtarına erişim verin. Aksi takdirde, güncelleme başarısız olabilir veya veritabanı kendi anahtarına erişimini kaybedebilir.

Aynı tenant veya tenantlar arası seçin

Her iki kılavuz da veritabanı kapsamında bir kimlik bilgisi oluşturur ve harici verileri sorgular. Kimliğin depolama hesabına nasıl ulaştığı bakımından farklıdırlar.

Veritabanı ve depolama hesabı aynı tenant'taysa, Aynı tenant'ta veritabanı düzeyinde kimlik kullanma yönergesini izleyin.
Depolama hesabı farklı bir dizinde ise Kiracılar arasında federe istemci kimliği kullanma bölümünü izleyin.

Aynı tenant içinde veritabanı düzeyinde bir kimlik kullanın

1. Adım: Kullanıcı tarafından atanan yönetilen kimlik oluşturma

Kimliği oluşturun ve hem Kaynak ID'sini hem de Nesne (sorumlu) ID'sini not edin. Kimliği veritabanına atamak için Kaynak Kimliği'ne ihtiyacınız var. Nesne (asıl/principal) kimliğine yalnızca kiracılar arası izlenecek yol için ihtiyacınız var; burada federe kimlik bilgisinin konusunu belirler.

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

Diğer yöntemler için bkz. Kullanıcı tarafından atanan yönetilen kimlikleri yönet.

Adım 2: Kimliği veritabanına atayın

UAMI'yi mantıksal sunucuya değil, veritabanına atayın. Bu atama, Veritabanı düzeyinde müşteri tarafından yönetilen anahtarlar bölümünde açıklanan, müşteri tarafından yönetilen anahtarlarla veritabanı düzeyinde şeffaf veri şifreleme (TDE) ile aynı mekanizmayı kullanır. Tam atama yöntemleri için Veritabanı için yönetilen kimlik alma veya ayarlama bölümüne bakınız.

Azure portalında kimliği atamak için:

SQL veritabanınıza gidin.
Güvenlik'in altında Kimlik'i seçin.
Kullanıcı Tarafından Atanan Yönetilen Kimlik altında Ekle seçeneğini belirleyin.
Oluşturduğunuz kimliği seçin, ardından Ekle'yi seçin.
Kaydetseçeneğini seçin.

Kimliği Azure CLI ile atamak için az sql db update kullanın:

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

Bunu PowerShell ile atamak için Set-AzSqlDatabase kullanın:

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

Kimlik Kaynak Kimliği/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name> gibi görünüyor. Bunu Azure portalındaki yönetilen kimliğin Özellikler altında bulun.

Adım 3: Kimliğe depoya erişim verin

Yönetilen kimliğe depolama hesabı için okuma erişimi verin:

Depolama hesabına gidin.
Erişim Denetimi (IAM) öğesini seçin.
Ekle>Rol ataması ekle’yi seçin.
Storage Blob Data Reader rolünü seçin ve ardından Sonraki seçin.
Erişim ataması için Yönetilen kimlik'i seçin.
Üyeleri Seç'i seçin, kullanıcı tarafından atanan yönetilen kimliğinizi seçin ve ardından Seç'i seçin.
Gözden geçir + ata'yı seçin.

ADLS Gen2'de daha ince erişim için, hesap seviyesinde rol atamak yerine belirli dizinlere erişim kontrol listeleri (ACL) ayarlayın. Daha fazla bilgi için Azure Data Lake Storage'daki Access control lists bölümüne bakınız.

Adım 4: veritabanı kapsamlı kimlik bilgisini oluşturun

Kullanıcı veritabanınıza bağlanın, master yerine, ve kimlik bilgisini oluşturun:

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

Bu kimlik bilgisi ne gizli anahtara ne de veritabanı ana anahtarına ihtiyaç duyuyor. Altyapı, sorgu zamanında veritabanına atanan kimliği belirler.

Sunucu düzeyindeki eşdeğer, farklı bir kimlik değeri kullanır. Karşılaştırmak:

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

Tam sözdizimi için bkz. CREATE DATABASE SCOPED CREDENTIAL.

Adım 5: Dış veri kaynağını oluşturun

Konteynerinize yönlendiren harici bir veri kaynağı oluşturun ve kimlik bilgisini ekleyin. Depolama tipinize uyan öneki kullanın:

Depolama türü	Konum ön eki
Azure Blob Depolama (Microsoft'un bulut depolama hizmeti)	`abs://`
ADLS Gen2	`adls://`

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

Adım 6: Verileri sorgulayın

Dosyaları ad hoc olarak sorgulayın:OPENROWSET

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

Ya da tekrarlanan sorgular için harici bir tablo tanımlayın:

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;

Kiracılar arasında federe istemci kimliği kullanın

Veritabanınız bir kiracıda, depolama hesabı başka bir kiracıda olduğunda bu yolu kullanın. Çok kiracılı uygulama kaydı, aralarındaki güveni sağlar: veritabanının UAMI'si, bu uygulamadaki bir federe kimlik bilgisi kimlik bilgisinin öznesidir ve depolama kiracısı, uygulamanın hizmet sorumlusuna verilere erişim izni verir.

Bu desen, şeffaf veri şifreleme için kiracılar arası müşteri tarafından yönetilen anahtarları örnek alıyor, bu yüzden bu özelliği zaten kullanıyorsanız kurulum tanıdık görünüyor.

Adım 1: Çok kiracılı bir uygulama kaydedin

Veritabanını barındıran kiracıda, Microsoft Entra ID'de çok kiracılı uygulama kaydedin ve uygulama (istemci) kimliğini not edin.

Daha fazla bilgi için Microsoft kimlik platformunda bir uygulamayı kaydetme bölümüne bakın.

Adım 2: Federe kimlik kimlik bilgisi ekleyin

O uygulamaya veritabanının kullanıcı tarafından atanan yönetilen kimliğine güvenmesi için federe bir kimlik kimlik bilgisi ekleyin. Uygulama ve yönetilen kimlik aynı Microsoft Entra kiracısına ait olmalıdır.

Uygulama kaydında, Sertifikalar ve gizli diziler>Federasyon kimlik bilgileri>Kimlik bilgisi ekle seçin.
Federated credential senaryosu için Managed Identity'yi seçin.
Aynı kiracılı rehberin 1. adımında oluşturduğunuz yönetilen kimliği seçin.
Otomatik olarak doldurulan Issuer öğesinin tenant’ınızı tanımladığını doğrulayın. Azure genel bulutu için düzenleyen https://login.microsoftonline.com/<tenant-id>/v2.0'dir.
Audience değerinin Azure genel bulutu için api://AzureADTokenExchange değeri olduğundan emin olun.
Kimlik bilgisi için benzersiz bir isim girin ve sonra kaydedin.

Kimlik bilgilerinin öznesi, yönetilen kimliğin Nesne (principal) ID'sidir, istemci ID'si değil. Kimlik bilgilerini manuel olarak yapılandırırsanız, Nesne (sorumlu) kimliğini tam olarak kopyalayın, çünkü özne büyük/küçük harfe duyarlıdır. Microsoft Entra ID, kimlik kaydettiğinizde yanlış veren, özne veya hedef kitle değerlerini kabul eder, ancak token değişimi daha sonra başarısız olur.

Daha fazla bilgi için, Bir uygulamayı yönetilen kimliğe güvenecek şekilde yapılandırma bölümünü inceleyebilirsiniz.

Depolama hesabını elinde tutan tenant'ta:

Bir yönetici, çok kiracılı uygulamaya onay verir ve bu da o kiracıda bir hizmet sorumlusu oluşturur.
Depolama hesabındaki o hizmet sorumlusuna Storage Blob Data Reader rolünü atayın. Adım 3'ü takip edin: Kimliğe depolamaya erişim izni verin, ancak Erişim ata için Kullanıcı, grup veya hizmet sorumlusunu seçin ve ardından uygulamanın hizmet sorumlusunu seçin.

Adım 4: Veritabanında federasyonlu istemci kimliğini ayarlayın

Veritabanını tutan kiracıda, kullanıcı tarafından atanan yönetilen kimliği veritabanına atayın ve 1. Adımdaki Uygulama (istemci) Kimliğini Federasyonlu İstemci Kimliği olarak ayarlayın:

SQL veritabanınıza gidin.
Güvenlik'in altında Kimlik'i seçin.
User-Assigned Yönetilen Kimlik bölümünde, aynı kiracı rehberinin 1. Adımındaki kimliğin listelendiğinden emin olun. Eğer öyle değilse, Ekle'yi seçin, kimliği seçin ve ardından Ekle'yi seçin.
Federasyon istemci kimliği altında uygulamayı seçin ve ardından Kaydet seçeneğini belirleyin.

Azure CLI ile ayarlamak için:

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 ile ayarlamak için:

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

Adım 5: kimlik bilgisi oluştur ve sorgula

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

Sonra harici bir tablo oluşturun veya tam olarak 6. Adım: Veriyi sorgulayın'da olduğu gibi PartnerStorage üzerinde OPENROWSET çalıştırın.

Sunucu düzeyi ve veritabanı düzeyindeki kimlikleri karşılaştırın

Özellik	Sunucu düzeyinde yönetilen kimlik	Veritabanı düzeyinde yönetilen kimlik
Kimlik kapsamı	Mantıksal sunucu	Tek veritabanı
Kimlik bilgisi sözdizimi	`IDENTITY = 'MANAGED IDENTITY'`	`IDENTITY = 'DATABASE MANAGED IDENTITY'`
Tenant’lar arası depolama erişimi	Desteklenmiyor. Bunun yerine paylaşılan erişim imzası kullanın	Veritabanında belirlenmiş federe istemci kimliği, `IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'` ile kullanılan
Depolama RBAC ayrıntı düzeyi	Sunucudaki her veritabanı için tek bir kimlik	Her veritabanı için bir kimlik
Maruz kalma kapsamı	Sunucudaki tüm veritabanları aynı erişimi paylaşır	Bir veritabanıyla sınırlı
Kimlik türleri	Sistem tarafından atanan veya kullanıcı tarafından atanan	Yalnızca kullanıcıya atanan
Veritabanı ana anahtarı gereklidir	No	No

Her iki kimlik bilgisi türü aynı mantıksal sunucuda ve veritabanlarında bir arada bulunabilir. Güvenlik gereksinimlerinize en uygun kimlik bilgisini seçin.

Geo-replikasyon ve failover

Kimliği bir veritabanına atarsınız, böylece her replika kendi atamasını taşır. Failover yapmadan önce jeo-ikincili birincil ile aynı şekilde yapılandırın:

Birincilin kullandığı aynı kullanıcı tarafından atanan yönetilen kimliği ikincil veritabanına atayın.
Bu kimliğe, 3. Adım: Kimliğe depolama erişimi verin bölümünde açıklanan aynı depolama erişimini verin.
Çapraz kiracı erişim için, aynı Federated istemci kimliğini ikincil veritabanında ayarlayın.

Her iki replikayı da bu şekilde yapılandırdığınızda, veritabanı kapsamlı kimlik bilgisi kullanan sorgular bir yük devretme sonrasında çalışmaya devam eder. Gereksinim, veritabanı düzeyindeki müşteri tarafından yönetilen anahtarlarla eşleşiyor ve bu anahtarlar da her kopyada kimliğin yerinde olmasını gerektiriyor.

Aynı yapılandırma hem aktif jeo-replikasyon hem de failover grupları için geçerlidir.

Limitations

Yalnızca Azure SQL Veritabanı. Azure SQL Yönetilen Örneği, SQL Server ve Azure Synapse Analytics bu credential identity'leri desteklemez.
Yalnızca giden kimlik doğrulaması. Bu özellik, kullanıcıların ve uygulamaların veritabanına kimlik doğrulama şeklini değiştirmez.
master veritabanında desteklenmiyor. Kimlik bilgisini bir kullanıcı veritabanında oluşturun.
Sadece kullanıcı tarafından atanan yönetilen kimlikler. Sistem tarafından atanan yönetilen bir kimlik, mantıksal sunucuya bağlıdır, bu yüzden veritabanı düzeyinde bir kimlik olarak hareket edemez.
Her veritabanı için kullanıcı tarafından atanan bir yönetilen kimlik.
Bu önizleme yalnızca veri sanallaştırmasını kapsar: CREATE EXTERNAL TABLE ve OPENROWSET, DATA_SOURCE ile birlikte. Diğer giden özellikler, örneğin sp_invoke_external_rest_endpoint, kapsamda değildir.

Troubleshoot

Veritabanı kapsamında bir kimlik bilgisi oluşturmak, veritabanı kimliğinin belirteç alabileceğini veya depolamaya erişebileceğini doğrulamaz. Hatalar daha sonra, harici bir veri kaynağı oluşturduğunuzda veya kimlik bilgilerini kullanan bir sorgu çalıştırdığınızda ortaya çıkar.

Veritabanı kimliği yapılandırılmamış (hata 15858)

Veritabanına kullanıcı tarafından atanan yönetilen kimlik atamadan önce IDENTITY = 'DATABASE MANAGED IDENTITY' ile bir kimlik bilgisi oluşturabilirsiniz. Bir sorgu kimlik bilgilerini kullanırsa ve veritabanında token almak için bir kimlik yoksa sorgu 15858 hatasıyla başarısız olur:

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)'.

Kullanıcı tarafından atanan bir yönetilen kimlik veritabanına Adım 2'de açıklandığı gibi atayın, depolama hesabına erişim verin ve ardından sorguyu tekrar deneyin. Yalnızca mantıksal sunucuya kimlik atamak, veritabanı düzeyinde bir kimlik yapılandırmaz. Veritabanı ataması mevcutsa ve hata devam ediyorsa, veritabanı kimliği sağlama durumunu araştırmak için Microsoft Desteği ile iletişime geçin.

Note

4675 izleme bayrağı ve yönetilen kimlikleri kullanarak URL'ye yedekleme ve geri yükleme bölümündeki silme ve yeniden oluşturma adımı Azure VM'lerde SQL Server için geçerlidir. Azure SQL Veritabanı'de veritabanı düzeyinde yönetilen kimlik için geçerli değildir.

Kimlik bilgileri bulunamıyor veya referans alınamıyor (hata 46516)

Harici bir veri kaynağı oluşturduğunuzda, Azure SQL Veritabanı credential'ın mevcut veritabanında var olup olmadığını ve ona referans verme izninizin olduğunu kontrol eder. İki kontrolden biri başarısız olursa, 46516 hatası alırsınız:

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

Harici veri kaynağını içeren veritabanında kimlik bilgisini oluşturun, kimlik bilgisinin adını kontrol edin ve kimlik bilgisine başvurma izniniz olduğundan emin olun.

Token edinimi başarısız oldu (hata: 15858)

Veritabanı Microsoft Entra tokenı alamıyorsa ve token sağlayıcı bir neden döndürüyorsa, 15858 hatası bu sebebi içerir:

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

Token isteğinin neden başarısız olduğunu öğrenmek için iç içe hata mesajını kullanın. Çapraz kiracı erişimi için, Bir uygulamayı yönetilen kimliğe güvenecek şekilde yapılandırma bölümünde açıklandığı gibi uygulamayı, depolama kiracısındaki yönetici onayını ve federe kimlik bilgisini denetleyin.

Harici verileri okumak için kimliğin ayrıca bir depolama verisi rolü de gereklidir. Aynı kiracı erişimi için, veritabanının kullanıcı tarafından atanan yönetilen kimliğine konteyner veya depolama hesabında Depolama Blob Veri Okuyucusu verin. Kiracılar arası erişim için, bunu depolama kiracısındaki uygulamanın hizmet sorumlusuna verin. Daha fazla bilgi için bkz. Blob verilerine erişim için Azure rolü atama.

Dosya yok ya da erişilemiyor (4860 hatası)

Bir dosya eksikse veya okunamazsa 4860 hatası alırsınız:

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.

Dosyanın yapılandırılmış konumda var olup olmadığını kontrol edin. Sonra, isteğin kullandığı kimliğin, bir depolama veri rolü veya ADLS Gen2 için yol üzerindeki erişim kontrol listeleri (ACL) üzerinden ona erişebildiğini kontrol edin.

Ağ erişimi engellendi (42121 ve 16539 hataları)

Mantıksal sunucu, depolama hesabına yönelik giden trafiğe izin vermeyen bir ağ güvenlik çevresiyle ilişkilendirildiğinde, 42121 hatası alınır:

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

Depolama hesabının ana bilgisayar adı için çevre profiline bir dış erişim kuralı ekleyebilir veya depolama hesabını aynı çevreyle ilişkilendirebilirsiniz. Daha fazla bilgi için bkz. Network security perimeter for Azure SQL Veritabanı.

Giden ağ trafiği mantıksal sunucuda kısıtlandığında ve depolama hesabı sunucunun giden güvenlik duvarı kurallarında olmadığında, 16539 hatası alınır:

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.

Dış veri kaynağının konumundaki tam depolama ana bilgisayar adı için bir giden güvenlik duvarı kuralı ekleyin. Daha fazla bilgi için Azure SQL Veritabanı ve Azure Synapse Analytics için giden güvenlik duvarı kuralları konusuna bakın.

Çapraz tenant yapılandırması eksik veya yanlış (hatalar 16561 ve 16562)

Çapraz kiracı sorgusu bu hatalardan biri veya 4860 hatası ile başarısız olabilir:

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.

Bu hatalar, sorgunun dosyalara ulaşamadığı anlamına geliyor. Kimlik gerekli depolama rolünü taşımayabilir, ağ erişimi engellenmiş olabilir, depolama yeri çözülmeyebilir veya token yanlış kiracı için olabilir. Düzeltmek için:

Uygun depolama veri rolünü verin.
Depolama hesabına ağ erişimine izin verin.
Konteyneri harici veri kaynağı konumuna ekleyin.
Adım 4'te açıklandığı gibi, veritabanında Federated Client ID'yi ayarlamak için DATABASE FEDERATED CLIENT IDENTITY kullanın.
Federe kimlik kimlik bilgisinin öznesinin yönetilen kimliğin Nesne (sorumlu) kimliği ile tam olarak eşleştiğini doğrulayın.

Yük devretmeden sonra sorgular başarısız olur

Eğer bir yük devretme sonrasında belirteç veya yetkilendirme hatalarıyla sorgular başarısız olursa, yeni birincil sistem, özgün birincilin kullandığı kullanıcı tarafından atanan yönetilen kimliğe sahip olmayabilir. Ya da bu kimlik depolama hesabında rol ataması olmayabilir. Her iki replikaya aynı kimliği atayın ve Geo-replication and failover bölümünde açıklandığı gibi bu kimliğe depolama erişimi verin.

Sık sorulan sorular

Sunucu düzeyinde ve veritabanı düzeyinde kimlik bilgileri aynı sunucuda bir arada bulunabilir mi?

Evet, aynı mantıksal sunucuda ve aynı veritabanında. Her kimlik bilgisinin IDENTITY değeri, bir sorgunun hangi kimliği kullanacağını belirler: MANAGED IDENTITY sunucunun kimliğini kullanır ve DATABASE MANAGED IDENTITY veritabanının kimliğini kullanır.

Sistem tarafından atanan yönetilen bir kimlik kullanabilir miyim?

Hayır Sistem tarafından atanan yönetilen bir kimlik mantıksal sunucuya aittir, bu yüzden kapsamını tek bir veritabanıyla sınırlandıramazsınız. Kullanıcı tarafından atanan yönetilen bir kimlik kullanın.

Bu önizlemeyi hangi hizmet katmanları ve bölgeler destekliyor?

Tüm Azure SQL Veritabanı hizmet katmanları, tüm Azure bölgelerinde.

Veritabanı ana anahtarına ihtiyacım var mı?

Hayır Ne DATABASE MANAGED IDENTITY ne de DATABASE FEDERATED CLIENT IDENTITY gizli anahtar kabul etmez, bu yüzden ana anahtara gerek yoktur.

Bu özellik sp_invoke_external_rest_endpoint ile çalışıyor mu?

Bu önizlemede yok. Önizleme, veri sanallaştırmasını kapsar.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Son güncelleştirme: 2026-10-30