SQLServerCentral / SQL Server 7,2000 / Sarbanes-Oxley / No DBAs allowed access to Production DB Servers... / Latest Posts

RE: No DBAs allowed access to Production DB Servers...

tedo — Thu, 10 Jul 2008 17:05:24 GMT

sounds like you auditors and IT directors are idiots. However, I would follow this to the letter and when a system goes down or a back up fails you need to tell him/her that you are working to his constraints and that this can only be fixed as quick as you can get a new key. The only people that should be band from making changed to production are developers. Regards,Terry

RE: No DBAs allowed access to Production DB Servers...

alen teplitsky — Mon, 17 Dec 2007 08:59:34 GMT

stupid auditors strike againone of the recommendations they told us to implement is to require MS DTC for everything. changed it on a few servers on Friday and now replication snapshots don't work. researched it and MS says not to do this and to use linked servers going forward.

RE: No DBAs allowed access to Production DB Servers...

Wallace Wood — Wed, 07 Nov 2007 14:59:36 GMT

Yes it is true. SOX is a real bummer and causes more head aches every time you look at it. I do not work for this company nor have I used the software they sell but the SOX issues may be worth it for you.http://search.adventnet.com/?query=sarbanes+oxley&searchSubmit=Search

RE: No DBAs allowed access to Production DB Servers...

rudy - Doctor "X" — Thu, 11 Oct 2007 14:11:06 GMT

I wish that I had worn my brown boots today instead of my brown shoes :sick: ...It is getting pretty deep in this thread today :D ...

RE: No DBAs allowed access to Production DB Servers...

John Hick-456673 — Thu, 11 Oct 2007 13:22:08 GMT

Well, well, well...Sergiy's world is certainly Sergiy-centeric - he has inherited no malformed, non-normalized, mission-critical databases with thousands of users and no badly designed legacy apps running as the UIs to the DBs.Sergiy, by your own admission, you are a developer. So, develop. And leave the database administration to the DBAs.And, yes, Sergiy, you ARE the best developer and DBA to have EVER walked this planet (Earth). You said so, yourself.

RE: No DBAs allowed access to Production DB Servers...

Sergiy — Sun, 07 Oct 2007 16:12:42 GMT

Maddogs,I was talking about MY PROJECTS.Projects I designed, built and told developers what to do.Of course, there are plenty of other projects around, designed by normal simple-mind developers.Of course, we have 3-4 minor issues per day and 1-2 major crashes per week with those applications.Of course, there was a suggestion to rewrite at least most critical parts of those projects, and of course management ruled them out. All projects but two, where desperation was too high because of too significant cost of those projects.And because it was absolute disaster they gave me Cart Blanche for any changes.Now nothing reminds those projects are in production.There are some operational guys who are watching the servers (SQL and WEB), doing backups, but they don't have an idea about internal functionality.And there are users which send us notifications about new customers connected to the network.That's how it works in real life.If it's another planet - sorry for you.It means that your planet is a sand box for childish amateurs who cannot build anything actually working.On my planet there are organizations with strict rules about confidentiality, mental health clinics, banks, credit cards, other organisations which don't let anybody to access their data.Do they exist on your planet?What do you think programmers should do?I think they should make programs, automatic procedures to work with data.If human intrusion is required then programmers failed. They appeared to be unprofessional.That simple.P.S. Does MS team have access to you Windows Registry? Or to system tables on your production SQL Server?Do these application work without their intrusions?Can you create anything with about the same level of reliability?Or it's also another planet for you?

RE: No DBAs allowed access to Production DB Servers...

maddogs — Fri, 05 Oct 2007 11:29:49 GMT

