|
Part of being an expert is knowing enough to say what you know and what you don't. In this area I was feeling I was less than confident about the best answer for you so I enlisted a colleague of mine, Steve, at www.briangia.com, and he shared this with me:
"Usually when I get asked a similar question, I respond by asking for a definition of 'secure' as well as what the risks are for the application. For example, if the servers are logically next to each other on a layer 2 switched network, the risks are likely minimal. In other words, it's much more likely that someone will root the Linux box or (more appropriately) will take over the box running SQL server and just grab the data there rather than sniffing the traffic between the app server and database server.
"If the concern is that there is a database call traversing a public, un-trusted network (Internet) a few things should be done, and even more could be done. First, the database server, especially an MS SQL server, should not be exposed to the Internet without a firewall in front of it. That firewall should have a default deny policy for both inbound and outbound and only authorized IPs should be allowed to communicate with the SQL server itself.
"For transport security, there are a couple options that spring to mind. The risk is that someone will sniff out the credentials and/or data while traversing the un-trusted network. First, an IPSec tunnel could be created between the application and database servers. This would effectively encrypt the communication thus preventing, or seriously hindering, any effort to view the data while in transit. Another option would be to create an SSH tunnel or even an SSL tunnel. This is usually less complicated but also less reliable.
"The application is then set up to perform a database call against localhost. When received by localhost, it's automatically transported across the encrypted tunnel. The application doesn't know the difference."
|
