Do you allow developer to access Production Server

  • I am the SQL DBA & a developer as well ..

    I am currently trying (without success) to lockdown all our SQL servers.. however

    Everytime I restrict developers to read only they go and unrestrict themselves by using their domain admin password.....!!!!!

  • andoi,

    What are developers doing with a domain admin password?

    To stop NT admins playing with my sql servers I remove the builtin/administrator from the sql admin group, hence they can't change anything on the sql server using there domain admin accounts. Doesn't stop them changing my password if they really wanted to, or using the sql server account password but it does seem to work.

    Steven

  • quote:


    To stop NT admins playing with my sql servers I remove the builtin/administrator from the sql admin group, hence they can't change anything on the sql server using there domain admin accounts. Doesn't stop them changing my password if they really wanted to, or using the sql server account password but it does seem to work.


    If you can't trust your domain admins, I think you'll have more serious problems than plaing around with some SQL Servers

    Frank

    Wenn Englisch zu schwierig ist?

    http://www.insidesql.de

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • Trust, yes

    But in my instance it is more about reducing the number of accounts that could do things (reducing the attack vectors, as such). Its easy enough if you do it when the server is build ie in the build notes. If a domain admin wanted to do something, you could not stop them.

    The main point is why would developers have a 'domain admin' account, and in andoi case they are giving themselves permissions where they have been previously evoked. How could you trust someone who does that?

    Steven

  • quote:


    The main point is why would developers have a 'domain admin' account, and in andoi case they are giving themselves permissions where they have been previously evoked.


    - convenience

    - laziness

    - habit

    - ....

    quote:


    How could you trust someone who does that?


    One way could be, to make sure you're in a better physical shape than the developer(s). And speaking out the threat of meeting after work.

    Frank

    Wenn Englisch zu schwierig ist?

    http://www.insidesql.de

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • Same old problems all over the world. Powerplay, echo trips, etc.

  • quote:


    Same old problems all over the world. Powerplay, echo trips, etc.


    heyhey, the next guru's waiting for give an audience

    Frank

    Wenn Englisch zu schwierig ist?

    http://www.insidesql.de

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • Developers should be given complete access if they are competent. In my experience I have worked with many developers whom had more knowledge of SQL than the DBA's supporting. DBA's become a bottleneck in a busy shop.

  • Some developers may have better knowledge of the data/application as they generally wrote it, hence may the best best people to support the data.

    But changes need to be controlled, tested etc. hence access generally has to be restricted.

    It depends on the shop and resources, on how this works in practice.

    Steven

  • quote:


    Developers should be given complete access if they are competent.


    uhoh, turns out to be a yase of

    'It depends....' thread

    Frank

    Wenn Englisch zu schwierig ist?

    http://www.insidesql.de

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • It depends ........

    No honestly I agree with the fact that many developers are more knowledgable than the DBA (Hence I am both).

    But the fact remains that 'Ignorance is the mother of all f**k ups' and a little knowledge can go a long long way. I try to educate those who are interested but there are too many people who like to dabble without wanting to understand what they are doing.

    I also try to disuade developers from using LIVE data in their test systems as this is a minefield as far as the Data Protection act is concearned.

  • I'm battling with this myself....

    There are several issues that may arise, and to some extent 'it depends'. Personally, I'd lock them with select and SP execute permissions where it involves data reading only - no excuse for extras. Realistically, its not possible. The smaller the IT team, the harder it is to 'lock out' as you always need backup skills for when you're not there. At the end of the day, its handled by 'contractual' details to limit what they can do. Everyone knows that anything DB related on production servers come through me and me alone - fine if I'm around and not away on hols.

    BUT, having just come back after two weeks off, I discovered that someone had been developing their SPs (mods of existing ones) ON THE PRODUCTION SERVER, and to limit the result sets, they modified the existing ones directly (to do TOP 50s as it happens). Needless to say, you will (if you listen carefully) hear the satisfying thud of leather on ass of the individual concerned

  • quote:


    if you listen carefully) hear the satisfying thud of leather on ass of the individual concerned


    This is alright if you are in a position of Power and have the ability and authority to kick some ASS...

    OR

    If you are in a Company where they take things like this seriously...

    I am neither but am trying to work with the Server Administrator to move all of the Development Servers on to a trusted domain thus meaning that we can alleviate some of the costs os licenses by utilising our MSDN Subscriptions... Also we can further lock down access to the Live environment

    Where do your developers reside within your network infrastructure???

  • Our developers are allowed the same level of access to the production data as our users. They are not, however, allowed to alter the structures within the production database -- we have development & test databases for that. And it's bad enough keeping them from making changes in Test without making them in Dev first at times...

    Thomas Rushton
    blog: https://thelonedba.wordpress.com

  • We are currently having a debate with or .NET developers. They NEED full access to all data and proc's at all times in all environments . I believe however that it is more down to being younger and less experienced.

    It is not a case of don't trust a developer, but more been there got the T-shirt, having deleted data by accident when being too tired or getting distracted.

    I have implemented a 3 environment structure (Dev / QA-Rollout and Production)

    .NET Developers have Full access to dev and have read access in QA and Production.

    The database objects are all managed/developed by my SQL Team and only the DBA and deputy have full access to QA and Production.

    The battle is nearly won and this is being accepted as reasonable strategy by all.

Viewing 15 posts - 16 through 30 (of 31 total)

You must be logged in to reply to this topic. Login to reply