Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««34567»»»

No DBAs allowed access to Production DB Servers... Expand / Collapse
Author
Message
Posted Friday, June 22, 2007 1:24 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 5:14 PM
Points: 35,266, Visits: 31,756
Then there's THAT   Works almost everytime...

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #375986
Posted Monday, June 25, 2007 12:29 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, December 9, 2008 2:30 PM
Points: 1, Visits: 2

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

 

Post #376198
Posted Monday, June 25, 2007 7:23 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Sunday, October 6, 2013 9:36 AM
Points: 568, Visits: 309

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!

SJ




Accepting all invites
Post #376260
Posted Monday, June 25, 2007 7:34 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, September 19, 2014 9:21 AM
Points: 153, Visits: 399
  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.


Post #376267
Posted Monday, September 24, 2007 9:23 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Thursday, September 18, 2014 11:10 PM
Points: 4,573, Visits: 8,351
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.
Post #402342
Posted Tuesday, September 25, 2007 7:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, September 19, 2014 9:21 AM
Points: 153, Visits: 399
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. 


Post #402561
Posted Tuesday, September 25, 2007 7:59 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 5:59 PM
Points: 31,082, Visits: 15,529
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #402575
Posted Tuesday, September 25, 2007 3:54 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Thursday, September 18, 2014 11:10 PM
Points: 4,573, Visits: 8,351
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.
Post #402769
Posted Tuesday, September 25, 2007 11:13 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, June 3, 2013 9:53 PM
Points: 433, Visits: 619
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



Post #402860
Posted Tuesday, September 25, 2007 11:54 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 5:14 PM
Points: 35,266, Visits: 31,756
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

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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #402864
« Prev Topic | Next Topic »

Add to briefcase «««34567»»»

Permissions Expand / Collapse