As DBA’s, we all know how to manage security, some are more advanced that others but ensuring that the right people have the right access to the right information is an extremely large part of our jobs – at least it is for me any way.

I’m pretty sure for most people the technical aspect of granting / revoking / denying access is relatively straight forward, however, it’s not the technical issues that this blog post aims to address.

There seems to a common misconception amongst non IT staff (and even some IT staff), that the role of the DBA is not only to run these statements, but also to decide who gets access and who doesn’t.

The role that should decide who gets access and who doesn’t should be the data custodian.

The data custodian should be a totally separate role from the DBA.

Now, notice here that I’m talking about roles – and not individuals. While these roles probably will be carried out by different individuals in larger companies, in smaller companies these two roles may be the responsibility of a single individual – so one person may need to wear two different hats, which can be quite a challenge at times.

I personally, fall into the first category. I have a list of named data custodians (best to have more than 1) for all of the databases on my instances.

And, I’m glad that I do. Why? Because, The data custodian know’s the data (probably better than the DBA in a lot of cases) , they work for the business (and not IT) and they are in a far better position than me (the DBA) to decide who gets access and who doesn’t.

so, why am I writing about this.

Well, it’s fairly common for a user to ask a DBA for access to data.  Often this is just through not knowing the process of getting cleared by a data custodian – and in that case I’ll always try and help the person out by pointing them in the right direction. It’s always best to do this,  as the data custodian may require them to sign something before getting access – for example to a HR database. Most firms require some sort of trail back to who authorised access and when – this protects you and it also protects them.

A similar rule applies when moving databases back from production into UAT \ TEST \ DEV – always get the data custodians permission (as a different set of users will have access to that data) – they are there for a reason.

Most people think it’s the job of the DBA to decide who does and who doesn’t get access to databases, but I always find that if you just take a little time to educate people on the role of the data custodian and why that role exists,  people will probably walk away a lot happier – even if you have not granted them access – than if you simply refused their request.

So, when ever I get a request from a user for database access, the answer is usually yes, you can have that, we’ll just need to run that request past the data custodian.

As DBA’s, we have to manage multiple relationships – and this is one of the most important.

Have a nice day.

cheers

Martin.

Related Posts :- The developer \ DBA relationship