When does a developer (database) have too much power?

[djbow]

I am in a new situation to me for a very large company and I would like to get some perspective.

Our DBA's have changed their role when it comes to support. The end result is that we have taken on support that has any relation to applications that use the database. In order to maintain that support the DBA's have granted my more power and now I can get into the production database as DBA.

Im afraid that if we get audited, I will get in trouble. I am a developer and I have the power to do anything in production!

Is this situation common? I have never been in this position and I dont mind the work I have to do but I just feel like I if anything goes wrong, I might end up the scape goat.

Let me know your thoughts.

 

[SantaMufasa]

DJBow,

I hope you don't mind my re-posting my reply from earlier (in another forum) when you posted your question. But so that we can get any alternative opinions to mine, here it is:

Yours is a very good question. When I worked as a developer for a bank in California, we were not even allowed in the computer room unless an Auditor accompanied us, and if we were there to make some sort of change, we stood next to the Auditor while the Auditor actually made the change (either at the keyboard or otherwise). So your concern is well taken.

To ensure that you are not to be held responsible during the execution of your job description (and to simply ensure that you will not be the subject of an execution <grin>), I would express your concern to your organisation's chief legal counsel or your company's representative from your Certified Public Accounting firm. Subsequent to their recommendation, I would also obtain a written confirmation that they have reviewed your assignment and its accompanying powers and authority, and have determined that those combinations are acceptable and appropriate.

(You are also welcome to obtain a second opinion by posting your question on the forum entitled, "Information Technology Ethics in the Workplace.")

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]

 

[monkeylizard]

Quietly passing your concerns on to the bean counters (Internal Audit or Controller) is usually sufficient. They will ask the CIO about it, who will ask the VP about it, who will ask the manager about it, who will make the changes so that nobody asks about it again. (Note: This may take some time from your call to the controller to any real change. Let it ride for a month or so)

If the bean counters don't think it's important, then I would suggest thinking about how important is it really? If you still come to the same conclusion, then go for SM's plan of outside pressure. This could be done by simply mentioning to the CPA auditor that "Hey, you might want to look over here."

If they aren't concerned with it either, then drop it.

Monkeylizard
Sometimes just a few hours of trial and error debugging can save minutes of reading manuals.

 

[chiph]

This is either a sign that they place great trust in your judgement, or that they're looking for an expedient answer until they can hire someone.

Personally, I wouldn't worry about it. I'd just make really sure that I had some CYA whenever I had to make a change (aka "get it in email").

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[djbow]

Thanks Chip, my direct manager has a great deal of trust in me and this is the expedient answer because the DBA group decided they werent going to support us anymore but we dont have any budget to bring someone in so Im not sure this is going to be short term.

I ended up blurting out my concerns at our staff meeting today which instigated a long conversation about it. The other developer who has been around a lot longer than I have didnt know exactly how much power I was very concerned. I think that helped re-enforce the need to deal with this sooner than later.

Im trying to parlay this into a promotion for me. We have had a completely different department handling our support and there are some other applications that dont have proper people supporting them. Basically those people arent technical and just bug people until they find the right person to fix the issue. I am offering to head a new group that supports our databases and these other applications.

This will also give them the oppurtunity to hire a former developer that they want back (and he wants to come back)

Hopefully it will all work out.

 

[Ed2020]

Database developers can *never* have too much power.

Ed Metcalfe.

Please do not feed the trolls.....

 

[FXP]

Sounds like good advice has already been given. I would caution anyone in going outside the company unless fraud is suspected. The outside auditors are the CFO's turf. I've worked for a CFO that would explode if anyone said anything to an outside auditor. I guess he felt it all reflected on him and how he was doing his job.

 

[Welshbird]

I've been an analyst in a company where this happened to one of our developers - in a completely different situation I am sure!

I didn't have much confidence in this guy as I had seen his work, so I managed to persuade the 'powers that were' to make sure logs where kept of his activities on the database.

This came in really useful the day that he thought he had truncated all of the tables in his test environment... and he had performed the truncate, just not on the correct server.

This was obviously an issue anyway, but even more so as this was the day that the BIG BOSSES were coming over to look at some reporting, and they were already in the air when he realised what had happened. The restore took much longer than the flight-time.

He hadn't kept any activity logs or plans of his own work so did attempt to deny it to management. Interestingly enough his employment didn't last too long after that!

I'm sure that this isn't an issue that will happen to you, but I'd make sure you document your activities adequately just so you make sure you can justify any actions should you be called to do so.

Fee

The question should be [red]Is it worth trying to do?[/red] not [blue] Can it be done?[/blue]

 

[wmichael]

You indicate you work for a large company. How large? Publicly traded? What type of applications are you supporting? Do they contain any customer, financial or confidential company information?

Just curious; do you have your own unique DBA access ID? Is this shared information? How about source code? Can you change that in production?

Keep in mind that you are likely not the owner of the data you have access to. Furthermore, keep in mind that you have just been granted the power to exceed even your job and affect the business.

