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

SQL DB Server Access Levels for Programmers Expand / Collapse
Author
Message
Posted Sunday, October 19, 2008 8:19 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, March 22, 2009 6:24 PM
Points: 2, Visits: 7
My Organisation have a SQL Development Server, Test SQL Server to test Databases and a Production SQL server.I'd like to have programmers to have all the access levels on Development server but certain access level on both Test and Production server.

My question, is there a guideline or policy for Programmers to have certain access to Test/Production servers?
Post #588351
Posted Wednesday, January 21, 2009 2:09 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, August 26, 2014 8:30 AM
Points: 354, Visits: 209
As per general Industry standards, Programmer (DEV team) will have only READ access to System Testing / UAT / PROD / DR Servers.

DBA & Release Management team should be contacted for getting Special / Specific permission in any of the Server / Environment(s).


Suresh
Post #640505
Posted Saturday, March 14, 2009 11:02 PM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Friday, April 4, 2014 3:57 PM
Points: 159, Visits: 317
Well, I am a programmer and I have sa in both test and production.

I guess it just depends on the programmer.

Our db's aren't part of the sarbanes oxly fold.

For those, I think programmers can't have write access in prodution.

Post #676053
Posted Sunday, March 15, 2009 6:46 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, March 22, 2009 6:24 PM
Points: 2, Visits: 7
Thank you very much.

I'll be taking all your advice into consideration when writing up a guideline for our programmers and DBA's.

much appreciated.
Post #676204
Posted Sunday, March 15, 2009 7:28 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, October 28, 2014 4:14 PM
Points: 2,087, Visits: 875
This is one of the things I loathe about SOx and all the other audits I've had to deal with. I've never been given a document saying "this is what you have to comply with": instead it seems they invent things to whinge about each time a new audit rolls around. I'm Australian, so we don't have to stick to things like HIPAA and PCI DSS (we deregistered ourselves from the NYSE because of SOx, which I believe is becoming quite common for non-US companies), although we do use them as guidelines: it's all the additional "best practices" that crop up each new audit that peeve me.

Anyway, what we do for the systems that qualify as SOx systems (even though we don't try explicitly to stick to SOx et al) is:
- Support staff have read access to prod and prod-copy (unscrambled) support systems
- Developers have dbo rights to scrambled dev and System test systems
- Developers and business analysts have read-only access to "higher" test systems (eg. UAT, Int Test, OAT), which are also scrambled
- Regression Test, P&V & QA systems require business sign-off to refresh and users to have (read-only) access to those are defined by the business before each round of testing.

It's the last group of systems that causes the greatest effort as the users need to be set up each time.

NB. Data scrambling is included as part of our automated test system refresh routines. The refresh needs to be done manually by specific people if the data is not to be scrambled. We have full segregation of duties, so people who are identified as support staff do not have access to dev/test systems and, most importantly, dev/test users do not have access to prod/prod-copy systems (although there is a process for them getting elevated rights in the event of a production incident).
Post #676208
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse