Database Protection

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 Barwell" <johnbarwell@.msmdirect.co.uk> wrote in message
news:dLYzc.15803$NK4.2608717@.stones.force9.net...
> 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?
>
The best way to prevent theft of your database is to ensure proper security
is in place; both at the physical server layer, SQL Server and database
access layer. Further, implement security protection to the backup's that
may be created. I know of nothing that would render the db useless outside
of a domain...
Steve|||John,
Encryption is possible (at least according to the adds) but I have not done
it. See:
http://www.netlib.com/
http://www.appsecinc.com/products/dbencrypt/mssql/
FWIW,
Russell Fields
"John Barwell" <johnbarwell@.msmdirect.co.uk> wrote in message
news:dLYzc.15803$NK4.2608717@.stones.force9.net...
> 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,
>|||Activecrypt Software provides encryption solution for MSSQL Server XP_CRYPT
(www.xpcrypt.com)
and protection for T-SQL code: stored procedures, user defined functions,
triggers. The code encrypted with SQL Shield (www.sql-shield.com) cannot be
decrypted with existing decryptors like dOMNAR's SQL Server SysComments
Decryptor.|||On 6/16/04 7:25 AM, in article dLYzc.15803$NK4.2608717@.stones.force9.net,
"John Barwell" <johnbarwell@.msmdirect.co.uk> wrote:

> 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.
It is important to first establish a policy that defines what data you wish
to protect from whom. In military terminology this would be the security
classifications of objects and the security clearance of the subjects. The
first step is to establish access control lists (ACLs) that obey the
security principle of least privileges when realizing your security policy.
Users should be granted privileges only to data which they need to complete
their duty. After this, you can audit access to individual records and
insure that they are accessed only on a need-to-know basis by those who do
have permissions to access them.
Once you have done the fundamentals, you can add an additional layer of
security by encrypting data both in transit (by using SSL connections) and
at rest. There are several third-party software and appliance products that
implement column-level encryption and key-management. These features are not
implemented in SQL Server 2000, but are on the way in SQL Server 2005.
I hope that helps. Please let me know if you have any other questions.
-Mark Shlimovich|||>These features are not
> implemented in SQL Server 2000, but are on the way in SQL Server 2005.
This seems to be good news. We have rejected MSSQL precisely because of its
weak security model. We spent one whole year researching and testing it.
Are you saying that the key management will allow one to lock out DBAs and
restrict access of specific tables or objects to specific keys that are
constructed outside of the DBA role or so-called sysadmin role? In other
words, if the db is detached and attached on another MS box could the
sysadmin or some phantom god-like role gain access to that db? This is the
mutli-million dollar question. Do I understand the impending functionality
correct here or I am I way off the mark?
"Mark Shlimovich" <t-marks@.microsoft.com> wrote in message
news:BCF9688E.1EBB%t-marks@.microsoft.com...
> On 6/16/04 7:25 AM, in article dLYzc.15803$NK4.2608717@.stones.force9.net,
> "John Barwell" <johnbarwell@.msmdirect.co.uk> wrote:
>
> It is important to first establish a policy that defines what data you
wish
> to protect from whom. In military terminology this would be the security
> classifications of objects and the security clearance of the subjects. The
> first step is to establish access control lists (ACLs) that obey the
> security principle of least privileges when realizing your security
policy.
> Users should be granted privileges only to data which they need to
complete
> their duty. After this, you can audit access to individual records and
> insure that they are accessed only on a need-to-know basis by those who do
> have permissions to access them.
> Once you have done the fundamentals, you can add an additional layer of
> security by encrypting data both in transit (by using SSL connections) and
> at rest. There are several third-party software and appliance products
that
> implement column-level encryption and key-management. These features are
not
> implemented in SQL Server 2000, but are on the way in SQL Server 2005.
> I hope that helps. Please let me know if you have any other questions.
> -Mark Shlimovich
>|||>if the db is detached and attached on another MS box could the
>sysadmin or some phantom god-like role gain access to that db?
Only if in addition to the database itself they had access to the keys. SQL
Server 2005 will provide a key management system.