3

My company is using a weird database setup and I can't really figure what it is adding in term of security.

Our Setup

Outside World [Firewall] DMZ – Web Server [Firewall] External Database [Firewall] Internal Database

  • The web server can only communicate with the External Database.
  • The External Database cannot be accessed from the outside. For example, I cannot access it from my home even if I know the address and have valid username/password.
  • The Internal Database cannot be accessed from the outside too.

So, the only difference between the External and the Internal Database is that the web server can access the External but not the internal.

Our data flow

When a user enters some information on our website, that information is sent to our webserver. The webserver then insert that information into the External Database. Then a job will run periodically and will take the new data on the External Database and insert it into the Internal Database. Then, employee can modify the data in the internal database and these modifications will be synchronized back into the External Database.

My question

What does it add from a security point of view to have an External and an Internal Database?

It would make sense if one database was accessible from the outside but since they are both behind the firewall what does it changes if we insert directly into the Internal Database. Anyway, if we insert something on the External Database, it will get synchronized to the Internal Database as well.

My problem

We dug ourselves in a complicated synchronization mess with jobs running everywhere, data duplicated everywhere and with that come the traditional errors. Some jobs are not updated when we update the schema, the data is no longer the same between all the databases and we end up with a ton of data that we no longer knows if it’s the most recent copy or not and which one is valid and etc. I see all those problems as a big waste of time and money.

Now, the big reason why we made it so complicated is because: “It’s more secure”. Is it really the case because I don’t see the difference between the web server inserting the data directly into one database and using multiple jobs to synchronize that data everywhere?

Gudradain
  • 6,921
  • 2
  • 26
  • 43
  • 1
    There are situations where an external-facing database is used to store temporary information which is "pulled" not "pushed" into a larger internal database then that data is deleted from the external-facing one. The purpose for this is to reduce the number of records which can be stolen at any given time yet allowing data to continue to be entered. – Trey Blalock Jan 29 '16 at 23:02
  • 1
    Can you clarify what data is in the two DBs? Does the external DB have a limited set of data? Are the two DBs intended to hold duplicate data? Other? – Neil Smithline Jan 30 '16 at 02:15
  • Do others in the company have any idea about the history of this configuration? – Neil Smithline Jan 30 '16 at 02:16
  • Both databases contain roughly the same information but only the internal database can pull/push data to the external database. So it doesn't really protect us against stealing information as both contain the data. Though it does provide protection against rewriting the data. Still I'm wondering if it wouldn't have been simpler to just fine grained the permission of the user associated with the web server to get that protection. – Gudradain Feb 01 '16 at 14:59

2 Answers2

3

There are situations where an external-facing database is used to store temporary information which is "pulled" not "pushed" through a one-way firewall connection into a larger internal database then that data is deleted from the external-facing one. The purpose for this is to reduce the number of records which can be stolen at any given time yet allowing data to continue to flow into the external-facing system. That said your situation may be entirely different. If the data is the same on both sides it likely isn't for this reason but one purpose for doing something like this is because can provide an additional layer of defense in depth for the databases.

Think about the case where SQL-injection attacks go through a front end server and effectively lands an attacker, sometimes with full shell-access, onto the the database connected to web app. In the case of a single database the attacker gets everything including all records. In the case I mentioned above the attacker only has access to a tiny subset of transactional records for the time they have access to the system (hopefully this is discovered and the timeline is very short). In any case, that is one reason why you might do something like this. Again your case may vary.

Trey Blalock
  • 14,099
  • 6
  • 43
  • 49
  • I think the OP says that all data is duplicated between the two databases so your answer (which I think is a very clever idea, BTW) isn't really relevant. I'll ask a clarifying question. – Neil Smithline Jan 30 '16 at 02:14
  • You are right on a few points. The data is indeed only pulled/pushed through a one way firewall connection. But we don't delete it once pulled and we even re-synchronize all the changes that happen once the data is in the internal database. So, I doubt we are trying to protect ourselves against data theft. – Gudradain Feb 01 '16 at 15:10
1

Well, the obvious question is - can the External Database access resources on the network the Internal Database is on?

If the External Database is isolated from the LAN, then that means that an attacker that ends up getting not only into the External Database's records, but also to the External Database's host OS, is unable to get farther into the network.

If the web server was connected directly to the Internal Database, then if they got OS access on the Internal Database, they'd be able to attack the rest of the LAN freely.

For the SQL Server example, your worst case is

  • SQL injection into the server
  • Use xp_cmdshell to run code at the server's command prompt
  • Find out the SQL Server is running as a Domain Admin
  • Wait for 6p.m. on the last workday before a long weekend
  • Steal EVERYTHING
  • Destroy all the backups that are still online
  • Wipe all the drives on the entire network
  • Wipe out the configurations on all network devices that use default passwords (SANs, switches, routers, firewalls, etc.)
Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • That's interesting. I didn't realize SQL injection could go that far. I always thought it was limited only to the database itself. The external database is indeed isolated from the LAN so it makes sense if the idea was to counter attack like that. But, do we need to replicate the data on the internal database to make it available to some internal applications (running on the LAN) or it would be possible to set 1 way connection in the firewall and get rid of all the duplication? – Gudradain Feb 01 '16 at 15:07
  • One way TCP connections on firewalls are solely for initiating a session; once the session is initiated, data goes both ways. Also, for SQL injection, a command like xp_cmdshell '"\\backupserver\c$\program files\backup app\initialize -t=all"' is entirely possible, if the SQL server's service account is a domain admin or equivalent. Precede this with turning xp_cmdshell on if it's off, if the application account is a sysadmin on the sql server, etc. Permissions are critical. Bugs happen, too, including security bugs. – Anti-weakpasswords Feb 02 '16 at 03:55