Validação de criptografia e certificado em Microsoft.Data.SqlClient

Baixar ADO.NET

Use a Segurança da Camada de Transporte (TLS) para criptografar o tráfego entre sua aplicação e o SQL Server. Mantenha a validação do certificado do servidor ativada para verificar a identidade do servidor. A criptografia sem validação de identidade não protege contra um adversário intermediário que se faz passar pelo servidor.

Microsoft.Data.SqlClient usa Encrypt=Mandatory e TrustServerCertificate=false por padrão. Encrypt=true é sinônimo de Mandatory. Para uma conexão remota, solicite explicitamente essas configurações e provista um certificado de servidor que o cliente possa validar:

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

Substitua os marcadores e use um método de autenticação suportado pelo seu servidor e ambiente de aplicação. Para SQL do Azure ou banco de dados SQL no Microsoft Fabric, veja autenticação Microsoft Entra.

Escolha um modo de criptografia

Encrypt controla se o cliente precisa de criptografia. Um servidor também pode exigir criptografia. Esta tabela descreve o comportamento atual sem fixação de certificado:

Mandatory Use para conexões criptografadas com servidores que não suportam TDS 8.0. Use Strict quando seu endpoint suporta TDS 8.0, incluindo SQL Server 2022 (16.x) e versões posteriores. TDS 8.0 suporta TLS 1.2 e TLS 1.3; não requer TLS 1.3. A versão negociada do TLS também depende da configuração do cliente, servidor e sistema operacional.

Optional Não é uma solução para erros de certificado. Pode deixar os dados da aplicação sem criptografia quando o servidor não precisa de criptografia.

Configure um certificado de servidor verificável

Para validação normal de certificados:

1. Providencie um certificado que atenda aos requisitos do certificado do SQL Server.
2. Inclua o nome que os clientes usam para se conectar no nome alternativo (SAN) do assunto do certificado.
3. Faça com que a autoridade certificadora emissora e quaisquer certificados intermediários necessários sejam confiáveis em cada host cliente ou container.
4. Configure o SQL Server para usar o certificado e mantenha TrustServerCertificate=false nos clientes.
5. Renovação do certificado de plano antes do vencimento, incluindo quaisquer alterações em nomes ou autoridades emissoras.

Um certificado de uma autoridade certificadora pública ou empresarial pode atender a esses requisitos. Um certificado empresarial não é automaticamente confiável dentro de um contêiner Linux ou em um computador desenvolvedor separado.

Conecte-se por um pseudônimo

Se a conexão usar um alias do Sistema de Nomes de Domínio (DNS) que não está no certificado, primeiro considere emitir um certificado que inclua o alias. Alternativamente, defina HostNameInCertificate para o nome esperado no certificado:

Server=tcp:sql-alias.contoso.com,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=sql-server.contoso.com;MultiSubnetFailover=true;

HostNameInCertificate muda o nome que o SqlClient espera durante a validação do certificado. Ele não muda o destino da rede nem contorna a cadeia de confiança e as verificações de expiração. Deixe-o não definido quando o nome do servidor já corresponder ao do certificado.

Fixe um certificado de servidor específico

ServerCertificate fornece um arquivo de certificado local para comparação exata com o certificado do servidor. Os formatos compatíveis são Privacy-Enhanced Mail (PEM) e Regras de Codificação Diferenciada (DER), incluindo arquivos de certificado .cer. Use-o com Encrypt=Mandatory ou Encrypt=Strict, e mantenha TrustServerCertificate=false.

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=Strict;TrustServerCertificate=false;ServerCertificate=C:\certificates\sql-server.cer;MultiSubnetFailover=true;

Distribua o certificado esperado por um canal confiável e proteja o arquivo contra substituição. Uma correspondência exata do certificado é uma alternativa à validação normal da cadeia e do nome, não uma verificação adicional além disso. Os bytes do certificado devem corresponder; o mesmo nome de assunto ou chave pública sozinho não é suficiente. Um arquivo PIN ausente, ilegível, inválido ou incompatível falha na validação.

Acoplar a implantação do cliente à rotação de certificados. Atualize o PIN quando o certificado do servidor mudar, incluindo a renovação. Não obtenha um PIN aceitando um certificado não verificado da rede.

O SqlClient não expõe um callback público para validação arbitrária de certificado de servidor TLS. AccessTokenCallback controla a aquisição de tokens de autenticação, não a validação TLS.

Certificados de desenvolvimento e solução de problemas

Use um certificado de desenvolvimento confiável com o nome correto do servidor. Se você usar TrustServerCertificate=true temporariamente com Encrypt=true em um ambiente de desenvolvimento isolado, a conexão é criptografada, mas o cliente não autentica o certificado do servidor.

Para configuração do lado do servidor, veja Visão geral do Certificado.

Mudanças no comportamento de criptografia e validação de certificado

Essas notas de compatibilidade explicam mudanças de comportamento ao atualizar aplicações antigas. Novas aplicações devem usar as configurações atuais descritas neste artigo.

Conteúdo relacionado

• Strings de conexão em ADO.NET
• Sintaxe de cadeia de conexão
• Melhores práticas de segurança