By Cathy Dew
Setting security follows a well thought out site structure, but sometimes you need a change
As you are building your SharePoint intranet, there will likely come a time when you either want to grant or take away permissions from certain groups of users. Being selective with your permissions helps you stay in control of who is seeing what and who can add, change, or remove data or documents stored within your SharePoint.
For instance, there are likely to be sites and site collections in your SharePoint environment that you will want all your users to be able to access. However, there are also probably other areas of your intranet that are more sensitive or specialized. You can use permissions to make sure that only people who need to access these areas have the authorization to do so. You can also use permissions to determine who does or does not have privileges to edit documents or carry out other more administrative tasks.
Site Collections and Permissions: What You Need to Know
By default, the way permissions work on SharePoint is through inheritance. Lower levels of your intranet will inherit their default permissions settings from higher levels. So, if you host a document library somewhere in one of your sites, and you’ve set things up so that all of your users have access to the site, then each user is also going to be able to access every document in the library with the same permissions they have to the site itself. E.g. Site Visitors will only get read access, while Site Members will be able to read and edit site pages, lists and documents.
You can also break permissions, to customize the security of your site pages, documents, and lists. However, it’s still a good idea to know about SharePoint’s inheritance chain so that you know when and where to break permissions and customize things a bit more.
Microsoft has some great tips here: "Best Practices for Authorizing User Access to SharePoint Sites Using SharePoint Groups/Permissions/Inheritance"
By default, the root sites or top-level sites in your site collection are at the top of the inheritance schedule. Within these root sites, subsites (as well as subsites of subsites) inherit their permissions from the root site. Going further down, lists inherit permissions from their sites or subsites, while list items inherit permissions from their lists, and so on and so forth.
Using Permissions to Safeguard the Security of Your Data
As the administrator of a site collection, it is your job to build out the root site and configure the permissions for this top-level site and its sub-sites. In many cases, one round of configuration is all you will need to do. For instance, if the site collection you are building is just an employee resource hub, you will likely want to have identical permissions across the board for everything on the site. Everyone can access all the lists, documents and sub-sites, but only a limited number of people (or perhaps only you) has permissions to add new pages, manage documents, edit existing lists, or carry out other administrative tasks.
In other cases, you will have document libraries, lists, or sub-sites where you want extra security. Perhaps you want to restrict who gets to access and read certain parts of a site. Maybe you want to make sure that only a limited number of users can add, delete, or update libraries or lists. By breaking permissions and customizing the access rights, you can do all these things. The more specific you want to get with the security of your site collection, though, the more individual permission configurations you will need to create.
In addition to configuring permissions at the root site level, you can also configure individual permission sets for sites, libraries, lists, and sub-sites. Note that each time you create a new configuration, you have effectively broken the chain of permissions. For example, if you set up your root site privileges, but then want to make a certain subsite more secure, you would create a new configuration for that subsite. Once the new configuration is in place, the permissions you established for the root site no longer apply to the subsite or any of its contents. Instead, all the subsites, lists, or list items contained within that subsite are now subject to your new permissions configuration.
You can continue creating new permissions configurations depending on the level of control and security you want. Some site collection administrators will just set permissions configurations for their root sites and call it good. Others will create different configurations for every individual subsite—or more extreme, for every single list contained within sites or subsites. In other words, it’s up to you how granular you want to get with your permissions.
The Pros and Cons of Breaking Permissions
As with many things, , just because you can doesn’t mean you should, and there are pros and cons to breaking permissions repeatedly. On the one hand, being something of a control freak with your permissions gives you more oversight for what’s going on with your sites, subsites, lists, and list items. By customizing your permissions in this way, you can pretty much ensure that no one is ever going to see a file they shouldn’t or delete something that is subject to a retention policy. On the other hand, breaking permissions over and over again can become extremely convoluted—to the point where no one, you included, remembers who is or is not allowed to do certain things.
Additionally, there is a cost in responsiveness directly related to how many times your permissions chain is broken. Customizing the permissions at every level increases the number of calculations SharePoint needs to do in order to ensure the proper permissions are being applied. With an on-premise installation the cost is not as large, but with SharePoint Online your site rendering could be throttled if the resource consumption due to layered permissions is too high. This will cause a massive slowdown in your SharePoint responsiveness.
Just like with anything else, here, there is a happy medium—a place where you’ve done enough permissions work to secure your data, but not so much that it hurts efficiency. Of course, where exactly this happy medium is will depend entirely on the company in question. As such, it’s not a bad idea to map out your site collection before you start configuring permissions. That way, you can formulate a precise plan for security and access before you start thinking about creating or breaking permissions.
For a deep dive into all that SharePoint has to offer and how we can assist you with any functions and capabilities, check out our topic page SharePoint Consulting: Experts reveal SharePoint mysteries, eliminate confusion.
If you need help navigating this process, feel free to reach out to 2Plus2! Our consultants are always happy to help SharePoint administrators create permissions plans for their site collections. Call us at (510) 652-7700.