Ověřování Microsoft Entra pomocí mssql-django

Tento článek vysvětluje, jak nakonfigurovat ověřování Microsoft Entra pro aplikace Django pomocí back-endumssql-django. Ověřování Microsoft Entra eliminuje nutnost ukládat hesla v konfiguraci vaší aplikace.

Předpoklady

  • Microsoft ovladač ODBC 18 pro SQL Server (doporučeno). Všechny režimy ověřování v tomto článku jsou podporovány Microsoft ovladače ODBC 18 pro SQL Server. ActiveDirectoryInteractive je pouze pro Windows bez ohledu na verzi ovladače. Pokud musíte použít ovladač ODBC 17, viz referenční dokumentaci k ověřování ODBC, kde najdete minimální verze 17.x pro jednotlivé režimy.
  • Pro ověřování přístupového tokenu: pip install azure-identity.

Metody ověřování

Nakonfigurujte každou metodu přidáním nebo úpravou DATABASES nastavení v souboru projektu settings.py Django. Příklady v tomto článku ukazují úplný DATABASES["default"] blok pro přehlednost; zkopírujte příslušné klíče do stávající konfigurace.

mssql-djangopodporuje ověřování Microsoft Entra dvěma způsoby:

  • Ověřování ovladače ODBC prostřednictvím OPTIONS["extra_params"]. Back-end připojí tento řetězec k připojovací řetězec ODBC beze změny, takže dostupné Authentication= hodnoty pocházejí z nainstalovaného Microsoft ovladače ODBC pro SQL Server, nikoli ze mssql-django samotného.
  • Ověřování tokenu pro programový přístup pomocí nastavení TOKEN Backend předá ovladači ODBC TOKEN jako SQL_COPT_SS_ACCESS_TOKEN, čímž obejde klíčové slovo Authentication= v ODBC.

Metody ověřování na první pohled

Metoda Konfigurovat pomocí Nejlepší pro
Token přístupu TOKEN Vývoj, krátkodobé skripty nebo aplikace s vlastní aktualizací tokenu
ActiveDirectoryMsi extra_params Produkční aplikace hostované v Azure (spravovaná identita přiřazená systémem a uživatelem přiřazená spravovaná identita)
ActiveDirectoryServicePrincipal USER, PASSWORD, extra_params Registrace aplikací, když není k dispozici spravovaná identita
ActiveDirectoryIntegrated extra_params Kontext uživatele připojený k doméně
ActiveDirectoryInteractive USER, extra_params Přihlášení uživatele s vícefaktorovým ověřováním (Windows)
ActiveDirectoryDefault extra_params Místní vývoj a aplikace, které by měly používat výchozí řetězec přihlašovacích údajů ovladače ODBC Microsoft Entra
ActiveDirectoryPassword USER, PASSWORD, extra_params Pouze starší scénáře posledního řešení (zastaralé)

Note

mssql-django Verze 1.7.3 a novější podporují Authentication=ActiveDirectoryDefault až OPTIONS["extra_params"], pokud nainstalovaný ovladač Microsoft ODBC Driver for SQL Server tento režim podporuje. Pokud potřebujete explicitní kontrolu nad získáním tokenu a chováním aktualizace, použijte vzor TOKEN se azure.identity.DefaultAzureCredential třídou.

Udělení přístupu k identitě v Azure SQL

Pro ověřování pomocí spravované identity nebo instančního objektu služby vytvořte databázového uživatele a udělte pouze role, které vaše aplikace potřebuje:

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 pevná role databáze se vyžaduje jenom v případě, že aplikace spouští migrace. Pro úlohy jen pro čtení stačí db_datareader.

Note

FROM EXTERNAL PROVIDERvyžaduje, aby sql server volal Microsoft Graph k překladu hlavního názvu. Pokud je server nakonfigurovaný pro ověřování pouze Microsoft Entra nebo se jinak nemůže spojit s Graphem, příkaz selže s Msg 33130 (Principal '<name>' could not be found...). Místo toho vytvořte uživatele ručně zadáním explicitního identifikátoru SID:

CREATE USER [<identity-name>] WITH SID = 0x<sid-hex>, TYPE = E;

