I'm curious about connection string security within a network. We have a
setup with many webservers going out to a clustered DB server. Is all
the effort I put forth to secure my connection strings(whether it be
DPAPI, encrypted and stored in the registry, etc...) in vain, since at
some point I have to leave the current box, and traverse the network to
talk to SQL Server? Couldn't anyone with packet sniffing, or network
monitoring tools compromise the connection string information at that
point? Is there a way to communicate securely with a remote DB server?
You could add an SSL certificate but it will slow down performance.
The flaw in the security design is there for a long time and will not be
fixed either I'm afraid. What you can do, if you administrate both the
webservers and the sqlserver, is this: (I assume you've followed best
practises and aren't running the machines in a domain)
- Add a new user to all the webservers, f.e. ASPNETRunner. Give it a
strong password.
- Add a new user to the machines where SQLServer runs on, and also call it
ASPNETRunner. Give it the same stong password
- Add the ASPNETRunner user as the user which is requesting/modifying data
in the database from the webservers, thus add it to sqlserver and to the
roles that allow modifying data in the catalogs used for the website.
- Use ASPNETRunner as the user which runs ASPNET and the webapplication
(site in IIS)
now you can use integrated security in your connection string, which means
you don't have to use sqlserver security, and therefore don't have to
specify a username/password in your connection string.
BUt because you have a lot of webservers, and a dbcluster, I think it is a
bit of a maintainance nightmare to add the user to all the machines.
The problem is that Microsoft has nice security guidelines but the people
designing the security models aren't reading them. I mean: you can't set
up a decent 2 box setup (db box + webserver) without a domain and WITH
integrated security unless you use the same windows user twice on each box
with the same password (and you have to remember to keep them in sync when
the password changes/has to be changed). ASPNET user, which is used to run
ASP.NET websites, is local to the webserver and unknown to the sqlserver
machine, which leaves you to use sqlserver security, something that is
'highly discouraged' by MS' security documents. Go figure.
FB
