October 2, 2001 at 11:17 am
Can anyone direct me to some info on best practices for hooking up a database to the web? I am mainly concerned with security practices and these seem to be often overlooked in books and articles talking about web access.
Our latest strategy is to create a partial copy of the production db's on the web server and push the needed data to it on a schedule. That way only some of the data is exposed for read, and none of it for write.
Thanks!
Curt
October 3, 2001 at 9:15 am
We put all web servers in the DMZ and only allow them to talk back to the sql servers. I setup users that only have read or write access to the DB's that are needed and don't use SA or any other account that can be dbo or sysadmin on the sql server. That is a good start.
Wes
October 3, 2001 at 10:15 am
This is a good document:
I have my web servers dual homed (actually triple). It looks something like this:
|
Router/Firewall (NAT)
|
192.168.3.0---------------------------
| |
Web Server Web Server
| |
192.168.2.0 ----------------------------
|
SQL Server
|
192.168.1.0 ---------------------------
|
LAN
Web Servers also have a 3rd connection to get to the LAN, but they are not part of the domain. The admins and others have separate passwords on the web server from their local LAN account. In this way, the SQL Server cannot access the internet, nor be accessed.
Steve Jones
October 3, 2001 at 12:31 pm
Thanks for the info.
So as far as user access, you would have to use a standard login to connect to the SQL server, since your web server would not be part of the same domain? Or is there some way to still use trusted authentication in this scenario?
So far we have been setting up standard logins for any web apps, and just giving them execute on stored procs that they use. But then you have to store a password somewhere, which isn't good. But it seems if you are using trusted it wouldn't be any more secure, if an intruder was able to execute code on the web server, they would have the connection anyway.
October 3, 2001 at 11:26 pm
If you're following Microsoft's recommended security document (assuming you're using IIS), your IIS box basically doesn't talk via UDP and you limit the TCP ports to what the web server needs such as ports 80 and 443. Also, the web server would exist in its own workgroup. What these two steps do are tighten down on some of the port vulnerabilities and also in the event that someone does compromise your web server, they aren't in your domain with a domain account. As a result, you are pretty much limited to SQL Server logins.
You're right, in that if the web server is compromised, then it is very likely that the intruder then has the username and password to the SQL Server and can use the web server to access it. That's not good, but compared to using domain accounts, you have significantly limited your exposure should an intruder break through.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
November 26, 2001 at 11:43 pm
Hi guys
We have the following in prod:
internet
|
firewall
|
ssl box
|
webserver (163.232.x)
|---------------domain controller (163.232.x)
sqlserver (10.10.10.3 private network)
|
disk-farm
we run a totally seperate domain for our prod environment, away from
the existing domain of the company. The connect strings to the DB
server are stored in secured registery entries on the webserver
and are only accessible under a specific COM+ user that is domain
protected. The code is all embedded in compiled COM+ DLL's
The network dudes setup all sorts of NIC relaying/on-way coms
etc to make it difficult to access the servers.
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply