Partilhar via


Casos especiais para criptografar conexões com o SQL Server

Um computador cliente deve confiar no certificado do servidor para que o cliente possa solicitar criptografia TLS (Transport Layer Security) e o certificado já deve existir no servidor. O cenário mais comum para a criptografia do SQL Server envolve ambientes que:

  • Força a criptografia para todas as conexões de cliente de entrada com o SQL Server.
  • Use certificados de uma autoridade de certificação comercial pública na qual o Windows já confia. O certificado raiz correspondente para a Autoridade de Certificação (CA) é instalado no armazenamento de certificados das Autoridades de Certificação Raiz Confiáveis em todos os computadores na sua rede.

Nesse cenário, você não precisa executar etapas extras para criptografia bem-sucedida depois de configurar o SQL Server para criptografia de acordo com o procedimento descrito em Criptografar conexões com o SQL Server importando um certificado. Este artigo fornece os procedimentos para criptografar conexões com o SQL Server para cenários menos comuns que não são abordados em Criptografar conexões com o SQL Server importando um certificado.

Observação

Para obter uma lista completa dos participantes do Microsoft Trusted Root Program, consulte Lista de participantes - Microsoft Trusted Root Program.

Use um certificado emitido por uma autoridade de certificação comercial pública e apenas alguns clientes precisam de conexões criptografadas

  1. Configure o certificado no SQL Server de acordo com o procedimento documentado em Configurar o SQL Server para usar certificados.

  2. Especifique a palavra-chave de criptografia nas propriedades de conexão para Sim ou True. Por exemplo, se você estiver usando o Microsoft ODBC Driver for SQL Server, a cadeia de conexão deverá especificar Encrypt=yes;.

Usar um certificado emitido por uma autoridade de certificação interna ou criado usando New-SelfSignedCertificate ou makecert

Cenário 1: Você deseja criptografar todas as conexões com o SQL Server

Depois de concluir os procedimentos documentados em Etapa 1: Configurar o SQL Server para usar certificados e Etapa 2: Definir configurações de criptografia no SQL Server no artigo Criptografar conexões com o SQL Server importando um certificado, use uma das seguintes opções para configurar seu aplicativo cliente para criptografia.

Opção 1: Configurar aplicativos cliente para Certificado de Servidor Confiável. Essa configuração faz com que o cliente ignore a etapa que valida o certificado do servidor e continue com o processo de criptografia. Por exemplo, se estiver a usar o SQL Server Management Studio (SSMS) 20 e versões posteriores, pode selecionar Certificado de Servidor Confiável na página de Login (ou na página de Opções em versões anteriores).

Opção 2: Em cada cliente, adicione a autoridade emissora do certificado ao armazenamento de autoridade raiz confiável executando as seguintes etapas:

  1. Exporte o certificado de um computador que esteja executando o SQL Server usando o procedimento documentado em Exportar certificado do servidor.

  2. Importe o certificado usando o procedimento documentado em Exportar e importar certificados.

Cenário 2: Somente alguns clientes precisam de conexões criptografadas

Depois de configurar o certificado para uso do SQL Server, conforme documentado na Etapa 1 em Criptografar conexões com o SQL Server importando um certificado, use uma das seguintes opções para configurar seu aplicativo cliente para criptografia:

Opção 1: Configurar aplicativos cliente para confiar no certificado do servidor e especificar a palavra-chave de criptografia nas propriedades de conexão para Sim ou True. Por exemplo, se você estiver usando o Microsoft ODBC Driver for SQL Server, a cadeia de conexão deverá especificar Encrypt=Yes;TrustServerCertificate=Yes;.

Para obter mais informações sobre certificados de servidor e criptografia, consulte Usando o TrustServerCertificate.

Opção 2: Em cada cliente, adicione a autoridade emissora do certificado ao repositório de autoridades raiz confiáveis e especifique parâmetros de criptografia para Sim na cadeia de conexão:

  1. Exporte o certificado de um computador que esteja executando o SQL Server usando o procedimento documentado em Exportar o certificado de um computador que esteja executando o SQL Server.

  2. Importar o certificado.

  3. Especifique a palavra-chave de criptografia nas propriedades de conexão para Sim ou True. Por exemplo, se você estiver usando o Microsoft OLEDB Driver for SQL Server, a cadeia de conexão deverá especificar Usar criptografia para dados = True;

Usar o certificado autoassinado criado automaticamente pelo SQL Server

Cenário 1: Você deseja criptografar todas as conexões de entrada para o SQL Server

  1. Habilite a criptografia no SQL Server usando o procedimento Etapa 2: Definir configurações de criptografia no SQL Server documentada em Criptografar conexões com o SQL Server importando um certificado.

  2. Configure os aplicativos cliente para confiar no certificado do servidor. Confiar no certificado do servidor faz com que o cliente ignore a etapa que valida o certificado do servidor e continue com o processo de criptografia. Por exemplo, se estiver a usar o SQL Server Management Studio (SSMS) 20 e versões posteriores, pode selecionar Certificado de Servidor Confiável na página de Login (ou na página de Opções em versões anteriores).

Cenário 2: Somente alguns clientes precisam de conexões criptografadas

Configure aplicações cliente para confiar no certificado do servidor e especifique a palavra-chave de encriptação nas propriedades de ligação para Sim ou Verdadeiro. Por exemplo, se você estiver usando o Microsoft ODBC Driver for SQL Server, a cadeia de conexão deverá especificar Encrypt=Yes;TrustServerCertificate=Yes;.

Nenhuma configuração extra é necessária no SQL Server para este cenário.

Advertência

As conexões TLS/SSL criptografadas usando um certificado autoassinado não fornecem segurança forte, porque o comprimento da chave nos certificados autoassinados é menor do que a chave nos certificados gerados pela autoridade de certificação. Eles são suscetíveis a ataques de homem no meio. Você não deve confiar em TLS/SSL usando certificados autoassinados em um ambiente de produção ou em servidores conectados à Internet.