I had an intuition prior to this that Sergiy might be from a non-US locale, but now I'm wondering what planet he is from.If you are lucky enough to walk into an IT shop where you are running more than a few applications and all of them run without needing production intervention of any kind, then production must consist only of numerous copies of solitaire on the client machines or exist at some extraterrestrial location. You don't have to be part of a large organization to have inherited applications (via mergers, homegrown, whatever) dating back 25+ years that are considered to be mission-critical that need daily care and feeding. The same management that decides these applications are too expensive to rewrite are the same ones who won't hire a dedicated DBA to comply with separation of duties but are willing to hire SOX auditors, and the IT people keeping the lights on are caught in the middle. Part of the increased pressure on the developer\DBA's as a result of SOX is that they are often expected by this same management to produce the same results in the same timeframe with the addition of the extra oversight overhead and red tape.

RE: No DBAs allowed access to Production DB Servers...

Sergiy — Thu, 04 Oct 2007 19:36:09 GMT

[quote][b]Ninja's_RGR'us (10/2/2007)[/b][hr]Just curious on how you guys proceed...if for exemple something more major happened and that it takes more than 1 hour to correct the situation, do you re-issue access, re-extend the key, assign someone else?What's the procedure in this case?[/quote]Just curios:how do you proceed if your car is broken?Do you call the factory to get the guy from over there within one hour?When we all become PROFESSIONALS not to allow anything major happen on our systems?Are you a programmer or not?Why you cannot program your thing to work without major failures?

RE: No DBAs allowed access to Production DB Servers...

ndeangelo — Thu, 04 Oct 2007 07:30:24 GMT

if the customers are not happy, and / or you are unable to do your job, then Sarbanes-Oxley has succeeded. :D

RE: No DBAs allowed access to Production DB Servers...

sing4you — Thu, 04 Oct 2007 07:27:06 GMT

They have done the same thing at my job and it doesn't work. We've outsourced our network operations, and the "other guys" have all the access to all the test and production machines. It takes a long time to get anything done.The customers are not happy. :crying:

RE: No DBAs allowed access to Production DB Servers...

Ross McMicken — Thu, 04 Oct 2007 02:59:10 GMT

In our environment, we have folks called DBA's whose main role is to check out a privileged ID from an automated ID control system, run the scripts they are given, then check the ID back in. All of the testing and such is done on a test server, with the results approved by the system or data owner (you DO have specific owners for all of the systems and data, don't you). The privileged ID management system changes the passwords every time an ID is checked in. All actions are audited. The DBA's will not run a script that is not approved by an owner.After using this for a couple of years, I can't really see a scenario where a devlopment or resolution person needs any access to the production data other than read.

RE: No DBAs allowed access to Production DB Servers...

Ninja's_RGR'us — Tue, 02 Oct 2007 22:29:21 GMT

Just curious on how you guys proceed...if for exemple something more major happened and that it takes more than 1 hour to correct the situation, do you re-issue access, re-extend the key, assign someone else?What's the procedure in this case?

RE: No DBAs allowed access to Production DB Servers...

Harris-358031 — Tue, 02 Oct 2007 22:24:08 GMT

The director is correct in implementing the security model.This will be the case in typical banking environment. No DBA will be given acess to server inturn to the data, without a prior issue to work. In the environment which I am currently working a DBA has to raise a token if any issue occurs, say a backup has failed.The escalation manager in you case the key-keeper will add you user id to appropriate role for a specified duration..typically an hour. After that you are no longer sysadmin.That means that no one is allowed to try any junk on the system.Thanks,Harris/

RE: No DBAs allowed access to Production DB Servers...

Jeff Moden — Tue, 25 Sep 2007 23:54:53 GMT

Uh huh... who fixes the auditing system if it breaks or causes any performance problems? ;) And who's going to do all the other checking you suggested when the DBA has been locked out of the database :hehe:And, part of the reason to refuse developer access to production data is to make it simpler to enforce SOX. But, before you even go for SOX, try passing the simple PCI audit.

RE: No DBAs allowed access to Production DB Servers...

Joe Clifford — Tue, 25 Sep 2007 23:13:27 GMT

