We see many instances in which the SQL DBA for SharePoint is the same as the SharePoint administrator, which also happens to be the same person as the security admin, and the support staff, and the etc., etc., etc.
Even though we see these roles blended for various reasons (lack of understanding of the importance of having role separation, not enough money to hire people, not planning the production deployment completely), SharePoint does actually have strong role separation by default. “Role Separation” means that administrators of one piece, tier, or component of the system may not necessarily need administrative access to other pieces, components, or tiers.
This is a valuable consideration for security and for stability. For example, you likely don’t want your enterprise domain administrators to have access to the CEO’s mail. For stability, your SQL DBAs probably don’t want the windows administrators manipulating SQL configuration settings. The same is true for SharePoint… having access to administer the SharePoint farm doesn’t necessarily mean a user should have access to the content within that farm.
So, if you were to design a team with complete role separation (assuming you have enough people to cover each role discretely), what might the team look like and what roles would they have? Here’s my list…
All of the roles above are System or Application roles… that is, none of them necessarily have a direct impact on content (with possible exception of web application policy)… but more importantly, none of the roles above are stored with content. If your farm needs to be rebuilt, the above permissions would all need to be rebuilt also.
The roles below are arguably content roles… that is, roles that have a direct impact on content, are visible in the users/groups lists in site collections, can and frequently are managed directly by users, and most importantly, are stored in the content database. Though it may be tempting to attempt to rigorously control these (and there are good reasons to do so), these are more likely best distributed throughout the organization and are frequently managed by people outside of the farm administrators group.
The most important points in the above lists are that the roles can be very, very discrete. For example, being the DBA does NOT mean you have access to content in the UI. Yes, it is possible for you to override this… but such an override would generally be visible in the system, either to farm administrators or to users.
As with most security systems, there is (by design) a mechanism for overriding security. For example, it may be reasonable for farm administrators to add themselves to the web application policy for specific investigation purposes… but in a well managed environment, these rights would generally not be required. However, this possibility means that regularly auditing those roles to ensure they haven’t been misused is an excellent activity. Such audits should NOT be scheduled, but should at random intervals, but should still occur with some amount of regularity.
Technically, there are many more distinct roles. For a complete list, look here: Plan for security roles (Office SharePoint Server)