|
|
In part 1 we looked at how permissions inherit and cascade, and using SharePoint groups to avoid inheritance problems. In part 2 we covered using mail-enabled security groups in O365 to make your permissions more consistent. In part 3 we looked at reducing your maintenance burden by using dynamic security group membership.
These 3 articles covered the technical side of setting up permissions that don't break the permission inheritance rules, adding a user to a single security group so they automatically get permissions to many sites at once, and how to add users to security groups automatically by setting up dynamic group membership in AAD.
This is the how of setting up permissions, but it's also important to understand the why of setting up permissions. If you don't understand why you're setting your permissions up the way you are, you'll just be providing permissions on an ad hoc basis without any structure. This will store up problems for the future because your permissions scheme won't be consistent, and the rationale for any given permissions can only be explained by the person who set them up. Why is Joe Bloggs in this security group when he's not a member of that department? Why does Jane Bloggs have Edit rights to this library when everyone else has Contribute rights? What's this security group used for? Why does every site have different permission levels to all the other sites? These kind of questions should not come up - and if they do come up, they should be easy to answer - if you have a permissions strategy.
As always when creating a strategy, the first question to ask is "What do we want to achieve?" Are you looking for minimal admin burden? The removal of data silos? Highly restrictive permissions to protect sensitive information? The chances are you want all of these things, but in different areas. So your strategy should lay down some general principles that guide you towards the most important goal for a particular site, but also ensure a consistent, structured approach to permissions.
Some useful principles:
- Only restrict a site if necessary. Most of your sites can be open, that is, everyone in your organisation has read access to the site. You might have a library restricted to a particular team, but otherwise the site is readable (and importantly, searchable) to the whole organisation. This helps breakdown data silos and reduces the admin burden. A few sites will be closed, that is, only those people who need access will be given it, and this is done where there is sensitive data.
- The higher the permission level, the less people should have it. This means the group with the highest permission level - Full Control - should also be the group with the fewest members. Normally this is your System Admin group, commonly the people responsible for maintaining the structure and security of your SharePoint instance. Conversely, the group with Read access will be the group with the largest membership (normally the built-in "Everyone except external users" group).
- Minimal complexity for maximum performance. The more unique permissions you have in a library, the lower the performance. This is not such a big deal for small libraries, but in larger libraries where each individual document could have unique permissions provided by users sharing things, it can cause a drop off in performance. There's a good discussion of this problem here, and although the article is talking about SharePoint 2010 on-premise, the basic elements of load-balancers, web servers, databases and CPUs haven't changed significantly. The performance can depreciate on both the indexing crawl and the site performance itself.
- Breaking inheritance is the last resort, not the first. If you have sensitive information in several folders across different libraries and you need to restrict access to these, but the rest of your libraries and documents can be read by anyone, you'll have to break inheritance for all of those folders. That's the easy way to "fix" the access immediately, but in the long run it's just more maintenance complication and potential access problems to troubleshoot. When you're designing the site take these issues in mind and create a single library for sensitive information. This will make the permissions much simpler and correspondingly easier to maintain.
- Security by design, not by accident. Your organisation has to comply with a regulatory framework, whether that be industry- specific (e.g. Sarbanes-Oxley) country-specific (e.g. local data protection laws) or trading-bloc specific (e.g. GDPR). A logical, well thought out permissions strategy can help prevent breaches, and, in case of a breach, also demonstrate that you incorporated sensible security measures into your design from the outset, which can help lower penalties and maintain your organisation's reputation.
- All permissions are documented. Out of all the principles, this is probably the most important. It's certainly the most useful, because even if you have no other principles to follow then at least you've got information about what permissions have been applied and why. In the design document for each site - you've got a design document for each site, right? - set aside a standard section explaining what SharePoint groups you've used with what permission level you've applied, which security groups are in each SharePoint group, and an explanation of any unusual or unique permissions, and any deviations from your standards. This information will be invaluable in a whole host of different future scenarios.
A permissions strategy is part of the governance of your SharePoint implementation. It should be written down and accessible to the whole organisation. All administrators who are able to add or amend permissions from the library level up should be familiar with it, and no site collection or site design should be applied to a site unless it meets the requirements of the strategy.
But whilst writing it and making it accessible is important, it's not enough. What doesn't often get talked about is the need to convert your strategy into practical actions. It can be difficult to understand how the strategy should be applied in day-to-day work, especially for people more used to solving technical problems than creating and interpreting policy.
So the strategy document should also have an accompanying permissions design guide that translates the strategy into concrete actions and requirements. The guide should include what default SharePoint groups are in your site template and why, under what circumstances it's acceptable to deviate from these groups, naming conventions for security groups, and so on.
The contents of your permissions design guide will vary according to your strategy (e.g. you may prioritise accessibility over security, or vice versa) and the overarching design decisions you've made (e.g. what your naming conventions will be, what default SharePoint groups you use, etc), so just as there is no "correct" strategy, there is no "correct" design guide. The design guide is there to provide your designers with the practical information they need to implement your strategy. Think of it as a tactical handbook which, if followed by everyone, will allow you to realise your strategy successfully.
A design guide takes a long time to write and is a living document. As new functionality is added to SharePoint, the design guide will change and grow. It would be nice to say "don't build anything until your design guide is finished!" but that's unrealistic in a production environment. Instead, start by working out your strategic principles and getting all of the stakeholders on board. Then at least you're all working from the same starting point. This is doubly important if you're well into a SharePoint implementation or you've got a mature implementation you want to improve (and realistically most people reading this will be in these positions).
The further into your implementation you are, the more potential work there will be to implement a strategy and corresponding design guide on your pre-existing sites, so don't expect to make sweeping changes. An incremental approach that gradually improves things has a better chance of success than a radical redrawing of your permissions to fit a new strategy. Start by creating a strategy and corresponding design guide that can be used for any new sites from now on, and when it's stable and well-understood you can look to implement it in existing sites over time.
The technical work of creating and implementing the permissions strategy is part of the admin's role. In the next article we'll take a look at user sharing, how to modify the out of the box settings (both at tenant and site level) and what you can and can't stop your users doing.