|
|
Posted by Erland Sommarskog on 12/05/06 16:02
Volker Hetzer (firstname.lastname@ieee.org) writes:
> Erland Sommarskog schrieb:
>> Actually, we had this sort of a problem with one of our customers, and
>> we developed a very cheesy low-budget solution. To our defense, I should
>> add that it was the customer's own idea.
>
> Out of curiosity, what would the high-budget solution have looked like?
The initial idea was to use the new encryption facilities in SQL 2005,
but I do not really like that, since it would require the users to work
with multiple passwords. And the customer wanted to go live with a version
of our product that does not support SQL 2005, so encryption was not an
option at that stage anyway.
Instead my suggestion was to have a second database on a second server.
This database would have all the sensitive information. The few functions
that needs to access it would connect to that database with integrated
security (so the users would not need any extra passwords). If the user
is not authorised to that database, the GUI would just display the dummy
data from the main database. It would fall on the business layer to make
that second connection; it would not be in the stored procedures.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|