Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo descreve detalhes sobre o protocolo Transport Layer Security (TLS) 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, onde podem proteger e enviar dados de aplicativos para a camada de transporte. Os protocolos TLS/SSL usam algoritmos de um conjunto de codificação para criar chaves e criptografar informações. O cliente e o servidor negociam a versão do protocolo e o conjunto de codificação a ser usado para criptografia durante a fase inicial de conexão (pré-login) do estabelecimento da conexão. A versão TLS mais alta suportada é sempre preferida no handshake TLS. Para verificar as versões dos protocolos TLS suportadas por diferentes versões dos sistemas operacionais Windows, consulte Protocolos em TLS/SSL (SSP Schannel). Várias vulnerabilidades conhecidas foram relatadas contra SSL e versões anteriores do TLS. Recomendamos que você atualize para TLS 1.2 para comunicação segura.
O SQL Server pode usar TLS para criptografar dados transmitidos por uma rede entre uma instância do SQL Server e um aplicativo cliente. O TLS usa um certificado para implementar a criptografia.
Habilitar a criptografia TLS aumenta a segurança dos dados transmitidos entre 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 TLS, o seguinte processamento extra é necessário:
- Uma viagem de ida e volta de rede extra é necessária 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), o Secure Sockets Layer (SSL) foi descontinuado. Use TLS (TLS 1.2 é recomendado) em vez disso. Para obter mais informações, consulte Suporte a TLS 1.2 para Microsoft SQL Server. O SQL Server 2022 apresenta suporte para TLS 1.3. Para obter mais informações, consulte Suporte a TLS 1.3. Se não existirem protocolos correspondentes entre o computador cliente e servidor, você poderá se deparar com o erro descrito em Uma conexão existente foi fechada à força pelo host remoto.
Visão geral do certificado digital
Os certificados digitais são arquivos eletrônicos que funcionam como uma senha online para verificar a identidade de um usuário ou de um computador. Eles são usados para criar o canal criptografado que é usado para comunicações com clientes. Um certificado é uma declaração digital emitida por uma autoridade de certificação (CA) que garante a identidade do titular do certificado e permite que as partes se comuniquem com segurança usando criptografia.
Os certificados digitais oferecem os seguintes serviços:
- Encriptação: ajudam a proteger os dados 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 afirmam ser. Normalmente, a autenticação é unidirecional, onde a origem verifica a identidade do destino, mas a autenticação TLS mútua 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 detém a chave privada correspondente. As chaves pública e privada são usadas pelo cliente e pelo servidor para criptografar dados antes que eles sejam transmitidos. Para usuários, computadores e serviços do Windows, a confiança na autoridade de certificação é estabelecida quando o certificado raiz é definido no armazenamento 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 estiver na lista de revogação de certificados ou na CRL da autoridade de certificação) ou expirado.
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 (grátis) | - O certificado não é automaticamente confiável pelos computadores clientes e dispositivos móveis. O certificado precisa ser adicionado manualmente ao armazenamento de certificados raiz confiável em todos os computadores e dispositivos clientes, mas nem todos os dispositivos móveis permitem alterações no armazenamento de certificados raiz confiáveis. - Nem todos os serviços funcionam com certificados autoassinados. - Dificuldade em estabelecer uma infraestrutura para a gestão do ciclo de vida dos certificados. Por exemplo, certificados autoassinados não podem ser revogados. |
| Certificado emitido por uma autoridade de certificação interna | O certificado é emitido por uma PKI (infraestrutura de chave pública) na sua organização. Um exemplo são os Serviços de Certificados do Ative Directory (AD CS). Para obter mais informações, consulte Visão geral dos Serviços de Certificados do Ative Directory. | - Permite que as organizações emitam seus próprios certificados. - Menos dispendioso do que os certificados de uma autoridade de certificação comercial. |
- Aumento da complexidade para implantar e manter a PKI. - O certificado não é automaticamente confiável pelos computadores clientes e dispositivos móveis. O certificado precisa ser adicionado manualmente ao armazenamento de certificados raiz confiável em todos os computadores e dispositivos clientes, mas nem todos os dispositivos móveis permitem alterações no armazenamento de certificados raiz confiáveis. |
| Certificado emitido por uma autoridade de certificação comercial | O certificado é adquirido de uma autoridade de certificação comercial confiável. | A implantação de certificados é 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 afirma 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 assunto do certificado | O campo Assunto do certificado contém o nome comum (CN) do host. Por exemplo, o certificado emitido para www.contoso.com pode ser usado para o site https://www.contoso.com. |
- Compatível com todos os clientes, dispositivos e serviços. - Compartimentação. Revogar o certificado de um host não afeta outros hosts. |
- Número de certificados exigidos. Você só pode usar o certificado para o host especificado. Por exemplo, não é possível usar o www.contoso.com certificado para ftp.contoso.com, mesmo quando os serviços estã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 nome alternativo no certificado (SAN) | Além do campo Assunto , o campo Nome Alternativo do Assunto 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 oferece suporte a certificados SAN. - Auditoria e segurança. Você sabe exatamente quais hosts são capazes de usar o certificado SAN. |
- É necessário mais planeamento. Você precisa fornecer a lista de hosts ao criar o certificado. - Falta de compartimentação. Não é possível revogar seletivamente certificados para alguns dos hosts especificados sem afetar todos os hosts no certificado. |
| Certificado Wildcard | 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 certificado curinga *.contoso.com pode ser usado para:www.contoso.comftp.contoso.commail.contoso.com |
Flexibilidade. Você não precisa fornecer uma lista de hosts quando solicita o certificado e pode usá-lo em qualquer número de hosts que possa precisar no futuro. | - Não é possível usar certificados curinga com outros domínios de nível superior (TLDs). Por exemplo, não é possível usar o certificado curinga *.contoso.com para os *.contoso.net hospedeiros.- Você só pode usar certificados wildcard para nomes de host no nível do wildcard. Por exemplo, não é possível usar o *.contoso.com certificado para www.eu.contoso.com. Ou você não pode usar o certificado *.eu.contoso.com para www.uk.eu.contoso.com.- Clientes, dispositivos, aplicativos ou serviços mais antigos podem não suportar certificados curinga. - Os comodins não estão disponíveis com certificados de Validação Estendida (EV). - São necessárias auditorias e controlos cuidadosos. Se o certificado wildcard for comprometido, afeta todos os hosts no domínio especificado. |