That's not my job!

My rotten kids are forever pointing fingers at each other over whose turn it is to help with laundry, or load the dishwasher, or give the dog an enema when he’s having tummy trouble. Actually, we don’t do that to the dog anymore, we simply make him watch that show with the Kardashians, and it has the same effect.

And the reason I bring this up is, it JUST came up in a partner discussion over compliance. We were chatting about which type of product to use in a particular situation to protect data from prying eyes. This subject has arisen on several occasions, this time in relation to compliance. And what we debated was the best way to prevent unauthorized access to compliance-related data. So imagine these options:

I can control access at the identity perimeter, meaning the point at which users authenticate to the proper role to access the data in question. I can also apply policies for authorization, meaning putting rules in place to determine which roles contain the correct privileges for accessing that data. This is a classic case for RBAC. Of course, this presumes that these policies then grant access to the functions which themselves access the data FOR those users. If we’re talking about the Oracle stack, for example, I’m using OIM to provision roles that are maintained in OIA, and using OAM for basic auth and AZ. I might also use OAAM for stronger auth, and even OES for fine-grained access control.

The second option is doing this at the database level. I can create database level roles in EUS. I can create realms of protection in Database Vault. I can employ Data Masking, Data Labels, and the Advanced Security Option, for encrypting (and exposing) data down to the column level, to only those souls fortunate enough to have privileges.

Which is better? This is what I was asked. So here’s the answer. It’s really hard to do business-oriented access control at the database level. It’s not HR-friendly. And you really, really, really have to understand the database’s relation to the individual business functions. But if you ARE able to establish those relations, and you have that understanding, and you’re talking about very critical data, then database security is airtight. No matter what programs a hacker has compromised, he can’t get past that database level wall. It’s the last trench dug by the defenders.

Auth and AZ protection, naturally, relate directly to the business. RBAC allows business people to dictate business-logical security. It’s certainly easier and more natural to maintain than database security.

Ideally, you’d have both. But the expense is most likely prohibitive for most organizations to HAVE both, at least simultaneously on the same apps. You might apply database security in some areas, and access control in others.

So the correct answer is ….. it depends on who’s responsible for it. Who will have the job of maintaining that security? That’s how you decide which to buy and deploy.  With great power comes great responsibility, wisdom we were given decades ago by Stan Lee. If I’m in charge of security for a subsection of the assets, not only must I protect it, I must also ensure access to those who need it. If I’m doing db-level sec, I need to make sure that the users AND the processes that need access can get it, otherwise I’m in business-prevention mode. But if the guys building the web services have done their jobs right, I may only need to provide database-role-level access to those processes that are acting on behalf of the users, and those services are only providing user id’s as context. Meanwhile, business-oriented security staff can build access policies based on users and roles and business context. But again, who’s in charge of security? Who will own it? Who will maintain it?

There are many advantages AND disadvantages to working out of the house (when I’m not on a plane, that is). One of them is having a con call to jump on whenever it’s time to load the dishwasher. “Hey, kids, YOU load the dishwasher. I’ve got to go pay the bills.”