We have developed and deployed a database which contanis very sensitive
information. Our client is now concerned about the security of the back
ups. In essense, if someone in the organization can get hold of the
backup of the database, he can simply restore it on any sql server in
the world with sa permission.
I know Microsoft provides flexibility of adding the "Password" in the
Backup t-sql statement but it wouldn't be of much use if the back up
task is saved as a script and password will be written inside the
script.
your suggestions are really appreciated!
Thanks<muzamil@.hotmail.com> wrote in message
news:1115055348.283887.64500@.z14g2000cwz.googlegro ups.com...
> Hi
> We have developed and deployed a database which contanis very sensitive
> information. Our client is now concerned about the security of the back
> ups. In essense, if someone in the organization can get hold of the
> backup of the database, he can simply restore it on any sql server in
> the world with sa permission.
> I know Microsoft provides flexibility of adding the "Password" in the
> Backup t-sql statement but it wouldn't be of much use if the back up
> task is saved as a script and password will be written inside the
> script.
> your suggestions are really appreciated!
> Thanks
If your client believes they cannot trust their own IT staff and/or cannot
secure their own backups, then I would suggest they have a number of serious
issues to address. On the technical side, they can implement a few standard
practices such as backing up to NTFS drives with appropriate ACLs, limiting
physical access to backup drives and tapes to a minimum number of trusted
staff, using OS-level auditing to see who accesses the files etc.
Ultimately, though, someone has to have access to backups, domain admin and
Exchange admin accounts etc., so they need to have people they can rely on,
and that probably isn't a problem you can or should try to solve for them -
it's really a human resources issue.
However, I appreciate that in reality, and especially in smaller companies,
these things may be not always be so easy. One possibility is to consider
encrypting the sensitive data using a key which is compiled into your
application. Your application can then encrypt/decrpyt the data when users
acess it, but if someone queries the tables directly then they only see the
encrypted data:
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=22
Simonsql
No comments:
Post a Comment