Database Protection

  • Thread starter Thread starter John Barwell
  • Start date Start date
J

John Barwell

Dear All,

I run a win2k domain. We will be bringing a bespoke SQL database system on
board in a few weeks. I want to ensure the integratity of this database by
putting some security measures in place. I have concerns that individuals
may try to take the database to a competitor by copying it on to CD or
sending it through email. I would like to put something in place that will
make the database useless if it goes outside my domain. Has anyone got any
ideas? Encryption?

Many Thanks,


John
 
I am not familiar with SQL however here is my two cents.

EFS or other encryption can limit access to any file to just those that have
the EFS private key either as a user or recovery agent [which is required in
W2K]. W2K does not accomadate sharing of EFS files very well like XP Pro or
W2003 though I believe there is a hack or in a domain multiple recovery
agents can be used that all can have access as long as the private key is on
the computer. EFS has it's own risks and the link below is mandatory reading
for anyone interested in it.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;223316

Otherwise in W2K it is impossible to secure a file from anyone who has read
access to an unencrypted/non password protected file. Therefore you need to
strictly control share and ntfs permissions. The other suggestion is to
harden the computer/domain to include complex passwords, an account lockout
policy, and of course physical security of domain controllers and servers. I
would also enable auditing of account logons and account management in
Domain Controller Security policy and logon events for servers making sure
to increase the size of the security log quite a bit. Ipsec policy can be
used to encrypt data that goes over the network and restrict access to
servers from certain computers on the domain. You can not however use ipsec
ESP/AH for communications between domain controllers and domain members, so
any policy would need to exempt them based on their static IP addresses.
Users leaving their computers logged on an unattended is another problem
that may allow unathorized access. You can use Group Policy to enable the
screen saver to lock a computer after a period of inactivity.

If users do not need cd burners, do not allow them and consider using
workstations with cases that lock access to drives, have usb/firewire
disabled in cmos, boot only from the hard drive, and password protect cmos
settings. Of course you still would have vulnerability to unathorized
computers on the network which would require switches that can use mac
filtering and/or 802.1x authentication to control that. Email is a problem
that can be controlled if you mail servers can deny sending attachments but
then you have a problem with http based email such as Hot Mail and the only
way I know of to control that is to use firewall rules that allow users to
access only specific internet sites based on IP address and deny all other
unauthorized internet access including chat.

Like I said, I don't know much about SQL, so you may also want to post in
one of the SQL newsgroups where you may get advice on how to implement SQL
specific features to improve security. --- Steve
 
MS SQL doesn't have native encryption capabilities, but third parties do
make plug-ins. You might have better luck asking in the sql security
groups. There are entire books devoted to SQL server security. The basics
are don't let the users have administrative (OS or DB) access to the server
and don't let them make queries directly to the database, use stored
procedures to limit what data they can retrieve.
 
John,

Configure the SQL Server service to run under a specific specially
configured account,
Give that account only permissions to the folder(s) containing the database
files,
Make sure you implement filestore security correctly,
Ensure that if backups are stored online they are stored in a similarly
secured location.
Ensure that Backup Operators have restricted privilege & that the Admin
account is not used for backups by a Person,
Keep backup tapes in a fireproof and secure safe (a fireproof safe is not
necessarily secure).
Ensure that Administrator accounts are not used or available for use for any
normal operation.
(By default the Administrator is also the 'sa' = big cheese).
Set the SQL Server (and related) service to start automatically *always*
except during emergency procedures.
This will result in the database files always being open exclusively by the
SQL Server process so no file level copying will normally succeed.

Ensure that all the databases within the SQL Server system are NOT set to
AutoClose - if a database is set to autoclose (a dumb idea most of the time)
then when the last user disconnects from the database SQL Server will close
the database so a file copy would be possible.

Control of Admin accounts with good physical security will get you a long
way.

- Tim
 
Back
Top