Re: Database Selection

Centuries ago, Nostradamus foresaw when "IvoD" <gordion(at)quick(dot)cz> would write:
>> smarl(dot)(dot)(dot)(at)g2switchworks(dot)com (Scott Marlowe) writes:
>> > About the security thing. Security is a process, and you won't get
>> > it from using two different database engines.
>>
>> I'd argue that security is an "emergent property" which is either
>> supported by or undermined by particular
>> facts/features/configurations.
>
> I had other "security" aspect on my mind - one half of the
> newsgroups data will be accessible from public part of web pages,
> second part and the whole company data system will be accessible
> from private part of web pages; newsgroups database must have
> read/write web access, company database will have read only web
> access and read/write access from 3 specific IPs.
>
> Lets assume two databases+two database engines:
> If somebody hacks the newsgroups database and gets the read/write
> access then he cannot access data from the company database (different
> engine, different engine type).

Let's assume two databases of two "styles"...

The administrator is unlikely to have a comprehensive understanding of
the security models of either, and will likely be forced into using a
security model that is something of a "lowest common denominator,"
taking on weaknesses of both, unable to take advantage of either's
strengths, and being vulnerable because they don't have time to
understand how to comprehensively protect both systems.

In effect, by dividing your attention, you present attackers with an
additional vulnerability.

> And now lets assume two databases+one database engine: If somebody
> hacks the newsgroups database and gets the read/write access then he
> could switch database under the same hacked access and get the
> read/write access to company data (if somebody gets access to
> protected database through (at least) the "only local
> access+login+password" restrictions then I must expect he knows how
> to switch (hack) to any connected database under the same engine).

You're essentially making the "monoculture" argument; if one fails,
they all do.

Unfortunately, that only involves some subset of the threats.

> That is why I wanted to separate two databases using two different
> database engines (in order to increase the standard security covered by
> other security rules)

Fallacy: You can't "increase" security, and there's no such thing as
"standard security."

What you can do is to use techniques that may (or may not) protect
certain vulnerabilities, whilst potentially exposing others.

> But this idea is maybee too paranoiac and disadvantages of two
> different engines exceed the security benefits (maybe hypothetic)

Security is about protecting against attacks. If there are
unmeasurable attacks, then measuring vulnerability or the implications
of attempts at protective measures may also not be measurable.
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxfinances.info/info/x.html
"But what....is it good for?" -- Engineer at the Advanced Computing
Systems Division of IBM about the microchip. 1968