SharePoint Governance- How it Works

Overview

The SharePoint Governance allow to set who are the users that are allowed to be members of sharePoint sites.

The menu displays a list of all sites

 

and for each site you can choose on of the following:

None- nothing was set yet to this site

Ignore - Do not check members

Allowed Groups- list of AD groups that their members are allowed to join the site

 

 

Supporting Nested Groups

 

This method that deals with nested groups, will check each group one generation up.

This means that when someone is added to a Site/File, SphereShield will check if they are in a group that is defined as Allowed Group or if their parent group (one generation up) is in the Allowed Groups.

If their Group or Parent group (one generation up) is in Allowed Groups they will not be removed form Site or folder/file. If their Group or parent group (one generation up) is not in Allowed Groups , they will be removed.

This also is only for SharePoint. For OneDrive, nested groups is not supported so users must share 1:1 otherwise permissions will be removed.

If an individual user is added, SphereShield will see if that user is part of the Allowed Groups and allow or remove permissions accordingly.

 

Handling timing and processes of SP governance

All of the above is done both by the proxy in real-time and the adapter in near real-time. So from the time the product is installed, customer should not expect any new violation to happen.

Existing permission before deploying the product are handled by the product using a process called long -run process by the adapter.

This process scans all existing content and removes entities that are not defined as allowed in the SP governance policies.

Before supporting nested groups, a sub group of the group defined as allowed would have been removed. With the support of nested groups, the long run will not remove a group that is defined as permitted to a SP site if it is a direct member of the allowed group

What is needed to set in active directory to make sure your users are allowed to SP?

When working with nested group you must make sue you are adding the sub groups to the master group that is defined in the SphereShield governance

Relaying only on checking if the members of the subgroup are part of the master group is not sufficient because members of sub group might change in time (without SphereShield knowing) and result in people getting access to a site they are not allowed. Also SP hold only the group name and not the members when adding a group to a site.

How do I verify if a user is allowed to a site?

A user is allowed to a site if he is a direct member of the master group or if he is a member of a group that is a member of the master group allowed.

When might things become wrong?

If you have a sub group assigned to a site which is NOT a member of the master group allowed, this group will be removed even if all of the sub group members are members of the master group set to be allowed to the site.

Long Running Site Membership

Amongst the processes that the API Adapter runs in order to manage memberships of SP sites, there is the Long Running Site Membership Inspection.
The main purpose if this process is to handle existing data as opposed to on-going changes
The Long Running mechanism inspects all SharePoint sites regardless of other processes that might be occurring at the moment.

Long Running, unlike regular site polling or Webhook handling, doesn’t remove a user if they are not in the MANAGED_USER_GROUPS table, in case there was a problem with the table.

Sharing Files Through OneDrive (Personal Sites)

To block file sharing through OneDrive, you need to:

  1. Enable Webhooks and/or polling for files when setting up the CASB Adapter
    (To read more: https://agatsoftware.atlassian.net/wiki/spaces/SKYP/pages/2644672992)

  2. Set Enable Webhook for Files in the portal page Cloud Service Integration to Yes.

File Sharing inspection is based on Ethical Wall Conference Policies. To enable blocking file sharing set a conference policy to block file share.

 

Office 365 Groups

7.11.22 - From our new SharePoint version, we are supporting Governance inspection of Office 365 groups. Before that, we support only security groups and mail-security groups.

The meaning of this support is:

  • On regular SharePoint sites, you can’t share a file with an Office 365 group or set permission to the site to an Office 365 group if this group isn’t in the allowed groups.

  • On OneDrive, you cannot share files at all with Office 365 groups (in the previous version you cannot share files with security groups and mail-security groups)

Limitations:

  1. It seems that is impossible to add an Office 365 group as a nested group of a security group

  2. When sharing an Office 365 group on SharePoint/OneDrive, the name of the group will include “ Members” at the end. It’s important because the governance check allowed groups by the groups' names, so it’s not recommended to add Office 365 groups to allowed groups at all.

  3. Webhook and short polling use a delta link to fetch the new members on the site. It seems that if you share a membership with an Office 365 group more than once, it’s not received in the delta link anymore.
    So, it’s important to enable long-run polling also to handle those cases