SQL Server e autenticação do Windows

Baixar ADO.NET

A autenticação estabelece qual a identidade que se liga ao SQL Server. As permissões da base de dados determinam o que essa identidade pode fazer após a ligação. Escolha a autenticação para o ambiente onde a sua aplicação é executada e configure a encriptação da Segurança da Camada de Transporte (TLS) e a validação de certificados de forma independente.

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

• O modo de autenticação do Windows aceita identidades Windows.
• O modo misto aceita identidades do Windows e nomes de utilizador e palavras-passe do SQL Server.

Definir uma cadeia de ligação ao cliente não altera o modo de autenticação do servidor. Para a configuração do servidor, consulte Escolher um modo de autenticação.

Cenários de autenticação

Prefira autenticação que não exija uma palavra-passe gerida pela aplicação quando o seu ambiente a suporta.

Uma aplicação orientada para a internet não requer necessariamente autenticação SQL. A autenticação do utilizador da Web e a identidade da base de dados da aplicação são decisões separadas.

Ligue-se ao Windows authentication

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

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 ligação são ignorados. Eles não selecionam um utilizador diferente do Windows.

Um serviço normalmente estabelece ligação com a sua identidade de serviço, não com a pessoa que utiliza a sua interface Web. Conceder permissões de base de dados à identidade de serviço pretendida. Se necessitar da delegação da identidade de um utilizador final entre diferentes computadores, configure e reveja explicitamente a delegação do Kerberos.

Pré-requisitos da plataforma

A segurança integrada não substitui a configuração das relações de confiança entre domínios, da resolução de nomes no Sistema de Nomes de Domínio (DNS), da sincronização horária e do SPN do SQL Server. No Linux, obtenha um ticket com as ferramentas Kerberos da plataforma, como kinit, antes de iniciar a aplicação. Não presuma que existe uma alternativa NTLM do Windows num cliente não Windows. Veja Registar um SPN para ligações Kerberos.

Para inspecionar o esquema de autenticação da sua ligaçã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 esta vista de diagnóstico depende das permissões do servidor. Uma ligação bem-sucedida por si só não prova que Kerberos, e não NTLM, tenha sido usado.

Para aplicações que devem 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 personalizados ou credenciais NTLM explícitas. Não é um modo de autenticação por string de ligação e não pode ser combinado com AccessToken ou AccessTokenCallback.

Provedores de contexto da Interface de Suporte de Segurança Personalizada (SSPI)

A SspiContextProvider classe abstract é a base para todos os fornecedores de contexto SSPI. Para criar um provedor personalizado, derive de SspiContextProvider e sobreponha o método GenerateContext. Atribua uma instância do seu fornecedor à propriedade SspiContextProvider de um SqlConnection antes de abrir a ligação.

O GenerateContext método é chamado durante o handshake de autenticação SSPI. 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 ligação tais como:

• Resource - O Nome Principal do Serviço (SPN) do servidor.
• ServerName - O nome da fonte de dados.
• DatabaseName - A base de dados alvo, se especificada.
• UserId - O ID do utilizador, se especificado na cadeia de ligação.
• Password - A palavra-passe, se especificada na cadeia de ligação.

Considerações importantes:

• Defina a SspiContextProvider propriedade antes de abrir a ligação. Ao tentar colocá-lo numa ligação aberta ou em estabelecimento, aparece um InvalidOperationException.
• A instância SspiContextProvider faz parte da chave usada para identificar pools de ligação. Evite criar uma nova instância de SspiContextProvider para cada SqlConnection, pois cada novo provider cria um novo pool. Refira-se à mesma instância de um provedor para as conexões 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 ligação em pool com o contexto de segurança errado pode ser devolvida para um pedido de ligação.
• SspiContextProvider é mutuamente exclusivo com a autenticação baseada em tokens. Colocá-lo juntamente com AccessToken ou AccessTokenCallback lança um InvalidOperationException, independentemente da propriedade que definir primeiro.

