autenticação do SQL Server e do Windows

Baixar ADO.NET

A autenticação determina qual identidade se conecta ao SQL Server. Permissões de banco de dados determinam o que essa identidade pode fazer após a conexão. Escolha a autenticação para o ambiente onde sua aplicação é executada e configure a criptografia e validação de certificados do Transport Layer Security (TLS ) de forma independente.

O modo de autenticação do SQL Server é distinto das credenciais que seu cliente envia:

O modo autenticação do Windows aceita identidades do Windows.
O modo misto aceita identidades do Windows e nomes de usuário e senhas do SQL Server.

Definir uma cadeia de conexão de cliente não altera o modo de autenticação do servidor. Para configuração do servidor, veja Escolher um modo de autenticação.

Cenários de autenticação

Prefira autenticação que não exija uma senha gerenciada pelo aplicativo quando seu ambiente permite.

Ambiente de aplicativo	Escolha de autenticação
Ambiente de domínio com uma identidade Windows apropriada.	`Integrated Security=true`. O SQL Server pode estar em outro computador dentro do ambiente confiável.
Aplicação Linux ou macOS usando uma identidade de domínio configurada.	Segurança integrada com pré-requisitos Kerberos no cliente e servidor.
Desenvolvimento local no Windows com LocalDB.	Segurança integrada sob a identidade do desenvolvedor local.
Aplicação hospedada no Azure com suporte ao Microsoft Entra no endpoint SQL.	Identidade gerenciada ou outro modo adequado de autenticação Microsoft Entra.
Ambiente que exige credenciais SQL.	Autenticação SQL com credenciais de menor privilégio recuperada de configuração protegida ou de um armazenamento secreto.

Uma aplicação voltada para a internet não exige necessariamente autenticação SQL. O login do usuário da web e a identidade do banco de dados da aplicação são decisões separadas.

Conectar com autenticação do Windows

Use a identidade sob a qual a aplicação roda:

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

Trusted_Connection=true é sinônimo de Integrated Security=true. Com a segurança integrada ativada, User ID e Password na cadeia de conexão são ignorados. Eles não selecionam outro usuário do Windows.

Um serviço normalmente se conecta como sua identidade de serviço, não como a pessoa que usa sua interface web. Conceda permissões de banco de dados para a identidade de serviço pretendida. Se precisar delegar a identidade de um usuário final entre computadores, configure e analise explicitamente a delegação Kerberos.

Pré-requisitos para plataforma

Client	Requisitos e comportamento
.NET Framework no Windows.	Utiliza rede nativa do Windows e a Interface de Suporte de Segurança (SSPI).
.NET moderno no Windows.	Usa rede nativa por padrão. O Windows Negotiate seleciona Kerberos quando configurado; ele pode recorrer ao NT LAN Manager (NTLM).
.NET moderno no Linux ou macOS.	Utiliza redes gerenciadas e .NET`NegotiateAuthentication`. Configure o cliente Kerberos, o realm, o nome do principal de serviço (SPN) e credenciais válidas ou cache de tickets.

A segurança integrada não substitui a configuração das relações de confiança de domínio, da resolução do Sistema de Nomes de Domínio (DNS), da sincronização de hora e do SPN do SQL Server. No Linux, obtenha um ticket com as ferramentas Kerberos da plataforma, como kinit, antes de iniciar o aplicativo. Não presuma que uma alternativa NTLM do Windows esteja disponível em um cliente não Windows. Veja Registrar um SPN para conexões Kerberos.

Para inspecionar o esquema de autenticação da sua conexão SQL Server atual, execute esta consulta Transact-SQL (T-SQL):

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

O acesso a essa visualização de diagnóstico depende das permissões do servidor. Uma conexão bem-sucedida sozinha não prova que Kerberos, e não NTLM, tenha sido usado.

Para aplicações que precisam controlar a negociação de contexto de segurança, SspiContextProvider suporta uma implementação SSPI personalizada. Este é um ponto avançado de extensibilidade para cenários como Kerberos personalizado ou credenciais explícitas NTLM. Não é um modo de autenticação por strings de conexão e não pode ser combinado com AccessToken ou AccessTokenCallback.

Provedores de contexto personalizados da SSPI (Interface do Provedor de Suporte de Segurança)

A SspiContextProvider classe abstrata é a base para todos os provedores de contexto SSPI. Para criar um provedor personalizado, derive de SspiContextProvider e sobrescreva o método GenerateContext. Atribua uma instância do seu provedor à propriedade SspiContextProvider em um SqlConnection antes de abrir a conexão.

O GenerateContext método é chamado durante o handshake de autenticação SSPI. Ele recebe o blob de autenticação de entrada do servidor, um gravador de buffer para o blob de resposta de saída e um objeto SspiAuthenticationParameters contendo metadados de conexão, tais como:

Resource - O Nome Principal do Serviço (SPN) do servidor.
ServerName - O nome da fonte de dados.
DatabaseName - O banco de dados alvo, se especificado.
UserId- O ID do usuário, se especificado na cadeia de conexão.
Password- A senha, se especificada na cadeia de conexão.

Considerações importantes:

