Somos un centro de datos que tiene un entorno SQL Server 2000 que proporciona servicios de bases de datos para un producto que vendemos y que se carga como una aplicación de cliente enriquecido en cada uno de nuestros muchos clientes y sus estaciones de trabajo.
Actualmente, la aplicación utiliza conexiones ODBC directas desde el sitio del cliente a nuestro centro de datos.
Necesitamos comenzar a cifrar las credenciales, ya que hoy todo es texto sin cifrar y la autenticación está débilmente cifrada, y estoy tratando de determinar la mejor manera de implementar SSL en el servidor minimizando el impacto del cliente.
Algunas cosas, sin embargo:
1) Tenemos nuestro propio dominio de Windows y todos nuestros servidores están unidos a nuestro dominio privado. Nuestros clientes no tienen nada de nuestro dominio.
2) Normalmente, nuestros clientes se conectan a los servidores de nuestro centro de datos mediante: a) Usando una dirección TCP/IP b) Usando un nombre DNS que publicamos a través de Internet, transferencias de zona desde nuestros servidores DNS a nuestros clientes, o el cliente puede agregar HOSTS estáticos entradas.
3) Por lo que entiendo al habilitar el cifrado, puedo ir a Network Utility y seleccionar la opción "cifrado" para el protocolo que deseo cifrar. Como TCP/IP.
4) Cuando se selecciona la opción de cifrado, tengo la opción de instalar un certificado de terceros o uno autofirmado. Probé el autofirmado, pero tengo posibles problemas. Te lo explicaré en un momento. Si elijo un certificado de terceros, como Verisign o soluciones de red... ¿qué tipo de certificado solicito? ¿Estos no son certificados IIS? Cuando voy a crear un certificado autofirmado a través del servidor de certificados de Microsoft, tengo que seleccionar "Certificado de autenticación". ¿A qué se traduce esto en el mundo tercero?
5) Si creo un certificado autofirmado, entiendo que el nombre de "emisión para" debe coincidir con el FQDN del servidor que ejecuta SQL. En mi caso, tengo que usar mi nombre de dominio privado. Si uso esto, ¿qué efecto tiene para mis clientes cuando intento conectarse a mi servidor SQL? Seguramente no pueden resolver mis nombres DNS privados en su red....
También verifiqué que cuando se instala el certificado autofirmado, debe estar en el almacén personal local de la cuenta de usuario que ejecuta SQL Server. SQL Server solo se iniciará si el FQDN coincide con el "emisión para" del certificado y SQL se ejecuta en la cuenta que tiene el certificado instalado.
Si uso un certificado autofirmado, ¿significa esto que debo hacer que cada uno de mis clientes lo instale para verificarlo?
6) Si utilicé un certificado de terceros, que parece la mejor opción, ¿todos mis clientes deben tener acceso a Internet cuando acceden a mis servidores privados de su conexión WAN privada para verificar el certificado?
¿Qué hago con el FQDN? ¿Parece que tienen que usar mi nombre de dominio privado, que no está publicado, y ya no pueden usar el que configuré para que lo usen?
7) Planeo actualizar pronto a SQL 2000. ¿La configuración de SSL es más fácil o mejor con SQL 2005 que con SQL 2000?
Cualquier ayuda o orientación sería apreciada.
Respuesta1
Sinceramente, lo mejor que puedes hacer es dejar de ir directamente al servidor de la base de datos. Esta es una solución inherentemente débil (en cuanto a seguridad), ya que cualquiera puede intentar iniciar sesión en su servidor SQL utilizando la cuenta sa.
Una mejor solución sería configurar un servicio web en un servidor web y hacer que su aplicación envíe solicitudes a través de HTTPS a este servicio web, luego hacer que el servicio web reenvíe las solicitudes a la base de datos, con la base de datos desconectada (o protegida por firewall) del Internet público.
Esto también le brinda la ventaja de poder cambiar la base de datos sin problemas, ya que los servidores web simplemente se comunican con la base de datos. También puede equilibrar la carga del nivel web para que, a medida que crezcan las cosas, pueda distribuir la carga de conexión entre los servidores web.