SOX, etc. don't require that you can't have access they require that any changes made to the various systems are audited/documented/logged.Look into products like SQL Sentry, etc. that track all activity against the database... best solution is to get an auditing solution in place, and then lock the DBA's out of the audit system. Document who has dbo access to your databases, make sure you're not sharing user Id's, etc. Then have the auditors run reports from the audit solution to their hearts content.Most audit solutions, like SQL Sentry, etc. will show any change, update, delete, etc. to the database, including what was changed - generating reams and reams of paper along the way which will usually have the auditors purring like kittens.Joe

RE: No DBAs allowed access to Production DB Servers...

Sergiy — Tue, 25 Sep 2007 15:54:54 GMT

[quote][b]alex abenitez (9/25/2007)[/b][hr]I think you just missed the whole point! Sox is not the problem here[/quote]The point here is: guys developed (and keep developing) systems which don't work without manual interfering with production data.SOX rules (or the way it's interpreted by auditors - does not matter) don't let them do it.And that's right![b]It's just a good quality check![/b]It's amazing, how many of you guys failed - and you are not ashamed by it!!!"I'm underachiever - and I'm proud of it!" - I see Bart is not alone.Does your car need mechanic on board to make it to another state?Guys, buy a Russian car (original Russian car, but not Lada, Lada is the best) and feel the quality of your development, experience what your customers experience using your applications.

RE: No DBAs allowed access to Production DB Servers...

Steve Jones - SSC Editor — Tue, 25 Sep 2007 07:59:23 GMT

I tend to agree with Alex that most people miss the point. It's easy to say "everything affects the financial system" and then go crazy with SOX. Part of this problem is that SOX was never well defined and the more stuff that's under it (from the auditor's perspective), the more billable time here is (from the auditor's perspective). There's also legal responsibility and fear or prosecution, and I'm not sure which is more important.SOX is very similar to ISO. It doesn't have specific requirements, but rather says that you must say what you do and do what you say. So document your process for doing things. Whether this is applying patches, accessing data, whatever. The follow the process (and document you did so). It doesn't have to be overly complex, just spelled out in black and white.

RE: No DBAs allowed access to Production DB Servers...

GrassHopper — Tue, 25 Sep 2007 07:35:41 GMT

I think you just missed the whole point!

Sox is not the problem here, but the lack of understanding of what sox requires of us. People are always with their finger on the trigger waiting to say it's a sox issue and must be under control when in fact not everything that is a problem is a sox issue. Let's not confuse sox with red tape. Sox is good, lots of red tape is not good.

RE: No DBAs allowed access to Production DB Servers...

Sergiy — Mon, 24 Sep 2007 21:23:24 GMT

Wow!Guys, honestly, instead of cursing politics and auditors you should pay more attention to the quality of your applications.Can you imagine: some people deploy their projects on Client's site totally isolated from external world! And no one except local sysadmins can access the servers. And of course, those sysadmins don't know anything about data processing in your bloody application and won't mess with the data under any circumstances.Only thing they can do is to give you most recent database backup for investigation if something went wrong.But you must do your investigation in their environment, on separate test server because some kind of data (like hospital patients history) should not be taken outside of the organisation.And you may apply any change to Production by sending scripts to those sysadmins for validation and deployment.And you know - it works!One of my recent projects is running for a year without any intrusion at all.The only time I get news about it is when new customer is assigned for using the application.Small companies should not host their production databases at all. It's just impossible for them to provide comprehensive service. If they do everything - they are not good in anything.Sorry, guys, but if SOX is a problem for you - your development quality sucks.

RE: No DBAs allowed access to Production DB Servers...

GrassHopper — Mon, 25 Jun 2007 07:34:00 GMT

That's usually the case, where somoene takes your tools to be able to do your job away then they figure out that they made you handicapped. But that is really not enough, it has to hurt their bottom line and disrupt the business in order for them to realize they made a decision without really thinking of the consequences. They have to come to the realization that you are not the enemy and that you are there to help them do exactly what they are trying to accomplish. But this is true...we have to play politics.... I have learned that the better you are with dealing with politics in your company, the more you are able to get done. There's no way around the politics.

RE: No DBAs allowed access to Production DB Servers...

swjohnson — Mon, 25 Jun 2007 07:23:00 GMT

