> smarl...@xxxxxxxxxxxxxxxxx (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). 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). 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) But this idea is maybee too paranoiac and disadvantages of two different engines exceed the security benefits (maybe hypothetic)
