Somos um datacenter que possui um ambiente SQL Server 2000 que fornece serviços de banco de dados para um produto que vendemos e que é carregado como um aplicativo rich-client em cada um de nossos muitos clientes e suas estações de trabalho.
Atualmente, o aplicativo usa conexões ODBC diretas do site do cliente para o nosso datacenter.
Precisamos começar a criptografar as credenciais - já que hoje tudo é texto simples e a autenticação é fracamente criptografada - e estou tentando determinar a melhor maneira de implementar SSL no servidor minimizando o impacto do cliente.
Algumas coisas, no entanto:
1) Temos nosso próprio domínio Windows e todos os nossos servidores estão associados ao nosso domínio privado. Nossos clientes não têm nada do nosso domínio.
2) Normalmente, nossos clientes se conectam aos nossos servidores de datacenter: a) Usando um endereço TCP/IP b) Usando um nome DNS que publicamos via Internet, transfere zonas de nossos servidores DNS para nossos clientes ou o cliente pode adicionar HOSTS estáticos entradas.
3) Pelo que entendi ao ativar a criptografia, posso ir até o Network Utility e selecionar a opção "criptografia" para o protocolo que desejo criptografar. Como TCP/IP.
4) Quando a opção de criptografia é selecionada, tenho a opção de instalar um certificado de terceiros ou um certificado autoassinado. Eu testei o autoassinado, mas tenho possíveis problemas. Vou explicar daqui a pouco. Se eu optar por um certificado de terceiros, como Verisign ou soluções de rede... que tipo de certificado devo solicitar? Estes não são certificados IIS? Quando vou criar um autoassinado através do servidor de certificados da Microsoft, tenho que selecionar "Certificado de autenticação". O que isso significa no mundo de terceiros?
5) Se eu criar um certificado autoassinado, entendo que o nome "emitir para" deve corresponder ao FQDN do servidor que está executando o SQL. No meu caso, tenho que usar meu nome de domínio privado. Se eu usar isso, o que isso fará com meus clientes ao tentar se conectar ao meu SQL Server? Certamente eles não podem resolver meus nomes DNS privados em sua rede....
Também verifiquei que quando o certificado autoassinado é instalado, ele deve estar no armazenamento pessoal local da conta de usuário que está executando o SQL Server. O SQL Server só será iniciado se o FQDN corresponder ao "problema para" do certificado e o SQL estiver em execução na conta que possui o certificado instalado.
Se eu usar um certificado autoassinado, isso significa que preciso que todos os meus clientes o instalem para verificar?
6) Se eu usei um certificado de terceiros, o que parece ser a melhor opção, todos os meus clientes precisam ter acesso à Internet ao acessar meus servidores privados de sua conexão WAN privada para verificar o certificado?
O que eu faço em relação ao FQDN? Parece que eles precisam usar meu nome de domínio privado - que não é publicado - e não podem mais usar aquele que eu configurei para eles usarem.
7) Pretendo atualizar para o SQL 2000 em breve. A configuração do SSL é mais fácil/melhor com o SQL 2005 do que com o SQL 2000?
Qualquer ajuda ou orientação seria apreciada
Responder1
Honestamente, sua melhor aposta é parar de ir diretamente ao servidor de banco de dados. Esta é uma solução inerentemente fraca (em termos de segurança), pois qualquer pessoa pode tentar fazer login no SQL Server usando a conta sa.
Uma solução melhor seria configurar um serviço Web em um servidor Web e fazer com que seu aplicativo envie solicitações por HTTPS para esse serviço Web e, em seguida, fazer com que o serviço Web encaminhe as solicitações para o banco de dados, com o banco de dados desconectado (ou protegido por firewall) do internet pública.
Isso também oferece a vantagem de poder alternar o banco de dados sem problemas, pois os servidores da Web apenas se comunicam com o banco de dados. Além disso, você pode balancear a carga da camada da web para que, à medida que as coisas crescem, você possa distribuir a carga de conexão pelos servidores da web.