Note from Editor: This post was co-authored with Bill Evans, Sr. Director of Product Marketing, Identity and Access Management.
This year’s release of SharePoint 2013 and Office 365, the fifth major release of Microsoft’s flagship collaboration system, extends the platform’s reach beyond the traditional data center to the cloud, with Office 365. At the same time, they’ve added a host of new features for apps, search, business intelligence, and social that will bring even more users than ever before. Support for functions like Remote Blob Storage “RBS” (managed by our own Storage Maximizer) makes SharePoint the one-size-fits-all enterprise content management system.
Want to centralize all those legacy file servers? How about giving users a versioned, searchable, synchronized personal cloud to replace all those local C-drive files? Or, consolidating a patchwork of internal and external legacy ECM and SharePoint internal and external sites?
Done and done. That’s why SharePoint is projected to keep growing beyond its current 165 million user base at a rate of about 32 percent. (More than 43 percent for cloud users!)
Fantastic. So, you’ve moved all your content into SharePoint 2013. And you think the security makes sense. Are you sure?
Try this. Go to the snazzy new SharePoint search screen and type “show me where all the PII lives, and who can see it.”
Ok, you’re back. Didn’t work, did it?
That’s because SharePoint’s default interfaces are only based on the outside surfaces of things. We can see site level security, document ACLS, individual users, and file names. But that’s not enough. To govern the data on SharePoint, you need to go inside the information. Looking at files from “outside the hatch” isn’t enough.
Is it OK to have PII, PCI, PHI and the rest in SharePoint? Sure. I’m 99 percent confident that most SharePoint farms have at least one file with a Social Security number inside, for example. But that leads to two broad questions:
- Who can see it, and why? Understanding users and roles is essential to managing their access. Some classes of users may need a lot of access to PII. Others may only have rights to see their own PII. SharePoint allows for inherited hierarchical permissions as well as custom ACLs. Microsoft’s classic definitions for SharePoint governance talk at length about processes and roles. Let’s assume the permissions are “wrong” – you also need to understand whether the document owner gave the permissions directly, or if the content lives on a SharePoint site that is widely shared.
- Where is all that sensitive data? Obviously, it’s not easily searchable. However, understanding its location on the farm matters. A lot.
A credit card number on a bill-of-sale document in the account processing department internal site probably makes sense. On a document in the FAQ area of a public facing web site? Probably not.
In the end, SharePoint is user software. In my experience, a lot of the need for governance arises from accidents and misunderstanding – not malice. In the SharePoint business, we talk a lot about three steps of governance:
- Awareness – Reporting and viewing data and activity – incident detection
- Action – Solving immediate issues in the system
- Policy – Over time, consistently reinforcing proper usage, and preventing “wrong” actions
The first step is knowing you have a problem. Information governance – data governance – requires a broad, consistent set of tools to let you see the results of all those thousands of SharePoint users in your farm, without it, you are putting your organization at risk.