September 25, 2007 at 7:35 am
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.
September 25, 2007 at 7:59 am
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.
September 25, 2007 at 3:54 pm
alex abenitez (9/25/2007)
I think you just missed the whole point!Sox is not the problem here
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!
It's just a good quality check!
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.
_____________
Code for TallyGenerator
September 25, 2007 at 11:13 pm
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
September 25, 2007 at 11:54 pm
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.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2007 at 10:24 pm
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/
October 2, 2007 at 10:29 pm
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?
October 4, 2007 at 2:59 am
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.
October 4, 2007 at 7:27 am
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:
October 4, 2007 at 7:30 am
if the customers are not happy, and / or you are unable to do your job, then Sarbanes-Oxley has succeeded. 😀
October 4, 2007 at 7:36 pm
Ninja's_RGR'us (10/2/2007)
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?
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?
_____________
Code for TallyGenerator
October 5, 2007 at 11:29 am
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.
maddog
October 7, 2007 at 4:12 pm
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?
_____________
Code for TallyGenerator
October 11, 2007 at 1:22 pm
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.
October 11, 2007 at 2:11 pm
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 😀 ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
Viewing 15 posts - 46 through 60 (of 62 total)
You must be logged in to reply to this topic. Login to reply