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.
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: 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).
Editor's Note: You may also be interested in reading: