Organizations deal with a lot of confidential information every day, information that is typically managed using business applications, like SharePoint. That means that properly implemented and managed security is critical to these applications.
With SharePoint, you can implement effective security, but managing it with the tools you get out of the box isn’t the easiest. Here we look at the challenges you will face managing security and permissions within SharePoint and discuss why you should make it a key element of your Information Architecture plan.
Managing Security in SharePoint 2010
Managing access to information stored in SharePoint can be done at a number of levels. You can secure from the Site Collection, the Site, a specific List or Library, a Folder or a document or item. By default, permissions are inherited from the parent (so a List inherits permissions from the Site, a Site inherits permissions from the Site Collection, etc). In many cases, inheriting permissions is the recommended approach to implementing permissions (it’s certainly the easiest to manage), but this inheritance can be broken and unique permissions applied as required.
SharePoint organizes users into Groups, with three Groups automatically created for you: Owners, Members and Visitors. Permissions are typically applied to these Groups by a permission level. A permission level is a group of related permissions; SharePoint offers four permission levels out of the box: Full Control, Design, Contribute and Read.
Note that there are additional permission levels if you are using the publishing template. You can also apply permissions to individuals, but that is not typically recommended due the maintenance effort involved. (Learn more about the basics for Security/Permission planning for SharePoint)
While using security/permissions out of the box sounds great, it’s not always that easy to map your security requirements to the default settings. Which means you need to be able to customize. With SharePoint you can create your own custom groups, your own custom permission levels — this is what most companies end up doing.
The Challenges of Custom Permissions/Groups
You know you need to set up your SharePoint security different from what is offered out of the box, so what should you do? Unfortunately, many organizations allow Site Owners to manage the permissions for their sites and things often can get a little out of hand. Security is a tough thing to manage and it requires regular attention (which is why most organizations have security teams).
For Site Owners, the focus is usually on the content and making sure the right people have access to it by whatever means possible; thinking carefully through how you create lists and libraries based on who needs what permissions is not something they tend to have time to do. Obviously things get messed up and out of hand.
You also have those cases where someone new comes on board and although you know you want to give them the exact same permissions as another employee, you can’t just click a button and have the right permissions applied. You have to first find out what permissions the current employee has (luckily SharePoint 2010 does provide a tool for this: Check Permissions), and then go and manually apply the same permissions to the new employee.
And what happens if an employee quits? Often they are still left in the system with all the access they had instead of being removed. This may not be the end of the world, but it leaves the system messy and causes confusion.
Now take the case of an employee who moves to another department. You have to find out everything they had access to, remove it, and then apply new permissions for the new information they need to access. What often happens is the permissions are not removed, or one or two get missed and the employee still has access to information they no longer should be able to access. Again, messy and confusing — and a security risk.
Make Security Planning a Key Component of your Information Architecture
Permissions should be applied on the principle of least privilege. I can pretty much guarantee you that this does not happen when you don’t take the time to properly plan. Your entire Information Architecture (IA) depends on a solid understanding of who has permission to what, and what kind of permission that is.