Security Roles in SharePoint Architecture: SharePoint Security Matrix

SharePoint Security Is Not Broken, But Are Roles Enough?  Enter Attribute Based Access Controls (ABAC)

Each time I get an opportunity to talk with a group of people at a conference or a customer connect meeting, I always like to ask if they have ever had formal training in SharePoint (and Teams) access controls.

The answer has always been and continues to be “no”.

What happens if you are a business user and want to do the right thing, and limit the access to your SharePoint site as it may have inherited too large of an access list?  You begin the process of changing it, only to be confronted by messages that seem scary  asking “Are you sure you want to do this”?

Since we have not had the training and we really do not know what the messages are telling us, we leave it alone and end up with over-permissioned sites.  What happens when people switch teams? Are we going into the administration site and removing access?  Offboarding is simply not done, and people continue to have access even though they no longer have a need.

SharePoint Security Roles

Microsoft SharePoint has a mature, well-structured role-based security model. As we have just discussed, it takes a lot of maintenance, and it is not well understood by the user community.

When a SharePoint Administrator manages the tenant, they can have broad access to any content stored in the various team sites by elevating their rights.  These are not misconfigurations. They are features of how SharePoint’s role-based access control model (RBAC) is designed.

The SharePoint Security Role Hierarchy

Here is a simplified view of common SharePoint and Microsoft 365 roles.  The key item to understand is that once you have access to a SharePoint site, you can see all of the content in that site all of the time.  Yes, your ability to change that content may be restricted, but you will see all of the files that are stored in that site.

The SharePoint Default Permissions

These are the commonly used default permission levels assigned to groups; however, some are only assigned to individuals to design and manage the site.

• Full Control: Full access to all features.
• Design: Allows users to view, add, update, delete, approve, and customize the layout of pages and lists.  Generally, the “design” permission is provided to a limited number of people.
• Edit: Allows users to add, edit, and delete lists.
• Contribute: Allows users to add, edit, and delete items but not manage lists or site structure.
• Read/View Only: Allows users to view pages and items/view without downloading (browser-based).
• Limited Access: Allows users to access specific items (like a shared document) without having access to the entire site.

SharePoint Inheritance: A Key Concept You Cannot Overlook

The most common method for creating new sites is to allow the site to “inherit” permissions from the root site.

A simple example is when a new specialty project is being set up by the project management team.  When a new project site is set up using the project management root site, the entire project management team will probably have access to the new specialty project site. This is because the new site “inherited” the access list from the root project management team site.

Say this new specialty project is for a top-secret M&A project called “Project Fissure”.  Your goal is to set up the site to limit access to only the “Project Fissure” team members.  That is when you head down the path of breaking the inheritance from the root site. SharePoint will display warning messages that you are about to break inheritance, and are you sure you want to do this?  This is where a number of teams get scared by the notices SharePoint provides, and they leave the site over-permissioned.

How can Attribute Based Access Control Help?

The largest problem with SharePoint RBAC is that the users of the site do not really know who has access (only the owner), or what permissions they hold if they do.  How many times have you tried to send someone a document only for them to get the “you do not have access” prompt?

Attributes are as simple as they sound.

For each document you are storing for this special project, you tag it with a label “Project Fissure” using a classification tool like our Spirion product by archTIS or leverage our integration with Microsoft Purview.  This is easily controlled by the content creators who are supporting this special project.

Every member of the special project team, you also add the attribute “Project Fissure” to their profile, be it Entra ID, Azure AD, or whatever identity system you may use.

Within NC Protect’s dynamic access control policies, you can then define that anyone on the Project Management Project Fissure team has full edit rights to the content, but the Legal team with Project Fissure attributes has view only rights, as you can use more than one attribute to define access rights.  Everyone else in the company does not have any rights to the content stored in SharePoint, as they do not have the Project Fissure attribute.

Sounds Very Similar To SharePoint Administration. Why Is This Better?

The key is how NC Protect then reveals or does not reveal content to the user accessing the site.

If you are a member of the project management team and visit the Project Fissure site, but are not a member of the Project Fissure team, you do not see any content.  To the non-project team member, there is no content to request access to because they cannot see any of it.

You can leave root inheritance in place, as access to content is no longer controlled just by SharePoint Administration.

ABAC policies also extend to the SharePoint Administrator.  Where they can elevate to see the folders contained in Project Fissure, without the proper attributes, they cannot see the content contained in those folders.

You cannot request access to content you do not see.

Securing Data Beyond the Role with NC Protect by archTIS

NC Protect works inside Microsoft 365, across both SharePoint and Teams, adding a dynamic, content-aware security layer on top of the native role model. Rather than relying solely on who has Site Owner or Admin rights, NC Protect evaluates both the sensitivity of the content and the attributes of the user and environment before granting access in real time for every request.

What NC Protect Changes

With NC Protect, even a user with SharePoint Site Owner permissions can be prevented from opening a document that their role does not justify access to. Access is determined by the sensitivity of the content and whether the user genuinely needs access to it, not just by what their SharePoint role technically allows.

This means organizations can:

• Restrict access to sensitive documents even for users with elevated SharePoint roles.
• Apply protections based on attributes such as content classification, user attributes, security clearance, or organizational policy, not just the site a document lives in.
• Control what users can do with information if access is granted.
• Prevent files from being downloaded, copied, or shared externally, and more.

The result is a security posture that goes beyond role management: one where your most sensitive data is protected based on its actual classification and your organization’s policies, not the broadest role a user happens to hold.