从远程网络上的Windows应用程序访问SQL Server的常见做法？

Question

Background

We have a Windows .NET application used by our field employees who travel all over the country and live out of hotels most of the time. Recently we added some features that connect directly to our SQL Server 2005 for data access (ie SqlConnection.Open()). Since then we have run into some issues with this generating errors indicating an inability to access the server.

The intermittent nature of this error among our employees led us to believe that it could be due to a port-blocking issue, and that some hotels may be blocking port 1433 - used by SQL Server. As we began researching this issue, we came across many comments expressing that having port 1433 publicly open is a major security hole, and that it should be limited to internal/local use.

Question

So my question is this - what alternatives are there for a Windows application to request and receive data from a SQL Server database that will result in better security and bypass common blockages placed by public networks (such as hotel WiFi)?

I know that one option is VPN, but from what I hear it is not uncommon for VPN connection to be blocked on public networks either.

Answer 1

Yes, use a protocol that is allowed to traverse every NAT/Firewall out there: HTTP. In other words, instead of connecting with SqlConnection, add a mid-tier web service layer. If you think this is complex, see Creating an OData API for StackOverflow including XML and JSON in 30 minutes .

Having the SQL Server TDS port open directly to the network, even after moving to a non-default port, is a major security headache not matter how you twist it or turn it.

Answer 2

Your best bet probably is to use a WebService which will call SQL internally. Then you can publish your webservice to whatever port you need, and the Windows Application (though I'd probably change it to a Web App, myself) can call the webservice on whichever port you've defined.

Answer 3

I would use a WebService or WCF Service with SSL encryption.

You should consider licensing costs too...

If your users access the sql server it's a license per user. Only per socket licensing is different.

Answer 4

There are really only two options:

1. Move the SQL server to a different port. This is still the least secure, but will get you past most firewalls. Hopefully you aren't really sending actual sql across that wire... Encrypt it regardless.

2. Change the app to communicate via web services. This will take a little bit of time, but you have the ability to end up with a much more secure system. Encryption is still a must; and under no circumstance use this to send a sql statement across the wire.