SharePoint Document Security

From its early start in 2001, SharePoint has primarily been looked at as a document management system. Looking at SharePoint Online, which is part of Office 365, not much has changed today. However, a cloud version of SharePoint was a significant improvement from the traditional file servers. It provides superior features for storing, organizing, and finding your documents. 

The primary focus of this blog is how to secure your documents using SharePoint security rules. We will go over the out-of-the-box SharePoint features, how they work, and, most of all, what you need to do to avoid common pitfalls.

The Basics of SharePoint Document Security

SharePoint security is very flexible and allows you multiple choices of sharing a document among users. This plasticity is very useful as use cases may vary from company to company or from department to department. It allows faster collaboration while keeping your documents secure and accessible. 

The most important things to know are:

1. How to define the scope of the permissions – SharePoint permissions can be set from the top-level Site Collection, all the way down through specific Subsites, Document Libraries, Folder, or even a single Document. Permissions are inherited from parents, but you can break this inheritance at any level and assign different permissions to that object. All child objects from now on will inherit permissions from the current object.

SharePoint broken inheritance explained

2. Permissions are granted by assigning SharePoint Permissions Levels to users – SharePoint has about 30ish base permissions, they are very granular. To keep users from dealing with so many base permissions, but preserve the flexibility, SharePoint groups permissions into more straightforward Permissions Levels like Read, Contribute, or Full Control.

SharePoint security

 

3. Permissions can be assigned directly to users or two types of groups

  • Security groups originating from you AD (or Azure AD if Online) 
  • SharePoint groups

SharePoint groups are specific to SharePoint, and they are created and defined at the Site Collection level. If a group is granted permissions to a resource, all group members can access it. Security groups can be nested in a structure by putting the second group among the first group’s members.

How to Avoid Pitfalls of SharePoint Document Security

Now that you understand the basics of how it works, it is also essential to understand what not to do. There are two main problems:

Firstly, SharePoint has a limit of 50 000 unique security scopes per list. You cannot go over this limit, so be careful not to find yourself in a deadlock. It is also vital to know that even 5000 unique security scopes can adversely degrade your SharePoint page performance.

The second problem is that with the growing number of documents, it is harder to manage permissions changes over time. SharePoint lacks proper permissions reporting features, and even simple tasks like onboarding a new colleague can become very time-consuming. In the end, this can cause losing track of permissions, compromising your security, and even lead to breaches.

If this happens, your only way out might be third party tools such as SysKit Point. SysKit Point is an Office 365 governance tool that tracks who has access to what across a tenant and puts it in one report. It simplifies onboarding and offboarding by isolating all permissions that a single user has and manages their access in bulk.  

How to Plan SharePoint Permissions

The best way to avoid problems down the road is to create a governance plan. The plan should consist of defining an easy-to-understand and flexible information architecture. If you plan it right, your users will be able to access the content they need quickly, while you’ll be able to respect SharePoint limits and manage it easily as the content grows. 

I will provide you with a couple of simple rules you can follow while defining your own permissions plan. Read more about Office 365 access governance best practices in our recent post. 

Always Follow the Principle of Least Privilege

A user should always have a bare minimum of privileges necessary to perform his job. Be careful to whom you grant Admin rights and who has Full control permissions level on the entire site. Try to limit the number of those people from two to five. Another example is if a user needs read-only access, give him Read permissions level, and not Contribute.

Creating a Secure Folder

Try to use the permissions inheritance behavior to your advantage. You need to minimize the number of places with unique permissions. To accomplish that, break permissions inheritance as high as possible, either at a library or folder level. Think about the group of users that will be accessing the content and which permissions each group needs. Maybe you can group the content with the same permissions requirements into folders or even separate libraries. If you regularly break inheritance at a document level, you could encounter the previously mentioned issues with performance and management.

Use SharePoint Groups

Always try to use SharePoint groups if you have to use security groups, put them inside SharePoint groups. Just think of a simple use case where a new employee comes, and you need to assign them the same permissions as an existing employee. If permissions are assigned directly on various documents, you will need to identify and manage them in multiple places, which is frustrating and time-consuming. It is a lot easier to identify and copy group memberships between users.

Avoid Security Groups Nesting

Although security groups nesting sounds like a smart move, it can cause problems and even pose a security risk. There is no out-of-the-box reporting functionality to show which group members can access the document – it will just show you the names of those groups. You could end up with a very complex security structure and low visibility into who can access what.

Security groups nesting

Do Not Change Existing Permission Levels

Each site based on a template comes with a few predefined permission levels such as Full Control, Contribute, and Read. If, for some reason, they do not meet your needs, it is better to create a new level than to modify the default ones. 

For instance, you want your users to have the Contribute permission level, but don’t want them to delete files. In this case, the best practice is to copy the existing Contribute permission level and modify it to create a new Contribute without delete level. When users grant permissions, they can only see the permission level name. Having the permission level with the same name, but with different base permissions across various sites, could confuse users.

Conclusion

SharePoint permissions are very powerful and flexible. Without proper governance, you could find yourself in very deep water. Try to define your permissions governance plan as early as possible. Think about how you can effectively set up and manage permissions over time. Even if you set up everything correctly, you still might need some help to overcome the lack of reporting inside SharePoint. You don’t need to worry as we can help you out! SysKit Point, as we mentioned earlier, is an Office 365 governance and reporting tool. At the same time, SPDocKit is a SharePoint on-prem administration tool that manages and reports on permissions on your farm.

 

Want to read more posts from us? Subscribe to our blog and stay updated.

SysKit Point Schedule a Demo


Subscribe to the SysKit Blog

Get more product guides, webinar transcripts, and news from the Office 365 and SharePoint world!