No public Twitter messages.

SharePoint 2010 Security Best Practices for Mortals

When working with new SharePoint clients one of the struggles we encounter is how to assign users to the proper security groups.  In most cases, we recommend providing access based on site security.  By providing access at the site level you are better able to maintain and predict site usage.  Of course SharePoint will allow you to further refine permissions all the way down to the item level such as to a document or a list item.  We strongly urge clients away from such practices; however there is always a business case that will demand this type of security thus the functionality has been provided by Microsoft.

Security best practices in SharePoint can vary depending on who you ask.  That being said, we have our own best practices that we follow and recommend to clients on a daily basis.  Here are our Security Best Practices for SharePoint 2010.  Again, these are best practices for most businesses cases and will not cover every possible business need.

  1. Always assign users to Groups. By assigning users to SharePoint groups you can predict what a specific user is capable of doing without auditing their security profile.  If you use a hybrid with Active Directory then create SharePoint groups and assign AD groups to the appropriate SharePoint group.
  2. Do not break site inheritance at the object level. Breaking permissions at the object (list or Library) level can lead to a lot of confusion and frustration.  Assign a user to the proper security group and let it be.  If the library or list contains sensitive data create a child site and assign group permissions accordingly.
  3. Need-to-Know assignments. Only assign people to sites where they NEED to have access.  If somebody can demonstrate the need, then assign them to a group that is associated to the access of their need.  In most cases, if a user cannot justify being in a contributor group they probably shouldn’t be on the site at all.
  4. Try like Hell not to assign document level permissions.  Assigning permissions at the document level is a maintenance nightmare.  If necessary, create additional libraries or sites before breaking the security of a library or list.  You can break permissions, but you will be sorry.
  5. Viewer Groups, never liked them.  At times a viewer group can be useful, however in most cases they are not.  This becomes even more relevant the further you drill down into a site.  If you are assigning a user to a project site as a “Viewer” you have to ask yourself… “If this person is on the project, why can’t they just contribute?”  If they can’t contribute, should they even be able to view the site to begin with?  In most cases the answer is no.
  6. Taxonomy Structure for group names.  Create a structure that makes sense and is easy to understand.  We recommend the following:
    1. SiteName_Viewers
    2. SiteName_Contributors
    3. SiteName_Owners

When there are child sites we often use the following:

SiteName_SubSite_ where is Viewers, Contributors or Owners.

The trick in creating SharePoint group names is that by viewing all groups in the farm you should be able to identify where a group is used without racking your brain.

We have also attached a free Permissions Template that you can use within your organization.  We recommend sending this template to perspective site owners so that they can think through who will have access to their sites as well as what level of access would be most appropriate.  Enjoy!

SharePoint Permissions Template


Admin -

Leave a Reply

Recent Tweets

    No public Twitter messages.

Top Rated