March 20, 2008 at 6:25 am
The standard industry practice to prevent people hacking into your data file is encryption.
SQL Server supports encryption of its databases. If the DBA does not know the encryption key, they cannot make sense of the data. The DBA will still be able to see the database structure and retrieve rows from the database, but they will be encrypted.
If you think encryption may be the right solution for you, you will need to do a lot of investigation to find out how best to use it. You need to involve a DBA in this work. If your organisation has no experience of using SQL Server encryption, it would be wise to pay for external advise on how to do this in the best way.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
March 20, 2008 at 11:47 pm
Given that we're talking about SQL 2005 there are various encryption options available to prevent exactly what the original poster was asking about - the risk that someone could get ahold of the .MDF/database files and then mount them elsewhere... sounds like a case for an encrypted database (and backups).
Though I very seriously doubt if I'd let a vendor install an encrypted database anywhere without providing us with the key(s).
Joe
March 21, 2008 at 1:30 am
Joe Clifford (3/20/2008)
Given that we're talking about SQL 2005 there are various encryption options available to prevent exactly what the original poster was asking about - the risk that someone could get ahold of the .MDF/database files and then mount them elsewhere... sounds like a case for an encrypted database (and backups).Though I very seriously doubt if I'd let a vendor install an encrypted database anywhere without providing us with the key(s).
Joe
Or...run profiler, and it would pick up the unencrypted version of the SP's..
Never mind the performance hit that happens when EVERY call to EVERY procedure, and EVERY table requires decryption. Might as well go back to using Access at that point, because your typical database app will be unusable.
Also - you'd better have a good support team in place, since the on-site DBA's won't be able to do ANYTHING. That will go over like a lead balloon there.
By the way - when you encrypt your key data, range searching only applies to encrypted ranges, so you end up with VERY interesting results.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 21, 2008 at 8:58 am
I'd like to add that there could be legal implications to locking a customer out of the database - I understand the intention is to protect the code, but the data inside the db belongs to the customer. You can't deny them access to their own data.
March 21, 2008 at 10:54 am
MR William thanks for replaying but there are not just one costumer the costumer is a company so alot of employees has different permissions to see data so i want to prevent all to access the mdf file itself to see its data and its structure out of its priveldge:)
YoU CaN't LoSe WhAt YoU NeVeR HaD;)
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply