RSMUS.comEvery project should have a considerable amount of the overall effort dedicated to planning. We typically gage 25% of overall effort. When it comes to SharePoint projects, the heavy design activities are typically around site structure, metadata, page layouts, and, if necessary, workflow. We often talk about governance and security, but many times holes are poked in that plan at the time of implementation.
Below are some things to consider, from a security and permissions perspective, when taking on your SharePoint project:
Document the planned security model – and then baseline
Every good planning effort should take security into account. Where are we considering item level permissions? How many functional groups do we need? What custom permission levels to do we need to create to provide the right amount of access to our end users? Once documented, execute on that plan prior to initial testing. Even the best laid plans can be disrupted, so if things change make sure to update the design and lessons learned. This will serve as an asset in the future.
Identify the gatekeepers – and train them
Whether or not SharePoint security is managed through IT, ensure that users know the ramifications of decisions made when altering permission. Just because a technician has managed a file share this does not mean that translates into management of SharePoint security. For example, do they know the difference between, ‘contribute,’ and, ‘edit,’ permissions? (They are not the same…) Should they add named users to a SharePoint group? Do the rules change based upon the sensitivity of the content? Ensure that your employees are stewards of the content and that training does not stop at ‘how to grant permissions”.
Got workflow? Don’t forget about the impact of permissions
Many times workflow is used to manage permissions based upon when an item is added, changed, etc. Make sure to consider the complications in starting workflows, updating items after permissions changes, etc. Using elevated permissions can be a work around, but challenge the process to ensure it is sound before going the easy route. Changing permissions via workflow is complicating the environment by breaking inheritance, so it should be treated just as if an individual was granted the ability to do the same.
Attempt to use security groups
The use of security groups rather than named users can prove very beneficial in knowing who has access to what in the environment. As a general rule, the more formal the documentation (policies, procedures, records, etc.) within the SharePoint environment, the more religious an organization should be around centrally managing security in Active Directory (AD). There are also performance gains as search has to re-crawl every item when a user is added explicitly to a group.
Consider access requests if enabling the share functionality
The share feature is a fairly new capability in SharePoint. From a collaboration perspective, its fantastic. From a security perspective, it can be a nightmare. As your organization warms up to sharing, use the access request feature to route the sharing requests through an owner. That person can see who requested the access and to whom the request is providing access.
Choose a governance tool early
Finally, consider a governance tool and get comfortable with it prior to things getting complicated. These can be invaluable tools for the organization and allow administrators and business owners the ability to be proactive in mandating a clean security model, thus avoiding the large ‘spring cleaning’ initiative 2-3 years down the road. There are many affordable tools available today and it will be well worth the investment.
To find out more about this or other ways that RSM can assist you with your SharePoint needs, contact RSM’s technology consulting professionals at 800.274.3978 or email us.
