SharePoint Security Standards
Back To All SharePoint Standards
What follows are merely suggestions as a starting point for defining your SharePoint security standards. Realistically your standards might vary quite a bit depending on your SharePoint usage, size, staffing, compliance regulations, and more.
- Word (Docx) Version: SharePoint Security Policy
- Excel (Xlsx) Version: SharePoint2010_Permissions_Matrix
The most important thing when planning for and supporting security is that there are always exceptions which lead to pros and cons. These are however practices that should be followed and is a good starting point for your own security standards.
Environmental Security Standards
- Separate accounts must be used for different services and processes.
- No executing service or process account may be running with local administrator permissions.
- In a two-server or more deployment, the Central Administration site should be hosted on a different server than the front-end Web server, where possible.
This can only be accomplished if application server roles are hosted on a different server than the front-end Web server role. For example, if Server A hosts the front-end Web server role and Server B hosts the database and application server roles, the most secure location for the Central Administration site is on Server B. However, if Server A hosts the front-end Web server and application server roles and Server B hosts only the database role, the only option is to host the Central Administration site on Server A. - Configure the Central Administration site to use SSL. This ensures that communication from the internal network to the Central Administration site is secured.
Content Security Standards
It is worth noting here that by following techniques around ownership, and effective site, library, and folder provisioning/usage you will significantly improve SharePoint security in an indirect way. If you follow the Content Standards it should help ensure clearer communication, understanding, and better usability/manageability.
- Customizing item level permissions should be avoided whenever possible.
- Assigning individual user permissions should be avoided whenever possible.
Group and Permission Management
- Each group must have a clear description which lists it’s purpose and the reasoning behind it’s creation.
- Create a custom group when:
- You have more (or fewer) user roles within your organization than are apparent in the default groups. For example, if in addition to Approvers, Designers, and Hierarchy Managers, you have a set of people who are tasked with publishing content to the site, you might want to create a Publishers group.
- There are well-known names for unique roles within your organization that perform very different tasks in the sites. For example, if you are creating a public site to sell your organization’s products, you might want to create a Customers group that replaces Visitors or Viewers.
- You want to preserve a one-to-one relationship between Windows security groups and the SharePoint groups. For example, if your organization has a security group called Web Site Managers, you might want to use that name as a SharePoint group name for easy identification when managing the site.
- You prefer other group names because it adds clarity/improves the groups usability/applicability.
- If the default groups are not being used remove them from the SharePoint site to improve group management and mitigate incorrect group assignment.
- You should not customize the default permission levels.
- A valid alternative is to create a copy of a default permission level and to modify the copy.
- You should create new permission levels (using the method above) if:
- You want to exclude several permissions from a particular permission level.
- You want to define a unique set of permissions for a new permission level.
References
- Security Planning for Sites and Content (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/cc262939.aspx
- Office SharePoint Server Security Account Requirements (2007) http://go.microsoft.com/fwlink/?LinkID=92883&clcid=0x409
- Plan for Administrative and Security Accounts (2007) http://technet.microsoft.com/en-us/library/cc263445%28office.12%29.aspx
- Harden SQL Server for SharePoint Environments http://technet.microsoft.com/en-us/library/ff607733.aspx
- Plan Security Hardening (SharePoint 2010) http://technet.microsoft.com/en-us/library/cc262849.aspx
- Plan Site Permissions http://technet.microsoft.com/en-us/library/cc262778.aspx
Am I missing a security standard? Don’t agree with one? Please let me know in the comments.
Hope this helps,
Richard Harbridge
{ 1 trackback }
{ 3 comments… read them below or add one }
Hi Richard, SharePoint permissions are so often the bane of my professional life. I’ve devised and implemented more security models than I care to remember, and written enough end user FAQs and guides to last me a lifetime, but while I always adhere to the guidelines you’ve documented above under Content Security Standards, I often encounter clients who won’t take “don’t” for an answer and are determined to roll out Fine Grained Permissions for all their documents. I wave Microsoft’s Best Practices guide to SharePoint security about, plus a few of my own documents (with case studies and lessons learned), but it rarely dissuades anyone. How / why do you encourage your clients to avoid item level security, and what are the circumstances, if any, where you’d advise them to countenance it?
Lynn
Hello Lynn,
Excellent question. Honestly there is nothing wrong with fine grained permissions if they are using code and the right code. Specifically the code: SPRoleAssignmentCollection.AddToCurrentScopeOnly which reduces some of the biggest performance challenges.
The problem is that when people do make many changes with fine grained permissions they don’t write carefully tested code, and they don’t consider the administrative implications and overhead that decision will cause. I have a horror story (though I can’t name who it was) where one company had implemented fine grained permissions all over several very large document libraries and to this day they are unable to perform simple things in SharePoint (like adding a group to a permission set on an item as it will result in a time out) and not even third party products can help them (as the big administration products take over 20 hours to load and then when they do, they actually crash or often time out when they perform operations). So sometimes a horror story can help.
The administrative burden is quite large, but the performance implications (and issues it can cause when you reach ACL limits etc) are the real danger. Administrative costs are often seen as ‘risks’ which the decision makers don’t truely understand because they don’t manage permissions and performance ones are very real risks that can more or less effectively shut down or limit an environment. So I normally focus on the performance risks more than the administration risks.
One trick I have learned is that if you can actually have the individual manage permissions for a little while, they will understand the administrative overhead very quickly, and will also understand the importance (in many cases) of buying a third party tool to help. 🙂
Hope this helps,
Richard
Hello Richard,
Excellent write-ups on standards; I will be referencing your ideas for my clients (and obviously pointing to your site and giving you credit)! For creating custom permission levels, I would add:
– Create a custom permission level only if there is a clear business case outlining the exact need which cannot be accomplished in another manner.
– Don’t modify a custom permission level after implementation without knowing if/which communities are using it.
– Provide business notification/education on the custom permission level implementation to the entire organization on how it can be used universally.