Re: Question re security

From: Nuno Souto <dbvision_at_iinet.net.au>
Date: Tue, 14 Jan 2014 21:50:59 +1100
Message-ID: <52D51693.6080206_at_iinet.net.au>



On 14/01/2014 9:18 PM, Niall Litchfield wrote:

Thanks heaps for prompt reply!

> 1) Principle of least privilege: The vast majority of workstations do
> not need direct access to sensitive resources, nor do the vast
> majority of application or database servers require direct access to
> non-related resources.

Yup, makes sense to me.
What I don't quite see is need of a subnet and firewall *between* the app server and the db server.
I can grok a subnet and firewall that isolate the app server *AND* the db server in one single unit.
But between the same app environment? Assuming one app per db and per app server (no consolidation),
it makes no sense in that context to argue "separate" apps from other apps. And if we go full consolidation a-la 12c, wow!

> 2) Ensuring you guard against the major risks. Inside attacks are by
> far the most common *cough*snowden*cough*.

Yeah, that is always a concern. I can also see for example subnets between prod and the rest of the dev artillery - DEV/UAT/TST. Nowadays, it's common for those to have exact copies of prod...

> 3) If system a is compromised, then segmenting and separating it from
> system b makes it much less likely that system b will be compromised.

That makes a LOT of sense! Indeed: minimize the impact area in case of break-in.
A very good strategy which I've seen in quite a few places.

> I don't have access to our bandwidth figures (and likely wouldn't
> share them on a public forum anyway), but my *expectation* is that
> bandwith and latency are not adversely affected by such a security
> setup - if they are then there would be an expectation that the
> network admins would work to reduce the latency/bandwidth hit - for
> example I know that on some firewalls SQL*Net packet inspection can
> be a significant CPU drain, in such a case one might choose not to
> implement packet inspection between known "whitelisted" hosts.

Packet inspection kills the performance between app and db servers, IME. I agree entirely: keep it out between those two kinds and only do it for the outside.

> On the whole though I'd expect not to be able to move from
> "application system" to "application system" without encountering
> such barriers.

Fair enough. It's in the *same* app system (between app and db server) that I have difficulty visualizing the need for this.

Are we talking security sensitive sites or vanilla commercial?

I know the military and places like google and such are bipolar, but I have difficulty seeing a small factory/store/govdept getting into this level.

Is it a practice you've seen in a lot of places or just in a few?

I saw it previously in banks, internet SEOs, some gov dealing in politics and most mil orgs, but that's about it. Most others don't bother. Of course: *all* bother with subnets/firewall for the intranet as a whole,
per dept/location. But that is a totally different kettle.

-- 
Cheers
Nuno Souto
dbvision_at_iinet.net.au


--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 14 2014 - 11:50:59 CET

Original text of this message