No DBAs allowed access to Production DB Servers...
-
I am curious to know what an auditors thoughts are on what a company should do when there are only 2 individuals qualified to be Database Administrators and both of these people are also responsible for internal application and development.
What is your definition of database development?
In my case our company is to small to have a dedicated database administrator, let alone a secondary support person that will cover him/her while they are on vacation.
In our company this person would be bored because it would only be a 8 hour a week job, on average. Now there is more than enough work for 2+ programmers.
Whats better, having an experienced DBA or some secretary who just inherited a new title so that we can maintain separation of duties on paper.
-
We're just about thru the Sarbanes prep. It has been a nightmare. DBA's no longer have the 'sa' password - we're not supposed to have access to the production system (financial apps, Solomon on one server, Epicor on another) - when we do need access, we have to call someone with a special user and password, do our thing, then call them back so they can change the password. The first day, we changed the password 4 times! There has to be a better way. The thing I disliked most about the audit is how the auditors make you feel. I got the impression that it was dangerous for me to know my databases inside and out, and that they would have been happier had I been some clueless accountant fixing things thru MS Access. What Sarbanes does is makes life harder for honest companies. For those who want to cheat, they are still going to find a way. I guess the upside is that it gave a temporary respite to all the auditors who lost their jobs because of Enron, Adelphia, etc...thanks for letting me vent!
-
Most interesting.
One would think that the best people to prevent fraud and misuse of data would be the ones who designed or maintained that system.
Although none of us are infalliable I would much prefer a professional to look after my data and it's structure than handing over access rights to a potential target.
I couldn't imagine working effectively in an environment like that, but I suppose it depends on how much you paid me...
Integrity and honesty, do only lawyers and auditors have it?
Max
-
This whole thing seems like a big money making raquet for a select industry. Companies like Price Waterhouse Cooper are making money hand over fist charging companies to do audits. This whole undertaking is supossed give investers the confidence to back companies that have been certified and passed the SOX audits. The goverment has not enacted any audit passing requirements. In fact the goverment has no SOX auditors. This whole thing is suspect as best! If you saw the cost and resources companies are throwing at SOX you might think twice about investing in these companies
-
... Integrity and honesty, do only lawyers and auditors have it?
really ?
* Noel -
It scared me to think that sys admin has sa password and is the key keeper in your case.
I do respect what sys admin does and how much stuff they do. They can fix server but they can't fix my sql server. I think they can kill my sql server then fixing it.
So here is my though: for small company. We might have DBA/Developer doing some work that overlap because there is not enough resource.
In medium company where you have more then 10 developers, you have DBA that is responsible for production and development environment.
In large company, you have Production DBA, Development DBAs / Database owners (dbo), and end users.
In this case end users has no right to modify any structure. They also has a gui tools provided to them to look at data, or enter data.
Database owner/development DBA give access to user.
Production DBA create logins.
Production DBAs put the SQL Service pack, install SQL and does other works related to the server.
System Administrator has no access to SQL Server
They could however work on the server to add more disk space or put the latest windows service pack.To sum up, I have worked in all the small, medium and large company.
mom
-
I work in a smaller IT consulting firm, and they tried the SOX lockdown where no developers were able to access the prod system unless they were added to the rollout group, which was in the Prod Servers administrators group andhas sa power on the production database.
That lasted maybe about 3 weeks, and the keykeepers (here it is the Network Folks who are the key keepers) were tired of being called at 2 or 3 am when we needed to do a rollout. At that point they "accidentally" gave us the local administrators account password for the prod machines, and they sleep much better now.
Give it time - stupidity like this is usually self solving.
Tim Blum
Senior Manager, Outsourced Data Services
Learn2Live at Ureach.com -
Yes, it is a bad idea. But don't say it is, don't worry and let the game be played. Like most of the responses here, it will naturally change back to what works. For me, it finally boiled down that the only requirement change was to log everything that a DBA did on a production Server, now that makes sense.
Dan
-
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???
-
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
-
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.
-
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.
-
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.
-
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...
-
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.
Viewing 15 posts - 16 through 30 (of 62 total)
You must be logged in to reply to this topic. Login to reply