July 27, 2006 at 9:13 am
I'm trying to finalize my service account standards for SQL Server 2000 and 2005. Here is what I have. Does anyone have comments on these standards:
Standards for setting up SQL Server service accounts:
· Set up a different domain account for each service if network resources are needed. If no network resources are needed then a local account should be set up for those services that no not need network resource. Justification: This allows rights to be assigned differently depending on the service. Also allows for better audit trail of determine where commands are coming from. Also minimizes security risks by only allowing network resources to those services that need them.
· Give each domain account only the network permissions they require. Justification: Minimize security risks. Service accounts only need the necessary permissions to perform the actions required for the service. Any additional permission opens the door for a service to gain access to resources they should have.
· Each domain account should be set up with a password that never expires, although DBA’s should develop procedures that periodically change the passwords for these service accounts. Justification: You don’t want service accounts to stop working because a password expired. But you do want to periodically change the password to minimize security risks associated with never changing passwords.
· Do not place the domain account of a service into the local Administrators group. Justification: Minimizes security risks. Giving a service account local Admin rights increase the risk of someone exploiting the service account to gain access and/or grant permissions to machine resources without authorization.
· Do not place a service account into a local group, or domain group. Justification: Minimizes security risks. Placing a service account into a group implies that two services would have the same rights. The idea of having separate accounts for each service is so rights can be assigned specifically to what a service needs. Placing a service account into a group would defeat the goal of having specific right for a given service.
· Revoke ”interactive login” permission for each services account. Justification: This will keep people from using this account to login into server. If you need to login with the service account for setup purposes (such as to set up the Outlook Client) then these right should only be grant temporarily while you are doing the setup.
Gregory A. Larsen, MVP
July 27, 2006 at 9:54 am
I think in an ideal world you've just about hit it on the head and tied in with security permissions on the file system would be good.
However, real world often requires servers to talk to each other, thereby placing service accounts in common groups and placing the DBA's in these groups is good. ( I'd ideally want to disable builtin admins group on each server )
Depending upon the work your server needs to do you may find yourself with a heavy workload. Where there are maybe several hundred servers common policies can be good but often servers need to talk to ftp sites, the file system, middle tier servers and so on.
Although I totally agree with your proposals I figure it would never work in any of the production environments I have supported over the last 12 years.
You need to include disabling builtin admins and file system permissions to your list, and protecting/disabling the sa account.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 27, 2006 at 12:35 pm
Colin, thank you for the feedback. I have a comment and a question regarding your post.
I suppose to make system administration easy having all service accounts in a windows group does simplify administoring permissions. I can see having a group where the permissions associated for the group would apply to all service accounts place in that group. Therefore I have reworded my standard around groups as follows:
· Only place service account into a local or domain group if the service account needs all the permissions associated with the local or domain group. If the service account needs does not need all the permissions of an existing group then create a new local or domain group with the specify permission needed. Justification: Minimizes security risks. Placing a service account into a group implies that two services will need exactly the same rights that are associated with the group.
Hopefully this would minimize sys admin work to set up a service, because now a group or multiple groups could be used to manage services that need similar access.
Qeustions: What do you mean "...it would never work in and of the production environments I have supported over the last 12 years."? Could you be more specific in why my standards will not work.
Gregory A. Larsen, MVP
July 27, 2006 at 2:34 pm
In some ways some of these forum posts would work better face to face !! still - I've tended to work where common groups of service accounts exist within a domain/AD group .. a good example being putting development, production, test server service accounts in a group ( each ) and the DBA's within the groups. hope that sort of makes sense.
One of the other issues is allowing an account for the DBA to use which allows administration of the SQL Server and the local hardware on the server - with builtin admins disabled this become tricky as you then need to add a seperate sysadmin account - the other issue is Clusters which are notorious for restricting permissions ( there's a number of kb articles titled " impeeding admins on a cluster " or soemthing.)
Linked/remote servers and DR replication etc. is easier to maintain if common server accounts exist - for a few servers it's fine but managing this across a few hundred?
Don't get me wrong I support you 100% but I dispair of the overall level of security I often see, notwithstanding third party apps which have to connect as sa.
It would be unfair to put into print any examples as they might infer criticism of past and present clients.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
August 1, 2006 at 10:50 am
Hah .. my moaning about lack of security has sparked an interest in security so your posting has come just at the right time!!
If we get to do this and I get some results I'll post back - I have the usual issues of almost the world and his/her partner as admins, apps logging in as sa/sysadmin, apps as dbo etc. etc.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply