0

A close relative of this question on Stack Overflow:

When you have a web site in your DMZ that needs to access production data stored on an internal DB, what strategies do you recommend using to lower the risks that come from accessing live data?

Is it even considered acceptable to have a connection initiated from the DMZ come inside of your network?

An extra detail about the nature of the site that kind of throws a monkey wrench into the machinery is that people using the web site will be competing for "spots" on a first-come, first-serve basis with others using the internal software. Because of this, as close to zero lag time between the two applications as possible is ideal.

Community
  • 1
aehiilrs
  • 103
  • 2

1 Answers1

0

Because of the general nature of the question, I can only mention a few of the many things you can do to reduce risk.

If your web site is extenally facing, you should have a dedicated firewall between it and your datasource, which is configured to only allow traffic between the two servers, for the specific ports required for access. You need this firewall, even if you have a firewall between the web server and the Internet. Having 802.1x and/or machine PKI configured is a good idea too. Additionally, all traffic should be authenticated at the web server, and the web server should have it's own account to access data. This ensures that if user accounts are comprimised, they won't be able to access your datasource.

Ideally, your datasource should be segregated from other internal datasources (i.e. running on a separate database server/VM, or at the very least, a separate instance).

For your internal users, either provide another web server within your Intranet, or make them go outside to access, like everyone else.

Of course, you need to make sure you are following security best practices on your server configurations, so that you minimize your exposure. The DISA STIGS and Microsoft provide good guidance in this area.

newmanth
  • 3,943
  • 4
  • 26
  • 47