If your company has SharePoint or SharePoint Online, then you know a major key to protecting the privacy and ensuring security of your data is getting a handle on SharePoint permissions management. The mandate is simple: use your data governance strategy as a guide when deciding who gets access to what, and how much access they can have. But managing who can see what in SharePoint has never been a simple task.
Understanding how SharePoint permissions function natively is important when creating a plan for securing your SharePoint environment. In this post, I’m going to talk about how out-of-the box permissions management in SharePoint and SharePoint Online works, and some gaps in functionality you should be aware of.
What SharePoint Permissions Can I Give?
Through permissions management, users and administrators have the power to control who can see and make changes to specific site collections, sites, folders, documents, lists, list items, and libraries within their environment. This gives both users and administrators a basic level of control over the security of their data. Below are the default permissions settings in SharePoint and SharePoint Online.
At the system administrator level, you can customize the types of permissions that are activated at each specified permissions level. You also have full control over who shall or shall not do anything at the web-app, user, or location level.
Default Permissions for Groups
It is typically best practice for both larger and smaller companies to categorize their users into groups, and the table above clearly shows why. Groups make it easier to apply multiple permissions to multiple users.
Inherited vs. Unique SharePoint Permissions
There are two types of permissions: inherited and unique. Inherited permissions are set as the default from the root site collection level and trickle down to the other locations and objects within that site collection.
Unique permissions are all other permissions that differ (or “break”) from what is set at the root. To help illustrate: Bob is a writer helping his co-worker Lucy publish some articles while she is away on vacation. Bob needs access to her draft library on her site, which he currently cannot see. This means he needs you, the SharePoint administrator, or Lucy, the site owner, to grant him unique permissions that let him into the library, but not the rest of the site. This — like all other unique permissions — should be set directly at the user or location level.
How it All Plays Together
There are two methods that allow you to take advantage of groups and SharePoint permissions inheritance:
- Set permissions at a site collection level and let those settings trickle down to subsites, other locations, and objects within the scope
- Create groups and apply unique permissions to users across different locations
Realistically, you’re using both, which means your permissions flow might look somewhat like the following:
Bringing it back to our previous scenario, this is what Bob’s permissions would look like after Lucy or a systems administrator gives him access to the library.
While it’s not impossible to manage your data security and privacy with just groups and native SharePoint permissions management capabilities, the biggest concern is keeping track of everything. Managing permissions at the group level provides administrators with a certain level of control, but difficulties can quickly develop when managing multiple users in multiple groups in locations with inherited permissions. Even in small companies, keeping track of permissions overlap and who has access to what can quickly become a daunting task.
This all boils down to three crucial areas where native functionality is lacking:
1. Permission Certification: Unique permissions will break SharePoint permissions inheritance — which is fine if it is necessary and within your policies. Unfortunately, there is no permission certification system in place to ensure that happens within policy when performed by business users. This means users like Lucy with full control, or users marked as owners in a group for a particular location can give the keys to anyone, without proper guidance and without you realizing it has happened.
2. Visibility: If you or a user with full control grants permissions to another user, you cannot centralize a view to see to mark changes as those permissions are permanent unless changed by an admin. That’s why, on top of making sure unique permissions don’t break along the chain, it is important to be able to see what a user has access to. Unfortunately there is no way to centralize an overview of what a particular user has access to. This is a problem in two very real instances:
- When an employee leaves the company, revoking access is like trying to find and pull out needles in a field of hay stacks.
- When a user needs temporary access to a location, whoever grants permission needs to remember and manually correct those changes after the fact.
3. Reporting: There are limited reporting capabilities that let you see how permissions are inherited across a location, but there is no way to get a centralized report of who has access to specific locations. For heavily regulated companies, this is a major concern as there is no way to audit how permissions are set from either the location or user/group side. For the everyday SharePoint admin, this means you are either spending most of your day hunting for permissions violations or addressing violations only after they have escalated.
Understanding the Bigger Picture
As I mentioned in the beginning, effectively managing SharePoint permissions — whether with only native functionality or with help from third-party tools — is an important factor in protecting the privacy and security of your data. However, it’s still just one part. An effective governance strategy extends beyond regulating who can see or interact with which site or document. Learn more about building and implementing an effective SharePoint governance strategy to protect your data with our free White Paper!