* Fraser Stuart
> Here are my two main security issues.
>
> 1) (valid) user does a sudo to root and runs "strings <db name>.MYD" - out
> drops all the sensitive text
> 2) (clever) user gets hold of the application user/password for
> MySQL (it's
> in the app config somewhere) - they run "mysql --user=foo --password=bar"
> and away they go...
>
> Using GRANT will not stop #1 or #2
> Encrypting the comms will not stop #1 or #2
> Encrypting the file system may stop #1 but not #2
>
> Encrypting fields will stop #1 & #2 so long as they don't have the key.
Ok... I agree, using GRANT would work only if you can trust root. :)
Even encrypting the fields will (as you point out) only be safe as long as
your users can't get a hold of the key, and with the clever root users you
seem to have, that could be a problem... ;)
IMO, #1 and #2 should be solved by physically restricting untrusted users
from the db machine, and also from the middle layer ("application server",
web server or similar). The client sw should only have access to your data
through a API in the application layer. The level of security, need of
encryption and so on could be separated in two different "domains":
_within_ the system, and _between_ the system and the client.
The need for security within the system is based on the need to protect the
system, not only against unauthorized access, but also against sabotage or
any kind of system crash. The needs are lower if you can separate the system
from the users, how low will of course depend on what kind of secrets you
try to protect. :) Don't rely on the security of the computer alone, a heavy
lock on the door may be just as important as a strong root password. And
don't forget the human factor: 1) Is your trusted sysadmin _really_
trustworthy, even if your competitor payed him 100K$? and 2) What if your
sysadmin is hit by lightning? The keyword here is redundancy... make sure
you have (at least) two trustworthy sysadmins, or at least that the root
passwords are stored in a safe or similar, only accessible by The Boss.
The need for security between the system and the client is based on the need
to prevent unauthorized access to the data, and will often be solved using
passwords and possibly also encryption. Needless to say, the passwords
should be stronger with higher security demands. Encryption is needed when
you want a somewhat elevated level of security, for instance when you can't
trust your ISP. While encryption can prevent eavesdropping, be aware that
this can give a false sense of security if, for instance, the client is a
web browser, and the "secret" information is stored in the cache of the
browser. In this case, "anyone" could read it from the cache after the
authorized user has left the workstation. If you are _really_ paranoid, you
should also worry about the electromagnetic radiation from the computer
screens and cables, and you would need to physically protect the
workstations. (For more on this, do a google search on "tempest protected"
or similar.)
To summarize: I think you already have a security problem, if you can't
trust your root users. Security is not only a matter of protecting
information from beeing read, it is also about protecting from
sabotage/destruction. No matter what kind of encryption/security you
implement, you would need to store the keys somewhere, and root will have
access to it.
The remedy: only allow access through an application layer. Encrypt the
client/app.layer communication if you need to.
(An exception to the above would be if there was only one or a few fields in
the database that needed protection. Then I would use encryption for those
fields. But not for the entire db.)
--
Roger
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
