On Wednesday 05 October 2005 07:37, L van der Walt wrote:
> Berend Tober wrote:
> > L van der Walt wrote:
> >> I would like to secure Postgres completly.
> >>
> >> Some issues that I don't know you to fix:
> >> 1. User postgres can use psql (...) to do anything.
> >> 2. User root can su to postgres and thus do anything.
> >> 3. Disable all tools like pg_dump
> >>
> >> How do I secure a database if I don't trust the administrators.
> >> The administrator will not break the db but they may not view
> >> any information in the databse.
> >
> > It may be just me and my silly old-fashion attitudes, but I kind of
> > think that if your sys admin(s) cannot be trusted, you are pretty much
> > screwed. And your hiring process needs fixing,
> >
> > But being that as it may, maintaining physical security, i.e., keeping
> > the host server in a locked room with restricted and recorded access
> > and that requires at least two persons present so that collusion is
> > required for tampering, disabling remote root login, granting limited
> > sys admin privileges with sudo (which records the sudoer activities,
> > for auditing purposes) might be a way to accomplish what you are
> > looking for.
>
> Then, I might as well just leave the whole PostgreSQL DB and write my
> own mini DB with encrypted XML files. I am sure someone must have an
> answer for me.
As long as I have the console OR root access you can write whatever you want -
it's just a matter of time to read the data. That's true for Windows, Unix,
Mac - basically any computer - maybe except the 2 or 3 in the pentagon that
use biometric sensors to figure out who wants to fire the nukes.
If you can't trust the sysadmin at your customer, the employees can't be
trusted either. So even if you encrypt everything, somebody needs to have the
key to decrypt, otherwise your whole software is disfunctional. What hinders
the employee from giving that password to the sysadmin (over a cup of
coffee)? I can't think of ANY system that is safe if someone got the console
and/or the root password.
As others have said - you need a legal solution. Have your customer sign a
non-disclosure agreement plus a EULA that restricts your customer from
decompiling, reverse-engineering etc (just download an EULA from Microsoft -
their's is pretty complete). Make the penalties for disassembling high enough
that it hurts when they do (say $500.000 per case). That certainly depends on
the legal system of the country you're selling the software in, so invest the
money into a good attorney rather than an encrypted solution.
If any of my customers would ask me if they should buy a system where they
can't access THEIR data in any other way than using the software that comes
with the deal I'd tell them to back off. Most customers on the planet are
not interested in your software - they make money from THEIR DATA.
I've got a pretty complicated insurance system out there - it took me 5 years
to develop and I'm actually distributing it in source together with a plotted
copy of UML and database diagrams. The point is: none of my customers ever
tried to use the software in any other way than agreed upon. Although I
manage the server (I give it to them as part of the deal, so I deliver
software plus hardware plus maintenance and off-site backup in one contract)
usually someone in the company has the root password just in case I get hit
by a bus. Some of my customers even have an agreement that they can modify
the software IF either agreed upon in a separate statement OR I can't provide
the solution they need.
All in all this provides pretty happy customers to me. They know they can use
the software even if I go out of business for some reason. Some level of
trust is the basis for a good customer relationship (too much trust will kill
you though).
UC
--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