We recently moved our datacenter and went through this whole discussion. The Finance/Sr Mgmt/Auditors all pulled that same argument that I couldn't have the SA password nor be a local admin on the box.

I agreed but only on the condition that they (the trustworthy ones --their words) were to be the "key masters". When our folks at overseas offices started calling me at 3 in the morning, I gave them the phone numbers to these trustworthy ones, a meeting was called very quickly to resolve this issue. (I actually go some decent sleep those three nights!)

The end result of the meeting was:

1. I am back were I am able to do my job (SA and local admin). We implemented many standardized procedures that can be documented and followed which is the real meaning of SOX and ultimately what the auditors are looking for.

2. I did use it to get most of the developers off the production boxes and for them to create more of an admin interface to do their jobs.

3. They now have a much bigger appreciation/understanding for the number of hours that we work and our job skills.

4. We had a serious and meaningful discussion about data security, job roles and responsibilities.

I hate politics as much as anyone but sometimes it has to be played when they won't come in with an open mind.

Good luck!

RE: No DBAs allowed access to Production DB Servers...

c Condron-386189 — Mon, 25 Jun 2007 00:29:00 GMT

The auditors should research he concept of "arms length transactions" this is a standard method for dealing with people having multiple roles in financial transactions. i.e. the corporation I own all of the stock in wants to give me a check for personal expenses. The way this is handled is simple. First do everything like it is separate people. Second, document everything. Third do everything by the book.

So log everything done on a production server, and don't do any development work when you're working on the production facilities. If you want be completely covered, log all of your development work as well. Dev work logs can be looser, but this will give a documentable trail of the two separate activities.

--C

RE: No DBAs allowed access to Production DB Servers...

Jeff Moden — Fri, 22 Jun 2007 13:24:00 GMT

Then there's THAT Works almost everytime...

RE: No DBAs allowed access to Production DB Servers...

GrassHopper — Fri, 22 Jun 2007 12:03:00 GMT

Bombard them with requests and then you'll see how fast they'll change it and give you rights again.

RE: No DBAs allowed access to Production DB Servers...

rudy - Doctor "X" — Fri, 22 Jun 2007 10:45:00 GMT

Lots of good stuff here. Basically I agree that SOX is a pain and those who know the least make the most mess procedurally for us DBAs. But now I am going to a bullseye on my back - or for those that are more medievil out there, my head on the chopping block.

I say if you have:

good standards - hardware and software
a solid infrastructure - SAN, network, backup and architecture
automated monitoring - MSX Server, MOM and custom scripts
somewhat stable applications - need I add to this ?

At present I support 20+ instances and 40+ applications. I only access production servers for upgrades. As a matter of fact I now am making changes to system maintenance switching from SAN to NAS drives for database backup storage. This is the first production change that I have made this year !!!

OK now that I've made my peace I am ready ...

RE: No DBAs allowed access to Production DB Servers...

Jeff Moden — Fri, 22 Jun 2007 05:58:00 GMT

Gosh, you would think so... I guess I understand why some folks don't, though... some DBA's don't practice what I consider to be the cardinal rule of being a DBA and it's kind of like being a doctor... "Above all else, cause no harm to the data"... not even if you leave or are asked to leave the company. Shouldn't even be tempted if you're truly a good DBA.

RE: No DBAs allowed access to Production DB Servers...

John McC — Fri, 22 Jun 2007 04:45:00 GMT

Isn't that the basic understanding: If you can't trust your DBA with your data who can you trust?

RE: No DBAs allowed access to Production DB Servers...

Jeff Moden — Thu, 21 Jun 2007 23:27:00 GMT

Bond a DBA or whatever is necessary, but no matter what the circumstance, the DBA must be a trusted individual in order to protect the very security required by SOX... and THAT DBA must have SA privs in order to do that job.

RE: No DBAs allowed access to Production DB Servers...

Justin-14543 — Thu, 21 Jun 2007 16:42:00 GMT

