Author: Peter Heydon

A few weeks ago, I was approached by our HR department to advise how to best secure the personnel files inside SharePoint. There were some concerns that a number of staff (IT and non-IT) who had unncessary access to this data. So I outlined for them our structure, who had access at each level, and them some options to mitigrate their security concerns. The HR executive understood that it would be impracticle to totally remove IT staff access from accessing personnel files, but agreed that it should be limited.

Current Scenario

The current structure of the INTRANET is along the lines of:

(1)SharePoint Farm:    COMPANY FARM
(2)Web Application:    |__INTRANET
(3)Site Collection:       |__Human Resources
(4)Site:                  |__Human Resources Site (root of site collection)
(5A)Site (subsite):          |__Management Tools
(5B)Site (subsite):          |__HR Only
(6)Document library:            |__Personnel Files

Let’s look at how we can give acccess to the Personnel Files (6).

1. At the lowest level (5B), a Site typically has the permissions defined in the Owners/Members/Visitors SharePoint groups. Removing access at this level, will block access for the majority of staff. Even with Visitor access at the top level site (4) we can prevent access to the lower sub-Sites (5B).
2. At the Site Collection level (3), there is an overriding group called Site Collection Administrators that effectively have access or the ability to grant access to all content below it, including the HR Only Site (5B).
3. At the Web Application level (2), we have a user policy defined, which gives a group of people full access to ALL site collections (eg Human Resources, Operations, Sales etc) and all Sites (inc HR Only (5B)).
4. At the top most level (1) there are Farm Administrators. The role here is to manage the SharePoint infrastructure. These people, although they may not have explicit access to any Web Applications (2) or Site Collections (3), they are in a position to grant access to themselves or someone else. It will be impossible to not have some IT staff assigned at this level. There are no options to restrict Farm Admins from changing permissions.

In my original communication, I included a list of staff who had access, and it was quite clear there was an abundance of people with access at the latter to levels – (1) and (2) which is what gave most concern to our HR department.

Mitigation Options

1. Enable full auditing on the HR Only site to record who has accessed information

PRO: Quickest to achieve, will not require an internal approval processes (treated as BAU).
CON: Won’t prevent access, will require monitoring from HR to review audit reports.

2. Trim the people with access as a Farm Admin, within a Web Application User Policy and Site Collection Administrators for Human Resources.

PRO: Quick to achieve.
CON: Will require staff who do have permission to perform more administrative functions, will require a submission for approval.

3. Create a separate web application just for HR and restrict Web Application User Policies and Site Collection Administrators

PRO: Moderate effort to achieve, should be able to move existing content without a lot of rework.
CON: Farm Administrators can still grant access to themselves or others, will require a submission for approval.

4. Create a separate SharePoint farm for HR-INTRANET. Least amount of non-HR priviledges can be granted to this farm, and lock down the IT staff access.

PRO: Most secure option, does not impact administration effort for INTRANET, should be able to move content across without a lot of rework, can provide a seamless transition between INTRANET and HR-INTRANET, can share some service applications across farms (eg managed metadata).
CON: Most amount of effort to achieve initially, will require a submission for approval.

Recommendation
I suggested that if HR is happy that auditing will be sufficient to monitor access to the HR Only site, then mitigation option 1 would be recommended.

However if it is not sufficient just to know who has accessed Personnel Files, then mitigation option 4 would be suitable for a complete, separate HR SharePoint farm.

Result
Site auditing was enabled as an immediate measure, and a proposal was submitted to proceed with the provisioning of a dedicated HR SharePoint farm. At the time of writing this is still awaiting approval.

I’ve been working on a SharePoint 2010 project lately, a migration from a SharePoint 2007 farm.  As usual in this particular organisation, there is never any time for any actual planning, but a desire to just trial and error it.  The only problem is, it has suddenly become production, and I’ve getting bogged down helping various people with site specific requests, rather than completing the infrastructure configuration (don’t even get me started on the user profile synchronization service…).

To help explain why everything is not yet configured, or why I have to keep performing IIS resets on the farm, I’ve been using an analogy to the staff who are coming to me – I call it the SharePoint House.

SharePoint is a big block of land, and we’re building a house (web application) on it.  Let’s call this house Portal.  Portal from the outside looks like a completed house – the foundations are down, there’s a roof, and we have a few rooms (site collections).  Some of these rooms have wardrobes or even other rooms contained within (sub-sites).

Within some of these rooms we have special functions (features) like a kitchen vs a bedroom, and they all have different looks and feels (theming, page layouts).  Inside the rooms, wardrobes etc is a bunch of storage items – drawers, cupboards, boxes – these are used to store stuff (libraries/content) and some of it may even be collated together to represent something in particular (content types).

Of course, no house would be complete without running water, electricity, gas, cable TV etc all connected up (service applications).

So when someone asks me questions or complains about the Portal, I explain the SharePoint House.  I then make a point that we didn’t use an architect to design the SharePoint House, we just started building.  Then all of a sudden, while we were still putting up rooms, everyone all of a sudden started moving in.  In the chaos of moving all their own stuff across, it was poorly organised and now hard to find.  To make matters worse, when anyone went to use the toilet…it wouldn’t flush.