SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


SQL DB Server Access Levels for Programmers


SQL DB Server Access Levels for Programmers

Author
Message
jgaitu
jgaitu
SSC Rookie
SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)

Group: General Forum Members
Points: 36 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?
Suresh.Utham
Suresh.Utham
Mr or Mrs. 500
Mr or Mrs. 500 (530 reputation)Mr or Mrs. 500 (530 reputation)Mr or Mrs. 500 (530 reputation)Mr or Mrs. 500 (530 reputation)Mr or Mrs. 500 (530 reputation)Mr or Mrs. 500 (530 reputation)Mr or Mrs. 500 (530 reputation)Mr or Mrs. 500 (530 reputation)

Group: General Forum Members
Points: 530 Visits: 216
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
foxjazzG
foxjazzG
SSC-Addicted
SSC-Addicted (467 reputation)SSC-Addicted (467 reputation)SSC-Addicted (467 reputation)SSC-Addicted (467 reputation)SSC-Addicted (467 reputation)SSC-Addicted (467 reputation)SSC-Addicted (467 reputation)SSC-Addicted (467 reputation)

Group: General Forum Members
Points: 467 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.
jgaitu
jgaitu
SSC Rookie
SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)SSC Rookie (36 reputation)

Group: General Forum Members
Points: 36 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.
Glenn Dorling
Glenn Dorling
Hall of Fame
Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)

Group: General Forum Members
Points: 3540 Visits: 926
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).
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search