If you care about application SaaS and network security, understanding four little letters is crucial – RBAC. “Role-based access control (RBAC) is a method of restricting network access based on the roles of individual users within an enterprise. RBAC lets employees have access rights only to the information they need to do their jobs and prevents them from accessing information that doesn’t pertain to them,” explained TechTarget’s SearchSecurity.
While RBAC is critical for overall security, it has special meaning in the Microsoft SaaS ecosystem. For Microsoft Microsoft 365, RBAC is the only route to security, and admin efficiency.
Here is Microsoft’s spin on RBAC. “RBAC enables you to control, at both broad and granular levels, what administrators and end-users can do. RBAC also enables you to more closely align the roles you assign users and administrators to the actual roles they hold within your organization,” Microsoft explained.
Take Microsoft Exchange, for example, where RBAC took a great leap forward in 2013. “In Exchange 2007, the server permissions model applied only to the administrators who managed the Exchange 2007 infrastructure. In Exchange 2013, RBAC now controls both the administrative tasks that can be performed and the extent to which users can now administer their own mailbox and distribution groups,” Microsoft said.
At first blush, Microsoft 365 seems to have role-based access control (RBAC) fully covered. After all, Microsoft 365 comes with a wealth of administrator roles, some 22 different ones, such as Exchange or License Administrator. This looks great on the surface, but a deeper dive exposed the flaws.
Despite the RBAC label applied by Microsoft to M365 permissions, the native admin delegation tool in Microsoft 365 is simply too blunt, lacking the granularity in giving rights large shops need. No matter how much you limit M365 permissions, all admins have global rights, which means they can reach out and touch all end users – a security nightmare.
The Microsoft 365 Admin Center is a least common denominator style tool, not built to handle the demands of distributed enterprise deployments. Large organizations are, in essence, a group of separate, geographically dispersed entities, each with its own needs – are not served well by a one size fits all, centralized, globally-based administrative structure.
The native Microsoft 365 Admin Center’s centralized management model of setting privileges entirely relies on granting “global admin rights” — even to regional, local, or business unit administrators. There is simply no facility for setting up regional and other geographic-based rights. Nor can you easily set up rights based on business unit, country, or for remote or satellite offices. In addition, you cannot easily limit an admin’s rights granularly so they can only perform limited and specific functions, such as changing passwords when requested.
Any IT pro worth their salt recoils at granting a local or departmental IT administrator global rights. This is simply not the way modern enterprises are structured and has no way to properly secure the environment.
Meanwhile, making everyone who needs a decent level of access a full administrator means there are too many people with full access to the Microsoft 365 environment. Do not forget. IT pros are people too, and the more folks that have high-level access, the more chance these privileges are abused.
A proper approach to Microsoft 365 permissions and privileges is partitioning permissions based on roles through truly fine-grained RBAC, resulting in far fewer, truly trusted global administrators. These global admins are augmented by a set of local, or business unit focused admins with no global access, all leading to far better protection for your Microsoft 365 environment.
Proper use of RBAC increases IT productivity by empowering more local administrators — saving time and money. In fact, The National Institute of Standards and Technology in its ‘Economic Analysis of Role-Based Access Control’ study found that a 10,000-person company saves some $24,000 in IT labor, and another $300,000 a year from reduced worker downtime every year through RBAC.
Meanwhile, delegating Microsoft 365 admin responsibilities to those closest to the end users results in less micromanaging from the central office, and greater Microsoft 365 uptime across the organization.
CoreView was designed in the trenches by a Microsoft Gold partner and solution provider to improve the manageability and security for its large base of Microsoft 365 clients.
Using a simple, intuitive interface, CoreView lets IT segment the Microsoft 365 tenant in myriad ways — for example, by department, business unit, or location. After these groups are set up, IT can dive deeper, using CoreView’s RBAC capabilities to define specific permissions for administrators who then can only perform certain tasks and only against a specific subset of users.
CoreView further allows you to fine-tune what actions each admin can perform, and which reports they can see. With CoreView, admins are limited to making changes only to their assigned users, and can only perform actions they are specifically assigned.
CoreView found that a company with 10,000 employees could save 950 hours of administration time per year, at a projected savings of $45,600 a year – just by properly using RBAC to set Microsoft 365 admin permissions.
The CoreView approach to RBAC is far simpler than the Microsoft role-based administration model. In Azure Active Directory, Microsoft has defined many roles. One is Application Administrator, which includes 71 different attributes an Application Administrator gets permission to do something with – to read or write or change. “Nobody, not even folks at Microsoft, knows precisely what all of these attributes exactly mean and what this functionally gives the ability to do. How can an IT admin look the chief security officer (CSO) in the eye and say, ‘I gave them Application Administrator rights, and know precisely what he’s now able to do?’ They cannot. Moreover, Microsoft does not define what those rights are,” Smith argued.
In the CoreView model, if IT checks the box so a person can create mailboxes, that person can create mailboxes – but cannot do anything else. They cannot change somebody’s password, or look up what they are doing on Microsoft Teams. “This is a critical security area. Nobody has truly deployed least privilege access within the Microsoft Microsoft 365 ecosystem – unless they use CoreView,” Smith said.
CoreView offers deep Microsoft 365-specific security protection, governance and compliance. Learn how we help with a personalized CoreView demo.