我们是一个数据中心,它提供SQL Server 2000环境,为我们销售的产品提供数据库服务,该产品在我们的许多客户端及其工作站上作为富客户端应用程序加载。
目前,应用程序使用从客户端站点到我们的数据中心的直接ODBC连接。
我们需要开始加密凭据--因为现在所有内容都是明文--并且身份验证是弱加密的--我正在试图确定在服务器上实现SSL的最佳方式,同时尽量减少客户端的影响。
然而,有几件事:
1)我们有自己的Windows域,所有服务器都连接到我们的私有域。我们的剪报与我们的领地无关。
2)通常,我们的客户端通过以下方式连接到数据中心服务器:( a)使用TCP/IP地址( b)使用我们通过internet发布的DNS名称,从DNS服务器到客户的区域传输,或者客户端可以添加静态主机条目。
3)根据我对启用加密的理解,我可以转到网络实用程序并为我希望加密的协议选择" encryption“选项。例如TCP/IP。
4)当选择加密选项时,我可以选择安装第三方证书或自签名证书。我已经测试了自我签名,但确实有潜在的问题。我一会儿再解释。如果我带着第三方证书,比如Verisign解决方案.我需要什么样的证书?这些不是IIS证书吗?当我通过微软的证书服务器创建自签名时,我必须选择“身份验证证书”。在第三方世界,这意味着什么?
5)如果我创建了一个自签名证书,我就会了解到,对于运行SQL的服务器来说,“发到”名称必须与FQDN相匹配。在我的情况下,我必须使用我的私人域名。如果我使用它,当我试图连接到我的Server时,这对我的客户端有什么作用?他们肯定不能在他们的网络上解析我的专用域名..。
我还验证了在安装自签名证书时,它必须位于运行Server的用户帐户的本地个人存储区中。只有当FQDN与证书的“问题”匹配并且SQL运行在已安装证书的帐户下时,Server才会启动。
如果我使用一个自签名的证书,这是否意味着我必须让我的每个客户安装它来验证?
6)如果我使用第三方证书(这听起来是最好的选择),那么我的所有客户在访问我的专用WAN连接服务器时是否都必须有互联网接入来验证证书?
我该如何处理FQDN?听起来他们必须使用我的私人域名--没有发布--不能再使用我为他们设置的域名了?
7)我计划很快升级到SQL 2000。使用SQL 2005是否比SQL 2000更容易/更好地设置SSL?
如能提供任何帮助或指导,将不胜感激。
发布于 2010-01-28 03:37:24
老实说,最好的办法是停止直接访问数据库服务器。这是一种固有的弱解决方案(从安全性上讲),因为任何人都可以尝试使用sa帐户登录您的Server。
更好的解决方案是在Web服务器上设置web服务,并让应用程序通过HTTPS将请求发送到此Web服务,然后让Web服务将请求转发到数据库,同时断开来自公共internet的数据库连接(或防火墙)。
这也给了您的优势,能够切换数据库没有问题,因为web服务器只是与数据库交谈。此外,您还可以负载、平衡web层,以便随着事情的发展,您可以将连接负载分散到web服务器上。
https://serverfault.com/questions/107041
复制相似问题