Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bu makale, Django uygulamaları için mssql-django arka ucunu kullanarak Microsoft Entra kimlik doğrulamasının nasıl yapılandırılacağını açıklar. Microsoft Entra kimlik doğrulaması, uygulama yapılandırmanızda parola depolama gereksinimini ortadan kaldırır.
Prerequisites
-
Microsoft SQL Server için ODBC Driver 18 (önerilir). Bu makaledeki tüm kimlik doğrulama modları SQL Server için Microsoft ODBC Sürücüsü 18 ile desteklenir.
ActiveDirectoryInteractive, sürücü sürümünden bağımsız olarak yalnızca Windows içindir. ODBC Sürücüsü 17'yi kullanmanız gerekiyorsa, mod başına en az 17.x sürümleri için ODBC kimlik doğrulama başvurusuna bakın. - Erişim belirteci kimlik doğrulaması için:
pip install azure-identity.
Kimlik doğrulama yöntemleri
Django projenizin DATABASES dosyasında ayarı ekleyerek veya düzenleyerek settings.py her yöntemi yapılandırın. Bu makaledeki örneklerde netlik için tam DATABASES["default"] blok gösterilmektedir; ilgili anahtarları mevcut yapılandırmanıza kopyalayın.
mssql-djangoiki yolla Microsoft Entra kimlik doğrulamayı destekler:
-
OPTIONS["extra_params"]aracılığıyla ODBC sürücüsü kimlik doğrulaması. Arka uç, bu dizeyi ODBC bağlantı dizesine değiştirmeden ekler; bu nedenle kullanılabilirAuthentication=değerlerimssql-django'in kendisinden değil, yüklü Microsoft ODBC Driver for SQL Server'dan gelir. -
TOKENayarı aracılığıyla programatik erişim belirteci kimlik doğrulaması. Arka uç,TOKENöğesini ODBC sürücüsüneSQL_COPT_SS_ACCESS_TOKENolarak geçirir; böylece ODBCAuthentication=anahtar sözcüğünü atlar.
Bir bakışta kimlik doğrulama yöntemleri
| Method | ile yapılandırın | En iyi kullanım alanları |
|---|---|---|
| Erişim belirteci | TOKEN |
Geliştirme, kısa ömürlü betikler veya özel belirteç yenilemesine sahip uygulamalar |
ActiveDirectoryMsi |
extra_params |
Azure barındırılan üretim uygulamaları (sistem tarafından atanan ve kullanıcı tarafından atanan yönetilen kimlik) |
ActiveDirectoryServicePrincipal |
USER, PASSWORD, extra_params |
Yönetilen kimliğin kullanılamadığı durumlarda uygulama kayıtları |
ActiveDirectoryIntegrated |
extra_params |
Etki alanına katılmış kullanıcı bağlamı |
ActiveDirectoryInteractive |
USER, extra_params |
Çok faktörlü kimlik doğrulaması ile kullanıcı oturum açma (Windows) |
ActiveDirectoryDefault |
extra_params |
ODBC sürücüsünün varsayılan Microsoft Entra kimlik bilgisi zincirini kullanması gereken yerel geliştirme ve uygulamalar |
ActiveDirectoryPassword |
USER, PASSWORD, extra_params |
Yalnızca son çare olan eski sistem senaryoları (kullanım dışı) |
Note
mssql-django1.7.3 ve üzeri, SQL Server için yüklenen Microsoft ODBC Sürücüsünün bu modu desteklediğini kabul eder Authentication=ActiveDirectoryDefaultOPTIONS["extra_params"]. Belirteç alma ve yenileme davranışı üzerinde açık denetime ihtiyacınız varsa, sınıfıyla TOKEN desenini azure.identity.DefaultAzureCredential kullanın.
Azure SQL’de kimliğe erişim izni verin
Yönetilen kimlik veya hizmet sorumlusu kimlik doğrulaması için bir veritabanı kullanıcısı oluşturun ve yalnızca uygulamanızın ihtiyaç duyduğu rolleri verin:
CREATE USER [<identity-name>] FOR EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [<identity-name>];
ALTER ROLE db_datawriter ADD MEMBER [<identity-name>];
ALTER ROLE db_ddladmin ADD MEMBER [<identity-name>];
db_ddladmin sabit veritabanı rolü yalnızca uygulama geçişleri çalıştırıyorsa gereklidir. Yalnızca okuma iş yükleri için db_datareader yeterlidir.
Note
FROM EXTERNAL PROVIDER, asıl adı çözümlemek için SQL server'ın Microsoft Graph çağırmasını gerektirir. Sunucu yalnızca Microsoft Entra kimlik doğrulaması için yapılandırılmışsa veya Graph'a başka bir nedenle erişemiyorsa, deyim Msg 33130 (Principal '<name>' could not be found...) ile başarısız olur. Bunun yerine açık bir SID sağlayarak kullanıcıyı el ile oluşturun:
CREATE USER [<identity-name>] WITH SID = 0x<sid-hex>, TYPE = E;
Yönetilen kimlik veya hizmet sorumlusu için SID'yi nesne kimliğinden değil, kimliğin uygulama (istemci) kimliğinden türetin. Azure SQL hizmet sorumluları ve yönetilen kimlikler için uygulama kimliğini ve yalnızca normal Entra kullanıcıları için nesne kimliğini kullanır. GUID'yi, tireyle ayrılmış ilk üç grubu bayt bayt tersine çevirip son ikisini olduğu gibi bırakarak dönüştürün. Örneğin, uygulama kimliği 00001111-aaaa-2222-bbbb-3333cccc4444 SID 0x11110000AAAA2222BBBB3333CCCC4444olur. PowerShell'de:
$b = ([Guid]"<app-id>").ToByteArray()
"0x" + (($b | ForEach-Object { $_.ToString('X2') }) -join '')
Nesne kimliğini yanlışlıkla kullanırsanız bağlantı bir belirteç almayı başarır, ancak hiçbir veritabanı asıl öğesi belirtecin Login failed for user '<token-identified principal>' talebiyle eşleşmediğinden Azure SQL appid döndürür.
Bir VIEW ANY COLUMN MASTER KEY DEFINITION permission denied hatası görürseniz, Always Encrypted senaryoları için kimliğe ek erişim izni verin:
GRANT VIEW ANY COLUMN MASTER KEY DEFINITION TO [<identity-name>];
GRANT VIEW ANY COLUMN ENCRYPTION KEY DEFINITION TO [<identity-name>];
Yönetilen kimlik kimlik doğrulaması (ActiveDirectoryMsi)
Django uygulamanız Azure App Service, Azure Container Apps veya Azure Sanal Makineler gibi bir Azure hizmetinde çalıştığında yönetilen kimliği kullanın. ODBC sürücüsü belirteçleri otomatik olarak alıp yenilediğinden bu yaklaşım üretim ortamları için önerilir.
Sistem tarafından atanan yönetilen kimlik:
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
"extra_params": "Authentication=ActiveDirectoryMsi",
},
},
}
Kullanıcı tarafından atanan yönetilen kimlik:
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
"extra_params": (
"Authentication=ActiveDirectoryMsi;"
"UID=<managed-identity-client-id-or-object-id>"
),
},
},
}
ActiveDirectoryMsi hem sistem tarafından atanan yönetilen kimlik (SAMI) hem de kullanıcı tarafından atanan yönetilen kimlik (UAMI) için ODBC modudur. UAMI için ODBC sürücüsü, yönetilen kimliği tanımlamak üzere UID bekler: Azure App Service veya Azure Container Instance için istemci kimliğini, aksi takdirde nesne kimliğini kullanın. Bunu UIDiçineextra_params yerleştirin, çünkü extra_params doğrudan ODBC sürücüsüne iletilir.
Yönetilen kimlik kullanıyorsanız, test veritabanını manuel olarak oluşturun ve birim testlerini çalıştırırken --keepdb parametresini iletin.
Hizmet sorumlusu kimlik doğrulaması (ActiveDirectoryServicePrincipal)
Uygulamanız kullanıcı bağlamı olmadan çalışıyorsa ve yönetilen kimlik kullanılamıyorsa Microsoft Entra uygulama kaydını (hizmet sorumlusu) kullanın.
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"USER": "<application-client-id>",
"PASSWORD": "<client-secret>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
"extra_params": "Authentication=ActiveDirectoryServicePrincipal",
},
},
}
İstemci gizli anahtarlarını settings.py içine sabit olarak kodlamayın. Çalışma zamanında kimlik bilgilerini sağlamak için ortam değişkenlerini veya Azure Key Vault gibi bir gizli dizi yöneticisini kullanın.
Tümleşik kimlik doğrulaması (ActiveDirectoryIntegrated)
Django işlemi etki alanına katılmış bir kullanıcı bağlamı altında çalıştığında ve ODBC sürücüsünün Microsoft Entra kimlik doğrulaması için bu Windows veya Kerberos kimliğini kullanmasını istediğinizde tümleşik kimlik doğrulamasını kullanın.
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
"extra_params": "Authentication=ActiveDirectoryIntegrated",
},
},
}
ODBC kimlik doğrulaması başvurusu, bu modu Windows ve federasyon ortamları için ODBC Sürücüsü 17.6 ve üzeri sürümlere sahip Linux veya macOS'ta belgelemektedir.
Etkileşimli kimlik doğrulaması (ActiveDirectoryInteractive)
Sürücünün kimlik bilgilerini istemesini ve çok faktörlü kimlik doğrulamasını işlemesini istediğinizde, yerel kullanıcı oturum açması için etkileşimli kimlik doğrulamasını kullanın.
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"USER": "<user@email.com>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
"extra_params": "Authentication=ActiveDirectoryInteractive",
},
},
}
ODBC kimlik doğrulamasına ilişkin ana başvuru belgeleri, ActiveDirectoryInteractive bunu yalnızca Windows’a özgü olarak belirtir. Bunu başka bir platformda kullanmayı planlıyorsanız, önce tam sürücü sürümünüzle davranışı doğrulayın.
Varsayılan kimlik bilgisi zinciriyle kimlik doğrulama (ActiveDirectoryDefault)
ODBC sürücüsünün varsayılan Microsoft Entra kimlik bilgisi zincirini uygulamasını istediğinizde bu modu kullanın.
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
"extra_params": "Authentication=ActiveDirectoryDefault",
},
},
}
mssql-django 1.7.3 ve sonraki sürümler bu modu ODBC sürücüsüne geçirir. Kimlik bilgisi kaynağı veya belirteç yenileme davranışı üzerinde açık denetime ihtiyacınız varsa erişim belirteci kimlik doğrulamayı kullanın.
Erişim belirteci kimlik doğrulaması (TOKEN)
Python kodunuzun Microsoft Entra belirtecini kendisinin almasını istediğiniz durumlarda TOKEN kullanın.
from azure.identity import DefaultAzureCredential
credential = DefaultAzureCredential()
token = credential.get_token("https://database.windows.net/.default").token
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"TOKEN": token,
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
},
},
}
Bu yol, , DefaultAzureCredentialve ManagedIdentityCredentialdahil olmak üzere ClientSecretCredentialtüm Python kimlik bilgileri sınıfıyla çalışır.
settings.py içinde alınan erişim belirteçleri, işlem başlatıldığında bir kez değerlendirilir ve genellikle 60 ila 90 dakika sonra süreleri dolar. Django işleminiz belirteç ömründen daha uzun süre canlı kalırsa, uygulama kodunda belirteci yenilemeniz gerekir. Uzun süre çalışan üretim uygulamalarının çoğu için, ActiveDirectoryMsi veya ActiveDirectoryServicePrincipal gibi belirteçleri otomatik olarak yenileyen bir ODBC sürücü modu kullanın.
Parola kimlik doğrulaması (ActiveDirectoryPasswordkullanım dışı)
Important
ActiveDirectoryPassword kimlik doğrulama seçeneği (parola kimlik doğrulaması Microsoft Entra ID) Microsoft SQL sürücülerinde kullanım dışıdır. Bu yüksek riskli kimlik doğrulama akışı zorunlu Microsoft Entra çok faktörlü kimlik doğrulaması (MFA) ile uyumsuzdur ve MFA'nın zorlandığı kiracılarda çalışmayabilir. Farklı bir Microsoft Entra kimlik doğrulama yöntemine geçmeyi planlayın.
Microsoft Entra ID parola kimlik doğrulaması, OAuth 2.0 Kaynak Sahibi Parola Kimlik Bilgileri (ROPC) iznini temel alır ve bu da bir uygulamanın parolasını doğrudan işleyerek kullanıcıda oturum açmasına olanak tanır.
Microsoft, MFA ile uyumsuz olduğundan ROPC akışını kullanmamanızı önerir. Çoğu senaryoda daha güvenli alternatifler kullanılabilir ve önerilir. Bu akış, uygulamaya yüksek düzeyde güven gerektirir ve diğer akışlarda mevcut olmayan riskleri taşır. Bu akışı yalnızca daha güvenli akışlar uygun olmadığında kullanın. Microsoft, kullanıcıları kötü amaçlı saldırılardan korumak için bu yüksek riskli kimlik doğrulama akışından uzaklaşıyor. Daha fazla bilgi için bkz. Azure için zorunlu çok faktörlü kimlik doğrulamasını planlama.
Oturum açma sırasında bir kullanıcı mevcutsa, denetim izinin oturum açan kullanıcıya atfedilmesi ve Koşullu Erişim ilkelerinin uygulanması için ActiveDirectoryInteractive veya ActiveDirectoryIntegrated kimlik doğrulamasını kullanın.
Katılımsız hizmetten hizmete senaryoları için Microsoft Entra hizmet hesabı kılavuzunu izleyin:
- Uygulamanız Azure altyapıda çalışıyorsa ActiveDirectoryMSI (veya bazı sürücülerde ActiveDirectoryManagedIdentity) kullanın. Yönetilen kimlikler, gizli anahtarların ve sertifikaların yönetimi ile yenilenmesinden kaynaklanan ek yükü ortadan kaldırır.
- Yönetilen kimlik kullanılamıyorsa (örneğin, uygulama Azure dışında çalışır), ActiveDirectoryServicePrincipal kullanın. Sürücü destekliyorsa, istemci parolası yerine istemci sertifikasını tercih edin. Sertifikayla, özel anahtar istemcide kalır ve istemcinin kimliğini doğrulamak için Microsoft Entra yalnızca imzalı bir onay gönderilir. Anahtar donanımda (TPM veya HSM gibi) depolanıyorsa ya da dışarı aktarılamaz olarak işaretlenmişse, istemci gizli anahtarında olduğu gibi dize olarak dışarı kopyalanamaz.
- hizmet hesabı olarak Microsoft Entra kullanıcı hesabı kullanmayın.
Bunu eski bir senaryo için kullanmanız gerekiyorsa açıkça yapılandırın:
DATABASES = {
"default": {
"ENGINE": "mssql",
"NAME": "<your-database>",
"USER": "<user@email.com>",
"PASSWORD": "<your-password>",
"HOST": "<your-server>.database.windows.net",
"PORT": "1433",
"OPTIONS": {
"driver": "ODBC Driver 18 for SQL Server",
"extra_params": "Authentication=ActiveDirectoryPassword",
},
},
}
İlgili içerik
- mssql-django için en iyi güvenlik uygulamaları
- mssql-django yapılandırma başvurusu
- mssql-django için bağlantı seçenekleri
- Azure App Service SQL Server ile Django uygulaması dağıtma
- ODBC Sürücüsü ile Microsoft Entra Kimliğini Kullanma
- Azure SQL ile Microsoft Entra kimlik doğrulamasını yapılandırma ve yönetme
- Microsoft Entra kimlik doğrulaması wiki'si
- mssql-django ile Always Encrypted