Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
bogey
Posting Yak Master
166 Posts |
Posted - 2007-11-28 : 10:50:29
|
I've got a customer who thinks their data should be sepeated and reside on two seperate databases in case one is compromised. Now I've never heard of anyone doing this and would like comments from the users here as to why this should/(shoult not) be done.I'm assuming that they want to keep their general info e.g. name and address on one database and keep other (medical info) on the other db.None of our db's are outside of the firewalls so to me this makes no sense but I would like feedback.thanks. |
|
pootle_flump
1064 Posts |
Posted - 2007-11-28 : 11:19:31
|
Should not.The only reason it would be compromised would be if you cocked up your security. Having to manage the security of two databases strikes me as increasing the likelihood that you will do just this. In any event, what if the second database is compromised? Perhaps you should suggest a third |
 |
|
cr8nk
Yak Posting Veteran
77 Posts |
Posted - 2007-11-28 : 11:20:48
|
I had a customer who didn't particularly understand technology and requested a similiar scenario, that sensitive data reside in a different database. We stressed that segregating data into 2 seperate databases isn't providing an added layer of protection and only comprimises the integrity of the data because you can't enforce RI cross databases. We reduced some fears by using encryption on the sensitive pieces of data. Have you suggestion encryption to the client? |
 |
|
anonymous1
Posting Yak Master
185 Posts |
Posted - 2007-11-28 : 11:21:49
|
depending on what they mean by compromise (sa password known vs dbo password known) you might or might not be able to increase security by separating databases. separating schema, databases or even different servers could all be options, but each increase the complexity and maintainence plus they might limit functionality. whatever option picked, poor security implementation can completely nullify all the additional effort (something like the same windows account is sa on all boxes and it is an account everyone connects under for database context). probably not the information you were looking for, but more requirements/risk concerns would help others in posting thoughts & comments |
 |
|
|
|
|