Do you hate SharePoint? Part 3 of 4
If the answer is yes, could your hatred be caused by your local implementation? In this blog series we look at four common problems with SharePoint implementations and how you can address them.
We continue our series by Neil McIsaac, SharePoint MCT, for putting this together. Happy reading! If you missed it you can still read Part 1 and Part 2 of the series
SharePoint is an interesting platform and as it grows as a product and with its already incredible adoption, it is an important cornerstone for many organizations. But ask the people that work with it, and you will find a divided love it or hate it passion for the product.
Why hate it?
It’s my experience (which dates back to the site server/dashboard days), that many customers have difficulty handling the product and I mean this a number of ways. Here’s the issue:
SharePoint will amplify your problems.
So why do we hate it? I would hate anything that made my problems larger. But did SharePoint create the problem? That would be like blaming the carpenters hammer for building a crooked house. The problems are our own doing in the majority of cases. In my experience, the most common problem SharePoint seems to amplify are the following;
- Information Management
- Project Management
- Information Security
- Business Intelligence
This week we look at Information Security.
3. Information Security
SharePoint has a confusing security architecture. A friend of mine continually jokes that you can do anything in SharePoint, as long as you know the 6 strategically placed security settings you need to set to allow users to interact with your content. I like to keep things simple. I always start addressing security by asking these 3 basic questions;
What are the requirements?
This question is pretty straight forward and we do it relatively well. Who gets access, and who doesn't.
How do we know we meet the security requirements?
This is one area where SharePoint poses some difficulty, since it lacks any worthwhile reporting tools and has enough security layers that are hidden in the UI that it feels like finding an answer to this question is akin to finding the meaning of life itself. Paired with the products inability to properly handle security inheritance and the lack of a proper method to deny permissions and you are on a never ending hunt for individualized permissions. Yuck. Unfortunately the best security reporting tools are third party. Your team needs to sit down and address how your organization will address security reporting and auditing.
When is the last time we checked?
Security audits are often checked at implementation, but rarely checked afterwards. Permission elevation happens for various reasons such as troubleshooting, making it necessary to schedule our audits. If running an audit is painful because we haven't properly addressed the above question, then scheduling it will hurt that much more. Again, get a good security tool.
Information Security Tips
Here are a few tips on implementing security in SharePoint to help make things a little more manageable.
Libraries/Lists are for security
I am not a fan of the Shared Documents Library which comes as a default. If you have ever heard me talk on the subject, you know I get a bit worked up about it. I am a fan of lists/libraries in SharePoint and I completely understand Microsoft's position in adding it. It was a necessary evil. The problem that I have with it is what most people put in it. It goes against pretty much every information management principal that we have. Many organizations use this library and why not? It says "Shared" and I want to share my stuff, so why not? The reasons are many, but at a simple level, you will end up with a folder structure that mimics your old file shares, and make it work by placing individual permissions on folders and files to compensate for your lack of proper architecture. If you think of lists and libraries as containers, which if you were paying attention in the previous blog post when I ranted about the importance of structure, you can shape these containers to better store its information. You can change the shape (think 'content types' ), and you can change the behaviour (think 'workflows' and 'views' ) to better aid the end user in the task they have at hand (think 'Use Cases' ). Coming back to permissions, if we have a container with similar information in it, we can control permissions to all of its content by controlling permissions to the container. In other words, permissions in SharePoint are best handled at the list and library level and not at the folder or file/item level. Which brings me to a solid point: If you are not sure how many libraries you should have, look at the common permissions to your content. If a group of people need read access to one type of content but not to another type of content, then the content should be in the same list/library and we can control permissions to the content by setting the permissions once on the list or library. So how many lists or libraries should you have? The answer is in how many groups of content with the same permissions you have. This is not always the answer, but it is a good starting point.
Use SharePoint groups as functional roles
SharePoint groups are best used to reflect functionality rather than entity. Since we typically use Active Directory groups, adding the AD groups to our SharePoint groups to reflect the same group would be redundant. For example, having a Sales group in AD, which we mimic and create a Sales group in SharePoint usually offers little benefit. Having a group in SharePoint that reflects their ability is preferred. For example, I can create a group in SharePoint called Sales Lead Generators that can better reflect what anyone in that group can 'do' rather than who they are. Not only does it simplify security administration, it makes audit reporting a lot easier to read and verify.
Use Information Rights Management
Information Rights Management has been around for some time now. Surprisingly, most organizations that want to secure documents rely on securing the folder or physical media where the file is stored. The problem is that this security simply doesn't follow the document where ever it goes. IRM on the other hand, does! You just have to ask someone if their documents are just as secure after an employee that has proper permissions to the file copies it to a thumb drive, or inadvertently emails it to the wrong person. SharePoint and IRM integrate very well. You can check out more about IRM here.
Next week, part 4 business intelligence…