I have been in a situation like this before. It was not for any SOX or HIPAA reasons. It was just so my Boss has full control over everything even the stuff he do not know about. (BTW, my boss was not a bad guy either - he was a control freak (may be due to his cultural background)).

After little over a year, I decided to get out of that place because I have to request access for everything and explain every thing. As a DBA, I must have a feel for my server which I did not have in that place. My boss felt giving more money will solve everything. Money can go only so far.

One day, I decided to walk out even without any job in hand. I was able to find another job within a week and before my last day. I still help them out occassionally (as an outside consultant).

RE: No DBAs allowed access to Production DB Servers...

devereauxj — Tue, 18 Jul 2006 13:17:00 GMT

Common and big misunderstanding. NO SOX auditors will make you do that. IF THEY DO, make the give you names of others that have implemented it. They won't and can't inforce it. Happened here and quickly went away. We are in our 3rd year of full compliance.

joe

RE: No DBAs allowed access to Production DB Servers...

paramind — Fri, 03 Mar 2006 14:17:00 GMT

I suggest, no congress member and no SOX-auditor should be allowed in their jobs without a degree in physics. This will give you some basic clue: http://www.newscientist.com/channel/fundamentals/quantum-world/mg18925405.700

>Even for the crazy world of quantum mechanics, this one is twisted. A quantum computer program has produced an answer without actually running.<

A quantum dba has maintained his servers, without actually having access to them. - or - A quantum dba has committed fraud, without actually having access to the money.

That's, what you we're all looking for. Sincerely.

RE: No DBAs allowed access to Production DB Servers...

david russell-253790 — Wed, 23 Nov 2005 19:47:00 GMT

We did this at a dot.com. I was the lead DBA with two full-time and two part-time DBAs under me. I also coordinated with one admin/DBA for production. With one exception, no "development" DBAs were allowed on production machines. I installed the clusters in the cage at the co-host facility, and beyond that, I never saw them again. All code, all data uploads, and all patches where scripted and delivered in self-installing packages. It was back to that general management philosophy that "SQL Server is so easy that Monkey's can do it!"

Okay, so maybe monkeys CAN do it if the developers (including developer DBAs) do their jobs right.

The one exception to the rule was when a link was discovered, created by a user, to no longer point from our site to its' original site; but now pointing to a porn site. It seemed pretty funny at first that people were buying up URLs and making them porn sites; but it wasn't a laughing matter since our audience was K-8.

it was inconvenient; but not unworkable. and for all the reasons I see people saying they have done it to... maybe the right way to go.

RE: No DBAs allowed access to Production DB Servers...

chisholmd — Fri, 16 Sep 2005 12:43:00 GMT

OMFG. Wow am I ever glad I am located and do business in Canada. SOX sounds like a nightmare!I agree with the earlier poster, with so much division of duties who is going to know enough to see the signs and catch the cheaters.

RE: No DBAs allowed access to Production DB Servers...

MAS-106370 — Tue, 13 Sep 2005 05:26:00 GMT

I think the auditors are not explaining it (SOX) very well. They call it here a division of duties. Therefor, developers are developer and DBA are DBA's.

Unfortunately with smaller companies and even some larger companies, this is not always the case. SOX does not care for "The real world scenerios".

Just my thoughts.

RE: No DBAs allowed access to Production DB Servers...

Goober — Thu, 25 Aug 2005 12:43:00 GMT

What is even more funny is that all of this has happened before with HIPAA ( Health Insurrance Portability and Accountability Act) several years ago. Everyone read into what HIPAA thought it said and locked down servers so individuals who needed access didn't have it.

Although, as an IT manager, I understand the reasoning behind the security. Maybe an IT refrom is needed to change the scope of jobs to meet new security requirements defined by SOX and HIPAA. Maybe there is a lesson to learn here... Probably not...

RE: No DBAs allowed access to Production DB Servers...

MidwestDBA — Fri, 19 Aug 2005 08:35:00 GMT

This is hilarious. Why?

Because in light of SOX all kinds of interpretations have arisen as well as companies claiming to "know" just how to implement SOX. Nowhere, and I mean nowhere does it say in the legislation that DBAs cannot have access to production. You just have to have an audit trail of what's being done.

Want to hear something funnier? Our SOX "guru" says that our developers are not allowed access on our dev servers. She nearly cried when I chuckled.

Don't get me wrong, SOX has it's place. It's about accountability. But I think what SOX has done is give many "business" types something to do.

RE: No DBAs allowed access to Production DB Servers...

bruce sherwood-232207 — Fri, 22 Jul 2005 11:35:00 GMT

I am in a DBA in an organization where we did something like this long before we ever of SOX.When I took over the DBA job, the previous DBA was a developer. He and the other developers we had after him were not very well qualified at what they were doing. They were great guys, but they just took on SQL development when there was a business need, not because they knew what they were doing.What I did was kick them off the production servers. They had a really bad tendancy to create something that ws broken (ussually on the front end) and then go tweak the production data until it worked again. I made them do their job in the development environment, and then create installtion / change scripts for anything that would affect production. Anything they handed to me, I reviewed thoroughly so I understood what was about to change. Occasionally I rejected something because it wasn't thought out or had obvoius errors.What this did was insure the production servers didn't have down time do to another 'oops' error. But this is obvoiusly not SOX compliant becasue I knew far to many details about the inner workings of the database and had access to production data.In another example, we hired a person to be DBA on our accounting system. He was an accountant by previous trade, and a system admin now. He was really good at the job. He even picked up a few development skills that helped him do some custom reporting for the end users from this system. But now he cant have his job by these rules. Not only does he understand the structure of the system, he also understands what the data really means. Luckily for both of us, we work in a 'not for profit' organization that can't afford to hire more people to do half our job since we aren't allowed to. But then we aren't a publicly traded organization. So no share holders to appease either.I can see how SOX has some good ideas. I can also see how resistance to change is its biggest barrier. As a DBA I also see it as a bad idea. I ceratinly don't want all the comfort I have in how I get to do my job to go away. If I step back from that I can also see how the controls can work to improve data safety. But then pessimism kicks in and I see how an organization nieve enough to blindly follow this will get its data 'owned' long before they realize it and more then likely way to late.

RE: No DBAs allowed access to Production DB Servers...

Joseph Mulhall — Mon, 20 Jun 2005 05:21:00 GMT

Disclaimer: I'm working as a SQL Security consultant and SOX is one of the issues I have to cover.

"One would think that the best people to commit fraud and misuse of data would be the ones who designed or maintained that system."

I've modified your statement to point out the obvious...

Dual control and segregation of duty may well be new phrases in the DBAs handbook, but really these are standard ideas that have been around for years in IT.

I'm always quite suprised by the vehemence that people insist they need godlike access to do their jobs, when usually it's ignorance that leads to the use of SA or Local Administor.

With some work and the right processes SOX compliance can be achieved without preventing people from doing their jobs. IT often suffers from a lack of processes, which makes everyones jobs harder.

RE: No DBAs allowed access to Production DB Servers...

Martin D. Cymerman — Mon, 16 May 2005 13:12:00 GMT

I hate to admit it but your Director is on the right path. If you are a developer and the DBA, SOX dictates that you cannot have full access to the production servers. IF you were just the DBA, and not a developer, that would be different. In my case I was put at the lowest common denominator, the developer or Operations Group, yet I’m still the DBA. If I need anything done to the production servers I need to submit in writing to the IT group what is needed and I will either receive a “Key” with a unique login/password to use on the particular sp/table I will be working with or I will sit with someone from the IT group and walk them through what is needed.It has called for a total revamp of our IT strategy by replicating to test servers and “duel” production servers. In six months I have not encountered any major problems just some small ones to my ego.Hope this helps.Marty

RE: No DBAs allowed access to Production DB Servers...

David Thayer — Tue, 19 Apr 2005 15:49:00 GMT

I would have to agree that it's best not to allow developer DBA's access to the production server, however, many shops are too small to have this restriction. How about spending the money that's being spent on an auditor for a new DBA???