March 17, 2010 at 11:23 am
My situation is a funny one in that I release develoeprs scripts to the test and prod servers, but those developers still do have access to those servers for fault finding purposes.
I now need to give developers specific permissions based on an audit requirement rather than the blanket "ok for most things" I have given them.
What is the best practise for me to provide such a security model? I can't be going in and setting permissions on a role per object at this stage in the servers life as there are thousands of objects.
Any advice?
Thanks
Shark :hehe:
March 17, 2010 at 11:26 am
You can set permissions on schemas if that's what you need.
It sounds more like you should deny the ability to create/modify/drop objects and just put the devs into roles that allow reading, and writing data, and executing stored procedures.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 17, 2010 at 12:14 pm
As mentioned previously, schema tend to be the way to go, although we usually grant VIEW DEFINITION at the database level for our developers to be able to see the underlying T-SQL for any object.
Is there anything else out of the ordinary that you need to do?
K. Brian Kelley
@kbriankelley
March 29, 2010 at 1:40 pm
K. Brian Kelley (3/17/2010)
As mentioned previously, schema tend to be the way to go, although we usually grant VIEW DEFINITION at the database level for our developers to be able to see the underlying T-SQL for any object.Is there anything else out of the ordinary that you need to do?
Yeah, I'm planning on doing that for some databases I've recently inherited. The developers get dbo access in the development, then View Definition only for test\prod.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply