From: Sarah Tanembaum <sarahtanembaum@...>
Date: 2004-07-10T09:42:30+09:00
Subject: Re: Secure Database Systems

Thanks Carl.

The goal is to be able to control down to a field level most efficiently. If
the only trade of for good security is performance, I can live by that BUT
not functionality. It should be transparent and ONLY the authorized user can
view the field in cleartext.

Ideally, if somehow I can rest the responsibility to the owner of the
information(user configurable) whether its the whole record or part of the
record(some fields are read-only public, some fields read-write for
restricted group, and some are for the owner eyes only), then I can think of
other security prevention without sacrifying usability.

Does any of the opensource/commercial (object or relational) DBMS support
field level control? Personally, I prefer the database be the custodian of
this sensitive data, rather than the programming/scriptiong language
controlling the business logic. Is this make any sense?

Thanks

Sarah

"Carl Youngblood" <carl.youngblood@gmail.com> wrote in message
news:e5ed7b6904070911523061c96e@mail.gmail.com...
> What you are referring to is actually a book called TRANSLUCENT
> DATABASES written by Peter Wayner.  Read more about it here:
> http://www.wayner.org/books/td/.  I've read it, and although it was a
> bit cheaply edited, it is a good book worth reading and has some
> pretty good advice.  One thing Wayner does little to consider is the
> ease-of-use and the performance factors.  You can encrypt individual
> fields in your database with a password known only to the user, but if
> the user forgets his/her password, that's all she wrote.  The data is
> for all intents and purposes gone.  Wayner does suggest a variety of
> methods, but most of them rely on secret information in the user's
> possession.  I would argue that most applications favor usability over
> security--i.e., most people don't want to lose all their data if they
> forget their password, so most applications are designed with a
> database where data is stored in the clear or at least where it is
> only obfuscated by a password that is recoverable.  The performance
> factor is also a big deal.  You don't want to have to decrypt every
> row of a 100,000 row result set.
>
> TRANSLUCENT DATABASES advocates practices that can be used on any
> database, so you don't need to worry about whether or not your RDBMS
> "supports" this "feature" or not.
>
> If you are concerned about someone being able to see your data then I
> would say don't use a shared hosting solution.  Go for something like
> escapebox.net or linode.com.  Then you _are_ the administrator and you
> have total control over your data.
>
> To answer your last question, I'm not sure I understand what you mean
> by "control," but if you're saying what I think you're saying then I
> believe you should use whatever security measures are available to you
> at the various levels of your system, such as verifying file ownership
> settings are secure, setting up a decent user scheme on the database
> layer that doesn't allow users to do more than they need to, requiring
> SSL access to your web app, and using a user authentication system for
> the front end.
>
> Carl
>
> On Sat, 10 Jul 2004 03:32:30 +0900, Sarah Tanembaum
> <sarahtanembaum@yahoo.com> wrote:
> > Hi Carl, thanks for your kind advice.
> >
> > One thing I've learned just yesterday that there are such thing
alled  -
> > Translucent Database - whereas you can
> > encrypt and put security(password or group passwd control) on each
field.
> >
> > Is there such a thing out there that mask out non authorized users(even
> > though if the user is an SA or DBA) from reading sensitive information.
The
> > field itself is not encrypted/protected, just the information stored in
the
> > field is encrypted/protected. Its kind of /etc/passwd database for the
> > unix/linux systems.
> >
> > My problem with the regular RDBMS is that if you are DBA/SA, you own the
> > data/information. Perhaps I'd like to put some control on who can
> > read/modify/add/delete the data.
> >
> > Is the control should be in the database or the programming language
such as
> > Java, Ruby, PHP, ASP, PERL, etc?
>
>