SharePoint App Site-level Sharing Permission Change Notification
Note
This is a Limited Availability feature. Contact Netskope support to enable this feature.
Netskope has introduced a change in the way Microsoft Office 365 SharePoint Sites app site-level sharing permissions are computed.
Problem Statement
In a typical SharePoint site, files, folders, or any other resources are shared with default groups i.e. site members, site owners, and site visitors and to any other groups or users who have access to this site. Existing Microsoft Graph APIs do not reveal site level sharing information while calculating exposure of a file. This can result in inaccurate exposure calculation. This change notification talks about the various changes that are being made to address this limitation. To summarize, follow the FAQ below:
What are the new changes because of this site-level exposure calculations?
Site meta data will now have a section to store sharing information.
Exposure calculation of a file (during initial listing and ongoing flow) will now use sharing information from the site to calculate overall exposure in addition to file level exposure. This means even if a file is not explicitly shared, exposure will also take into consideration site level exposure and for example, if the site level exposure is external, Netskope API Data Protection will mark the file as externally shared.
Exposure of existing files will be re-calculated (based on the site-level exposure) if there are any edits made to these files after the new change is deployed.
What happens when permission-inheritance is broken on individual file or folder objects with these new site-level exposure calculations?
Does Netskope detect and alert? - No
Does the exposure of the individual file or folder object change because of permissions-inheritance being broken or do we still show only based on site-level exposure? - Yes
Existing exposure computation logic does not consider a specific SharePoint functionality. This means Netskope does not detect any break of inheriting permissions and ends up computing exposure based on site level permissions and explicit permissions given to the file.
What is the behavior with the retroactive scan with these new site-level exposure changes?
Once this feature is enabled, Netskope does not process files that are already listed to update the exposure. Customers can initiate file listing again with help from Netskope support to update exposure before running retroactive scan. However, this step is optional.. This is also applicable to any subsequent changes made to site level exposure.
Are there any UI changes in the Netskope tenant for this feature?
No. This is a back-end-driven change. If you intend to leverage this feature, you may contact Netskope support to enable the feature on your tenant.
What is the behavior with the Restrict Access policy action?
The Restrict Access policy action will not remove sharing at the site level. However, the policy action will continue to remove permissions explicitly applied at file level.
Caveats
This feature has the following caveats:
There is a delay (approx. 12 hours) in detecting new sites and exposure changes.
If there is a breakage in the inherited permissions, API Data Protection does not handle this use case as expected.