Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo descreve detalhes sobre o protocolo TLS (Transport Layer Security) e certificados digitais.
Segurança da Camada de Transporte (TLS)
Os protocolos TLS e SSL estão localizados entre a camada de protocolo de aplicativo e a camada TCP/IP, em que podem proteger e enviar dados do aplicativo para a camada de transporte. Os protocolos TLS/SSL usam algoritmos de um conjunto de criptografias para criar chaves e criptografar informações. O cliente e o servidor negociam a versão do protocolo e o conjunto de criptografia a serem usados para criptografia durante a fase de conexão inicial (pré-logon) do estabelecimento da conexão. A versão TLS com maior suporte sempre é preferida no handshake do TLS. Para verificar as versões de protocolos TLS compatíveis com diferentes versões dos sistemas operacionais Windows, consulte Protocolos no TLS/SSL (SSP Schannel). Várias vulnerabilidades conhecidas foram relatadas em relação ao SSL e versões anteriores do TLS. Recomendamos que você atualize para o TLS 1.2 para comunicação segura.
O SQL Server pode usar o Protocolo TLS para criptografar dados transmitidos em uma rede entre uma instância do SQL Server e um aplicativo cliente. O TLS usa um certificado para implementar a criptografia.
A habilitação da criptografia TLS aumenta a segurança dos dados transmitidos pelas redes entre instâncias do SQL Server e aplicativos. No entanto, quando todo o tráfego entre o SQL Server e um aplicativo cliente é criptografado usando o TLS, o seguinte processamento extra é necessário:
- Idas e voltas extras da rede são necessárias no momento da conexão.
- Os pacotes enviados do aplicativo para a instância do SQL Server devem ser criptografados pela pilha TLS do cliente e descriptografados pela pilha TLS do servidor.
- Os pacotes enviados da instância do SQL Server para o aplicativo devem ser criptografados pela pilha TLS do servidor e descriptografados pela pilha TLS do cliente.
Importante
A partir do SQL Server 2016 (13.x), a SSL (Secure Sockets Layer) foi descontinuada. Use o TLS (O TLS 1.2 é recomendado) em vez disso. Para obter mais informações, consulte o suporte do TLS 1.2 para o Microsoft SQL Server. O SQL Server 2022 apresenta suporte para TLS 1.3. Para saber mais, confira o Suporte ao TLS 1.3. Se não houver protocolos correspondentes entre o computador cliente e o servidor, você poderá encontrar o erro descrito em Uma conexão existente que foi fechada à força pelo host remoto.
Visão geral do certificado digital
Certificados digitais são arquivos eletrônicos que funcionam como uma senha online para verificar a identidade de um usuário ou um computador. Eles são usados para criar o canal criptografado usado para comunicações do cliente. Um certificado é uma instrução digital emitida por uma AC (autoridade de certificação) que atesta a identidade do titular do certificado e permite que as partes se comuniquem com segurança usando criptografia.
Os certificados digitais fornecem os seguintes serviços:
- Criptografia: eles ajudam a proteger os dados que são trocados contra roubo ou adulteração.
- Autenticação: eles verificam se seus titulares (pessoas, sites e até mesmo dispositivos de rede, como roteadores) são realmente quem ou o que eles afirmam ser. Normalmente, a autenticação é unidirecional, em que a origem verifica a identidade do destino, mas a autenticação mútua do TLS também é possível.
Um certificado contém uma chave pública e anexa essa chave pública à identidade de uma pessoa, computador ou serviço que contém a chave privada correspondente. As chaves públicas e privadas são usadas pelo cliente e pelo servidor para criptografar dados antes de serem transmitidos. Para usuários, computadores e serviços do Windows, a confiança na AC é estabelecida quando o certificado raiz é definido no repositório de certificados raiz confiável e o certificado contém um caminho de certificação válido. Um certificado é considerado válido se não tiver sido revogado (não está na lista de certificados revogados ou CRL da AC) ou expirou.
Os três principais tipos de certificados digitais são descritos na tabela a seguir:
| Tipo | Descrição | Vantagens | Desvantagens |
|---|---|---|---|
| Certificado autoassinado | O certificado é assinado pelo aplicativo que o criou ou é criado usando New-SelfSignedCertificate. | Custo (gratuito) | - O certificado não é automaticamente confiável por computadores cliente e dispositivos móveis. O certificado precisa ser adicionado manualmente ao repositório de certificados raiz confiável em todos os computadores e dispositivos cliente, mas nem todos os dispositivos móveis permitem alterações no repositório de certificados raiz confiável. - Nem todos os serviços funcionam com certificados autoassinados. – Difícil estabelecer uma infraestrutura para o gerenciamento do ciclo de vida do certificado. Por exemplo, certificados autoassinados não podem ser revogados. |
| Certificado emitido por uma AC interna | O certificado é emitido por uma PKI (infraestrutura de chave pública) em sua organização. Um exemplo é o AD CS (Active Directory Certificate Services). Para obter mais informações, consulte a Visão geral dos Serviços de Certificados do Active Directory. | - Permite que as organizações emitam seus próprios certificados. - Mais barato do que certificados emitidos por uma AC comercial. |
- Maior complexidade para implantar e manter a PKI. - O certificado não é automaticamente confiável por computadores cliente e dispositivos móveis. O certificado precisa ser adicionado manualmente ao repositório de certificados raiz confiável em todos os computadores e dispositivos cliente, mas nem todos os dispositivos móveis permitem alterações no repositório de certificados raiz confiável. |
| Certificado emitido por uma AC comercial | O certificado é comprado de uma AC comercial confiável. | A implantação de certificado é simplificada porque todos os clientes, dispositivos e servidores confiam automaticamente nos certificados. | Custo. Você precisa planejar com antecedência para minimizar o número de certificados necessários. |
Para provar que um titular de certificado é quem ele diz ser, o certificado deve identificar com precisão o titular do certificado para outros clientes, dispositivos ou servidores. Os três métodos básicos para fazer isso são descritos na tabela a seguir:
| Método | Descrição | Vantagens | Desvantagens |
|---|---|---|---|
| Correspondência de entidade de certificado | O campo Assunto do certificado contém o nome comum (CN) do host. Por exemplo, o certificado que é emitido www.contoso.com pode ser usado para o site https://www.contoso.com. |
- Compatível com todos os clientes, dispositivos e serviços. -Compartimentalização. A revogação do certificado de um host não afeta outros hosts. |
- Número de certificados necessários. Você só pode usar o certificado para o host especificado. Por exemplo, você não pode usar o www.contoso.com certificado para ftp.contoso.com, mesmo quando os serviços são instalados no mesmo servidor.-Complexidade. Em um servidor Web, cada certificado requer sua própria associação de endereço IP. |
| Correspondência de SAN (nome alternativo da entidade) do certificado | Além do campo Assunto , o campo Nome Alternativo da Entidade do certificado contém uma lista de vários nomes de host. Por exemplo:www.contoso.comftp.contoso.comftp.eu.fabrikam.net |
-Conveniência. Você pode usar o mesmo certificado para vários hosts em vários domínios separados. - A maioria dos clientes, dispositivos e serviços dá suporte a certificados SAN. – Auditoria e segurança. Você sabe exatamente quais hosts são capazes de usar o certificado SAN. |
- Mais planejamento necessário. Você precisa fornecer a lista de hosts ao criar o certificado. - Falta de compartimentalização. Você não pode revogar seletivamente certificados para alguns dos hosts especificados sem afetar todos os hosts no certificado. |
| Correspondência de certificado curinga | O campo Assunto do certificado contém o nome comum como caractere curinga (*) mais um único domínio ou subdomínio. Por exemplo, *.contoso.com ou *.eu.contoso.com. O *.contoso.com certificado curinga pode ser usado para:www.contoso.comftp.contoso.commail.contoso.com |
Flexibilidade. Você não precisa fornecer uma lista de hosts ao solicitar o certificado e pode usar o certificado em qualquer número de hosts que talvez seja necessário no futuro. | - Você não pode usar certificados curinga com outros TLDs (domínios de nível superior). Por exemplo, você não pode usar o certificado curinga *.contoso.com para hosts *.contoso.net.– Você só pode usar certificados curinga para nomes de host no nível do curinga. Por exemplo, você não pode usar o *.contoso.com certificado para www.eu.contoso.com. Ou não é possível usar o *.eu.contoso.com certificado para www.uk.eu.contoso.com.- Clientes, dispositivos, aplicativos ou serviços mais antigos podem não dar suporte a certificados curinga. – Os curingas não estão disponíveis com certificados EV (Validação Estendida). – Auditoria e controle cuidadosos são necessários. Se o certificado curinga estiver comprometido, ele afetará todos os hostes do domínio especificado. |