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.
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
Configure o certificado no SQL Server de acordo com o procedimento documentado em Configurar o SQL Server para usar certificados.
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:
Exporte o certificado de um computador que esteja executando o SQL Server usando o procedimento documentado em Exportar certificado do servidor.
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:
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.
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
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.
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.