Re: Question re security
Date: Tue, 14 Jan 2014 15:24:25 +0000
Message-ID: <CABe10sZgR7YdDzRnGYoqV2Uf0xXXT1U-XhzvUCeWQU7_BR7uQg_at_mail.gmail.com>
Ah if you have two apps HR and FIN say with servers
HR
application server = SRVAPPHR01
db server = SRVDBHR01
and
FIN
app servers = SRVAPPFIN01,SRVAPPFIN02 db rac cluster = SRVDBFIN01,SRVDBFIN02,SRVDBFIN03
then I agree a firewall between SRVAPPHR01 and SRVDBHR01 or the 5 FIN servers makes little sense to me, I assumed you were talking SRVAPPHR01 being separated from SRVDBFIN01 etc.
On Tue, Jan 14, 2014 at 10:50 AM, Nuno Souto <dbvision_at_iinet.net.au> wrote:
> 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
>
>
-- Niall Litchfield Oracle DBA http://www.orawin.info -- http://www.freelists.org/webpage/oracle-lReceived on Tue Jan 14 2014 - 16:24:25 CET