SharePoint is Microsoft’s enterprise-class environment for sharing content: documents, presentations, spreadsheets, notes, images, and more. While SharePoint has many advantages over a raw file system in terms of content management, access to the content still has to be permissioned.
SharePoint has its own permission types (view-only, limited access, read, contribute, and more) that can vary by the types of objects (lists, sites, etc.). For a complete list of all the SharePoint permissions and what they mean, check out this Microsoft resource.
SharePoint administrators can become just as confused about the level of access available as file system admins. It boils down to the same issue of understanding what the true permissions a user has for a specific resource. That’s not easy to do on your own. Varonis DatAdvantage for SharePoint helps organizations make sense of SharePoint permissions.
Common SharePoint Data Problems
Directly Assigning Users to ACLs
Many sites and directories within SharePoint have users with direct access to the site/directory. Directly assigned users add complexity to ACL management: since these users don’t belong to a group, it’s difficult to track down individual user ACLs when they need to be updated. They typically slip by unnoticed and are never recertified.
Failure to Recertify Access
Since most SharePoint groups are managed by business users rather than IT, they often don’t have the time to keep the ACLs up to date – often an issue when an employee moves to another group or leaves the company.
Too Many Users with Full Control
Due to the nature of SharePoint groups, the Owners group has full control over the site/directory to which it’s assigned. SharePoint groups are typically managed by business users. While IT can perform recertification, most business users are unaware of the steps, and therefore never complete a recertification on their data.
Too Much Stale Data
Stale data is an issue that affects many SharePoint systems. Stale data – data that’s no longer used or serves its original purpose – steals resources away from the rest of the site. Keep in mind that stale data can contain personally identifiable information (PII) and other sensitive information, increasing the business risks when there’s an attack or cyber incident.
Varonis Best Practices for SharePoint
Identify Actively Accessed Sensitive Data
Assign permissions and access based on the content of the data, especially for data that requires more granular protection, like sites/directories containing sensitive data.
Create data-specific security groups for these sites and directories and avoid direct permissions.
For example, a services firm may have sensitive customer data that should only be accessible to specific individuals. Once they identify the sites/directories containing this data, they should grant permissions only to individuals in a content-specific group – and should not assign permissions to departmental groups on that folder.
Classify and Monitor Sensitive Data
Classification and identification of sensitive data is critical to proper governance. By understanding where sensitive data lives, SharePoint admins can then lock it down through access management and proper permission structures. Removing stale sensitive data is a low-hanging fruit that greatly reduces risk with little or no effect on the user community.
Archive and Delete Stale Data
To limit the risk of exposure of sensitive data, admins can achieve a quick win by reviewing their stale data. Archive and transfer the data to a location where the permissions are set to a small administrative group, effectively removing all access from other users. Once the retention period for the stale data is reached based on company guidelines, the archived stale data should be deleted.
Identify and Utilize Data Owners in the Authorization and Recertification Process
Identify the owners of sensitive and protected data, and involve them in the permission authorization process as well as the recertification process.
Manage and maintain an owner-to-data mapping to ensure proper execution of both the authorization and recertification processes. The data owner’s goals should align with the site owner or site collection administrator on the SharePoint side.
Develop a clear process for access requests and recertification once ownership of a SharePoint resource is assigned to a business user. An authorization workflow can ensure that users are following the proper steps for requesting access allowing the business users who own the data to approve or deny requests accordingly. Log all approved/denied requests for auditing purposes.
A recertification workflow is essential for SharePoint groups as they are not typically managed by IT and are left with users who no longer need access. Without an authorization and recertification workflow, the state of the ACLs may return to their previous disordered state.
It’s important to disable Native SharePoint access requests for sites not utilizing external sharing. This will restrict access requests to the tool of choice where there is more capability around requests.
Define Standards for Access Permissions
The same steps can be taken from the Actively Accessed Sensitive Data section and can be applied across all managed sites and directories. Create data-specific security groups for these sites and directories and avoid direct permissions.
Many customers utilize different types of permissions for their SharePoint sites and directories. Adopting a least-privilege model ensures that a customer will only grant access to the users who need it and the appropriate level of access needed. In most cases, a basic set of three SharePoint permissions should provide the access that is needed: Owners (Full), Members (Contribute), and Visitors (Read). The fact that SharePoint has a permission level that provides full control to sites calls for extra precaution about who belongs in that Owners group.
Define an Appropriate Site and Permission Structure
For sites and directories, it is best to have a clear demarcation point for where sites and directories are disabled from inheritance and assigned groups are managed. Anything below the demarcation point should inherit as much as possible.
If a group of users requires the same access to a dataset, that data should be found in a common site or directory. This reduces the number of recertifications and authorizations that need to be performed and limits redundant provisioning of access. If a subsite or subdirectory requires distinct permissions, they should be managed separately or the data should be moved out from the current structure to its own top-level site/directory.
Active Directory Groups vs SharePoint Groups
While both SharePoint groups and Active Directory groups can be used for SharePoint sites and directories, Active Directory groups are typically better managed by IT so it is best to use Active Directory groups in most situations. However, SharePoint groups are required if external sharing is necessary.
External sharing requires the use of SharePoint groups. SharePoint groups must be tied to a data owner and managed the same way AD groups are. SharePoint groups can have their memberships recertified to ensure that only users that require access can access a site or directory.
In order to restrict excessive entry, disable anonymous access to internal sites. Anonymous access allows anyone to connect to a site without credentials and eliminates the ability to audit a user’s actions. Always be cautious with anonymous access and only use when necessary.
Want to learn more about how Varonis can help protect your data on SharePoint (and SharePoint Online)? Reach out for a 1:1 demo and see how Varonis can help streamline your SharePoint permissions, get you visibility into who’s accessing data on SharePoint, and help alert on (and remediate) any SharePoint data leaks and overexposed sensitive data.