Re: security against dba´s

[rohnskii () gmail com]

Scott's quote "Trust but Verify" (and Nicks comment about designing in security) summarizes what I was trying to say.  
DBA, AFIK you have to give them the "GOD" access, so you have to trust them.  But that being said you still have to 
verify that what they are doing, by logging their access, just like you do for everyone else.

Andre: yes, while as DBA I had access to the sensitive data, but I was "trusted" not to read it unless I needed to in 
performance of my duties.  And I knew that "trust" was backed up with access logging.

And Andre, yes a DBA can send data out via email but that was also part of what I was thinking of controlling when I 
mentioned NAC.  While I still mean that NAC is important, I was blending with a different concept "DLP- Data Loss 
Prevention".  DLP tools intercept outgoing data and have the tools parse it down to the data (can unzip it, can read 
PDF, can read HTML) and can interpret the data to determine if it is sensitive. Then other rules are applied to 
determine if is alright to allow it out, maybe sending it to a person, security?, to make the final determination.

Yes, I agree with the others that sensitive data should be encrypted in the DB.  But generally the idea behind that 
type of encryption (I think) is that data at rest (sitting on the Hard drive) in the DB should be unreadable to "the 
bad guys".  But the DB would have the key and decrypt it when an authorized person (presumably our DBA in this example) 
reads it. 

Part of the security design could be a security policy that requires DBA to sign additional Non-disclosure agreements 
(NDA), with additional legal penalties (beyond being reprimanded or fired) built in to it (depending on the specific 
laws of your location).  Or you could limit hiring DBA's to people who have professional accreditations/certifications 
that impose an additional requirement that they behave "ethically".  It doesn't eliminate/restrict them from doing "bad 
things", but it provides an additional level of redress.  That being you would complain to their "Professional 
association"/certification body and they could face penalties (ie being decertified) from them also.  If their 
certification is important enough it might limit what work they could subsequently get.


Andre: here's a though to make you pull your hair out (grin), email and USB aren't the only possible data leaks.  Off 
hand, how about the "threat" of displaying sensitive data on your/DBA terminal and snapping a picture of it with a 
digital camera (like the one on almost every cell phone these days!).  No NAC or DLP will prevent people from doing 
that.

Don't forget that DBA isn't the only one with access to most/all production data.  I've worked in a "production 
support/developer help desk for users" positions where part of our job was to fix problems in production code/data.  We 
had to read production data to reproduce the user's problem and implement the code or data fix for them.  In another 
job we custom generated code to create answers to user data requests.  They would send in request saying something like 
"give me a list of all customers who live in this specific area, who have bought this type(s) of service(s) from us, 
who are over a specific age ..." and we had to use or report on sensitive customer data.

I do have to admit that most of my experience was before all of this "sensitive" personal information paranoia became 
legislated.  But even so, most of the legislated stuff is covered by the twin concepts of "Trust but verify" and 
"Design Security into the system".  Digressing a little, I just read an interesting blog on the idea of "Designed in 
security" vs "Bolted on, retrofitted Security" being very different concepts (ie bolt-on just doesn't work as 
well/securely as designed in): http://blogs.techrepublic.com.com/security/?p=376