Certificados no SQL Server 2008

Question

Eu preciso implementar SSL para transmissões entre meu aplicativo e o Sql Server 2008.

Estou usando o Windows 7, o Sql Server 2008, o Sql Server Management Studio e meu aplicativo está escrito em c #.

Eu estava tentando seguir a página do MSDN sobre como criar certificados e este em 'Encryptt para um cliente específico', mas fiquei irremediavelmente confuso. Eu preciso de alguns passos para ir mais longe no caminho para implementar a criptografia com sucesso.

Primeiro, não entendo o MMC. Eu vejo muitos certificados lá ... esses certificados que eu deveria estar usando para minha própria criptografia ou estão sendo usados para coisas que já existem? Outra coisa, eu assumo todos esses certificados são arquivos estão localizados no meu computador local, então por que existe uma pasta chamada 'Pessoal'?

Em segundo lugar, para evitar o problema acima, fiz uma pequena experiência com uma montagem auto-assinada. Conforme mostrado no link do MSDN acima, usei o SQL executado no SSMS para criar um certificado autoassinado. Então eu usei a seguinte string de conexão para conectar:

 Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True

Conectou-se, funcionou. Então apaguei o certificado que acabei de criar e ainda funcionou. Obviamente, nunca foi fazer nada, mas porque não? Como eu diria se é realmente "trabalho"? Eu acho que pode estar faltando um passo intermediário de (de alguma forma?) Obter o arquivo do SSMS e para o cliente?

Eu não sei o que estou fazendo nem um pouco, então qualquer ajuda, conselhos, comentários, referências que você possa me dar são muito apreciados.

Obrigado antecipadamente. :)

    

Answer 1

Se eu entendi a especificação do MSDN corretamente, tudo que você precisa é especificar na string de conexão Encrypt=True;TrustServerCertificate=True . Isso significa que o cliente solicita criptografia e está disposto a aceitar qualquer certificado que o servidor possa usar . O servidor sempre tem um certificado autoassinado gerado na inicialização do servidor para usar, se nada mais estiver disponível. Se o cliente estiver disposto a aceitar qualquer certificado , então ele aceitará aquele auto-assinado temporário do servidor, é tão bom quanto qualquer outro.

O que essa configuração fornece é um canal de comunicação criptografado entre seu aplicativo e seu servidor, um canal que não pode ser ouvido com facilidade. No entanto, o canal está aberto a um ataque malicioso do tipo man-in-the-middle. Se um invasor puder enganar o cliente para conectar-se a ele em vez do servidor (por exemplo, controlando os registros DNS, mais exatamente o IP do servidor DNS que o cliente usará, que é uma configuração DHCP trivial). para controlar) então o atacante pode apresentar qualquer certificado e o cliente irá aceitá-lo, ele pode fazer a autenticação completa com o cliente, obtendo assim o nome de usuário e senha SQL usados, então ele pode conecte-se ao servidor verdadeiro e avance para frente e para trás em toda a comunicação, com uma visão livre de todo o conteúdo. O cliente nunca saberá que está sendo 'monitorado'. Este é o ataque "man-in-the-middle".

Para evitar a situação acima, o cliente deve remover o TrustServerCertificate=True da string de conexão. Uma vez feito isso, o certificado usado pelo servidor tem para ser confiado pelo cliente, e é aí que surgem todas as complicações. Se você está bem com uma configuração mais fraca em que você tem um tráfego criptografado, mas você entende que você pode estar sujeito a um ataque man-in-the-middle e você está OK, então use a configuração muito mais simples de TrustServerCertificate=True . Se não, infelizmente você deve realmente entender o que está fazendo e não é trivial. Se os dados forem tão importantes, talvez seja necessário distribuir o dinheiro para que um certificado VeriSign, Thawte ou GlobalSign (estes são as três raízes confiáveis de todos os clientes Windows) para seu servidor (~ $ 500 / ano) seja não tão estranho.

    

Answer 2

"Pessoal" é um nome enganoso para o armazenamento de certificados. Quando você está no MMC, se você ver um certificado que pode ser selecionado, provavelmente você está bem. Eu recomendo usar um certificado real. Esse pode ser um certificado que é criado internamente usando o Microsoft Certificate Server ou um certificado adquirido de um provedor de certificados. Eu não usaria um certificado autoassinado. O serviço de instância do SQL Server também deve ser reiniciado para que entre em vigor.

Algumas dicas gerais:

Se você aplicar a criptografia no cliente, toda a comunicação SQL no cliente deverá usar a criptografia no nível de transporte.

Se você aplicar a criptografia no servidor, toda a comunicação SQL para essa instância deverá usar criptografia no nível de transporte.

Independentemente da configuração escolhida (seletiva ou aplicada), seu aplicativo ainda requer suporte para as várias opções de conexão. Como a palavra-chave de conexão Encrypt.

Descobri pessoalmente que o cliente SQL Native fornece mais mensagens de erro descritivas do que o cliente SQL interno, mas você pode usar / reforçar a criptografia com qualquer um deles.

A documentação da Microsoft é um pouco incompleta, mas há alguns bons artigos:

Usando seletivamente a conexão segura com o SQL Server
link

Como habilitar a criptografia SSL para uma instância do SQL Server usando o Console de Gerenciamento Microsoft do link

Usando palavras-chave de seqüência de caracteres de conexão com o SQL Server Native Client
link