Who should have Sysadmin rights?

  • Comments posted to this topic are about the item Who should have Sysadmin rights?

  • I have been using the login as a different user for a few years now. s you are running with a different user you have a different profile. I use that to change the color scheme of my sql management studio so that it is very apparent in that I have more privileges in this environment.

  • We have a set of firecall IDs, governed by a change management system, that have the necessary rights in production/DR. You can retrieve the password and log in with the firecall only if you have an approved change number or a high-severity incident ticket number. You cannot use these accounts in your day-to-day business.

  • Seems to me that a user should have access with minimum privileges through standard login, and a separate unique account with elevated privileges.  No one should share an account, unless there's some way to limit use of that account to one person at a time and track which person had it for how long - with a new, time-limited password for each request.  Otherwise it would be difficult to tell who used the SysAdmin account to drop the production database.

  • Len.Geoghegan - Monday, March 11, 2019 7:18 AM

    Seems to me that a user should have access with minimum privileges through standard login, and a separate unique account with elevated privileges.  No one should share an account, unless there's some way to limit use of that account to one person at a time and track which person had it for how long - with a new, time-limited password for each request.  Otherwise it would be difficult to tell who used the SysAdmin account to drop the production database.

    Totally agree. I would have normal logins for everyone, then have specific admin accounts for each person that's accountable for admin access. Sharing an account, especially administrative accounts, allows too much anonymity and doesn't hold each individual accountable.

  • Agree with minimum necessary privileges, but also, in order to avoid accidentally modifying prod instead of dev / test, I find it's useful to use Register Server in SSMS and assign a different status bar color or color family to each sever, depending on the environment. My prod servers have a red status bar -- caution, do not make changes unless deploying; test is orange (since yellow is the default); dev is green.  A server that doesn't neatly fit these categories might be cyan.  It's not a foolproof system -- assigning colors per DB instead of per-server would help me -- but combined with moving the status bar to the top of the widow, it makes it very easy to know at a glance which server the current SSMS tab is connected to.

Viewing 6 posts - 1 through 5 (of 5 total)

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