Defina a SspiContextProvider propriedade antes de abrir a conexão. Tentar configurá-lo em uma conexão aberta ou em processo de conexão gera um InvalidOperationException.
A instância SspiContextProvider faz parte da chave usada para identificar pools de conexão. Evite criar uma nova SspiContextProvider instância para cada SqlConnection uma, já que cada novo provedor cria um novo pool. Use a mesma instância de um provedor para conexões que você quer que sejam consideradas para pooling.
Um SspiContextProvider personalizado deve autenticar com o mesmo contexto de segurança para os mesmos parâmetros de entrada. Se o contexto de segurança for diferente, uma conexão agrupada com o contexto de segurança errado pode ser retornada para uma solicitação de conexão.
SspiContextProvider é mutuamente exclusivo com autenticação baseada em tokens. Colocando-o ao lado de AccessToken ou AccessTokenCallback gera um InvalidOperationException, independentemente de qual propriedade você definir primeiro.

Example

NegotiateAuthenticationrequer .NET 7 ou posterior, então este exemplo não compila no .NET Framework. Para um provedor do .NET Framework, implemente GenerateContext com base em uma API da SSPI da plataforma.

O exemplo a seguir mostra um provedor de contexto SSPI personalizado que usa NegotiateAuthentication para realizar a autenticação:

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

Atribua o provedor a uma conexão antes de abri-la:

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

Considerações de segurança

Tenha em mente as seguintes considerações de segurança ao implementar um provedor de contexto SSPI personalizado:

Valide todas as entradas. Sempre valide os blobs recebidos e os parâmetros de autenticação antes de processá-los. Dados malformados ou inesperados devem ser rejeitados retornando false de GenerateContext.
Proteja as credenciais. O SspiAuthenticationParameters objeto pode conter valores sensíveis como UserId e Password. Não registre, persista ou transmita esses valores de forma não segura.
Use bibliotecas de autenticação estabelecidas. Sempre que possível, delegue a lógica de autenticação para bibliotecas bem testadas, como NegotiateAuthentication em vez de implementar protocolos criptográficos você mesmo.
Descarte recursos. Se seu provedor aloca recursos não gerenciados ou contextos de autenticação, implemente IDisposable, e garanta a limpeza adequada. O SqlClient não descarta a SspiContextProvider instância. Descarte o provedor quando sua aplicação não precisar mais dele.
Restrinja o pacote de autenticação. Use apenas pacotes de autenticação apropriados para seu ambiente (por exemplo, Negotiate ou Kerberos). Apenas passe entrada confiável e configuração para o pacote de autenticação.
Teste minuciosamente. Verifique se seu provedor funciona corretamente em todas as condições esperadas, incluindo renovação de tokens, pooling de conexão e cenários de failover.

A Microsoft não valida nem audita implementações personalizadasSspiContextProvider, nem garante a segurança das conexões autenticadas por meio de um provedor personalizado. Quaisquer vulnerabilidades introduzidas por uma implementação personalizada são da sua responsabilidade.

Um login permite que uma identidade acesse o servidor. Um usuário de banco de dados representa uma identidade dentro de um banco de dados. Mapeie o login ou grupo pretendido para um usuário do banco de dados e conceda apenas as permissões necessárias por meio de funções de banco de dados.

O SQL Server suporta logins de contas do Windows, logins de grupos do Windows e logins SQL. Um grupo do Windows permite que administradores gerenciem a membresia sem precisar criar um login separado no SQL Server para cada pessoa. Logins de certificados e chaves assimétricas usados para assinatura de código não são identidades de conexão interativas.

Usuários de banco de dados contidos e principais responsáveis da Microsoft Entra têm requisitos de provisionamento diferentes. Veja Principals e a documentação de autenticação do endpoint, em vez de presumir que todos os usuários precisam de login SQL.

Autenticação de modo misto

Use autenticação SQL apenas em um endpoint configurado para aceitá-la. Forneça User ID e Password, desative a segurança integrada e mantenha a validação do certificado ativada. Authentication=Sql Passwordseleciona explicitamente autenticação por senha SQL; não seleciona autenticação por senha Microsoft Entra.

O exemplo a seguir do console .NET usa Microsoft.Data.SqlClient. Defina SQL_SERVER, SQL_DATABASE, SQL_USER_ID, e SQL_PASSWORD através do seu ambiente de desenvolvimento ou mecanismo de injeção secreta. SQL_SERVER deve conter um endpoint do Protocolo de Controle de Transmissão (TCP), como tcp:sql-server.contoso.com,1433. Não imprima a senha nem a cadeia de conexão completa.

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

A consulta imprime o nome do banco de dados conectado. Use o SqlConnectionStringBuilder em vez de concatenar credenciais em uma string. O construtor faz o escape de valores da cadeia de conexão; ele não decide o servidor, o banco de dados ou as permissões que seu aplicativo deve permitir.

Mantenha Persist Security Info=false, é o padrão. Armazene segredos de produção em um cofre de segredos protegido, restrinja quem pode lê-los e rotacione-os. Não use uma identidade de administrador ou dono de banco de dados para solicitações rotineiras de aplicação.

Microsoft Entra e limitações de serviço

Integrated Security=trueautentica uma identidade do Windows no SQL Server. Authentication=Active Directory Integrated obtém um token do Microsoft Entra. Esses não são intercambiáveis.

Banco de Dados SQL do Azure utiliza autenticação SQL ou Microsoft Entra em vez da autenticação integrada comum do Windows. O banco de dados SQL no Microsoft Fabric suporta apenas identidades Microsoft Entra; Autenticação SQL e logins não são suportados. Use o artigo da Microsoft Entra para conexões baseadas em tokens.

Comentários

Esta página foi útil?

Última atualização em 2026-10-08