TDS 8.0

  • Artigo

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

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

O protocolo TDS (Tabular Data Stream) é um protocolo de camada de aplicativo usado pelos clientes para estabelecer conexão com o SQL Server. O SQL Server usa o protocolo TLS para criptografar os dados transmitidos por uma rede entre uma instância do SQL Server e um aplicativo cliente.

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

O handshake do TLS agora precede qualquer mensagem do TDS, encapsulando a sessão do TDS no TLS para impor a criptografia, tornando o TDS 8.0 alinhado com o HTTPS e outros protocolos da Web. Isso contribui significativamente para a gerenciabilidade de tráfego do TDS, pois os dispositivos de rede padrão agora são capazes de filtrar e passar consultas SQL com segurança.

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

Como o TDS funciona

O protocolo TDS é um protocolo no nível do aplicativo usado para a transferência de solicitações e respostas entre clientes e sistemas de servidores de banco de dados. Nesses sistemas, o cliente normalmente estabelece uma conexão de longa duração com o servidor. Depois que a conexão é estabelecida usando um protocolo de nível de transporte, as mensagens do TDS são usadas para a comunicação entre o cliente e o servidor.

Durante o tempo de vida da sessão do TDS, há três fases:

  • Inicialização
  • Autenticação
  • Troca de dados

A criptografia é negociada durante a fase inicial, mas a negociação do TDS ocorre em uma conexão não criptografada. A conexão do SQL Server é semelhante a esta em versões anteriores ao TDS 8.0:

Handshake do TCP ➡️ pré-logon do TDS (texto não criptografado) e resposta (texto não criptografado) ➡️ handshake do 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 serão assim:

Handshake do TCP ➡️ handshake do TLS ➡️ pré-logon do TDS (criptografado) e resposta (criptografada) ➡️ autenticação (criptografada) ➡️ troca de dados (criptografada)

Criptografia de conexão estrita

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

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

Recursos que não oferecem suporte à criptografia estrita forçada

A opção Force Strict Encryption adicionada com o TDS 8.0 à configuração da 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 conexão strict falham ao se conectar ao SQL Server.

Os seguintes recursos ou ferramentas ainda usam a versão anterior dos drivers, que não oferecem suporte ao TDS 8.0 e, por isso, podem não funcionar com a criptografia de conexão strict:

  • Grupos de disponibilidade AlwaysOn
  • FCI (instância de cluster de failover) Always On
  • Replicação do SQL Server
  • Envio de logs
  • Utilitário sqlcmd
  • utilitário bcp
  • Serviço do Programa de Aperfeiçoamento da Experiência do Usuário do SQL Server
  • SQL Server Agent
  • Database Mail
  • Servidores vinculados
  • Conector Polybase para SQL Server

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

Veja o que foi adicionado às cadeias de conexão para criptografia:

Palavra-chave Padrão Descrição
Encrypt false Comportamento existente
Quando true, o SQL Server usa a criptografia do TLS para todos os dados enviados entre o cliente e o servidor quando o servidor tem um certificado instalado. Os valores reconhecidos são true, false, yes e no. Para saber mais, confira Sintaxe de cadeia de conexão.

Alteração 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, true ou yes, o SQL Server usa o 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, false ou no, a conexão usa o TDS 7.x e será criptografada somente se exigido pelo SQL Server.
TrustServerCertificate false Comportamento existente
Defina como true para especificar que o driver não validará o certificado TLS/SSL do servidor. Se true, o certificado TLS/SSL do servidor será considerado confiável automaticamente quando a camada de comunicação for criptografada com TLS.

Se false, o driver validará o certificado TLS/SSL do servidor. Em caso de falha na validação do certificado do servidor, o driver vai gerar um erro e fechar a conexão. O valor padrão é false. Verifique se o valor passado para serverName corresponde exatamente ao Common Name (CN) ou ao nome DNS no Subject Alternate Name no certificado do servidor para que uma conexão TLS/SSL tenha êxito.

Alteração de comportamento do Microsoft Driver ODBC 18 para SQL Server
Se Criptografar estiver definido como strict, essa configuração especificará o local do certificado a ser usado para validação do certificado do servidor (correspondência exata). O driver é compatível com as extensões de arquivo PEM, DER e CER.

Se Criptografar estiver definido como true ou false e a propriedade TrustServerCertificate não estiver especificada nem definida como null, true ou false, o driver usará o valor da propriedade ServerName 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 propriedade HostNameInCertificate não for especificada ou for definida como null, o driver usará o valor da propriedade ServerName como o nome do host para validar o certificado TLS/SSL do SQL Server.

Conteúdo relacionado