Our company currently has a customer facing cluster for our signups and customer account management which have direct access to the live database (one master plus several read only slaves).

We have had some discussions recently about improving the security of this setup (beyond existing firewalls). The idea (coming from management) is that the production servers should not have direct access read or write to the database but that instead something should run from either the database server or some other internal server that connects out to the production servers and requests information from some temporary queue existing there.

So

Currently:

Application writes new signups into db
Application reads data about customers from db

(App -> DB)

Proposed:

Application writes new signups into temporary local cache (could be filesystem, temp db, memcached, etc)
Cron/daemon from internal network connects OUT to application server and fetches queued db requests
Cron/daemon writes new data into db or reads old data from db as requested

Cron/daemon pushes back result to application server

(App <- Daemon -> DB)

As a developer (not a sysadmin), this seems ludicrous to me but I readily admit to not being a security expert. As an alternative, I've proposed that if we can't have direct DB access, then we could have an intermediary layer that accepts structured requests and generates DB queries and returns the data. This would look something more like

(App -> Proxy -> DB)

Management's response is that this is suboptimal (but it is still at least open to debate).

I assume this type of argument has played out lots of times in lots of places but I haven't seen anything that specifically addresses the pros or cons of their proposed architecture. Is the proposed backwards proxy approach really that much more secure that its worth the time to build it? If not, what would use to back up your argument if you were asked to implement such an architecture.

2 Answers
2

What specific vulnerability are they looking to mitigate? Seems like a lot of extra overhead and complexity (which inevitably leads to problems of one kind or another).

If the App servers still have access to the database servers, through a proxy or other intermediary, a rooted app server could still craft a request that hoses the DB. I just don't see any particular added security in the proposal; perhaps I'm missing something.

Security isn't some nebulous or fungible "thing" that you can add through obscurity or complexity. Security is specific measure(s) taken to mitigate specific threat(s).

I wasn't given any specific threats, just the 'ideal' that external servers could never push requests/data to internal servers. Instead, the internal servers would have to pull information. The reason: "because its more secure".
–
Rob Van DamNov 6 '10 at 2:18

Production servers shouldn't be External. Typical model is a three zone model, External, DMZ (De-Militarized Zone), and Internal. External should never be able to access Internal. However, the Productions servers should be in the DMZ. DMZ servers should have limited access into the Internal network. Access from the DMZ should be an a least privilege basis.

For this type of application, I would provide access to services on the internal network which do the necessary actions. These should be a limited set of actions which can update one client's data at a time.

Generic access from the DMZ risks your data if someone cracks the a production web server.

I believe this is (close to?) the model I was suggesting. So customers access the external servers which send requests thru the DMZ to anything internal, correct? As opposed to something on the DMZ that pulls requests from external, performs them and pushes back answers?
–
Rob Van DamNov 6 '10 at 2:52

Yes, if the external servers are off your network, then the DMZ services can be provided by a reverse proxy sever ensuring the appropriate requests are being sent by the appropriate servers. If the servers are on your network, they should be in the DMZ. DMZ servers should be able to accept requests rather than pulling them. See en.wikipedia.org/wiki/DMZ_(computing) for more details.
–
BillThor Nov 7 '10 at 4:28