HomeAvePoint BlogSharePoint Gone Wild: When Governance Lacks Restrictions

SharePoint Gone Wild: When Governance Lacks Restrictions

In my last post on when governance lacks appropriateness, I discussed why content appropriateness is important and the issues it brings to an organization. Restrictions within Microsoft® SharePoint® are probably the most contentious issue I come across in customer discussions. The main reason for this is that there are so many approaches to a security model within SharePoint, including:

· Granting Active Directory Users a permission level directly to objects (e.g. sub site, list, list item)
· Granting SharePoint Groups a permission level directly to objects and adding Active Directory Users to these groups
· Granting Active Directory Groups a permission level directly to objects and adding Active Directory Users to these groups
· Granting Claims a permission level directly to objects

The other main reason is that often these decisions may be agreed upon by the governance committee, but are often delegated for management to “Site Owners” who have not received this communication. Subsequently, everyone addresses security models in different ways.

SharePoint’s hierarchical inherited security model also doesn’t fit well for traditional records managers who look for “document type” or “classification” based security. For instance, there is no way to have different security based on the “content type” of the document or on a document having metadata with a particular classification level such as “top secret”. The only way to do this would be through item-level permissions, which are not recommended in large lists due to the negative performance implications.

I think the biggest scare story I’ve had in this space is when an organization migrated its file share to SharePoint, and set security at the first four levels of folders within the library. Unfortunately, on the sixth level, where the Human Resources department had stored employee contracts and their salary information, the security permissions had been broken and “NT AUTHORITY\Authenticated Users” was added, giving everyone who can authenticate into SharePoint access to these documents. On a file share this wouldn’t have been so much of an issue as its search capabilities are typically terrible, but SharePoint search is powerful and easily accessible with alerting. What happened is people did “ego-searches” and came across their contract, then started searching for others names and realized they could see all contracts. This is just one example of why it is important to keep on top of your security model for sensitivity of your information in the organization.

Unfortunately, there is no easy way to stop people from breaking inheritance on an object or granting direct access to an AD User rather than AD Group or SharePoint Group. The only control you have out of the box is to allow them to manage security or not.

With all this in mind, I have seen some really complicated information architectures out there with an overlaid security model. So what does that mean? When a content contributor wants to upload a document, they immediately get confused and have three fears:

1. The document is in the wrong place.
2. The security model is too constrained and people can’t access the document.
3. Alternatively, the model is too open and the wrong people have access.

All of this leads to very poor adoption of the system.

Some of the key strategies to mitigating these issues are:

· Communicate It’s amazing how little companies communicate security management to site owners. The most effective organizations I have seen have site owner’s manuals and training in order to explain how the organization manages security.
· Lock down – Create locked down information architectures where the security model is overlaid and fixed with groups that represent roles within the organization. The request to be granted access is to a role not directly to an object or group. This also means modifying the permission level, or change to a custom permission level, so that “Site Owners” cannot modify permissions on sites they “own”.
· Keep It Simple Stupid (KISS) – It sounds obvious, but actually having a simple information architecture with a overlaid security model makes it easy for users to understand where they should put sensitive items and understand who can see them. The more broken inheritance you have, the harder it will be and most likely less adoption you’ll see.
· Monitor – Librarians can manually monitor security within the web interface, but a more efficient out-of-the-box approach is to write some PowerShell scripts to iterate through site collections and the hierarchical tree in order to report where permissions are broken. There is obviously third-party software that can help in this area, including AvePoint’s DocAve Administrator tool.

Next week, I’ll explain in greater detail the next business driver for governance: discoverability.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

More Stories