U spravované identity nebo instančního objektu služby odvoďte identifikátor SID z ID aplikace (klienta) identity, nikoli z jejího ID objektu. Azure SQL používá ID aplikace pro instanční objekty a spravované identity a ID objektu pouze pro běžné uživatele Entra. Převeďte identifikátor GUID tak, že obrátíte pořadí bajtů v prvních třech skupinách oddělených pomlčkami a poslední dvě ponecháte beze změny. Například ID aplikace 00001111-aaaa-2222-bbbb-3333cccc4444 se změní na SID 0x11110000AAAA2222BBBB3333CCCC4444. V prostředí PowerShell:

$b = ([Guid]"<app-id>").ToByteArray()
"0x" + (($b | ForEach-Object { $_.ToString('X2') }) -join '')

Pokud omylem použijete ID objektu, připojení sice úspěšně získá token, ale Azure SQL vrátí Login failed for user '<token-identified principal>', protože žádný objekt zabezpečení databáze neodpovídá deklaraci appid tokenu.

Pokud se zobrazí chyba VIEW ANY COLUMN MASTER KEY DEFINITION permission denied, udělte identitě dodatečný přístup pro scénáře Always Encrypted:

GRANT VIEW ANY COLUMN MASTER KEY DEFINITION TO [<identity-name>];
GRANT VIEW ANY COLUMN ENCRYPTION KEY DEFINITION TO [<identity-name>];

Ověřování pomocí spravované identity (ActiveDirectoryMsi)

Spravovanou identitu použijte, když aplikace Django běží ve službě Azure, jako je Azure App Service, Azure Container Apps nebo Azure Virtual Machines. Tento přístup se doporučuje pro produkční prostředí, protože ovladač ODBC získává a aktualizuje tokeny automaticky.

Spravovaná identita přiřazená systémem:

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",
        },
    },
}

Spravovaná identita přiřazená uživatelem:

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 je režim ODBC pro spravovanou identitu přiřazenou systémem (SAMI) i spravovanou identitu přiřazenou uživatelem (UAMI). Pro UAMI ovladač ODBC očekává UID k identifikaci spravované identity: pro Azure App Service nebo Azure Container Instance použijte ID klienta, jinak použijte ID objektu. Vložte to UID do extra_params, protože extra_params se předává přímo ovladači ODBC.

Pokud používáte spravovanou identitu, vytvořte testovací databázi ručně a při spuštění jednotkových testů předejte --keepdb.

Ověřování pomocí service principal (ActiveDirectoryServicePrincipal)

Pokud vaše aplikace běží bez kontextu uživatele a spravovaná identita není k dispozici, použijte registraci aplikace Microsoft Entra (objekt služby).

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",
        },
    },
}

Nezakódujte tajné kódy klienta v settings.pysouboru . K poskytnutí přihlašovacích údajů za běhu použijte proměnné prostředí nebo správce tajných údajů, například Azure Key Vault.

Integrované ověřování (ActiveDirectoryIntegrated)

Integrované ověřování použijte, když proces Django běží v kontextu uživatele připojeného k doméně a chcete, aby ovladač ODBC použil tuto identitu systému Windows nebo protokolu Kerberos k ověřování Microsoft Entra.

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",
        },
    },
}

Referenční informace k ověřování ODBC dokumentují tento režim na Windows a v Linuxu nebo macOS s ovladačem ODBC 17.6 a novějšími verzemi pro federovaná prostředí.

Interaktivní ověřování (ActiveDirectoryInteractive)

Interaktivní ověřování použijte pro přihlášení místního uživatele, pokud chcete, aby ovladač zobrazil výzvu k zadání přihlašovacích údajů a zpracovával vícefaktorové ověřová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",
        },
    },
}

Hlavní referenční dokumenty k ověřování ODBC označují ActiveDirectoryInteractive jako určené pouze pro Windows. Pokud ho plánujete používat na jiné platformě, nejprve ověřte chování s vaší přesnou verzí ovladače.

Ověřování pomocí výchozího řetězce přihlašovacích údajů (ActiveDirectoryDefault)