Forget what confidence your manager has in you as a person; that is irrelevant. I am sure you are excellent at what you do, and act with integrity.

It does not, however, change the fact that most every regulatory environment would simply shudder at the level of access you have. You can make changes in production as a DBA?

By the time code and data get to production, they should work just fine without having to have a DBA pump in with full access. At most, you should have the ability to report only in production.

Large company? It sounds like a lemon-aide stand. No offense, but wow.

~wmichael

"small change can often be found under seat cushions

 

[Tarwn]

I'm finding the responses interetsing. I work in a small to mid company, <400 computer users, 2 sites, and I am the only person I would classify as a developer at either location. However we are part of a larger corporation holding group and our IT group spans all of the companies, so more accurate numbers might be <1000 users, 8 sites + >10 offsite sales offices/warehouses.
All developers (+2 report writers) have DBA-level access to the production databases (as do IT managers, but thats another story). Each of us has a company, location, or primary application set that is our concern, but none of us are limited in any fashion in what we can do on the production servers. We do have a great deal of logging in place, and only a single person controls the administrator password (also kept in a password vault accessible by Dir. of IT), so all work is done using domain logins.

We pass our regular ISO audits, GMP, H-something-or-other, etc. There are something like 4-6 different groups, mostly food related, since we make a product that comes in contact with food.

Source code is stored centrally, etc.

So, by wmichaels measure, we too are a lemonade stand. We just happen to be the biggest lemonade stand in synthetic versions of our product, and I believe third or fourth biggest lemonade stand in view of all competition (yes, that is worldwide).

My question is, if code and data should work fine by the time they are ready to go to production, without requiring a DBA (or in our case, a developer acting with DBA privileges):
Who builds the tables?
Who builds the procs?
Who makes sure indexing is setup correctly?
Who manages the backup plans, if the changes above require changes to the plan?
Who manages any jobs that need to be run?
Who manages setting up new users for any new databases the application requires?
Setting permissions on procs and tables?

Reporting only doesn't get the job done, even if you are scripting everything from a development DB to a production DB. You either need a DBA or someone with DBA rights.

 

[djbow]

To answer some of your questions

You indicate you work for a large company. How large?

> 100,000 employees

Publicly traded?

Yes

What type of applications are you supporting?

HR Apps

Do they contain any customer, financial or confidential company information?

No customer, but financial and confidential.

Just curious; do you have your own unique DBA access ID?

No, its the batch ID that I have access to with all the power.

How about source code? Can you change that in production?

Yup

 

[Welshbird]

Just curious; do you have your own unique DBA access ID?
No, its the batch ID that I have access to with all the power.

THis comment slightly worries me - as it implies that others use the same log-in. On the grounds of CYA I'd request a unique ID so you can be sure that you all know who did what just in case.

I'm aware that sounds like a really negative comment, but it's also a positive one - it makes sure that things you have done really well will also be attributed to you.

Fee

The question should be [red]Is it worth trying to do?[/red] not [blue] Can it be done?[/blue]

 

[Tarwn]

I agree. Not only from a CYA point of view, but from a maintenance point of view. I know one password that has admin level access in the system, and it's my domain password. Any other accounts that have been created for applications I have built have had access restricted to only what they needed, and never have any type of schema modification access.
If I were to leave the company, the company would be able to easily freeze my account and change the 5 or 6 passwords I know (they are in the master vault with notes on where they are used). This reduces their liability and makes HR feel much more comfortable.
Additionally, since I am wandering around the own databases with my own name, any action I take will be logged under my name. While I have no intention of any negative action, HR and various other business units all feel safer if they know I would be logged.

 

[flapeyre]

We have a "God" profile over here, but the way it works is that it's disabled until we need to use it (only programmers have the menu option to enable it, and we must get management approval before doing so). At that point, a log entry is created, an e-mail goes to management saying who enabled it and when. The programmer who checked out the profile logs on (and is forced to change the password), and makes his/her changes. The job log from the session is also emailed to management, who reviews it. When we are done, we run another menu option to disable the profile. And then, we have to log our actions (to be compared to the job log that was e-mailed to management). If they don't match, we have to clarify.

We had to set up all of this to comply with Sarbanes-Oxley.



Feles mala! Cur cista non uteris? Stramentum novum in ea posui!

 

[Diancecht]

Well, my point is: "who watchs the watcher?"

Ay my job, I cannot even dream with get DBA rigths at production. We need to fill in a form so anyone out there makes the changes but ... is that one smarter than me?

Could be, but it's not the question. It's too much power for anyone because there are no 100% error free people.

I think the important thing is how that rights are used. I imagine that those users are there just in case, they're not used unless any critical issue really needs it.

So if it's the case, I'd carefully report in advance to my supervisor from my own enterprise and my customer if I have one, getting their written approval before commiting any change.

Anyway, at my work I just send the database scripts to one guy that most of the times executes them without even looking what are they doing: they rely on us.

Coulb be risky, but assuming there's a preproduction environment, errors can be reduced to minimal. And here everything goes OK.

Cheers,
Dian