SQL Server a ověřování systému Windows

Stáhnout ADO.NET

Autentizace určuje, která identita se připojuje k SQL Server. Oprávnění databáze určují, co může tato identita dělat po připojení. Vyberte autentizaci pro prostředí, kde vaše aplikace běží, a nakonfigurujte šifrování a validaci certifikátů Transport Layer Security (TLS) nezávisle.

Režim ověřování serveru v SQL Server se liší od přihlašovacích údajů, které váš klient posílá:

  • Windows authentication mode přijímá Windows identity.
  • Smíšený režim přijímá Windows identity a uživatelská jména a hesla pro SQL Server.

Nastavení připojovacího řetězce klienta nezmění ověřovací režim serveru. Pro konfiguraci serveru viz Zvolit autentizační režim.

Scénáře ověřování

Preferujte autentizaci, která nevyžaduje heslo spravované aplikací, pokud to vaše prostředí podporuje.

Aplikační prostředí Volba autentizace
Doménové prostředí s odpovídající identitou Windows. Integrated Security=true. SQL Server může být na jiném počítači v důvěryhodném prostředí.
Aplikace pro Linux nebo macOS využívající nakonfigurovanou doménovou identitu. Integrovaná bezpečnost s požadavky na Kerberos na klientovi i serveru.
Windows lokální vývoj s LocalDB. Integrovaná bezpečnost pod identitou místního vývojáře.
Azure-hostovaná aplikace s podporou Microsoft Entra na SQL endpointu. Spravovaná identita nebo jiný vhodný autentizační režim Microsoft Entra.
Prostředí, které vyžaduje SQL přihlašovací údaje. SQL autentizace s nejmenšími privilegiovanými přihlašovacími údaji získanými z chráněné konfigurace nebo tajného úložiště.

Aplikace orientovaná na internet sama o sobě nevyžaduje SQL autentizaci. Přihlášení uživatele webu a identita databáze aplikace jsou samostatná rozhodnutí.

Připojte se k Windows authentication

Použijte identitu, pod kterou aplikace běží:

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Trusted_Connection=true je synonymem pro Integrated Security=true. S integrovanou bezpečností zapnutou User ID a Password v připojovací řetězec jsou ignorovány. Nevyberou jiného uživatele Windows.

Služba se obvykle připojuje pod identitou služby, nikoli jako uživatel jejího webového rozhraní. Udělte databázová oprávnění určené identitě služby. Pokud potřebujete delegaci identity koncového uživatele mezi počítače, konfigurujte a zkontrolujte delegaci Kerberosu explicitně.

Předpoklady pro platformu

Client Požadavky a chování
.NET Framework na Windows. Používá nativní síť Windows a rozhraní Security Support Provider Interface (SSPI).
Moderní .NET na Windows. Používá nativní síť ve výchozím nastavení. Windows Negotiate při konfiguraci vybírá Kerberos; může se vrátit k NT LAN Manageru (NTLM).
Moderní .NET na Linuxu nebo macOS. Používá spravované sítě a .NETNegotiateAuthentication. Konfigurujte klienta Kerberos, oblast, název hlavní služby (SPN) a platné přihlašovací údaje nebo cache tiketů.

Integrovaná bezpečnost není náhradou za konfiguraci důvěry domén, rozlišení systému doménových jmen (DNS), synchronizace času a SPN SQL Server. Na Linuxu si před spuštěním aplikace zřiďte tiket pomocí nástrojů Kerberos na platformě, například kinit, Nepředpokládejte, že záložní varianta Windows NTLM je dostupná i na klientovi mimo Windows. Viz Registrovat SPN pro připojení ke Kerberos.

Pro kontrolu autentizačního schématu vašeho aktuálního SQL Server připojení spusť tento dotaz Transact-SQL (T-SQL):

SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Přístup k tomuto diagnostickému zobrazení závisí na oprávněních serveru. Úspěšné spojení samo o sobě nedokazuje, že byl použit Kerberos, nikoli NTLM.

Pro aplikace, které musí řídit vyjednávání o bezpečnostním kontextu, podporuje SspiContextProvider vlastní implementaci SSPI. Jedná se o pokročilý bod rozšiřitelnosti pro scénáře jako vlastní Kerberos nebo explicitní NTLM přihlašovací údaje. Není to režim autentizace pomocí spojovacího řetězce a nelze jej kombinovat s AccessToken nebo AccessTokenCallback.

Vlastní poskytovatelé kontextu rozhraní Security Support Provider Interface (SSPI)

Abstraktní SspiContextProvider třída je základem pro všechny poskytovatele SSPI kontextu. Pro vytvoření vlastního poskytovatele odvozte z SspiContextProvider a přepište metodu GenerateContext. Před otevřením připojení přiřaďte instanci svého poskytovatele k vlastnosti SspiContextProvider na SqlConnection.

Metoda GenerateContext je vyvolána během SSPI autentizačního handshake. Přijímá příchozí autentizační blob ze serveru, zapisovač bufferu pro odchozí odpověď blob a SspiAuthenticationParameters objekt obsahující metadata spojení, jako například:

  • Resource - Service Principal Name (SPN) serveru.
  • ServerName - Název zdroje dat.
  • DatabaseName - Cílová databáze, pokud je uvedena.
  • UserId – Uživatelské ID, pokud je uvedeno v připojovacím řetězci.
  • Password- Heslo, pokud je uvedeno v připojovací řetězec.

Důležité aspekty:

  • Nastavte vlastnost SspiContextProvider před otevřením připojení. Pokus o nastavení u otevřeného nebo připojovaného připojení vyvolá InvalidOperationException výjimku.
  • Instance SspiContextProvider je součástí klíče používaného k identifikaci spojovacích poolů. Vyhněte se vytváření nové SspiContextProvider instance pro každou SqlConnection instanci, protože každý nový poskytovatel vytváří nový pool. Používejte stejnou instanci poskytovatele pro připojení, která mají být zahrnuta do poolingu.
  • Vlastní SspiContextProvider musí být autentizováno se stejným bezpečnostním kontextem pro stejné vstupní parametry. Pokud je bezpečnostní kontext odlišný, může být pro požadavek na spojení vráceno spojení spojené s nesprávným bezpečnostním kontextem.
  • SspiContextProvider je vzájemně vylučující s autentizací založenou na tokenech. Nastavení spolu s AccessToken nebo AccessTokenCallback vyvolá InvalidOperationException, bez ohledu na to, kterou vlastnost nastavíte jako první.

Example

NegotiateAuthenticationvyžaduje .NET 7 nebo novější, takže tento příklad se v .NET Frameworku nekompiluje. Pro poskytovatele .NET Frameworku místo toho implementujte GenerateContext pomocí rozhraní SSPI API platformy.

Následující příklad ukazuje vlastního poskytovatele SSPI kontextu, který používá NegotiateAuthentication k provedení autentizace:

using System;
using System.Buffers;
using System.Net.Security;
using Microsoft.Data.SqlClient;

class CustomSspiContextProvider : SspiContextProvider
{
    private NegotiateAuthentication? _auth;

    protected override bool GenerateContext(
        ReadOnlySpan<byte> incomingBlob,
        IBufferWriter<byte> outgoingBlobWriter,
        SspiAuthenticationParameters authParams)
    {
        _auth ??= new NegotiateAuthentication(
            new NegotiateAuthenticationClientOptions
            {
                Package = "Negotiate",
                TargetName = authParams.Resource,
            });

        byte[]? blob = _auth.GetOutgoingBlob(
            incomingBlob, out NegotiateAuthenticationStatusCode statusCode);

        if (statusCode is not NegotiateAuthenticationStatusCode.Completed
            and not NegotiateAuthenticationStatusCode.ContinueNeeded)
        {
            return false;
        }

        if (blob is not null)
        {
            outgoingBlobWriter.Write(blob);
        }

        return true;
    }
}

Přiřaďte poskytovatele k připojení před jeho otevřením:

using var connection = new SqlConnection(
    "Server=myServer;Database=myDatabase;Integrated Security=true;Encrypt=True;");
connection.SspiContextProvider = new CustomSspiContextProvider();
connection.Open();

Bezpečnostní aspekty

Při implementaci vlastního poskytovatele SSPI kontextu mějte na paměti následující bezpečnostní aspekty:

  • Ověřte všechny vstupy. Vždy ověřujte příchozí blobs a autentizační parametry před jejich zpracováním. Nesprávně zformovaná nebo neočekávaná data by měla být odmítnuta návratem false z GenerateContext.
  • Chraňte přihlašovací údaje. Objekt SspiAuthenticationParameters může obsahovat citlivé hodnoty, jako jsou UserId a Password. Nezaznamenávejte, trvale neukládejte ani nepřenášejte tyto hodnoty nezabezpečeným způsobem.
  • Používejte zavedené autentizační knihovny. Kdykoli je to možné, delegujte autentizační logiku na dobře ověřené knihovny, například NegotiateAuthentication místo toho, abyste sami implementovali kryptografické protokoly.
  • Uvolněte prostředky. Pokud váš poskytovatel přiděluje nespravované zdroje nebo autentizační kontexty, zaveďte IDisposable, a zajistěte správné čištění. SqlClient instanci SspiContextProvider neuvolní. Zrušte provider, když ho vaše aplikace již nepotřebuje.
  • Omezte ověřovací balíček. Používejte pouze autentizační balíčky vhodné pro vaše prostředí (například Negotiate nebo Kerberos). Předávejte autentizačnímu balíčku pouze důvěryhodné vstupy a konfiguraci.
  • Důkladně otestujte. Ověřte, že váš poskytovatel funguje správně za všech očekávaných podmínek, včetně obnovy tokenů, poolování připojení a scénářů failoveru.

Microsoft neověřuje ani neaudituje vlastní implementace SspiContextProvider ani nezaručuje bezpečnost připojení autentizovaných prostřednictvím vlastního poskytovatele. Za jakékoli zranitelnosti zavedené vlastní implementací zodpovídáte vy.

Typy přihlášení

Přihlášení umožňuje přístup k identitě na server. Uživatel databáze reprezentuje identitu uvnitř databáze. Přiřaďte příslušné přihlášení nebo skupinu k uživateli databáze a poté udělte pouze požadovaná oprávnění prostřednictvím databázových rolí.

SQL Server podporuje přihlášení do Windows účtu, skupinové přihlášení do Windows a přihlášení do SQL. Skupina pro Windows umožňuje administrátorům spravovat členství bez nutnosti vytvářet samostatné přihlašovací číslo pro SQL Server pro každou osobu. Přihlášení pomocí certifikátu a asymetrického klíče používaných k podepisování kódu nejsou identitami interaktivního připojení.

Uživatelé uzavřené databáze a principálové Microsoft Entra mají odlišné požadavky na provisioning. Podívejte se na Principals a autentizační dokumentaci koncového zařízení, místo abyste předpokládali, že každý uživatel potřebuje SQL přihlášení.

Ověřování ve smíšeném režimu

Používejte SQL autentizaci pouze na endpointu nakonfigurovaném tak, aby ho přijímal. Zadejte User ID a Password, zakažte integrované zabezpečení a ponechte ověřování certifikátů zapnuté. Authentication=Sql Passwordvýslovně vybírá autentizaci pomocí SQL hesla; nevybírá Microsoft Entra password authentication.

Následující příklad .NET konzole používá Microsoft.Data.SqlClient. Nastavte SQL_SERVER, SQL_DATABASE, SQL_USER_ID a SQL_PASSWORD prostřednictvím vašeho vývojového prostředí nebo mechanismu pro vkládání tajných klíčů. SQL_SERVER by měl obsahovat koncový bod protokolu Transmission Control Protocol (TCP), například tcp:sql-server.contoso.com,1433. Netiskněte heslo ani kompletní připojovací řetězec.

using Microsoft.Data.SqlClient;

static string Required(string name) =>
    Environment.GetEnvironmentVariable(name)
    ?? throw new InvalidOperationException($"Set {name} before running.");

var options = new SqlConnectionStringBuilder
{
    DataSource = Required("SQL_SERVER"),
    InitialCatalog = Required("SQL_DATABASE"),
    Authentication = SqlAuthenticationMethod.SqlPassword,
    UserID = Required("SQL_USER_ID"),
    Password = Required("SQL_PASSWORD"),
    Encrypt = SqlConnectionEncryptOption.Mandatory,
    TrustServerCertificate = false,
    MultiSubnetFailover = true
};

using var connection = new SqlConnection(options.ConnectionString);
await connection.OpenAsync();
using var command = new SqlCommand("SELECT DB_NAME();", connection);
Console.WriteLine(await command.ExecuteScalarAsync());

Dotaz vytiskne název propojené databáze. Použijte SqlConnectionStringBuilder místo spojování přihlašovacích údajů do řetězce. Builder uniká hodnotám řetězce spojení; nerozhoduje, který server, databázi nebo oprávnění by vaše aplikace měla povolit.

Nechte Persist Security Info=false, je výchozí. Výrobní tajemství ukládejte do chráněného tajného úložiště, omezte, kdo je může číst, a střídejte je. Nepoužívejte identitu správce nebo vlastníka databáze pro rutinní žádosti o aplikace.

Microsoft Entra a omezení služeb

Integrated Security=trueautentizuje identitu Windows do SQL Server. Authentication=služba Active Directory Integrated získává token Microsoft Entra. Tyto pojmy nejsou zaměnitelné.

Azure SQL Database používá autentizaci SQL nebo Microsoft Entra místo běžné integrované autentizace ve Windows. SQL databáze v Microsoft Fabric podporuje pouze identity Microsoft Entra; SQL autentizace a přihlášení nejsou podporovány. Použijte článek Microsoft Entra pro propojení založená na tokenech.

Související obsah

  • Poslední aktualizace v