Tento režim použijte, pokud chcete, aby ovladač ODBC použil výchozí Microsoft Entra řetěz přihlašovacích údajů.

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 a novější verze předávají tento režim ovladači ODBC. Pokud potřebujete explicitní kontrolu nad chováním zdroje přihlašovacích údajů nebo aktualizace tokenu, použijte ověřování přístupového tokenu.

Ověřování přístupového tokenu (TOKEN)

PoužijteTOKEN, když chcete, aby kód Python získal samotný token Microsoft Entra.

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",
        },
    },
}

Tato cesta funguje s libovolnou Python třídou přihlašovacích údajů, včetně DefaultAzureCredential, ManagedIdentityCredentiala ClientSecretCredential.

Při spuštění procesu se vyhodnocují přístupové tokeny načtené settings.py jednou a obvykle vyprší po 60 až 90 minutách. Pokud váš proces Django zůstane naživu déle než životnost tokenu, musíte token aktualizovat v kódu aplikace. U většiny dlouhotrvajících produkčních aplikací použijte režim ovladače ODBC, který automaticky aktualizuje tokeny, například ActiveDirectoryMsi .ActiveDirectoryServicePrincipal

Ověřování heslem (ActiveDirectoryPasswordzastaralé)

Important

Možnost ověřování ActiveDirectoryPassword (ověřování hesla Microsoft Entra ID) je v ovladačích MICROSOFT SQL zastaralá. Tento tok ověřování s vysokým rizikem není kompatibilní s povinným Microsoft Entra vícefaktorovým ověřováním (MFA) a nemusí fungovat v tenantech, ve kterých se vynucuje vícefaktorové ověřování. Naplánujte migraci na jinou metodu ověřování Microsoft Entra.

Ověřování heslem v Microsoft Entra ID je založeno na grantu OAuth 2.0 Resource Owner Password Credentials (ROPC), který umožňuje aplikaci přihlásit uživatele tím, že přímo pracuje s jeho heslem.

Microsoft doporučuje nepoužívat tok ROPC, protože není kompatibilní s vícefaktorovým ověřováním. Ve většině scénářů jsou k dispozici a doporučeny bezpečnější alternativy. Tento tok vyžaduje vysokou míru důvěryhodnosti v aplikaci a nese rizika, která nejsou přítomna v jiných tocích. Tento tok používejte pouze tehdy, pokud bezpečnější toky nejsou proveditelné. Microsoft odchází od tohoto vysoce rizikového toku ověřování, aby chránil uživatele před škodlivými útoky. Další informace najdete v tématu Plánování povinného vícefaktorového ověřování pro Azure.

Pokud je při přihlašování přítomen uživatel, použijte ověřování ActiveDirectoryInteractive nebo ActiveDirectoryIntegrated, aby byla auditní stopa přiřazena přihlášenému uživateli a aby se uplatnily zásady podmíněného přístupu.

V případě bezobslužných scénářů mezi službami postupujte podle pokynů k účtu služby Microsoft Entra:

  • Pokud vaše aplikace běží na Azure infrastruktuře, použijte ActiveDirectoryMSI (nebo ActiveDirectoryManagedIdentity v některých ovladačích). Spravované identity eliminují režii při údržbě a obměně tajných kódů a certifikátů.
  • Pokud spravovaná identita není dostupná (například aplikace běží mimo Azure), použijte ActiveDirectoryServicePrincipal. Pokud ho ovladač podporuje, upřednostňujte klientský certifikát před tajným klíčem klienta. S certifikátem zůstane privátní klíč v klientovi a do Microsoft Entra k ověření klienta se odešle jenom podepsaný kontrolní výraz. Pokud je klíč uložen v hardwaru (například v modulu TPM nebo HSM) nebo je označen jako neexportovatelný, nelze jej zkopírovat jako textový řetězec tak, jako to lze u tajného klíče klienta.
  • Nepoužívejte Microsoft Entra uživatelský účet jako účet služby.

Pokud ho musíte použít pro starší scénář, nakonfigurujte ho explicitně:

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",
        },
    },
}

Související obsah

  • Last updated on