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.

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

Am I missing a security standard? Don’t agree with one? Please let me know in the comments.

Hope this helps,
Richard Harbridge

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.
Print Friendly