Audit and analyze SharePoint permissions
To ensure an effective audit of the SharePoint permissions, it is important to first understand the principle of the accreditations model.
Before entering the detailed aspects, the image below offers a global view of the functioning of the rights in SharePoint. Globally and by default, rights are inherited within the sites collection (from the parent site to the subsites, and from sites to the components or libraries). In addition, inheritance breaks are possible at any level of this hierarchy. The simple act of, for example, giving access to a specific person on a file will have the consequence of « Breaking » the inheritance of rights from this folder.
First principle: SharePoint permissions are inherited within the « Site collection »
The permission template starts with the concept of site collection. A site collection is composed of a parent site and a set of subsites.
By default, rights are inherited from the parent site to all subsites. You can represent a site collection with the following schema:
Second principle : the inheritance within the site of the SharePoint permissions
Beyond the inheritance from the parent site to the subsites, each site itself is composed of a set of components. These components can be lists, libraries of documents, …
In document libraries, there is also an inheritance from the parent folder to the child folders, as shown below:
Third principle : the breaking of inheritance
Once you gave rights to a person on a site, a list a folder (…), a break is created in the inheritance of SharePoint permissions.
For example, if an authorized user shares content with another person (or with a group), the rights will be changed, and an inheritance break will be created.
In the case above, a new user will be added directly to a folder.
To control the rights granted to SharePoint users, you must be able to detect all inheritance breaks and track individual rights that are set.
The default access levels in SharePoint permissions
Default access levels are defined in SharePoint. They can be consulted directly from the administration pages of your sites:
Nevertheless, and as the screenshot above suggest, access levels can be customized. Depending on the policy applied in your organization, it may be appropriate to plan for an extraction of the different levels of authorization in your organization and the associated real rights.
Using SharePoint groups
Authorization levels, described so far, can be assigned to any users, AD groups or SharePoint groups.
By default, when you create a SharePoint site, you have the choice between using a new permission set, or inheriting these permissions from the parent site:
In case you select a new SharePoint permission set, default groups are created for the site. In the case of the creation of the site « AERAS Documents » above, SharePoint groups are set up by default:
A good practice is to use SharePoint groups to assign rights to final users. We might think, to audit the permissions of a site, that it is enough to analyze the members of these groups SharePoint to have a good overview. If the approach may seem relevant for a first inventory, in the case of an audit and a precise analysis, this would not be enough, for the following reasons:
1. Any user can be enabled live on any component of the site (outside of any group). This practice is generally to be avoided, and it is recommended in this case to be able to identify these cases.
2. Any Active Directory group can be accredited on one of the subcomponents of the site.
3. Any other group in the site collection may have permissions on your site.
On this third point, it is not obvious, but the scope of a group concerns the whole site collection. For example, if you have a developer site named « DEV_PRJ » and another for managing AERAS documents « AERAS Documents » , you can view all groups in the « Site Collection » .
Although it is created with default SharePoint permissions (which match their description), there is nothing to prevent « Full Control » permissions from being assigned to any other group in the site collection. Below, the list of permissions of the site « AERAS Documents » in which the group « DEV_PRJ Visitors » has been assigned the level « Full Control » (by mistake or malicious act of malicious intent):
Also, if you want to guarantee the confidentiality of the data of your SharePoint sites, you must be sure to be able to map and track these inappropriate authorizations for a better governance of your accesses.
Your organization probably has multiple sites and site collection. It is unthinkable to search « by hand » and « dig in » the SharePoint interfaces for all the inappropriate permissions for each site, each component, each subfolder. For us, it is better, if not necessary, to equip yourself with tools that will allow you to list all the permissions, inheritance breaks and real rights of users on all of your data.
We must not neglect any aspect of the points cited in this article, and in particular concerning groups: do not just analyze them by their description. Check the actual scope of permissions of your SharePoint groups and industrialize the verification process.
Caricaturing on our example: do not let the group « Visitors » of the site « Developer » take control of your most confidential data!
Your check-list for auditing SharePoint permissions and ensure an efficient access governance:
To ensure a good level of audit of SharePoint permissions: