Re: Developer Permissions -vs- SQL Server Managability
From: Dan Guzman (danguzman_at_nospam-earthlink.net)
Date: 06/08/04
- Next message: Kenneth: "IIS and SQL server securities"
- Previous message: Andrew J. Kelly: "Re: CHanging default listing port sQL 7.0"
- In reply to: DBADave: "Developer Permissions -vs- SQL Server Managability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 7 Jun 2004 20:42:00 -0500
We basically use option 2. However, all of our scripts are kept under
source control and we use those scripts to promote objects to QA and beyond.
Developers are given access to non-dev boxes only for troubleshooting.
One of the nice thing about the source control approach is that this
provides full auditing of changes and version history. Furthermore, source
control provides a good focal point for related processes, like code
reviews.
-- Hope this helps. Dan Guzman SQL Server MVP "DBADave" <anonymous@discussions.microsoft.com> wrote in message news:B799B132-855A-4D21-934A-FF1030D82964@microsoft.com... > I am faced with a situation where a group of web developers, with basic t-sql skills, periodically develop/modify database objects on a development SQL server that the DBA team manages. The developers insist on having the ability to create/change database objects at will, but also want to be able to test database access via their web-app front-end withoiut having to ask the DBAs to switch DB object ownership from the individual developers that created the objects, to DBO, and without having to specify permissions. Having been a DBA for years, I see the obscurity of this requests and the reprecussions of it, but due to circumstances beyond my control, I need to identify a process that will help them develop and test, but also want to maintain a secure environment where I can track DB changes. > > Below are two proposed solutions. I am interested in hearing from seasoned DBAs that have encountered this situation and am interested in hearing which of the below two choices you would choose - or what other process you used to solve this dilemma in your environment: > > Option1 > - All Developers login to the dev sql server with a generic sql account (ex: DevTest) > - The DevTest account has dbo rights to the respective development databases > - While in the 'development' stage, the web developers have the web-app front-end connect to ths DB via the same devtest UserID > - The above would allow dev to create/modify objects and execute/reference objects without object ownership chaining issues > - Once this DB goes from the Dev to QA phase, the DBA team changes all object ownership to DBO and sets the DevTest UserID to db_datareader rights only > > Option2 > - The Dev team is granted sysadmin rights to the Dev SQL box, granting them the ability to create objects as DBO > - The above would allow dev to create/modify objects and execute/reference objects without object ownership chaining issues > - Once this DB goes from the Dev to QA phase, the DBA team restricts sysadmin rights and permits the Dev team to have the db_datareader rights only > > Of the 2 options, Option2 makes my stomach cringe, but I am interested in hearing which of the 2 options you use, or if there is a better process or policy that you use that allows developers to work somewhat autonomously, while still giving the DBA the ability to manage the SQL server itself. > > Thanks in advance for your assistance! >
- Next message: Kenneth: "IIS and SQL server securities"
- Previous message: Andrew J. Kelly: "Re: CHanging default listing port sQL 7.0"
- In reply to: DBADave: "Developer Permissions -vs- SQL Server Managability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
