Internal Audit Policies

The Oracle RDBMS market has long been a-shrinking.

A future as an Oracle specialist definitely looks like being past its shelf-life.

Of course, having spent many years as such you will have many transferable skills anyway, transferable to other products and languages within administration, build, performance, troubleshooting or design and development. And if you’re lucky to a number of these. It’s highly likely that you’ve not been a monogamous technologist anyway.

However, what frustrates me, I mean really, really frustrates me are internal audit policies.

Oracle is filled with plenty of fabulous features.

But when I can’t use a significant number of those then it makes me mad… to the extent that I see this all coming to an end prematurely. Unnecessarily.

I can’t use DBMS_PARALLEL_EXECUTE.

Fabulous feature.

From http://docs.oracle.com/database/122/ARPLS/DBMS_PARALLEL_EXECUTE.htm#ARPLS67331 :

To execute chunks in parallel, the user must have CREATE JOB system privilege.

Well, the application schema isn’t allowed CREATE JOB (or access to DBMS_SCHEDULER) because it’s against the internal audit policy.

(And I also hate it when I’m told that “anyway DBMS_JOB is deprecated” when it’s not, at least not until 12.2 and even then they deprecation is dubious because of transactionality or rather the continued lack thereof in the replacement.)

If I’m granted CREATE JOB then apparently I’m, or rather my application is, likely to suddenly go bonkers creating jobs left, right and centre when I should be using standard job infrastructure like Autosys or Control+M or whatever you use. (Even though I wouldn’t because I’m responsible for what I and my application do. And if I do irresponsible things, in general I expect sanctions and consequences)

I can make a very reasonable and well-reasoned argument as to why I should be using DBMS_PARALLEL_EXECUTE but ultimately I’m arguing with a checklist, even if there is a Jobsworth holding it.

Bottom line is that if I want to do multi-threaded work like this via DBMS_PARALLEL_EXECUTE, I can’t. But if I want to achieve the same thing in one thousand Java threads, that is perfectly fine. This is just not a level playing field!!!

My reasonable response is ok but can’t the DBAs provide a controlled developer toolkit of wrappers around such policied functionality?

To which the answer is also no. Because then the DBAs would potentially be responsible for any issues arising out of that usage.

The internal audit policy is largely driven by external policy coming from generic regulators and auditors (so I am told regularly although I don’t have direct access to the external policy).

The bank is being subjected to severe regulation and those regulations cannot be put on hold whilst alternative solutions are sought. Regulators and auditors have no concern when it comes to the lower level problems that are caused when they see high level gaps that need to be closed.

Yeah… so the application has to deal with the consequences even when the policy is wrong. Sorry. It’s wrong. Or it’s poorly implemented.

The list of what I can and can’t do (not personally remember, this is the main application schema, not me or a representation of me) grows all the time.

This DBMS_PARALLEL_EXECUTE and CREATE JOB is actually an old wound re-opened by a recent refusal to be allowed to use an application context / SYS_CONTEXT.

The application needs CREATE ANY CONTEXT.

No, this is an elevated privilege. Not allowed.

Why is it an elevated privilege? Oh you mean the ANY word? That’s sort of misleading.

Checklist says no.

It’s not the same as CREATE ANY TABLE which allows you to create a table in ANY schema. Contexts are global. Security for actually setting the context value is via a named schema.package.

Checklist says no.

So the application can’t use VPD or any other worthy use case of using applications contexts.

Checklist says no.

So, can the DBA create the context for the application? Or provide some wrapper or toolkit to create it.

Checklist says no.

Um… ok. So that’s it then.

It’s just plain bonkers.

These are just two examples of many.

I’m had many a battle over the “can’t grant a privilege directly to a schema, has to be via a role” conversation. Which then leads to the explanation to the DBA of how PLSQL works. Oh so tedious.

I’m not 100% sure to what extent this is just local law enforcement or whether this is more widespread.

I’m pretty sure the latter but there are bound to be pockets of sanity and common sense out there somewhere.

Bottom line is that this will accelerate the shrinking Oracle RDBMS market.

People whose “speciality” are Oracle checklists are contributing to the demise and they will hopefully be able to transfer their checklist enforcement skills to other markets.

And shouldn’t product owners within Oracle surely be aware and be working with regulators and auditors to address these issues and in turn work with their customers to make sure the what they have discussed and agreed is carried down to the lower level? Also asking too much.

Bonkers. Bonkers. Bonkers. And been getting worse for years.

Working with Oracle is becoming unworkable.

My first article in nearly a year… and not a technical article… just a moan… and a reflection that I’m doing less and less Oracle work.
(But I’m not writing regularly on my other learnings either: http://thereplmc.wordpress.com)

It’s just a shame.

Advertisements

One Response to Internal Audit Policies

  1. stewashton says:

    Enter “Oracle Cloud Audit Services” ! 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: