hi!
On Feb 20, 2009, at 3:02 PM, MARK CALLAGHAN wrote:
Has anyone here undergone an audit for 'web app' personal data?
In such an audit has access control at the app server been sufficient?
Are managers at such a company comfortable that anyone (such as a
disgruntled employee) with access to the db can read all customer
data?
the problem really comes down to:
if any part of the app needs access to certain data, certain people
will have access to the data (because there must be some way to access
the username/password combination) otherwise it's useless.
"certain people" depends on the size of the organization, i guess. in
my experience it means either a) devs or b) DBAs. or both for small
companies. outside of those two groups, people don't generally have
access to the systems (accounting, marketing or other "business" folks).
in my past, yes access control at the app layer was sufficient to be
considered "safe" by external auditors, but of course i have no idea
of what standard was used to determine safety by the auditor.
we had to sign NDAs and other agreements to mitigate the fallout in
case of abuse, this was in accordance to german laws, though i suspect
much of it would hold up in all of the EU. not sure about the US.
in my experience, pretty much all bets are off once an attacker makes
it inside the network. too many vectors of attack open themselves, and
if he/she is smart about it, chances are they will find the first
username/password combination to unravel the security chain. then
again, you can make it really hard at the expense of, well, expense. i
know of only very few places that actually take it this far, though
(google might of course be one of them, for all i know). most web
shops i'm familiar with (either by first or second hand knowledge)
aren't secure at all once you gain access to the actual systems.
laziness and lack of experience usually leaves all doors open on the
inside, no amount of access control in the DB will help in this
scenario, obviously.
the old and rather lame statement applies: the weakest link determines
the strength of the chain.
to bring this slightly back on topic: if drizzle intends to be run in
reasonably secure environments where you can control who has access
_and_ you trust the people involved (devs, dbas) then it does not need
to concern itself with internal access control.
i'm not yet convinced that it is a realistic assumption, but if people
are willing to sacrifice security for speed, then let them.
the only point that makes me nervous is that ripping out access
control from the entire server code will make it nearly impossible to
add it back later. unless of course you don't rip it out but replace
it with stubs that call no-ops in the default - still representing a
cost, but a hugely decreased one. there you go, another api and plugin
opportunity :)
cheers,
-k
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools
Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
