Partilhar via

TDS 8,0

se aplica a: SQL Server 2022 (16.x) Banco de Dados SQL do AzureInstância Gerenciada SQL do Azure

O SQL Server 2022 (16.x), o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure oferecem suporte ao Fluxo de Dados Tabulares (TDS) 8.0.

O protocolo TDS (Tabular Data Stream) é um protocolo de camada de aplicativo usado por clientes para se conectar ao SQL Server. O SQL Server usa TLS (Transport Layer Security) para criptografar dados transmitidos por uma rede entre uma instância do SQL Server e um aplicativo cliente.

O TDS é um protocolo seguro, mas em versões anteriores do SQL Server, a criptografia podia ser desativada ou não habilitada. Para atender aos padrões de criptografia obrigatória ao usar o SQL Server, uma iteração do protocolo TDS foi introduzida: TDS 8.0.

O handshake TLS agora precede qualquer mensagem TDS, envolvendo a sessão TDS em TLS para impor criptografia, tornando o TDS 8.0 alinhado com HTTPS e outros protocolos da web. Isso contribui significativamente para a capacidade de gerenciamento de tráfego TDS, já que os dispositivos de rede padrão agora são capazes de filtrar e passar consultas SQL com segurança.

Outro benefício do TDS 8.0 em comparação com as versões anteriores do TDS é a compatibilidade com o TLS 1.3 e os padrões TLS futuros. O TDS 8.0 também é totalmente compatível com o TLS 1.2 e versões anteriores do TLS.

Como funciona o TDS

O protocolo Tabular Data Stream (TDS) é um protocolo ao nível da aplicação usado para a transferência de pedidos e respostas entre clientes e sistemas de servidor da base de dados. Em tais sistemas, o cliente normalmente estabelece uma conexão de longa duração com o servidor. Uma vez que a conexão é estabelecida usando um protocolo de nível de transporte, as mensagens TDS são usadas para se comunicar entre o cliente e o servidor.

Durante a vida útil da sessão TDS, há três fases:

  • Inicialização
  • Autenticação
  • Intercâmbio de dados

A encriptação é negociada durante a fase inicial, mas a negociação TDS acontece através de uma ligação não encriptada. A conexão do SQL Server tem esta aparência para versões anteriores ao TDS 8.0:

Troca de TCP handshake ➡️ pré-login TDS (texto não criptografado) e resposta (texto não criptografado) ➡️ handshake TLS ➡️ autenticação (criptografada) ➡️ troca de dados (pode ser criptografada ou não criptografada)

Com a introdução do TDS 8.0, as conexões do SQL Server são as seguintes:

Handshake TCP ➡️ Handshake TLS ➡️ Pré-login TDS (criptografado) e resposta (criptografada) ➡️ autenticação (criptografada) ➡️ troca de dados (criptografada)

Suporte ao SQL Server 2025

O SQL Server 2025 (17.x) Preview apresenta o suporte ao TDS 8.0 para as seguintes ferramentas de linha de comando:

Criptografia de conexão estrita

Para usar o TDS 8.0, o SQL Server 2022 (16.x) adicionou strict como um tipo adicional de criptografia de conexão aos drivers do SQL Server (Encrypt=strict). Para usar o strict tipo de criptografia de conexão, baixe a versão mais recente dos drivers .NET, ODBC, OLE DB, JDBC, PHP e Python.

Para evitar um ataque man-in-the-middle com a criptografia de conexão strict, os utilizadores não podem definir a opção TrustServerCertificate para true, impedindo a confiança em qualquer certificado fornecido pelo servidor. Em vez disso, os usuários usariam a HostNameInCertificate opção para especificar o certificado ServerName que deve ser confiável. O certificado fornecido pelo servidor precisaria passar na validação do certificado.

Recursos que não suportam forçar criptografia estrita

A Force Strict Encryption opção adicionada com o TDS 8.0 na Configuração de Rede do SQL Server força todos os clientes a usar strict como o tipo de criptografia. Todos os clientes ou recursos sem a criptografia de strict conexão não conseguem se conectar ao SQL Server.

Os seguintes recursos ou ferramentas ainda usam a versão anterior de drivers que não suportam TDS 8.0 e, como tal, podem não funcionar com a criptografia de strict conexão:

  • Grupos de Disponibilidade AlwaysOn
  • Instância de cluster de failover (FCI) Always On
  • Replicação do SQL Server
  • Transporte de Logs
  • Agente do SQL Server
  • Correio de banco de dados
  • Servidores Vinculados

Alterações adicionais nas propriedades de criptografia da cadeia de conexão

As seguintes adições são adicionadas às cadeias de conexão para criptografia:

Palavra-chave Predefinido Descrição
Encrypt falso Comportamento existente

Quando true, o SQL Server usa a criptografia TLS para todos os dados enviados entre o cliente e o servidor, se o servidor tiver um certificado instalado. Os valores reconhecidos são true, false, yes, e no. Para obter mais informações, consulte Sintaxe da cadeia de conexão.

Mudança de comportamento

Quando definido como strict, o SQL Server usa o TDS 8.0 para todos os dados enviados entre o cliente e o servidor.

Quando definido como mandatory, trueou yes, o SQL Server usa TDS 7.x com criptografia TLS/SSL para todos os dados enviados entre o cliente e o servidor, se o servidor tiver um certificado instalado.

Quando definida como optional, falseou no, a conexão usa TDS 7.x e seria criptografada somente se exigido pelo SQL Server.
TrustServerCertificate falso Comportamento existente

Defina como true para especificar que o driver não valida o certificado TLS/SSL do servidor. Se true, o certificado TLS/SSL do servidor é automaticamente confiável quando a camada de comunicação é criptografada usando TLS.

Se false, o driver valida o certificado TLS/SSL do servidor. Se a validação do certificado do servidor falhar, o driver gerará um erro e fechará a conexão. O valor predefinido é false. Verifique se o valor passado para serverName corresponde exatamente ao Common Name (CN) ou nome DNS no Subject Alternate Name no certificado do servidor para uma conexão TLS/SSL ter sucesso.

Alteração de comportamento para Microsoft ODBC Driver 18 para SQL Server

Se Encrypt estiver definido como strict, essa configuração especifica o local do certificado a ser usado para validação de certificado do servidor (correspondência exata). O driver suporta as extensões de arquivo PEM, DER e CER.

Se Encrypt estiver definido como true ou false, e a TrustServerCertificate propriedade não estiver especificada ou definida como null, trueou false, o driver usará o valor da ServerName propriedade na URL de conexão como o nome do host para validar o certificado TLS/SSL do SQL Server.
HostNameInCertificate nulo O nome do host a ser usado na validação do certificado TLS/SSL do SQL Server. Se a HostNameInCertificate propriedade não for especificada ou estiver definida como null, o driver usará o valor da ServerName propriedade como o nome do host para validar o certificado TLS/SSL do SQL Server.

Conteúdo relacionado