Blogs

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 -  http://technet.microsoft.com/en-us/library/cc262939.aspx)

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, and of course 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 (http://searchsecurity.techtarget.com/definition/principle-of-least-privilege-POLP). I can’t pretty much guarantee you that this doesn’t 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.

When you start to map the information you will be adding to your SharePoint environment, clearly identify the information management policies that apply to that information -- so who can read it, who can edit it, delete it, share it; do you have to keep versions, track who made changes, apply workflow approvals, etc... This information will guide you to the proper IA for your environment.

Of course it won’t always be that easy (not that it’s an easy process). There will be instances where you have to apply permissions at deeper levels than you would normally. Sometimes you might need to even adjust permissions temporarily, but only for a period of time. That’s okay, as long are you are managing your deviations from the standards carefully.

SharePoint Security/Permissions Management OOTB

Here’s the problem with managing custom security in SharePoint, or any security for that matter -- it’s a very manual and tedious process. SharePoint Admins love to hate managing security when they only have the tools SharePoint provides them.

There is the new Check Permissions feature which allows Admins/Site/Site Collection Owners to see all the permissions applied to a user/group across a Site Collection, all permissions applied to a particular Site or List/Library, or even a particular list item/document. But this is a read-only look at the permissions. How do the permissions compare to those you defined in your information management policy? Manually do a compare and fix. What if you need to change them? Manually go to each group/user/Site/List/Library/Item and change them. What if you want to apply the same permission structure in another SharePoint farm (say maybe from your Staging environment to Production)? Document the security structure and then go manually recreate it in the new farm. What if you need to change the permissions on a number of Sites, or lists in the exact same way? Again manually go to each Site/List and make the change. Getting the idea here? It’s a very manual process that can be prone to error.

And if you are leaving security in the hands of your Site Owners, which many do, then you want a tool to monitor what they are doing. You won’t find that with SharePoint out of the box.

I’m not saying that you can’t manage security in SharePoint with the tools that come out of the box. You can. I’m saying it’s manual, tedious and prone to errors. So to keep you on the best track possible, make security planning a key component of your Information Architecture strategy, implement your structure with a keen eye to how permissions will be applied and actively manage it (and keep your IA updated as you make changes).