Example

NegotiateAuthenticationrequer .NET 7 ou posterior, por isso este exemplo não compila no .NET Framework. Para um fornecedor de Framework .NET, implemente GenerateContext numa API SSPI da plataforma.

O exemplo seguinte mostra um fornecedor de contexto SSPI personalizado que utiliza 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 provider a uma conexão antes de a abrir:

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 fornecedor de contexto SSPI personalizado:

• Valida todos os campos. Valide sempre os blobs recebidos e os parâmetros de autenticação antes de os processar. Dados malformados ou inesperados devem ser rejeitados devolvendo false a partir de GenerateContext.
• Proteja as credenciais. O SspiAuthenticationParameters objeto pode conter valores sensíveis como UserId e Password. Não registe, persista nem transmita estes valores de forma não segura.
• Use bibliotecas de autenticação estabelecidas. Sempre que possível, delegue a lógica de autenticação a bibliotecas bem testadas, tais como NegotiateAuthentication, em vez de implementar protocolos criptográficos por si próprio.
• Liberte os recursos. Se o seu fornecedor aloca recursos ou contextos de autenticação não geridos, implemente IDisposable, e assegure a limpeza adequada. O SqlClient não liberta a instância SspiContextProvider. Elimine o provider quando a sua aplicação já não precisar dele.
• Restrinja o pacote de autenticação. Use apenas pacotes de autenticação adequados ao seu ambiente (por exemplo, Negotiate ou Kerberos). Apenas passe entrada e configuração confiáveis para o pacote de autenticação.
• Teste exaustivamente. Verifique se o seu fornecedor funciona corretamente em todas as condições esperadas, incluindo renovação de tokens, pooling de ligações e cenários de failover.

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

Tipos de login

Um login dá a uma identidade acesso ao servidor. Um utilizador de base de dados representa uma identidade dentro de uma base de dados. Mapeie o login ou grupo pretendido para um utilizador da base de dados e depois conceda apenas as permissões necessárias através de funções na base de dados.

O SQL Server suporta logins de contas do Windows, logins de grupo do Windows e logins SQL. Um grupo Windows permite aos administradores gerir a adesão sem criar um login SQL Server separado para cada pessoa. Os logins de certificados e de chave assimétrica usados para assinatura de código não são identidades de ligação interativas.

Os utilizadores da base de dados contida e os responsáveis da Microsoft Entra têm requisitos de provisionamento diferentes. Consulte Principals e a documentação de autenticação do endpoint em vez de assumir que todos os utilizadores precisam de um login SQL.

Autenticação em modo misto

Utilize a autenticação SQL apenas num endpoint configurado para a aceitar. Fornecer User ID e Password, desativar a segurança integrada e manter a validação de certificados ativada. Authentication=Sql Passwordseleciona explicitamente autenticação por palavra-passe SQL; não seleciona autenticação por palavra-passe Microsoft Entra.

O seguinte exemplo de consola .NET utiliza 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 Controlo de Transmissão (TCP) como tcp:sql-server.contoso.com,1433. Não imprimas a palavra-passe nem a cadeia de ligação completada.

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 da base de dados ligada. Use o SqlConnectionStringBuilder em vez de concatenar credenciais numa string. O construtor escapa dos valores da cadeia de conexão; não decide que servidor, base de dados ou permissões a sua aplicação deve permitir.

Manter Persist Security Info=false, é o predefinido. Guarda os segredos de produção numa loja secreta protegida, restringe quem os pode ler e roda-os. Não use uma identidade de administrador ou proprietário da base de dados para pedidos rotineiros de aplicação.

Microsoft Entra e limitações dos serviços

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

O Base de Dados SQL do Azure utiliza autenticação SQL ou Microsoft Entra em vez da autenticação integrada Windows comum. A base 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 ligações baseadas em tokens.

Conteúdo relacionado

• Principais (Motor de Base de Dados)
• Práticas recomendadas de segurança
• LocalDB e desenvolvimento local