We provide datawarehousing reports.
Our datbases are currenlty in the DMZ.
Why? Wouldn't just the webserver be in the DMZ and the db's reside on the private network?RE:
Q1 Our datbases are currenlty in the DMZ. Why?
Q2 Wouldn't just the webserver be in the DMZ and the db's reside on the private network?
A1 That is a good question for your DB developers, IT / business management, etc.,.
A2 Configured well, that may be a somewhat more secure arrangement than having all (?) corporate DBs in a DMZ :( . Some corporations may have reasons to isolate (low risk DBs) in a DMZ. For example, if 'main' internal DBs are completly isolated from any intenet connectivity for security or policy reasons, there may be periodic small loads to the DMZ DBs of a working dataset, (while the core of the historical data is physically secured from any potential internet exposure). Or it may have just been for developer convenience.|||What is very curious is that datawarehouse data is usually highly confidential.
Normally, database servers are restricted from being accessed directly from the Internet due to security/confidential/hacking issues. Also, make sure that the ports that are open are ones absolutely necessary. The database server should only be accessible from the application/web server.
If the database server has to be available in the DMZ then replicate/copy the information from the master database, which is on the intranet behind firewall 2, to the DMZ database - this way if any damage does happen to the DMZ database server your master is still protected.|||When you say "master" db you mean the systme db, right? How do I use the master db to recover from a user db failure. I remember that when I was studying for my exams but I have never had to use that.
-K|||No - The master is the sql server instance running on the intranet (not the dmz).
